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

[TorQueMoD]

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?

[Lucian]

You should use World Position Offset Disable Distance for your tress because in this moment, the virtual shadow on your scene is calculated every frame because of WPO. Also, the nanite trees are instances, no?

PS: I ran some performance tests using World Position Offset Disable Distance in a scene using Lumen and VSM. Even with heavily forced LODs (which clearly don’t look as good as Nanite meshes), you can still gain performance by using Nanite combined with world position offset disabled. The biggest challenge when working with Nanite and VSM is handling meshes that rely on WPO effects. If your world consists entirely of trees using WPO effect, then sure, using Nanite might not be the best approach. However, it’s not accurate to conclude, as stated in your video, that “Nanite can’t handle open-world games.” Try creating a city scene instead, and you might find yourself saying, “As you can see, LODs can’t handle open-world games.”

[Aresias]

From the beggining OP is constantly doing wrong comparisons using Nanite incorrectly and using only edge cases scenarios that are never actually used in real world uses cases of Nanite.
This whole topic is mostly missinformations.

[myasga]

I removed content if you read this. Excuse me you need to find a your way how to deliver performant large scale enviroment.

[Lucian]

for LODS use Hardware RT shadows, that overwrite VSMs and looks similiar. Nanite with Lumen+VSM and some effects cause flickers on lower screenspace settings.

Raytracing shadows have limitations too, such as shadow distance. It depends on your game’s needs, in specific scenarios (like when all models have WPO enabled), using LODs instead of Nanite might be a better choice, as I mentioned before.
Each workflow has drawbacks, Nanite/LODs, VSM/Ray Tracing, Lumen/Baked Light. As a developer, you should choose the best workflow for your specific game.

Also you didnot tell what are settings for LODS since its crucial with managing triangles and also you should remake wind on LOD.

I tried to be fair and try to match the nanite scene, even if I couldn’t with a system of 5 LODs. I’m not sure what you mean by “remake wind on LODs.” The “wind” effect is a material feature using World Position Offset (WPO), which allows the vertices of a mesh to be manipulated in world space through the material shader. The LODs will still have this effect having the same materials if you didn’t change them per LOD.

[Lucian]

@myasga

r.RayTracing.Culling (1-2) 3 is default
r.RayTracing.Culling.Radius
r.RayTracing.Culling.Angle
For later lods disabling shadows and rt is way to optimized .waiting now how to cull shadows with Intesitiy instead pops that is the issue atm.

Yes, you can do that, but increasing the radius too much will hurt performance. It’s still better than before, as they’ve made significant performance improvements for ray tracing in 5.4+. Also, keep in mind that these commands will also impact RT Reflection and HWRT Lumen.
In my tests, even with a larger culling radius and LODs, it still doesn’t match the VSM distance with Nanite. And like you mentioned, the shadow tends to pop in at a distance.

@myasga

For WPO you can reduce in material so it will cull on preffered distance.

I tested this a few months ago, and it doesn’t work that way. It will still be calculated. It’s similar to a light source with low intensity, you won’t see it, but it will still calculate the shadow it casts. This is actually why they implemented the “World Position Offset Disable Distance” for each actor.

[Aresias]

IDK, but just look at this post, a guy used Nanite with landscape nanite HLOD and it improved his performances by a lot :

500×500 2.84 KB

Nevermind, I managed to get this World Partition + Landscape Nanite + Landscape Nanite HLOD working with an incredible high quality result, and it increased the game’s performance by 30+ FPS on my most heavy level.

[Aresias]

I don’t think that with such a flat landscape with almost no static meshes and other stuff to render you can reach the threshold where Nanite become more performant to render the whole scene.
Just look at the video a few post above that TorQueMoD posted, the title is a bit clickbait but the content is interesting. He compared classic trees and bushes with masked materials and LODs vs everything 3D for trees and bushes with Nanite and not only it looks a lot better but it also performs a lot better. You can even render grass with greater distances without destroying performances unlike non-nanite and masked materials.

[Aresias]

I don’t know what you are talking about he is using exactly same windows size for the comparison this is one of the fairest comparison that someone have ever done and he is going from 35 to 50 fps in the village with as optimised as possible trees and foliage for each scenarios (masked materials and LODs for non-nanite and full 3D for Nanite). And the trees looks miles better on the Nanite version. you said the grass looks to thin, to me even the grass looks better too with the Nanite version. He was curious himself for his game and did the full real world scenario comparison.
It’s crazy how some people here can say that they’re right even when there’s undeniable evidence that they’re wrong.

