Hey everybody! Just wanted to make another quick video. This one is going to be talking about skeletal
meshes vs. static meshes, and the performance and when you should be using one and the other. The most common misconception I see, especially
in the indie games space, is that just because an object is animated, that it should have
to use a skeletal mesh, and that it should need to be rigged with bones. A common example of that might be, for example,
here we have a pistol, a gun in a game. Most games, most assets you see on the Unreal
Marketplace or online, they're rigged skeletons where you've got a bone for your slide, you've
got a bone for your trigger, and you've got a bone for your hammer and a bone for your
magazine. However, I think that in a lot of cases this
technique is a mistake and it's gonna be costing performance. And there's other situations as well, like
for example, maybe you have a chest or a box

that can open and close. A lot of people might put a bone in that so
that the mesh can hinge. Right, they thing, Okay well this needs to
be able to move, so I'm going weigh these vertices to a bone, and that'll allow me to
move it. I can use a skeletal animation. The mistake there is that you can animate
static objects through the vertex shader, and there are a lot of different techniques
that you can use to achieve that, and I'm going to be talking broadly about several of them. But these skeletal meshes are gonna have a
greater per vertex cost every frame, they're gonna be ticking every frame, they're gonna
be generally not able to be instanced at all or as easily. They are going to be more expensive per vertex,
more expensive per bone than a static mesh, which doesn't have any. So I think that I really just want to challenge
you to ask yourself more questions when you go to create this asset, and not just say,
okay does this need to be animated?

but also, is there a way that animation can
be achieved though the vertex shader? Does the physics asset need to change with
this animation? Right? If you have a human character that's up close,
and has a hitbox, maybe again if we look at a shooter for example - you're shooting at
an enemy character and you need that bullet to have impact with a hitbox, and that hitbox
needs to follow the physical representation of that character, then you don't want to
do that in the vertex shader because the vertex shader isn't going to change the physics asset. That needs to be a skeletal mesh. Now, crowds and distant characters or maybe
small animals like frogs and birds and things like that - they don't necessarily need to
have their physical asset represented perfectly by the mesh. These are generally small visual details that
don't have significant gameplay implications, right? The slide or the hammer or the trigger moving
on the gun as part of an animation doesn't

really impact the way that object physically interacts with the game. It's just a visual effect. So I'm gonna hop over into Unreal Engine real quick where I have this loaded up with a material, and what we can see here is if I, for example, turn this on, you can see that this trigger is being animated. And this is a static mesh. This is entirely being animated by the vertex shader. I can go in and I can make the hammer animate, and I can go in and make the slide animate. You can change the magnitude of these animations. Right now it's only moving a little. Now it's not moving at all. And so the point I'm making here is just that this is gonna be significantly more performant. I can have a much greater number of these assets in a scene. They can have more complex animations and much more detail than they would necessarily be able to have at the same performance level than if they were skeletal.

And you can actually test this, or look at
the millisecond cost of the animated meshes in a scene. And it depends on how many you have and so
on, but I'm just gonna... Bring in a skeletal version of the same mesh. This is the same mesh, just a skeletal version,
and we are going to turn on our stat anim here, and I am just going to quickly simulate
this. So you can see there we got skinned mesh comp
tick here of .03 milliseconds, and that's really not a lot, right? But the main thing is that these add up, and
that's just one piece of the animation cost. The more you have as far as objects in the
scene that are doing this, and this may be a skeletal mesh but it doesn't have any bones,
and it's imported without any bones which is gonna make it less expensive. But if we get rid of this and we bring back
this one, you can see here that that is 0.

milliseconds. So essentially, from a CPU standpoint, that's
gonna be significantly more performant than a skeletal mesh would be, and there's no loss
in visual quality. You can get this to animate in exactly the
same way as a skeletal mesh would. So if we go back to Blender, the way that
this is working here is I've got each element of this mesh, such as the slide, the barrel,
the trigger - you can see that each of these elements are their own separate island, and
that's because I don't want the polygons connecting. If the polygons of the slider were connected
to the polygons of the frame, then as the slide moved - I could grab this and move
it - you know you don't want the polygons of the frame to be moving with it, right? You want them to be free. And you could do this by making them separate
meshes, but in this case, I've chosen to make them separate islands within the same mesh.

The next thing I've done here is actually to give them different vertex colors. So if we go over into the vertex colors here, you can see, okay here we go. You can see that each element, the slide, the hammer, and this all in the alpha channel so it's grayscale so it might be a little hard to see the difference but it's pretty obvious with the slide vs the frame and the barrel. But these have different values, so I've given the slide a value of 1 and the trigger is 0.75, the hammer is 0.5 so they have different alpha values that allow me to basically use the vertex color to identify elements of the mesh within the vertex shader. So I can say every vertex with a value of 1 on its alpha channel is going to receive a certain vertex transformation. So within unreal what this looks like if we go to the material there's a lot going here. But the simplest thing is gonna be a linear transform.

