Game Tech 2004 Featured Talk - How a Character Should Walk - Tom Forsyth of RAD Game Tools

it's not quite so important though you do spend a lot of time looking at people walking around

but in third-person games the thing that most people spend most of their time doing is looking

at your walk cycle so that's got to be a really good walk cycle it's just like it's got to be the

best because when they're not looking at your walk cycle they're actually playing the game

shooting at things picking up things um half the time they're looking at the the hud so you know

it's got to be nice and stuff but it's crazy the amount of time people spend just looking at the

the back of their character um walking along so be nice to do it well so yeah these two main

things running and walking and shooting at the player take up the vast majority um sorry yes

this is ai shooting at the player take up the vast majority of the time of what's going on on screen

um we're pretty good at doing people shooting at you it's kind of simple

um

it's an animation um rubbish at walking and running i've seen like two games that have

even half impressed me and the rest is just like i mean it's it's not that easy which is probably

why people just go ah whatever um but let's let's do it right so normally we use uh granny

is our favorite model um she's got this big long dress rubbish for showing a walk cycle

plus she sort of minces along like that

um so so we got a slightly different variation and uh

so this is uh the uh the unique imagination of steve theodore um thanks steve you should have

seen it when i was modeling he starts with no clothes on then puts it's not a pretty sight

anyway so this is granny uh warrior sort of queen mom or something and um so she's just doing her

walks i don't know if you can see her she's just doing her walks i don't know if you can see her

cycle

and uh you can speed her up and she can go jog like a fast run

so you can do all sorts of running around and stuff like that

so you get the idea it's a pretty simple demo or so you'd think so let's let's start with a

couple of principles i wanted to make this realistic so it's not uh it's as little like

a game demo as possible i mean obviously it is a demo but

it's got to be something like what you put in the game and the principles of a well-natured

animation system are that it doesn't take control character movement the the movement of like the

the center of gravity or the pelvis or you know whatever you sort of take as the middle of your

like collision bounding box or whatever is is determined by the player the game logic

the collision system which then prevents some of those movements

then the physics system which does like crazy stuff. And the thing that doesn't influence

it is the animation system. It's the animation system's job to take this highly responsive

player that's doing exactly what the player wants to do and make it look as good as possible.

It is not the animation system's job to make it sort of flow really beautifully but lose

control. Now it works for some games, Prince of Persia is probably the best known example.

But a lot of people really just hate the spongy feel. Oh and fighters as well are much more

indirect sort of style. So this doesn't mean that the animations have no control, they

determine a bunch of sort of default things. So the artist makes a walk that looks natural

for the character.

And then at the start of the day, when you load the walk cycle in, you go, oh, how fast does that move?

Okay, so let's make that the standard walk speed.

Now, in some cases, you might say, you know, look, you can't speed it up or slow it down too much.

It'll break the game.

You know, one character can run much faster than the other.

So those are constraints.

But they're constraints that, you know, the designer says to the artist, it's like code doesn't care about that.

It's like, and even if you did enforce that, there's a problem that, you know, if you say, well, that's a very nice animation you've coded, but it's too fast, so I'm just going to slow stuff down.

And then the animator's going, hey, you're not playing the walk cycle that I actually made.

You're doing some weird lerp stuff most of the time.

So that channel's going to be used anyway.

Complex motions, getting in and out of cars was the one I forgot.

Just, yeah, okay, let it do its stuff.

And that's just too tedious to do properly.

Sorry, in code.

We've got these weird unnatural gamisms that you need to respect.

Players expect it.

Zero wind-up jumps.

I hit the jump key.

I should be going that direction instantly.

None of this wind-up.

I don't care if, you know, you're in this weird pose here.

I want you to be moving there, that way.

So stand to runs.

It's like I have a D-pad.

I'm pushing it, or I'm not.

None of this speed-up rubbish.

And nose-scraping on walls is, we're all sort of kind of cool players.

We have instant sort of, we automatically straighten up because it looks good.

Novice players will just, like, run at an angle of 10 degrees to a wall

and just scrape their nose along it and go, wow, this looks really shit.

It's like, well, you're running into the wall.

What do you want?

I want it to look good.

You can cheat with AIs because you can just say, hey, no,

you're going to be in this weird pose.

You have to do the wind-up.

No instant jumping.

That's rubbish.

Looks awful.

Let's start with the basics, just walking forwards, constant speed.

So this demo allows me to change the speed of the walk.

Not applicable to every game, but it's kind of nice.

So we have multiple walk cycles, in this case three of them, slow, medium, and fast.

The medium is kind of the default speed, and then, you know, if you're walking uphill,

you might slow down.

I don't know, things like that.

Each of the actual animations is just a single walk cycle.

They all, in fact, they all are single walk cycles.

They all start and end with the left foot down, mid-stride.

So they're all starting and ending in this reference pose,

which means they all start synced.

You then, when you load them up,

you calculate their actual speed in meters per second for each of the animations

because, obviously, they're different speeds.

They're also different cadences.

So they have different...

They have different numbers of strides per second.

So they have these two different numbers,

which is actual obtained speed and number of steps per second.

And you can have animations that have a lot of steps per second,

but are the same speed as one that has a few steps,

like a big, long stride is about the same speed

as, like, a slow sort of jog type thing.

So, anyway, you find out the actual speed that this covers.

You then say, well, for each...

Separate animation, you say,

well, how fast do I need to play this animation to actually get, you know,

the player says they want to do 0.8 meters per second,

so for each of these slow, medium, and fast animations.

And, obviously, the slow animations,

we're going to need to speed them up quite a bit,

and that's going to look unnatural.

And the fast ones, we're going to have to slow them down for a medium one.

So we find the animations that are, obviously, closest and use those.

I just use the nearest two and do a lerp.

But you also lerp this frequency to find a global cycles per second.

You then make all the animations that you're playing

go at this number of cycles per second.

Because if the animations are not synced, you can't blend them.

It doesn't mean anything.

It doesn't mean anything to blend something with the left foot down

and something with the right foot down.

You get this sort of weirdly hovering thing.

So they must always stay in lockstep, in phase,

even though they're different lengths, which is why I do all this.

I'm just faffing around with frequencies.

So it does sound complex, but it does cope with animations

that have this sort of wide variation in the gate.

And it means that the animators can compose pretty much what looks good.

And you're not saying, no, no, no, this animation is 29 frames long.

It needs to be 28.

This isn't working.

Look, it's drifting out of phase.

Oh, and now all this sort of stuff.

And it copes with just as many animations

as you'd like, which is nice, rather than forcing two.

So this is the kind of medium walk.

And I can slow it down to, this is a completely different

animation, which is just a sort of slow little doddering walk.

You see the cadence doesn't change much.

It's mainly a change in the stride length.

And then as we, oh, sorry.

Oh, sorry.

Too smart.

And that's the sort of fast walk, which is really quite a long stride length.

I think it's slightly faster frequency.

But still, all the change in speed is done by the stride length.

And also, she does different things with the sword, how amazingly she holds it and stuff.

So I don't know if you noticed, but when I changed speeds, there was a lean,

forwards, and when you decelerate, there's a slight lean backwards.

There's a whole variety of effects that this has on the body.

You dig the heels in for a slow down, and you get up on your toes.

And this happens even at walks.

It is very subtle for walks, because there isn't a great deal of change of speed.

But it is actually there, and I find it very difficult to actually see the thing.

But if I turn it off, it looks wrong.

You get this sort of robotism thing.

It sort of magically speeds up, it looks very strange.

It is a subtle effect, but so you have two more walk animations.

One is a speed up one, one is a slow down one.

The important thing is they don't actually speed up or slow down.

Both these animations have exactly the same constant ground speed as the medium speed

walk.

They just have the motions.

So it's this sort of weird thing that looks like it should be speeding up, but isn't.

So it's not a big difference.

But it's not a big difference.

Debug keystrokes.

I hope these are all written down on a piece of paper.

Don't worry.

Lost it there.

There it is.

Okay.

Let's see, let me just show you.

I can't see it.

I can't see the key.

So I'm just gonna throw it down.

I'm going to turn it off.

I'm gonna close this one.

There it is.

I'm going to close it.

Okay.

I'm going to close this one.

And I'm going to close this one.

And now I have a button.

And I'm going to close this one.

So this is the slow walk, but it's been sped up because she needs to do that.

This is the medium walk, which is about correct speed.

And this is the fast walk, which has now been slowed down because she actually wants to travel slow.

And this is the speeding up walk, which is absolutely constant speed.

It's just this lean.

And as you can see, they're very exaggerated.

And she's doing the sort of balance thing.

So they're very exaggerated.

And in practice, you never blend all the way to them.

They're very slight little things.

But you do the exaggeration just because then you've got the blend space.

It's hard to extrapolate beyond the blend space.

You could if you wanted to fill in some more realistic ones.

But I've got the key now.

So this is fairly obvious.

You extract the acceleration.

You take the acceleration from some heuristic from the game.

You want to damp it fairly heavily otherwise the lerp kicks in very suddenly, and she sort of goes jerk.

So you want to damp that quite a lot.

The heuristics depend on what your control scheme is and all that sort of stuff.

So that's ...

So, again, we play these two animations in just lockstep phase.

And just blend towards them.

it does mean that if you're accelerating hard the three walk speeds that we had they all get

blended away from towards the acceleration one and there's only one of those and in theory you

should have a fast medium and slow one of those but it's just not worth the effort especially as

you almost never get towards the full one you're always somewhere in the blend space in between

them so the small fraction blended in it's it's like a hint or the the displacement map stuff

that was talked about last night it's it's it's more the difference between a normal walk and a

