Good morning. Thank you for coming. So, my name is Matthew Lake. I am a technical animator working in the video games industry. As a technical animator, I touch almost all aspects of character and animation, from rigging tools, state machines, etc. So, a little bit about me. I worked on Destruction Allstars, a PlayStation 5 launch title. My most recent game was Forspoken, also running on the PS5, with both titles utilizing Unreal Engine 4 and 5 live, respectively. My latest venture has been to release a book all about technical animation and video games, which released in December. But today, I'm here to share with you some knowledge that I've accrued in regards to character and animation optimizations in Unreal Engine 5. So, this talk will mostly be an artist-friendly talk with processes that everybody can apply, but there are going to be some nuggets of code in here. But I've tried to make sure that I can accommodate this talk for anybody with access to the engine can do most of the things we're going to be covering a lot.

of basis from some obvious Tech to some relatively unknown ones, but I do hope that you're going to come away with some extra knowledge that you can apply to your own projects. So, I'm going to be going quite fast, as there is a lot I want to share, but do not fret, as this is recorded, and it will be viewable online later. So, without further ado, let's start off with some quick profiling tools. First up, some common commands. So, start FPS will display the current FPS and frame time on your screen. Stat unit will break down more information about the frame time and how long the game thread took, etc. ET. If you like graphs, you can visualize stat unit over time with stat unit graph. Stat anim will give you a live breakdown of exactly what the current animation costs are. Finally, show debug animation will actually give you a breakdown of what's evaluating animation-wise as well. So, onto a handful of tools at our disposal as well. So, the size map tool. You can access this on any asset in

the engine by right-clicking it and choosing size map. This will bring up an interface that includes every hard dependency that this asset needs. In the top right of the interface, you can actually switch between dis size or memory size, so this is super useful for validating the overall footprint of your assets and their dependencies in memory and storage. Memor part is a command that you can run that will output a text file containing everything that's in memory. So at any point of the game, you can run memor report D full, and then you'll get this nice little text file outputted, and it's very useful for tracking exactly what's taken up your memory. If you use control rigs, there are some built-in profiling tools in there as well. So if you go to the class settings inside the control rig, find the user interface and VM category, and you can enable profiling, show node run count, and instruction index. And then once enabled, the graph will light up like a Christmas tree, and you'll get a total cost of the control rig in the bottom corner there.

which is really useful. So, each node will have a cost in the top left corner, and in the top right, you're going to have two numbers. So, one is the instruction index, and then the node run count. The GPU visualizer is a tool to get a breakdown of the current GPU frame. So, at any point in the game, press Control + Shift + Comma, and you'll get this interface popping up, and it'll give you a breakdown of exactly the frames' GPU cost. But if you want to go into more detail, I do recommend Insights. So, Insights is a comprehensive performance profiling tool built into Unreal. So, you may notice this Trace icon at the bottom of your screen. This is Unreal Insights. So, settings-wise, if you want to profile some animation work, I do recommend enabling the animation channel asset load times, as well as stat-named events. And to make things a little bit easier, click Open Insights after Trace so you can begin a quick profile run around, do some actions, and then you'll get this interface here. So, zooming in, you can begin to see all of

the components that were calculated that frame enhanced input sweep checks your state machine costs, your spakes cost, and even animation decompression. So, it's very useful for breaking down exactly what is going on. So, let's dive on to some character work animation sequences. So, these assets are likely the most frequent type of asset that you will have for characters. There can be hundreds, if not thousands, of animations per title, so small optimizations will go a long way. This may seem obvious, but start with content auditing. It's quite common for animations to be imported imp Ed with unnecessary data. Validate the content of your animation data and ensure you are only importing what is absolutely necessary. So, this includes animation tracks. Perhaps you might have face joints baked into the animation, but you don't need them in that animation sequence. Or you've got defamation joints like twists that are going to be recalculated at runtime anyway. All of this data does is just BL blow your animation sequences, so remove it from the fbx before you import. The same goes for animation curves, so make sure you

audit these and you're only including what is necessary when necessary. So sometimes I've seen animations imported from Maya that may include like Blend orian or blend parent curves. Just remove them. So one technique I've historically used to audit the animations with the animation tracks UI. At a quick glance, you could see the entire animation sequence directly U the content directly inside of unreal. I recall knowing if I saw 66 tracks, it was the perfect amount for gameplay. If there was anything other than that number, there was going to be an issue. I am unfortunately speaking in the past tense as this UI element was removed in 5.2. But you can still get this data in the editor. The easiest way I've found is with an editor utility. So these are blueprints that allow you to make inedited tools, which are perfect for auditing. So I've quickly made an asset action utility, which allows you to add a function to the right-click menu. So this is the logic. It's quite simple. We're iterating through the selected asset and getting the animation.

