the documnetation that comes with the DX SDK has excellent information on vertex/index buffers and how to use them most efficiently.

In a nutshell. By locking a vb/ib (vertex buffer/index buffer), you're telling d3d that "Im using these vertices/indices". If d3d knows this then it wont do any processing on the vertices you are using. When you unlock, you are telling d3d that you're done using those vertices, so now d3d can do whatever it wants to it.

You have to lcok vertex buffers to put data inside them. When they are created, all the vertices have garbage values. SO you need to lock the buffer to get a pointer to the buffer, then through this pointer you can put data into the buffer.

As for how to lock, well you have two types of data that you put in a buffer. Static data, and dynamic data. Static would be the vetices of a room (usually dosen't change) and dynamic would be a particle system (usually changes every frame).

For static data you just usually lock teh buffer once and fill the whole thing at load time. So there isn't really very many things to take into consideration - abuse load time as much as you can :)

Dynamic data on the other hand has to be filled in almost everyframe. Every frame you'd lock the buffer and tell d3d that "Im using this portion of the buffer, dont touch it, do what you want with the rest of the buffer". You do that by specifying the D3DLOCK_NOOVERWRITE flag when locking a buffer. This lets you update a portion of the buffer (the changed portion) and also lets d3d access teh rest of the buffer. This is necessarry because usually other parts of your buffer are still being rendered, so if you locked the whole buffer, youd cause a stall in the graphics pipeline (you'd have to wait till the hardware was done rendering and only then would you be allowed access). But with the NOOVERWRITE flag, you allow the hw to work in parallel with you.

Again the sdk docs describe three different ways of making use of dynamic vb/ib. Make sure you read it all.

JDUK: That is correct, the room would be static and the character would be dynamic. And yes there is a big performance gain to be had by carefully managing buffers. I don't have the exact links handy but nVidia's developer site and ATI's developer site have a lot of documents on optimizations and how to properly manage data in a buffer. They have all these charts that show you how much of a performance increase was achieved with various tests. the nvidia and ati developer sites have a lot of similarly useful documents/presentations on different aspects of graphics.


onnel:

1) Well there are many ways to keep track of where your data is within a buffer. It can be as simple as keeping a variable that tells where in the buffer it starts and another variable that keeps track of how many vertices is part of the object.

2) Definetly if you have data that is never going to be changing then storing all of that in a single static buffer is better then storing them in different buffers. Dynamic buffers are usually a "See which case gives best performance" issue. See link below.

3) If you haven't seen the VertexBuffer Optimization yet, I suggest you take a look at it. *Very* good info in there, and some of the main docs I mentioned above are directly linked from there as well.