and a slowing down and speeding up so walking and running so if we accelerate a bit faster she just

breaks into a run and slow down quite a bit and she keeps up the run she keeps this gate but it's

a

it's just a jog now and um and there's a manual toggle and there's quite a lot of overlap between

run and walk so because changing gate is kind of unnatural and we don't don't tend to do it much

so you want to make sure that the runs and the walks overlap quite a bit uh this is the this

is to stop unnecessary transitions but also just because that's the natural thing once you're

running you tend to stay running it's just a different animation set

exactly the same five animations fast medium slow accelerate decelerate do exactly the same math

it's just all the speeds have changed slightly according to the animations so in fact as far as

this is concerned you could swap the two animation sets around it would just work so

the transitions are the only thing that care if you try and run uh yes if you're in a run

and you slow down slower than the slowest run you switch if you're doing a walk and you go faster in

the fastest walk it switches to a run the uh you don't have to do the specific transition it's a

fairly quick transition so you can just just blend at any time that looks fine i i think was mentioned

yesterday crossfades between two animations you're doing quick it's fine no one cares but the the

sort of physically correct thing is to not do it in the middle of a walk you wait until one foot

just lifts off the chain and you're ready to go so you just wait until you're on the left foot for the right foot

and then you do the next東西 and then you do another fast transition and then you do the next switch

the second one is the not the first one it's all about the speed you're doing a pertama

the fastest walk it switches to a run the you don't have to do the specific transition it's a fairly quick

the ground. That's when you started. You transitioned while the foot is in the air, and the transition

must have finished by the time that foot hits. So it's a simple matter of timing when the

foot comes off, when the foot goes down. This sounds complex, but actually this thing of

being able to extract foot, the times and durations of when foot feet leave the ground

when they hit, we're going to extract all that later anyway for the footstep IK, so

it's actually really simple code. Oh, and I just do a simple look. You could actually

have an animation that says this is a hand-authored transition, but it's a really fast transition,

so it's fine. So turning, the other effect is turning. Now, walk speeds are just, she

just turns. You could do a slight lean, manual sort of code lean in IK, but it's not too

bad.

When she runs, though, I actually have, speed her up a bit. There's a decent bit of body

lean. You kind of see the effect kicking in. And there's also two different animations

for left and right lean because she does slightly different things with her arms. I can accentuate

this, I think. Oh, I see. I'm going to turn it down. Hey.

There's quite a lot of lean. You can see she's really digging into that corner with

that inside arm and shoulder. And there you can see the arms sort of coming out like that.

So for walking I just ignore it. It's just not worth the animation effort. You typically

got like 30 of these things to do. Adding a couple more here and there. This is where

you get the most of your animation effort. You just don't want to do it. You want to

more animations is just tedious so these two animations are medium run speed

again they're extreme left and right leans again the animations actually go

straight they don't do it do it in a curve I think they were actually authored

so they go in a curve and then he just stopped the bone the root bone turning

and just did it straight so you calculate the turning amount from the

game input again in whatever heuristic you have you know if it's a d-pad then

it's kind of you just get this binary left right and you want to damp that a

lot and so on that's all kind of stuff you just need to play with according to

your control scheme just to emphasize when I say the rotation or the the

acceleration is damped I mean the effect on the animations the gameplay the

actual effect she instantly just turns right that's the game's problem how fast

she's moving which direction she's turning

I mean the effect on the animations the gameplay the actual effect she instantly just turns right that's the game's problem how fast she's moving which direction she's turning and

animation system doesn't control that that's just like this is what the game

does so it's purely the effects that the animation plays so in this case it's

just to stop you know she's running along and then you suddenly do a hard

turn and the body just sort of goes pop as very unphysical looks very strange

so the that's all the animations I have it's twelve animations in total

so the actual blend space is 4d so there's the linear speed blends in one

direction there's the turning speed acceleration and deceleration and the

gate which is simply walking or running and transitions between now in theory I

have three three stops at each of these I have a steady state I have an

acceleration I have a deceleration at a no turning turning left turn right

linear speed I have three walks and gates I have two so that's like

nine eighteen eighteen animations so I don't have an awful lot of these only

have twelve and wait that's 2054 something crazy like that on the fly math so most of the corners

of the blend space do not have an animation associated with them because most of the

time you don't get there you don't have like a fast acceleration with a hard left turn you know a

you never actually get to that blend space

and even 12, maybe you don't want that

for some of the simpler characters

you just go, oh you know what, I don't want the lean animations

I'll just IK something in, it'll be fine

so here are the 12 animations

this is basically how you calculate the blend weights

and these are the blend weights on the left

with the name of the animation, they always sum to 1

so I have walk and run, which walk is

1 minus run and so on

slow, medium and fast walks, which is derived from

what's my speed, what's the speed of the walks

ok, find the nearest 2

and the runs are exactly the same thing, only with run speeds

steady acceleration, deceleration

again, this column sums to 1, this column always sums to 1

no turn, left turn, right turn

multiple altogether, it's fine

you notice that only the runs have the turns

on the walks there are no turns

so I just ignore that

interpolation value

she just rotates

strafing's kind of an odd thing

gamers expect it

they don't want to, they want to adjust slightly right

to actually, you know, they're walking forwards, there's a doorway

they don't quite fit, they just want to sidestep right

they don't want to turn, do all this sort of stuff

so in an RPG like this where she's wielding a sword

the direction that she's facing in isn't too vital

so what you'd probably do is say

ok, he was walking forwards, and then he applied a bit of strafe

so the composite motion isn't that way, it's now that way

so all I'll do is I'll just turn the character

and walk them that way

so strafing leads to turning

which means that you can completely ignore strafing because

you don't have any, you just have a bunch of turns

in shooters, it's a very different situation

in shooters, the guy's got a little rifle there

over the shoulder or something

and the direction the weapon is facing in

that's it, that's the game

is which direction this weapon is facing in

you must not change this

now to be realistic

the shooter's pose is like that

and you can't really turn the body all that much

and still remain in a proper shooting pose

so people do actually strafe

they just walk around like this

it's kind of bizarre

so the easy thing is the actual RPG

the thing to just do a turn

that's too easy, so I did the strafing

so it looks kind of goofy with her waving a sword but

I'll just show you

so here we have Granny

and we strafe to the left

so yeah, it looks kind of strange with the sword

but it is

oh hey

and the animation system is again doing its best

she's instantaneously changing strafe positions

so you can make her do weird little dances like that

as the animation system tries to keep up

but that's because I'm being a pathological user

so for strafing you could have

actual ape animations

in each walk direction

lurk between the two

8 extra animations is kind of a lot

especially if it's not a particularly important part of the game or something

so here I don't do anything

there's no extra animation

I just move the body

and the foot IK, which I'm going to do

just copes, which is kind of nice

the only modification I needed to do

was the footstep prediction that says

hey, where should I be planting this foot?

on the ground

that looks at the strafe

and takes that into account

so there's this concept of footfalls

a footfall

slightly vague terminology

I call a footfall the time when the foot goes down

or comes up indeed

so when I talk about that it's always a time thing

this is similar to the constraint intervals

stuff that was talked about before

it is a binary thing

the foot is either down or not

it's either constrained or it's not

and it's just represented by two times

for each single walk cycle

an up time and a down time

and you have one of these per foot

the way it's actually authored

is you have an attribute per foot

in the art package

and it just goes from 0.0 to 1.0

you can use the fractional stuff for like

a foot slip

in a fast run

as the foot comes off

it can like skid across the ground a bit

so you can use that

there to just say

oh yeah, there is a bit of foot slippage here

and for static poses you can say

these would both be half

because I'm equally balanced

sort of lounging around on one foot

there's like a 0.1 on there

because I probably should keep it stationary

but if you want to move it

well, it's not a big deal

if I want to move this one

I really should shift my gait

and do that

so I just load these in

and at the start of the day

I just sample them

and find where they go

above and below like 0.95

and that produces two times

and then there's a bunch of utility functions

so I can say

hey, I'm currently here in the cycle

is my foot down or up

how long is it till there's the next

up or down transition

and what fraction of the way through

the current state am I

and this is all the stuff that

when I talked about

you want to do the walk to run transition

this now is trivial

it's just like

okay, hey look

a foot just went from down to being up

I can start my run transition

how long till it goes down

oh look, this just all comes out very easily

I can just

make sure that the scale offset works

for that transition

blending multiple footfalls

you could

these constrained intervals

you could do something fancy

I just blended the start and end time

and that seems to work fine

seeing as all the animations are synchronized anyway

that seems to work fine

probably if you're doing different animations

maybe you need to do something smarter

but different animations kind of don't

don't work very well together

so it's just a bunch of utility functions

but it's

it's something you don't think that you'll need

but incredibly useful once you go

alright, let's just write this code

hey look, I can now just feed it a signal

and I can ask things about signal

so the next concept is a footstep

again, sorry about the terminology

so a footfall is a time thing

a footstep is a position

and it's the position when the foot first hits the ground

if the foot then subsequently slips

I don't care, that's encoded in the animation or whatever

but it's when it first hits the ground

so when the footfall goes from 0 to 1

now each foot has two footsteps

they have a future one

which is always being continuously predicted

it's like when you're walking along

you're scanning along to see where you're gonna walk

and a past or current one

if the foot is down then it's obviously the current one

as soon as the foot comes up, it's the past one

so you always have two

the instant the foot touches down

the currently predicted one becomes the past one

you start predicting the next one

in this demo, as soon as the foot goes down

that's it

that is the past footprint

it can never move again

if you're sliding

or you got knocked off your feet by a physics thing

then obviously you don't want to glue that foot down forever

but, yeah