track names from the animation sequence. So, after running this audit check on this asset, here you can see we have 89 tracks on this first animation. There we go. But if we run it again on all of the assets, we can actually see that some of them have 89 tracks, but some of them have 159 tracks. They're all inconsistent, so it's worth checking the data that's getting imported. And although we can still get this data, please read this UI. It was wonderful, and I miss it dearly. So, when dealing with curves, there are a handful of import settings that we can tweak in an animation sequence. In particular, that delete existing animation curves in attributes, as well as the Do Not import curves with zero values. It can be quite a pain to change these one by one, so if you want to change these settings globally, you can navigate to your engine's config folder, and you'll find the base editor per project user settings any file, and you'll find a section called FBX anim sequence import data. It looks a bit

something like that. So, this is where you can alter the default values that are going to be applied engine-wide. So, let's put all of these together on a quick example. So, we've got a 200-frame animation here. First cleanup is to remove the animation tracks. Only 64 of those were actually needed, and the rest of them were twist joints and deformation joints that are going to get recalculated anyway. There were a lot of curves that weren't necessary, 126 curves, and that ended up giving us a 71% decrease on the storage and a 90% decrease on the memory. So, these are absolutely crazy savings from a tiny bit of cleaning up after yourself. Now, extrapolate those savings across thousands of animation files that are going to be in your project. It's going to soon add up. So, this additional data also has an impact on the animation graph. So, as you can see between these two animations, you can visually see that there is extra information being passed through the execution flow, and then this data is

then subsequently passed through all the following nodes, so the less data we are processing at each point, the better. So before I moved on, I thought I would talk about animation compression briefly. So if you're not using it already, I do recommend using ACL for animation compression. This is now the default compression in 5.3 onwards, so if you're up to date with the engine, you don't really have to do anything to use this. But if you are using older versions, the plugin supports back to 4.25, and it's on the marketplace, so you can go grab that for free. So let's cover level of detail, otherwise known as LOD. So LOD is a technique we can employ to make our skeletal mesh become less resource-intensive as it goes off into the distance. Not only can we reduce geometric detail, we can also reduce joint counts, remove morph targets, and skin influences. We can generate LODs directly inside Unreal now, and the engine has some pretty amazing tools built in, which I highly recommend giving them a shot. So inside the LOD settings category of our

skeletal mesh. You'll find a number of Ls value if you enter a number of desired LS in here and click apply changes. Unreal would generate you some fairly high-quality LS. Now, while the default L settings are okay, we can customize these to get some much more finer control. So, to do this, head back to your L settings category, and there's another option called Lo settings. Click the generate asset button there, and it'll create a dedicated data asset. So, the benefit of this is that you can apply your L settings once and apply it to every single skeletal mesh in your project. These changes in one place are then applied everywhere instead of having to change the settings over and over again, and it really helps with consistency. So, let's dive into a few of these settings. So, each L within the L groups array will have its own cluster of settings. I would focus your attention on these four settings: screen size, hesis bone list, and reduction settings. So, screen size is a setting that defines when the switch to this lot occurs. So, this setting is based on

screen real estate. So how much of the screen is taken up by that skeletal mesh? And this chart shows some of the values we're talking about, and the numbers can get really small really fast. You can actually use the visualize LS command, which will show the on-screen, uh, the screen size value in the debug information. So this is particularly useful for helping determine setting those values. Hysteresis is the next setting. This value helps fix a problem with L switching. Let me demonstrate the issue. So when you're at an L threshold, you can sometimes get this point where you're constantly switching back and forth between LS, even if the camera is completely static. So this is where hysteresis comes in to save the day. Effectively, this allows you to create an offset on the transition threshold in the enter and exit directions, so you no longer ride that flicker point as the threshold to trigger the L switch is different in both directions. And now with this setting applied, it's nearly impossible to get that flicker.

