>>Chance: Hey, everybody,
and welcome back to the weekly Unreal Engine Livestream.
We are your Community Team. Iâm Chance.
This is Alexander, and we are now
presenting Jess Hider. >>Jess: Hi. >>Chance: Who is
going to be heading up our community management
efforts across Europe. Jess, tell us
a little bit about yourself. >>Jess: Okay.
I am a Scottish game developer. My games career started
using indie games for mobile platforms where I used
a lot of UE4, met you guys. After that, I did a little
bit of triple-A work working at 4J Studios on the console edition
of Minecraft, and now Iâm here. >>Chance: Awesome. We are super
glad to have you on the team. Weâre probably going to be
having her at all sorts of events across Europe. If youâre going to be
out and around, youâll find her at shows,
different meetups, and all across
our internet channels. Stop by and say hello,
be friends. Weâre going to hop
into the news really quick, and then weâll have
Laurent and Ray hop on and take us through
all the great animation things about
the Characters in Paragon. If we could do the monitors. >>Chance: Earlier this week,
we put out 4.10.2 Hotfix. This solves a number of issues that were still lingering around
after 4.10.1. If youâre still working on 4.10, we definitely recommend
you going to download it. Pull it down and see
if your fix is in here. See if it makes your life
infinitely better. We certainly hope so. Actually, give me
this whole keyboard. >>Alex: Oh, take the whole
keyboard. You ran over my foot! Iâve got to close the tabs.
>>Chance: Oops, wrong window. Let me get back over here. Sorry for rushing through news
a little bit. Laurent has got so much to show
today, so we want to make sure we can get it
all out there for you. Preview 2 for 4.11 is out.
As you know, Preview releases arenât
really for production work. However, this is a really
great place for you to get in and take a look at whatâs coming and help us find out
some of the issues with it so we can try
and get as much as we can in before it actually releases
in the coming weeks. Stevenâs team - theyâve got
a new post on the forums where you can check everything
thatâs been fixed in Preview 2. Download it;
tell us what you find. We are all ears. We canât wait until
the full release is out there, and you guys have been
instrumental in helping us make these as robust
and bulletproof as possible, so thank you. Unreal Match 3 is
a learning sample that we kicked off a few weeks
ago, right before the break. We had Lauren and Alan Noon
come on and talk about it. It started as an
Epic Friday project where Alan was working on
some mastering mechanics and it turned
into a full-on game. Itâs a learning example
that goes through a number of different aspects
of game development from in-app purchases,
C++, programming, Blueprint scripting,
building analytic packages - everything.
It is pretty solid, and not only is it available
for download in iOS, through the launcher
and the project files themselves there in Android,
all of the documentation Lauren has told me
have all come online now. If youâre looking at making
a mobile game, this is a really good one
for you to understand a lot of the different
specific things youâre going to want to keep
in mind working on mobile. But even if youâre just building
a game in Unreal Engine or you just want to get started and see what the process stem
to stern actually looks like, this is an extremely
valuable asset for you there. If you just want to play
a Match 3 game on your iPhone, itâs free right now in the App
Store, so go check it to. >>Alex: Itâs very addicting.
Fun fact - I talked to Lauren earlier. She just got feedback
from the UX Team, so sheâll be doing an update
and then explaining through some of that stuff
too in a future post. That should be really
good more information, and there is a postmortem. >>Chance: Even more learning.
>>Alex: Even more learning. >>Chance: Laurenâs got a great
postmortem about the process and how it all came together
on our blog as well, so Iâll be updating it
with links to all of the places you can get Unreal Match 3. Check it out
and let us know what you think. Next up, Jess and I
are actually going to be heading up to FIG Talks 2016
which is an extension of BFIG, which is Boston
Festival of Indie Games. Theyâre basically having
three different tracks, so itâs design, development,
and business at the Microsoft NERD Center
on Saturday. Weâre going to be presenting
a Why Unreal Engine? Weâre covering pretty much end
to end what Unreal Engine and Epic offers developers
and some of the great things that people are building
in the Engine. Itâll be a really good time. Weâre hoping that if youâre
at the show that you swing by. Even if youâre not planning
on coming to the show, we will be there
until Monday where Seth, our user group lead for
the Boston Unreal Engine Meetup is throwing an event
at the Jacob Wirth Restaurant there downtown.
Weâll be there with everybody. There are a lot of
UE developers locally that are going to show up. We canât wait to meet you all.
Bring us your projects. We really want to see
what youâre working on. Thereâs so much talent
in Boston. Every time Iâm there,
weâre just really blown away and excited to get back.
I encourage you to show up. Weâll be there, and we hope
to see you there too. Hereâs the Epic Unreal
Meet and Greet and Drink. Itâs all on Meetup.com where you can check out more
information about the event. Really quick, before we move on
to the next thing, I wanted to say something
about Meetup.com. Just to reiterate
from the past, we do a lot of sponsorships
for user groups that are all over the world,
and itâs growing. Weâre seeing organizers
and passionate UE developers everywhere
reach out to us and try to get connected
to others in their areas. We offer a full support package
for that whether itâs branding materials,
promotion - weâll even come to events just like what weâre
doing here in Boston. If thatâs something that
interests you, reach out to us. Find us on some of the number
of avenues that are out there. There are some Twitter names
across the bottom here. Feel free to hit us up.
Weâre more than happy to work with anybody thatâs willing
to organize something locally. We think itâs super awesome, and weâd love to come
visit you when we can. The last thing we wanted to
bring up here for the news today is the Virtual
Reality Hackathon in Brussels. I think weâre going to be there. I think Osman is going
and maybe Tom Looman are both going to be there
this weekend. I think it starts tomorrow
and goes through the weekend. If youâre in the area,
definitely get in touch with Osman, Tom, or even Juan,
the organizer there. Weâre hopefully going to be
doing a little bit more in that space for the greater
Brussels community, if you will. Apparently, itâs pretty easy
to get there from the surrounding countries. If youâre there, reach out
and find one of us, or if youâre a developer
in Brussels, reach out to me
or somebody else on this team. Weâre happy to get you
plugged into others in the area. Iâm actually really upset that
weâre not able to go to that, because that sounds
like so much fun. But at the same time, Boston
is going to be a lot of fun too. It always comes down
to these things where they happen
to be on the same day and weâve got to make
those tough decisions. >>Alex: We only have so many
Chance clones. Iâm so sorry. >>Chance: Yeah,
two of my clones right now are upstairs writing things
and monitoring the chat, and then here I am. What did you do with
the other one, the fourth one? >>Alex: Shh, he died.
Yeah, sorry. >>Chance: Letâs hop over to
the Community Spotlight really quick before we talk about some of the great
things community is doing. For anybody thatâs new,
every week we try to highlight some of the coolest projects that have come across our radar
for the week. We always encourage people
to reach out and show us
what theyâre working on. Thatâs how you end up on here, and weâve got a running list
of them on the forums as well if you want to see what
weâve highlighted in the past. Thereâs a number of you
in the chat that weâve shown off
your project before. Alex is going to take us
through what weâve got now. >>Alex: Sure. First thing up is
we have the top Karma earner of the week on AnswerHub. First thing isn't on the screen. Top 3 Karma earners of the week.
Cancel, a first-time winner. Moss and Devils D,
both of you already have badges, but Cancel is getting
a new badge. Congratulations on that.
Good work. Thank you everybody else on
the list who is trying for it. Youâre going to have to fight
pretty hard, though. These guys are
pretty competitive. >>Chance: Well, itâs funny. Iâm
looking at the list here too. Weâve got a number of really
high earners in the past. I can see Horacio on there. Hey, Horacio. Pretty much hop
on the Answer Hub. We really love seeing the
community help each other out. Thatâs what makes it so great. We have so many people that are
willing to support each other. Itâs humbling to us.
Thanks for all the hard work. >>Alex: Thank you guys
so much for coming on and being out there
with everyone. Onto the actual thing. This actually kind of
happened pretty quickly last night.
BananaKing932, Chris Robertson. >>Chance: Oh, I thought you were
saying last night at 9:32. [LAUGHTER] >>Alex: No it was probably
around 10:30 or something. He and I were talking yesterday
and he said, hey, I know you have OSVR.
Iâve precompiled the plugin. They have
a 13-minute video instructional guide of how to install
their version of it. But heâs gone on
and just precompiled it and is now giving it out. It makes it a lot more plug
and play. If youâre using OSVR,
itâs super easy now. Thank you so much. Heâs updating it for 4.10
and all that, too. Heâs also in here making updates
as he goes along. If you are someone
who is interested in VR and you were one of the people
who got an OSVR because they were 350... >>Chance: âBecause Iâm not
some god like figure like our âHero of the Peoleâ
Michael Allar.â Iâm reading his... >>Alex: Yeah, he mentions
Kitatus. Heâs talking about
all you guys out there that are always in the chat.
Thank you so much. Good work. Next up, weâve got
a Loading Screen tutorial. This oneâs actually
relatively new. Itâs a proper C++
tutorial series, a really long tutorial of hereâs
how you go through it, how you can do
a nice loading screen. Itâs pretty straightforward,
which is what I like. You can just go in, read it.
Heâs got a great description. This was written
by James Baxter. Thank you so much for
making this awesome tutorial. >>Chance: Yeah, itâs funny.
I get asked that a bit too. Itâs like, hey, I want to build
a proper loading screen; do you have
any resources for it? >>Alex: Thatâs why I had
to highlight it. Itâs one of the most
common things that shows up. Itâs just, how do I make
a loading screen. Here you go. Really, really easy.
Thank you all so much. >>Chance: Thanks, James. Does that wrap up
for Community Spotlight? At this moment,
we are going to get over to the meaty conversation
of animation where weâre going to see
some really cool new features that are on the way.
We were poking around earlier. >>Alex: Yeah, I was having
fun poking at controls. >>Chance: Jess,
thanks for joining us. >>Jess: Thank you for having me. >>Chance: Iâm sure
youâll see her around. >>Jess: Yeah, come say hi if you
spot me anywhere in Europe. >>Chance: Take care.
>>Jess: See ya. >>Alex: This is why it's awesome
to have these mics. >>Chance: Then we can
sneak a few people in. >>Alex: They'll
hear you walking on. Such a great trailer. Iâve actually watched it
at home a few times too. >>Chance: This segment of these
4.11 Paragon tie-in streams has been what Iâve been excited
about for quite some time now. Jay Hosfelt and
Ray and Laurent and I have been talking about this for a couple months now since
before the end of the year. This, for me, Animation and AI are the two
parts of game development that I know the least about,
so every time I see tools that make that process easier
or more intuitive for me, itâs huge. I really canât wait to see
what weâre going to get into. >>Laurent: Yeah, animation
is very visual, so itâs always nice to see
you have some subjects or a lot of theory or math
or something very abstract. But animation is visual.
You can see it. Itâs always
interesting to watch. >>Chance: Absolutely. I know that youâve got
a project currently loaded. I think itâs down there
at the bottom. >>Laurent: Perfect. Before we
start showing any gameplay, I kind of want to explain
the goals that we had. Obviously, when you do animation
for a game, the game will dictate
what youâre trying to achieve, your constraints,
your limitations. Working on Gears
or Fortnite or Paragon, these goals are very,
very different. >>Chance: I can imagine. >>Laurent: Itâs important
to start by sort of framing what weâre trying to achieve and what kinds of limitations
we had. That will explain
the choices that we made. The first one
was next-gen quality. When you look at Paragon,
everything looks fantastic. We have very talented people. We had the stream
on Character rendering. It looks fantastic.
The World looks fantastic. The Characters look fantastic. Weâre trying to match
that level of quality. They raised the bar so high. We want animation
that matches that. The number one goal
was trying to get something that was really next-gen
and have that look. The second one
was high performance. Paragon we wanted to run
on a lot of hardware, very different hardware.
Itâs not only for high-end PCs, so performance
is very important. The third one is we have
a very small team, so we want something
thatâs fairly quick to author. We donât have just
a single hero. Itâs not Gears
where you have Marcus and thatâs who you play
throughout the entire game. You have many heroes. Theyâre all very unique,
and we have many of them, so we canât spend too much time
on a single hero. We have to be able
to go really fast. We want high quality,
but at the same time, we want very short time frames to achieve that
with a fairly small team. We donât have hundreds
of animators or programmers dedicated to just animation.
It has to be efficient. The last one is -- What weâre going to show and what we did is purely
cosmetic, purely visual. We donât want animation
to get in the way of gameplay and controls. I have a lot of games that can
play with motion animations. For example,
they can take away control to play a nice transition
or a recovery. We donât want to do any of that. We still have abilities
that the heroes can do, and in some cases,
when you do a leap or a jump, weâll take control away
from the player for these. But as far
as regular look motion, just running around and jumping
and moving through the Level, animation
is purely cosmetic there. These are the constraints
that we had, and the goals. Traditionally, our animations
have been fairly simple in terms of number of clips
that we used. We would typically
just one idle animation when youâre not moving, and then a loop of a jog
when youâre in motion. We just do a simple crossfading
between them, very simple stuff. Thatâs how we did it
in Gears of War, and thatâs how weâre doing it
in Fortnite. To try to bring that to make it
a bit more complex and interesting,
we had layers on top of that. We have a lot of additive
animations that will play. Weâll have deep dips and leans and weâll try to simulate
getting into a run by doing a little lean
and a dip and a stop. >>Chance: Got it, so itâs not
just like two states youâre blending between or even
three states. Youâve got other little
modifiers too. >>Laurent: You have a base of a
static idle and then your jog, and then you do the crossfading
on top of that. You add additive animation
to it even more, complexity. But these tend to stack up quite
a bit and be kind of complex. When you have so many layers,
itâs hard to control the output, the quality that you have.
For us, next-gen meant that we wanted
a lot of organic motions. We want some anticipation
in recovery. When you do a jump,
before you do your jump, you sort of crunch.
Then you do the jump. Then when you land,
you have this little compression and recovery phase.
When you look at any action, you always have
a little anticipation when you prepare to do that. Then you do your action,
and then you have the recovery. Typically, in the past,
we cut that all out completely. You end up with animations that
just donât look very realistic. >>Alex: Yeah, they feel
like a video game. >>Laurent: Yeah. We wanted
to try to focus on that. Iâll show quickly a video of
kind of how things were before. Thatâs the hero
weâll be talking about today. This is Kallari. What you see here
is really what we had before we started
any of this work. You see thereâs basically
the idle, and then you have the jog
forward locomotion loop, and thereâs a crossfade
in between. Itâs not very grounded.
You see when she starts and stops
the feed slide a little bit. Thereâs really no anticipation
and no recovery there. Itâs very stiff. >>Chance: Yeah, itâs clear that itâs two
states youâre looking at. >>Laurent: Yeah,
and that was fine 10 years ago. But 2016, we want to do
something a little better to match just the quality
and visuals of Paragon. I will show that again
at the end. Itâs a nice comparison
of kind of where we were and where we got to. The strategy
that we used on this, we wanted to reduce the number
of layers that we use. This adds a lot of complexity, and itâs really hard to control
the final look of the Character. When you have so many layers
and so many steps, itâs easy for them to not
play well with each other. Additive animation
has that problem. It can look good when you
author it on a certain base, but if you change that, you have
unnatural bends, rotations. >>Ray: I think an example of
that, during pre-production, we did a lot of layers,
very few anims. We would say have an additive
layer if you run a slope. Then we would have
an additive layer that would play
if you started to run. Those two would combine.
Then say you jump. Weâd have an additive layer
that compressed you. So all three or four
of these things would combine and suddenly youâd see
an arm start to turn weird or youâd see a knee turning
funny because things would just -- all those things would pile up.
Theyâd all look good. >>Chance: Youâre instructing all
of these different bones to do different things that theyâre not necessarily
expecting, right? >>Ray: Yeah, everything is
just getting added up, added up, added up.
>>Alex: The rotation is going to -- you eventually get
sort of a weird yaw or something. >>Ray: It could be. >>Laurent: Yeah,
and every piece is very fragile and requires a lot of tinkering
to get it to look right. When you have something
that looks bad in a game, you have a bug and you need
to fix and improve it, itâs pretty complex
to track down just what was wrong about it. When you have no layers
or very little, itâs a lot easier
to deal with that. Pretty much when
you author animation, what you author
is what youâll see in-game. You wonât have a lot
of additional steps in between. Itâs easier to correct
and improve it. We wanted to do that, basically,
reduce the complexity. At least from the animatorâs
point of view, what they do is Maya is what theyâll
get in-game as much as possible. We wanted to add a lot of frames
before and after these actions. More anticipation,
more recovery, a lot more transitions,
try to get the organic and realistic motion
that humans have. >>Alex: It's very fluid. >>Laurent: Yeah. Thatâs what makes
I think animation more next-gen, is having these types of things. We wanted to try to have
longer cycles too. Weâve always done
one cycle for jog. Itâs very repetitive. We tried to play additives
to try to mix it up. But nothing beats
mocapping a real actor and getting many cycles. We tried to shoot for four.
In some cases, we made it. In other cases,
it was difficult. But tried to do that
as much as possible, and then use mocap
as much as possible. Itâs super easy when youâre
dealing with human bipeds, but Paragon is a game where weâll have
very different heroes. >>Alex: Yeah, youâve got some
monstrous-looking guys in there. >>Laurent: Yeah, and
you canât always mocap that. As much as possible,
weâll try to. And where we canât,
weâll try to use inspiration or have a model to create this sort of
anticipation or recovery again. The first step that we did
is do a big mocap session. Thatâs the very first thing
we did on that Character. We planned out
a big list of moves. We planned it very quickly.
It was only a couple of days when we decided we need
to do a mocap shoot for this. >>Chance: You were the
model, right? >>Laurent: No.
[LAUGHTER] I wish. No, I don't know actually, because we did
some scary things. >>Ray: It was Melissa May,
right? >>Laurent: Yeah.
>>Chance: Awesome. >>Laurent: We wanted to capture
her going up and down slopes, and so we tried
to put a platform, but we had no real platform
to do that. >>Ray: Itâs like eight by
eight. Itâs what was used
for the trucks in Gears 2. They had these inner tubes
they bounced it on, so itâs a big eight
by eight platform. We just stood it up, and then it basically has poles
coming through each side. We just put them
in the rungs of a ladder, so it was the
most sketchiest -- >>Laurent: Unstable. >>Ray: -- thing anyoneâs
ever stood on ever. >>Chance: Ehh, it worked.
>>Laurent: You were at the end, if she would fall,
you were ready to catch her. >>Ray: I just stood back there
because she would sprint backward up
this crazy, rickety... >>Laurent: Youâve got to sprint
backwards up that thing. >>Ray: But it was great. I got some of the best stuff
I think in the game. I love it when
the slope animations play, because you just feel it. Itâs so much more physical now
when they hit, and it grounds them in the world.
Because theyâll hit a slope and then start digging in
to climb a slope. I think itâs one
of the best things we did. >>Laurent: Yeah, a lot of
that realistic next-gen feel is really in the details. I think motion capture,
you capture that very easily. Trying to reproduce it by hand
is very, very difficult. Itâs also very time-intensive,
and we want to be fast here. We want to avoid tinkering
forever on small details if we can capture
that right away. >>Chance: Especially when
you say small details, theyâre like
the biggest thing, right? Youâre going to want to
prioritize them at some level, so however you can make
that more efficient. >>Laurent: Now weâll get to look
at a bit of gameplay, what weâve done. The first thing that weâve
tackled is our transitions. For start and stop transitions, our idea was to
do motion prediction. Basically, weâre trying
to predict where
the Character is going to stop. In a game, when you move around,
youâre just that capsule. This is what moves in the game. The Character is, as we said,
purely cosmetic. Itâs kind of a layer
that plays on top. What you move around
is this capsule. What weâre trying to do is
predict when itâs going to stop. You see the red sphere. This is predicting the location
of the stop. When we start,
we leave a green sphere, and this is where we started. Essentially, for the stop,
weâre looking ahead. Weâre predicting
where youâre going to stop and weâre looking ahead. That gives us a few frames to do
the anticipation for the stop. When we do the start,
we drop the marker and we look backwards.
We look back in time and for the stop,
we look ahead in time. When we do pivoting, the purple
is basically the pivoting point. We see that we look ahead
a little bit and then we look
back quite a bit. We basically predict the motion
the Character does and we place these markers
in the world. We do the same for jumps.
We predict the apex, thatâs the purple, and the red
is the landing point. Very easy stuff. Purple apex,
and the red is the landing. A good way to think about that is weâre dropping these
marker locations in the world, and then weâre using them
to synchronize our animations. >>Chance: Itâs kind of
like a new node of data that you didnât calculate
distances and rotations, right? >>Laurent: Yeah, so looking
at our start transition, this is the start forward
that we use. We recorded the motion
of the actor in the studio. Just like with Root Motion, if youâre familiar
with the term, itâs really just Root Motion. What we did is we translated the
physical movement into a curve. We have it here.
We call it a Distance Curve. In the case
of a start transition, youâre looking back in time
at where that marker was. That Curve describes
the distance of the Actor to that marker. When you start
the distance is zero. Thatâs what the curve indicates. As you go forward,
increase the distance. At the end, we reach 500 units.
Thatâs about five meters. We mocapped our start transition
to be a distance of five meters. You see in the start, we have
a little bit of anticipation. Then we sort of build
into that jog speed. The stop transition is very
similar, except the stop, instead of looking back
in time, youâre looking ahead. When we start,
we have about 105 units, so about a meter away.
Then we go all the way to zero when we reach that marker,
basically. You see we have
a little bit of distance from the anticipation
to the stop. Then the rest is just
a recovery after that. Pivoting is a combination
of both, because you reach a point
and then you leave that point. In that case, the Distance Curve
is going to stop being negative. Here we have about
60 centimeters before you hit
your pivoting point. Thatâs where you go
into your stop, and then you push away. For this one, we have about
three meters away from that. Weâre really synchronizing
the animation to the movement
of the capsule in the game. When we recalled the actor
in the studio, the actor has its own speed
and acceleration. In a game,
itâs obviously different. Weâre trying to remap the motion and we record it to the motion
thatâs in the game. When we do this,
by using the distance, we get really precise
foot placement, no foot sliding at all. But the flipside of that
is we play the animation either a little faster
or a little slower because both speeds
donât match exactly. >>Ray: For people who are
familiar with Root Motion, basically the animation
tells the capsule where to go. If I crossed the room
in the animation, the capsule will just follow
the animation along. This kind of flips
that on its head. Basically, the capsule
is going to cross the room, and then it looks at
that curve to say, at what point across the room
am I in this animation? Then it plays that frame. It uses the motion of the
capsule to pick which frame to play in the animation. Basically,
the animation stays locked to what the capsule
is doing movement-wise. If the capsule is sitting still
and then starts moving forward, the animation says, okay, Iâm
two units from where I started; Iâll find that on this Curve
and play that frame. When Iâm 100 units away,
Iâll play the frame that... >>Chance: Itâs predictive, right?
>>Ray: Yeah, right. >>Laurent: You can see the start
and the stop in there. If you remember the video
we showed earlier, itâs a huge difference. The Character feels
a lot more grounded. We donât have this crossfade
between the idle and the loop
causing the foot sliding. On the way back,
we get a little step to stop, and then a nice shift
in the body. A nice anticipation
and recovery there. We get the same
when we do pivoting. See, she kicks her leg out
and then pushes out of the way. Thatâs the kind of detail
that that gives us. Weâll get back into
trying to match both girls and playing the animation
a bit faster and slower. We use Speed Warping
to solve that. Weâll go in detail
about that in a little bit. The next thing that I want
to talk about is synchronization markers. Basically, when we go
from our start transition into our looping
locomotion animations. To make that seamless, we put markers on the animation
for where each foot is. If we look at our looping
animation for the jog forward, we have about three
or four cycles in there. You can see these
green markers here. Right, left, right, left. This is where basically
the foot crosses with the hip of the Character,
basically. The right foot goes through
and then the left goes through, and so on. What we've used here -- Actually let me see
if I can show the bones. We look at the toe bone. Itâs this one, when it crosses
the root bone of the Character. We do this for every foot
thatâs on the ground, every passing foot
on the ground. The reason for doing it that way
is this sort of tells us spatially where the foot is, and we can
synchronize animations that way. We thought about this, and a lot of people
seem to describe the movement as when the foot touches
the ground and leaves the ground, sort of like
the amplitude of the step. We decided to go instead
with spatially where it was around the player
to minimize foot sliding. When you transition
between animations, weâll sort of try to get
the closest position to where the capsule is,
basically, to minimize sliding. We sacrifice a bit
where the foot is, in terms of being up in the air
or down on the ground. But we try to keep the position
in the World to minimize foot sliding. >>Ray: Basically, we favor its
position relative to the hips, then where it is in the cycle. >>Laurent: Exactly. >>Ray: The hips may be down
on this one, or they may be up
on the other one, but if the foot is
in the same position, we choose that so that foot
doesnât slide. Even though it may slightly
fight with the overall motion of the arms or the hips,
the feet wonât stay locked. >>Laurent: It seems to work really
well, and itâs a lot simpler because we just have --
for one cycle, you just have two markers
every time. >>Ray: This has been just such
a huge feature for us, because in the past in Gears, all the jog anims
that needed to blend together needed to be the same length
so that they could be synced. Now, this has a three-cycle jog.
Jog left may be one cycle. Jog backward
might be two cycles, and it matches everything up
using these feet markers. >>Chance: It allows you to be
much more flexible and loose when youâre designing
the animations. >>Ray: Especially when
weâre mocapping a lot of stuff, because we can kind of
take what the mocap gives us. If the mocap gives us
three good cycles, great. If it gives us one,
thatâs not the best, but it will still work
with the other ones. Where before, if we could only get one good
cycle of jog backwards, that really meant
we only had one good cycle of any other direction
regardless of how it looked. >>Laurent: Thatâs the start
transition and basically, we start, stopped,
and when we pick up speed and we go transition
into our jog loop. We have these feet markers, and that allows us
to find a good spot in the loop to transition
so itâs completely seamless. We use this for pretty much
all of our transitions. Well, the ones that go to
and from the looping. >>Ray: Again,
this is a big difference of how it has been before. Because before, we would need
to get out of that transition as quickly as possible
because you need to get the jog forward
out of jog forward start, because from jog forward, we may
branch into any other direction or anything like that.
But since we have sync markers, we can slowly crossfade
into jog forward or into any other direction. >>Chance: And it doesn't care.
>>Ray: No. >>Laurent: Yeah, so the pivoting
is the same. Thatâs basically what we used
to connect our transitions to our looping,
locomotion cycle. This is a feature that Martin
Wilson in the UK worked on, so a little shout out to him. Martin Wilson,
thank you for your help. Itâs a great feature. Weâve been
wanting that for a long time. Itâs great to finally have it. After that, the next
thing we'll look at is -- Weâll come back to locomotion
in a little bit. First, I want
to show Turn In Place. Turn In Place we use
basically the same technique. We use the same Distance Curve,
except here itâs not distance, but itâs rotation angle. We have 90 degrees left
and right. We rotate the head first,
and then the body will catch up. We have more of a lag
on the 90 degrees. When we go to the 180s,
itâs a lot more responsive. Sheâll turn it a lot faster
in that case. >>Chance: Yeah, because clearly
the player wants to turn and look that way
right now, right? I like that the head tracks almost exactly one to one, just a little bit of lag
behind the Camera. >>Laurent: Yeah, there is a very
small lag on the head, barely. Then the turn lags a little bit.
The setup for that stuff -- Basically, your Distance Curve describes the angle remaining.
Here we have minus 90 degrees. Thatâs a 90-degree turn.
Then we go all the way to zero. Again, we start the animation
with Root Motion where we have the turn. We back it out, and then
we translate into this curve. We could use Root Motion as is, but that curve
is an optimization. Itâs easier to work with. We know how much
turn you have left. We know when you are finished
with your turn. >>Ray: It may be interesting
just to play the animation in show the perspective
so people can see this is what actually gets brought
into the Engine as a turn. The curve that you see down
there is us basically backing, counter-rotating
the Character out so that they basically do
that little shuffle instead of physically turn. >>Laurent: We back out the head
turn as well, and that is procedural
in the game. >>Ray: Basically,
the capsule turns and we use that curve
to sort of sync them up. >>Chance: At the same time.
>>Ray: Right. As the capsuleâs turning, it basically puts
the rotation motion back in it that we pull out of it Maya. That curve,
it might be interesting also -- the Distance Curve
that you see down there is just a custom attribute on the root bone
of the Characterâs rig. Then for people
who have used the art tool that ships with UE4, I just take one of
the Offset nodes, back that rotation
out of the Character, and then copy that curve to this
custom attribute on the root. It just gets imported into UE4. Thereâs a checked box
on the FBX import that says, âImport Custom Attributes."
Itâs just like that. Thereâs no work
or anything extra. >>Laurent: Yeah, and before
we had restrictions where the rotation
had to be constant. That curve would be linear,
and thatâs not very organic. Here, we just stick
with what the mocap does, and we can use it. You can see thereâs almost
no turning in the beginning. Thatâs going to be
your anticipation frames where we prepare the turn, and then we do the turn,
and then we slow down and we have the recovery phase
after that. You see the movement
in the hips. The way that weâve set it up
is as soon as you finish a turn, your angle reaches zero,
we go into a different state. Weâll show this State Machine
a bit more in detail. Basically, you go from your idle
into your TurnInPlace, and thatâs going to be
your active turn. As soon as you enter
the recovery phase, weâll go in the recovery state.
This one can be interrupted. If you change your mind, and just to make
the rotations more responsive, we can abort the recovery and then
take another turn right after. >>Ray: Having a long recovery
on a turn is something
weâve never had before. >>Laurent: Yeah. >>Ray: Thatâs something
you just try to get through as fast as possible, because theyâre going
to do something else. >>Laurent: Thatâs the Character
thatâs not directly aiming with a weapon, so we made the turns lag
a bit more. But you could make them
more responsive, and then the interruption
would matter a lot more to increase
the responsiveness. Thatâs what we have
for TurnInPlace. Then the extension of that
is we do turns and we tolerate quit a bit
of lag before you catch up. What we added
is spin transitions. If you start moving
before you turn, then we have this
spin transition where you do a turn
while moving. We mocapped forward and back,
clockwise and counterclockwise. You do these little spins.
The setup for these is basically a combination
of what weâve seen so far. We have a Distance Curve
that we use for the turns. Then we have
the synchronization markers that we use to go
from the jog back into the jog. You can see that we have
basically all of this here. Thereâs a couple jog cycles so
we can come into this animation. Then we have the turn. Then we have a recovery phase
with a few cycles to branch back into the jog.
We have four of these forward and back and clockwise,
counterclockwise. >>Ray: This is definitely
one of those anims -- if you play that,
itâs hard to tell what youâre looking at
with the rotation backed out. That really doesnât look like
what you see in game because the rotation
is completely backed out of it. Sheâs actually changing
direction during that part, and thatâs just described
by that curve again. You see the curve goes 180
during that part where she makes
that weird sidestep. >>Laurent: Now weâll go back to
talking about Speed Warping. Initially, we mentioned
Speed Warping for transitions. We mocap an actor,
and heâs locomotion, so heâs speed and acceleration. Then the game has something
completely different. To minimize foot sliding, we try to use the animation
exactly as it is, but weâll play it
a bit slower or faster depending on what the capsule
does in the game. Playing animations faster
and slower looks really bad. You have very little range
that you can play with. Usually, you push it
to maybe 10 percent, and then after that,
it completely breaks apart. Even these 10 percents
you have to be careful with. >>Chance: One of
those that you just try it out a few times to kind of see
what you can get away with? >>Laurent: Yeah, itâs funny
because when we did our mocap, we decided to take the Actor
and record her on a treadmill. We wanted to sort of study
how she would change from a slow walk
into a jog and into a sprint. It was pretty slow. I think we did
that over two minutes. It was a really
slow progression. We wanted to study
how do you change that? How do you adapt? What we saw
is that her upper body didnât really change speed
all that much. Thereâs definitely
a little acceleration, but not a whole lot. What happens is the legs,
they tend to take bigger steps. This is a big difference.
Thatâs what we tried to do with Speed Warping essentially,
is instead of playing animations slower and faster,
weâre going to change instead the size of the steps
that you take procedurally. We will show a bunch
of examples of that. Thatâs essentially
the idea behind it. I have a video showing
the difference between Speed Warping and not. On the left here, you see
Speed Warping. On the right
is when we change the Play Rate. As we go to 1.5
and keep going up, it plays faster and faster. You reach very quickly
that hill phase, and then beyond
that itâs just unusable. When you slow down,
itâs the opposite. You completely freeze. Eventually,
you reach zero and you stop. You see with Speed Warping, youâre basically
jogging in place. This is one animation.
Itâs the same animation, and we just sort of stretch
the steps that youâre taking. That gives us a much
bigger range than we could get with just changing
the Play Rate of animation. >>Ray: A game like Paragon
or any game where the speed can change
dynamically because of a buff or because youâve killed
some jungle minion, that gives you extra speed
or something. >>Alex: It was just
hopping in place. >>Laurent: Thatâs a very
important point. Thereâs many things. Adapting the curve
that we do for transitions is one case where itâs useful. Changing speeds
dynamically in a game, [inaudible] change that, but design as
heroes change and get tweaked, you can get huge speed changes.
Without a system like that, that means a lot of animations
have to be redone, and usually we donât have
the time to do that. >>Ray: No, that would be
a terrible email to get. After all the locomotion
is finished, oh, it needs to be
50 percent faster, 25 percent faster.
Oh, my goodness. >>Laurent: But at the same time, you donât want to get
in the way of design. If they need to make these
changes to make the game better, then we should support that. Thatâs a great tech to have,
because nobody stresses. Just try it. It will still look good.
Everybodyâs happy. Perfect. >>Chance: I don't know, Iâm kind of
liking this one on the right. >>Alex: That still has the
little fast legs. >>Ray: You can see like
at 2.0 and 3.0, you wouldnât really
animate it like that. But if itâs only going to be
on screen for 10, 15 seconds or something like that
and it will save us from having to make a whole other motion
set at that speed. >>Chance: You can get away with it.
>>Ray: You sort of start saying you're picking your battles. Maybe time would be better spent
working something that has more impact on design
or on gameplay or on the player. >>Laurent: Thereâs another case
where itâs really useful. Paragon can also be played
with a controller. You can also go much slower,
basically push on your stick. Youâll go much slower. That allows us to adapt
the animation dynamically, and we donât need to authorize
many different styles. This is not a silver bullet
where you do only one locomotion set
and you cover all cases, because it doesnât
change the style. Between a jog and a sprint
and a walk, your upper body will do
something very different. You still want different
locomotion sets for that. But for each set, this system
gives you a much greater range where you can use it.
With that, it would have to probably
double the locomotion sets we have just to support
all the speeds that we have in the game
plus the Controller [inaudible]. >>Alex: How expensive would you
say using warping as a technique is for systems? >>Laurent: Itâs not
expensive at all. Weâll go in a bit of details
of how it works. But the good news is the setup
that it uses is the setup that we require on all
the assets on the Marketplace. Itâs kind of a standard setup
that weâve had at Epic for many, many years.
I can show you quickly. Itâs a Post Processing node
that you just slot in your graph. This is our looping
locomotion state here. We have two main
locomotion styles. We have the travel
mode and we have the regular jog
for this Character. Itâs just a little node that we
place in there, Speed Warping. Essentially, what you tell it
to do is just scale, and then you also tell it
the direction of your scale. So the movement, direction,
and how much slower or faster you want it to be. Then itâs just Post Processing
from there. It uses our IK setup on this. We go into Wireframe like this. Basically, we have defined
what we require in the Marketplace assets
is IK bones. Basically, you have
an IK foot root bone. Then we have left
and right feet from there. These match exactly
the IK position of the legs. Thatâs the setup that we use
for Speed Warping. Now weâll go back to the video. Essentially,
here what you see in red is the original animation. What you see in blue
is the resulting animation. Here we do Speed Warping 2X, so the Character
moves twice as fast. Itâs kind of a two-step process. In Green, you see where
the IK should be ideally if you went twice as fast. We take the IK position
of the feet, and weâll just say youâll
travel twice that distance. Obviously in that case, it would
stretch the legs horribly. You see this sphere
in the middle is where the hips would end up if you were taking
this literally. >>Alex: So it would be
like constantly splitting. >>Laurent: Yes.
2X would be too much. >>Chance: Just like
that nightmare fuel that you get
from animation bugs. >>Laurent: But this is
a very naĂŻve goal. We just took the IK and you tell
them, travel twice the distance. We then try to pull the hips
a little bit towards these goals.
But then we do the opposite where we clamp the feet
and never stretch them. We have a hard rule
that itâs okay to compress a leg but never overextend it. We donât want to break the pose.
Thatâs what we do here. These would basically be
completely unreachable without breaking the pose,
basically. What that means essentially is you canât reach
your ideal targets, and so your feet spend
more time in the air. Thatâs convenient,
because thatâs what happens when you run faster and faster. Your feet spend less time
on the ground. It works great in that case.
Itâs very simple stuff, but that turned out
to be a huge timesaver. It helped quality
quite a bit as well. We used to be scared
of speed changes in games, and now we donât worry
about it anymore. >>Chance: Seems like a really
viable solution for it. I kind of wish you had recorded the moving
of the green IK scale. >>Laurent: Thereâs probably
a video somewhere. Another case where itâs useful -
the spin transition is a great example
of where Speed Warping shines. Again, we have a video
on the left that's without it. On the right,
itâs with Speed Warping. What we do here is we play at
about a third of our speed. We get this by not pressing
all the way on the game pad. One third. You see on the left, the whole
animation is slowed down because this is how
we can get it to not foot slide. But the downside is that
is slows down your turn as well. With Speed Warping, weâre
basically taking smaller steps so we donât slow down the turn. The transition plays
for the same amount. Weâre not slowing it down. Weâre just taking smaller steps
to not foot slide. >>Alex: It also eliminates
the moonwalk effect and you get kind of
a tiptoeing effect instead. Very natural. >>Ray: It looks like sheâs coming
up to a crosswalk jogging. >>Laurent: That
helps us quite a bit. When you look at the transition
like the start and stop and those kinds of transitions,
it eliminates these transitions playing a little too fast
or too slow. Weâre able to play them
on a regular speed. We just take smaller steps
when needed to have what we recovered
from the actor match what we have in the game,
basically. Itâs all dynamic,
so designers can come in and tweak the physics or whatever
top-speed acceleration. >>Chance: Iâm sure it makes
Rayâs life easier too. >>Ray: It definitely is
easier. When Laurent first sort of
started talking about this idea, I was a little bit skeptical,
just stretching out the legs. But itâs really the best option.
Itâs so much better, as you saw, than just speeding it up
or slowing it down. Because weâre doing
all of these extra transitions and things like that
for locomotion, if you only have one cycle jog
and thatâs it, then itâs not that bad
to do a walk, a jog, a run, and a sprint
and just have those on a continuum
that kind of blend together. But since we have three-cycle
jogs, four-cycle jogs, starts, stops, pivots - we canât do that for walk,
jog, run, sprint. The animation budget
starts growing. Producersâ hair starts falling
out, and Jay starts crying. >>Laurent: Gavin
starts laughing. >>Ray: Yeah,
Gavin starts laughing. >>Chance: I think Gavin
is still in the chat. I think heâs laughing
at the chat right now. >>Ray: This gives us that
sort of spectrum to play in without having to author
a spin transition when youâre running at half
speed and a spin transition when youâre sprinting. We can sort of stretch
these animations out, and itâs so much better
than just scaling the Play Rate. Scaling the Play Rate is something that
just drives animators crazy. On previous projects,
you had worked on something, three or four or five
or six months would go by, and then you would come around
back to it to do a little bit of polish and you see a designer
has sped all the animations up 400 percent
or something like that. Youâre just like,
oh my goodness. Seeing something other than
just adjusting the Play Rate of an animation
is a very nice thing. >>Laurent: What weâre
going to take a look at now is more of what we put into
our main locomotion loop. In this case, itâs a jog,
a jog forward. We have about three
or four cycles in there. This is the Blend Space
that we use for that. We added slopes in there,
so we have uphill and downhill, and then we added the leans.
In the past, leans is something that we used to do
with an additive, but we found that mocapping
you really get something that looks very different
and adds a ton, so we try to mocap it.
It looks better. One Blend Space
for one direction. We use four of these. If we go back to
our driving state, you see the four that we used. We have North,
East, South, West. Very easy. Each one we just provide
a lean angle, the slope, and then the Play Rate. We do Scale Rate a little bit.
We do want some of it. We donât want too much of it,
but we want a little bit. We can control how much
we want Speed Warping and how much we want Rate Scale.
If you jog faster, we want the arms
to swing a little bit faster. We control how much we want Speed Warping,
so you take bigger steps, and how much Rate Scale we do
so you run a little faster. Basically, each direction
is done with this Blend Space, leaning slope, Play Rate. Then we do Aim Offset,
so thatâs procedural rotation. We will support 90 degrees total before transitioning
to another direction. The Aim Offset actually supports
180 both ways, 360. Then weâll physically
rotate the animation by this 90-degree max
before we transition from North. Weâll go to East
and West and so on. We have the same
for all our actions. The reason we did it that way
instead of [inaudible], it would put
all our actions into a single Blend Space. The problem with that
is when you hit the diagonals, you have your feet at cross.
By doing this, we avoided it. Here weâll basically
just rotate it. Then when you change direction, thatâs where youâll transition
between your different states. >>Chance: Is there a building
in the background? >>Ray: Yeah, thatâs the default. >>Laurent: Epic Offices. >>Alex: Yeah, over to the
left, thatâs us. >>Laurent: I don't know if
you can reach that game pad. Itâs harder to show on
a keyboard and a lot easier to show on a game pad.
As I circle around, she will basically
do this sort of body shift. Thatâs when we go from North
to West and South and so on. But it helps us, eliminates
the crossing we have in between. It sort of gives it
a natural movement too. >>Ray: That
looks really nice. So before, basically we would
have say forward and left. Then as he would approach
that 45 degree, we would just start blending
those two, so you would get 50 percent
forward and 50 percent left. The legs would start
going through each other and it would just be
sometimes okay, and sometimes not so good. But this heâs actually
rotating forward right until he gets to 45
and just beyond it. Then he says, okay,
left can take over. Then he rotates left back
to that 45. We never have that
50 percent blend of a mess. I think it looks great. >>Laurent: The next
point is leans. We showed sloping,
so letâs show slopes in there. When we go up,
it just plays the slope uphill, and when we go down,
it plays downhill. When you go left and right,
we play our mocap leans. The slope is one
thatâs difficult to get multiple cycles.
We have only one cycle, otherwise our actor
would be dead. [LAUGHTER] But weâll see if we can get
a better ramp, I guess, try to get - >>Ray: Yeah, we have
a better ramp now. Itâs not as much fun
as it used to be. >>Laurent: Itâs fairly
straightforward. We do leans on the
four directions and the slopes
on the four directions. If we look at backwards,
for example, we go up, and we lean
and go down and so on. When you use your gamepad
and you sort of circle strafe, you have this nice
leaning motion that you get from having it
on all directions. Thatâs it for stop animations. The next bit that weâll talk
about it Slope Warping. Slope Warping is basically our support of slopes
through IK procedure. Switch to debugging so
we can see what this looks like. What you see here in red again
is the original pose. Blue is the resulting pose. I can also disable it
so you see. Thatâs how our animation
would be without it. Then when you enable it,
this is what it looks like. Itâs a big, big difference. Iâm going to disable it
for a bit so we can run around and see what it does. But we only have slope
animations for our loops, so when I start my start
transition, I donât have it. As soon as I hit the loop,
then I do have it. If I were to do pivot transition
on a slope, you see Iâm doing it
on a flat surface. Thatâs basically the animation
that we recorded. So when we enable Speed Warping, now weâre basically transforming
in real-time through IK and you have this nice pose. Debug,
this is what it looks like. The way it works
is similar to Speed Warping. We use the same IK setup
for the feet. We have two modes.
We have one thatâs super-fast. Basically, we use
the information of the capsule to tell us where the floor is. We want the orientation
and the distance. The capsule can give us that. Itâs not perfect,
but itâs good enough for speed. The high-quality mode
does traces on each foot, and we use that
to adjust the IK. What we do essentially - the little diamond
that you see in there is the IK roots for the foot.
We offset it to meet the floor. In yellow, the yellow ball
is basically the floor location, and the yellow arrow is the
orientation, is the normal one. Weâll basically use that
to offset the IK. >>Chance: You calculate
based on that normal? >>Laurent: Yeah, and rotate it. So weâll basically say we move
the feet to the floor location and weâll rotate the IK feet to match exactly
the orientation of that floor. Now, thatâs going to create
some stretching and overextension on the legs. So the next step
is to pull the hips. Again, we donât want
to break the pose. We allow compression, which is what
is happening on the left leg. The one thatâs up the slope
gets compressed a little bit, but the one thatâs down
the slope, we want to preserve it.
We donât want to break it. You see around the pelvis, the red is
the original location. The blue green
is the resulting one. We basically pull the hips
a few times to try to stabilize it
and not break the pose. This is again, a node that
is done as a Post Processing. So where we have our 2-bone IK
for the legs, we run it just before and we just have one of these
in the entire graph. Then we do the IK
for the legs right after. The thing thatâs really neat
about that system is itâs basically using the information
it finds from the animation. If we look at our Blend Space
that we had, this is our locomotion forward
Blend Space. Weâll show the IK foot root. This is the IK foot root
that we have in this. For our looping animation, itâs straight because itâs been
authored on the ground. Then when you go uphill,
you see it rotate up and then downhill rotate down. The Slope Warping now is
basically doing the difference to meet the current
slope of the game. If you have animations,
it will use what it has and it will just make up
the difference. >>Ray: That rotation on
the foot root is in content. I basically rotate that in Maya
as a way to say, this was the angle
that we had her running on. Then when he gets in here, itâs flat on all anims
except for these because these are the only ones
that we authored on a slope. That basically just saves
the slope that the person was on
for this from a raw. >>Chance: So a design
consideration there, you mocapped on the slopes that
match the scale of the slopes that you would have in the game? >>Laurent: No, we got as
much slope as we could safely without injuring anybody.
>>Ray: Safe-ishly. >>Chance: Then did you go through
and adjust those to match what the game was expecting? >>Laurent: No. Itâs done
with that node procedurally. >>Ray: You can see
itâs on a continuum. It could be a less-steep hill,
and itâs going to have a blend between the flat jog forward
and the slope jog forward. >>Laurent: I think here we got
about 25 percent. >>Ray: I think weâre 25
degrees. Which doesnât sound like much, but when youâre sprinting
backwards up on an eight-foot, itâs - >>Laurent: So the node will
make up the difference. If in the game
you have 30 degrees, then it will make up the 5 thatâs missing
from these animations. >>Alex: Itâs very interesting. >>Laurent: For the transitions,
we have [inaudible] only on the flats, so weâll do the full
30 degrees in that case. >>Alex: You said it kind
of detects the ground and helps you
with foot placement, but what if youâre close
to a ledge? Is that kind of calculated
as well so you wonât have a foot hanging over an edge
and that kind of weird floating? >>Laurent: No, you can have
a foot hanging. The capsule is what tells you
whether you are falling or not. So the animation
will have one foot hanging. When we do the traces, if you choose the expensive
option with the traces, thereâs a limit on it. If the ground is near,
youâll take a step down. If itâs way too far, then youâll
just have your foot in the air. If you use a capsule, then itâs
wherever the capsule tells us. The capsule tells us, youâre not falling;
youâre still on the ground. >>Chance: Right. But even so, when youâre looking at
some of these, that might be just
a really minute detail thatâs not necessarily
noticeable in those fringe cases that you would be so close that the trace
would be too far down, right? >>Ray: Those choices constantly have
to be made everywhere. For performance, do we have
the performance to do a trace for each foot?
Maybe not. >>Laurent: We might
be able to get it - >>Ray: You can probably get
right on the edge of that. >>Laurent: A case here
where weâre close enough. I donât do it. Thatâs the cheaper
version, though. This one is just the capsule, so you always have
a foot hanging there. The downside of the capsule
is when youâre at an edge like this, your foot does fly. Yeah, you do need to have
the traces for this one. >>Alex: So thereâs limitations to
that technique versus the other, but thereâs performance
tradeoffs that youâre making. >>Laurent: Yes, absolutely.
The cheap one with the capsule is not as precise,
but itâs cheaper. The one that has the traces
is way more. >>Alex: For each one, thatâs going
to be way more expensive, especially considering
how many Characters are going to be running around. >>Laurent: Right. >>Ray: Itâs a per Character,
I think. Itâs an issue that is a bigger
problem for larger Characters with wider stances. Sheâs relatively
a small Character and her feet are pretty close to where the
capsule is or the root origin is anyway most of the time
when sheâs standing still. But say a Character
with a really wide stance, that foot could be
hanging way out in space. Just like almost everything else
with this stuff, you sort of have to weigh four or five different things
and then - >>Chance: Make the tradeoffs. >>Ray: - make the cheapest,
fastest, best-looking tradeoff. >>Laurent: Weâll
jump very briefly because weâre starting
to run out of time. The jump was made a similar way
using Distance Curve. We broke our jump
in three parts. We had the takeoff,
the in-air apex, and then the landing.
So the Distance Curve tells us - we basically drop a marker
when you jump on the ground, and then we measure the distance
you are to this marker. We use it here to get a few
extra frames of compression. Because animation
runs after physics. When we know that youâre
jumping, itâs already too late. You are already jumping.
This allows us to compensate and have a few extra frames
of the feet on the ground. >>Ray: You can see in content, Iâm pushing her down
through the ground. In Maya, sheâs going below the
origin at the beginning of that. >>Laurent: Exactly,
so she starts above the ground and then she sinks
into the ground. We compensate for that.
In game, she will have her foot. >>Chance: Because the capsule
is moving, right? >>Ray: Right.
The capsule takes off instantly. I just lag her behind
just a little bit. I try to do it as much as I can,
and the designers were like, oh, the capsule and the shooting
overhead is still hitting her. But I try to do that
as much as possible so it feels as grounded
as we can make it. >>Laurent: If we slow it down, we'll be able to see as
we take a jump. >>Alex: Oh, cool. >>Laurent: We have a few more
frames where the feet connect. Itâs kind of hard to show that. If you look at the capsule -
letâs see if it works. The capsules basically leaves
right away and you see the feet stay
on the ground a bit longer. >>Ray: You can imagine
if the feet stayed level with the bottom of the capsule, how kind of weak
that jump would feel. She would just be lifted off the
ground instead of pushing off. >>Laurent: We also use
Distance Curve for the landing. Landing is similar. We put a marker
where youâre going to land, and then we use that
to synchronize your feet getting close to the ground. The arc is synchronized
with the apex. The Distance Curve is basically
how far before it and then once you go past it. Just like our transitions,
we look ahead and we look behind and we use that to synchronize
what the Character is doing. Then we have an additive. I think the mouse
is starting to die. >>Alex: Oh, wow. Yeah,
that happens every now and then. >>Laurent: We have an additive
animation that we play, and this plays on top
of anything in the game. Thatâs why we picked additive. If we were to do a jump
and then we land with pivot, it would play on top of the
pivot transition we have there. >>Ray: It gives us a nice
landing compression regardless of whether youâre running
when you land, whether youâre standing still, if youâre in the middle
of some transition like that. We still get a nice
landing compression. >>Chance: Helps it blend better. >>Ray: Yeah, because if we
didnât make it additive, we would have to make a landing
for jog forward, jog backward, left, right,
all this other stuff. By making an additive,
even though maybe the result isnât what you would have
animated exactly, you still get a nice feel to it without making tons
and tons of content. >>Laurent: Weâve got it playing
on top of pivot in this case, and standing still is
[inaudible]. I think that covers the jump. Another useful feature -
this is something that Ben Gallagher in the UK
worked on, is blend profiles. That allows us to, when we do
a blend between animations, have different speeds depending
on which bones youâre blending. Weâre using that to make
the feet align really quickly and then the upper body
really slowly. Typically, our feet will blend
twice as fast, so we have very responsive
foot placements. The upper body can lag and be smoother
and have longer interpolation. Iâm not going to spend
too much time on this, but we also have a system
to play upper body animations. The keyboard
is not working here. Your E is not working.
We wonât show this then. The last piece of tech
is AnimDynamics. We have a simple physics
simulation that runs. This Character doesnât have any,
so we canât really show it. >>Chance: Weâre actually
going to have Ben on I think
at some point in the future. >>Laurent: Yeah,
that would be ideal. >>Chance: Following this. We wanted to talk here now and then move back
into the more technical bits. >>Laurent: Yeah,
itâs really cool stuff. We use it for a lot of flappy bits and cloth and hair,
just a lot of physics things that you want
moving on Characters. Itâs cheap and itâs a node
that you drop, same thing as a Post Process
in your AnimGraph. >>Ray: Giving scale control.
>>Laurent: Yeah. The last thing is we can just quickly give an overview
of the AnimGraph, and then I think
weâll take questions after that. When weâre looking at this, weâre looking at it
kind of backwards. This is the resulting pose.
This is where you finish. When we take it
from the very beginning, we basically have
a locomotion state machine. Thatâs the starting point. We donât have
a whole lot of states. Itâs fairly simple. Idle, itâs obviously
an idle state. From there, we showed earlier
the TurnInPlace in the recovery. We have a few states,
your Stun and KnockedBack. Jumping is only one state. The recovery
is one once you land and you play the additive. When we go into
the locomotion bit, we have the start
transition here, and that leads into the jog,
and thatâs our main loop. From here,
we can go into a pivot, and itâs split into two. We have what happens
before you reach the pivot point and then what happens after. We broke them apart so you can
go back and forth if you wanted. Itâs kind of an edge case,
but we support it. Then the spin transition
is in there. From your loop, you can go
into the stop transition. Thatâs really all there is.
Itâs fairly simple. Each state
is extremely simple inside. The pivot we just feed
an animation in its position. Like the main locomotion loop,
we put an Aim Offset to get supporting
different angles and then we rotate
the animation. We rotate it up to 90 degrees
and then we have 4 directions. Thatâs about all there
is in every state. Itâs pretty much like that, except the looping one
that has all four directions. When you come out of that, basically we have a place
where we play the additive jump, so this plays
on top of everything. Coming out of the locomotion
state machine, weâll play the additive jump
on top of whatever comes out. After this, we have the setup for playing
upper body animations. We didnât show this.
Itâs basically split in half. We have one part where we play
additive animations, and thatâs on the full body. Itâs basically that state,
so itâs in MeshSpaceAdditive. Then we have a part
thatâs full body overrides, and that plays on the head
and the arms. When she does something
on the upper body, sheâll take out a knife
and hold it. Weâll have the additive
that will play on top of the full body,
except the legs. We take out the legs right here. Then the head and the hands
weâll take over completely. This will play the idle
or additive to make it seamless, so the same idle
would play on top of when youâre standing still, when youâre taking a turn,
when youâre stopping. All these sorts of stopped poses
will play that seamless idle. Here we handle
the main rotation. Thatâs what happens
when we TurnInPlace and do the spin transitions.
Weâll have the Aim Offset to cover the head
and torso rotation, and then we have a simple
rotate root bone to handle the angles,
the rotation angle. After that, we have
a few slots to play montages. This is mostly for our VTs.
We have upper body. We have a breakdown
if youâre moving or in place or in the air
or on the ground, different things
that you can do. We have a little override
for the jets that she has on her back.
It has its own state machine. It opens and closes.
Nice details. Hit reactions are additive.
Theyâre played here. The tentacles on the back
also have their own animation. We have some correctives
as well. Travel Mode we havenât shown
a whole lot, but we do share
a bunch of the animations from her regular set
and we have some additive to do some corrective poses
on top of that. Then itâs a bunch
of Skel Controls, so we use trails
for the tentacles that she has. We have Slope Warping
for the slopes, IK for the legs, and then thatâs it.
Thatâs the final pose. >>Alex: Wow, so it has to
basically add together so much just to get to that.
Itâs amazing. >>Laurent: Itâs so
much, but itâs a lot less than what
we had before. >>Ray: At any given moment, a lot of those nodes
have a weight of zero. >>Alex: Okay,
they are just ways you can interject correction into - >>Laurent: Yeah, exactly. >>Chance: Itâs the little
interfaces for you to say, nope, do this instead, or give it a little bit
more squash or stretch, right? >>Laurent: Yeah. We took
out the idle as an additive so you wouldnât see hard jitters
or transition issues when you went from the idle
to a turn, so thatâs separated
and seamless. But once you go
into your jog forward, youâre pretty much just playing
that, this IK processing. But thereâs no other layers
or other animation playing on top of that. And because we donât have
the Blend Space for doing the directions, we do a lot less blending
than traditionally. Itâs simpler. I think weâll take
some questions now. >>Alex: If you scroll down on
there, weâve got a few of them. >>Chance: Thereâs a
lot that came through that we had already answered, but feel free to grab from here.
Weâve got some time. >>Laurent: Do all players
share the same Skeleton, or do they have
their own Skeleton? They donât share. Thatâs a big
difference from Fortnite where they all shared
the same Skeleton and we could do
a lot of retargeting. Here, everything is
pretty much unique. >>Chance: Very different
Characters, right? >>Laurent: Yeah. >>Chance: Retargeting I think
would work, but I think you wouldnât get the effects
that you would want, right? >>Laurent: The Characters
are just so, in what they do and how they look
and their style - maybe down the road
if we have many Characters, weâll be able to share a bit. At the moment, thereâs really
no sharing going on, and not for a while. >>Chance: There are a number
on facial animations, but I think weâd have to touch
on that at another time. >>Laurent: Yeah,
I think facial stuff, weâll save it
for another stream. Thereâs a lot
to talk about there. >>Ray: We are using art, though. Thereâs a question there, are
you using art to do the face Character rigging? Weâre using art.
Same art that ships in UE4. >>Alex: Yup,
the art rigging tools. >>Ray: And the Distance Curves, all those things. Thereâs nothing custom in what
weâre doing with any of this. >>Laurent: If we use any special
techniques to solve intersections between rigid pieces of armor
on moving Characters? So it would be Blend Shapes,
in this case. >>Ray: Yeah, and probably
AnimDynamics, limits, and stuff like that
would probably - not sure when AnimDynamics
go out to the world. >>Laurent: I don't know. Youâll have a stream
about it soon. >>Chance: Weâll talk
with Ben more about it. >>Laurent: How do we set
priority animations when youâre getting hit,
still attacking? How do you choose which one
takes priority on the blend to be there all the time? Itâs basically
how the graph is set up. Thereâs an order to it, and you
choose what overrides what. In the case of hit reactions,
we show that. At the very end,
itâs an additive. It will play on everything
thatâs before it. If we play an animation
on that slot, for example, that will take over
everything thatâs before it. But hit reactions
will still play on top. Itâs just the way
that you create your graph. You decide what takes over what. >>Ray: Thatâs kind of a
design - That sort of
has design implications, a question like that.
Itâs partly up to design. Part of it is probably also
part of the Character. Sheâs a melee Character, so playing a small additive
on her during an attack is probably not going
to be that bad. But say a Character who needs
to have both hands on a weapon or a Character that needs to do some really
precise thing with a weapon, that may be a problem,
applying some hit react additive on top in the middle
of a complicated animation. >>Laurent: How are legs
on slope animated? Is this IK? Yes, most of the time.
The loop though, we showed, we have some author animations
for that. But we donât for everything
else, basically, all the transitions. IK takes over.
IK does whatâs not there. If the animation provides some,
weâll use it. If itâs not there,
then IK will take over. >>Chance: Then
youâll use IK for it. >>Laurent: Yeah. >>Ray: What is the bone limit?
We still explore that every day. Every new Character,
we test those boundaries. >>Laurent: From the test we made,
the bones doesnât seem to matter too much for performance, not as much as we thought,
at least. Itâs not our biggest concern
and focus right now. I would say our Characters
are probably from between 100 to 150 bones maybe. We try to stay
within that range. >>Ray: Some go
a little lower than that. But there are some that
have some complicated mechanical stuff. >>Laurent: Thatâs for
in-game, too. >>Chance: Weâve got time for maybe
two or three more, I think. Then we'll kick
off the game jam. >>Laurent: How many unique
animations do you typically have for a single Character? >>Ray: Again, thatâs really
dependent on the Character and what design sort of requests
that they do, how complicated some of
their attacks or their abilities or something like that. Is it just one fire
and forget thing, or does it require a whole set
of performing this action and needing to be able to walk
and fall and turn, and all that stuff? But say for Kallari,
I think weâre - goodness. >>Laurent: I would say
typically itâs over 100. >>Ray: Yeah, weâre
definitely over 100. I think locomotion alone is
like 75 or something like that. >>Alex: Is that just because youâre blending
in so many different things? >>Ray: We just have
tons of transitions. >>Laurent: Yeah, locomotion
is more of a known thing. Itâs the ability part
thatâs very variable, so it really depends there. >>Ray: I would say, if someone
said the budget for a Character was going to be 125, 130, 115, that would seem reasonable
for what weâre doing right now. Obviously itâs going
to be different for different Characters. Some Characters that need to be
100 percent keyframe for one reason or another, that budget is just going
to have to be cut, because itâs going to have to
go to down some. >>Chance: Yeah, and how detailed
different abilities are with the Characters is definitely going
to make a difference. >>Ray: Yeah, exactly. >>Laurent: Does the warping allow to mix two animations done
at different frames per second? Like one anim at 15 FPS
and the other at 20? Yes, it doesnât really matter
what FPS they have. I assume you mean
the Speed Warping. What matters there is the speed that the animation
was authored for. If we have in our case,
per state, we have only one speed. So we do Speed Warping
all the time pretty much unless youâre exactly
at that speed. If you had animations
that would cover a range, you would only use Speed Warping
outside of that range. But animations
can be any frame rate. It doesnât really matter. Any chance that
the Speed Warping node and any other additional ones will be exposed
to the generic 4.11 Engine? Speed Warping and Slope Warping,
definitely no. The other features
we talked about, Iâm not sure. I would say everything
will make it into the Engine at some point. We definitely want to give
Speed Warping and Slope Warping. When, I don't know. The marker sync,
the blend profiles, and the AnimDynamics have
all been done in the Engine, so they will be
available shortly. Itâs not 4.11.
It will be soon after. >>Chance: Right, 4.12 timeframe. >>Laurent: Slope Warping has not
been moved into the Engine yet, so weâll do that first.
More delays there. And when getting
the animation states, did you know exactly
all the states you were going
to have before creation or was the process
sort of experimental until all the animations
were covered? It was very much experimental. The Character we showed is
the first one we did for this. It was a big R and D. We spent about two months
working on that. When we did the mocap,
we sort of had an idea of we wanted the start, the stop, pivots,
and the leans, and the slopes. We kind of knew the scope
of what we wanted to do. But we had none of the tech
pretty much. >>Chance: Iâm sure too as far
as design goes, that might change,
that number as well. >>Laurent: Yeah. >>Chance: And what you expect. You might have to experiment
a little bit more. >>Laurent: I would say
the spin transition is one that came late.
We didnât have it originally. When we started playing
with turn transitions and adding more lag,
we realized that it would be useful
to have the spin transitions, so we mocapped that later. But yeah, it was very much
experimental in R and D. >>Chance: Cool.
Weâre going to move over and kick off the Game Jam here
in a sec, but thank you so much. >>Alex: Thank you guys.
Really great stuff. >>Chance: Really appreciate it. >>Ray: No problem.
>>Chance: Itâs super valuable. I canât wait to see more of
these features hit the Engine and see what the great community
ends up doing with them. >>Alex: Yeah, very powerful
animation tools. Itâs very cool. >>Chance: Itâs been a while
since we have had y'all on, so we are super glad
to have you back as well. Thanks again. Letâs go ahead
and kick off this Game Jam. Before you push the button
and update there, I just want to remind everybody
at home, the Game Jam kicks off now. Youâve got until
the end of the day Sunday. Youâve got until midnight
on Sunday to create something and package it up,
something in Unreal Engine 4. Package it up around the theme
and submit it to a submission thread
thatâs on there. Weâre about to push
the thread live. Thereâs a new submission
thread there and you have to download
all the rules there too. Thereâs Epic swag to be
given away, t-shirts to win. >>Alex: And of course,
Allor to be frustrated. So make sure that you tune
into Awesome Allor when he plays through
all of the Game Jam games, and you get to watch
his great frustration and enjoyment of various games. >>Chance: Itâs
always a lot of fun. He starts streaming
right at midnight afterwards, and usually by the time I get in the next day,
heâs still going. Feel free to tune it. I usually make it
until about 3:00 a.m. and then I pass
out with my phone. Weâre doing a new t-shirt
design as well. Our design team
has that right now. We may have
mentioned it last week. But thanks again
Phillip for helping us pioneer the Game Jams
with the t-shirt contest winning that,
the one weâve got here. Weâre just going to refresh it
for 2016 and moving forward. All right, now you can do it. >>Alex: Oh, now I can.
Okay, thanks. >>Chance: So we have it
loaded over here. Letâs go ahead and click
on that forum thread. Load it over
to the other screen. Scroll down just a little bit. >>Alex: There we go. >>Chance: And weâve got,
Donât Push the Button! >>Alex: Donât Push the Button!
Iâm psyched about this one. >>Chance: We were talking
about this earlier. There were so many ideas
that came out between Jess, Alex and I.
So make something awesome. Surprise us. I canât wait.
Itâs going to be fun. Also, we wanted
to remind everybody too, weâre going to be showing
the winners two weeks from now as opposed to one week from now,
so we can get good footage of everybodyâs game
for the highlight reel and spend a little bit
of extra time in the judging cycle
and everything so itâs not - >>Alex: Sometimes it feels
a little rushed. >>Chance: Kind of a little bit
of a madhouse around here for those first three days
coming back. Itâs the 28th livestream
weâll be announcing the winner. Tune in, everybody.
With that, thank you, Shelly. Thanks guys, thanks Alex.
Thanks Jess. Clint, youâre pretty cool too. All right everybody,
weâll see you next time. >>Alex: See you guys.
>>Ray: Bye.
Discussion: https://forums.unrealengine.com/showthread.php?97151