Alright, so if we look at this material, what we've got is the vertex color node, right? I'm taking the alpha channel and I'm putting that into a bitmask. And the bitmask essentially allows you to search for a specific value and mask out all other values of data. In this particular case, that value I'm using is 0.003922, and the reason for that is because the bitmask is expecting a value between 0-255, but Blender is taking that value as between 0 to 1. So I think with this, that was maybe a 1, and I divided that by 255. I'm not gonna redo the math here, but essentially you take the value that you've mapped your mask to, and then you want to make sure that it's written in a way that Unreal is going to understand it. This is essentially masking out anything that doesn't have that value. So what I can do here is show you that mask if we take this result and pop that into our

base color. You can see that the slide turns white, and
everything else is black because that value is being masked. And if I were to do the same thing here with
the hammer, and it's just using a different factor. I think this one might have been 0.5
in Blender. You can see that the hammer gets colored white,
while everything else gets colored black. So that's what that is doing, and it just
allows you to isolate different parts of the mesh. There's other ways you could do this. You could, for example, use the RGB values to
store information about the group, like say, for example, what we really want to do with
the slide is get it to move along the X axis, which is what the rest of this code is here
for. So if I look at this, we take our mask, and
we're multiplying it by a vector in order to get the polygons to move along that vector. So that vector here is just red, just 1 in
the red channel or the X, 0 in the green or

blue. So what that's essentially gonna do is make
the slide move along the frame, 'cause that just happens to be the X direction. And then we multiply that, our 1,0,0, our
vector, by the magnitude - the strength - that we want that to have. So here, I've just got a sine wave that's being
multiplied by a parameter, so that tells me the parameter, essentially the maximum value,
and the sine wave is modulating that to turn it into an animation. If I got rid of that and just plugged this
straight in, we go back to our mesh here. Turn this on. Now you can see that I can directly control
the position of the slide. So, the next thing you might ask yourself
is okay, so I know that I can mask out which vertices to move using this bitmask. I can
tell it what direction to move, and I could've actually baked this vector into the vertex
colors. I could take that group of vertices that I
have identified as the slide, and I could give

them the red vertex color, and that would give
them this vector. Then I wouldn't need to define that vector
in the engine. The reason I've done it this way is that this
gives you 3 more channels of vertex data to use. What if you have other ideas about how
you want to use that vertex data? Maybe you want to put in a curvature map for
wear and tear, or anything like that. So, by putting that data in the
shader, frees up the vertex color channel. And it's pretty simple to keep track of that
number. Alright, so once you have this vector, we're
just taking it out into the world position, and we're adding it to any other masked positions
that we need to do. So translating or transforming laterally,
moving in the X, Y, Z is very simple. All you have to do is mask the area and then
multiply that by a vector of your choice. I want this to move in one direction, that's
very simple.

You could potentially do this with traditional
vertex animation textures. So, a vertex animation texture is a texture
that, rather than using a parameter - you could use a material parameter collection and animate
it with a curve, or anything like that, but you can also take a texture and have that
texture be sampled, and the value on any given pixel of the texture represents one frame
of animation. I'll be putting in a link to a really great
article that goes into extensive detail on vertex animation textures and how you can
use them, and I'd highly recommend taking a look at that, but I wanted to keep this more
general and just showing that a value is being read. It doesn't matter where this value comes from,
this value could be read from a texture that is baked from an animation that's been hand
authored, this could be made mathematically like for example here with a sine wave. You could use anything to drive this animation. So moving on, the next topic is gonna be rotation.

So rotation is a little bit more complicated. When we look at both the hammer and the trigger,
these are animations that require rotation. So rather than just multiplying by a vector,
we need the Rotate About Axis node. There's also a Rotate About Axis Cheap node,
but I found that in its current form, the Y axis is broken on it, and that's what I needed
for my example here for the way my hammer and trigger are rotating, and I didn't feel
like fixing the material, so I'll just be using the normal rotate about axis. So you have to use this node, and this takes
a couple of pieces of information here. So once again, we've filtered out, masked out
anything that isn't our hammer, and we're taking that and we are putting it into a multiplication
with this rotate about axis. And the rotation axis is Y, or green here. So this is going into the normalized rotation
axis. The rotation angle is gonna tell us how much
do you want to rotate, right?