Point amazing. So, moving on to the B list setting. This works in conjunction with the bone filter action option to change how the bone list behaves. The first mode will remove joints in the bone list but keep everything that is not listed, whereas the second mode only keeps joints in the bone list and will remove everything else. So, I would use both of these settings for different LS. So, for example, on L one, maybe I only want to purge the face joints, whereas on L two, I only want the core skeleton joints. So, then I could filter everything else out. So, both of these settings have their place, so use them both. And finally, the R, the reduction settings. This in itself is a whole host of options, but let's briefly talk about some of the big ones. Remap moth targets does what it says on the tin. It basically makes the L have any moth targets present on the above L. Morph targets can be quite heavy, so I would keep this off unless absolutely necessary. Max Bor influencers put a clamp on the amount of skin influencers.

for that l so you can get some really good savings from reducing this too. If your L zero is maybe eight influences, you could drop your L three down to four and then have your furest L have one skin influence. There are also a variety of geometry modification settings that you can play with that will tweak the generated geometry, from volumetric corrections to preserving vertex color boundaries, all super useful settings. And this is what the end result can look like, mostly unnoticeable if you do it right. So LS are becoming less prolific in art due to technologies like nanite, but for the time being, we need to Lad skeletons until we get nanite fully supporting skinned and simulation workflows or for platforms that do not support N8. So onto the animation blueprint, there is a lot we can do here to maximize our efficiency. The first tip is to ensure you have multi-threading support enabled. This will enable your blueprint to run on separate threads and alleviate some resources in sure the allow multi-threaded animation update project.

setting is enabled. This is in Project settings, engine general settings. Then, in each animation blueprint, you need to enable the used multi-threaded animation update, and that can be found in the class settings. So, one word of caution: if you're utilizing root motion from everything or from montages, this will make your animation graph run on the game thread, and you're going to lose multi-threading. With the multi-threading enabled, make use of the thread-safe version of the update animation event, the thread-safe update animation function. So, move all of your logic to this where applicable. So, the next tip is fast path. So, whenever you see this lightning bolt, this means that that specific node variable access is running in an optimized manner and utilizing fast path. If you don't see it, then we are exiting to the blueprint virtual machine, which is a slow operation. So, fast path does need a project setting enabling, and you can find this in the same location as the multi-threading setting. Optimize anim blueprint member variable access is what you're looking for.

for so it's very easy to accidentally exit the fast path through some bad practices. So, you can actually turn on warnings in the animation blueprint to let you know when you've exited the fast path. So, in the class settings, you'll find a warn about blueprint usage option, and then once enabled, you'll get warnings directly on the Node and in the output log whenever the fast path has been exited. So, what can and can't we do with fast path? So, accessing values directly is safe. Direct connections will maintain the fast path. Not variables are also safe as well. These are okay. Do not access variables via reference or chain nodes. And as you can see here, we have a reference to another actor, and we are reading a variable from it. This is going to exit the fast path. Don't do this. Instead, you can access variables via the property access node instead. Now, we have the same functionality of calling that external actor, but it's fast path safe. Do not use and or o nodes. This will also exit the fast path. And finally, don't do any logic.

manipulation to variables prior to plugging them in. But what if you need to use and or nodes? Or what if you need to manipulate a value before you plug it in? How can we do this but still maintain the fast path? So, this is where animation graph functions come in. These allow you to run a function directly in the animation graph's execution. So, there's two methods of triggering these. The first is functions on nodes. If you select any node within the animation graph and go to the details panel, you'll have a little functions category here. You can assign functions to run on initial update, become relevant, or unupdate. And these functions are really useful for ensuring relevant logic is only executing when that node is operating. So, in this example, I've got the my special function is running on update. So, it'll run every time that that node updates like a tick. It's very useful. The second method is with the dedicated call function. So, this is a dedicated animation graph that can run functions directly in the flow. And unlike functions on the nodes

these actually have a much bigger selection of triggers, so animation graph functions must be thread-safe to be used. So, to turn this on, you need to select your function in your animation blueprint, go to your details panel, scroll down to Advanced, and then you'll find a thread-safe option. Turn that on. So, let's apply this to a use case. So, if we remember this transition event that was failing the fast path earlier, let's move that criteria into a node function, and we're going to make a new variable that is the sum of that logic, and then we're going to plug that variable into the transition event, and then call that function on the result node. So, now we have the same functionality, but we're maintaining our fast path. Amazing. So, next up is animation graph LS. This is applying level of detailed methods to your animation graphs. First up, the node LS. So, you will find a performance category with a threshold value on each of your nodes within the animation graph. This allows you to connect the node's execution to a

