Rendering many different objects

Batch your vertices together and don''t store them in vertex buffers until you go to render, at which case you copy your vertices into one dynamic, write-only vertex buffer and render them. Of course there''s exceptions, but that will work for most objects. I made a post here for my dynamic vertex buffer class to help you out if you need a reference. Good luck.

---
Brent Gunning | My Site

> The point of the problem is how expensive is SetStreamSource change...

There are worse things you can do, but it''s certainly not free. In addition there''s memory overhead associated with every vertex buffer you create. So packing meshes into vertex buffers is usually a good thing, up to the point where they are so large that they interfere with memory management.

> copy your vertices into one dynamic, write-only vertex buffer and render them

Dynamic VBs usually live in AGP memory which is great if the CPU is modifying them frequently -- CPU writes to AGP memory are extremely fast. But the downside is that the GPU has to copy them across the AGP bus as they are rendered.

If the vertices aren''t changing, they are happier in a static write-only VB. That way they''ll likely be allocated in local video memory where the GPU can read them quickly.

I had that very same problem than you, and I decided to continue using static vertex buffers like the ones you''re using now.

I don''t think that filling a dynamic vertex buffer with 300 vertices will be faster than doing a SetStreamSource with a static vertex buffer and then calling drawprimitive. Maybe it could be faster if you draw all of them in a single drawprimitive call after batching. But it is very likely that you will have to still render model per model for setting materials, shaders and matrices on every model.

Dynamic vertex buffers are designed primarily for dynamically generated vertices (lod terrains, water, skined meshes)

Actually, I''m more concerned about SetVertexShader calls, I think I read somewere that from all the SetWhatever calls before a drawprimitive call, SetVertexShader is the slowest of them... I would love if anyone could confirm/deny it...