rig asset type

• rig.json — the readable skeleton document, the asset's primary. Consumers reference the .rig asset's guid, never this inner file. It holds:
  • bones — ordered bones, each with a name, a parent index (-1 for a root), the node index it maps to, its rest local transform (translation / rotation / scale relative to the parent — the bone's offset and length), and its inverseBind matrix (16 floats). The rest is the hand-editable driver for posing and shape-preserving retargeting; the inverseBind is what skinning reads.
  • profile — the retarget holder: base plus a roles map from each canonical humanoid role to the bone name that fills it. Present when the skeleton is a humanoid; this is the map that drives retargeting and the thing you edit to fix a mis-mapped bone.
  • humanoid — the structural classification (isHumanoid, hasHips, hasHead, armChains, legChains, mappedRoles) that gates whether the rig joins the shared humanoid-animation pool.

The format is JSON, not binary, because a rig is small structural metadata an agent inspects and hand-corrects — the bulk binary .mesh/.animation carry their own decode paths, but a rig is meant to be read.

A skinned .mesh references a .rig (the mesh keeps only per-vertex skin weights; the skeleton lives here). An .animation references its source .rig. Retargeting maps a clip from one rig onto another, routing each bone through its canonical role in the shared BASE rig (rigs/base_humanoid.rig).