Hey, this gave me the occasion to reflect a bit about the question Vertex animation VS Skeletal animation. This is my very rough analysis of the pros/cons of the second one. First some quick calcs:
An animated model has let\'s say 20 bones, and most of them can rotate and translate in 3 directions, so for the starting bones positions we have:
20bones x ( 3coords + 3rotations) x 4bytes = 480 bytes.
Every bone must store a weight map, defining how much it affects every vertex in the model, and this is defined only once for every model. In the worst case, where we assume that we specify the weight even for vertices that are affected at a zero degree by that bone, we have:
20bones x 800vertices x 4bytes = 64K per model
The animation for a bone is stored both in its position and rotation, so we have:
20bones x ( 3 coords + 3 rotations) x 4bytes x 30frames = 14.4K per animated action.
For the Kran model example we would have:
initial vertex and normal data: 14.4K
starting bones positions: 480bytes
weightmaps: 64K
Bones animations for let\'s say 3 base standard actions (stand, walk, run): 3x14.4K=43.2K
This gives us around 122K for a model animated with 3 actions: extending this result over all the 24 races gives us around 3MB total data required for base animations.
If we think to add let\'s say \'stab\', \'drink\' and \'\'play banjo\' actions to the base ones, the total data would top around 4MB. This shows how a skeleton based animaton system is less affected by the addiction of action in respect to a vertex-based one.
Things that didn\'t enter in this rough evaluation:
- normal and vertex data per each frame must be calculated runtime by the engine, which is more work for CPU.
- eventual morph targets to add nice subtilities to the motion have not been taken into account. They may be replaced by a bone structure having more bones.
- Actions can be longer or shorter than 30 frames. A \'play banjo\' one could be only 10 frames long i.e., while a \'wear complete armor plate\' could be 100 frames long. But I suspect that the mean would be around 20-30 frames.
- In this case the bones animations have been keyframed, but they could be scripted too: a walk cycle could be driven by parametric expressions, resulting in less stored data, but higher CPU load.
- the same skeleton animation can be exchanged through different models, if certain conditions exist: interesting save of data.
- a clever method of mapping skeletons to meshes would allow us to create a new animation of the skeleton and apply it only once to all the required models, without having to animate each skeleton for each mesh with the new action.
- a skeleton would automatically provide attach points for weapons, so it wouldn\'t require us to add them to the mesh as we do now.
- a very good looking skeletal animation is more difficult to achieve, unless morphs or complex skeletons are not provided.
- a last-minute idea (I don\'t know how much realistic or feasible, but I caught if passing through my brain): skeletons would be better to have imposter-rendering of animated characters far away. Imagine rendering the segments of arms, legs, etc... and then having those mapped to simple quads bound to the skeleton. We could see 1 character at 2 Km distance, or, conversely, we could handle huge crowds of models with less CPU stress. Uhm...
Well, Venge, these were my thoughts about the question. I\'d like to continue it, because the time when we\'ll have to decide if switching or not to skeletons is coming closer, even if it\'s not yet 1 of our priorities.
I\'m quite late for dinner and I\'m rushing this a bit, so please report me everything that I wrote that could be wrong.
