4 ms·

Really cool! Animation compression is a fascinating, under-discussed, subject. However, I'm surprised he didn't tackle two important techniques: In most cases

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 11y ago
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 11y ago
  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.

krautsourced 11y ago

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 11y ago
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.