Absolute and Relative key frames

Started by
5 comments, last by Tispe 12 years ago
Hello

During animation of skinned meshes a hierarchy of bones are calculated from a set of Key Frames in an animation track.

The default character pose is a static set of bones in addition to the animation tracks.


I have read some code that uses the default pose as a "base" and then calculate animations relative to the default pose, instead of interpolating between two "animation poses".

Have anyone ever seen this done before? Is it common? What are the cons/pros between Absolute and Relative Key frames?
Advertisement

Hello

During animation of skinned meshes a hierarchy of bones are calculated from a set of Key Frames in an animation track.

The default character pose is a static set of bones in addition to the animation tracks.


I have read some code that uses the default pose as a "base" and then calculate animations relative to the default pose, instead of interpolating between two "animation poses".

Have anyone ever seen this done before? Is it common? What are the cons/pros between Absolute and Relative Key frames?

When you have a mesh, you need to adjust the bones to fit into the mesh, i.e. a character is often using the T-pose. This pose is your default pose (=rest pose/bind pose) in which you bind your vertices to the bones and your animation use this default pose as base for further animation frames.
You don't really need it for just animating the bones, but you need it to move the skin accordingly.
I don't quite get it. Is the T-pose the same as just the offset bones in a hierarchy?
When I interpolate between two key frames I end up with a matrix. This Matrix is supposed to be the interpolated bone to be used in the hierarchy. But instead this interpolated bone is multiplied on top of the corresponding T-pose bone. As to perturb the T-pose, relative to it.

Lets say in T-pose the elbow is rotated at +10 degrees.
It sounds to me illogical to say "given T-pose and time=0 rotate elbow +20 degrees resulting in 30 degrees", and then one second later say "given T-pose and time=1 rotate elbow 24.3 degrees resulting in 34.3 degrees".

Why not explicitly say that at elbow is 34.3 degrees at time=1?
You can store absolute transforms too. The formats I've seen usually store transforms relative to the parent though.

In the end, right before you send data to the GPU, all the data is absolute. For a joint J, the data is
(bind pose -> J joint local) * (J joint local -> world of frame f) when dealing with row vectors.

So in the end, you have to convert relative transforms to absolute transforms.

http://graphics.ucsd..._w05/3-Skin.htm is a great article.
Right, it is just an extra matrix calculation to go from T-pose to animated pose. So whats the point of doing it that way?
Ok, in case anyone is interested I think i have figured out why some games use key frames relative to the Bind Pose.

You don't have to animate all bones if you do it relative the T-pose. A single animation may only animate one arm, while another animation may animate the other arm. This means with animation blending the two will not conflict with eachother. Also memory space is saved as you don't have to save bones with are not animated by a given track :)

This topic is closed to new replies.

Advertisement