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.).
1 Like
(post deleted by author)
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.
(post deleted by author)
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
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
(post deleted by author)
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
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
(post deleted by author)
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
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
3 Likes
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
good analysis