it's a simple demo

so, I'll show you the footprints

there we go, so

this is showing

all four footprints

the past or current

and the future for each foot

so you can see that her feet are

so these leading ones are the predicted ones

you can see that her feet are actually getting there

oh, yes, sorry

yes, this foot slip you're seeing is in the animation

I'm not entirely sure where you put it in there, but

I'll just change to the walk, which doesn't have one

yeah, the walk doesn't slip, the run starts slipping

and that's because you said that you were putting one number there

yeah, well, the curious thing is the slow run slips

and then the medium run doesn't

so that makes no sense to me, but I'm not an animator

so you can see as I start turning

these

the prediction footprints

turn with me

or turn ahead of me, in fact

and as I speed up

they'll get longer

and then as I slow down

they get closer together

it's kind of a subtle effect with the walks because

they're

it's the

no, it is the stride length, sorry, you can see that

stay with the walks

the slip is distracting

so

the way I

the future footstep is always continuously predicted

it's not like

I predict it once per cycle or something

so you find the time

until the next foot down

which is

which is the place where the footprints are

where the footsteps are nominally at

so you predict the current motion of the root bone forwards to that time

and you also sample the animations at that time

and then you know

so I may be here in the middle of the cycle

my foot in the air

but I look ahead

I say, when's the next footfall?

it goes, well, it's at this time

so I go, okay, the animation at that time

is in this state

I move my hips forward to that time

and then I go, right, that's where the footprint is

so I'm here and I can

forward predict

and then

I have this

what on earth is that?

oh, I know what the key does

don't do that

always keep your debug keys useful names

oh, there we go, there we go, right

so I have this

landscape that is curiously popping

but

oh, yes, yes, there's some

some teapots

that great bit of coder art

so there's this

so there's a variety of landscape waveforms

and there's a random one

and a flat one

and some sine waves

and some steps up and down

so I'll do the steps up and down

because that's kind of easy

so anyway, yes

sample the landscape height at that

and just move the predicted one up

to the right foot

and then the IK is obviously going to do some seeking

which I'll get on to

so strafes and turns are special

you don't predict

when I said you predict the motion to the

to the next foot fall

as the foot just goes down

in fact

strafes and turns you predict to the next

mid-step

so it's quarter of a cycle on

and you do this because

when you're strafing or turning

what you want is that

when you're doing the action

by the time you get to mid-step

that foot should be straight

and directly under your body

otherwise you're going to fall over

or if it's not straight you get extra torsion

which is just uncomfortable

so people tend to plant their foot

so that by mid-stride

the foot is straight ahead

and directly under the body

or it'll be slightly offset

because you're doing this walk thing

but anyway, so that'll be the natural pose

so if I'm walking in a circle

I will look ahead

I will pre-turn my foot

so that by the time I get there

and ditto with a strafe

I'll step further out

so you do further prediction ahead

so you can see a rear view

as I strafe

the footprints move quite a bit

the predicted ones

and you can see her stepping out

if I slow down time

so you can see

the instant the foot touches down

she's actually now wider

now if you turn this down

so that

sorry, so that at mid-stride

it's actually under her body

I'll find a key

there we go

so if I turn this off

and she just predicts to the

to the next footfall

so you can see that

as she plants it

it's underneath her body

the problem is

that at mid-stride

it's like

oh, it's holding her up

she's leaning over weirdly

so yeah, that's a subtlety

and you can see if I

come up to normal speed

it kind of looks sort of odd

she's just like

permanently off to one side

whereas that looks much more balanced and natural

so there's this problem with

discontinuities

as I

as I, the pathological user

discontinuously change my

user inputs

so the predicted footstep

at least moves

smoothly

there's never any

abrupt move

but a smooth change in x, y

x, z

can change the predicted height because

somewhat foolishly

I have chosen to have a discontinuous height field

but I thought hey

that's a pathological case

I can get this right

anything will work

so I damp the predicted foot

sorry

I should damp the predicted footstep height

to prevent this pop

I actually don't

now the interesting thing is I only notice

this very occasionally

even on this sort of landscape

which you think hey look

it's got tons of little steps and stuff

but

it actually doesn't happen that often

for example in a completely straight walk

you can see

although the steps up and stuff

the predicted footprints are never actually

moving

because

I'm not applying user input

so I apply user input

and you can sometimes see that

the

one of these two footprints ahead

is sort of popping up or down

it has very little effect

so that's a subtlety

so you might want to damp that

or you might just want to go

yeah whatever

it's fine

the problem with damping is of course

it might mean that you put your foot down

and actually

it's interpenetrating the landscape

so there's that annoying trade-off

the other cute thing is that

it's not very fussy about

I mean I've moved the height

so that it follows the landscape

but you could move the x, z as well

I mean there's

according to the strafe and stuff

but you could do it in other ways

so you see that they're about to step on

like someone's head

which is kind of unfriendly

so you just move it to the side

and that's fine

so little adjustments

or they're about to step on

actually step on like a coke can or something

and you go well no

in real life you'd just

you'd like

just move your foot slightly to avoid it

so maybe we can get a bit more realism this way

to just avoid small things

probably the biggest one is

is if you

if you've got someone sidling along a wall

so they're right

they're very close to the wall

and the game design says

hey they've really got to be able to get their shoulder on the wall

but the

you know this is a big beefy bloke

or maybe a cowboy or something

so he's got this big wide stride

so when he's up against the wall

the right foot actually goes into the wall

or it just looks wrong

so now maybe the collision system can go

hey that foot's actually inside the wall

can we just shove it sideways a bit

or for

you know

or if it's a cliff

you don't want it hanging off the edge of the cliff

so you can tweak it in little ways like that

I put down dancing as a rather optimistic

optimistic one

dance granny dance

so the footstep position only describes one instance of time

in the entire cycle

one instance when the foot went down

the

as mentioned yesterday

there's actually two constraints on most feet

which is when the heel strikes

and when the ball of the foot strikes

and those are regarded as two separate constraints

a good thing for walking

is you can mostly do everything as a delta off

like some nominal position

you simply say

well as long as I nail the heel

then the ball of the toe is going to be pretty good

because I'm not doing any

sort of huge changes like

like sort of that

or the martial arts moves that they were doing

where you do an awful lot of rotating on the ball of the foot

so it's slightly simplified

but it's an awful lot better than most games are doing right now

so that's fine

so the IK needs to be applied to the feet at all times

rather than just when it's down

because otherwise it's going to pop on and off

and you're going to be seeking there

and just go

as soon as it goes down

so there's three distinct phases to this IK

same end logic

same complex stuff

you just feed different stuff to it

so all three phases

have the desired position and orientation of the footprint

which is usually this predicted position

or the previous footprint

they have a reference position and orientation

which is

if I did nothing

if I just played the animation a straight line

where would the foot hit?

so it's just a straight line thing

where's it going to go according to the animation?

and then there's this desire factor

of how much I want to play with the foot

so when the foot's down

that's the easy case

the foot's on the ground

you say

well

that footprint

I've got the actual position

it wants to be there

so the reference is the animation starts

when you just planted the foot

and then the desired position is the

the actual place it got to

despite where you've moved in the

in the meantime

so it's pretty simple

the nice thing about this is that

these two are

talked about at the same time

these are both that

when the foot goes down

now the fact that you're like mid-stride

as you'll see that doesn't matter

even if the animation puts some foot slip in

it still works

so that's when the foot's down

we're just taking another look at it

so if the ground

the foot is in the first half of the swing forwards

exactly the same two inputs

it's the last foot plant

for both the reference and desired

and the desire simply starts at one

as the foot comes off

and then fades to zero at mid-swing

so at zero we're doing no IK at all

so

when you're in this pose

this foot is completely unconstrained by IK

there's no

it's now in the animation neutral pose

and then as we go through the

second half of the swing

we start using the forward predicted footstep

we look forwards in the animation to see where

that would strike normally

and then the desired

starts from zero again

and fades up to one

so that at the point of impact

we should actually hit

the predicted footstep

these desire curves

just piecewise linear

kind of simple

actually work

I was expecting to have to like smooth step them

or get the artist to author these or something

but they actually work fine

so why overcomplicate it

but you could obviously do that

one thing about doing them in an art package

how do they preview them?

it doesn't mean anything

so the way you actually do the foot IK

is you've got this reference position

you've got this desired position

you find the delta from one to the other

just to transform the

linear offset and the rotation

you scale by this desire factor

and then you just apply this delta to the ankle bone

so again

this delta

that's the delta

as the foot hits

wherever you are in the cycle

that's what we're talking about

as the foot hits

it's that delta

now if you're in mid cycle

then that's why the desire factor kicks in

so here I'm unconstrained

and as I go forwards

the desire factor increases

and I seek towards

the right delta

and again during

while the foot is on the ground

if the animation says

hey I want to slip the foot

well that's fine

you say okay

I don't actually care where you want to put it

I just know it's got to be like

two centimeters to the right of where you think it should be

but what you're doing with this slip motion

that's fine

you've just got to be two centimeters to the right

and one up

because it's higher than you think

so actually applying the position delta to the ankle is easy

you move the

this is a standard

two bone IK solver

knee pop control was mentioned

this is

I don't know

if you've ever done any IK on legs

it's really obvious

as you swing forwards

this knee goes bam

and it's really bizarre

locks out

and then as it comes up

it just sort of goes

it's very strange

and it's because

as the

as you move the

ankle further and further away

as you get here

to the near extent

a tiny movement in the ankle

requires a large movement in the knee

so although the ankle is moving at a linear speed

the knee sort of accelerates

and slams against the stop of the leg

which as humans we never do

you don't want to stress the knee that much

