how to walk a complex tutorial on a seemingly simple subject
TRANSCRIPT
How To Walk
A Complex Tutorial on a
Seemingly Simple Subject
How To Walk
• Players spend most time walking around– They’re looking at their 3rd-person avatar
• Other time is mainly shooting at stuff– But they’re looking at the enemy
• Most visually important thing characters do:– Walking/running– Shooting at player
• Games already good at doing the second
Presenting…
• Granny is our favourite model– But she wears a long heavy dress– Not very good for showing a walk
• So we show her ancestor:
Granny: Warrior Queen Mother
Principles of a Good Anim System
• Anims do not drive character movement• Character movement:
– Player determines movement directions– Game logic decides speeds– Collision system prevents some movements– Physics does all sorts of modifications
• Anim system must respect above• Then move limbs to make it look good
Principles of a Good Anim System
• Animations determine default motions– Extracted from animations at start of day
• Used as references by game logic• Anim system given control for complex
motions:– Mantles, commando rolls, acrobatics– Hand-to-hand grappling
• Must be interruptible (e.g. being shot)
Principles of a Good Anim System
• Must try to cope with unnatural “gameisms”– Zero-windup jumps– WASD strafing and instant stand-to-run– Nose-scraping on walls
• AI-driven characters can be denied these– Restricted, but more natural movement– This can change gameplay
Walking Forwards
• Artist creates multiple walk cycles– Each has different stride length and duration– Here we use three – slow, medium, fast – Each anim is a single walk cycle– Each starts and ends in mid-stride, left foot down
• Calculate actual speed in m/sec for each– Start of day or offline– Allows artist to create at whatever speeds they like
• For target speed, find closest two anims
Walking Forwards
• For each anim, calculate frequency in cycles/sec required to achieve target speed
• Lerp frequency to find global cycles/sec
• Play both anims, weights lerp between them
• Apply same frequency to all animations– Manually keep them all in phase– Can’t blend correctly unless all anims in phase!
Walking Forwards
• Sounds needlessly complex
• But it copes correctly with animations that:– Have few cycles per second, but long strides– Have many cycles per second, and short strides
• And lerps smoothly between them
• Can cope with more than two anims– As we shall see…
Changing Speed
• Subtle change in walking style to change speed– Slight body lean– Heel/toe balance changes– Arm motions become exaggerated
• Even at low speeds• Effect is visually subtle
– Perceived subconsciously by most– Animators trained eyes can see it consciously
• Increases immersion– Reduces “robotism”
Changing Speed
• Add two more walk anims– One for speed up, one for slow down– Both are actually constant speed!– Both at speed & frequency of middle walk– Both are extreme versions
• Find out what desired acceleration is– Heuristics depending on game– Then damp fairly heavily: 1-2 seconds to full
Changing Speed
• Play all anims in lockstep phase, as above• Blend from the three walks towards the
respective accel/decel anim• Means that at full accel/decel, there is only
one anim for all speeds• Could author three versions of each
– But not usually worth effort & memory– Usually only have a small fraction blended in
Walking and Running
• Running is just different anim set
• Three speeds, plus accel and decel
• Run anims generally faster than walks– But considerable overlap in speeds– Slowest run is same speed as medium walk
• Exactly the same blending and lockstep
Walking and Running
• Transitions triggered by speed– Going slower than slowest run switches to walk– Going faster than fastest walk switches to run– Gives considerable hysteresis
• Transition starts as either (soonest) foot lifts• Transition ends as the same foot touches• Simple lerp in between
– Could be an animation instead
Turning
• When turning at speed, body leans– Legs, arms and hips also change slightly
• At low speeds, effect is much less– For walking, leaning is totally ignored– So slight, it’s not worth the art time
• Two more anims at medium run speed– Exaggerated extreme lean left and right– Anims actually go straight, not a curve!
Turning
• Calculate turning amount from game input– Heavily damp to prevent “body lurch”
– Same as with accel/decel leans
– Again, actual rotation is not damped
• Turning lean is multiplied by speed• Lerp from standard runs to leaning animations• Footstep prediction (see below) also uses turn
Blending Summary
• Sparse 4D blend space• Axes are:
– Linear speed– Turning speed– Accelerate / decelerate– Gait (walking or running)
• Most corners of blend space not filled in– Almost never used – not worth art time– Less important characters can have sparser blend space
Animation Blending Summary
Anim name Resulting weightWalk slow = walk * slow_walk * steadyWalk med = walk * med_walk * steadyWalk fast = walk * fast_walk * steadyWalk med accel = walk * accelWalk med decel = walk * decelRun slow = run * slow_run * steady * no_turnRun med = run * med_run * steady * no_turnRun fast = run * fast_run * steady * no_turnRun med accel = run * accel * no_turnRun med decel = run * decel * no_turnRun med left = run * left_turnRun med right = run * right_turn
Strafing
• Slightly unrealistic, but expected in games
• Game code does what it wants– Animation tries to do its best– But there’s always a limit
• In RPG like this, would probably turn body– But in shooters, this is very distracting– For demo we do strafing, because it’s hard!
Strafing
• Can have 8 walk cycles in each direction– No running sideways allowed!
– Extra art effort is considerable
– Doing short steps is tricky to do well
– But sustained sideways walking looks odd
– AIs can help by hinting what they are about to do
• Here we just let game logic move the body– Foot IK just copes
– Footstep prediction uses current strafe amount
Footfalls
• Measures times of foot contacts• Used for IK, turn prediction, gait changes• Artist creates animated flag for each foot
– Created as attribute in art package– Number from 0.0=up to 1.0=down– Fractions for slipping feet and weight balance
• At start of day, scan for transitions– Produces a single up and down time per cycle
Footfalls
• Utility functions to find:– Time to next up or down
– Time to last up or down
– Fraction through current up or down state
– All handle looping correctly
• Functions to blend multiple footfalls together– Each animation has two (one per foot)
– Blended with exactly the same weights as anims
– Allows code to query footfalls of blended anim result
Footsteps
• Footstep = position of foot plant• Each foot has a future and a past/current• Past/current is set the instant a foot touches
– Never moves after that– In real game, would move in some cases
• Sliding on slippery surfaces• Explosions, being shot, etc
– Used as target by IK system while foot is down
Footsteps
• Future footstep is continuously computed:– Find time to next foot down (footfall data)– Predict current motion forwards to that time– Sample animations at that time– Find (X,Z) where foot lands– Sample landscape height Y at that (X,Z)– IK “seeks” foot towards future footprint
Footsteps
• Strafes and turns are special
• Time to next mid-step used
• Not just time to next foot down
• Foot is still nailed down at time of contact
• So when you get to the mid-step, foot is:– Pointed in line with body (turn influence)– Underneath body centre of gravity (strafe)
Footsteps
• Foot IK seeks towards predicted footprint• Changes in speed/turn/strafe change predicted
(X,Z), can change predicted Y discontinuously– So damp predicted footstep height to prevent pops
• Predicted footstep position can be tweaked– Stay away from ledges and curbs
– Avoid rocks, equipment, bodies
– Dancing!
Foot IK
• Uses footsteps as guide
• Footsteps only describe an instant of time– Instant when foot went down
• IK needs to be applied to feet at all times– Otherwise, sudden pop as IK turns on/off
• Three distinct phases– All use same logic with different inputs
Foot IK
• All three phases produce:• Desired pos & orn of footprint
– Next or previous actual footprint
• Reference pos & orn of footprint– Where foot will/did fall without IK– Forward and reverse sampling of anims used
• Desire factor– From 0.0 (no IK) to 1.0 (full IK)
Foot IK
• Foot is down– Reference is animation state at last foot plant– Desired is current(/last) footprint– Desire = 1.0
• Foot is in first half of swing– Reference is animation state at last foot plant– Desired is (current/)last footprint– Desire = 1.0 at foot up, to 0.0 at mid-swing
Foot IK
• Foot is in second half of swing– Reference is animation state at next foot plant– Desired is next predicted footprint– Desire = 0.0 at mid-swing, to 1.0 at foot plant
• Desire curves are simple, but acceptable– Could be spline-softened for better tangents– Could be artist-defined using animated curves– But hard to preview in art package!
Foot IK
• Now find delta from reference to desired• Scale by desire factor• Apply position delta to ankle
– Move knee joint as necessary– Standard 2-bone IK– Simple knee-pop control
• Orientation delta applied to metatarsals– (bones from ankle to ball of foot)
Hip Height
• Can make legs shorter by bending them
• Cannot make legs longer! (hyperextension)
• If stepping down, hips need to move too
• If stepping up, hips cannot move too soon
• Hip height not controlled directly
• Instead move “ground shadow” root bone
• Then feet will IK back up to correct place
Hip Height
• Always at least as low as lowest foot
• But causes “bumpiness” during foot swings
• So during foot swing, use virtual foot height– Lerp from last footprint to next footprint
• But also blend to other foot in mid-swing– No hard reason for this, just looks better!
The Skirt
• (and shoulder straps)
• Offline cloth sim in Maya
• No runtime cloth sim at all– Far too expensive!
• Recorded as vertex animation
• Encoded as spline curves for space– Keyframed vertex animation gets big!
The Skirt
• Cloth sim does not loop perfectly– Do “settle down” phase of ~10 cycles– Take next 2 cycles– Copy & offset by a cycle– Crossfade to make a perfect loop!
(a standard trick in audio processing)
The Skirt
• Only stored for six anims– Three speeds of walk and run– Not leans or accel/decel– Quality increase is tiny– Would double the memory & authoring effort
The Skirt
• But vertex anim blending doesn’t work!
• Bones slerp & preserve lengths
• Vertex animation can only lerp
• Mismatch where they (should) meet
• When the legs IK, what should the skirt do?– When blending, waistband doesn’t meet hips– Skirt penetrates legs with blending or IK
The Skirt
• So don’t store object-space vertex anims• Skin the skirt, as if it were a miniskirt
– But doesn’t influence actual animation shapes
• Vertices can now be transformed back into the default pose on each frame
• Removes effect of bones• Just effect of “being cloth” preserved• This is now stored as the vertex animation
The Skirt
• At runtime, replay vertex anims• Blend together in “default pose space”
– All vertex anims stored in the same pose– So lerps “make sense” here– They don’t penetrate body (usually)
• Then animate using standard skinning– IK “just works”– Vertex animation is simpler – less memory
The Skirt
• This trick can be used for most fine anims– Hair, cloth, muscles, facial expressions
• Large-scale movements encoded in bones
• Small movements encoded per-vertex– Lerps have minimal artefacts– Small motions, so simple curves = low memory
• Don’t need to be present in every anim
What’s Next
• Demo is still work-in-progress!• More emotions (aggressive, defensive)• Walk to stand and back again
– When is a single step just the start of a walk?
• Standing pose transitions– Transitions done while keeping one foot still– Foot chosen according to weight distribution
• Turning on the spot– Again, moving just one foot at a time
What’s Next
• Attacks– IK’d attacks to precisely strike target
(allows stabs, not just big dramatic slashes!)– Hits taken are tricky (blend with ragdoll?)
• Looking around– Multiple (9) head poses – lerp to required dirn– Bone-masked blend onto body animation
What’s Next
• Upper & lower body anims– Move + attack at same time
– Each upper-body anim has a mask per-bone
– Says how much that bone is required for anim
• Jumping– No-windup jumps are unrealistic
– But required for responsiveness
– Therefore, hard to get looking right
– AIs can be forced to do windups
What’s Next
• Noise to hide repetitive walk cycle– Player is looking at the walk 50% of the time
• Crossfade multiple versions of anim– If your artists have time
• Add position noise – makes them look old!• Add noise into phases of bone motions
– Only works for cyclical motions (not poses)
• May need IK fixups to nail hands/feet
Summary
• Walk cycle is very important– Hard to get perfect, unlike stationary poses
• Most benefit from sticking feet down– Control hip height to prevent hyperextension
• Good transitions get next most benefit– Accel/decel leans surprisingly important
• Then correct prediction of foot plants– Rough terrain, turning and strafing prediction
The Golden Rule
• At all times, game logic/player decides:– Position of player (centre of gravity)– Actual speed and turn rate
• Animation system must try to cope– Pick appropriate speed walk anim– Blend in leans (accel/decel/turn)– Foot sticking & prediction– AIs can look better by being constrained