Skeletons and Joint Hierarchies

Reach up and wave. Notice what your shoulder just did: it swung your whole arm — upper arm, forearm, hand, every finger — as one connected unit, and then your elbow and wrist added their own smaller motions on top. Nothing detached and floated off on its own. A digital character moves the same way, and the reason is a hidden skeleton: a set of invisible bones called joints, wired into a parent-child tree so that moving a joint automatically carries everything below it.

This page is about that tree — how each joint is really a little coordinate frame, how a joint's motion is stored relative to its parent, and how the engine chains those relative transforms down from the root to place every bone in the world. It's the structure that forward kinematics walks and that skinning binds a mesh to. Everything a rigged character does starts here.

A skeleton is a tree of joints

A rig's skeleton is not just a list of bones — it is a tree. One joint is the root (often the hips or pelvis); every other joint has exactly one parent and any number of children. Follow the parent links upward from any joint and you always arrive back at the root; there are no loops. A typical humanoid chain runs hips → spine → chest → shoulder → upper-arm → forearm → hand → fingers, with the tree branching at the chest (two arms, a neck) and at the hips (two legs).

That last point is the whole trick, and it is why the structure is a hierarchy rather than a flat list. Because each bone lives in its parent's frame, rotating the shoulder does not need to know anything about the elbow, wrist or fingers — they come along for free, because they are defined on top of the shoulder's frame. Flatten the skeleton into an unrelated pile of bones and you would have to move every one of them by hand to keep the arm from falling apart.

Local vs world: two frames for every joint

Every joint carries two transforms, and keeping them straight is the heart of rigging.

The two are tied together by walking the tree. A joint's world transform is its parent's world transform followed by its own local transform:

M_{\text{world}}(\text{joint}) \;=\; M_{\text{world}}(\text{parent}) \,\cdot\, M_{\text{local}}(\text{joint}).

Apply that rule recursively and it unrolls into a product of local transforms running from the root all the way down the chain to the joint:

M_{\text{world}}(J_n) \;=\; M_{\text{local}}(J_0)\cdot M_{\text{local}}(J_1)\cdots M_{\text{local}}(J_n),

where J_0 is the root. The root itself has no parent, so its world transform is its local transform — the root is what carries the entire character through the world. Push the root forward two metres and the whole skeleton walks forward two metres, because every world transform below it is built on top of the root's.

Seeing the sub-tree follow

Below is a labelled joint chain: a root at the hips, up the spine to the chest, then out along one arm to the shoulder, elbow and wrist. The bones are drawn as connected segments and each joint is a dot. Press Play to swing the shoulder joint. Watch that you only animate one joint, yet the elbow and the wrist swing with it — they are the shoulder's sub-tree, so its rotation is baked into their world position through the chain rule above.

Nothing reached into the elbow or wrist to move them. That is the payoff of storing motion in local frames: a single shoulder rotation propagates down the tree automatically.

Worked example: where is the wrist?

Let's compose transforms by hand for a flattened 2-D arm so the numbers stay small. We track only position and a single rotation angle per joint; the rule is the same in 3-D with full matrices. Each joint's local transform is "rotate by \theta, then translate along the bone by its length L."

JointLocal rotationBone length
Shoulder (root of this chain)\theta_1 = 90^\circL_1 = 3
Elbow (child of shoulder)\theta_2 = -90^\circL_2 = 2
Wrist (child of elbow)\theta_3 = 0^\circL_3 = 1

Place the shoulder at the origin. Angles accumulate down the chain — that is the world transform being built as the product of locals.

Shoulder → elbow. The world angle is \theta_1 = 90^\circ (straight up). Stepping one bone length gives the elbow at (0,0) + 3\,(\cos 90^\circ, \sin 90^\circ) = (0, 3).

Elbow → wrist. The elbow's local rotation adds on, so the accumulated world angle is 90^\circ + (-90^\circ) = 0^\circ (now pointing right). Stepping L_2 = 2 gives the wrist at (0,3) + 2\,(\cos 0^\circ, \sin 0^\circ) = (2, 3).

(The wrist's own \theta_3 = 0^\circ and its bone L_3 = 1 would carry a hand tip on to (3, 3).) The wrist lands at (2, 3) — and notice we found it by composing the locals in order, root first. Change \theta_1 at the shoulder and both the elbow and the wrist move; change \theta_3 at the wrist and nothing above it budges. That asymmetry is the hierarchy at work.

The rest pose: the skeleton's home position

Before any animation plays, a rig is authored in a neutral rest pose (also called the reference, bind or T-pose): arms out, palms down, every joint at its default local transform. The rest pose does two jobs. It fixes each bone's default orientation — the direction the joint's frame points when it is "doing nothing" — and it is the pose in which the character's mesh is later bound to the skeleton for skinning. Animation is then expressed as offsets from the rest pose: "rotate the elbow 40° from its rest orientation," not "put the elbow at this absolute angle." Get the rest pose or a joint's rest orientation wrong and every pose built on top of it inherits the error.

Any joint could be the root — the tree only needs a single top node — but the root is the one joint whose transform moves the entire character through the world, so you want it at the body's centre of mass and centre of motion. For a walking biped that is the pelvis: it is where the character's overall translation and turning naturally live, and putting arms and legs as descendants of the spine above it keeps the branching symmetric. Root a character at the head instead and a simple nod would drag the whole body around, because everything below the head would be the head's sub-tree. The root is a design choice, and "hips" is the choice that makes locomotion and balance easy to animate.

Two classic mistakes bite here.

1. A joint's animation lives in its LOCAL frame. Keyframes store local transforms — the joint relative to its parent. If you grab a joint and shove a world-space value into it by mistake (say, copying a global position onto a channel that expects a local one), the joint jumps to the wrong place and, because every child is defined on top of it, the whole sub-tree jumps with it. The arm folds into the torso, the hand shoots across the room. Always ask: is this value local (relative to parent) or world (relative to scene)? They are almost never interchangeable.

2. Transform ORDER matters — parent before child. Matrix multiplication does not commute, so M_{\text{parent}}\cdot M_{\text{child}} is not M_{\text{child}}\cdot M_{\text{parent}}. You must compose down the chain from the root: apply the parent's transform first, then the child's on top. Flip the order — or evaluate a child before its parent's world transform is known — and the limb ends up rotated about the wrong pivot. When in doubt, walk the tree strictly root-first (a topological order) so every parent is finished before its children read it.