
Compressing Skeletal Animation Data - cpeterso
http://engineering.riotgames.com/news/compressing-skeletal-animation-data
======
MurkyWaters
Really cool! Animation compression is a fascinating, under-discussed, subject.

However, I'm surprised he didn't tackle two important techniques:

In most cases, a quaternion can easily fit in 15 bits if it expresses a
quantized delta from the previous key. Keep that 16th bit for "is compressed"
and you are good to go.

He also didn't mention that many joints (knees, elbows) are often only
rotating around a given axis, which allows for way deeper compression.

Honestly, I'd tackle these two low-hanging fruits before looking at curve
fitting, which is going to be a massive CPU hog at decompression time.

~~~
krautsourced
There should be virtually no overhead from decompression, since, if I
understand this correctly, there isn't any actual compression going on in the
sense of e.g. ZIP etc. It's just a matter of lossy data reduction, by e.g
decreasing a 32bit float to 15bit while keeping the original value as closely
as possible. Same with the curves, they are still regular uncompressed curves
with fewer keyframes than before, the "compression" is done by efficiently
placing these keyframes and letting the interpolation between them take care
of the rest. So I guess speaking of data reduction instead of compression
would be closer to the thing? In any case, I really liked the article.

~~~
MurkyWaters
Well, without going into too much detail, once you start curve-fitting, you
kinda have to do it on a per-bone basis, so your animation poses aren't going
to be sequentially placed in the data-stream. That means that your poses have
to be re-formed before they can be blended into the higher parts of the
animation system.

When all your keys are aligned, your keys are effectively poses themselves, so
blending them together can be done as you do the inter-animation blending,
which is a lot more efficient.

Again, it's totally worth it, especially if you have memory contraints, but
not what I'd have tackled, given what they described.

Edit: in the context of this article, compression and data-reduction are
interchangeable terms. Converting a quantized value into 4 floats isn't free
and constitutes the "decompression cost", same goes ith interpolation.

------
bhouston
Neat. I've written keyframe compression data before by removing keys that can
be reconstructed by linear/cubic interpolation of the remaining keys -- this
is an interactive process (key removing keys) that works fairly well. Although
I guess it doesn't shift around existing keys thus it won't be quite as
efficient as the curve fitting approach but it is a lot easier to implement.