so what we actually do is damp that

and just say

hey

the knee is not going to get

the foot is not going to get there

in the right way

now

the guys last night

what they did was actually just

they damped the motion of the knee

from frame to frame

and then they actually just lengthened the bones slightly

to make sure the ankle

went in the right direct position

I did a

much simpler version but

it's all kind of

the position deltas we're talking about are very small

in fact that's the problem

if it were larger it would be easier

so all I did was I said

in the IK solver

I said well beyond like

an angle of 170 degrees

just whatever

angle you wanted

whatever deviation you wanted from 180

just I think I divided it by four

and did a scale so it's continuous but

but what it means is that the ankle doesn't actually get to where you want it

but it's a pretty small

small error

you know as you can appreciate the difference between

170 degrees and 180 degrees is a very small movement

so that's your maximum error

and it just slows the knee down into that

to that crucial

going straight phase

works

very nicely

so you can see she's

there's no

knee pop even if you sort of slow it down

it's when she's swinging the foot forwards there

is when you get the knee pop

so

that seems to do the trick

it's kind of cheesy

the nice thing about it

there's no like smoothing or annoying

frame to frame coherency

which in general you want to avoid this as much as possible

obviously I have to have some for this

footprint prediction but

but I do as little as possible

oh and

so that's just the position applied to the ankle

and then the actual orientation

the twist is just applied to the

the main foot bone

so this was also mentioned the hip height

if

if you vacayed

a foot down

say you're stepping down onto something

well

so this foot needs to go further down

but it can't

I haven't got a longer leg

so you can easily make legs shorter

you can't make them longer

so what you need to do is you find

the

in practice you could do it in 3D

and stuff like that

you'd need to do that for a martial arts move

for walking you can just do it all based on height

and

it's not strictly correct because

a large angle is

there's

like it's not quite right

you don't see that

the effect is timing

so you just say

well

you look at the lowest foot

of the two

and then you say well that foot is

two centimeters lower than my reference pose

so I need to move the hips down by two centimeters as well

now that moves the other foot down

but it's okay it's IK'd

it'll IK back up again

so that's fine

now this does break one rule

which is as I said

the game controls where the character is

well now I've said hey

but the animation system wants to move you up and down

okay so that's a fight

put the animation coder and the gameplay guy in a room

and whoever comes out alive

it's a trade-off that needs to be made

in many games

the actual vertical height of the character is not important

in some shooters it will be

so that's just

it's one of those reality games

the gameplay trade-offs you need to make

so always at least as low as the lowest foot

this does cause bumpiness during foot swings

so if I'm stepping up to something

then obviously my right foot is the lower one

as soon as I step up

it's going to swing forwards

and it's going to be higher

so very quickly my hips are suddenly going to go boing

and then as I step

and if I

the next one is down

so like I'm just stepping over a temporary obstacle or something

so I step up and then down

the problem is

normally the motion would be fluid throughout the cycle

you'd step up and then down

problem is this transition

this foot almost immediately goes higher

and then this is the lowest foot for

like 80% of the stride

and then it almost immediately goes lower

so instead of a nice curve like that

it goes

bam

looks weird

so instead of the actual foot height

which is the virtual foot height

which is just

very simply

it's the linear interpolation between the previous footprint

and the next footprint

I have all this data

I just learnt between that

so if you temporarily step up onto something and down again

it acts as though that foot just moved in a straight line

it didn't go up or down at all

but this also looks wrong

because that means when you're stepping over an obstacle

your hips don't move at all

this foot, the previous and last positions

are the same height

I do a lerp

same height

it's always the last one

so that looks goofy as well

so I did this blend to the other foot

so you do at least get a blend up

and a blend down

that looks much better

again

these are very hand-wavy explanations

there's no hard math behind this

it just looks better

sometimes this is animation coding

this one I think I actually did do a smooth step function on

so that it was continuous

rather than piecewise linear

because you can see that

nasty

the change in

the abrupt change in speed

smooth steps just like you apply this cubic thing

so

if you notice the skirt

I'll turn the footprints off

so this fetching skirt that she's wearing

and in fact these show

shoulder straps here

though they don't move nearly as much

so this is kind of cool

and it looks like a cloth sim

and it's not

or at least it sort of is

so it's not a runtime cloth sim

you're doing 30 of these

that seems too expensive

especially if you've got all the collision stuff to do

and it's just a pain

what we wanted to do is say

look, you can have any sort of animation you want

so as well as just being a cloth sim

it could be any hand authored

or very complex system

that you want to do

certainly for like a t-shirt

you can have all the crinkles around here

and even just things like

when my arm is up

the t-shirt sort of hangs down

when my arm is down

it sort of hangs the other way

not hangs but yeah

so anyway this is just purely

the animator says

hey I've got this cool thing

and it's not representable in bones

because there'd be bazillions of them

so I want to record it as vertex animation

okay, says I

little knowing

so we record it as a vertex animation

just each frame you just capture the vertex positions

and then for each vertex

it's positioned through space

I just encode that as a spline curve

because you store the raw keyframes

that's huge

the spline curves aren't that much smaller

sorry, I mean they're a lot smaller

they're still kind of big

but we shall see a way to do that

so one of the problems is that this cloth sim

which was just the Maya standard one

which isn't that great

but it doesn't loop properly

which is the problem

it'll forward predict all day

and it'll do kind of the same thing

but it's not a perfect loop

so each animation was actually 12 cycles

or this was kind of tweakable

10 seemed to be about good

and then the next two

so from the standing start

the skirt's just sitting down there

you start walking

the skirt kind of does random stuff

because you just applied energy into the system

and it takes it

so she just keeps walking for about 10 cycles

and finally the skirt sort of calms down

to this proper swish motion

regular swish motion

without any weird movements or anything like that

so that's the settle down phase

and then the next two cycles

you kind of hope are the right thing

and practice some of them

like especially the run animation

which is very energetic

every now and again

a couple of the straps

are sort of ballistic

and you know stretch off to infinity

and come back again or something

so we'd like edit this

of which two cycles you picked

but you picked one

two cycles anyway

so to do this loop

this is a standard trick from audio processing

see this cross disciplinary stuff

very useful

so you just copy it and offset

so these are the original source data

I've just offset one

and then you just

and then I cross fade this

so that you get most of this bit

and most of this bit

and because we get most of this bit here

and this bit's the same as this bit

well obviously that transition works

because that was just part of the animation

so this now loops seamlessly

so that's a neat trick

as I said they're kind of big

every vertex has a spine curve associated with it

gets kind of heavyweight

so I only did it for the six major animations

which was the three walks

and the three runs

no leans

no accelerations

none of that

you could do them for the other ones

but you know what

the effect on the actual skirt

just kind of doing this noisy random thing

you don't notice that

it's not leaning the extra

you know three degrees over or something

and it would literally double the memory

you know six atoms to twelve

so there's this problem

blending vertex animation doesn't work

bones slurp and preserve length

when you move your leg in a circle

it actually preserves the length

the knee moves in a circle

if I encoded that as vertex animations

and had a pose here and a pose here

and did a lerp

my knee would shrink

but there's nothing else you can do with vertex animations

all you have is a bunch of positions

you have no

well I mean you could get connectivity information

but it's

it's not very

like there's a lot of it

it's just a polygon soup

and besides this is cloth

this is deforming in weird ways

good luck with that

that's what a cloth sim does

so this wouldn't probably be a problem

I mean you know

if you played back just the skirt

it'd be fine

because you know it's doing something noisy

the problem is where they meet

which is around the hips

they need to actually meet

so what you could do

is you could have

the actual vertices where they meet

boned normally

the next vertex down on these

highly tessellated strips of cloth

could be vertex animation

so that top segment would stretch like crazy

in places

and the difference is quite big

it's on the order of 10 centimeters

the difference between the slurp and the lerp

so you'd see this

and the skirt would obviously look kind of disconnected

it's really weird

and there's this other problem

when you IK the leg

so when I lift my leg

from the IK

so the original animation is down here

the skirts are lying along it

I IK the foot up

oh

it just goes straight through my leg

it's bizarre

so we don't do object space vertex animations

you get the artist to skin the skirt

just like it was like a tight miniskirt or something

so there's bone weightings on the hips

there's bone weightings on each thigh

for the relevant bits

and then he just turns the

there's a blend shape in Maya

and there's a

there's a cloth sim

and so you just turn the influence of one of them

just down to nothing

so it doesn't actually change the animation

it's just so that this post process

would use this data

so now for each of the vertices

for each of the poses

as a preprocess

I transform it back into the default pose

because I know how to get from default pose to animation

that's what I do every frame at runtime

so I just invert that matrix

move the vertex back into the default pose

so now I've got this swishing skirt

but she's in the standard da vinci pose or whatever

and it's swishing around there

so this actually makes sense now

we can

you can

you're lerping these things in the same space

and she's just like standing there

with this skirt swishing magically

but that makes sense

and better yet

if you have two bits of

two vertices

they're out here

when you do that swish

it won't interpenetrate the legs

because all the preceding ones

now you can actually get

as fine interpenetration as

like a cloth

in one frame it's around here

and in one frame it's around there

and it goes through the leg

but that's kind of rare

so that's fine

so it's just the effect of being cloth

that is preserved

the gross movement of

oh this lot sort of moves generally forwards with the leg

and the up and down motion as she jogs

that's all removed

that's the big effects

and that is preserved in the bones

so the runtime's really simple

you replay the vertex animations

into your vertex buffer

you throw it at the vertex shader

and you bone it as well

so you do all the standard boning stuff

but your position has actually come from an animation

rather than just being static

again yeah

lerps make sense here

all the animations

