If I have multiple identical models to be rendered, is it faster to put a single copy in a vertex/index buffer and then render this multiple times with different transformations or is it faster to transform the pixels as needed per object and then put them all in a single vertex/index buffer? The former means you don't have to transform the actual vertices in your own code, you simply use the matrix transform to correctly place each object. This is efficient in that you're not locking/unlocking the buffers, but it also means you're not getting near the ideal number of vertices in the buffers for rendering/call (I'm basing this on DirectX rendering of indexed buffers). The latter would require the vertices for each object to be transformed every render and then inserted in to the buffers. This can, I think, be done with only a single lock of the buffers and will mean that the vertices are nearer to their optimal size. Are there any other options? Is one of these options clearly better? Will it depend on whether you're rendering 10s or 1000s of objects? Any suggestions? How are others handling this? What about if the vertices for the objects are identical, but the textures and materials are different? Onnel [edited by - onnel on September 13, 2002 4:54:29 AM]

I''m definitely with oyu on everything you wrote, but a few additional questions:

When you talk about putting many meshes in a single buffer, that means that those meshes must have their vertices in world coords (since you cannot specify different transforms for multiple objects in the same buffer) and that all of the objects must have the same texture and materials.

Based on this, I''ll try and minimize the number of different buffers I have to use by making sure that objects with the same texture in buffers (I already do this). My problem is with moving objects, though. since I need global coordinates in the buffer, then I''m going to have to do the transformation on the cpu before inserting the vertices in to the buffer. This goes directly against your advice (which KI think is good) to push the transformation to the video card.

I realise that vertex shaders could be used to address the issue, but I''d like to be able to support older cards which don''t have vertex shaders (what''s the oldest card to have a vertex shader implementation? GF3?)

Onnel

P.S. As always, thanks for your replies. We seem to browse at the same time!

pieman, everything you wrote about vertex shaders makes sense..my only worry is support. What cards support vertex shaders at speeds that make this approach worthwhile? The whole point is to do something faster than either performaing the transformation on the vertices on the CPU before transmitting them or having to perform lots of individual calls to render (one for each transformed mesh).

Vertex shaders definitely fix the issues with those two methods, but are they supported widely and well enough to make it a faster solution for most users?

What method are most games these days using?

Onnel

Quest, I thought that this answered everything, but it would seem that I'm still going to be doing DrawPrimitive calls with far less than the optimal number of vertexes (since I'll have to be readjusting the transformation and rendering speerately for every instance of the mesh in the buffer). At that point, it's no difference than having a single copy of the mesh in the buffer and just rendering the whole buffer multiple times with different transformations.

Can you spell it out for me a bit more?

Onnel

[edited by - onnel on September 13, 2002 7:22:24 AM]

Great...I understand the alternatives now and am confident that i''m not missing any huge pieces of the puzzle. Now it''s time for me to try the various alternatives out!

Thanks again for giving me the dumb downed version.

Onnel