Recommended Posts

I know it's bad to have lots of small buffers, but I'm making a solar system renderer type of thing, and I want to have a kind of asteroid belt. But I want each asteroid to be different, and so I have a CRock class, which has a draw function and vertex and index buffers as members, so I can pass it a D3D device and it will render itself. Is there a better way to store the vertices and indices so that I dont have lots of tiny buffers, but one bigger one? What will the performance hit be for lots of small ones? Maybe I could use impostoring to speed it up. My class heirarchy is like this:

The bodies is just a templated CBody factory, so I couldn't really store any vertices or indices there. Maybe I could have the buffers in the CSolarSystem class, then the bodies could store offsets or something. What do you think?
Edit: Heirarchy diagram was wrong.
---------------------------------------
Let's struggle for our dream of Game!
http://andrewporritt.4t.com[edited by - f8k8 on November 30, 2003 10:30:14 AM]

Share this post

Link to post

Share on other sites

even if the asteroids are dynamic store them all in one big vertex buffer and render from it.the problem in using alot of vertexbuffers is that the call to SetvertexBuffer will cause a load on the processor without doing any thing useful and you may be processor bound not rendering bound.

0

Share this post

Link to post

Share on other sites

Keep your data (mesh data and similar) seperate from your world instances. If you have five hundred asteroids, and you want instanced info about them all then they should not have the vertex data in your object. Should have a simple token or id for rendering a particular vertex buffer. This way you can do a few things depending on your needs.

If you want to position/rotate you objects you are simply pushing a matrix on the stack before rendering the same vertex buffer. Obviously you would probably want to make sure all asteroids were rendered together, so make the renderer a little intelligent and cache render calls to the same mesh instance with different matrix ops.

If you want to animate an asteroid its very easy to animate it on the render side rather than in the instance. Also, by separating resource data from instance information you are minimising data doubling.

With this method also, most of your world instance information becomes very generic. A node may contain a token for a mesh, a token for a sound, a token for a motion and so on. Making it much easier to handle the nodes throughout your code. You would then end up using simple grouping methods or spatialisation algos (like quadtree or octrees) for maintain positional relationships, or even a simple grouped hierarchy would do.

As far as the vertex buffers go, get them out of your main code, and have a renderer look after them. You should have largish buffers that get filled as infrequently as possible. And also ideally stripped triangles, with state sorting. (ie keep vertices of same materials in same buffer).

If you need vertex info, in you world instance (i really cant think why) then have a mechanism for getttin the vertices from a render token. Most of the time this would be if you are doing collision or physics on an object. But you would have a collision object in the collision system that represents the world instance - often built from the mesh. But this should not be in the instanced object, because you should only need one collidable shape for the asteroid shape, and it is again shared anmong all instances..