even when I'm blending

between a run and a walk

the vertex animations

are both recorded in this default pose

so again the lerps make sense

even though they're in world space

so that's kind of cool

and the IK just works

when the knee comes up

that bit of the skirt comes up

now it's still not obviously technically correct

because it should be sort of splitting and hanging due to gravity

but it doesn't interpenetrate

it doesn't look goofy

that's fine

there's a nice side effect

the vertex animation is simpler

if you've got a vertex that just kind of moves with the leg

that motion gets completely removed

if it's nice and flat

we use fewer knots for the curve

so it does actually come out with less memory

this is a cute trick

you can use it for a lot of fine vertex stuff

facial expressions I think would be cool

it means you can get the jaw movement as a bone

so you can lip sync with that

but then the actual expressions on the face

can be vertex done

rather than having to encode them as bones

which typically gets bigger than the vertex animation

which is kind of annoying

depending on the tessellation of your hands as well

it can be cheaper to store them as vertex animations

rather than every single little bone in the

there's like

sort of A20 or something like that

if you have not particularly well tessellated hands

then you just go

well I'll just store them in position

that's fine

and obviously cloth of all sorts

anything physically simulated

that you don't want to do at runtime

and this is kind of good

because

you've still got the gross movement in the bones

that all happens

if you have an animation

if you have vertex animation missing from one of the animations

fine, you just take it from the others

and it'll look kind of swishy

it'll look kind of clothy

it'll be fine

you'll still get the

the effect of the

second animation applied

you just won't get like

fully perfect

per vertex stuff

so this demo is still kind of a working process

things I want to add very quickly

more emotions

that was a

a good one talked about very briefly yesterday

in that it's not enough these days to just have a walk

and you go

hey look the feet are stuck brilliantly

okay but I don't care about this character

let's have some emotion so

so we've got like a

you know granny's really

you know

poised and ready to kill you

before she's like

whoa

that's a big dragon

so stuff like that

and lerping between those

obviously this demo didn't have any standing

and if you slow her down she just sort of stops

that's right

so I want to do some standing stuff

which prompts a problem

I'm standing there

and the user taps forwards

so I go okay

well I better start walking

and then

and then you go

oh user's not pressing forwards

oh they just wanted to like hop forwards

now

if you're in a sword animation like that

a hop forwards

you lead with the left

a walk forwards

you start with the right

so there's this problem of like

well

I know the user has just started pressing forwards

which is it

so I don't really know how to stop that

so that's going to be an interesting thing

my current best thought is that

you hack it

and you start the step

and if at this stage

the user hasn't taken their finger off

you go okay it's a walk

and you do this

so it's a slightly odd start to a walk

because it's like this

but hey at least it's smooth

and it's not like some sort of

and then you just sort of magically swap legs

or something crazy like that

um

standing pose transitions

no one does these right

so I'm standing around like this

sorry

I'm standing around sort of on one foot

and then I do something like

I want to kick with this foot

so what you need to do

is transition

and then kick

so that's

so what the artist really wants to do

is give you a couple of poses

like that one

or an even one

or that one

or you know your fighting ready stance

or something like that

and then you need to be able to do transitions

but the feet will always be planted differently

so you need to move at least one foot

and if you're taking this strict thing

that the game controls the centre of mass

then you can't move that

just because the animation says

hey you know I'd like to

I'd like to move one of the feet

so what you need to do is

move one foot and then the other

and it's like this

it's an automatic adjustment

that humans very easily make

but it's

it seems to be difficult to do that automatically

so I'm hoping that some sort of weight distribution

means that I can choose sensibly which foot to move

or which foot to move first at least

turning on the spot is the pathological example of this

I'm standing here

and I want to be standing here

so you've got to do this weird foot shuffling thing

and which one do you move first

and how much and stuff like that

the attacks

I catered to precisely strike the target

I was going to kind of fudge this

but the animation by example stuff

well that's how you do it properly

so I've just changed my mind on that

so yeah I might be implementing some of that

and the big thing is

with these sword things

I don't know if you've noticed

the only attack you can do is a big slash

and that's because

well they're never quite sure where the bad guy is

so as long as we do like a big slash like that

he can be anywhere and there you'll hit him

there's never like a

stab

because if you stab

and he's just slightly to the left

you missed

a little red number appears above the head

hey but I missed

what

so if you can do like the various stabs

you know

and then do this blending

smart blending

so you precisely hit them

you know for a critical attack

you actually hit them straight on the voice box

they fall down dead

and you go yes

rather than going

well you didn't actually hit him

but hey I'll take the loot anyway

it's not like the

yeah

so

that should be kind of cool

getting decapitations actually on the neck

it's taken a tricky because

it's like well they could hit you anywhere

so that's going to have to be

some sort of physics rag doll

and I might kind of just ignore that

because I don't feel like playing the physics engine

through a demo

but that's how I think you'd do that

with

in a game

looking around

you know she's just

fixedly ahead

you want

you know her to be looking around at random objects

literally random objects

sort of

godsim we did

called startopia

we just

someone just hacked in one day

as the characters were wandering around

we had this movable head

which was intended so that when you talk to them

they'd actually look at you

which is kind of nice

but someone just hacked in one day

that

as they're walking around

they pick a random object within a certain range

and they look at it

until it goes

until their neck just

can't move anymore

and then they pick another object

wow

these things were alive

as they're walking around

they just go

huh

hmm

look at that

and one of the

one of

it's just like wow

look he's a real person

he's looking around

he's looking at stuff

and one amusing thing was

the users actually interpreted this

in some cases

as like a slight obsession

so

it happens that two characters want the same thing

they both want some food

and there's only one food thing

in the entire universe

because you've forgotten to put down more

so they're both going on a long journey

over there

so they're both walking

now as he's going around looking at this stuff

one day

one of the objects he'll pick

is the other person

they're both walking the same thing

the neck never gets over torsioned

they will stare at this person

forever

this is like this horrible stalker type thing

so people love that

they'd say yeah I got this really evil guy

and he was just like following this other guy

and just staring at him

so

it's just like a

whatever

okay

we don't have a stat for like

obsessiveness

so stuff like that

just improves it

this would be with the standard

like nine head poses

and you do your lerp

and then you just

bone mask it onto the

sort of

the V of the shoulders and the neck muscles and stuff

to look around

upper and lower body anims

at the moment I just have the whole anim on the thing

just to do moves and attacks at the same time

pretty standard stuff

each attack has a

mask per bone

to say how much this attack needs that bone

so if it's just like a simple parry

my left hand

my left arm basically isn't involved

it can do whatever walking stuff it needs

if it's a big swing

it's you know you almost take over the control of the hips

and the foot IK just has to

like try and cope

and the jumping

which I hate

I mean trying to get jumps looking good

yeah

I don't know how to do that

I'll find out

noise

there's a whole bunch of noises

this is quite interesting

if you add position noise

you get this sort of doddery thing

it looks very odd

and you can tone it down

but you just get slightly less doddery

until you get no noise at all

so you never get like

oh it's kind of

they're a real person

kind of doing the right thing

you just

like they're either old or not

that's not very good

they're either old or a robot

which is

not good

so for cyclical motions you can change the phases of

the motions in each bone

so the nice thing about that is

your foot always still gets there

it's not like some random jittery thing

it's just

each time you swing it forwards

well maybe the knee comes in a bit earlier this time

or maybe it comes in late

or maybe the foot sort of does something slightly strange

because it's out of phase with the stuff

so it's still a cyclical motion

it's just kind of

it's just sort of like

slight discoordination in the movements

so that looks a bit better

doesn't work for standing still there

because there's no phase

and whenever you add noise

you'll need IK fix-ups

even if the native animation works fine

so

quick summary

walk cycle's really important

we've kind of got the stationary pose stuff

pretty good

they're not too bad

walk cycle's still terrible

terrible marks all around

apart from like two examples

which are actually

pretty impressive

we need some more people in the middle please

it's like

wow I can't break this at all

and yeah well

you're just changing your feet all over the place

the most benefit

number number one is sticking the feet down

that is the most obvious thing

when people see the feet suddenly

changing

it's just like

there goes your suspension of disbelief

you fix that, that's fine

that's easily the best one

good transitions

are nice

so again

just stop the rest of the body popping

strangely when you change

stuff

and then

the correct prediction of foot plants and stuff

copes with rough terrain and so on

it's kind of

it's kind of the icing on the cake

but it really does make it look good

oh the difference between sticking the feet down

and the correct prediction

is you might not actually be sticking them to the real terrain

you might be just like

sticking them somewhere arbitrary

but that's still better than

not sticking them

even if it's the wrong position

so again

I'll just say this again

the golden rule

the AI does not control the character

the AI must cope with whatever

character movement it's given

thank you

applause

so uh

any questions?

yes

um

alright

have you thought about

doing foot path protection

because like when you're walking up the stairs

you're getting just as bad

artifacting

yes

the foot path

yes

at the end

so the problem here is that

uh

she only ever looks

where her footprints are

at the actual footprint

right

um

find the key

there we go

so the only

the only

the only place I'm sampling the

the height field at

is the

footprint

um

so the lerp in between

means

oh there we go

she uh

she moves the foot

through the

should probably do it again there

work

yes

um

so yes

yes you could do

the problem with that

is

so what do I do about it

I know my path's going to intersect

do I just keep moving

like moving up the midpoint

because I can't move the endpoints

they've got to actually hit

so the only thing I can really move is

like

the midpoint

or the

first quarter

or the

mid quarter

and like draw a spline through it

do I just keep moving them up until

until

it doesn't hit or something

uh

like sometimes

it seems like you want

you want

the path

you have some