particular. So here's an example of this in action. We have a very simple graph with an additive set to a threshold of one. So if we preview that in the game, we can see it executing for L zero and L one. But when we hit L two, the node and its children will stop executing. So this is very useful for disabling particular nodes in your graph at a distance. We can also access the predicted L level for use in our graph. So this is the current L value of the skeletal mesh. You can get this in Blueprint directly from the skeletal mesh, or if you're in an animation blueprint, you can query the owning component predicted L level. And then you can use this value in your graph to drive logic. So here we have another simple example. We're using the L level to gate on a blend by bool node. So when the LH changes, we can control it to switch execution tracks. Now this is just a simple demonstration, but this could be used to change or skip entire graphs depending

on your L value and one last L tip for those using post-process animation blueprints. In 5.3, Unreal added a new option to the skeletal mesh asset to control the threshold at which the post-process animation blueprint will stop evaluating. So, let's round off our animation graph section with some good rules of thumb to apply. So, space conversion nodes, these do have a cost associated with them; they're not free. So, going back and forth between local and component can soon add up, so try to bundle these together and have as few of them as possible. State machines have a handful of settings that you can customize to alleviate the burden of some of the costs. The max transitions per frame and max transition requests can be dropped down and tailored to your liking. And if you're not using pose caches already, you should be. These allow you to evaluate a pose once and store it for use in multiple places. Perhaps you need to reuse your idle throughout your graph; consider caching it once and reusing it everywhere. It'll evaluate once rather

than once per instance, and the caching also applies to State machines. Don't stack nested State machines inside of nested State machines. You can put all of your state machines on the top level, nice and flat, cache them, and you can use them where needed. This will also add a huge degree of flexibility into your animation graphs, but you would be quite limited in a nested workflow. So, let's discuss a little bit about skeleton pose updates. So, Unreal's defaults have a big priority on getting something working and working fast with minimal hoops to jump through. This is great, but it also means sometimes things are not set up in the most efficient way. So, with skeletal meshes, if they're right next to you, a million miles away on screen or off screen, they're always going to keep updating their pose. And as you can imagine, this isn't always ideal for performance. Fortunately, there are some settings we can control to modify this behavior. So, visibility-based anim tick is one such option. This allows you to alter the criteria that defines when the update to update the animation tick.

this can be found in skeletal meshes optimization category. By default, this is set to always tick and refresh bones, which means the behavior we just demonstrated. But there are other options, such as only tick pose when rendered, which means if the skeleton goes off screen and it's not rendered, it won't update. So, this is the behavior of only tick pose when rendered, and as you can see, the animation blueprint is only updating when it's needed. This can save a ton of performance for skeletons off-screen, and it's really useful for incidental or environmental animation work too. Now, as you can imagine, it can be quite annoying to manually set that every single time, so what we can do is change the project default to get this optimized behavior by default and then opt out for our edge cases. So, if you head to your project's config folder and go to the default engine ini, you can add the following code: engine.skeletal mesh component visibility based anim tick option equals only tick pose when rendered. Then restart your editor, and the only tick

pose when rendered option will now be the default value. Unfortunately, this only applies to skeletal mesh components, and it does not apply to skeletal mesh actors. So, skeleton mesh actors are when you drag a skeleton mesh into your scene. These are treated slightly differently, but if you do want access that covers everything, you're going to have to modify the source code for the engine. So, in the Skeletor mesh component CPP file and the Skeletor mesh actor CPP file, in both instances, switch the visibility-based anim tick option to only tick pose when rendered. So, now the default value will be only tick pose when rendered, and we can still choose to opt out with this behavior and manually set the original behavior for edge cases. So, next up is no skeleton update. This acts as a complete shut-off button for updating the skeleton. This is a simple Boolean that can be found on your skeletal mesh. I've previously used this on a room trigger, so when the player would enter a room, I would disable the no skeleton update and re-enable it on

exit. So, this kept everything in the room disabled until the player actually entered it again. If you'd like to change the default value of this, you can head to the skeleton mesh component CPP file, and you'll find the no skeleton update Boolean. So, update rate optimizations is a technique that effectively skips frame updates on skeletal measures at distances. You can enable this in the skeletal mesh component's optimization category, and you'll find the enable update rate optimizations button, as well as a debug option below it. So, out of the box, Unreal does have some default settings that are demonstrated here. You can see the red bounds there mean it's skipping zero frames, green is skipping one frame, blue is skipping two, and black more than two. These default settings are not customizable without going into code, unfortunately. Now, I did mention I wanted this talk to be as artist-friendly as possible, so for those that do not know C++, during the course of putting this talk together, I've made a free plugin that exposes this functionality to Blueprint. It's available on the Unreal