[Aresias]

Again, I don’t know why you’re bringing screen resolution into the discussion, he was using high scalability settings with the same screen percentage. His comparison is fully valid.
And at the end of the video he did zoom out and showed that it is actually a pretty dense forest.
But i don’t know why i’m talking with you about this video you obviously haven’t watched it judging by your answers.

[Aresias]

This is funny that you bring this because he did say in the video that he even increased the amount of trees for the Nanite case because they have lower density foliage but the final image have about the same amount of foliage and he even increased the rendering distance to cinematic unlike the non-Nanite case.
To me the Nanite case looks a lot better and is a lot more performant that’s not even a debatable point.

[Aresias]

Even funnier : The fact that the Nanite case have full 3D branches and leafs makes it a lot less prone to ghosting that can happen with temporal AA solutions.
Temporal AA artefacts is mostly coming from moving/animated textures or transparent textures due to the lack of motion vectors (that’s why non-nanite masked material grass have terribly bad ghosting in most games). So this is one more good reason to use Nanite.

I forgot to mention this, thank you very much.

[Rafael-57]

@Aresias

From the beggining OP is constantly doing wrong comparisons using Nanite incorrectly and using only edge cases scenarios that are never actually used in real world uses cases of Nanite.
This whole topic is mostly missinformations.

Then Epic should just delete this line from the documentation:

https://dev.epicgames.com/documentation/en-us/unreal-engine/nanite-virtualized-geometry-in-unreal-engine?application_version=5.4

## What Types of Meshes Should Nanite Be Used For?

Nanite should generally be enabled wherever possible. Any Static Mesh that has it enabled will typically render faster, and take up less memory and disk space.

And also this:
An example of an exception to these rules is something like a sky sphere: its triangles will be large on screen, it doesn’t occlude anything, and there is only one in the scene. Typically these exceptions are rare and performance loss for using Nanite with them is fairly minimal so the recommendation is to not be overly concerned about where Nanite shouldn’t be enabled if Nanite supports the use case.

If the exceptions are so rare and the performance loss is “farily minimal” that would be there is no wrong way to use nanite. Either you are wrong or the documentation is wrong.

You’re arguing without even replying to what the OP is actually saying.

[SHK_Maenavia (Maenavia)]

You also forget to mention the rest of the documentation, which more precisely explains what makes a good candidate for Nanite.

Just with the first recommendation, which states “Contains many triangles, or has triangles that will be very small on screen”, we’re clearly talking about high-poly meshes, as Epic has demonstrated in all their tech demos since the very first presentation.

There is no benefit to using Nanite on low-poly meshes. In fact, it has never been presented for that purpose and probably never will be. Maybe it will happen one day who knows, but that’s clearly not the primary goal of this technology.

[TheKJ]

There is no benefit to using Nanite on low-poly meshes.

Tell that to multiple Epic Games presenters saying otherwise.

we’re clearly talking about high-poly meshes

No, it’s not clear if your saying this. It states small triangles because small triangles kill quad unitization. That’s why a 6 million poly mesh (with little small triangles visible) runs faster without Nanite.

Thank you for proving my point.

we’re clearly talking about high-poly meshes, as Epic has demonstrated in all their tech demos since the very first presentation.

LOL, you mean like city sample where they kill 10 frames(“fairly minimum” eh?) because they wanted to put Nanite on the skydome and the demo’s where they stack an enormous amount of content? Some demos if you ask me.

Fortnite doesn’t have the geometric complexity to even justify using nanite apart from the trees(which Brian Karis stated wasn’t a good idea for foliage).

[SHK_Maenavia (Maenavia)]

I’m talking about “Lumen in the Land of Nanite” as well as “Valley of the Ancient.” Those demos would be impossible to run at exactly the same visual quality using LODs alone. For the Matrix demo, it might be possible to adopt a different workflow that uses LODs, since many of the meshes in that demo aren’t super detailed.

If all you’re aiming to do is render basic geometry the same kind we’ve been using for years, Nanite currently offers no real advantage. That kind of geometry is already highly optimized (low-poly plus LODs, whether manual or automatic).

