Adventures in Interpolation

Been working over the interpolation code some, and a few important insights are coming out.  This one could get bumpy. :)

The first one is an old one, and it's that movement interpolation should only be applied to MOVETYPE_STEP entities.  This is correctly reflected in the FitzQuake and DarkPlaces source code (and possibly a few other engines) and on it's own automatically resolves a lot of the weirdness and special cases that otherwise needed workarounds in the original interpolation tutorial code.  Some other odd behaviours still exist, which is where the rest of this stuff comes in.

So from here we need to start looking at the nature of movement interpolation itself.  This next one is actually hinted at in the Quake source code but made explicit by the Quake II code, and it's that movement interpolation should be synchronized with frame interpolation.

The reasoning behind this is that MOVETYPE_STEP entities move by - you guessed it - stepping.  So the movement needs to begin at the same time as the step animation begins, and likewise end at the same time as the step animation ends.  Quake II movement interpolation works that way, and in Quake the "don't mess up the step animation" comment on setting the U_NOLERP flag suggests that the same also applies here.

A third one is that - as should be obvious - step animations only occur in the horizontal planes, and so movement interpolation should also be done in only those planes.  This is more of a deduction on my part than being based on any solid evidence from either code-base, but the end-result bears it out.

That end result is that absolutely everything to do with movement interpolation now appears to be cleanly resolved.  Monsters step smoothly, non-monsters move smoothly, Scrags no longer fall jerkily from the sky, and Hell Knights in e4m6 now gracefully ascend on platforms (without even the little sink-in that standard movement interpolation gives).

With hindsight the whole interpolation drama was a victim of initial over-enthusiasm in the early days of Quake engine coding - a feeling that "interpolation is so awesome that it should be applied to everything!" - even things where it's either not appropriate or causes problems.

There's still a bit more to be worked out, but it's all just icing on the cake from here.  One in particular is to switch rotation interpolation from Euler angles to Quaternions (the rotation transform itself is already done using Quaternions so this is just a matter of moving the conversion to earlier in the process) and slerp them rather than using linear interpolation so as to get smoother rotation movement.

A nice result.