# Animation, Interpolation, & Structure

I have been working on animation in my small game engine recently and I am implementing some interpolation to be used with skeletal animations. I know how to do interpolation but I am not sure where to put the equation that I get out of it.

Do I save an equation for each channel of every bone in the data structure? Maybe something along the lines of:

struct Channel
{
std::string boneName;
std::vector<KeyFrame> keyframes;

// These equations will be used to find the position/rotation/scale of
// the bone at t time.
std::vector<float> rotEqX, rotEqY, rotEqZ;
std::vector<float> translateEqX, translateEqY, translateEqZ;
std::vector<float> scaleEqX, scaleEqY, scaleEqZ;
};


Do I just calculate the equation every time I want to update the animation? (Seems a little inefficient?)

• Start out by doing it, don't worry if it's inefficient. Computers don't get tired. Addendum -- when you're running on a mobile device, computers start to get tired... battery life. But just the same, start out getting it to work at all. Commented Oct 30, 2014 at 22:07
• one thing: euler angles (heading/pitch/roll) aren't really suited for interpolation, the best I've seen is quaternions Commented Oct 31, 2014 at 0:10
• Im using quaternions. Honestly just dont know what to call those three components. (Well 4) Commented Oct 31, 2014 at 0:23
• I thought it was just x, y, z, and w. Then again I never said I was using Euler angles. Commented Oct 31, 2014 at 0:34

I'm not sure what you mean 'these equations'. I think you mean the inputs into equations.

I would store rotations as quaternions (x,y,z,w) as mentioned. Interpolating from a key-A to key-B would use a slerp or nlerp function (http://keithmaggio.wordpress.com/2011/02/15/math-magician-lerp-slerp-and-nlerp/).

Translation is stored as x,y,z and uses a simple linear interpolation.

Scale is stored as x,y,z and also use a simple linear interpolation, although in hierarchical animation non-uniform scale is a complicated matter often requiring the squash/stretch rotation to know in what coordinate space the scale is to be applied.

Once you have that working, you can investigate various forms of compression and key frame reduction to reduce the cost. For example, keep track of which bones have identify scale (1,1,1) or no translation (0,0,0) and store flags to avoid performing calculations for those bones. This might be per skeleton, or per animation used on a skeleton. If a bone has a rotation that is consistent for the whole animation, just store it once. You can also store data quantized at a lower precision to get better compression.

Here's an article about different techniques:

http://www.digitalrune.com/Support/Blog/tabid/719/EntryId/131/Character-Animation-Compression.aspx