Why use technology designed for very high-detail meshes on assets that are already low poly? It makes no sense for me. However, if people want to push the level of detail much further where LODs become inefficient because almost the entire scene is high-poly then Nanite becomes extremely useful. Whether you like it or not, that’s just a fact.

Whatever Epic says is one thing, but if you aren’t doing your own profiling and real-world tests to find out the actual costs and whether it’s worth it, that’s another matter. Marketing is marketing, but you still need to run your own objective analyses.

Nanite still has plenty of improvements ahead, but even once it’s fully optimized, there’s no way it will outperform LODs and highly optimized base meshes. Even if it became 30% more efficient tomorrow, it still wouldn’t be fast enough for very basic scenarios.

Nanite will remain a technology primarily designed for handling highly detailed, high-poly meshes for many years to come. It’s unlikely we’ll see it match or surpass the performance of LODs any time soon.

[TheKJ]

Those demos would be impossible to run at exactly the same visual quality using LODs alone

I think the quality of those demos are quite poor so I disagree. My stance on AA and the noise found with the shadows and geo-detail should clarify my point. The silhouette of the meshes shown in the first demo could be done without the slow vis-buffer prepass and the micro detail can easily be with texture illusions(but the Epic has not made the workflow easy in unreal).

Whatever Epic says is one thing, but if you aren’t doing your own profiling.

We’re talking about the dozens of studios using this poor documented engine/technologies.

Why use technology designed for very high-detail meshes on assets that are already low poly? It makes no sense for me.

Because studios don’t want to invest in LODs and the downward spiral of shadow rendering. It doesn’t make sense to me but Epic presenters still tell people to do this.

It’s unlikely we’ll see it match or surpass the performance of LODs any time soon.

We need hybrid approaches with precomputed visibility. GPU cluster culling is slow/inefficient and the vis-prepass is a major problem.

[SHK_Maenavia (Maenavia)]

All of this is subjective to each person, so there’s not much point in discussing what you consider worth it or not. Recreating Lumen in the Land of Nanite with LODs, detail maps, etc. definitely wouldn’t have the same geometric level of detail, given all the cuts you’d have to make to optimize the geometry right from the start.

Besides, how many games have come out so far with that level of detail? None, aside from Hellblade 2, which is somewhat close. It’s extremely expensive to develop a high-poly game, and unless that changes in the future, it’s obviously not going to be practical for most games.

If studios just rely on marketing without doing a thorough evaluation, we’ve really hit rock bottom. Who takes marketing at face value? Ideally, no one though in reality it’s often the opposite, with games where Nanite brings no added value when dealing with low-poly meshes where the tech is simply overkill for what they need.

Epic should have been clearer that this technology was mainly intended for high-poly meshes and been more explicit about the real-world scenarios where it provides a real advantage. If you’re just rendering basic optimized low-poly meshes (like those from the PS4 generation) with a high-poly bake on top with nanite there’s no real benefit.

Personally, I’ve always seen Nanite as a way to render high-poly meshes and push the boundaries of geometric detail. It’s clearly not efficient for low-poly meshes, as LODs completely surpass it. Even if Nanite handles foliage much more efficiently in the future and runs 50% faster, it will still be overkill for rendering basic meshes.

By the way, Epic should improve the speed of VSM. I’m not sure how, maybe by using the Nanite fallback, which is low-poly, as an alternative method to accelerate everything. With some screen-space shadows, it might do the job to some extent. That would be welcome.

[myasga]

(post deleted by author)

[Frenetic]

My understanding is that because of the cluster-based nature of culling, having low-poly meshes does work against you because the singular cluster ends up being much of the mesh.

Higher poly meshes have more bends, twists, and more tri’s to make clusters from, so the fidelity to match the curve of the mesh is much greater, has better granularity, hence it can do the culling much tighter.

I’ve always felt Epic has been decently straight-forward with their expectations around performance; they’ve specifically noted they target 60 FPS. I know I want more, we all do, but they never set the bar at 100’s of FPS, so.. ? I cannot really call them out there.

For my experience, I’ve had decently-good returns with regards to the performance-loss (so to speak) vs the amount of detail, sheer instances of grass for example, and whatnot. It’s topped out a bit yes, but it runs well, LOOKS good (for what I can make) and al that especially considering I have a ~10year old processor. I’m good for a target platform in that if I can run it well-enough, so will anything newer. (tested)