Physics-Based Character Control

Every character you have animated so far has been a puppet: you (or a mocap actor) dictate exactly where each joint goes, frame by frame, and the renderer simply plays those numbers back. The character passes straight through a wall if you keyframe it there; it never notices a shove; it cannot trip. That is kinematic animation — pose is prescribed, physics is ignored.

This page is about the opposite bargain. We take a ragdoll — a set of rigid bones joined by hinges — drop it in a rigid-body simulator, and then, instead of setting its pose, we let it push on itself. At each joint the character applies a torque, exactly as your muscles pull on your bones, and the simulator works out the resulting motion. Get the torques right and the ragdoll stops being a rag: it stands, balances, walks, runs, and staggers when you kick it — reacting physically to pushes and terrain no keyframe ever anticipated. Get them wrong and it collapses in a heap. The whole subject is the art of choosing those torques.

Kinematic playback vs actuated control

Kinematic (keyframe / mocap) playback — the pose \theta(t) for every joint is prescribed directly. The body follows it perfectly, weightlessly, and without regard to forces. Cheap, reliable, and totally passive: it cannot fall, but it cannot react either.
Physics-based (actuated) control — the pose is an output of a simulation. We supply joint torques \tau(t); the simulator integrates \ddot\theta = M^{-1}(\tau - \text{gravity, contacts, Coriolis}) to get the motion. The body has mass, obeys gravity and contact, reacts to perturbations — and can fall over if the torques don't keep it balanced.

The trade is control effort for physical truth. A kinematic clip is done the moment you have the poses; an actuated character needs a controller — a policy that decides, moment to moment, what torque each joint should apply so that the whole assembly does something useful instead of folding up. Building that controller is the rest of this page.

The actuator: a PD controller at every joint

We rarely command a torque directly — a raw torque tells a joint how hard to push, but what an animator actually wants to say is where the joint should be. The workhorse that turns a target angle into a torque is the proportional–derivative (PD) controller. Give a joint a desired angle \theta_{\text{target}} and it computes, every simulation step,

\tau \;=\; k_p\,(\theta_{\text{target}} - \theta)\;-\;k_d\,\dot\theta.

The proportional term k_p(\theta_{\text{target}} - \theta) pushes toward the target in proportion to how far off it is — a spring. Large k_p = a stiff joint that tracks its target tightly and resists being pushed off it.
The derivative term -k_d\,\dot\theta opposes the joint's angular velocity — a damper. It bleeds off energy so the joint settles instead of overshooting and oscillating.

This is exactly a damped spring pulling the joint toward \theta_{\text{target}}, and it is a good caricature of a muscle: a set point it wants to reach (stiffness) plus a resistance to fast motion (damping). Give every joint a PD controller and a full target pose — one desired angle per joint — and the whole body springs toward that pose while remaining a live physical object: shove it and the springs fight back, then restore the pose. Feed the controllers a sequence of target poses over time and the character animates itself, under physics.

Balance: keep the centre of mass over the foot

A PD controller can drive a joint to any angle, but that says nothing about whether the whole character stays upright. Standing is a global condition, and its simplest statement is a piece of statics: the centre of mass (COM) must project down inside the support polygon — the area under and between the feet in contact with the ground. Let the COM drift past the edge of the support and gravity's torque about that edge tips the character over. A single foot gives a small support patch; two feet planted apart give a wide, stable one; a raised foot mid-stride gives almost nothing.

Walking is what happens when you deliberately break this condition and catch it. The classic model is the inverted pendulum: the stance leg is a rigid strut, the COM an inverted bob pivoting over the planted foot. You let the COM topple forward off the support, and just before you fall you swing the other leg out and plant it where it will catch you — the new support foot. Walking is controlled falling, and the single most important decision is foot placement: where you put the swing foot down sets whether you recover, stop, or pitch onto your face. Push a well-tuned walker and it steps into the shove — placing the foot further out to widen the base and arrest the fall — exactly as you do on a lurching train.

Classic controllers: SIMBICON and trajectory tracking

How do you schedule the target poses and the balance corrections? Two influential answers:

