Nanite Performance is Not Better than Overdraw Focused LODs [TEST RESULTS]. Epic's Documentation is Dangering Optimization.

Development Platform & Builds Debugging, Optimization, & Profiling
, ,
266

Is there a complete benchmark of this system, for example on the City Sample, versus World Partition? With a full comparison (CPU, memory, VRAM) and also using Unreal Insight to allow for comparison and an in-depth analysis of all this?

I just quickly reviewed the provided documentation and presentation videos. It seems more focused on managing dynamic actors spawned in the game world rather than handling actors placed in the world by artists, as World Partition does with HLODs, full deloading of actors in a cell, etc.

268

Yes, all of this is there to optimize real-time actor spawning. The system is not meant to replace World Partition, most things that make up a world are, 99% of the time, static meshes in ISM/HISM anyway.

So, I don’t see how you’re going to effectively manage your open world for the environment (which will make up 99% of what’s in memory). You’re not going to handle thousands of actors with this dynamic spawn plugin, it will definitely require World Partition or a similar technology. You can’t just leave tons of actors in memory even if they’re ISM actors representing your world, they’re still heavier than HLODs of a WP cell.

1 Like
269

time and time again people have proved the ineffectiveness of nanite. Lumen can be used in some cases.
Epic is catering to the wrong industry, and it shows all over the place. Just watch any of their recent presentations and you can see who they’re catering to.

1 Like
271

I think you’re missing a key point here. The landscape is just one of the thousands of actors your game will have to manage. On your map, you’ll be placing thousands or even hundreds of thousands of elements, right? It won’t just be an empty, uninteresting landscape.

So, how will you handle loading and unloading all these elements without World Partition? HLODs aren’t just for terrain, they’re essential for all actors within each cell.

For example, the Matrix demo leverages HLODs extensively, using simplified cell representations to unload as many actors as possible and minimize computational load on the world.

2 Likes
272

I honestly have no idea what you’re talking about, and I also don’t understand what point you’re trying to make with your comment.

What exactly are you complaining about? I see over 120 FPS in your screenshot—that’s more than playable. You could just as well be rendering a black background at 900 FPS on a GTX 750 and then complain about poor LODs dropping your performance down to 400 FPS. Those evil LODs…

Could we PLEASE stop taking Stone Age tests at face value and instead conduct context-specific tests that yield better and more meaningful results than these:

What actual performance improvements have we achieved? How many milliseconds does the GPU take to render a single frame?

Only milliseconds matter! If a test does not specify the hardware used and the ms times on CPU & GPU then the test is simply meaningless.

1 Like
274

In Silent Hill 2, very few models actually make use of Nanite. From the tests I’ve done, such as in the apartments, disabling Nanite has no impact since there are no meshes utilizing it.

In the forest at the beginning, I found a mesh some decorative logs that correctly switches to a low-poly fallback version when setting r.nanite=0. Overall, most of the rendering in SH2 doesn’t rely on Nanite, and the game doesn’t even use Virtual Shadow Maps (VSM), which clearly shows it’s not utilizing these systems intensively.

Considering the heavy use of vertex painting throughout the game, which Nanite doesn’t support (yes, an alternative is coming in 5.5, but the game was built on Unreal 5.1), it’s understandable that Bloober didn’t really utilize Nanite.

This raises the question of the benefit of mixing both rendering methods (classic LODs and Nanite) when the game uses Nanite so minimally, only here and there on a few meshes. It incurs a significant performance cost for little added value, especially given that the classic meshes, which make up most of the rendering, don’t even occlude the Nanite meshes.

1 Like
275

I conducted some tests myself, and yes, it turns out they did use Nanite for a limited set of objects. They clearly should go only with LODs in this case. Especially that they didn’t use Nanite for trees which is understandable given that Unreal Engine 5.1 struggled with opacity masks and WPO.

They could improve the performance with a lot of other techniques. They don’t even use LODs for the rest of the objects, only for foliage. (you can see differences if you change “foliage.ForceLOD” but not when you change “r.ForceLOD”). There could be a performance boost if they added LODs for any other objects, not only for foliage, and enabling nanite for certain meshes.

Or if they adopt a more Nanite-focused workflow, they could separate the trees into two meshes, one using a solid material (nanite) and the other with an opacity mask (non-nanite). This approach would allow Nanite to be enabled for the solid parts, potentially shifting the balance toward better performance. This could be effective if they also enabled Nanite for other meshes currently disabled and lacking LODs.

For instance, the cars are highly detailed and don’t use Nanite, yet they also don’t have LODs, which is a very strange decision.

It’s a very odd and disappointing mix of Nanite and non-Nanite meshes. However, Nanite isn’t solely to blame here, especially considering that this game performs similarly or worse than the City Sample, which doesn’t rely on a dense “wall” of fog a few meters away that could easily be used to increase the performance.

There are a lot of settings that could improve the performance with minimal visual change instead of disabling Nanite for meshes (Of course, it depends on resolution, GPU, etc.) Example:

Default Settings: Nanite ON, r.VolumetricFog.GridPixelSize 8 - 9.4ms

2024-11-12_15h37_22
2024-11-12_15h37_221920×1080 149 KB

Nanite OFF, r.VolumetricFog.GridPixelSize 8 - 8.8ms

2024-11-12_15h37_35
2024-11-12_15h37_351920×1080 150 KB

Nanite ON, r.VolumetricFog.GridPixelSize 16 - 8.3ms

2024-11-12_15h42_17
2024-11-12_15h42_171920×1080 145 KB

5 Likes
276

