Thanks for the hint ! Will try to check Nvidia tools if there will not have any Legal records and have easy access to implement into Engine. HW RTX Lumen With foliage flicker is an “Crying into Discoteque” and fried PC’S . ! I will Defend @TheKJ with His statements - he is right there. New technologies pushed but they are all in early beta stages. It starts when you want create Performant terrain - best way to have one is to remove Landscape sytem and this WP/HLOD additions . It is not game ready
Not having HLOD for cells and keeping all actors in memory in an open world, which can consist of tens or even hundreds of thousands of actors, is clearly not a good practice and causes the opposite effect a quickly saturated memory and excessive CPU usage. Naturally, this isn’t noticeable when there isn’t much in the world.
Maybe you’re simply talking about excluding just the landscape itself from the World Partition, as that would cause performance issues, and not the rest of the world?
Nvidia’s ReSTIR GI/DI is even more resource-intensive than Lumen, with more significant issues (incomplete skylight support that neither occludes nor produces any GI, ghosting due to heavy reliance on temporal data, an unstable render, etc.).
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.
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.
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.
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.
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.
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.
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
Nanite OFF, r.VolumetricFog.GridPixelSize 8 - 8.8ms
Nanite ON, r.VolumetricFog.GridPixelSize 16 - 8.3ms
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.
good analysis
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)
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.
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.
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.
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.
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.
(post deleted by author)
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.