you have some spline

that is the end effector path

right

it's not it's not necessarily one of your joint splines

but it's like you know

it's some nonlinear function

of whatever's happening

right right

and you want to perturb that

until it doesn't collision

with that

collide

with the ground

oh sure

for us at least

it's major

yeah

right

so

I would do

in practice

I'd do two things

number one

I'd manually do stairs

right

just like

hey it's stairs

let's play the walking up stairs animation

and

it's really easy for the animator

to just make sure the foot moves vertically

and then horizontally

magic

end of problem

um

and second I wouldn't

yeah

wouldn't do this

crazy gaps like that

um you still

still do get them

in real life

uh

curbs

sidewalk curbs

um

that's probably the

the major thing

um

again

I don't know how to solve that

it's

it's very very tricky

um

hey you know

in real life

I

don't solve it terribly well

fall over a lot

but

certainly

you know

it's something that it takes us like

uh

it takes kids like

10 years to learn

is not

how to

not fall over

uh

steep steps

so um

yeah

it's a tricky problem

um

kind of related to the same thing

um

it seems like you're

turning on the IK

for the foot down

events

and blending it off

right

so that the IK is not anticipating the foot up

you're not raising the knee

in advance

you know

if the

if the next foot step

is going to be higher

you're still just kind of turning on the IK

to compensate for that

as the foot is coming down

you're not

anticipating that height change

yeah

so the

the problem is that

if my next step is

is a high one

what I should be doing is

lifting the knee at

this point

I should lift it here

and then step up

um

that

that's all to do with the

um

the three phases of this foot IK

and the fact that it only changes from the previous one

to the next one

in the midpoint

now

instead of having these two distinct phases

with

one

bottom

and

one

foot

you could have a two-way blend

between the

like the animation neutral one

and either one

you'd probably have a three-way blend in some way

um

and you'd need some heuristics to say

well

was I stepping down from something

is that the most important part of this animation

so I'm stepping down to something level

or I'm stepping from something level upwards

and

and then you've got the weird case of like

well I'm

I'm stepping up for this step

but

ne

so

um

yeah

I think you probably just changed the

the blend curves for that

um

but

I

I haven't played with that yet

that is something I'd like to get right

because the step ups and downs

still don't look great

for large step ups and downs

uh

let's go over

I had a question while we're transitioning to

I noticed

when you were doing the IK prediction

for the foot placement

and I don't know if it was during just your debug stress test

but you'd get some feet

crossing through the other legs

and I know my animators would scream and say

that wasn't in the original motion

why am I seeing that

you know

I think the only time

so did you look to avoid that at all

I think the only time that happens

is when you strafe

so

there

um

and that's basically cause

this is not a real animation

this is just the walk forwards animation

that I'm just moving the body sideways

so you can definitely

uh

instead play

the strafe animation

that

instead of just going

like

smacking one knee through the other

would like

move the foot round

um

if they wanted

but

again

that's

that's like

the

I mean

it's easy to blend in

I know how much I'm strafing

I can just blend in

it's like turns and

everything like that

but

hey guys

it's another

however many animations to do

so

that's your choice

um

yeah

uh

just curious

what are the two

good examples of walking you've seen

so one of them was this game

um

I think it was Half Life 2 or something

that was quite impressive

um

we've been swapping tails

of trying to break that

by

you know

there's a cut scene

and you know he's gonna do something

and you rush in

and you put crates in the way

and see how he responds

and they always do the right thing

I mean they don't do the like

the high level smart thing

which is just a

yeah

but they like

they either clamber up on the crates

and then still correctly pick the object up

or

or they now round them

and

it's like

it's impressively hard to break the animation system

I mean

yeah they still look goofy doing it

but they look

they look like a goofy human

rather than just like a

completely broken

uh

computer animation stuff

so so there's good stuff there

I was quite impressed

um

so about your golden rule

that uh

the animation should not be driving

the object

uh

the game object

um

so how do you author your animations

uh

to avoid foot sliding

in the case when you're not doing IK

do you make it so

do you assume that they're going to be moving at a

constant speed

and you adjust your feet that way

well I

I do what

um

so

first the designer and the animator

agree on a speed

and then the animator does an animation that

kind of gets that speed

but he doesn't have to be spot on

um

and then

when you load the animation

you actually measure

okay so I know it's one cycle long

because otherwise I'm

going to get out my

my stick

um

so I know it's a cycle long

and I know how far it moved

so

um

because you've got the

the motion of the root bone

extracted

and it says

hey this is how I'm moving

uh

you need this for complex animations anyway

so

for a walk it's just kind of

dull

but you just measure the position between the

start and end points

and you just go

okay

now I know how fast it moves

so I'm just saying

hey

if the character's walking

Mr. Game

this is kind of how fast it's moving

is that okay with you

the game probably says

yeah yeah that's fine

or it like throws it

throws up an assert saying

dude this guy walks really fast

or just

break the game

what about for a cycle

of an animation that moves

very regularly

like a limp

thing that you know

for most of the cycle

you're not advancing

and then you move forward a bunch

well any

any cyclic thing is fine

because

I just measure the start and end

um

and

for those

uh

granny

the

um

the animation package we have

is uh

has a variety of ways

of extracting this motion

um

and one of them is

this

uh

thing where the root bone

is

linearized

so it assumes it just moves linear

and then

the difference between that

and the real motion

is encoded actually

just into the animation

so

um

so if the game just moves

the object forward at a

steady pace

that's fine

and then

the object

might offset itself a bit

because of the limp

so

um

so all the delta

is in the information

is in the animation

as far as the game's concerned

hey this guy's just moving

straight forwards

in some cases

that's not a good idea

because

his collision volume

is moving

steadily

whereas it is

um

the real one isn't

and in that case

the game then goes

okay

so it's a

it's really

like a mantling thing

or getting into a car

or something complex like that

where

you still want the bounding volume

to be right

so you can like

shoot him in the head

or whatever

um

but the game really doesn't want

to have to go

okay

so time is less than blah

so it's this position

tell me where it is

and that's fine

I now cede control of

it to you

because usually

when you're doing those

uh

the player is also given up

their control

right

they said get into the car

they don't expect to be able

to do anything

during that period

so

so that's fine

so the game

and the player

implicitly give up control

so

same with things like mantling

and commando roles

and stuff like that

it's complex animation

that's when you hand it over

to the animation system

I haven't looked at

going backwards

or even standing still yet

so

uh

yeah

yes

agreed

um

that

the

the step up and down

for the extreme cases

um

that was a perfect segue

into my question

uh

which was

uh

some of the animation stuff

last night

and you a bunch of times today

have basically mentioned like

oh well if you want a better effect there

just have the animators

do more animation

for that specific effect

or movement

which is totally valid

uh

you know

data drive

driven way of approaching it

but

that fill in process

is going to replace code

like you've got special hacked

I mean not hacked

you've got special code

to deal with

no strafe

walk

doing some IK

um

uh

have you given any thought

to like

how to data drive

the process of fill in

and put all of the fill in

in the hands of the animators

like

to know when that's there

to turn that code off

or that kind of thing

like how do you

instead of going like

oh

okay

the animators have decided

that the walk strafe

looks horrible

so we're going to have

we're going to fill all that in

um

oh

okay

I got to go comment

on a bunch of code now

so the

the way

if they say

oh that looks horrible

look let me just do one

so

all the sort of

the steady states

like walk

and run

and so on

have standardized names

and then you want to do a transition

from walk to run

you actually look for an animation

called

walk to run

you just do the string

concatenation

and

if it's there

that's cool

I'll use that

and just transition into that

if it doesn't exist

for this character

okay

I'll do my code thing

um

and so for the strafe

it'll be the same thing

you look for an animation called strafe

okay

well

I'll just move the hips

because I'm going to move the hips anyway

right

again

game's in control

it wants to move the hips

okay

so the animation says

okay

game moved the hips

have I got a strafe animation

okay

well

I'll just IK the feet

and do the prediction

and hope it works out

if it looks rubbish

well

the animators need to do a thing

but if the animation was there

cool

I'll play it

now I still need to do this prediction

and IK

but the nice thing is

if you're also playing this animation

well

the prediction's going to be pretty accurate right

I mean

otherwise the animation's rubbish

sorry

absolutely

but the thing there

is

it's the same with the walk speeds

um

the game's idea of how fast a character walks

has to match

you know

roughly

the animator's idea

of how fast the character walks

otherwise it's going to look rubbish

I mean

it's just going to look rubbish

and it doesn't matter

how good your animation system is

you've got this mismatch

right

so

but at all times

so what I'm saying is that

there's got to be this connect

between design and animation

fundamentally

the animation system

the actual code

doesn't care

it will just cope

right

now

if it's fed junk

but hey

it's going to get junk

but hey

it's going to get junk

but if

if the

two match

um

so

yes

you're right

that these two have to match up

but

they don't have to match up in code

they have to match up in

like design

and

you know

the parameters that are put in

to how the model moves

so yeah

if

if the user says

so if the game says

hey

we want to strafe at

you know

a metre a second

and the animation only strafes at

half a metre a second

well animation code doesn't care

it's still going to do the foot fix up

but

but there's not a lot you can do about that in code

and nothing

none of that is hard coded

it's all just like

this is the game design

this is the animation

they've got to

agree somehow

no

that's correct

yes

so the

um

so

come on

this

slideshifting

where are we

um

this

foot

ok

so where I have this

I have this desired position

which is obviously the

the prediction

and

the

actual orientation

so the actual orientation

is

so I actually go forwards

and

whatever animations are currently playing

I

actually

do

this

so

I

if

playing, I sample them at that future time. So if there's no strafe, the foot will just

