Vertex buffers in 3d engine design
Author
Ok. First a little background. I've been working on my 3d engine using a top-down approach so I've implemented basic scene management and rendering. A scene is an abstract data-structure that organizes scene objects. When drawing a scene the renderer iterates through the renderable objects in the scene that is in the view frustum and call a Draw() method with the renderer interface as parameter. The renderables in the scene uses the renderer interface to draw themselves.
So what I now need to do is to implement methods for drawing primitives in my renderer interface. I'm not too familiar with vertex buffers but I know that they are used in the directx 9 API and necessary for getting good performance. I have a couple of questions:
1. In what "level" should vertex buffers be allocated and used? e.g. should the client programmer that uses my 3d engine need to be concerned with vertex buffers?
2. Striving for API independence what basic vertex buffer management and primitive drawing methods should the renderer interface provide?
I appreciate any comments. Thank you.
You probably want to be able to create and lock/unlock the buffers (in GL this is done with glMapBuffer). You might want to put an option for shadow buffers (system memory copies that allow for faster reads). And you want to be able to bind them. GL can source its attribute information from seperate streams, but I'm not sure D3D can, in which case you probably want some way to describe the vertices stored in the vertex buffer. You might want to check out the OGRE buffers, as they seem to be done decently.
As for the first part, you want to expose the ability to load up a vbuffer and use it somehow (unless you are at a really high level). Are you writing the model loading code, or is the client? That kind of question really determines how much you expose.
As for the first part, you want to expose the ability to load up a vbuffer and use it somehow (unless you are at a really high level). Are you writing the model loading code, or is the client? That kind of question really determines how much you expose.
Author
Perhaps I should describe how I vision my engine to work.
I must admit that starting out I had no other goal in mind than creating an 3d engine that provides an easy way of managing and rendering scenes. The client programmer sets up the scene(s) by selecting appropriate data-structure provided (octree, list, whatever) or creates a new one using an scene interface provided. Building the scene will only be a matter of adding scene objects to it. The client programmer should not have to worry about constructing the scene(graph) manually by adding nodes etc.
The engine should provide basic scene objects present in most scenes such as camera, light, and mesh. I think it is natural to have the engine provide methods for loading meshes etc. Since vertex buffers is to be shared among several meshes, the allocation and use must be handled by the client programmer at this point (or not I'm not sure, perhaps that is to be handled by mesh creator factory thingie.. not something I got a good check on I must admit).
I must admit that starting out I had no other goal in mind than creating an 3d engine that provides an easy way of managing and rendering scenes. The client programmer sets up the scene(s) by selecting appropriate data-structure provided (octree, list, whatever) or creates a new one using an scene interface provided. Building the scene will only be a matter of adding scene objects to it. The client programmer should not have to worry about constructing the scene(graph) manually by adding nodes etc.
The engine should provide basic scene objects present in most scenes such as camera, light, and mesh. I think it is natural to have the engine provide methods for loading meshes etc. Since vertex buffers is to be shared among several meshes, the allocation and use must be handled by the client programmer at this point (or not I'm not sure, perhaps that is to be handled by mesh creator factory thingie.. not something I got a good check on I must admit).
If the engine takes care of loading meshes, you will want it to have some kind of caching scheme for vertex data anyway, so in that case the client can ignore vertex buffers (if I understand your design right).
Author
May I ask how this caching scheme might work? E.g. how do you determine the ideal size of a vertex buffer?
Well, for one, mesh instances can all source from a single VB, so you at least want some infrastructure there for that (something similar to textures, with refcounting or something, just to make sure a resource doesn't get loaded twice).
I can't say whether combining VBs is a good idea (I don't do it), but that's just a matter of trying to fit a mesh into one of the active VBs, and if it doesn't fit into any creating a new one (or precomputing for better fits). For optimal VB size, check the nVidia/ATI websites, although in a GDC presentation recently I think I saw 5mb floating around (for DX)? Don't take my word for it though.
I can't say whether combining VBs is a good idea (I don't do it), but that's just a matter of trying to fit a mesh into one of the active VBs, and if it doesn't fit into any creating a new one (or precomputing for better fits). For optimal VB size, check the nVidia/ATI websites, although in a GDC presentation recently I think I saw 5mb floating around (for DX)? Don't take my word for it though.
Author
Thank you, I'll look into it. I figure I'll start out trying to implement a Mesh class and see exactly what features I need. The top-down approach suits me best. Otherwize I'll end up with lots of generic classes and end up not implementing them to 100% and only using a few of the features I thought I would need. That usually results in "ugly" code that feels unfinished. Anyway, that is not really relevant.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
