1-hour of Unreal GPU Optimization Tips & Tricks

All right, so here we're looking at the dark ruins environment example from Megascans.

We have a couple of really beautiful shots here just going around the environments.

I want to try and look at this project and see if we can find some obvious performance issues that we can improve on that will also apply to your projects as they're just super common issues.

Now, there's also some things that are just common issues with things like mega scans that we might look at, but generally speaking, I want to keep it broad enough that it should apply to your game as well not just this particular example but some things will be maybe a little bit sample or material specific now i'm currently running this on a 4080

super so that's a pretty high -end gpu generally this should already be running pretty well um i would say it doesn't like run super well to be honest but it looks absolutely beautiful my goal is to try and run this in a package build on maybe something that's a little older i have a 2080 ti lying around that's used

to be a high -end gpu but now it's you know a few years old or even something as crazy as a steam deck to see if we can scale this all the way down to something um really low end so there's one like small issue with getting this to run and that is that it already relies on mega lights now Now, that's an experimental feature as a 5 .5.

And so if we just press G to get out of the game view mode, we can see that there's just this ridiculous number of lights here.

Now, they're not all affecting this scene right now.

Because if we were to look at something like these candles, it's actually that only the highest one is affecting the world.

And the other two are set to affect world is off.

Probably just some, you know, there's a non -destructive workflow.

but it's a little bit misleading in a number of lights that are actually in the scene.

We can check that out here if I just select.

They're actually called does not affect world, and we can also see that, yeah, affects world is disabled.

So it's not as horrible as it makes it out to be, but it's still pretty awful in terms of number of lights that we have here if you were to turn off something like Megalights.

And I don't really want to rely on Megalights that much, because again, it's 5 .5, it's experimental, you might not even be on 5 .5, and I doubt you want to use a experimental feature in production.

There's also some other issues that I noticed some are like specific to this project so I'm not sure what's going on but we can mostly work around those issues luckily.

So in a quick rundown what I want to check out first of all light complexity although that is a bit of a problem when there's just this many lights I can show you the light complexity view but this is just ridiculous because we have the light complexity here and it 's just basically entirely white now i think that's just because of the mega

number of lights that they placed here and with mega lights it can sort of work if we enable stats gpu we can see that the mega lights is currently at this editor viewport taking up three milliseconds or so if we press f11 we can see now it's 6 .6 milliseconds so it's increasing quite a lot already now this

is not great and also the number of lights it really doesn't show in terms of quality so to speak so if we were to just view it from this angle like this we could really solve with just a couple of lights we have of course a beautiful light falling in and we have some other like fill lights here actually I moved this mesh around I should just delete this guy because there's this beautiful

skeleton here which ridiculous amount of detail also has a couple issues that we should fix and of course running this in the editor is not super great because we have like a very variable um like screen percentage that we're using currently is on 50 percent and we are rendering this at 4k so it's upscaled from about 1080 so that would actually be a reasonable target by the way rendering this

internally at 1080p and upscaling this to 4k and that's generally what unreal engine wants us to do if we're running something at 4k i think generally it expects maybe a 1080p upscale or 1440p if we have the budget for that but yeah super project dependent of course and hardware dependent so if we want to cover everything i think it's going to be quite some hours of time to spend and

dissecting this project so we'll see how far we can get but i just want to go through some of the options that we have available and some things that will that will be immediately relevant to your project as well so the first thing i want to check out because, of course, I've already seen some of the things in this project.

So I've typed out setGPU to hide this again.

And one thing I want to see is the virtual shadow mapping visualization.

So we have the virtual shadow map, and then I'll go check out cached page.

In 5 .5, they updated the visualization mode, which is significantly easier to use than 5 .4 or prior.

Now, for some reason, this is a little bit bugged.

I don't know why in this particular sample.

it works fine in other samples but i'm only able to see this particular uh light here invalidating and i can't get any of the other lights to invalidate for some reason now this is the main light that i wanted to check out anyway there will be other lights that are potentially issues that are invalidating as well but at least they're all going to be the same step so it doesn't really matter now

it took me a little while to understand where this light was coming from somewhere coming from above there so we have this giant light causing some volumetric lights and it looks really cool but if we look here we can actually see okay so this really must be the source of the light it matches with the

shape actually what it's doing over here is just casting this light on the scene right here and it's actually massive if you look at maybe hopefully a view no this is going to help much it's not going to show us ah there uh if we just if we go into some other geometry that we can see just how large this cone is it goes

quite far um let me just press f to go back to this light well the thing is there's a bit of an issue in terms of performance because even though it's stationary well it's movable but even though it's not moving it's constantly invalidating and we can see that by go back into the cache pages view modes by

it being blue so that's dynamically invalidated so something is causing all of these pages like literally every page to invalidate every single frame and it's quite a significant light as well so there's a lot of pages and this will be costly for us and it's also not going to be the only light now luckily we have some other view modes available again just press f to go back to the light we

can use some nanite visualizations just go to nanite visualization and then i have evaluate wpo and immediately i can see the problem because all these materials all these meshes are set to green now in this case green is bad because green means that the world position offset the wpo is being

evaluated for these for these meshes this is sounds really unnecessary especially with things like Nanite, WPO is very expensive.

You don't want it unless you really need it.

And you only want it when you're nearby.

Well, the problem is that there's no distances, like max distance set on evaluated WPO.

This is something you can, for example, set when you have foliage that needs to animate with the wind or something like that.