go straight forwards. If there's a strafe animation playing, the foot will actually

go out to the side. Either way, I also forward predict and I say, well, the foot actually

needs to be over there. Now, if the two match, hey, that's cool. I have to do hardly any

work with the IK. If they match completely differently, which is what happens here when

she's strafed, because it really is quite different, then it just goes, okay, I'll do

my best. But yeah, if there's an animation there, it'll just go, it'll play it. And then

this coder just doesn't care because it just goes, hey, what's currently playing? Okay,

we'll look ahead and see where the foot would naturally fall. So if they agree, that's cool.

The IK doesn't have to do much work at all.

So I have a very similar kind of question that was actually inspired by a conversation

which I had last night, which is sort of at a more philosophical level.

There's a decision, definitely, as to whether you're going to use data or some kind of a

hack. So from, say, the kind of position that we were showing yesterday, walking up the

stairs is a completely different kind of thing than walking on level ground. If you've watched

you, a person do it, there's no way you'd ever say they're the same motion. You need

to record both of them.

Absolutely agree.

So the extreme point in that philosophy, you would have lots and lots of motions.

What you've sort of have been showing here is animation is so, so precious. I can get

these nine loops. I'm never going to get any more. I've got to squeeze every last little

bit out of them.

Yep.

So I guess I don't have a feel for that tradeoff. As Chris mentioned, some of the

classic arguments of, well, data takes memory footprint. Well, big code, you know, it's

really takes memory footprint. The other argument of, well, as data are expensive, smart programmers

to do this kind of stuff are expensive. So how do you see that tradeoff playing out?

You're right that it varies a lot by project and company. Something like Eco, there's two

characters. So, well, okay, there's the shadow guys as well. But there's two characters,

and they've probably got a fleet of animators. Great. They can animate absolutely everything.

There's so much more, there's more animator time than there are, like, animation time.

Vastly more. So you can do that all custom. But what seems to happen in games these days,

and increasingly, it's not a good thing, but it's just kind of inevitable, is that every

time you iterate a game, it's like, oh, this game's got 20 characters, so we need 30. And

this game's got some, like, really cool mantling animations, so we need that. Like, so there's

50% more characters, and there's 50% more animation. Okay, I'm now bottlenecked on animation.

My animators just can't do every combo. That's, like, I need to squeeze out those resources.

Obviously, that needs to stop somewhere, but, yeah, there's, but the thing about 30 characters,

it's the same code. So you do it once, and it works for one character or 30. So, yeah,

it's an absolute tradeoff.

But...

I just wanted to add that on the console projects I'm working on, memory footprint

is a huge issue. We have 20 character types, each of them very different. You can't run

a female walk on a male or a male walk on a female. It looks silly. So we have, you

know, 4,000 animations, and to define the whole animation space for all those, we just

don't have the memory. And we're even banking and streaming in styles.

With the same token, you probably also don't have the memory to have 4,000 separate code

pieces to deal with all of those things.

Well, we don't. We have a general code blending system that can handle all of them with different

parameters. But, yeah, my point is I agree that having the right example is important,

and we try to bank them up so you can stream them in. But the memory is huge, and it's

a big...

I mean, we had custom pistol rifle strafes, you know, animations that were custom for

that. We ended up having to dump those and say, oh, we only have a pistol strafe that

we play on the lower body, and then we do a single frame pose for the gun, and we IK

it for the upper body, because the memory was just incredibly huge.

That is the number one request. I mean, Granny runs on kind of everything. So the number

one request from the console guys is...

Oh, can you use less memory?

And it's like, oh, kind of, I mean, yeah, but I'll stop throwing stuff away that you

actually want. And they spend hours tweaking, like, the compression parameters to say, no,

no, no, now it looks rubbish, so just turn it down a bit, and yeah, okay, now it's fine.

They spend hours tuning the memory. Memory is a big problem on consoles, even if you're

doing the streaming and stuff like that. Streaming just, like, raises how high you can aim, kind

of thing. It doesn't make it any easier.

For a time, though.

Hang on, hang on, hang on, please.

Oh, sure, sure. Sorry.

Are you sure that's not this one? I was thinking it was this one, too.

Well, state your question, and then tell the talk.

Well, so on that philosophical topic, I think there's a pretty key thing which is missing

from that analysis, which is, like, you don't just have, I have animations, and I blend

them together, or I have some code, and, like, there's a proportional number of, you know,

bits of code to the number of animations. What actually happens when a programmer sits

down, or sometimes an animator, if they're making, like, a complicated rig or something

like this, is they're actually, like, orthogonalizing the parts that make up the animation, so,

like, I'm taking a thing like looking left, and I'm using some, like, knowledge about

how that works to make it so that I can generate looking left for any situation that may occur,

right? And it may not be perfect, but it's gonna do something reasonably good, no matter

what the situation is. Now, with animation, the problem is everything is captured together,

and if you're just gonna do blending, there's no way to separate out what is the part of

the motion that you cared about and what is not. So, I mean, really, the thing is, yeah,

if you could do something like, say, the synthesis by example stuff that you have, there has

been work in the past which goes like, okay, you know what, we've got these examples, and

we're gonna try and, like, extract out part X so that when we blend together, we don't

need to have, like, the total, like, exponential explosion of getting all the corners of all

the different boundary cases of this plus this, and this happens at the same time as

this, which would be prohibitive to store, and we're just gonna try and store, like,

kind of these orthogonal things we can combine together to get to any one of those corners,

and that's fine, but that stuff really hasn't matured yet to the same level as, hey, we

just have some snippets and we blend them, and we're always staying within some of the

convex blend of these things, or very close to it, so everything's okay. So, really, I

mean, that's, like, the missing piece. Like, yeah, we're gonna do something like that,

we'd love to always use animation, but the truth is that when you actually get down to

doing that, you kind of have this problem of no one really has the really solid component-based

separation and recomposition thing that you need there. And we're getting closer, but

it, you know, it's not there yet.

Well, and, and the slightly odd thing is that frequently some of these animations

that are generated, that, that we get from animators, they are actually completely procedural.

They've, they've rigged up this incredible complex rig in Max or Maya so that, you know,

that, like, the, certainly the looks, when I was watching the animator do them, so he

has an object, and he does the whole, like, head and neck and eye rig and stuff, so he

can move, he can just move this object around, and the person, the character is looking exactly

at the thing. Then, he exports 27 animations. And I do the blending. And you go, wait a

minute, there's this, you've got this rig. I mean, he's not adding any, like, well, he's

adding artistic stuff, but it's in code, essentially. It's, it's, it's, it's all procedural

stuff. Then we sample it, and then I try and reconstruct the signal. That seems kind of

crazy.

Right, but that...

We need a converter. The problem is, the two systems are so totally different. I

mean, the rigging systems used in Maya are just, just, like, real hotchpotch of whatever

people happen to like. And you want to duplicate that in code? Hey, good luck.

This was, I, I had another point about another section of it, but just to reply to

it.

Yeah.

I wanted to talk about that really quick, because this, part of what we were talking

about last night was, like, the procedural synthesis version versus the sampling thing.

But, I mean, in the, in the long run, they are, he's able to accentuate that with style.

Absolutely.

Whereas, the straight-ahead code one can't.

Right.

So, like, you want to, there, there's, the style aspects are what we want to preserve.

Oh, you actually want to be able to do that.

Right.

There's no doubt about that.

Right. So, you need to make sure. So, but I, what I was going to say, I was going to

kind of plug tomorrow's, although it's the next two-day conference, but some of you are

going to be here for, tomorrow's got a bunch of postmortems, and one of the ones that I,

that I helped someone rehearse with, Andrew Wilmot from The Sims 2, was talking, and this

answers the earlier question about the, or speaks to the earlier question about the trade-off.

Basically, they were never in danger of missing art lock. Like, the animators and the artists

and stuff were always ahead of code and design. And so, when that, when that trade-off gets

calculated, it's like, actually, just, it does scale to throw another ten artists on

the project, whereas it doesn't scale to throw another ten programmers on the project.

That is true, that, that adding more animators, you actually get more animation.

Right.

That's true.

And that, you know, the mythical man month is for coders. It works a lot better for artists.

And if you're a big company that can just throw animators at it, yep. So, it, yes, it

totally depends on the project and the company. So, yep.

Do we have any?

Yes.

I don't have an answer for this. You probably don't have an answer for

either. I'm just curious if you want to comment on it. You talked about making the walk look

good, and all of these challenges. And I know, with the average first person shooter,

the character goes 25 blocks or runs at 25 miles an hour. And if you, so you labor it laboriously

and then the game designers see it and they're like, well, the guy's moving so slow it drives

you crazy. If they set this standard that is ridiculous, in the end, the result is you've

just got to make everybody skate. And in certain games, they'll live with real time, but that's

just been a frustration for me on a lot of projects.

Yep. And I'm sure most animators, animation coders and animators down the years

have gone, 25 miles an hour? Are you crazy? But, hey, wasn't it like 40 miles an hour

in one of the Quake games or something? It's just like...

You ran it 95 miles an hour.

Really?

Yes.

Okay. So...

You never stopped at one place.

Oh, yes. That's right. Yeah. 90 miles an hour to Nort. It's like, wow, I love those

trainers. Can I get, like, buy lots of them and sell them?

Yeah.

And stick them on my car?

So I guess the question is, given that goal, what you're trying to achieve, do you

have any strategies or thoughts on how you reconcile that, the game design decision with

making it look good?

The short answer is no, I have no ideas. If the game demands that the player run at

these huge speeds, yeah, you've just got to, like, make the animation look kind of cool.