marketplace. Go check it out. It's completely free, available from UE4 to 5.4. So, it has two modes: there is an L-based mode or a screen percent mode, allowing you to connect either one of those to a reduction in animation update rates. So now, after customizing some of our settings from left to right, we're skipping zero frames, 10 frames, 20 frames, and 30 frames. We've interpolation turned off, and now the same skip rate with interpolation turned on. So, we've interpolation turned on, the reduction rates not really noticeable until you get around 10 to 15 skips. Now, obviously, these videos are quite significant skip rates, but you could have much more smaller granular numbers that would be quite unnoticeable for distant characters. For those in U5, we also have access to the budgeted skeletal mesh component. So, this allows us to have a maximum performance budget for all skeletal mesh components in our scheme. This is accessed through the animation budget allocator plugin, and once enabled, you get access

to a new component type called the skeleton mesh component budgeted switch out all of your skeletal measures for this one, and then you're going to enable the functionality with the a. budget enabled command. And then you need to use the enable animation budget node as well. So, we're going to apply this technique to our little army here. We have 100 characters that are taking anywhere between four and 5 milliseconds, and this debug information can be drawn with a. budget. debug. enabled. So, if we pop back to blueprints, we can use the set anim budget parameters node to Define our settings. So, let's say our game only has a budget of 1 millisecond for all of our characters. You can set that value in there, return straight back to the game, and now, as you can see on the graph, we are maintaining our 1-millisecond budget, and all of the update rates for all of those assets have been altered to compensate and reduce the load to ensure we are hitting that Target. There's also a plethora of

customization options if you expand that struct, and you can tailor your experience accordingly. So, let's move to talk a little bit about textures. So, textures will likely have the biggest size footprint out of all of your character assets, so it's important that we maximize the efficiency of these. You'll commonly find textures offered at 4K, but often that resolution may not be needed at runtime, and they can take up a huge amount of space. Oh, then we divide down. These are some of the other common file types. Now, a common misconception I often see people mistake is that these are effectively Haring their size when going from 4 to 2K, 2K, 1K, when that's not the case. These divisions fit in a lot more than you may expect. A 2K fits inside four times, a 1K fits inside 16 times, 512 fits inside 64 times, and a 256 fits in 256 times. So, as you can imagine, this is going to dramatically increase the footprint of your texture. So, let's see

what we can do about this texture size limits. So, on a per-texture basis, you can clamp the resolution of your texture that will be cooked under the compression category of your texture. There is a maximum texture size value, so you could maintain maybe your 4K source files but then cook to 2K. And as you can see, this is quartering the resource, dropping from 22 megabytes to 5.5. So, as usual, it can be quite a pain to manually set this on a per-asset basis, but thankfully, there is a global solution for this in your engine's config folder. If you open up the base device profiles in the file, you'll find the global default device profile. And I'll look up a little bit something like that. You're specifically looking for the character texture group lines and the Max L size value. So, this is where you can set a maximum size for the character textures project-wide, no matter its important resolution. It's going to be clamped to this. This set will only apply to textures that have been marked as character in the texture group, so you

can find this in the level of detail category on your texture select character from the dropdown. My recommendation would be to use the property Matrix to apply this to all of your character textures rather than doing that one at a time as well. So micro detail is one of the biggest reasons why you may need huge textures to preserve those small details on objects, things like threads on gloves, scratches on metal, weaves. These small details really add a huge amount of fidelity to characters but often, but unfortunately, to maintain this detail with textures alone requires huge resolution assets. So this detail can also be really easily nipped out on lower-end hardware when 4K drops to 2K and all that detail is lost. So my recommendation would be to apply this micro detail in a Shader instead. Have small tiling textures that repeat over your mesh instead of baking that micro detail directly into the main texture. If you need multiple micro weave, micro detail textures, then use a mask system to help define those zones. This also has the added benefit of

allowing you to drop your texture size down considerably, and that micro detail will still hold as it's entirely Shader-driven, and it will also hold up against meing, so that detail will be there no matter what. So, onto texture compression. So, the default compression in Unreal for standard textures is BC1 or BC3. So, BC1 has three channels: red, green, and blue. BC3 has four channels: red, green, blue, and Alpha. So, when you import a texture into Unreal, it's going to do its best to try to figure out what you need, and it may not always be right. So, sometimes it can detect an alpha channel when you may not want it to. So, you can use the Compress without Alpha option to enforce it back to being a BC1. It'll get rid of that alpha channel for you. Now, I'd be cautious about the cost of an alpha channel, as you may notice between textures with an alpha and without can double in size. You can see here we've got the 2 megabyte no alpha versus 4 megabyte with alpha. So, under