Then you have something like Evaluate World Possession Offset that you can toggle on and off.

And you can see the toggling here where it will stop evaluating that and then it will switch to a faster render path for nanites for those nanite meshes now of course i already did a quick look at the material to figure out what this could potentially be and if we just step into this material let me let me open that

here and we have the smart master that is for something i'm assuming from mega scans now here actually is where we can find the issue it has some kind of material function contact shadows and that is doing certain things also it has pixel depth offset as a potential setting for the pdo pixel like pixel depth offset

shadows now the problem here i i'm not sure why they're using this i would have to look into this more deeply but basically the contact shadows is something that they're enabling here on this material and i'm sure it can look amazing in certain scenarios and it's probably has some really cool visual effects that we can get with it but if the level is not set up properly for

this especially with something like these contact shadows as soon as you have that you really need to properly manage your evaluation distances and maybe if you get up really close to some kind of mesh then you might want to have those contact shadows because they might look amazing i would have to look more deeply into that

but with no evaluation distance said the problem is really that all your shadows and all of these lights are constantly going to be invalidating now for some reason i can only in this particular scene i can only get that to visualize that one particular light i don't know why but the other lights are also constantly invalidating certain pages so long as i it's

you know if we just toggle to other places in the world we can see that there's a lot of sections all of them basically have a lot of green and that's all bad.

It's all of those rocks, basically.

So for now, without doing too much stuff, I'm just going to work around this issue by literally just bypassing this whole context shadows material function.

A bit of a hack, obviously, but this is the fastest way to show this difference to you.

And so we go back to EvaluateWPO, and now everything is red.

So this is awesome.

This is a way better view, so we can just go between all of them.

Let's see where we were, actually somewhere here we can oops we can fly back to that one particular light let's see let's go back it was this light and now if we go back and we check out the evaluate wp oh we actually already did

that so that's good now and now we can go back to virtual shadow map cached page and we can see that yes now it is properly working again and only when we go in and out do we see that it's invalidating individual pages because we're transitioning to a different resolution.

And so before we continue with other stuff, I want to make sure that we get a quick before and after.

So I'll just use stat GPU.

Of course, it's all in editor, but still it should be like a reasonable comparison.

I'm going to make sure it's in full screen as much as possible.

I'm going to toggle between having that WPO enabled and disabled.

by just recompiling those shaders at the moment.

And so what we want to look for with this is especially shadow depth.

So now we have shadow depth at 1 milliseconds, because that's really where the cost is going to be.

So if I reapply, and we have the original WPO again, so let's reapply that.

It's recompiled.

Let's go back to lit mode.

So now you can see that it's about 1 .7

instead of 1 .0.

So in this particular scenario, with this particular light, we shaved off 0 .7 milliseconds, which is, well, percentage -wise, quite a significant difference.

And this is just with this one major light, but basically the entire scene would have been affected by these invalidations.

But again, because of the bug, we can't really properly visualize that.

But we do see a performance benefit of turning this off.

And visually, I don't think we're going to really notice this.

So I think this is certainly a surefire thing that we should just apply.

I'm going to reapply without the custom contact shadows nodes.

And we are back to 1 .0.

Probably there's still other things that we could improve here with invalidation, but this is at least a pretty good start.

So one thing I'm going to do before we move on to anything else, I'm going to just draw the virtual shadow map stats on screen.

So I want to start for virtual, because everything is on a virtual for ShadowMaps.

Well, at least virtual ShadowMaps.

Virtuals show stats.

So we have r .shadow .virtual .showstats.

And now we can see that, okay, well, actually we don't really invalidate.

We have dynamic cache 65 and static cache 65.

So I don't see any invalidations happening.

So at least I got that confirmed.

And then once we, and if I just one more time reapply the original material, we can see that the dynamic cache is zero and dynamic invalidators is 65 so it really flipped all of them are no like none of them are dynamically cached anymore so you can see that that indeed

helped quite a bit and now it's all uh dynamic cached again so that's great okay we can just hide those stats again if you by the way toggle this and you don't uh see these stats show up even if you run that command it is all under shader print so if you have r .shader print that should be set to one because otherwise it

might not render so this just in case it doesn't show up for you then let's hide this step gpu for now and also let's hide the virtual show stats we don't need this anymore then let's move on to something else that you will very likely suffer from without realizing and you can already see this happening over here

where if we wait a little bit we have these particles that are just beautifully stimulating in the world and if we use shift plus forward slash on the keyboard it will forcefully reset all of the instances in the world so that you can see where they're happening or what they look like without having to wait for them

to re -trigger but the problem with that is that it just costs CPU and GPU time if they are also GPU particles regardless of whether or not they're on screen so we can actually show this also in another stat it is Niagara system counts these don't autocomplete unless you're playing so that's a little bit annoying but we

can see that we have 59 of these particle systems and they're all the ns pebbles we can just search here for pebbles and we can see these are all the pebbles that are active so we have them really oh we even have them outside so the the funny thing is that these are active even though we're not outside at all like

we're not even near to this or we weren't near to this um but they're but they're now all um actively simulating and doing nothing now we don't really see much of the cost with the system counts this is just to show like okay which systems are in the in the level and how many of the systems are there we have other stats for

that we have niagara systems and this will show us a little bit more already on the cost so i also like this one because it's also quite simply it's also quite simple it just shows the cpu costs of these so it has like gt or gt cnc and rt so game thread that would just run synchronously on the game thread so that is probably for us the worst one if that would be

