Importing rigged and animated models

Skeletons, skin weights and animation clips each have their own failure modes on import.

A rigged model carries three things: the mesh, the skeleton, and the binding between them. Animation is a fourth, often in separate files.

The skeleton

Bone names and hierarchy. These matter far more than they look: retargeting, animation sharing and IK setups all key on names. A skeleton with auto-generated names is a skeleton that cannot easily share animation with anything.

Adopt a naming convention early. Many teams use a widely-adopted humanoid layout precisely so third-party animation works without remapping.

Skin weights

Each vertex is influenced by up to a few bones, with weights summing to one. Engines cap the influences per vertex — commonly four — and an import that exceeds it silently drops the smallest influences, which shows up as odd deformation at joints.

Check the cap in your DCC tool before export rather than debugging it in engine.

Bind pose

The pose the skeleton was bound in. If the exported bind pose disagrees with what the engine expects, the mesh arrives distorted — the classic "exploded character". Almost always an export setting rather than a modelling error.

Animation

  • In the same file as the mesh, or in separate files sharing the skeleton. Separate is usually better: one mesh, many clips, no duplication.
  • Frame rate must match between authoring and engine, or timing drifts.
  • Root motion — whether the character's movement is baked into the animation or driven by code — is a decision that has to be consistent across a whole animation set.

For auto-rigged models

Auto-rigging produces a standard humanoid skeleton, which is the good case for retargeting. Expect to inspect weights at the extremities: automatic skinning is reliable on a torso and progressively less so at fingers, jaw and anywhere thin geometry overlaps.