   Dynamic Vertex Buffers
  I'm reading through the book 3D Game Engine Programming (Zerbst, 2004) while a little dated, might have some decent ideas still applicable today.  One I'm trying to get my head around is the idea of introducing a layer of caching between the engine's draw calls and the actual D3D draw calls using a vertex caching scheme based around filling up several dynamic vertex buffers until they either need flushed, or you're done for that frame.  I'm kind of skeptical of how he handles vertex translation/rotation/scale, etc.  Basically anytime the world matrix needs to change (you translate to the next model's position, for example) it needs to flush the buffers, resulting in a DrawPrimitive (or related) call.  I'm having trouble seeing how you would ever end up with more than one set of local vertices in one of the dynamic buffers with this scheme.  Wouldn't this require translating/rotating/scaling every single vertex before putting them in a dynamic buffer in order to achieve any sort of batching?I guess I'm a little unclear on the benefits of dynamic buffers in general.  Are they only meant to contain vertices that get translated, rotated and scaled as a group, or is there some other piece I'm unaware of?   
  Dynamic buffers would be useful if you're doing a particle system on the CPU, for example. Then you have a lot of small primitives which change every frame, and probably share textures, so pushing them into a dynamic buffer and flushing when needed will work well. From what you describe I agree that the method described in the book doesn't sound effective.   ;  Dynamic vertex buffers are good for geometry that's dynamic. Particles are a good candidate, like ET3D mentioned. Or maybe some sort of cloth simulation where the vertices are animated on the CPU. For static geometry, you'll want to put it in a static vertex buffer and leave it alone. Then for any transformations (translation, rotation, scale), you can just apply a world matrix on the GPU. If you do have multiple instances of the same mesh/geometry, then you can use instancing techniques to draw them in a single draw call.   ;  I think that clears things up a bit.  I was worried it might not be a good thing to have a static buffer for each unique geometry (not instance-able, for example, a rock, a tree, a different tree, a house, etc) in a scene that needs to have its own position, rotation, etc, but it is sounding like that is either not so bad, or unavoidable.   