There seems to be very little information about draco’s animation compression but it is highly likely to require up-front decompression of the whole file before clips can be sampled. Texture packer style compression would also behave the same (most likely).
@reimund I’ll answer your question here.
ACL uses an error metric documented here: Animation Compression: Measuring Accuracy · Nicholas Frechette's Blog
The gist of it is that in order to evaluate the error as close as what you’ll see at runtime, ACL simulates rigid skinning around each bone. You can picture a sphere around each bone and the error is measured on the surface of that sphere. The radius of these spheres is called the ‘shell radius’ or ‘virtual vertex distance’. Each bone can have its own value. The core ACL library assumes that units are centimeters but the JS module abstracts this away and assumes meters are your unit of distance (it’s what glTF uses). This means if your model isn’t stored in meters, you’ll need to change the shell radius and the constant translation threshold to match your units (you’ll scale the existing values to convert them from meters into your units).
Typically 0.1 millimeter is a decent precision threshold and it’s good enough for cinematographic quality (e.g. AAA games). But you have to be careful what shell radius you set for each bone. Because ACL simulates the visual mesh deformation using a fixed distance (rigid shell), the better it approximates your visual mesh, the better the results will be. If the rigid shell is too conservative, you’ll retain more accuracy than you need and the memory footprint will end up higher as a result. If the rigid shell isn’t conservative enough, you will have a lower footprint but you might start to notice visual artifacts. A proper shell radius is important.
If you have access to the visual mesh, you can grab the furthest vertex skinned by each bone and use its distance. That should be optimal. For bones that do not have skinning information (e.g. root, IK, camera, etc) you’ll want to use a fairly high and conservative value. 1 meter is typically good enough. Note that this radius value is in local space of each bone.
If you do not have access to the visual mesh, you can hardcode a reasonable value like 3-10cm. You can see here how I tuned ACL for UE4: acl-ue4-plugin/error_measurements.md at develop · nfrechette/acl-ue4-plugin · GitHub The repo also contains the source code for the plugin which you can use as inspiration. The API isn’t quite the same as the ACL one but they will converge in ACL 2.0 to the one the JS module uses.
For bones that have attachments (e.g hands, prop sockets, etc), you’ll want to use a more conservative value as well. For example, say 3cm is a good estimate for the visual mesh around the hand. This might be fine when nothing is attached to it but if a large 2 meter sword is picked up, all of a sudden the visual mesh of the sword is rigidly skinned with the hand bone.
How close the camera can get to your animated models might also impact your choice of shell distance. The closer the camera can get (e.g. first person), the easier it is to spot compression artifacts from up close. If the camera can never get too close (e.g. tower defense style game), you could use less conservative values as any compression artifacts won’t be as easily visible.
As long as all your models have consistent units and sizes, picking decent defaults should be possible without too much trial and error.
Note that ACL takes the bone hierarchy into account when measuring the resulting error and as such it will handle any amount of complexity gracefully. It also supports any number of root bones and as such is suitable for compressing whole cinematics or simulations with multiple animated models into a single clip (if desired). I try to keep ACL as engine agnostic and flexible as possible. If there is something you need that it can’t do, let me know!