Animations

Every animation in the FBX file becomes an animation in the glTF file. The method used is one of "baking": we step through the interval of time spanned by the animation, keyframe by keyframe, calculate the local transform of each node, and whenever we find any node that's rotated, translated or scaled, we record that fact in the output.

Beyond skeleton-based animation, Blend Shapes are also supported; they are read from the FBX file on a per-mesh basis, and clips can use them by varying the weights associated with each one.

The baking method has the benefit of being simple and precise. It has the drawback of creating potentially very large files. The more complex the animation rig, the less avoidable this data explosion is.

There are three future enhancements we hope to see for animations:

• Version 2.0 of glTF brought us support for expressing quadratic animation curves, where previously we had only had linear. Not coincidentally, quadratic splines are one of the key ways animations are expressed inside the FBX. When we find such a curve, it would be more efficient to output it without baking it into a long sequence of linear approximations.

• We do not yet ever generate sparse accessors, but many animations (especially morph targets) would benefit from this storage optimisation.

• Perhaps most useful in practice is the idea of compressing animation curves the same way we use Draco to compress meshes (see below). Like geometry, animations are highly redundant — each new value is highly predictable from preceding values. If Draco extends its support for animations (it's on their roadmap), or if someone else develops a glTF extension for animation compression, we will likely add support in this tool.