Jump to content
  • Advertisement
Sign in to follow this  
renqilin

How to avoid VB buffer lock?

This topic is 4831 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!