top | item 34420191

(no title)

diegomacario | 3 years ago

Wow that's super cool! That's definitely the biggest challenge - how to keep the size of the mocap data small.

Our library is not the best at that, since it simply records everything to Alembic files, which are quite heavy.

Best of luck with Explayn. I really like the idea of learning from mocapped lessons.

discuss

order

madlag|3 years ago

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|3 years ago

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.

jhurliman|3 years ago

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.