In this case, I've got that being driven by a sine wave. But just like before, you could have that driven by a vertex animation texture.
You can have that driven by anything, right? Then we have the pivot point, which the pivot is by default gonna be the center of the mesh. And we don't want this to rotate around the center of the mesh. We want it to rotate around some point in space. So if we go back to Blender here and we look at our mesh, I'm gonna go into the side view. If we go ahead and add in an empty, there's a lot of different ways you can figure this out here, but I'm just gonna hover this empty vaguely around the area I want this to rotate from. Right, so it's somewhere around here, right? And so we can see this is -0.83 and 0.37 within Blender. So if I go back over to Unreal, you can see that I have this set to -86 and 30, so roughly

a similar position. You could copy it exactly. I fine-tuned it
to a spot that I liked. That rotation and the reason that it's 86 instead of 0.86 is just
because of the scale difference in Blender and Unreal. But once again, what you could have done - you
could've determined that in Blender and you could've baked that rotation axis, that pivot
point into the RGB value of the vertex colors. Then you can just read the RGB and use that
for your pivot point. So 
again I just chose to keep those RGB values free for the sake of demonstrating this all
within the shader. Then you have your position, which is just
the world position of the mesh. The other thing that you need to do with rotation
is you have to fix the normals. The reason for this is when you're translating
or transforming a polygon forward, backwards, left, and right without rotating it, the normals
of the mesh stay pointed in the same direction.

right? If I slide something on a table to the left,
up on that is still facing up. But if I turn it on its side, I rotate it,
what used to be facing up is now facing to a side, right. Maybe it's facing towards yourself, or away
from yourself, depending on which way you decided to rotate that object. And Unreal doesn't know that. It's gonna continue to have that side face
that used to be the top, have its normal facing upward still, and the shading will be completely
wrong. So what you need to do is take this node. Fix
Rotate About Axis Normals, and give it the rotation axis, which is the same as before,
just our Y rotation axis. We feed it the same angle as before. And then this will give us a new normal. And I've just taken that normal and masked
out certain parts of that normal because I'm going
to be recombining it with another corrected normal later. So I want to correct for both the hammer and
the trigger, and then combine those corrected

normals. So essentially, I only want to be the normals from say the hammer and how that's being corrected and get rid of the rest. And you can use that with the movement mask here, so this is going to apply the movement only to the hammer while the rest stays the same. And I'm further actually masking it out so that I can add in this next one here. So it gets a little bit more complicated if you have multiple different pieces that can independently rotate. And you want to make sure that you're compensating the normal directions for both of them or else your shading will be wrong. That's what this section is designed to do. Hopefully that's detailed enough, but just keep in mind that you have to correct. And the way that you correct that would really depend on your specific application, so I don't wanna get too in detail about what I've done here because it might not really be relevant for most use cases but again I'm correcting the normals, masking out the parts of the

normals that I'm not using and combining that
with another normal map that is also corrected and masked out. Then that's just going into the actual normal
here. So that all makes sense... There's a bit more going with these, because
you need to use this rotate about axis node, and you need to correct your normals, but that's
really about it, right. So if you're using vertex animation textures,
you don't necessarily need to go through all this, but this in particular is doing is decoupling
the vertex animation from the poly count. One thing you're gonna run into with vertex
animation textures, unless you plan and prepare accordingly, is that a texture in unreal can
only be 8k at a maximum. So with a vertex animation, that means that
if you're animating each vertex independently, you can only have 8000 vertices in a mesh. So what we've done here is rather than trying
to animate each vertex, we have taken those

and made elements, larger features that are
going to be animated together. The slide doesn't need to stretch, so it doesn't
need to have some vertices being controlled differently than other vertices. They should all be moved a uniform amount. You can do this with other types of complicated
objects too, like a human. The arm, as it rotates, the forearm is all
going to move together, generally speaking. Especially if you're looking at a distant
person where you're not going to notice the tiny changes that would be seen when they're up
close using skeletal animation. All those polygons will move together as a
group, so you really want to assign them the same value and move them as a unit. That gives you a lot more options and look
at much higher poly meshes to use this treatment on. Again, in this particular case, I could animate
this using curves, I could animate this using math, I could animate using textures, but at
no point did I have to use a bone.

That's the real key takeaway. Most of you are already using vertex animations
in your foliage. You would never make a tree or a blade of
grass or a bush and then put a skeleton in it and then animate each leaf by hand. It just doesn't make sense. This is ultimately going to allow you to achieve
animations that will rival skeletal animations without ever having to take the performance
hit. Hopefully you find this insightful and have
ways that you can apply this, and if you have any questions, feel free to throw them down
in the comment section. Once again, this has been kind of a surprise. I just recently hit 100 subscribers and 10,000
viewers on my channel. For something that is just kind of a hobby
that I do in my free time, I never expected it to get so much traction, so thank you all
so much for watching and - till next time!

Stop Using Skeletal Meshes! (Unreal Performance Optimization Tips)

Stop Using Skeletal Meshes! (Unreal Performance Optimization Tips)