Docs / Panel reference / Skeleton
Skeleton
Card 01 — create the canonical rig, adopt one of your own, or point the plugin at a rig already in the scene.
Chooses the rig the generated motion is keyed onto. The header pill reads
not created until a rig is ready, then ready.
| Control | Description |
|---|---|
| Existing skeleton + Refresh | Lists the skeleton roots in the scene, so you can target a rig that is already there. Refresh rescans. Nothing is auto-picked for you: if the previous selection is gone, the picker shows blank rather than silently choosing a rig you never chose. |
| Show canonical skeletons only | On by default — the list shows only rigs the plugin built. If the filtered list comes out empty, the plugin falls back to showing all roots rather than showing you nothing. |
| Namespace | The prefix on created joints (default animatica), which keeps several rigs in one scene apart. The same field appears in the Prompt Timeline header, and the two stay in lock-step. |
| Create new skeleton on generate | Build a fresh rig as part of the next generation instead of reusing the current one. |
| Create Skeleton | Builds the canonical soma77 rig — 77 joints, rooted at Hips — under the namespace shown. |
| Adopt | Makes the selected rig pipeline-ready: stores its current pose as the bind pose, plus hip height and namespace. |
| Delete | Removes the selected rig and the constraint markers the plugin attached to it, after a confirmation. It cannot be undone. |
#Reusing a rig under the same namespace
If a rig already exists under the namespace you typed, Create Skeleton reuses it — but only after checking its shape. A rig built for one model is rooted at Hips just like every other, so a name match alone is not enough evidence that the rig is the right one.
If joints the selected model needs are missing, the plugin refuses. It names how many are missing, gives a few examples, and tells you what to do: change the Namespace so a separate rig is built, or delete the existing rig.
#Adopting your own rig
Adopt is you asserting this pose is the rest pose, so it overwrites any stored bind pose unconditionally. It works two ways:
- from the picker, for a rig the plugin recognises; or
- from the viewport selection — select any node of the rig and the plugin climbs to the top node and adopts from there. This is the escape hatch for an imported rig whose joint names the detection does not recognise.
Adopt deliberately does not mark the rig canonical, so an adopted rig stays out of the Show canonical skeletons only list. That is by design: it keeps rigs you brought in distinct from rigs the plugin built.
Namespace-free rigs — the namespace prefix is derived from the root's name: the part before a
:, or before a_. A root with neither falls back to the namespace shown in this card.
#When your rig is not the model's rig
Your rig goes on the wire as it is, and the server decides whether a retarget is needed — the plugin does no retargeting of its own. Two outcomes are worth knowing about:
- If the server carries a retarget model, it retargets and generation proceeds.
- If it carries none and your rig does not match the model's canonical skeleton, the plugin refuses rather than producing something wrong: "this server does not support retargeting — use a rig that matches the model's canonical skeleton (Skeleton → Create), or a server with a retarget model". Press Create Skeleton and generate onto the canonical rig, or point the plugin at a server that has a retarget model.
The route through that decision is the Retarget route setting in Settings → Non-canonical rigs; leave it on Auto.