Linear interpolation is the fastest of interpolations, but if accuracy is desired it requires much more storage space, both at run-time and on disk.

A compromise would be to start out with all 250 example key frames and eliminate redundant key frames.
This is fairly trivial to do.
Start with key frames 0 and 2 and linearly interpolate between them.
If the result is reasonably close to the value of key frame 1, eliminate key frame 1.
Repeat with key frame 1 and 3, checking to see if 2 can be eliminated.
When you reach a point where you can’t eliminate a key frame, repeat the whole process from that key frame.
For example if 2 cannot be eliminated, restart the process with key frames 2 and 4, checking for 3’s elimination.

You can adjust the accuracy tolerance to eliminate more key frames at the cost of playback accuracy, but you generally won’t be able to notice any inaccuracies at run-time unless they are huge.


L. Spiro

Keyframe interpolation can be done entirely on the GPU without needing to re-up any vertex data at runtime, and is even reasonably friendly for instancing - if you're drawing 10s or 100s of the same model then there's a good chance that many of them will share the same pair of keyframes (perhaps with the order flipped, in which case use 1 - blendweight). Per-model data can be as low as a single transformation matrix (or even just position xyz if it doesn't need to rotate), a blend weight and maybe some colour/lighting info. Set 3 vertex streams - one for keyframe 1, one for keyframe 2, one for shared data (like texcoords), then issue a draw call - done.

In that sense it's still a viable technology for many model types. Not everything needs the full animation possibilities of a character or opponent, and simpler models can be quite reasonably handled with keyframes. If you're happy to eat the extra memory requirement (which - depending on the simplicity of the model - may not actually be overly onerous and may be hugely outweighed by the perf benefits) then it may be a great choice for certain classes of scene decoration objects.

They probably wanted to keep the MD5 format simple.

I think most modeling programs allow you to use cubic bezier paths to define interpolation between keyframes. This makes it possible to have very small number of keyframes even for complex animations. But those keyframes/interpolations are usually defined for IK targets during animation and (at least for Blender) will be resampled to many keyframes with linear interpolation while converting animations to FK skeleton.

You can compact your animations to cubic or quadratic bezier interpolation, thus significantly reducing the number of keyframes but it requires a method to find local minima of arbitrary functions (some serious math). Or some optimization library (like LM).

So right now it sounds like just linear interpolations may be the way to go after all. I was looking at some code for cubic interpolation and it looks a bit heavy. Also if this worked for Doom 3 in the year 2004, it's probably fine and not something that will cause huge performance issues today.

It will be storage issue, not performance issue. High-quality animations take a lot of space and thus the compression of keyframes is important.

But this probably is no-issue for most indie games where people do not have a budget for massive amount of scripted animations anyways...