Course 3 · Rigging & Animation · Advanced

Controllers, IK chains, and pole targets

Ask for IK and the agent wires a chain that bends the knee backwards, snaps to the wrong pole, or quietly creates a dependency loop that makes the whole rig twitch — IK is a system of relationships, and the agent sets each relationship without seeing the others.

Read this module through your lens

Designers: IK is what makes a rig posable by feel. Test it like an animator — grab the controller and move it.

IK is a system, not a setting

So far bones moved one at a time (forward kinematics). Inverse kinematics flips that: you move a single controller — say, a foot handle — and the chain of bones above it solves automatically to follow. It is what makes a rig feel like a puppet you can pose by grabbing one point. But IK is not a single switch; it is a small system of relationships: a chain of a specific length, an IK target, a pole target that decides which way the knee or elbow points, and rotation limits that stop joints bending backwards.

The agent can add each piece, but it sets each relationship without perceiving how they interact. So you get individually reasonable parts that fail as a whole: a chain one bone too long, a pole target omitted so the knee flips randomly, limits missing so the leg hinges the wrong way, or — subtlest — a dependency cycle where bone A depends on B which depends on A, making the rig twitch or refuse to solve.

The advanced skill is to specify the relationships, then test the system as one thing.

The case study: a leg IK

prompt 1

”Set up IK on this leg so I can move the foot.”

failure

Moving the foot controller, the knee snaps inward, then backward — there is no pole target, so the solver picks a direction at random each frame. The chain also includes the toe bone, so the solve is one bone too long and the foot rolls oddly. At one extreme the rig twitches: a constraint cycle between the foot controller and the shin.

fix · prompt 2

”IK chain = 2 bones (thigh + shin), IK target = foot_ctrl, add a pole target in front of the knee so it points forward. Add a rotation limit so the knee cannot bend past straight. Ensure no constraint cycle. Report the constraint stack on each bone.”

output

The knee now tracks the pole cleanly, the leg straightens but never back-bends, and the twitch is gone once the cycle is broken. The reported stack confirms a clean two-bone solve.

Test the controller, read the graph

Two inspections matter here, and neither is a still image. First, grab the controller and move it through its extremes — foot forward, back, up, side to side. A correct IK limb tracks the handle smoothly, the knee always points where the pole says, and the joint refuses to bend past its limit. Flips, snaps, and twitches all surface in this sweep and nowhere else.

Second, when something breaks, read the constraint stack the agent reports for each bone. That stack is the graph of relationships; a dependency cycle, a missing pole, or an over-long chain is visible there as structure, where the symptom in the viewport was just “it twitches.” Diagnosing from the stack tells you which single relationship to change.

The lesson echoes skinning: the agent assembles the system, but only motion reveals whether the system is sound, and that motion test is yours to run.

Hands-on exercise

Take a rigged limb. Prompt “set up IK so I can move the [foot/hand]” and then sweep the controller through its range — record the first flip, back-bend, or twitch. Re-prompt with explicit chain length, an IK target, a pole target with a direction, and joint limits, asking for the per-bone constraint stack. Sweep again and confirm clean tracking. Capture the two extreme poses before and after, and name the one relationship that caused the original break.

The same lesson, a different object

prompt 1

Set up IK on this robot arm so I can move the gripper.

failure

With no pole target the elbow flips direction every frame. The chain includes the gripper bone, so the solve is one link too long. At full reach the rig twitches — a dependency cycle between the gripper controller and the forearm.

fix · prompt 2

IK chain = 2 bones, IK target = gripper_ctrl, pole target in front of the elbow, add an elbow rotation limit, and ensure no constraint cycle. Report the constraint stack on each bone.

output

The elbow tracks the pole, the arm never back-bends, the twitch is gone. Same system as the leg: each constraint individually plausible, only the whole tested by sweeping the controller.

The failure gallery

Each of these is caught by a quality gate — keep the cheatsheet open while you work.

Watch the journey

Screen-recording: the gripper controller swept to two extremes, before and after — flipping elbow vs clean tracking. video slot · supplementary to the written core
A control rig is a graph of constraints — chain length, pole target, limits — that only works as a whole. Specify each relationship explicitly and test the controller through its range; a constraint that is individually plausible can still break the system.

Cheatsheet

Prompt skeleton
Set up IK on [limb]: chain length [N] bones, IK target = [controller], pole target = [ctrl]. Constrain the pole so the [knee/elbow] points [direction]. Add rotation limits at [joints] to prevent back-bending. No dependency cycles. Report the constraint stack on each bone.
Failure modes
  • Joint bends the wrong way (no limits / wrong axis)
  • Pole target missing -> knee/elbow flips unpredictably
  • Chain length wrong (too many/few bones in the solve)
  • Dependency cycle -> rig twitches or won't solve
  • Controller doesn't actually drive the limb
Key operations
  • Define the IK chain length explicitly
  • Add an IK target controller + a pole target
  • Set rotation limits / preferred axis to stop back-bending
  • Check for and break dependency cycles
  • Test by moving the controller through its range
Quality gates
  • Does the limb track the controller cleanly?
  • Does the knee/elbow point where the pole says?
  • No back-bending past limits?
  • No twitch/cycle in the constraint graph?
Workflow steps
  • Specify chain length + IK target + pole
  • Add limits to vulnerable joints
  • Move the controller through extremes
  • Find the flip/cycle; fix the specific constraint
  • Log a controller sweep (extremes) before/after
Next module
  • rig_animation_boundary — the limit of what the agent can do.

Reflection card

Active retrieval — answer from memory before re-reading. Saved to this browser.

  • A working IK limb with an IK target and a pole target, posed at two extremes.
  • One systemic failure (flip, back-bend, or cycle) diagnosed and fixed.
  • A note on which constraint relationship caused it.

Next: rig_animation_boundary — the limit of what the agent can do.

Finish — back to Rigging & Animation →