🔒 Locked

Model animation

Started by Bouga Dec 25, 2004 at 7:59 AM 1 reply 400+ views

Original Post

Dec 25, 2004 at 7:59 AM

Hi, right now I'm working on the design document for my next game, though its more a big paper on what to do how in the engine, not the game itself, but with respect on what the game will need from the engine to do. So now I've come to character animations - or any other objects that will require bone animations. Where to do the new vertex position calculations? Should I do it with a shader? Or should I do it on the CPU? I guess if only drawing was the issue, then the shader would, of course, be more efficient, right? Since matrix math is performed faster on the GPU (4 paralell operations), right? But what happens when collision detection comes into play? I heard a talk by John Carmack, where he said he was not doing bounding box collisions in D3, but colliding with the model itself. Is that the way to go? I guess so, if I want to have decals on the model itself, like the blood in D3. If so calculating the new vertex positions has to be done on the CPU. So maybe I should do all the calculations on the CPU? But a creature will not get shot at every frame, so I have come up with this solution: Calculate the new vertex position/tangent/bitangent & normal in the shader for rendering. And only when the creature geets shot at (a bullet collides with its bounding box, one that covers the whole model), calculate only the new vertex positions & do the collision detection. (Will do allmost double work, but only once per the frames it needs to be done.) So what I want to know - is this the way to go, or is there a better, more faster way, in terms of performance? Any opinions/experiences are welcome. Thank you. EDIT: damn, forgot one very important aspect :) What if i need to do some multipass rendering? Am i guaranteed to have a better performance by precalculating the positions/tangents/normals every frame & then just use them each pass? [Edited by - Bouga on December 25, 2004 8:40:38 AM]

yzzid

Dec 25, 2004 at 8:42 AM

Unfortunately, the answer to your question of whether to do your animations on the CPU or GPU is, it depends. Let me explain.

The key to getting great performance out of a game/engine is the following:
balance between the GPU and CPU.

Here is what I mean:
Doom 3 uses a lot of per pixel lighting effects, etc. Therefore the GPU is used heavily for all these effects. This is why Carmack decided to do animations on the CPU. Therefore he balanced Doom3 to effectively use the CPU and GPU.

If you have a game that does everything on the GPU, most likely the CPU will sit around waiting for the GPU to finish doing its job. The same goes for the reverse. If you do everything on the CPU, the GPU will sit around doing nothing while the CPU is chugging along processing all its tasks. A finely crafted engine balances the two, using the CPU and GPU to its full potential. Unfortunately, this takes a lot of profiling, which could take a long time to tune your game.

So, what you really should do is figure out which processor (CPU or GPU) is doing the least amount of work and use that to do your animations.

Hope this has shed some light on the topic for you.

Let me know if you need more info.

Bouga

Author

Bouga

Dec 25, 2004 at 8:55 AM

Not so simple, eh, thats what i was afraid of... then, is this a good way to balance between GPU & CPU? (I use OGL & lets presume there really are some heavy shaders applied ).
Do all the vertex/normal/etc calculations on the CPU for one model, or a part of it, if it can be split up. Store the results in vertex arrays.
Draw them, using glDrawElements, this call should be non-blocking if theres still place left for atleast one instruction in the OGL render queue, right? So the next calculations on the CPU should take place while this glDrawElements call is still rendering, right?
Then do the same for the next model/model part.

EDIT: damn, forgot to mention that the rendering would be done in the start of the game loop, so the new vertex positions are already calculated (efficiently, becouse of the GPU/CPU usage at the same time) when they are needed for collision detection later in the game loop.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.