high uh in a gt cnc that is the concurrency the concurrent call so that is game thread related but it's running on worker threads and then we have rt that is the cost that is running on the render thread and so So this is not ideal that these are running, especially if we use our worker threads for a lot of other stuff already.

If we want even more detail, then we have also stat Niagara available.

So this will run even more.

Maybe by now I should just hide some of the others because it's getting a little bit full.

So we can properly see what we have.

So this is the most detailed version.

and here we can also see a GPU dispatch setup and we can see other GPU costs here as well.

And this is very interesting because now we can very clearly see that and also we see the GPU memory that's being used, the GPU instance counts.

So there's quite a lot of stuff here, which is excellent because we can see that, okay, there's quite a lot of stuff going on with particle systems, but we're not seeing much of this.

And that's because there's just no culling by default unless you specifically set this up in your Niagara systems. So let's very quickly go in and find, first of all, find this particle system.

I'm just going to get Niagara system.

And also because I already have the content folder, the root folder, select that, I can just easily find NSPebbles.

And the problem is going to be here in the system where we don't have an effect type specified.

You can also have things specified in the renderers where you can have individual culling and things like that.

But I think the very first thing you should apply is an effect type.

And as you can see that all of these are GPU -based.

Now, it's not always necessarily good to have GPU particles whenever you can.

Especially in a sample like this, we're entirely GPU -bound.

We're basically doing almost nothing on the CPU.

and so it might be better for certain things to just be a cpu particle system rather than a gpu now in this case i'm not too keen on getting or changing all of this also they have things like collision setup which is using gpu distance fields for your particle systems you should really consider like does it actually benefit me to have this be a gpu particle rather than just always trying

to have everything be gpu and that's really a case by case basis always so we have the ns pebble so i'm going to create a new effect type i can also just create asset here or just use it for the content browser as usual i think we are actually i'm going to put this in effects yeah i'm just going to put it in the root folder

of the effects i'm going to call this um ambience effect type i don't really have a particular convention for this at the moment but just i want to set this as an ambience effect type you can make it as specific for a single particle system if you want but generally speaking you want to want to categorize this for a very

particular set like maybe your muzzle flashes will in your shooter game will have one effect type and maybe the bullets projectiles will have another one the impacts might all share one effect type etc so let's open that up and do some really basics set up.

We don't have to do a lot here.

I just want to have the absolute basics.

So let's set up a system scalability settings.

And if we open that up, we can specify for which of the scalability settings we want to enable this.

Now I'm going to only have one at the moment.

But you might want to, for example, set them high in Epic.

Cinematic is not super relevant for us, but if you have a cinematic preset, that's of course relevant.

And then we can add another one.

And then we disable these others.

So now we have these settings for the low and medium spec and then high epic cinematic, their own setup thing.

But I'm just going to keep this to one for now to keep it very flat and simple.

So we can set up things like, okay, beyond this distance is going to be called, well, I don't really want to have a distance call because I think seeing them from a really far distance still looks pretty cool.

So in this particular example, I'm not going to do that.

but i do also not want to have budget scaling we're not dynamic enough for this for this scene but i do want to have well also pre -calling actually we don't have that but i do want to set a max time without render if we're not rendering for like i don't know half a second just call us just stop rendering us entirely and then the allow pre -calling by few frustum this is going to be super

relevant for things like gameplay where the gameplay might spawn the system or might spawn the like a muzzle flash or something like that and if we enable this it will first check the bounds of the system so you have to make sure you have good bounds and then it will decide okay well actually we're not visible we would not be visible right now and so we just don't even bother spawning it that's

super valuable if you want to have something like a very short living protocol system that if you don't immediately see like a muzzle flash don't even bother instancing it because you're never going to be you're never going to miss it So we're also just going to enable this.

I'm not entirely sure how they spawn this.

Oh, it's just a regular system.

But especially things in gameplay will be able to pre -call, which is really, really nice.

And also max time outside view frustum.

That's again, I don't know, set this to half a second or so.

We have other options here, but that's not super interesting for this particular scene.

We'll have more detail on that in other videos.

So let's save this guy out.

let's make sure this guy is also it's applied and we can just apply this and so finally before this starts to work because these are ambient little systems that are already in the scene having in this update frequency be spawn only doesn't really work for us because we're not like a muzzle flash where we're only wanting to maybe check this on the spawn or something but we want to make sure that we are checking

this constantly well we don't necessarily need this to be continuous like it It doesn't have to be every single frame.

Maybe once per second is good enough.

And that will say, like here, you can see that by default, that's one second.

Every one second, it checks it.

For example, high will be 0 .25 seconds.

Continuous will be every frame.

Now, that's a bit extreme for our needs.

So I'm just going to set it to low.

That's all fine.

And now, if we go back in, we can see this counts quickly going down back to two.

so now two of them are shown here and actually if we go and then re -enable some of the counts here we can also see like yeah we indeed have only two of those pebbles currently active which is significantly better than the 59 that we had enabled before and besides this affecting the cpu there's because there's

these are also gpu particles of course if we are actually rendering them then it would affect things like translucency but if we're not rendering them then it would still be able to affect things like the compute shaders that are running for those gpu -based particles so if i just quickly do stat none to clear all this

