>>Jeremiah Grant: The title
of this talk is Making the Most
of Animation Blueprints, and kind of sub-title it with
Dynamic Motion in Fortnite. First off, who am I? I am a Senior Tech Animator
at Epic. I have been
working on Fortnite for about the last year,
year and a half. Previously I worked on Paragon, and a few movies
and other games. Either way, I have been
doing rigging, simulation, Character work. Gone by many titles;
Rigger, Creature TD, Technical Animator,
Character TD Technical Artist. They are all
kind of the same thing; creating simulation,
attaching verts to bones, and making them move good. Specifically, on Fortnite,
Tech Animator is creating the Skeletal Mesh,
doing the rigging, and adding the simulation
on top. Fortnite has been
in development for many years, and there is a kind
of a standard motion set on the Characters already, so the Skeleton is
pretty fixed for the biped. We have six body types, but they are all retargeted
on the same Skeleton. That is fixed. All other bones
that we want to add in, we do that later
on individual Skeletons, and I will go
over that in a bit. This talk is kind of broken up
into two parts; the first, I am just
going to go over, what is a Character in Fortnite? How do they all combine
and get assembled? Then I am going to go over
more of the dynamics and individual nodes, how we assemble those
and some specific settings, that might help you out,
hopefully. What is a Character? In this case we are
looking at a constructor, one of our Save
the World Characters. You see a body and a head,
some hair, an extra little robotic arm
and a backpack. Every Character is going to have
a head and a body, that is kind of
how we define our Characters. That can be kind of weird;
for instance, we had a banana Character
recently. Where is the head defined
on a banana? I do not know. But we got creative,
and it worked out. In this case,
the beard and hair, which we call
face accessories, those will have their own
Animation Blueprint, their own Skeleton. All of these will have their own
Skeleton Animation Blueprint, and will be combined
in right along. Diving in a little deeper, I kind of feel like our job
is moving just files around. These are all the files that
might make up the Character. We would probably consolidate
some of these, but again, every Character
is going to have hair, which hair, Skeleton,
Animation Blueprints and a data item,
or a data Asset. That data Asset,
which we call Character parts, contains references
to the Skel Mesh, the Animation Blueprints,
the master Skeleton -- which everything is targeted
on -- and a few other things. You can do Material overrides
and such on that. That is a whole other talk, just about those data
Assets as well. Zooming out a little further, we see what makes up
a Character in its completion. There is a Character
item definition, Hero Item Definition,
and Hero Specialization, and multiple Character parts.
All of those are data Assets, and all of those contain
some amount of information about what the Character is. Once we get
into Character parts, that is where as a Technical
Animator, we start working. We start adding in references
to our Animation Blueprints, or Skel Meshes, Skeletons,
and any other number of things. This can get quite complex, especially on something
like a progressive Character. We have a Viking Character
or a pirate Character, and those may have five
or ten different tiers -- all of those with individual
Skel Meshes, Skeletons, Animation Blueprints,
Character parts -- that gets quite unwieldy, and so carrying those all the
way across the finish line can be a bit of a challenge. How do we do that? Copy Pose from Mesh
is probably our go-to node, and in this case, that is what
gets all the animation from that invis Skeleton or that base Skeleton
onto our Characters. Every Skel Mesh that you see is an attachment
onto that base Skeleton. That way, we get the performance
of just running one Skeleton. Everything gets attached on, so on the servers you will
just see invisible Skeletons running around, and everything
is propagated locally. Some of the settings here
on the Copy Pose from Mesh is the Use Attached Parent, and that is actually
what gets the motion from that base Skeleton. That is what we use on nearly
every Animation Blueprint; this is how we start,
except for a few exceptions where we just attach
to a bone or a socket. That would be using
probably a sub-graph input, or something like that,
just for performance reasons. Copy Pose from Mesh
essentially does just bone mapping,
direct bone mapping, so the bone exists in the base
Skeleton or the parent Skeleton, and it exists
in the attachment Skeleton, then it will just drive
those directly. That way,
in your child Skeleton, you can add as many bones
as you need, drive those individually
with Anim Graph, and then you can get
layers of motion. That is really
where the work comes in. On a Character, again, we can
have tons of different things. Backpacks can take on various
shapes, sizes, motion sets -- all kinds of random things. Hair and beards
can practically be an entire
Character of their own. Clothing can be everything
from a giant skirt or dress to whatever we can --
to a banana, if you want. Danglies are just anything
that is hanging off, and danglies can be
on a pickaxe, it can be on here -- her hair would represent
some of that. The wings can have
dynamic simulation that would just
kind of be dangling. We layer all of those on. This gets really tricky
when we are talking about putting a Character across
a dozen different platforms, and still having them feel like
they are the same Character. If you spend real money
on a Character, you want to be able
to play that Character, whether it is on your phone,
or on the Switch, Xbox, PC. That becomes really trick
as a Technical Animator, to make that work. The way we approached it is,
you start from the bottom. You start with the lowest
common denominator. If you are doing a dress,
how can that dress, when everything gets LOD down, still feel and react like it
is part of that Character? When you are
on a mobile device, we are not actually using some
of the simulation libraries, like Rigid Bodies
and AnimDynamics,
and a couple of others. But we still have
a few other tools that we will get into later,
to get some of that motion. The key thing to think about is, peeling off these layers
of simulation, and still making it work,
like maybe just skinny two legs and adding some corrective bones
or some corrective shapes, and then adding a simulation
layer on top of that, which might be
another Skeleton -- not an actual Skeleton, but more bones
that can be LOD'd off and still pad
the skinning back up. The key of this, of course,
is test every LOD all the way through,
because you will see it. On some of our gameplay modes,
you can have 20 Characters, 50 Characters all in one place, and you may only have
three Characters that are LOD 1. The next tier --
LOD 2, the next tier -- LOD 3, and those can all be
on screen at the same time. They all have to look
pretty good, hopefully. With the most
complex graphs, if we are doing a lot of complex
evaluations in the event graph, then we would try and nativize that into code after the art
has been complete, and that gives us
a lot of performance. Let us dive into a node here. We are going to dive into
the Rigid Body a little bit. In this case, we have it on
a pickaxe, on this floppy shark. Here, I would not really
call this a dangly, though I think we do have
a dangle there on the rope. But we need to just kind of
have that rubbery feel, and we want
the Rigid Bodies here. I do not know if we can quite
see those numbers on there, but starting at the top,
that is where our physics Asset would be; though I think in this case
we would put the physics Asset on the Skel Mesh. Going into the gravity settings,
we are not using it here, but on most of our Characters, we actually explicitly
set the gravity. That allows us to control
the weight of the Asset. Kind of an odd legacy thing
that happened on Fortnite is, years ago, just as people
were messing around and kind of game
jamming the whole game, gravity got set to about
three times gravity. That is just now
how gravity is in Fortnite, so we are countering all that back
on our animation nodes, back to real-world gravity,
just to make things work. That was actually
a real challenge for us, because we could not figure out
why our Rigid Bodies were breaking
all the time; things were jittering
all the time. I have gone online
and I have read a lot of people have had
these same type of issues, and hopefully I can dive into
how to help that out a little. But setting gravity
explicitly helped a lot. Setting your simulation space
helps a lot. When you have a Character that is running around
in World Space, which here we do have it set
to World Space -- though we should
probably change that -- when you are in a vehicle and moving
at what unknown speed, everything is going to be
pulled away from your Character. You are not able to control it. Usually we simulate
either in component space, root bone space, or if you have a bunch
of dynamics on the shoulders, you might just do Spine 4,
Spine 5 space, and the infuse more motion
using that component linear acceleration scale
and component velocity scale Those, essentially infuse world
velocities back into the Asset. Danglies -- that is what
we are calling them here, because I do not know
what else to call them. We are looking at a couple
of different nodes here. We have the Trail Controller, the AnimDynamics nodes
and Constraints. I think Constraints are
a little newer in the Engine -- has anyone used them at all?
Excellent! I will talk about Constraints.
All they are is, you enter in kind of a parent's constraints,
or a barnacle, or rivets, if you are familiar
with any of those terms. It attaches an Object
to the surface, or wherever you place a bone, and then rides along
based off the percentages of the bones listed there. In this case
we have a ring and a skull, so a skull on the hip, which is weighted
100 percent to the skirt and 0 percent to the pelvis. It is parented to the skirt,
I suppose. You can drive those live. If you wanted to swap out
the kind of space switch, that skull, whenever a Character
does some specific motion, you could absolutely do that.
This has been crucial for us to get bullets
sitting on the chest, or some sort of layers
of simulation, and then something
that sits on top of that, and that thing on top
can have its own simulation. Since this is all
a linear process, you can layer these
in very specific ways to get the type of motion
that you want. Trail Controller is not
in the simulation library, which means that we can
use that on mobile. That has kind of been
our saving grace for everything, for capes
and for various Objects. I think in here we are using a little bit of
Trail Controller for -- the sword has some of it,
I think. That way, we can still get some of that life
in the Character as we peel away those layers,
and get down onto mobile. A Trail Controller
is a lag-based, positional-based node
where as you pull the -- it just comes right back to
Ref Pose over a period of time. You can define
how quickly that is. You can define a curve
as it finds its children, to how quickly
it returns draft pose. But the downside to that is,
you do not get any overlap, you do not get that
secondary motion that you need. You can combine
that with things like the Spring Controller, which is also not
in the simulation library, which works on mobile for us, and get that secondary motion
kind of layering on these. We also see AnimDynamics here. AnimDynamics, some people love
it, some people hate it. I love it. AnimDynamics
is essentially a pendulum; you are hanging a pendulum
off of a bone. The bigger
you make the body, the slower it will move. You can make it kind of
like a pancake, and it will just wobble.
You can alpha it on, you can do all kinds
of tricky things with this. I have a little bit in here,
where we talk about kind of being sneaky
and driving simulation, using different simulation nodes
to get exactly what we want. Let us dive into specific
Asset type, Backblings. Backblings encompass anything
that attaches to the back. In this case,
we have four different types. We have just kind
of a static backpack, a dynamic backpack, cape,
and some wings. They attach to a socket, so they will not be using
that Copy Pose from Mesh. They will probably be using
a sub-graph input. That means that they do not
know where the shoulders are; they cannot react
to how the spine bends. But we still needed to attach and feel like it
is grounded to the Character, and still r react
to the Character. That goes back
to selling that fantasy, being consistent
across all platforms. The backpack on the right,
the static one -- that is just geometry
and a bone. There is nothing fancy about it. The next one, we are seeing
some Rigid Bodies in action. Having it just kind of move
with the Character, we are able to simulate
in component space, and that just gives it
that feeling that it is
part of the Character. Since it is -- I think we are
driving in some of those forces; that component linear scale
and velocity scale, to make it so when you move
and run and twist, you can get specific motion. Since you have
each access available in those component scalers, you can say, only when I twist,
feed in more motion, or only when I move
on a vertical axis, feed in more motion.
You can get very specific about the type of motion
you want in there. The cape is -- I think here we are seeing it
as cloth solution, though we do use both cloth
and Trail Controller -- and I will go into that
a little bit more here next. The cloth solution
is a little tricky, because back
in the Character parts, we define what we call
cape colliders. A cape collider
is a base set of physics bodies that that cape
can collide against, and it just moves
to wherever those bones are. That allows us to collide
against a Character, but it is a little tricky
to get going at the first place. The wings are kind of
the most complex here, because they have
an entire state machine. They have specific poses
that we are driving based off
what the Character is doing, and we will get into that
a little bit more here. The capes --
it was a pretty tricky thing, just trying to figure out how we were going to get that
to work on mobile. How do we get that
to work on PC? How do we get it
to still look good, feel like it is this cloth
just draped from a Character? Characters can take
on any size and shape, but again, how do you
put a cape on a banana? Well, you can. In this case, we are seeing
the Trail Controller in motion, and you can see it kind of
just return to that Ref Pose
as he moves sideways. But it gives it
that kind of secondary motion. In this case,
we do have three chains; so there is a first chain
and then two forks. That way we can control
the stiffness of the upper versus
the bottom of the cape. We standardized the Skeleton
and the simulation Mesh, so that any cape that you create
gets put onto that Skeleton, and then you automatically
get all this behavior that we worked so hard
to get, kind of for free. That makes it so now
we can create a cape in about five minutes. For the cloth, you can
just use the same simulation Mesh, even if it
is long or short. We have standardized that so it just makes it really quick
to get the behavior. Again, we are going into peeling
off layers, so at lower LODs, we can manipulate the Trail
Controller, LOD out bones, and still get some of
the simulation that we need. But I think at the lowest LOD,
stiff as a board, just sticking off your back. Diving in a little into wings, here we are seeing the animation
play on the wings, based off
the Character's performance. Whenever the Character aims
down sites, the wings pull back. Primary reason for that is,
when you aim down sites, the camera zooms
right over the shoulder, and you do not want wings
blocking that, so we are getting those
out of the way, and it kind of gives it
a cool behavior. We also have,
when you start sprinting, those wings kind of fold back
a little bit; when you skydive,
the wings come out. All those are just
individual poses, and we are blending in
to each pose. You can see down
at the bottom here, we are doing a little bit here
in the Anim Graph to pull the Pawn speed,
so the faster you go, blend in the wings between
a sprint and a base kind of idle pose,
that is just one place where we layer that
on top of the state machine. All right, hair. Cannot really say
this is how we do all our hair, but this is how we do -- I mean, every hair
gets its own treatment. In this case, we are using
AnimDynamics, and trying to be
a little clever with it. In AnimDynamics, you are able
to define collision spheres, and that is what is allowing us
to get those little ponytails to react to the shoulder
when the shoulders come up. We are also able to feed
in our alpha. Has anyone used AnimDynamics
or FInterp, or anything like that
to get some of the behavior? In this case, basically,
based upon speed, we are using the FInterp
abilities of the alpha parameter
on AnimDynamics to change the way
that that hair bounces. The Art Director said it is
bouncing too much when running, tone that down, and this allows us
to do that dynamically. Since you can also change the way
that alpha is on and off, you can use the interp speed
also on that parameter, to make it
so it can blend on really quick, and then settle again
when you stop running, so you do not get this jump,
start shaking, stop immediately, what you usually get
with that type of alpha. All right, so cloth. We might spend
a little time here. We never know what animation
is going to play on a Character. They have a base traverse set
that has been set for years, but at the end of the day,
new emotes, dances and behaviors
are being created, and there is always stress test
the setups that we have created. In this case, I created
a dress out of Rigid Bodies and tried to -- the front leg straps
kind of flung up way too much, that are way too active. When you are running
from a third person, all you see are these leg straps
kind of come in over the body. I treated that
a little differently, which you see
in that graph there. Diving into Rigid Body first
to describe what I am doing, usually if you do
a setup like this, you get a lot of jitter. I am sure some of you have
experienced that before. The first thing that I learned
was controlling my mass per body is extremely important. I start kind of
with a power of 2 mentality. On the lowest child, I always
start the body a mass of 1, and do mass 1, 2, 4, 8, 16 -- you always want
the sum of the children to be less than the parent.
That kind of takes -- anywhere you do Rigid Bodies,
that is true. If you wanted to be
more extreme, so the lower bodies
move a lot more, then you could do 1, 5, 10 -- I do not know,
you can kind of fuss from there. Another thing that
we are doing here is, we are creating
cross constraints. You can create your own
constraints between bodies. First we get just --
what do I have, like, 5, 10 chains there? Then I will create
a cross-constraint between two. You do not want to do it
between every single one; that just does not give
the bodies anywhere to go. You want to give
some flexibility, so I will do every two
or every three. That way, your leg does not
just slip between the dress, rather it will move it
out of the way, because those bodies
will still stick together and kind of give you
a cloth approach. Then I think I pretty much
always have some spring on here, some level, just to try
and pull those back together. For the cross constraints,
those springs are pretty high. I really do not want those
bodies to pull apart too much, I want them to go along
for the ride. But if you go too high,
again you get jitter, and that is kind of
a balancing point. That all describes
this first dress node. But there is a lot more going on
in this Character. In order to kind of prevent
those cloth strips from flying out of nowhere and really screwing up
everything, we went ahead and added
these AnimDynamics nodes. Where I am doing that -- you see on this kind of
danglies Rigid Body, there are two sets of blocks
on the bottom are the Rigid Bodies that
are colliding with the shins. But the only way they are doing
that is they are being -- oh, sorry, they are not
actually colliding there. It appears
that they are colliding. I am driving the upper part
of the legs with AnimDynamics, because I can really control
that motion, and I can control the way
that it flies out. Instead of hitting a body
and bouncing out like I was getting
with Rigid Bodies, I can just say, just kind
of dangle between here. Then I used those
as kinematic bodies to then drive the simulation
of the lower part. I do this type of thing
all the time, and it really allows me
to art direct the simulation. That can be
one of the hardest parts, as when the Art Director says, hey,
tweak this one little thing, and then it breaks
your entire setup. You may have noticed
that these are all Rigid Bodies in AnimDynamics, so how does any of this work
on mobile? That is a good question.
I am glad you asked. What I am doing
for mobile is, I am adding a Trail Controller
for all of the skirts. Now one of the key problems
of Trail Controller, since it is lag-based,
it does not care where it goes. If she ran backwards, that skirt would just go
straight through the body. Based off the direction
of the Character, I blend on and off
Trail Controller, and I try to do that slowly so you do not pop back
into position. I also have
spring controllers for all the fur around her neck, so I have basic simulation
happening for that, which you see
in those Rigid Bodies. But then once we go into mobile, I am using Spring Controller
just to get a little bounce. As far as those
leg cloth things, those, I think,
just deform with the legs. They look pretty good enough
at a lower LOD. Beyond simulation, we have to make everything
look good all the time. In this case,
with this guy just crouching, and it does not really
look like much, but that little llama
on his hip normally would just pierce
right through his thigh. We have pouches and grenades and all kinds of things
that always get attached there, and that always ends up
being an issue. Our approach to correct
is generally -- let us go back here --
is to use this Get Delta Transform
from Ref Pose. Again, this is a newer node that I worked with the
Anim Engineers to create. We were normally doing the math;
I do not want to do the math. This makes it really easy
to get a bone and get it in a specific space. We use these
all over the place. On the backpacks and the capes
and everything, if you have a really
long backpack and you look up, it goes right through the chest,
right through the stomach. We will get
a reference to the body or to the end of his Skeleton, and I like to get the head
in Spine 5 space, and that just gives me
kind of a drastic angle. If you just said look up,
well, he can do this, and it does not have any effect. If you say, well,
whenever the Spine 5 goes up, well, you could lay down
and theoretically rotate it in root space
or component space, and that still does not
give you what you need. But the head and the spine
or pelvis space, that was giving me
exactly what I wanted. But in this case, I am taking
a look at the left thigh, and whenever I crouch,
I kind of define my angles here, and was able
to generate an alpha, so I just would map that 0 to 1,
and I feed that in my Anim Graph there at the top,
into that Transform Modify Bone. It is not the most performance
way to do that, I will admit, but it gives us
exactly what we need. Then whenever our director says,
hey, can we tweak this out a little bit more,
you do not have to go all the way back
into your DCC Maya or Blender and create a pose or animate it; you can just do it
right there in the Engine. Pose Driver -- has anyone used
Pose Driver before? Awesome, a couple.
Pose Driver is, in Maya we will create a set
of poses for the Character. I usually record
these straight out of game, because I want those angles
to be exact. If I am aiming and I look up, I want the shoulder pads
to react to that motion; I do not want it to guess. If I just create an animation
of this type of thing, and then adjust my shoulder pads
to react to those, I may never hit
those angles in Engine, unless I create an animation
that looks exactly like that. But that is not a good way
to validate it. In this case, the Pose Driver
allows me to create a set of animations
for bone sets I will be watching,
and then a set of animations, or a set of poses for the bones
that I will be driving. You see those big old cages
over the shoulder pads -- those are all being driven
based off of the clavicle and the upper arm. There are a few rules
with Pose Drivers, or some guidelines
with Pose Drivers. The fewer bones that
you are watching, the better. You try and watch
all of your clavicle upper arm, and maybe your spine -- all of those bones
have to line up to that exact, right place
for you to hit that pose. You want there to be
some wiggle room. You may hit it,
and then that corrective pose will just pop on. Then you wonder, why am I never
getting this look? I like to narrow it down to just that shoulder-upper
arm pose, if I can. If I am not quite getting that,
then I will add in a clavicle. You also see here
in the middle picture that I have it split out
into four. That is because I get poses
that may be very similar when I am skydiving
to aiming a specific weapon, but I do not want those
skydiving poses to muddy up my weapon poses.
I create new Pose Drivers. I detect if my Character
is skydiving, and if it is, then I swap over
to that other graph. I spent a long time
using quaternions, and that made it very difficult, because any time
you do a little twist or something in your pose,
you may completely lose -- that kind of invalidates
all other spaces that your arm could be in. In this case,
I am using swing angle. I should have had a graphic
for all the settings, but in this case,
on the right we are seeing, I think, 12 or 15 poses. I do recommend the fewer poses,
the better if you can. Otherwise, let us say,
if you try and do poses all the way up the arm,
like five different poses, then it will just pop
between them, where you get this kind of
jitter effects, which is not at all
what you want. Another thing is,
I break out per shoulder, again, because I do not want to be watching both
right clavicle-left clavicle, right shoulder-left shoulder.
I break each arm into its own. In some cases I will have
eight different Pose Drivers looking at all different things, because I really want
to isolate the problem. I went through
that really quick. Thank you!
[Laughter] [Applause] ♫ Unreal logo music ♫
