Sign in to follow this  

Vertex/Index bufferseses

This topic is 4557 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

Up until recently I've been using multiple dynamic buffers (for dynamic vertex data obviously), but I got to wondering and after doing a considerable amount of searching on how to properly use vertex/index buffers I came to the conclusion that all one really needs are a couple of buffers (if one were to follow the rough guidelines on Nvidia's developer website for filling these buffers). So, the question I have is, is this correct thinking? If I were to have 1 huge buffer for static mesh data, and one buffer (obviously not huge) for dynamic vertex data that gets appended/filled per frame, would this be an effective strategy? Or is it a better idea to have multiple dynamic buffers? And isn't there a performance penalty for switching between buffers like that? Computers suck. I apologize if this has been covered a million times. Just post me a link to the proper forum discussion if you don't feel like repeating stuff that's been said a million times over. [Edited by - Tape_Worm on June 23, 2005 8:42:36 PM]

Share this post


Link to post
Share on other sites
My approach is kind of like what you suggest, but not exactly. I don't think it's wise to create one huge buffer for all of the static mesh geometry, because you still have to make multiple DIP calls to draw more than one instance of the same model. However, I recommend something similar, but a little more refined:

After all your entities are created, and you know how many times the same mesh can be drawn, fill a vertex buffer with multiple copies of the mesh data. Now, you have one vertex buffer, with n copies of the same geometry - this means that you can draw that model n times in the same DIP call. This is very efficient.

But what about the separate transforms of each object? In the shader, we will store an array of world matrices, instead of just one. In the vertex structure, there is a member that holds the index of world matrix that it should use. Like this:

struct VERTEX
{
D3DXVECTOR3 position;
D3DXVECTOR3 normal;
D3DXVECTOR3 tangent;
D3DXVECTOR2 texCoords;
D3DCOLOR transformIndex;
};


We can store other useful data in the other 3 bytes of the D3DCOLOR, if needed. Also, the number of copies of the mesh in each vertex buffer is dependent upon the buffer's maximum size:

n = maxSize / (numVerts * sizeof( vert ))

I hope this points you in the right direction. This is kind of a crude version of instancing, but it works, even on old hardware. If you support vs 3.0 though, try out the hardware instancing.

Share this post


Link to post
Share on other sites
That's a really cool idea. I never really considered doing instancing in that fashion before. However, I think it's probably a little more specialized than what I was thinking about (which is my fault, I didn't really say anything about being generalized). However, it'd make a neat alternative system to use with regards to instancing for people (i.e. me) who lack hardware instancing capabilities.

I'm glad to hear I'm not entirely off track here with this stuff. I've been using Direct3D for quite some time now (exclusively a hobby) and I've tried multiple methods of dealing with these buffers. I've never really ran into any issues (performance or otherwise) with any method I've tried, however my data set was quite limited and not at all on par with a game. The reason why I ask is because I've used OGRE/Axiom as a guide sometimes for scenegraph organization techniques and general rendering tips, and they used multiple vertex/index buffers for each model. Considering the popularity of these engines, and how well they appear to perform, I had started to question my initial thoughts on how vertex/index buffers should be used and maintained. Anyway, I'm babbling.

Thanks for your input circlesoft.

Share this post


Link to post
Share on other sites

This topic is 4557 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this