   Number of VB/IB?
  I understand that for optimal performance in direct3D you should have as few vertex and index buffers as possible. I was going to create a class to hold a single vertex and index buffer that would be used by all the primitives/meshes, would this achieve optimal performance? Currently I am using USHORTs for my indices so I would be limited to 65536 indices. Would it be better to switch to ints or start a new index buffer when the first is full?   
  The actual total count of VB's/IB's is largely irrelevant - VRAM permitting you could have a million of them if you really wanted.The more important question is how you use them - the logic behind having a small number is that there are less SetStreamSource() and SetIndices() calls (both of which are relatively expensive). If, via some culling system, you only render from 30 different source yet have 1000 in memory then that isn't particularly bad. Alternatively, if you have 1000 in memory and render from each of those 1000 in every frame then yes, you probably will have a problem.ID3DXMesh uses a pair of IB/VB for each instance - it doesn't to my knowledge pool them across/between instances. So what you're describing sounds fairly similar to a pooled version of D3DX's implementation.Bare in mind that moving from 16bit to 32bit isn't straightforward. Allowing 32bit doesn't necessarily mean you can store 4.2 billion (232) unique vertices, rather it means you can store more than 216 unique indices. For example, my GeForce 6800 only allows up to 224 (~16.7m) unique indices even though it supports an IB with D3DFMT_INDEX32.Finally... I'm personally a fan of implementing it with performance in mind, but not adversely affecting your architecture just to suit some arbitrary limit. If you design it well you should be able to come back to it later (when a performance profiler says so) and change it. Refer to the classic statement: "Premature optimization is the root of all evil" [smile]hthJack   