out and then do stat gpu again and if i were to maybe clear this guy out let's respawn this and now we should see uh there we go niagara gpu simulation is about 0 .1 uh it can spike sometimes a little bit higher maybe if we uh

about 0 .1 uh it can spike sometimes a little bit higher maybe if we uh depending on like how many particle systems are actually active so if i use shift and i just re -trigger them then we could see that it does actually spike a little bit higher like 0 .6 actually 0 .7 between like even up to almost one millisecond

so it does spike up and down a little bit based on how many of those systems are currently simulating, colliding, and everything like that.

So certainly having these, having this effect type set up for this ambience is going to be very, very helpful because now we should be able to probably not even see this anymore.

Ah, there we go.

Actually, I can see it here.

So it's 0 .02 by just setting up this little effect type that took us a few minutes.

And you want to make sure you enable this essentially on every single particle system well in in your game but also in your environments so fires um just ambient low candles if they are if they happen to be particle systems in this sample they are not they're actually just uh simple animated planes so that would be that's another nice step to improve

performance in this example so then let's have a look at some particular assets actually because i happen to just find issues with assets by just sometimes opening the first asset that i would see , I would open it and would immediately see an issue.

So let's actually go in.

Rather than me knowing which assets are problematic, let me show you.

Well, some of them I just stumbled on luck with some luck, but others I used some tools.

So let's just use the tools.

And actually I used, let's see, audits.

And then we have these statistics panel.

I still like this.

It's a really old tool, but it still can be helpful sometimes to find out what's going on in your level.

so here we have the primitive stats enabled and sometimes i like to just look at individual things like maybe uh what do we only have one instance count of like do we need this asset to exist at all because if you only use it once and it's not a hero asset it's not an important thing at all maybe if we just

delete it from this level it doesn't even get used in our game anymore and now we don't have to package that assets the the static mesh we don't have to package maybe even the material or its textures.

So this can really trim down on assets.

It can be a bit of a annoying thing to, you know, go through all the assets, but it can be, it can pay off if you apply this pretty broadly to your, to your level.

Now, these things are mostly going to be, um, like pretty unique meshes.

Um okay.

So we have these columns, uh, for example, we have, uh, the armor.

Well, that's certainly going to be one -off because we only have this one skeleton mesh but we still really want the skeleton mesh but you can really see this and really see like okay there's quite a few that have one instance or maybe only two it is a thing you could consider for your game to really optimize things and it's going to actually affect

a few things so it's not going to only affect your packaging sizes which is still very important of course because why do we have so many games that are 100 gigabytes plus it's just that a lot of stuff gets stuffed in there with poor consideration for the end user the other thing that it might affect especially if

there's unique materials on these is that we do in a way increase the nanite draw calls now nanite is getting extremely good at has always been really good at draw calls because it does instance things so well but if we enable something like nanite stats oh nanite stats actually i'll have to make this a little

smaller we have these shading bins over here and we have 277 shading bins so that's essentially 277 draw calls and 213 of those are empty that means they were sent to the gpu but they didn't do anything now i believe in recent versions maybe 5 .4 or so it's going more and more towards compute shaders for also these

maybe 5 .4 or so it's going more and more towards compute shaders for also these shading bins which means that there's less waste they can be pruned much more easily so there's less overhead to having a lot of these empty draw calls essentially earlier versions that was a little bit worse you had to be more considerate but still i would say like probably good to be considerate about

this and now if you just zoom like look around we have the same amount of draw calls but we have fewer empty draw calls we're actually using more unique materials and if we were to just grab this one guy and delete it we go down one draw call because that was only there was a unique material on this guy uh so that's another thing that if you were to this like remove a bunch of these unique

assets essentially your draw call count is still is going down regardless of whether or not they are on screen now it really depends your mileage may vary whether or not this is going to have any impact on your scene but just a little bit of a shout out to shading bins and the number of unique draw calls that you will be generating especially if you're using things like material instance

dynamics a lot this could really balloon to thousands which is you know not ideal especially because we really don't need material instance dynamics anymore we have better solutions for that such as custom primitive data which doesn't require unique materials then let's have just another look at some other things that i always find interesting um there's also some like light map stuff here this

is not super interesting anymore and also this ui is not always the best uh to resize but we have well triangles sure we have also instance counts it's nice to see like how well we're instancing certain things but really the size is interesting because if we just look this up well actually okay so the size of

these vines is kind of crazy um i wasn't expecting that so let's have a look at this uh first of all i see that these guys are about a million triangles and for some reason nanite is not enabled so this is going to be a bit of a nightmare for a lot of things uh including lumen

performance but also for well shadow performance if these guys are shadowed at all if non nanite virtual shadow maps is enabled and that's going to be a disaster but we can just click on this little the three actors to actually see where they are being used uh actually that's just up top the stairs where we just were we were just in the room right there and so

they're just right here up the stairs so for some reason these guys are non -nanite now i don't know why uh probably just a bug i imagine just an oversight okay enable nanite support really should be the first thing we do with this ridiculous number of triangles um i think it's going to be a bad time not having

nanites enabled and then for things like lumen and purchase channel maps it's going to be really bad so let's just apply this and now we can see okay well at least our fallback triangles are now like nice and small those fallback triangles are used for a number of things including things like hardware ray tracing for lumen and also for collision generation now realistically this really doesn't need

collision but again unreal has everything just enabled by default so yes it will have collision that's also why this was just so absurdly large because the collision data was really massive so if you just refresh this now it's gone right it disappeared so if you just search now for Vine, we can see, OK, actually, the

