Jump to content
  • Advertisement
Sign in to follow this  
Opwiz

Vertex buffers in 3d engine design

This topic is 4726 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
May I ask how this caching scheme might work? E.g. how do you determine the ideal size of a vertex buffer?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!