Hi guys, my question is a bit between CPU and GPU. I am working on getting Collada Animations to work in our current engine. To do so I loaded all bones and added all the frames their animation matrices, timings and interpolation types to them. I modify the vertex data for each vertex to have 3 bone weights and affiliations. The current implementation ignores the whole tweening on itself, which feels kinda silly (you will prob. notice the animation skipping if looking closely...). My question is what would be the best way to tween? I have 2 options in mind which for me sound like the best, depending on hardware and tested speed: 1. The animation data is interpolated on the CPU before send as shader data. This uses for example 80*3 float4 = 240 variables. Shader model 2 at least required. 2. All animation data is projected into a texture, and read by the vertex shader in some exciting indexing way. My calculation is that this would need about 6 reads, which is kinda much. Plus side is a lot of variables are open and make way for instancing. Shader model 3 with actual VFetch support is needed (so no fake ATI cards either). Unless I am missing some option here, I think the first is the best as a general solution, where the second might be awsome depending on test results... What's your opinion, am I missing something? What would you do? Has anyone got any links for more info/detail etc? Cheers! Jan

1 is easier. 2 is possible (or with CUDA if you prefer) but requires a little more thought, and can have limitations with more complex techniques (i.e. ragdolls, IK etc).

Quote:Original post by RobTheBloke
1 is easier. 2 is possible (or with CUDA if you prefer) but requires a little more thought, and can have limitations with more complex techniques (i.e. ragdolls, IK etc).

unless you don´t want to, could you be a bit more specific in these limitations?

Quote:Original post by FeverGames
unless you don´t want to, could you be a bit more specific in these limitations?

For a relatively small set of animations, the cost of lerping the anims (and blending multiple clips together) is relatively small - i.e. for a typical single anim on a 50 bone character, you're talking about 50*(quat slerp + vec3 lerp + posQuat to matrix) - which is not a lot at all. There is also the problem of data size - Animation data can become a huge drain on available memory, and as such data compression and the removal of redundant anim data soon becomes pretty important. This is not that easy to do on the GPU, so typically you'll end up using the CPU to do it.

Then ask if it's really worth extracting the keyframe data, and then sending it to the GPU to compute. The initial answer may be yes, but if you then need to use the resulting matrix data for say...

a) game logic
b) AI
c) Ragdolls
d) IK

... You'll need to read the data back to make use of it in the engine code. You might as well have done the computation on the CPU and send the final matrices to the GPU instead.

That's not to say computing posQuat slerps on the GPU is a bad idea, you may be CPU bound, or you may have a huge amount of this data to compute (i.e. extremely dense motion graphs, or thousands of characters). GPU's are after all very good at processing large data sets.

Anyhow, make your choice wisely based on the needs of the game, because the two methods require radically different data sets and architectures. Changing the technique at a later date will be extremely difficult to do (read: will require a complete re-write).