Generating locomotion without keyframes: building a procedural walk cycle with Control Rig and Full Body IK in Unreal Engine 5.2.
This project is a technical animation demo built in Unreal Engine 5.2 using Control Rig and Full Body IK, developed following this Udemy course. It generates a walk cycle entirely at runtime through procedural math rather than playing pre-authored animation clips — a fundamentally different approach to character locomotion that adapts to terrain and movement conditions in ways that keyframed animation cannot.
You can watch the demo in action here: YouTube
Keyframed vs. Procedural Animation: The Core Distinction
Standard character animation in games works by playing back pre-authored clips — an animator recorded a walk cycle, and at runtime the engine blends and transitions between clips based on the character’s state. This approach is predictable, visually polished, and well-understood, but it has a fundamental limitation: the animation was authored for a flat surface at a specific speed. When the terrain changes — a slope, a step, uneven ground — the feet slide or float because the clip doesn’t know about the actual surface geometry.
Procedural animation flips this: instead of playing back a recording, the character’s pose is computed each frame based on the current state of the world. Foot positions are determined by raycasting against the actual terrain, leg positions are solved by IK from those foot placements, and the body position is derived from the legs. The result adapts automatically to any surface without requiring authored variants for every terrain type.
The tradeoff is complexity: procedural animation requires a mathematical model of the motion, careful tuning, and a solver that can compute valid poses in real time. Control Rig is Unreal’s system for building exactly that.
Control Rig: Runtime Rigging in Unreal
Control Rig is a node-based rigging system that runs inside Unreal’s animation pipeline, executing per-frame in the Animation Blueprint graph. Unlike traditional offline rigs (which live in DCC tools like Maya), a Control Rig executes at runtime — it has access to the current game state, can query the world, and can modify bone transforms before they reach the final pose.
The Control Rig graph operates on bone transforms directly: reading the current transform of a bone, applying mathematical operations to it (rotations, translations, constraints), and writing the result back. For a procedural walk cycle, this means the rig is computing foot positions, solving leg chains, adjusting pelvis height, and applying body sway — all as explicit mathematical operations in the graph, executed every frame.
Control Rig graphs are divided into forward solve (called every frame to compute the output pose) and backward solve / construction event (called when the rig is initialized). The forward solve is where the procedural walk cycle logic lives.
Full Body IK: Solving the Leg Chain
Inverse Kinematics (IK) is the mathematical technique that determines what bone rotations are needed to place an end effector (the foot) at a target position. Given a target foot position on the terrain surface, IK solves backwards through the leg chain — foot, shin, thigh — to find the joint angles that achieve that placement.
Full Body IK (FBIK) extends single-chain IK to the entire skeleton simultaneously. Rather than solving each limb independently, FBIK solves all limbs and the body together, respecting constraints between them — if both feet are planted on high ground, the pelvis must rise accordingly; if one foot steps into a depression, the body tilts to compensate. This produces a coherent whole-body response to terrain rather than limbs solving in isolation.
In Control Rig, FBIK is available as a solver node that takes a set of effectors (foot targets, possibly hand targets) and a set of constraints (bone limits, preferred angles) and produces a full-body pose. The effectors are the outputs of the foot placement system; the solver handles the rest.
Procedural Walk Cycle: The Step System
The core of the procedural walk cycle is the step system — logic that determines when each foot should lift and where it should land. The basic model works as follows:
Each foot has a current planted position and a target position. The target is computed by raycasting downward from the expected foot position based on the character’s current movement — where the foot should be if the character continues moving at the current velocity. When the distance between the planted position and the target exceeds a threshold (the step trigger distance), the foot initiates a step.
A step is a lerp (or a curve-driven interpolation) from the current planted position to the target, with a vertical arc added to simulate foot lift — the foot rises as it moves toward the target, peaks at mid-step, and descends to plant. The arc height is typically a sine curve applied to the interpolation parameter.
Left and right feet are phase-offset so they don’t step simultaneously — when one foot is mid-step, the other is planted. This produces the alternating gait of a walk cycle. The step speed is tied to the character’s movement speed so faster movement produces faster steps.
The elegance of this system is that the walk cycle never “plays” — it’s always responding. Turning, accelerating, stopping, or stepping onto uneven terrain all produce naturally adapted foot placements without any authored variants.
Body and Pelvis Response
With foot positions solved procedurally, the pelvis and body position must follow. The pelvis height is derived from the foot positions — it sits at a height that keeps both legs within their comfortable extension range, accounting for the terrain elevation under each foot. On flat ground this is stable; on slopes or steps the pelvis adjusts continuously.
Body sway — the lateral and forward lean that characterizes natural walking — is applied as a sinusoidal oscillation synchronized with the step cycle. As the left foot plants, the body shifts slightly left; as the right foot plants, it shifts right. This is a subtle but significant contributor to the animation reading as organic rather than mechanical.
Reflection
This project is the most technically demanding of the Blueprint series and the one most directly connected to production animation work. Procedural locomotion is used in AAA games precisely because it solves the terrain adaptation problem that keyframed animation cannot: a character that walks convincingly on any surface without a library of terrain-specific clips.
The Control Rig approach also has an important implication for animation pipelines: the rig lives in the engine, not in the DCC tool. Animators and technical animators can iterate on the rig behavior in the same environment where it runs — they see the actual runtime result, not a DCC approximation of it.
From a background in DreamWorks, the conceptual territory here — IK solvers, rig evaluation order, pose blending — is familiar from offline VFX pipelines. The key difference is the real-time constraint: the solver must complete in under a frame budget, which means FBIK iteration counts and solver complexity must be tuned for performance, not just accuracy. Control Rig exposes these constraints explicitly, making the performance tradeoffs visible and controllable.
Nicolás Bertoa 
Leave a comment