9
\$\begingroup\$

Just a bit curious - where do you perform mesh manipulations, on the CPU or in the shader? I've been doing everything on the CPU and a friend suggested moving things on to the GPU side.

If you're doing things like bone animations... on the GPU, how do you get back the mesh? (since I'm doing collision detection...)

\$\endgroup\$

1 Answer 1

14
\$\begingroup\$

This commonly happens on the GPU, but there are trade offs for both and it's up to you to decide which will work best for you.

Doing the manipulation on the GPU means you only need to send the mesh data once, then you can just send the matrix transforms to deform it. This is great because it greatly reduces the bandwith required between CPU->GPU. It also means you can upload just one copy of the mesh to the GPU and apply transforms for many different instances of the mesh. However, it's more difficult to have "mesh accurate" collisions. Since the transforms are done on the GPU, you don't have them available to test with on the CPU.

Doing the manipulation on the CPU means you have access to the transformed mesh. You can access everything you need to know about it. However, it means you need to upload that entire mesh to the GPU each frame. It also means you have to upload a transformed mesh for each instance of that mesh. In summary here's a no where near exhaustive list of pros and cons.

  • Pros for GPU

    • Upload the mesh data once
    • Transform it for multiple instances
    • Only need to send the matrix transforms
    • The GPU is very good at parallelizing these types of things
  • Cons for GPU

    • Transformed meshes are not available for testing on CPU
  • Pros for CPU

    • Transformed meshes are available for collision tests and anything else needed.
  • Cons for CPU

    • Need to upload the entire transformed mesh each frame
    • Need to upload an entire mesh for each instance of the mesh

There are ways to get around the cons for the GPU however.

  • Don't have mesh accurate collisions. Use something "close enough" like a bounding box for the entire mesh or have bounding boxes for each bone of the mesh. The below is using on the GPU transforms for the mesh, and on the CPU transforms for axis aligned bounding boxes that represent the mesh. You could get even more accurate bounds by using non-AABBs.

goblin bones

  • Transform a copy of the mesh on the CPU if and only if mesh accurate collisions are needed. After a bounding box collision has returned true, transform a mesh to match the transforms on the GPU, then check the collisions against that to get more accurate collision data.

All-in-all I assume you can see why it's more common to transform on the GPU

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Just out of curiosity, is it actually practical for meshes to be transformed on the CPU when taking into account the complexity of meshes in modern games, the power and multi-core abilities of a modern CPU and the other tasks a CPU must do? Also, is the uploading to the GPU so slow that this idea wouldn't even get off the ground? \$\endgroup\$
    – R4D4
    Commented Dec 30, 2012 at 16:45
  • \$\begingroup\$ It would depend on the game, but it's usually not practical for games above a moderate complexity. When there's such a easy choice of doing the transforms on the GPU, it's hard to find a reason to justify the additional resource requirements of doing the transforms on the CPU. The issue is more with sending the transformed mesh to the GPU every frame, that gets expensive fast. As is often the case with software it's up to the developer to make the decisions between complexity and performance. \$\endgroup\$
    – House
    Commented Dec 30, 2012 at 17:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .