Yup, matrix interpolation pretty much never works the way you want it to. What you can try doing is converting to a quaternion representation and slerping. Search for those terms here or on Google for more information [smile]

AFAIK there is no way to generally interpole a single homogeneous transformation matrix directly, or else you get results as in the "BAD" picture: The rotational part needs a spherical interpolation, e.g. a slerp or a faking nlerp (i.e. a lerp inclusive a post-normalization), or else you don't get an arc as path. The translational part and the scaling part need a planar interpolation instead, e.g. a lerp. (Someone may please correct me if I'm wrong, and there _is_ a way of doing it in a single matrix.)

This would mean that you have to decompose your transformation at least into the rotational part and either a combined translational/scaling part or else separate translational and scaling part. Then each part has to be interpolated with an appropriate method, and the result have to be composed again.

IMHO, it would be senseful to decompose the samples of the transformation matrices once (e.g. when loading them), and furthur only use the parts for all interpolation steps.


Dave has an article in which he talks about rotation interpolation in section 4.5 for matrices, quaternions, and axis/angle representations.

I like to make things complicated ;) and so I want to point out that quaternion slerp may be the right or the wrong way to go. It depends on what you want to reach. Your interpolation is done for keyframe animation of skeletons. Therein are 2 possible purposes for interpolation:

(1) "intra-track interpolation" is done to yield in an intermediate value between 2 samples on the same track
(2) "inter-track interpolation" is done to yield in blending of animations

Now, slerp has a constant speed over the arc, since in fact the angle is interpolated. That guarantees a smooth motion. However, when a keyframe is crossed, a sudden change is introduced into the motion. This is a fact as long as any linear interpolation is used (slerp, nlerp) since linear interpolations provide only continuity in location, not in speed (notice please that the constant speed of slerp is only on the arc segment, not when going to the next segment). Due to this you may decide that constant speed over the arc is questionable, and may go with the nlerp instead (which is easier to implement and faster in processing).

The nlerp doesn't show constant speed, but it has the advantage of being commutative (the slerp isn't commutative). For case (1) commutativity plays no role, since you can ever interpolate "naturally" from the sample with the lower timestamp to the one with the greater timestamp, even if you would play the animation backwards. However, for case (2) commutativity plays a role: The overall animation will look different if you blend animation A with B or else animation B with A. In other words, if the blending depends on the order, you impose your artist to think about that, and you need to implement a guarantee to get always the prescibed order. Hence, IMHO nlerp would be the better way for case (2).

It's worth noting that several high-quality animation systems I know of do use linear interpolation of matrices or quaternions. The key is to keep the keyframes very dense (every 3-4 frames or so) so that the interpolated transformation is never very far from the ideal. The results aren't quite as good as SLERPing, of course, but unless you were looking for it very carefully you'd never see the difference (at least with quats), and the performance is unbeatable.