asymmetry with meshopt_encodeFilterQuat and meshopt_decodeFilterQuat

[Ono-Sendai]

Hi Zeux, all,
I'm using meshopt_encodeFilterQuat and meshopt_decodeFilterQuat to encode and decode some quaternion data (for animations).

I have noticed meshopt_encodeFilterQuat takes as an argument an array of floats (the quaternions). However meshopt_decodeFilterQuat decodes to an int16 array.
However I want the quaternion data decoded as floats. Of course I can do the dequantisation myself, but it seems wasteful, since looking in the meshopt_decodeFilterQuat code, it already decodes to floats (to compute the implicit x, y, z or w value), and then quantises to int16. So If I dequantise in my code, there's a completely pointless quantisation and dequantisation done.

What's the reason then for returning int16 data from meshopt_decodeFilterQuat instead of floats? Maybe another API function should be added that returns floats?

Cheers,
Nick

[zeux]

This probably can use better documentation... The filters are primarily designed for glTF like storage, and are bridging the gap between quantized in-memory storage and optimal compression. The idea is that we'd like to minimize runtime memory impact, so the expected runtime storage is quantized - 4x16-bit snorm in quaternion case. However, for data like quaternions, the "raw" quantized representation is redundant - there's entropy in individual components that can't be recognized by compression well. So the filter is designed to, in-place, decompress into the quantized representation from a representation that is less redundant.

Now, it would be possible to encode into this representation from the quantized representation too. However, that results in a little extra precision loss due to double-quantization, so the encode APIs instead take float data.

From runtime perspective, the expectation then is that the application keeps using int16 storage; animation code can divide each component by 32767 before using the resulting quaternion, which is usually "free" from the arithmetic cost perspective but much better memory-wise (both in terms of memory consumption and in terms of cache efficiency during animation evaluation).

This maps more or less directly to quantized SNORM storage of quaternion data in glTF format.

[Ono-Sendai]

Ok yeah I see, you are expecting that the user keep the quats as int16s and convert them to floats on-demand in the anim code.
I guess that would probably be faster due to lower cache pressure as you said. It is slightly less idiomatic though.

I had a concern about normalisation or lack thereof of the quaternions, but I see I'm doing nlerp (normalised lerp) between my quaternion keyframes so I guess they come out normalised anyway and that shouldn't be a problem.