SIMBICON (Yin, Loken & van de Panne, 2007) — a finite-state machine of target poses. Walking is broken into a few states (left stance, right stance, …); each state holds a target pose that the PD controllers track, and the machine advances on foot contact or a timer. The crucial ingredient is balance feedback: the swing hip's target is nudged by the COM's horizontal position and velocity relative to the stance foot, so the foot lands further out when the character is falling faster. That one feedback law makes a simple FSM walk robustly and shrug off pushes.
Trajectory tracking — take a reference mocap clip and follow it with physics. The clip supplies a time-varying target pose \theta_{\text{target}}(t); PD controllers apply torques to track it, while extra balance corrections adjust the targets so the simulated character doesn't drift off and fall. You get motion that looks like the mocap but is genuinely simulated — so it collides, reacts and recovers.

Both share the same skeleton: PD controllers as the muscles, a schedule of target poses as the intent, and a balance-feedback law as the thing that keeps the whole edifice from toppling. They are painstaking to tune by hand — which is exactly the itch the learning-based methods scratch.

The modern frontier: deep-RL imitation controllers

Hand-crafting FSMs and feedback laws for every motion is slow and brittle. The modern approach learns the controller. In DeepMimic (Peng, Abbeel, Levine & van de Panne, 2018), a neural network is a policy \pi: it reads the character's state (joint angles, velocities, phase) and outputs the PD targets for the next step. It is trained by reinforcement learning to imitate a reference mocap clip while the physics simulation runs underneath — the reward is high when the simulated pose matches the clip and the character stays alive.

Because the policy is trained across countless perturbed rollouts, it learns to recover from states no clip ever showed: shoved mid-stride, it takes a stagger step and carries on; on rough terrain it adjusts foot placement on the fly; asked to change direction it blends. This robust, interactive, perturbation-resistant control — a learned torque policy wrapped around the same PD actuators — is the bridge to the learning-frontier module, where policies are trained not just to copy one clip but to draw motion from generative motion models.

Worked example: one joint tracking a target angle

Strip the character down to a single hinge joint — think of a knee — with moment of inertia I = 1, currently at angle \theta with angular velocity \dot\theta. We want it at \theta_{\text{target}} = 1 radian. The PD controller commands

\tau \;=\; k_p\,(1 - \theta)\;-\;k_d\,\dot\theta,\qquad I\,\ddot\theta = \tau,

which is a damped-spring equation \ddot\theta + k_d\,\dot\theta + k_p\,\theta = k_p. The plot below integrates it from rest at \theta = 0. Fix the stiffness at k_p = 40 and drag the damping k_d:

With too little damping (small k_d) the joint shoots past the target and rings — it oscillates around 1 before settling; a whole character built this way visibly buzzes. Turn k_d up to about 2\sqrt{k_p\,I}\approx 12.6 and you reach critical damping: the fastest approach with no overshoot — the joint slides cleanly onto its target. Push k_d higher still and it becomes over-damped, creeping to the target sluggishly. Stiffness k_p sets how tightly the joint tracks (and how hard it resists a push); damping k_d sets whether it gets there gracefully or rings like a bell.

A muscle, roughly, has a set length it is trying to hold (via the stretch reflex) and it resists being pulled away from that length faster when you yank harder — a stiffness and a damping. A PD joint has exactly those two: k_p is the muscle's stiffness about its set point \theta_{\text{target}}, and k_d is its velocity resistance. Biomechanists even model muscles as tunable springs and dampers, and biological motor control adjusts co-contraction (stiffening a joint by tensing opposing muscles) precisely the way an animator dials up k_p to make a limb hold firm. The PD controller isn't just a convenient hack — it is a genuinely muscle-like actuator, which is part of why physics-based characters can move so believably.

Three failure modes lie in wait when you set k_p and k_d:

Too-high k_p with too-low k_d — the joint is stiff but undamped, so it overshoots and oscillates. A whole character like this vibrates and buzzes — an unstable, jittery mess that can even explode the simulation when the ringing pumps energy in faster than damping removes it.

Too-low k_p — the joint is floppy. The spring is too weak to hold a pose against gravity, so the character sags, its limbs droop, and it can't support its own weight. Turn stiffness up until it can hold, then set damping near critical (k_d \approx 2\sqrt{k_p\,I}) so it settles without ringing — the stiffness/damping ratio is what you're really tuning.

And the mode that has no kinematic analogue at all: a physics controller can fall over. Perfectly tracking every joint's target pose does not guarantee balance — if the COM leaves the support polygon the character topples no matter how crisp the PD tracking is. That is why balance feedback is not optional: without a law that moves the targets to keep the COM over the feet, the best-tuned PD gains in the world will still land your character on its face.