the hood. It's not just adding one extra channel, which logically you might expect it to just add 33% on top, but that's kind of not what's going on. So, BC1 is saving five bits in the red channel, six bits in the green, and five bits in the blue. And that's where that bit of trivia about green channels having more information comes from. The image is processed in 4x4 chunks, effectively giving you four bits per pixel, whereas BC3, on the other hand, is saving eight bits in four channels, again processed in 4x4 chunks, giving you eight bits per pixel. So, suddenly you can see where this big jump in the data is coming from. So, be careful about your usage of an alpha if your memory tight. If you're doing any texture work where you only want a single channel and you don't want to waste any resources, make use of the G8 compression. This will remove the green, blue, and alpha channels from your texture and leave you only with the red channel available. So, keep

that one in mind. All of these compression settings can be found in the details panel of your texture. So, UD is a set of data compression systems that are built into Unreal. You may have noticed this little tab up here hiding away on your textures. This is the UD interface, and it can provide you with some pretty good information. In particular, the area at the bottom will try to give you a best estimate of the final compressed size of your texture, which is really useful. But the area at the top you can use to customize the UDLE compression settings. So, the defaults are zero, but a 30 Lambda gives some pretty decent results. So, have a play with these settings, and when you're happy with what you're seeing, you can apply these project-wide. If you go to your base engines in file into the engines config folder, you will find the texture encoding project setting. And then if you enable the top setting there, the final uses RDO, the settings after it will then be applied project-wide. So, Channel packing is another excellent technique to make the use out

of your texture space. This is a technique that effectively refers to combining multiple textures together into a single texture and utilizing each channel of that texture respectively. So, one example of this is your ambient occlusion, roughness, and metallic textures. Since they're all grayscale information, you can combine all of these into a single asset. We have occlusion in red, roughness in green, metallic in blue, giving you an ORM mask in RGB. And if you want, you could even put something else in the alpha channel, like emissive. Then you have a single texture driving four different properties rather than four different textures. So, pack stuff together, then you'll have less texture samples but with the same amount of data. And if you are extremely tight on texture space, we can actually apply this packing technique to a normal map. Now, a word of warning, this does come with a fidelity trade-off if you do utilize this, but it may help you out. So, there is a node in Unreal that allows you to derive a normal Z from its X and Y, which

will free up that channel. So, to do this, we need to switch our compression settings for the normal back to a default BC texture. Then, we need to set up our Shader a little bit. So, this is what it's going to end up looking like. So, at the beginning, we are unpacking the red and green Channel and applying a constant bias scale to make the range go from minus one to one again. Then, we are pending our channels together into the derive normal Z node. And then, this is the before and after. So, you can see there's a little bit of a downgrade there. There's a bit more stepping, visual quality loss, but it may help you out if you're in a pinch, um, and it'll leave you with the empty blue Channel and as well as the alpha if you wanted to put more information in there. So, masks are also an exceptional tool for many texture and shaded purposes, colorizing areas, applying detail zones. As I mentioned earlier, one efficient technique that Mark Kushley shared with me many years ago and I've been using

ever since is to not limit yourself to only using red, green, and blue, but also to use San magenta and yellow, the secondary opposite colors, as well as key. So, Canan is the opposite red, magenta, the opposite green, yellow, the opposite blue. This allows you to get seven different masks from a single RGB texture, over doubling the amount of information from a single mask, which is really useful. And if you want it as well, you could even use Alphas, black and white, as two additional masks, ping that to nine masks from one texture. So, skeletal mesh components have quite a few settings that we can modify as well. So, bounds in Unreal are automatically calculated and updated every single frame. You can use the sh flag. bounds one to see the bounds of the character, and then each component within that blueprint is going to be calculated its own bounds, which can be often unnecessary in some circumstances. So, there are a few options that we can control this behavior with. So, the first up is Skip bounds update when interpolating. This will only