size is now 1 .2 megabytes instead of something like, what was it, 90 or something?

I'd already forgot.

But it was way, way, way, way, way too much.

So like a complete utter waste of resources.

And it was just because Nanite was not enabled.

Now, actually, if you're curious to see, also easily just browse your level and see when things are not nanites, I actually like to do the following.

I'm just going to disable it again.

And we have the show flag dot nanite meshes.

And if I just disable this, now actually you can just very crudely go through your level and see, like, OK, actually, so selecting does still use the original scene.

But so you might sometimes have to fly up really close to be able to select it because the other stuff might still be in front, even though it's not rendered.

But then we can see, OK, actually, yeah, these vines are not enabled.

Also, these other ropes are not enabled.

That's also one.

Of course, there's other ways to go about this.

You know, we have a whole view mode available for this.

Let's see, mask.

So this will also show it for us.

But, you know, if there's something behind this wall, you would not see that it wasn't not nanite, right?

So this alternative, let's say, hacky approach can also be very useful.

that if you just hide your NetApp meshes, it will more easily maybe show that your level should be mostly empty.

But yeah, the mask view mode is also useful.

Okay, let's re -enable these guys.

Oops, let's re -enable.

Down is more we could do with this asset, especially regarding collision, but I think this whole level needs a collision pass, honestly, because there's just a lot of memory wasted on collision.

But since this is not a gameplay -based map, This is purely a visuals map.

I don't think they really cared about it all that much.

But since people are going to extract meshes from this and to use in their own scenes, I feel like they should have cared about this.

Anyway, let's move on.

And let's have a look at the second biggest, which is now the biggest.

And that is actually this helmet.

And let's actually select it in the world.

That is more interesting.

Now, this is going to have, I mean, it looks really cool.

And they have like a pretty far near clipping plane.

by the way, just a little bit annoying to see.

But we can just hold down right mouse button and just press C to really zoom in.

So we can see all this incredible detail.

It looks really freaking awesome.

But again, there's something up with this, because 66 megabytes is way too big.

While we're at it, by the way, I just want to hide my nanad stats.

Nanad show stats, 0.

In case you don't know, using a space in your console commands makes it so much easier to find your commands right if i had to remember that there was like r .nanite .showstats i would just constantly forget exactly what it was so just nanite whitespace and then something with stats you will also see the um the results like maybe this is super obvious

for everyone but i don't know it's it's helpful okay so this one is also way too big definitely a problem with the asset so let's double click it and open it oops press f to focus and also this is a problem because now it is enabled but look at the fallback triangles in the top left we have the see we have the fallback

triangles is 800 000 triangles that's awful truly awful it's the same as the nano triangles and also if you're on an earlier version the 5 .2 or anything like that a lot of these are going to be quite poorly set up probably like not guaranteed but i'm pretty sure a lot of them were set up poorly maybe depending on how you upgraded your your assets from like 5 .0 to some other version but if

you have a more recent version you should be fine but in this case you can already see that it's not fine because the fallback target is not set the default it's triangle it's percent triangles and that's 100 that's ridiculous okay Okay, so let's set it to auto, which is the current default again.

And let's apply the changes.

And again, the reason why this is so awful, even if you're not, or even if you're just using Nanite, the fallback triangles, fallback mesh is still very important for, again, for things like collision generation.

So something like line traces would have been line tracing against a helmet that is like 800 ,000 triangles.

and we can visualize this also with the visibility collision so let's see if you can't really see this well maybe just let's say let's hide meshes so under the show flag let's hide stack meshes and here we can see still I find this to be a little bit ridiculous because we never need this level of detail in our collision

so there's a couple of things around this or a couple of ways around this and also i mean let's have a look at this stuff actually like look at these crazy the crazy detail in all of these uh wooden planks like this should just be um a cube right it should just be a simple primitive rather than something as crazy as uh like a highly detailed with all the grooves of the wood

but anyway let's first let's first let's try to focus let's try to focus on this this particular asset because at least now with this fallback set properly we have 10 thousand triangles to consider that's already significantly better than what it was before uh so we will have not improved both well the collision performance in this environment but also we'll have improved things like the ray

tracing cost that will still at this time use things like um the fallback bash because not everything supports a nanite at this time okay Okay, so that was a quick, oops, I don't, oh yeah, oops, right, because we have disabled static meshes, we completely messed that up.

Another cool thing that I think is just funny is just if we go into our nanite visualization and we just check out triangles, we can see actually they modeled out these, all of these spiderwebs, like cobs, spider cobs, what do you what do you call these things cobwebs yeah sorry all these cobwebs are

just modeled out which is pretty cool and it's gonna i guess perform a lot better than something like uh mask materials when you use nanite but still it's uh i just thought it was interesting because before that we would never um really use triangles for for something like this but with nanite it's all possible okay so let's just do a few other things um if we go back into the stat gpu i think this is

just interesting to continue going down some examples or just going oops going down some of the costs here i can see a lens flare is enabled 0 .7 milliseconds

but if i just disable lens flare and again if i don't remember the the command exactly i'm just going to type out lens flare and we see lens for like quality and then in the output log i'll see okay the current setting is two uh actually was set by by scalability so it is controlled by scalability i'm not going to be worried about that right now i'm just gonna set

