9 ms·

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 si

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.

madlag 4y 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.
- jhurliman 4y ago
  Take a look at the MCAP file format (https://mcap.dev 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 4y ago
    Thanks for the pointer, I will definitely have a look at this format, I was not aware of this.
- gernb 4y 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.
  - madlag 4y ago
    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.)

madlag 4y 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.

jhurliman 4y ago
Take a look at the MCAP file format (https://mcap.dev 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 4y ago
  Thanks for the pointer, I will definitely have a look at this format, I was not aware of this.
gernb 4y 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.
- madlag 4y ago
  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.)