update the bounds with a pause update and not during interpolation. So, on screen, I've actually reduced the update rate of the skeletal mesh, but it's still interpolating. Those bounds are only updating when the POS itself does, rather than every single frame. The second option component uses fixed scale bounds instead of calculating the bounds based on its content. You have a static bounds now. I would be careful with this. If the skeleton mesh leaves those fixed bounds, it can become invisible when it should be rendered. So, as long as your character is staying within those bounds, you can safely turn this on. And finally, I mentioned the bounds are calculated for each component. So, if you have a modular character, this bound check is going to be completed for every shirt, every pants, every hat. And as you can see that happening on the left, we can use the used parent bounds or used bounds from the leader POS component to calculate the bounds for the main body and then propagate this to the clothing pieces, as shown on the right. These bound options can be found

on the skeletal mesh components details panel, and one quick pipeline I'd like to highlight is the render static for skeletal meshes. This is another option you can find in the optimization category, but this will effectively make the skeleton mesh render as a static mesh, skipping a lot of extra computation work. So, this is particularly useful if you have a static mesh, if you want a static mesh variant of a skeletal mesh without having to have a duplicate asset, which comes with the additional resource footprint. This option can be dynamically switched in the editor on and off as needed as well. So, until nanite skeletons arrive, there is one technique that allows us to leverage nanite with animated skeletons. So, this involves the use of an invisible skeleton that has nanite meshes attached to it. So, Unreal does not allow you to import a skeletal mesh with no geometry, so skin a single triangle and import that. Then, inside the skeletal mesh editor, you can right-click in the background of the L section and click a hidden option for disable. And once disabled, this will turn that single poly

invisible and now you have your invisible skeleton. Then we need to import all of our skeletal mesh static mesh pieces as static meshes, sorry, with n enabled, and then attach those components together in a blueprint with the correct sockets, and then place some animation, and voila, you now have an animated nanite mesh. So this is really useful for vehicles or rigid mechanical parts, so make use of that until we get some nanite skeletal meshes. So let's wrap up with some Blueprinting pipeline work to be more efficient, starting with tick this guy. So event tick often gets quite a bad rep. I think it's mainly because it's often abused, and the default unreal settings don't really help either. So let's start off with a few steps that we can apply to make tick work a bit more appropriately, starting off with turning it off by default, of course. So in a real, the default state for actors is to start with tick enabled. You can set the start with tick enabled to be false in the blueprint, and this can be found on the class settings.

but tick will also need disabling on a per-component basis, as each component is set to tick by default as well, and this can become quite tedious to maintain, as you're going to need to keep on top of this for every single component in Blueprint. But if you want, you can actually modify the core actor and component classes so you don't have to do this every single time. So, from the actor CPP file and actor component CPP file, you'll find it starts with tick enabled value on the primary actor tick and primary component tick. But if you do turn that off, I do recommend re-enabling the controller's tick so your input's going to be properly registered, as that's necessary for characters. Now, with the tick off by default on Blueprints and components, you can then opt into ticking when needed instead of opting out every single time. There's going to be a lot less blueprints that need tick on than turning off. So, when we do need tick, do you need to tick every single frame? If not, this is where the tick rate can come in.

you're able to customize the frequency of our tick with the tick interval value. So, a value of zero means it's ticking every single frame. If you want it to tick once a frame, you can set it to one, two ticks, .5. So, this is very useful for decoupling the logic from the frame rate. So, if you have some logic that's maybe running once or twice a second, again, if you want to change the default in the source code with a tick interval value in those files. If you do customize this, again, swap the controller CPP back to the default value; otherwise, things will not behave properly. And one final bit of advice on dump ticks. So, this is a command that you can run in-game, and it'll report a list of every ticking object in your scene, like so, and it's super useful for tracking down exactly what is going on in the game. And finally, moving on to references. So, these are often overlooked and can become a huge issue to lay into development. So, references are all of the dependencies and connections an asset.

may have so if we open up the size map, you can see that all the hard references connected to an object references are not inherently bad. The problem comes from hard references of unrelated assets, so these assets become entangled and will always be loaded together. So, this is the third-person character blueprint. Let's dissect this a little bit. So, in green, we have our materials and textures for the mesh, and in white, we have our skeletal mesh asset. On the right, there is a slither of green there as well. That's our animation blueprint. So, this asset needs all of these other assets to function properly, which in this case, this is all okay. This is fine. However, there are several bad practices that can cause entangling of other assets that should not be loaded together. So, now let's take a look at this. This same blueprint has now jumped 100 megabytes, and we're now loading in the vehicle blueprint in red. And this has happened because of one very, very small change. That character blueprint now has a variable reference to that car, to the vehicle. So, since this

