How to avoid VB buffer lock?

Started by
4 comments, last by renqilin 18 years, 10 months ago
while performing skin animation on a mesh, we need some VB to store the transformed points. simply i used to use two way to achieve this: the first way: . Create a D3DPOOL_DEFAULT vertex buffer, which can accommodate the incoming data. . And in gameloop, lock the vertex buffer(severe performance hit !) . transform the points, and copy them into the locked buffer. . unlock and draw. the second way: . Create a D3DPOOL_SYSTEMMEM vertex buffer, and lock it only once. preserve the pointer. . In gameloop, copy transformed points into the previously preserved pointer. . draw The drawbacks of the two way are abvious: the first way has no efficiency, while the second way, data needs to be copyed twice: one is from your buffer to VB, one is from SYSTEMMEM vb to vedio memory. i need to find a more efficient way, is there anybody can give me some advice?
Advertisement
Use Direct3D skinning and let the vertex buffer alone.
Just pass the new animation matrices instead of new transformed points.
Take a look at skinned mesh temo (tiny.x). You can also go hardware and gain a huge performanence boots, because you just pass the NEW animation matrices to the video card and all skinning in done in hardware.

Try to implement the software skinning first, to see if your matrices are correct aligned and then switch to hardware. By software skinning I mean check the sample what it does when it uses software skinning. I believe there is something like *skin(new matrices, NULL)*. Just leave the second parameter alone, because it is not used.
Samurai Jack:

I agree with you that hardware skinning is an efficient way, and it can avoid lock on VB. but...if there are hundreds of dynmaic objects in a scene, with many effects(such as fire, water,etc.) , then the GPU is very busy, and the CPU is left idle. In this case, i prefer drawing pre-transformed vertices in order to lower the burden of GPU.

As the sample you mentioned, it still used "Lock" operation as the most commonplace skinning.
I guess it really does depend on you app, and wether it's already GPU or CPU limited, but a crutial thing to remember is that GPU's are hardwired from the ground up to be as effecient as possible with things like matrix multiplication and vertex transformation. A CPU is much more general purpouse, and thus will generally be slower. Also, consider that in most games the CPU will be handling physics, game logic, input, sound, file IO, networking, etc. It's usually best to simply let the GPU take care of whatever it can.

That said, if you have need for per-poly collision detection or other CPU only operations that require transformed points then yes, you're better off doing it on the CPU.

[Edited by - Toji on May 25, 2005 3:31:48 PM]
// The user formerly known as Tojiro67445, formerly known as Toji [smile]
the third way:
- Create your verts in memory. (no VB, just an array).
- Create a dynamic VB. (Default Pool, Dynamic, WriteOnly)
Every Frame:
- Use/update your memory verts.
- Update (in part or in whole) the dynamic vb.
- Draw.

Don't try and read back from a default pool resource. The dynamic flag will help the graphics hardware make the types of operations you want to do efficent as posible.

You have got this a couple of times already, but look at hardware skinning as a much more efficent option than using dynamic buffers will probably not redistribute the processor load as you expect, but cause everything to run slower. This is probably not the way to take advantage of an underused CPU.
thanks to all. i think i got the idea.

This topic is closed to new replies.

Advertisement