Yeah. Whether any sort of IK or anything can do anything useful at all, or whether the

IK is just going to permanently be out there and out there, and they're just going to look

stupid. Yeah. That is tricky. Yes?

Have you done any experimentation with retargeting the animation, I guess, to do the

skill to get the character?

Well, Granny just kind of does that. So, hey, yes?

So you can take the animation and you define it as a grand skill and then run it

against something with a different number of bones or different moments?

Absolutely. Yeah.

And how do you use that? How does that work?

It's just a name matching. So there's two ways. There's simply, like, oh, I'm a

character, I've got this walk cycle, and now I want to play it on this angel, and he's

got a bunch of wings. So, obviously, well, I've got this animation, it doesn't say

anything about the wings, or vice versa. I actually animated the wings, but now I'm

playing it on a human.

So that's just, that's easy, obviously. You just throw away bones. Different numbers

of bones, you have to do, you have to supply the original skeleton, the new skeleton, then

there's a mapping. Now, it's pretty good. It's not as good as the retargeting you do

in, like, animation packages, because they solve all sorts of constraints and stuff.

But we're talking about, this is basically a memory compression technique, right? Otherwise,

you'd do it offline and just generate all the combos.

Right, so I don't try and solve that, because the art packages have some pretty heavyweight

offline solvers to do all that. So if you want it perfect, you just bloat out and export

all the combos.

But, yeah, you can, you know, normally you can do some runtime stuff that's very cheap.

Do you do some rescaling also? Because it's not enough.

Oh, yeah, yeah.

It's not enough just to do the name matching, because the feed would be in the floor.

No, no, no. So the name matching is only done for, like, bits that are there or not.

The actual, yeah, you do rescaling and stuff. So you can play adult animations on children

and stuff. It still looks like a small adult walking, but that's better than, like, oh,

I've just doubled my animation.

I've just doubled my animation budget, because you put children in the game.

Ted.

Casey.

Yes, Mr. Casey.

With the retargeting thing, the deal is basically that if you don't have the rest of the stuff

that Tom talked about in this slide going on, then it's usually, like, a complete disaster.

Because if you're, like, talking about someone who's even, like, you know, a foot taller

or something like this, then what happens is the feet will skate pretty badly, because,

you know, even though you're going to scale the gross displacement of the guy, you're

still going to have these problems of, like, the actual knee bends and all that stuff are

not going to line up properly.

But if you are willing to do the IK again to, like, fix up the feet, that takes care

of a fair amount of it.

So usually what you end up with is just situations where other things where your system isn't

doing IK fix-up already to keep something planted during blending, like, i.e., oh, I

was, like, bending down to pick up this box, and it's, say, yay big.

Then you end up with these problems of, like, well, his arms are longer, so they actually

close further into the object than I was thinking, and so on.

But, again, like, you know, assuming that you can add those parts to your games because

you want to pick up different sized boxes or whatever, then you start to fix those automatically.

So that's typically the way the retargeting works.

I mean, there's always problems, like, if I'm, like, a man and I've got an animation

where I do that, if you now retarget me to a woman that's the same size, so she's got

the same length arms, but her shoulders are just closer together.

So instead of doing that, you now that.

It's just like, well, this.

The joints and everything are doing the right thing, and the joints are the right length

and stuff like that, but you just forward, and it's just like, what are you gonna do?

The woman's shoulders are narrower, but her arms are the same length, so it's gonna, yeah.

So there's always problems like this.

But, hey, for runtime, it's kind of fine.

If you want to do this properly, you do it offline.

There was some work a few years ago about retargeting physical simulation, like how,

you know, how things move differently when you've got longer bones or heavier or more

mass and stuff like that, and I assume the style-based guys are looking at, like, how

you retarget and kind of add, you know, remap the style aspects of the things, too.

But I was interested, actually, a question for Jeff, because you were saying basically

you can't reuse that many animations.

I assume mostly because of style-based things, like it's got to walk like a girl or a guy

or whatever.

So, like, what kinds, what percentage of your animations can you retarget versus you just

have to have new animations because the artists demand it?

We end up, because there's so many stylized, everything's caricatured a little bit, there's

a lot of stylized stuff, so the only things that get reused are really generic walks,

idols, but even idols become really explosive because you have the stylized idols for females

and different kinds of females and old ladies and things, so, yeah.

But that's where streaming comes in.

You go, oh, I know I only have these in, I'm going to stream, I have my little generic

bank that it plays until the stream is ready, and then we switch off.

Do you do practically none?

Practically none, yeah.

Some.

Luckily, we haven't had to deal with children, so, dogs and cats.

Dragons.

Yeah, dogs are going to be fun, aren't they, because they're going to be all different

sizes.

Yeah.

Wow.

Any other questions?

Don't do a pet simulator.

Oh, we've got one here.

I was just going to ask, there seems to be, the main method in which you blend influences

on the final outcome, the final motion is a linear blend.

Yes.

The problem we were talking about a little while ago with the stairs and so on and so

forth, have you thought of using any kind of obstacle avoidance, fuzzy kind of obstacle

avoidance, flocking type influences for nearby obstacles?

Is that something that could be built in or maybe done by a client programmer using a

system?

Well, first you've got to find the obstacles, right?

So, that's usually pretty expensive in most games.

But assuming you did that, yeah, I'm not sure how you'd do that because all of a sudden

you're actually pathfinding the foot around, and it's a 3D problem.

I mean, the vertical one is kind of constrained because you don't want to move it too abruptly,

but that seems kind of tough considering we're still having trouble getting guys to walk

from one end of the room without, you know, walking through stuff.

So, yeah, I guess you could do.

It seems heavier weight than you would expect.

Yeah.

It seems heavier weight than anyone needs at the moment.

But, yeah, kind of interesting.

The thing is with this is it's only on one of your foot spots that the target goes to

the other.

It's not a case of you have to go .

It's just that little clock the foot goes to.

I noticed that even with the lateness of the position of the foot on the other side of

the wall.

Yeah.

On the upstairs.

It didn't seem to me to be a great problem except the fact that the foot was then going

through the step.

Right.

And that, I was thinking, just totally, really, very, very localized to that.

Well, you can totally just draw a spline through the three points, either end point, which

are fixed, and this midpoint, and you just sort of kind of move the end point up and

down.

And here it's like, well, the only thing I can do is move it up.

So, yep, still colliding, still colliding.

Oh, hey, look.

There it is.

Although, there's probably an explicit way to do that, as well.

You know, I'm sure.

Quadratic spline and make sure it avoids this point.

So, there's probably an explicit expression for that.

But yeah, yeah.

And that would just drop right in to the blend weights.

So, yeah.

Yeah.

A general thing in this is I've got a whole bunch of points.

whole bunch of like linear blends in this and in general linear blends in animation are rubbish

because they're they're discontinuous in the tangents in the gradients and in a lot of places

you can see them so you have a smooth step function which you can just like it's the magic

hey make c1 continuous although not that great because it you know if you've got a continuous

thing like that it sort of wiggles weirdly but at least it's c1 and that removes a lot of artifacts

um what i tried to do is not put any smooth steps in until it looked bad so i think i have one smooth

step in in there um and then the rest look fine which is kind of interesting because i expected

there to be more problems and it's just one function it's really easy but i i just wanted

to avoid putting it in uh and see how much i could get away with uh and and it is nice that that i

think i was at one or two uh compared to the like tens of ones i do anyway it was uh it was pretty

good

you

, just to go back to the retargeting for one second to offer a different data point to jeff's

um we just finished shipping halo and we have male and female marine characters in our game

we found we're able to retarget about 98 percent of that animation and no one notices because they

are military characters laden down with gear then the subtlety of those motions are lost unless you

have something like an idle animation but um it is possible to use retargeting in practice for

characters and even when you're looking at them up close obviously on a console you really need

to get in there and you need to get in there and you need to get in there and you need to get in

there and you need to get in there and you need to get in there and you need to get in there and you need to get in there

as much as that uh it's basically compression technique right so

yeah you you you put uh take a skinny hooker and put on the the big fat guy animation and it works

i mean as you said the feet placement's perfect uh it looks very bizarre any other questions why

don't we oh one more trial

another quick data point on the same kind of issue uh which is what we use in our games for

is an artist interaction layer for plugging in animations,

which allows them to retarget or share animations

or make more blend points as they deem needed.

So we have things like walk and run,

and by default the run is just a sped up walk,

and for characters where that looks fine,

it's good because it reduces the memory use.

The animators, if they want to make more data points

for a walk 45 degrees, things like that,

they can go in and create those extra animations.

Same thing with sharing, you know,

if you put animations from a male to a female,

by default they could just use all the animations

and then they go and plug in the ones

where they think it looks bad.

Is there like a mapping file

that says you use this animation as your map

and then you can fill it in in the script

or something like that?

Yeah, exactly.

Previous projects I've used just the simple naming scheme

like I mentioned.

If there's no thing called walk to run,

then it just goes, okay, I'll do it up.

Obviously as the combination space gets kind of big,

your file names get kind of big,

and the naming scheme,

the naming scheme's rubbish

and animators seem to be unable to spell,

which doesn't help.

Like the number of ways of spelling,

like I can't remember what it was.

We had like four different,

in this whole string thing it goes,

okay, well I didn't find that.

Let's look for this, which is the different spelling.

And it's just, I don't know, some, yeah, anyway.

So that's always fun, but.

Okay.

Probably pluggable stuff would obviously

be slightly more robust.

I think we'll take a break now

and get ready for the next talk.

Thank you very much, Tom.

And we'll try to start up again 11.15 or so.

Thank you, sir.

You all good?

I realize that we're behind schedule a little bit.