Yeah but again, Nanite is not eating your framerate.
Lumen and Raytracing is.
If you disable both, and just use Nanite, you will have the same performance as without Nanite ±1ms.
HWRT is turned off in your second Build, you can see no Raytracing Scene in the profiler.
You are totally right that your second scene is more optimized, but your reasoning is wrong. Nanite is not tanking your framerate…
We will see. Nanite 8 k landscape built .
With base UE setup seems like problem with collisions
Looks fine to me. You are using Nanite Tessellation, as visible by the high triangle count in the top left view.
If you offset the mesh triangles in the material, it does not represent that in the Physics scene.
Same thing happens if you use WPO.
That’s not a Nanite issue, but a limitation by the Physics Engine.
K i wasnt able to pack 10 mln Foliage instances into Hlod - crashed - only landscape tiles
so in loaded main sector added foliage - that separated is tricky since its covered by strange BP with this assets pack which no allows me to control same places (auto update with changes) - so i went with combined one atm - which is fair it runs pretty good - i disabled WPO too.
let me know if we use this cheat for nanites or 100% full (via switching for Impostor) and culling for grass. (that shouldnt be allowed since guys this is your main postulate that nanite can go infinite with same quality and for laziness one click nanite assets without tweaking - so i disagree for Nanite flip to low poly at that point) Are we good and all clear?
AO Setup VS Lumen - Lumen changes color alot but that can be tweaked for potato pc users with directlight color and some PP in other GI Methods - also frames attached for comparision 
lazy setup OFC
[/Script/Engine.UserInterfaceSettings]
bAllowHighDPIInGameMode=True
[/Script/Engine.RendererSettings]
r.ReflectionMethod=1
r.GenerateMeshDistanceFields=True
r.DynamicGlobalIlluminationMethod=1
r.Lumen.TraceMeshSDFs=0
r.Shadow.Virtual.Enable=1
r.DefaultFeature.AutoExposure.ExtendDefaultLuminanceRange=True
r.DefaultFeature.AutoExposure.ExtendDefaultLuminanceRange=true
r.AllowStaticLighting=False
r.SkinCache.CompileShaders=True
r.RayTracing=True
r.DefaultFeature.LocalExposure.HighlightContrastScale=0.8
r.DefaultFeature.LocalExposure.ShadowContrastScale=0.8
r.VirtualTextures=True
[/Script/HardwareTargeting.HardwareTargetingSettings]
TargetedHardwareClass=Desktop
AppliedTargetedHardwareClass=Desktop
DefaultGraphicsPerformance=Maximum
AppliedDefaultGraphicsPerformance=Maximum
I… dont quite get your point here. What are you trying to say?
So it looks like you put 5 Million Grass instances into the scene using the foliage tool and you tried to bake that into HLOD. (And a bunch of trees).
The HLOD baking then crashed.
Just to be clear here. Nanite is a tool with it’s own limitations.
For example nanite is hard capped to 16 million instances. So it is not possible to just fill a giant world with grass and “nanite will handle”. Nanite requires culling. At a certain distance the grass will be invisible anyway, so why waste processing power on tiny meshes?
Also there are a few things that should be common sense.
Like, you don’t bake grass into HLODs.
Or you don’t paint grass using the foliage tool, if your world exceeds a certain size.
It is also recommended by Epic, that you should switch trees to imposters at a certain distance, as trees are basically the worst use case for Nanite.
I don’t know if you are still learning, and I don’t mean to offend you, if you do.
But assuming you know your stuff, it feels like you are intentionally trying to deceive people by either lying or by using worst practices to degrade performance.
I have created levels with dense foliage, fotoscans, WPO enabled, (see my earlier posts here) and was able to get 150-200 FPS consistently.
(post deleted by author)
Nanite takes 2.5ms to render, as his preview clearly shows. + 0.5ms base pass.
His HW basepass takes 1.25ms(about 1ms less) and they are using a partial prepass(which results in somethings in the engine not being compatible)which only cost .2ms
Nanite is basically 3.1ms
HW raster is 1.5ms until you realize @myasga is rendering velocity separately adding a .9ms which you can remove by changing velocity render to “during basepass”.
That’s literally 2x faster than Nanite.
which is less, put you can see LODs popping in and reduced detail.
That’s Epic’s fault for not implementing proper transition patterns.
Also @TheKJ, overdraw doesn’t matter, if it doesn’t affect frame time. Nanite can have pretty harsh overdraw and barely increases in render time.
The visibility buffer is slow to resolve because it uses pixel shaders. If it was a HW visibility buffer(no clusters), it would be faster than the non-nanite basepass and the nanite basspass would stay the same. Because no z-testing exist because it’s a SW raster, the clusters are processed every time you see overdraw. The sw rasterizer is 3x faster but the overdraw makes it 2x slower. It’s a huge deal and it’s a reason why it takes 2x slower.
Overdraw literally means information was processes and wasted, that’s true in SW or HW raster.
Also, @myasga, show quad overdraw with LODs and investigate the shadow maps draws.
I do agree that this is redundant, the thread is here to update timings across each engine version to see if improvements where made to Nanite. We don’t need to throw random content at HW or SW raster. We need to see if Epic is improving the Nanite pipeline and resolve efficiency.
Yes, but that wasn’t his argument.
He said you get double the FPS if you disable Nanite. You correctly stated, that we are only talking about a 1.5ms difference.
Which is only 10% of the total frame time.
So his argument was wrong. And you are correct.
While you are correct again, that the overdraw slows down the rendering, I don’t see a 2x performance degradation. According to nanite documentation, nanite takes 2.5ms for the base pass, which matches with his benchmarks, regardless of overdraw.
With the rest I agree
Okay, We are Here guys. Without WPO , With That Assets Made Specific for Nanite - we have a clear winner for New Generation Of GPU.
If you want to have maximal quality and would put infinite Triangles - like Forest:
FOR 8k+ Levels that Use Landscape System for REALISTIC Ultra High Poly Geometry Titles go Full Nanite - but watch out for scam Assets.
Would like to Sorry All of You Guys with
my Misleading Informations. 
Removed my previous Video!
I Had no proper Foliage Assets and that Should Be Immediately Flagged By EPIC:
That Sellers Cannot Provide “Nanite ready information” -if they aren’t created proper way. So i have proposition:
Spam Here Till The Epic will Review Once Again that missleading and faulty made assets..
Have no Idea how it comes when the Windy Things Start to move Assets (World Position Offset ,Pivot Painters and other Effects). Iam not an expert to that type of thing so would like to leave someone who can compare properly.
But You Can Compare my Results with Raytracing - Enabled ALL + DLSS4 + FRAMEGEN:
VISUAL: Nanite Shines Here
LOD with Imposter (FROM 700k to 2 Triangles) Made with care to not see visual popping and have close to Nanite visual.
NANITE without any Tweaks -Auto (1,5 mln start and 6k Feedback)
LOD RT info about VSM not supported but but it looks outstanding and that not really affect much with that density^
NANITE
LOD Without RayTracing With Global Ilumination set to None and + Shadow Maps Method
NANITE Without Raytracing With Global Ilumination set to None + Shadow Maps Method
Thanks to EasyBiomes for Creating that such amazing Assets. No idea when the separated Trunks from Leafs Come . But i assume that can perform even better?
@TheKJ - Developers and Users must change their Tech Scenarios to be Complete Large Scale Enviroments.
5.5 Delivers in that real Game Scenario - but there must be Huge Amount of Geometry to actually see when that Nanite tech applies sweets. Also in presented Screens Video i provide massive visual difference in distant objects.
All the best!
The creator often test quad/prepass/topology unknown LODs vs Nanite which produces untrustworthy win results for Nanite, but it was a good test that resulted in big gains vs instanced and non-instanced nanite(many epic demos). Adding to the mega-thread [17]. Currently making test that build off these results. Instancing also helps regular HW rendering.
I’m not sure what the creator was doing. But I had a somewhat complex scene(somewhat quad optimized) that was taking 2.8ms to render with hw basepass+full-prepass. Nanite visbuffer took .7ms(not a whole lot of sw raster overdraw) and nanite material evaluation was was taking 4.3ms. (Nanite evaluation is too slow).
Instancing turned .7ms vis buffer into a .4ms visbuffer. Looks like this only helps slow vis buffers
Developers and Users must change their Tech Scenarios to be Complete Large Scale Environments.
There’s barely any context here, I have no clue what overdraw looks like, how the LODs are setup, or what is killing perf in each scenario.
Is there any conclusion as to why the nanite is expansive?
We could Use also for Terrain Virtual Texture in Final for LOD system That could apply some Frames but looks will be also worse.
No Idea. Engine just render Nanite Assets much better in Visual Quality with distance
No matter it is same Tris/Poly LOD 0.
You literally did the same but the opposite way with this topic.
The closest fair comparison video was removed from Youtube (forest and village with optimised LODs masked material vs the same scene but with poly only Nanite). The guy literally took the time to test it for his game and see what’s better, not just a random scene. And concluded Nanite was better. Not only it looks better but upscallers works better.
Moreover 5.6 have big performances improvement for HWRT lumen and virtual shadow maps so it works even better with nanite.
And concluded Nanite was better.
He was doing something wrong yet have no timing here showing what he messed up.
The quad overdraw is a mess. The ratio of failed quads will put Nanite for the win easily. It’s not optimized properly. Masked objects need to be used, that’s cheap on modern hardware.
forest and village with optimised LODs masked materials
He was doing something very wrong then. LODs mean nothing, they are just an approach to introduce better quad friendly topology and UE doesn’t account for this.
@Aresias , He wasn’t even trying to optimize HW raster. Nothing here was proven. https://d3kjluh73b9h9o.cloudfront.net/original/4X/2/4/c/24cce56f7711fc4a57f5a61c70c1243e2d47aade.jpeg
I’m glad you proved how good nanite can be when used properly.
Faster and looks better and also when moving the camera it should looks better because upscallers can use motion vectors so it’s a win everywhere.
You should see even a bigger win for nanite in 5.6.
A very interesting performance comparison from 5.5 to 5.6 i have seen many people report big performance gains mainly due to RHI thread time reduction and possibly better culling ? (primitive is 2 to 3 times lower in 5.6)
It’s also more stable (one stutter completely disappears on 5.6 at 0:29)
Unreal Engine 5 Performance Comparison (5.5 VS 5.6) - Quixel Dark Ruins Sample
What I found interesting is that Nanite’s culling and resolve became far slower in 5.6
Though, we would need more data on the VRS settings. They may be more aggressive in 5.5.
EDIT: Almost everything is slower in unreal 5.6, the only thing changed was how Lumen was enabled. In fact the only performance gain comes from the Lumen GI stat missing. It doesn’t even seem to be enabled in the 2nd test because if it was, the deferred lighting stat would be around 2ms.
EDIT: Comment quote on the video:
Quite misleading if you don’t know how the engine works. If Lumen is in Async, the timing for Lumen is transferred from LumenScreenProbeGather to RenderDefferedLighting.
Most of the timings are slower in 5.6. Nanite, MegaLights, Translucency, & Volumetric Fog are less optimized now.
TSR & Shadows are better in 5.6 but it only has more FPS (about 2ms more fps) because Lumen diffuse GI (which cost around 2ms) is not enabled unlike the 5.5 test
RenderDefferedLighting would be more if Lumen Gi was enabled, it’s also lower in 5.6 which makes no sense. This is the case unless settings by the uploader where botched for Lumen for the 5.6 test.
@Aresias “You should see even a bigger win for nanite in 5.6.”
Thanks for the video which directly proved this claim wrong.
Tbh, it’s not a good video, I’m more than sure that I noticed a resolve speed up on the g-buffer export from Nanite.
It doesn’t makes any sense to just look at Nanite timings alone and say “if it’s slower that mean that Nanite is slower” since Nanite, VSM and Lumen have optimizations when enabled together. It would require a lot more investigations.
What i see is that the fps is a lot better in 5.6.
Nanite seems to have better culling in 5.6 that could speed up a lot of other rendering times not directly related to Nanite. Maybe this culling improvement require more time for Nanite but overal improve performances.
None of your tests are done properly either.
Then optimize quad overdraw. This is not a hard concept. TSR is a mess though.
