what is wise, speaking of memory usage, when I create a set of static vertex buffers? More specifically, if I allocate say 16 megas, only for vertex buffers, will directX swap them between the main memory and the video ram? is it stupid, far too much, etc. ? any insight appreciated, I dont know what size of vertexbuffers I can realistically handle within the app.

Quote:I dont know what size of vertexbuffers I can realistically handle within the app.

You can handle as big a buffer as D3D reports you have available memory. On my 128mb card I can expect to get a good 100mb's of geometry in VRAM if I wanted it.

If you want an answer to your question with regards to what will give you the best performance then you need to dig into ATI/Nvidia's developer relations sites. They have numerous optimization guides that will tell you what a particular piece of hardware "prefers" (e.g. how many primitives per batch).

Quote:will directX swap them between the main memory and the video ram?

If necessary, yes it will. I can't remember if the D3DPOOL_DEFAULT does this, but definitely D3DPOOL_MANAGED will page memory in/out of VRAM as necessary - but avoid it if you can as it'll kill performance.

hth
Jack

thats great, you made a clear and informative answer! Thanks a lot. I feared somebody would say that it was stupid to use more than a few megs of ram for vertex buffers.

a correlated question: its faster to have precalculated many vertex buffers, even if Dx has to swap between main and video memory, compared to making too few vertex buffers, and having to calculate them on the fly?

Quote:a correlated question: its faster to have precalculated many vertex buffers, even if Dx has to swap between main and video memory, compared to making too few vertex buffers, and having to calculate them on the fly?

Difficult to say for sure. In general, locking/writing/unlocking of a vertex buffer is a slow operation - especially if read-back is required. So "having to calculate them on the fly" has obvious drawbacks.

As counter-point, lots of vertex buffers can mean lots of state switching internally and/or paging in/out of VRAM which is equally detrimental to frame rates.

For the majority of games, you might as well just create the geometry for everything you need - more than 30mb of pure vertex data would be rare, and given the large number of 64->256mb cards these days...

If you're expecting to deal with a huge amount of vertex data, grouping everything together into a couple of vertex buffers is probably a good idea, and then use index buffers and batched drawing to control the final output.

The ideal thing for you to do is run a few tests (with profiling using PIX) on the size of data and typical environments you're wanting to handle. Your question, as it currently stands, is a bit too open ended to give you a "correct" answer...

hth
Jack

thanks, I will try both method.