Animation export fails in a small set of recognisable ways, most of them settings rather than data.
What formats carry
- FBX carries skeletons, skin weights, animation curves, morph targets and multiple takes. It is the industry default for animation interchange.
- glTF/GLB carries skeletons, weights, animation and morph targets too, with a cleaner specification and better PBR support. Increasingly the better choice where supported.
- OBJ carries none of it. It is geometry only.
- Alembic carries baked vertex positions per frame — no skeleton, just the result. Enormous files, perfectly faithful, used for film and simulation handoff.
Baked versus curve-based
- Curve-based stores keyframes and interpolation. Compact, editable, and dependent on both ends interpreting the interpolation identically.
- Baked stores a value per frame. Larger, dumb, and reliable — what you export when a rig uses constraints, IK or expressions that the target cannot evaluate.
Bake anything driven by a rig feature the destination does not have. This is the single most common cause of "the animation looks different after export".
Frame rate
Must match between authoring and target, or timing drifts and keys land between frames. Set it at project start.
Multiple clips
Either separate files per clip sharing a skeleton, or one file with defined ranges. Separate files are usually easier to manage and avoid re-exporting everything to change one clip.
Root motion
Whether movement through the world is baked into the animation or driven by code. It has to be consistent across an entire animation set — mixing the two produces characters that slide or double-move.
Common failures
- Exploded mesh on import. Bind pose mismatch.
- No animation at all. The clip was not selected for export, or the range was wrong.
- Deformation differs from the DCC. Influence count exceeded the engine's cap.
- Missing morph targets. Off by default in the importer.