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

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

5 Likes