Dimensions & Key Domains¶
This is the idea the whole tool is built on, and it takes one page.
A pose is stored at an address. A dimension is one component of that address.
How a layer's dimensions add up¶
A pose layer keys across three things:
its own grid + its carrying control + its knob
Each contributes its own axes, and they compose into a single address:
| The layer | Sum | Chip |
|---|---|---|
| A 3 × 3 grid, global, no knob | 2 | 2D |
| The same layer inside the Head control | 2 + 2 | 4D |
| …keyed across a 13-position phoneme knob | 2 + 2 + 1 | 5D |
| …if that knob were a 3 × 3 grid instead | 2 + 2 + 2 | 6D |
Six is the ceiling for a pose layer — its own grid (at most 2), its control (at most 2), and one knob (at most 2) — and four when the chain is fully global: with no control in play there is no carrying grid, and a global layer tops out at its own 2 plus a 2D knob. ORC enforces the budget everywhere an axis can be attached — the Knob picker hides over-budget candidates, a drag refuses with the reason, and Make Global refuses when the result would pass 4D. A layer takes exactly one knob, which is what caps the chain.
The Outliner shows the number on every row, and hovering it spells the sum out:
5D — total axes this layer keys across (own grid + carrying parent + each extra knob).
Two cases contribute nothing:
- A control's face — it is the control's grid, so it does not also key across it.
- A global layer — there is nothing above it. A global slider reads
1D.
Drivers and look-ats reach eight¶
A driver or a look-at field adds its own widget's dimensions on top of the same stack:
the widget itself (0–2) + the control (0–2) + the pose layer (0–2) + its knob (0–2)
A 2-D pad driver keyed across a control and a pose layer and that layer's 2-D knob is 8D. Nothing stops you; nothing warns you either.
| Widget | Its own dimensions |
|---|---|
| Checkbox | 0 |
| Slider, Combo Slider | 1 |
| 2-D pad (Continuous Grid) | 2 |
| The look-at joystick | 2 |
Key domains¶
A key domain is the set of positions something is keyed across.
Pose layers get theirs from where they sit in the tree — that is why dragging a layer changes its behaviour. Drivers and look-ats choose theirs explicitly, with the same four options and the same words:
| Domain | One value per… | Use it when |
|---|---|---|
| Global | Everything. It is not keyed at all. | The value never depends on the pose. |
| Control | Control snap | It changes with the turnaround — perspective, foreshortening. |
| Pose Layer | Pose-layer snap, the same at every control pose | It belongs to the expression, not the angle. |
| Control + Pose Layer | The product of both | It genuinely varies with both. |
Pose Layer is the only domain a global layer can use
A layer parented to Globals has no control dimension, so Control and Control + Pose Layer have nothing to key against. ORC greys those options out and says so.
Look-at's two modes each pick their own domain, from the same four — see Look-At.
When a domain is unavailable¶
ORC never hides an option it cannot offer. It greys it out and puts the way forward in the tooltip:
| Greyed | Because |
|---|---|
Control, Control + Pose Layer |
"Pick a control first — Globals has no control grid to key across." |
Pose Layer |
"No pose layer to key across for this owner." |
Control + Pose Layer |
"No pose layer under this control — a Globals layer is not under it, so it cannot form the product. Pick the control that owns the layer, or key across the layer alone." |
| Everything but Global, on a checkbox driver | "Checkbox drivers are Global only — pick another widget type to scope to a Control / Pose Layer." |
If a domain becomes unavailable temporarily — you have not picked the control yet — ORC remembers your choice and restores it the moment the dimension exists again, rather than silently downgrading you to Global.
Snap addresses¶
Every snap has a name, and it is built from the domains above, left to right: the control's position, then the layer's, then the knob's.
You will see these in the log, in preset previews, and in the Unroll table:
One segment per dimension, left to right — the control's snap, then the layer's:
| Address | Reads as |
|---|---|
R5C10 |
A control face at row 5, column 10 |
UR0C4:P1LR1C2:P1RR2C0 |
Control snap R0C4 · page 1's left grid at R1C2 · its right grid at R2C0 |
UR1C2:P2LR0C1 |
Control snap R1C2 · page 2's left grid |
UBR1C2:P1LR0C0 |
Control snap R1C2 on the back face · page 1's left grid at R0C0 |
G:P1LR1C2 |
A global layer — no control component at all |
UR1C2:K1R0C3 |
A knob's own pose — the owning control at R1C2, the knob at R0C3 |
UR0C4:P1LR1C2:W3 |
The page-1 pose, at position 3 of the layer's knob |
The prefixes:
U |
The carrying control's snap (its unit) — whatever that control is called. A Torso control keys with U too. UB is its back face. |
G |
No control at all — a global layer, keyed head-less. |
P1L / P1R, P2L… |
Page 1's left and right grids, page 2's, and so on — one numbered scheme for every page. |
K1 |
A knob authoring its own poses — K plus its axis slot, then its snap. |
:W3 |
Position 3 of the layer's knob. |
The control's name never appears in an address — each layer belongs to exactly one control, so U always means "my carrying control", with no numbering needed.
Why the letter is U and not C
U stands for the control unit — ORC's internal name for a control. The obvious letter would be C for control, but C is already taken: it is the column letter inside every snap. CR0C4 would put two different meanings of C five characters apart, and an address exists to be read at a glance — so the control keys with U.
Why a 2-D knob's :W is one flat number
A 2-D knob addresses its position as a single index — :W7 on a 3 × 3 knob means row 2, column 1 (row × columns + column) — instead of an R2C1 snap. That is deliberate: the composed rig stores each knob position as a stacked state file in Toon Boom's own layout (stack/0.tbState, 1.tbState, …), and the flat index is that file's name. The address stays aligned with the thing it points at.
You never have to type an address. But when a message, a preset preview or the Unroll table names one, this is how to read it.
Interpolation¶
Between the snaps, ORC blends. With Interpolation on, the pose is the weighted mix of the four surrounding snaps, the weights always summing to 1. Turn it off and the nearest snap simply wins.
It is a runtime toggle in the finished rig, so the animator chooses between a smooth control and a hard-stepped one. An unkeyed snap is not a hole — it is a position that blends from its neighbours.
It is also the only global one. Every other built-in toggle exists per thing it acts on, and only when that thing exists: Mirror needs a paired pose layer, Mirror All needs more than one pair, and Front ↔ Back needs a control with both faces — each two-faced control composing its own flip. Interpolation's question — blend between snaps, or step? — is asked once, about the whole rig; an interpolation checkbox per layer or per control would multiply widgets without adding a single decision. So one checkbox governs everything, and it stays home only on a rig with nothing continuous to blend — all on/off drivers, no grids.
What dimensions cost¶
Every axis multiplies the poses available, the time Compose takes, and the memory it uses.
| Rig | Addressable poses |
|---|---|
| A 3 × 3 layer, global | 9 |
| …inside a 5 × 3 control | 135 |
| …plus a 13-position knob | 1,755 |
| …plus a Front and Back face | 3,510 |
You are never required to key them all. But a dimension you add is authoring you are promising, and ORC will tell you so as the counts climb:
1024 snaps — authoring this by hand is a big job, and capture/compose time grows with every keyed snap.
It warns. It does not block.
The one thing that actually blocks Compose¶
Dimensionality itself never stops a compose. Exactly one structural conflict does:
Two extra knobs writing the same node and the same channel cannot sum. When that happens the offending Outliner row lights up red — name, chip and icons — and Compose refuses until you resolve it.
Everything else is a warning.