even with instancing....there will be may changes...i guess i'll create some kind of manager for all of this....
i'll make the goal 2 mb for each vertex buffer.
unless you have a LOT of meshes with one texture, you'll never get there.
2 meg of vertices?
"some kind of manager" is the right way to go.
apparently it's called a "render queue". i call mine a "drawlist" (a list of stuff to draw, duh!) <g>.
as stated "state changes" are costly (time wise).
what you want to do is make sure your manager (render queue) sorts drawing on the most to least expensive state changes.
to the best of my knowledge, the relative costs of state changes are as follows (highest to lowest):
1. binding a texture.
2. binding a vertex buffer
3. binding an index buffer
4. material changes
5. constant buffers
6. other state changes (alpha test, cull, clamp, etc)
unless you put everything in one buffer then draw ranges (sections of the buffer) based on texture, its unlikely you'll ever get to 2 meg for a vertex buffer. even less likely for an index buffer.
but then again, you might. each game is different.
in my case, an efficient data layout sorted just on texture, not even mesh or near to far, combined with state management while drawing for the rest, allows me to do ~10,000 small static meshes of 4-100 vertices each, AS SEPARATE BUFFERS AND CALLS IN FIXED FUNCTION PIPELINE with no problems. read my signature block. below.
Edited by Norman Barrows, 01 September 2013 - 10:01 PM.
"DirectX is like a belt fed machine gun, where every texture change is like hand loading in a new belt of ammo. worse, every mesh (vb) is a new belt of ammo, and a texture is like breaking the gun down, and setting it up again elsewhere, then loading it, then spraying triangles again. so you want to setup the gun once, string all your belts together, load it once, then just spray."
Rockland Software Productions
"Building PC games since 1988"