it to zero that's for quality zero uh now we can see the cost is entirely gone okay that's great but i want to check out quickly if i can find a place where this is going to affect me so first of all let's remove that gpu i don't care about that right now but i do want to ab test to see am i using this somewhere i don't

know if i'm using lens flares a b test um and then we have that now we have now i do have to remember the uh the the um command r dot lens flare uh oops lens for quality luckily i can read it and we're going to be toggling between two uh sorry

between zero and two so a b test r dot lens flare quality zero two zero space two uh and now we can see that we're toggling between them now of course this is just uh it's going to give us a performance comparison which is nice but that's not really what i'm on about i want to make sure that i can actually see

if i can find the visual difference if i can see any kind of visual popping okay so yeah here we can see the difference right we can see it popping in and out but do we really need this i mean if we're gonna be using this on a lower end platform if we had it turned off would we have noticed that's really the question

like there's there's a there's a visual difference but could we not just maybe scale some other value up a little bit to get this same lighting because it's mostly just blur like makes the whole scene a little bit lighter around where it is um showing the the brightest spots in the scene like really not worth any any kind of consideration that's like 0 .7 milliseconds is way too much also we

don't have any oops we don't have anything with the candles or something that does some kind of crazy lens flare effect let's have a look yeah so it really just is sort of making the whole thing a little bit more bright um and then you can consider do we want to spend that much um gpu on this on a 4080 super

like what if we go to an even lower end device now of course it's already set up in scalability right so if we go down in scalability probably the cost is already smaller but yeah so let's first of all let's a b test stop this so really we should be able to disable that and for some reason i'm now currently uh fps

locked i'm not sure what i did or if anything has happened uh but just you know setting t max fps to 999 got rid of it for now i'm not sure why that was suddenly happening because i didn't see that before maybe i changed some some settings somewhere i don't know i think for this video the final thing i want to just call out um because we're just exploring this scene, is that there's

actually a lot, a lot, a lot more to talk about.

I think I'm going to do two more things for now.

The first one being the basic setup of light calling and making sure that lights are of a reasonable cost.

Now we have mega lights enabled and we have these ridiculous number of lights over here.

Now that's already going to be dramatically bad but there's a couple of things we can just really easily tune here the first one being just attenuation radius that's the most obvious one that um you know honestly still gets done incorrectly all the time like for example we have this wait this light is got selected so we press t then we disable

the translucency selection so now we have the option to select this light.

Now, this light is really cool.

It's a hero light for sure, but if maybe we can go to wireframe, well, no, we can't because that's nanite, so it looks impossible to see.

I want to just quickly show you just how large this light is, really.

See, it's really massively bleeding into this other world, sorry, this other room, and it has a really large attenuation radius and a really large cone and so it also goes underground for quite a bit over there and so the problem is that it's going to add cost even if we're

quite far from it and especially because if we go back to lit mode if we were to just disable the lights and for that we can always use affect affect world it doesn't really affect this section of the world at all well okay here it does all if we're just back into that room that's obvious but here it still has the

attenuation radius and it doesn't affect the scene whatsoever so realistically if we want to make this perform well on any kind of device we should realistically just be a little bit more conservative when it comes to well attenuation radius

and so i think we can just reduce this one like we can make it smaller without trying to affect the overall scene too much like you're going to really upset artists if you're not the one that places light and you're going to be messing with it but we really have to consider this and now we can see that on the top here it's going to be reduced a little bit but

you have to also consider is it really going to be worth the cost right do we can we afford these lights to be this massively um this this large um and affecting us in a much wider area in terms of light projection cost than what we were expecting could also affect things like shadowing but that's a little bit different for virtual shadow maps that works a little bit

different for like non -virtual shadow maps and whether or not things get invalidated or re -rendered but or sorry or get cached but the bottom line is it's still going to affect our light projection cost right that's just going to essentially render the shape of this cone on screen and so So the more our screen is affected by these lights, essentially that's going to affect the cost of the lights.

And so we want it to be small, right?

And the second thing we want to do is have something like a draw distance enabled on this.

Even with this light in particular, we should be able to set up a draw distance.

So let me just make this a little bit more readable again.

I'm just going to type a distance.

And then we have max draw distance, max fade range.

And what I usually would do is try to find the max visible distance for the light now here this is really small right we just go around the corner and so we're already really close but maybe if we were to view this from this bridge right here and now i want to deselect this light but of course we want to be able to tweak it

so i'm just going to use the little lock so now we can escape we deselect it we no longer have that distracting little thing also we can just use game view if we wanted to keep it but without all the distracting icons and then let's well first of all let's set a draw distance of 100 where it's definitely going to be

turned off right now we can see that this is turned off it's not it doesn't look great because we want this to be you know this looks this looks better to be fair it's not as big of a difference as i was expecting maybe we could make these candle lights more pronounced as we're this far away but that's you know more of

an artistic thing as well so let's this to let's just find the range like this okay so there we go we can slide it here so around this range is when we enable it um sure and then of course we never want to pop this in because if we were to like do this this looks awful for obvious reasons you don't want to have pop in so

we could set like usually i start with a fade range of 750 it's just the number that i end up using which looks pretty well but it really depends on how you're using your lights see now it sort of blends in as we fade in and out though probably i want this range to be even bigger so that the player can't see it so

that it gets called entirely beyond this range so then the light it's the shadows are going to be called we don't have any like accidental like invalidations and we don't have any light projection cost even if it's on our view because we just have disabled it and so let's use some numbers in order to actually check out whether or not this is

