[madlag]

Thanks for the kind words! Yes, file size for live action or shipping directly in an app is always an issue. I may actually contribute some code, my file format is no rocket science, just a bare set of floats with some metas, not even some diff encoding between frames, so quite easy to interpret between languages and platforms.

[gernb]

For a body, with bones, since they can't stretch. All you need is rotation at each joint. You can get away with 10/11 bits per axis.

So for a full body you should be able to compress to 200 bytes per frame for 50 joints. That would mean 300k for 1 minute of animation at 30fps. Interpolate to get 60fps. That doesn't include faces.

If you do faces like Apple does, which IIUC is just N morph targets where N is like 15? Those are 1 weight each and you could easily make those 1 byte per weight or less so that's 27k for 1 minute of animation

Both of those could probably easily be compressed by storing deltas like draco or fit to curves for lots more compression.

[madlag]

Thanks! Yes, that’s the way to go. There is only a compromise between code simplicity/specialization and compression performance. And another point is the ability to use the format in memory without too much decoding or overhead when opening the file, random access for fast forward etc (when doing delta encoding) etc. (And I actually need strech too because my NPC interacts with objects, so the arm/hand bones should be at their exact place at replay, that’s 32 bones just for fingers.)

[jhurliman]

Take a look at the MCAP file format (https://mcap.dev), we invented it for the robotics industry but it’s a generic write-optimized container format for time series data. Since it’s a container format, you need to choose a serialization format as well such as flatbuffers or protobufs.

[madlag]

Thanks for the pointer, I will definitely have a look at this format, I was not aware of this.