Presentation on theme: "How To Walk A Complex Tutorial on a Seemingly Simple Subject."— Presentation transcript:
How To Walk A Complex Tutorial on a Seemingly Simple Subject
Who Am I? Tom Forsyth I work at RAD in Seattle I work on Granny email@example.com
How To Walk Players spend most time walking around –They’re looking at their 3 rd -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 nameResulting weight Walk slow= walk* slow_walk* steady Walk med= walk* med_walk* steady Walk fast= walk* fast_walk* steady Walk med accel= walk* accel Walk med decel= walk* decel Run slow= run* slow_run* steady* no_turn Run med= run* med_run* steady* no_turn Run fast= run* fast_run* steady* no_turn Run med accel= run* accel* no_turn Run med decel= run* decel* no_turn Run med left= run* left_turn Run 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
Thankyou firstname.lastname@example.org Tom Forsyth RAD Game Tools