going to work but for that i do at this time at least want to disable megalites because that's going to be messing with our stats a little bit and also again megalites experimental and just certain stats are going to be different so i'm i don't really want to use megalites for this particular little test whether or not it gets cold or not so i'm just going to disable it are the megalites that

allowed zero uh it does have some overflow and has some other issues again because as seen is definitely made for mega lights not for anything else but with that and again just make sure we have the draw uh distance and set up so that it will fade in and fade out mega lights is disabled and then i want to set

up a draw count as one way to show you just how many lights we have like now we have 124 lights also if we use something like stat gpu we should be able to see um uh let's see lights there we go it's actually the number one cost right now the lights so this is the light projection cost this is not the shadow

casting cost it's under shadow depths but the um the projection of the individual lights would be under here uh now we 124 lights that we are actively rendering that's pretty that's a lot now that's maybe a bit too much also it would be less by the way if we had uh mega lights because i guess the stats just work a

little a lot differently and how it calls lights.

Honestly, with Megalights being so new, I'm not too familiar with how it operates.

That's why I also just disabled it for this particular test, especially because I doubt people will want to use it immediately.

So if you just set this back to zero for a second, now it's definitely enabled.

Let's just go back slightly.

So we have 116 lights.

And now if it definitely calls this, we have 115 lights.

So we can see that indeed, we have these lights getting called.

and then as we approach it well actually a lot of lights go up but that's just because other lights um get visible or started getting projected and so there's a maybe a chance that our um light projection costs would go up a little bit or go down a little bit depending on whether or not we have those light enabled or not it's probably not going to be a huge

difference because we have just this many lights going on but yeah with stat draw count we should be able to see but with that draw count you can see kind of the the calls that are being made and whether or not like you have like an excessive number of lights that are currently being projected which we definitely do we have now even 180 so 100

260 lights so yeah we have a lot of stuff we have a lot of these these kind of lights that are being currently projected so that's something we should really focus on if we wanted to get good performance out of this because we can even see that the light projection cost is significantly higher than even the shadow drawing cost which you wouldn't really see all that often and if you do

then you have something to fix or you have incredibly well cached shadows could also be so the next step would be to set up like the attenuation radius and honestly the and the attenuation radius and also things like draw distance on these individual let's see let's me reselect it i still had to unlock on the

individual lights and actually this is also set to an attenuation radius of two now if actually if you set this to like even like 50 i already tried this out a little bit it won't even show that much of a that much of a difference um maybe a little bit like maybe 100 or 75 you can really play with this but it has to be as

small as possible and then the other thing you want is i mean do we even really need this many lights in the scene like because they still use other things like these fill lights right this is still other stuff that it actually uses a very large radius which you can again just i don't even see the difference like

i can see it at the end here in a small little radius but it's just a like a way too large of a radius um and honestly even with megalights we shouldn't really let this happen right we should have small radius we only use what you need the other issue that we'll have and that is something we could fix in the material with this particular like let me just disable stat gpu again it's

really getting in the way this little light really is required to be rendered for this um candle wax to show up properly if we were to disable the lights let's say affect world now it i mean it looks cool of course but it no longer shows the lit view of the candle wax so it matches visually matches if whether or

not the light would be on, but of course, this is still shown, right?

So we would also have to disable this mesh.

That's fine.

Not a big deal.

It looks pretty cool, by the way.

This whole scene looks amazing.

Again, it just has some performance opportunities.

So you would hide this.

You would hide this guy.

Let's see, visible.

And then if you just disable the lights, now it is properly disabled.

So that looks visually really cool.

And it works this way because it's using subservice scattering this doesn't always work and maybe i don't know maybe on lower end platforms you might not want it you might want to have a cheaper solution because you can actually fake this same thing in a material we we just we know the object bounds of the candle and we can sort of have this gradient effect to still have this light fake transmit

through the environment so and you know we've done that before it's it's not that crazy um could easily should easily be doable and you would need that actually because if and also actually the lights um the the shadows are really glitching out right now but i believe that's just because of the one pass projection is overflowing so we have all of these broken shadows which

is you know not really concerned right now we would have to first optimize these lights to be these candle lights to be less crazy so we could spend more time on this maybe another time i don't know the other thing you could consider doing is like especially on like lower end do you need this many candles could you just uh

you know oops could you grab this guy or even this guy that's even like basically already hidden for some reason i mean maybe just delete this this is just not properly aligned anyway actually and so if we want to hide this then we would go to the engine scalability and it should be under effect so if we set this to low

well actually now a lot of things are going to be recompiling so it has a of side effects but we could mean in the meantime set up detail mode uh let's set it on but we could set it on a for example on a on this particular mesh or if we want to set it only on the light we could disable the light based on the

scalability oops based on the based on the scalability here maybe disable a light maybe disable the mesh entirely so we could we could play more of that maybe in another part because this is already really long and there's still a lot more to talk about um then the final thing i want to just remind you of that's also

happening is um that by default in this particular sample the tone mapper sharpen is already set to two and that's just enabled in the project settings we can see here project settings also this is really awesome they can set the history of how it was set this wasn't available in earlier versions i think like maybe five or four or something introduced it i don't quite remember very helpful so that

you know like what actually caused this this console variable to be this value but we also had this right we had last set by we already knew this but we didn't know the history uh so that's that's very very nice so tomepper sharpen is set to two and this is actually a really big deal because if we just disable this i'm

