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

Zero responses about the performance or data given on this thread because people refuse to acknowledge the performance & visual issues with Nanite:


Mods should do their job and remove off-topic (rule breaking on personal harassments) comments.

There are people having double the performances in packaged build vs in-editor so all timings could be really different when packaged (UE5.6 is slower than UE5.5 in editor but faster when packaged).

I’ve shared several packaged test. This also doesn’t affect the shader timings. It just removes some editor timings and reduces a few memory issues(bottle necks if present, which non where). You’re also not proving major improvements relate to Nanite because you all refuse to use proper optimization tools.

test scene that would look like a plausible game use case.

No, instead I’ve shown non-nanite games rendering pipelines running faster & proved how impossible it is for nanite to be faster than optimized rendering.

Unlike all the commentators making personal attacks, I made the thread so that Epic would fix the docs which ridiculously states a typical non-nanite scenario has a 25% faster prepass than basepass.

Consumers & devs demand changes to the docs that are less manipulative in nanite’s favor.
Prove me wrong or get out of the thread & stop embarrassing yourselves. Provide internal res/pixel count all pass timings, hardware, quad overdraw, velocity settings, and then show it looking better in motion/no subpixel aliasing without TAA.

PRECOMPUTED LODs are FASTER than REAL-TIME COMPUTED LODs?! NO WAY?! Who would’ve thought…

Apparently Epic Game teachers & the docs themselves. Several people on this thread kept lying and saying Epic never said “use it on low poly” or “it’s faster” meanwhile several presentations said otherwise. Thank you for reminding everyone how important this thread was.

1 Like