Russ Dizdar

Procedural Animation and the Russ Dizdar Approach

Procedural animation in games and film is often misunderstood as some kind of plug-and-play solution. It isn't. I spent years working with these techniques on actual shipped titles, and the gap between what people expect and what they get is enormous. The method most people trace back to Russ Dizdar involves combining motion capture data with rule-based IK solving and runtime blending so characters don't slide around like wax figures on a cold floor. It works. It just requires more infrastructure than most studios are willing to build. You start with amocap session — a handful of performance-optimized clips that cover your character's primary movement vocab: idle, walk, run, jump, land. You strip the raw mocap of platforming artifacts and retarget it to your skeleton. This is where most teams fail because they skip the cleanup and expect the engine to compensate. It won't. The data has to be clean before it ever touches a blend tree. Next you define the procedural rules. For leg locomotion this means setting up an inverse kinematics solver that constrains foot placement to terrain normals. You tune the solver stiffness, root height, and step height parameters to match your character's proportions. A tall CG model needs differentIK targets than a compact stylized character, and getting this wrong results in foot sliding or legs that snap through geometry.

Then you layer the blend. Runtime blending between mocap and procedural isn't a simple lerp. You use weighted transitions that take input from the game state — velocity, direction change, surface type — and gradually shift authority from the clip to the solver. This usually takes 0.2 to 0.4 seconds depending on how responsive you need the character to feel. Fast reactions kill immersion because the body looks like it's lagging behind the input.

What People Miss

Here's the part nobody talks about at GDC panels: procedural animation breaks down in narrow spaces. I learned this the hard way on a mid-production platformer where characters were navigating corridors that were just wide enough for the animation system but not wide enough for the IK solver. The feet would try to place themselves on the wall because the collision mesh wasn't filtered properly. The fix was to add a raycast guard that disabled lateral IK when the clearance delta dropped below a threshold. Not glamorous. It saved the level from looking like every character was having a seizure. Another issue is weight variation. A procedural system treats every frame equally until you add damping based on the character's mass and momentum. If you don't implement this, your characters start and stop with the same mechanical precision whether they're a featherweight assassin or a heavy armored unit. The difference is almost invisible in a single frame but accumulates over a full playthrough until it just feels wrong.

Tools and Implementation

Most teams implement this inside Unreal Engine using Control Rig or inside Unity using the Animation Rigging package. Both have their tradeoffs. Control Rig gives you more runtime flexibility but requires you to build the solver chain yourself. Animation Rigging is faster to prototype but harder to customize once you hit its limits. There's also a third option if you're building something custom: writing your own IK solver in HLSL or GLSL. This gives you full control but costs several weeks of development time per character type. For mocap cleanup I used MotionBuilder for years. It's not pretty, it hasn't changed its UI in over a decade, but it still does this job better than anything else on the market. If your studio can't afford a MotionBuilder license, Mixamo's auto-retarget works for basic movement but falls apart the moment you introduce procedural layers because it doesn't give you the joint hierarchy control you need.

The Honest Assessment

Procedural animation is worth the investment if you're building a game with large open environments or physics-heavy interaction systems. It's not worth it if you're making a linear game with set-piece animations that play out on rails. In that case you're paying for complexity you'll never use. A good motion-capped sequence with proper blending between clips will look better than a poorly tuned procedural system 9 times out of 10. The sweet spot is somewhere in between. Use procedural for locomotion and environmental interaction where the game world is unpredictable. Use captured animation for story beats, combat sequences, and any moment where directorial intent matters more than player freedom. The systems that ship are the ones that acknowledge this split and build two separate pipelines around it rather than trying to force everything through one approach.