just gonna get in some like scenic view i don't know let's me just this area of course shadows are messed up because of the mega lights not being enabled maybe i should just enable that again um mega lights and allowed one okay so this fixes that issue looks a little bit better but then let's go and set sharpen to zero now

i think in a in a video in a compressed video it might not show up but this is blurry this is blurry as hell like if we were to zoom in on this it really gets muddy um and it's also in stationary view so setting this back to two has a huge

impact on the quality of this environment so i feel like this one concept variable is really saving this sample from looking fine to looking really excellent of course like it looks good without this concept variable uh i don't want to be too extreme about this but it's it's really an important concept variable that

i kind of emphasize enough just how important that tone up or sharpen is for this particular scene to look this excellent and that is perhaps you could consider that as an issue I would probably agree with that because it's a little bit problematic that without sharpening, it looks this blurry.

That is where we're at right now.

So definitely consider this also for your own projects to have the tool mapper sharpened.

Maybe two could be too high for you.

You could also set it to one or I don't know, half maybe.

That should still have an influence.

Play around with this in your own levels.

It can have a fringing effect sometimes on certain meshes.

and i think this is mostly due to a particular kind of fog i would still have to look into this a little bit more on exactly when this can happen and how we could avoid this but make sure you properly test this like tone mapper sharpen but really consider this in your own projects and see uh whether or not you get good results of that and again you can do a b test to run that tone

mapper sharpen and enable it and disable it and just see how enormous the visual difference is especially in like this sample but also probably in your own projects okay then we'll do one more we'll do one more um i want to just show off one more thing and this is um not really a scalability option or i mean it's not set as a scalability option by default in unreal but i feel like it

should perhaps perhaps it should be actually i'm gonna set this back to epic for now i don't want to make i don't want to have anything messed up and that is actually the nanites max pixels per edge and that's actually that's actually huge so max pixels per edge is by default oops that doesn't show properly max pixels per

edge is set to default by one or at one and that's of course the most excellent view of nanite it looks absolutely incredible this is what we would want but if you are if you have a particularly expensive vis buffer or you're just on lower and hardware and your gpu can't keep up there is the option to maybe

reduce this a little bit and i'm gonna set it 10 like this is relatively extreme and this is really gonna affect the scene i don't know if we can really properly see it let me just toggle and i think you should look really at the ground pebbles in the middle of the screen to go between 10 and 1 where you can see a little of

detail being added back in uh also with this the lot transitions might not be as buttery smooth so if i set this to 10 again now if we were to zoom in on this particular um mesh we can actually see the geometry sort of blending in like now this detail that super detail doesn't even exist i'm

not sure if you can see that in the video again because it's just going to be so small but if we just zoom in this the detail sort of appears um so it's like much more aggressive in the lotting essentially but uh let's have a look let's see if we can go do a bit of a comparison in the

performance now we have nanite vis buffer of 1 .8 or so and now the nanite vis buffer is let's see 2 .3 let's 2 .2 2 .3 so there is a bit of a difference here and this is just some view some scene it's pretty um detailed scene to be fair

but maybe also like on lower spec machines you might see a bigger difference and depending and of course it also was setting it to 10 which is maybe a bit too high even like two or four or maybe six could be useful to scale down now again by default it's not set as a scalability setting so you can't just put this in your scalability groups and just be done with it you have to manually

manually set this but again it might be very useful for you because it can really reduce um the vis buffer cost and if you do it more sparingly maybe uh let's say the four uh you might not even notice it like once you're playing you might not see that the that it's actually set to four and then uh now we have to set the

four and it's below two like mostly it's below two so that's great and and actually to visualize this difference is see um we can either use clusters or triangles i'm just going to use clusters because that's going to be more easily to see in a compressed video i'm going to toggle between four and one we can see

that there's just significantly more detail like now even at 10 some are not even colored properly anymore and maybe maybe this also tells us that we've gone too far i don't know but you can see just the number of clusters and the number of clusters really influences the cost sort of the performance and cost of nanoviz buffer among other things but clusters is really like a very easy way to can that

you can tell like okay we might have a performance issue if we have like a ridiculous number of clusters on screen let's go back to lit so there's a thousand more things to talk about in just this sample alone but but i think this would be a decent starting point of just having done some optimization now we've done is very very

locally and not everything is applied like if i mean lens flares back on right so most of our optimizations haven't been applied in this final moment of the video uh so we didn't really move the needle all that much because you know a lot of these things are just uh we reset to the defaults but this can really move the needle on your projects and

uh i would like to maybe see if we can continue this video uh with more videos that we can really nail down performance And eventually, maybe, and honestly, I don't know at this point if this is going to even run on a Steam Deck, but maybe we could get this to run on a Steam Deck, see just how far do we need to scale down

to get this to look decent and run at 60 frames per second.

So that's it for now.

I think we covered quite a few things.

It wasn't super coherent, perhaps.

It was just me going through the scene.

But there is a, there's just a lot to talk about when it comes to this environment.

I mean, it's just, I don't know, there's a thousand things.

I could just select these fog planes here.

And if we drag them up, we can see like, okay, this is crazy.

Like, why does it have so little coverage on such a mega plane of translucency?

We'll end up with a lot of overdraw on translucent meshes.

So, you know, just selected one more asset and we have another problem, right?

So there's a lot of other stuff.

There's a lot of other stuff that we could improve on.

But I think this is a good start for today.