character blueprint needs to understand the vehicle. The vehicle must now be loaded with the character blueprint, which isn't ideal. This also happens if you cast from that blueprint as well, so we don't want to load that vehicle asset with a character. So, what can we do to stop it? So, let's start off with a couple of solutions to our casting. So, generally, I only like to cast when appropriate, such as to self-contained items. For example, a blueprint casting to its own animation blueprint, that's fine. Those things are going to be loaded together anyway. Often, I see casts done like this in overlap checks. I find this really overkill. Replace these with alternate methods. There's more than one way to do things in Unreal. For example, just query the class of the object instead. If it's a child of it, continue. If you're checking for the player, don't necessarily cast to the blueprint, just check if it's the player pawn. Something as simple as this can remove those casts from your blueprint. Now, this isn't always ideal, as casts have an added

benefit of being able to communicate with that blueprint that you've just been cast to. So, how can we get the same behavior without the cast with interfaces? So, interfaces act as intermediaries that allow you to call functions back and forth between different blueprints without entangling them. So, you can create an interface from the blueprint category in the content browser, and it'll open up an empty list like this. So, you can add the functions in here that you want to communicate between blueprints, and then all you need to do is add that interface into your blueprint in the class settings, and you'll find an Implement interfaces category there. And then in the My Blueprint panel, you will now find the functions from our interface. So, you can implement them and add some logic there. So, all we need to do is go back to our blueprint, and you can add a Does Object Implement Interface node, and if it does, you can call that function. So, now we're able to call functionality on another blueprint without casting. Amazing. Now let's talk about our

solutions to our hard referencing problem. So, we need to solve these. We're using soft references instead, so these change the type of data that's stored in the variable itself. In 5.4, you can swap to a soft object reference by clicking the variable and just choosing Change to there. In all the versions, you have to change to a soft reference when modifying the variable type. So now we have our soft reference. However, we can't really do much with it compared to the hard one. So, to fix this, we need to use a Resolve Soft Reference node. There is still a problem, however. This node will only output a valid value if the object is in memory, and since we're using soft references, there is the chance it may not be loaded, and it's going to return None. So, we must load our assets manually into memory with the Load Asset nodes. So, there's a couple of nodes here. We have the Load Class and Load Asset Blocking nodes. These are going to load an asset but will stall the entire game until

it's loaded, and it can cause hitches. Alternatively, there is the async variant, which will load asynchronously and then output the pin once it's done. So, we can simply plug our soft reference into there, into the load async node, and then from the completed execution pin, our object will be loaded. Wonderful. And one word of warning: the output pins of these load nodes have a tendency to get things stuck in memory. So, after loading an object, this pin will actually keep that loaded object in memory for the lifetime of the blueprint, which is not ideal. So, a solution I found to this is to use the set ref by ref node to clear that value on the Node Direct, and it'll allow it to become garbage collected properly. Now, there's one final hard reference issue that you need to be aware of: parent class component assignments. So, let's say we have a master character blueprint. In there, we have our Quin skeletal mesh, and then we have a child blueprint. Let's say we're just overriding the skeletal mesh to be

the money. We can run into an issue here. If you look at the references for the money child blueprint, you can see that we're not only loading in the money assets, but we're also loading in the parent blueprint Quin assets. So, to fix this, we need to reconfigure our setup a little bit. So, instead of having a particular character be the master and have children overrides, you need to have the master blueprint with all of its functionality intact but remove any and all references to assets that are not going to be there 100% of the time. Then, have both characters inherit from the master rather than having a character inherit from another. So, if we take a look at the money size map again, it's now only referencing the relevant assets, which is amazing. So, keep your logic and functionality in the master blueprint and then have the children blueprints have references to the assets. And with that, that draws me to the end of my talk. You can find me at mat lakea on YouTube, Twitter, LinkedIn, on my website, um, if you're interested in

Joining a community of technical animators. There is a Discord server there, uh, and also if you're interested in more of my ramblings on the subject of technical animation. I've got a book all about technical animation and video games, about Meer and Unreal, and uh, thank you for listening. I do hope you've learned something and hope you have an amazing rest of your Unreal Fest. [Applause]

Unreal Engine 5 Character and Animation Optimizations | Unreal Fest 2024

Welcome to the official Unreal Engine channel!

Unreal Engine is a complete suite of real-time 3D tools made by developers, for developers. Create and take your content anywhere, from PC, console, mobile and VR games to cinematic experiences, visualizations and training applications. With Unreal Engine you get everything you need to start, ship, grow and stand out from the crowd. 

Click link below to download Unreal Engine.