So I''m finally done with procrastinating, and I''m coding skeletal animation for my engine. I''m trying to decide how to represent bones in a skeleton. For reference, I want to allow animated rotations of each joint (of course), and I may want to allow animation of a bone''s translation, as well. I don''t think I''ll bother with scaling, at least not for the time being. The way I see it, there are three main options: 1. Represent a joint''s binding position as an arbitrary quaternion rotation, and an arbitrary scalar translation along a specific axis. Animations operate on a quaternion for rotation, and a scalar for translation. 2. Represent a joint''s binding position as the identity quaternion (zero rotation), and an arbitrary vector translation. Animations operate on a quaternion for rotation, and a vector for translation. 3. Represent a joint''s binding position as an arbitrary quaternion rotation, and an arbitrary vector translation. Animations operate on a quaternion for rotation, and a vector for translation. The way I see it, either one would would be suitable to express any skeleton. It''s simply a matter of how you draw your local coordinates for the binding position. Option 1 is a little more simplified than option 2, and feels a little more intuitive. Option 2 might be somewhat easier to write exporters for. Option 3 is the most flexible, but feels like overkill. Which one did y''all use? What pros/cons? "Sneftel is correct, if rather vulgar." --Flarelocke

Another option is to store the transformation matrix for each node instead of separate rotation/translation values. The advantage is that when traversing the skeleton to render you can just save the current modelview matrix and then multiply it by this node''s matrix to get a new modelview matrix. No need for conversion from quaternions and no separate rotate/translate. The disadvantage is slightly more data stored per node.

quote:Original post by ResearchMonkey
Another option is to store the transformation matrix for each node instead of separate rotation/translation values. The advantage is that when traversing the skeleton to render you can just save the current modelview matrix and then multiply it by this node's matrix to get a new modelview matrix. No need for conversion from quaternions and no separate rotate/translate. The disadvantage is slightly more data stored per node.

The generated transformations, including the inverted binding transformation, will be stored as matrices. But per-frame matrix generation is inevitable, since otherwise there would be no way to interpolate rotations or translations.


"Sneftel is correct, if rather vulgar." --Flarelocke

[edited by - sneftel on November 17, 2003 3:26:36 AM]

I''m not sure that I completely understood your post but yes, I think that for run-time interpolation, you''re probably better off with quaternions and vectors.

Store the skeleton purely as a list of matrices which represent the inverse of a bones base pose. That''s all you need.

For the animations, store them as quaternion/vector rotation/translation pairs. If there''s a translation in a skeleton it will very rarely be single-axis.

I use number 3, It''s been easy to visualize and very straightforward.

The other methods seem as though there would be more math involved, which could be a bad thing.

bump...anyone else?

[edited by - sneftel on November 17, 2003 11:46:02 AM]

I agree with the AP, matrix for reference pose, and quat/vector for keyframe data.

For most animations, translation is not needed per frame. A default translation, stored in the mesh, is fine.

When using Character Studio, it uses bones 0, and 1 to help ensure the feet remain on the ground. These may change per frame if using Character Studio, or something similar.

Only rarely will you have translations needed per frame, per bone.

Our animation system handles all of the three cases.
1. Default translation.
2. Keyframe translation of bones 0 and 1, with default translation elsewhere.
3. Keyframe translation on all bones.

Also, if your anim system can act on a subset of bones, that''s useful. This way you could play one animation of your run cycle, while playing another animation waving your arm, which affects only the arm bones. You end up with your character running and waving his arm. You can use this waving animation anywhere you want, without creating dozens of animations for each situation. Blending between the animations in essential (unless you really like popping).