Yes, as shown in your screenshot with Nanite disabled, the water reservoir appears completely broken, now displaying Nanite’s fallback mesh.

It’s odd to see this mix of Nanite and regular meshes, especially with Nanite enabled on so few elements the benefit is really not worthwhile. It’s also strange that Bloober uses few or no LODs even on the regular meshes.

Also, using Lumen on regular meshes without LODs is likely quite costly in terms of caching.

5 Likes
277

good analysis

1 Like
278

Irrelevant, SH2 barely uses nanite meshes, you can confirm it yourself by setting MaxVisible* to ridiculously small amount, like 2, to bascially dont render nanite. I spend a quite some time hunting for scene where Nanite meshes were used and there weren’t many (just a few rocks there and here)

279

I’m not sure how what I said is irrelevant. It directly addresses the issue you mentioned: they used Nanite for only a limited number of objects and didn’t implement LODs for the rest of the meshes (except for foliage). This approach unnecessarily increased the computational load for calculating Nanite, without any clear benefit. Also, they didn’t create LODs for other objects. It’s like you baking lighting for a scene to use it as static light while still having the game calculate all dynamic lighting and Lumen GI simultaneously, without any justification.

3 Likes
280

SH2 is so bizarre. Why only use nanite on so few meshes? Why not go all in on Nanite or skip it for a LOD system. Now they barely have neither.
My assumption is they tried Nanite early on in development, then decided not to use it but then forgot to turn the feature off on certain objects. The weird thing is, they would be able to catch that in the GPU profiler, did they never open the profiler? Or use debug visualization.

2 Likes
281

It is irrelevant precisely because they don’t use Nanite [properly]. The “”“analysis”" from above has 0 value, it shows the case of someone forgetting to disable Nanite, for whatever god reason, that’s all. There isnt any BIG BREAKING, INDUSTRY SHATTERING conclusions to be made from that silly mistake.

I don’t know why they decided not to utilize Nanite at all, I assume majority of the game was done on 4.27+ and then they decided to abandon migration to Nanite due to unforseen amount of work, etc. But more importantly, they did not really need it, nor they needed any complex and numerous LODs. Why? I RE’d their streaming system - it is a “heavily culled” approach with their custom streaming volumes. Each volume has a pre-load box that initiates async load of numerous linked StreamingLevel, and on top of that it has a toggle volume box itself that will immediately load the SL synchronously, if needed, and then set it to Visible. This works the same for both outdoors and indoors, with the one exception is that outdoors literally re-implement fog as away to hide distance objects being culled almost identical to original game.

In short, they use very manual and tuner streaming approach so they always can control how much stuff is rendered at any time and thus they did not need to setup 773 LODs for every potential distance visibility because this game never has a case of “See that mountain 50km away? You can go there”. Whatever they succeed at such approach or not is debatable.

tl;dr An attempt to drag every modern UE5 game here will only hurt your stance rather than backing it up.

2 Likes
283

I ran these tests to figure out what might have gone wrong and why turning off Nanite improves performance in this specific case. Not sure who you’re arguing with about this, but I never said anything about it being “industry-shattering.” Honestly, the opposite, I was just pointing out a possible mistake to show there’s no need to jump to conclusions like, “AHAHA, Unreal Engine is bad, and all games using it will be terrible.” I know how the streaming level works, but if Nanite isn’t being used, adding at least one LOD level could really help performance on low-end PCs. Even with objects that are close, highly detailed models with dense polygons can still cause quad-overdraw at short distances. LODs are especially crucial for foliage since meshes with opacity can hit performance hard when there are lots of “overlapping” polygons in view.

3 Likes
285

I do not see any open world + if you are using Nanite for low poly meshes, your frame rate absolutely deserves to drop for no reason.

I am not entirely sure how many times people tried to explain when to use Nanite and when not to, but it is clear you either have not read any of this or just simply didn’t understand it. In either case, no one is able to help you, so please stop sharing this type of content. You are unironically wasting peoples time and making zero progress on this topic about NANITE and NOT open world games - thank you very much.

287

I was watching your video. The tree on which you had Nanite enabled on had fewer than 10,000 polygons. Nanite was specifically designed for meshes with over 1,000,000 polygons, which is 100 times more than what your mesh had. You even mentioned it yourself:

You are absolutely right. Lets go back to 1998 when Lara Croft had no shadow and only 50 triangles; when both the graphics AND the performance was sh*t.

1 Like
290

It’s not wasting resources. Nanite performs better with higher poly geometry, and it’s saving development time when you don’t have to bake everything into normal maps.

3 Likes
292

It takes devs a while to transition to new methodologies. There’s a reason why assets that actually use nanite properly are supposed to be tagged, but I think people are using the tag/description when they only turn on the Nanite boolean. Without reviews you can’t really combat this, so yeah it sucks. Fab is garbage in its current state.

2 Likes
294

Don’t test FPS inside the editor. Package your game and then test. Editor readouts are unreliable. I was getting 45 fps for my project in editor and 240 in a packaged game.

3 Likes
296

Standalone is still running with the editor in the background. You will not get accurate framerates until you do a full package of your project and run it after a fresh reboot of your computer. As I said, the difference can be wild. 45 - 240 fps is a HUGE difference. Until you package the game and see if your FPS is still low, don’t bother with the reading you see in the editor even if you run stand-alone.

There’s also a lot more to performance issues than just nanite. How do you know that nanite is causing your slowdown? Do you have virtual shadow maps enabled? What shader model are you running? Is your model dense enough for nanite to make a difference or did you just turn on nanite for a standard low-poly mesh?

5 Likes