I would expect a test in a level where Nanite strengths are obvious
In other words an unoptimized scene with extreme overdraw. The reason why I am posting this is because Epic and the UE channel has videos and presentations that tells devs Nanite is faster even for simple scenes when it’s clearly not.
If I do a test with a extremely high poly to the point of extreme overdraw, then that’s faking a reason to use Nanite over LODS in terms of performance(No game should have extreme overdraw). Also regarding you memory comment, it’s not my fault Epic doesn’t have LODs with distance hierarchies that load into the GPU based on closest draw distance. Instead we have a giant mess with visibility buffers and clusters.
If you mean a scene with high drawcalls from several kinds of meshes? Again not my fault we don’t have meshlets that combine multiple meshes we know always get loaded in memory together and their LODs get combined into one instanceable meshlet the GPU can precompuational cull with a single draw call.
Also, I recently dumped an entire city scene from NFS2015 by dumping the geo from a API inspector and loaded the frame’s scene geo in unreal, ofc it was one big mesh but it was 6 million triangles total. I enabled Nanite on that 355mb mesh and instantly lost 3ms due to nanite’s overhead. It was a pure geo test with one unshadowed skylightm 3ms without Nanite and 7ms with. The scene was well optimized and had little overdraw from the gameplay perspective.
So what in your opinion is a scene with Nanite’s streets? A dense foliage scene with really small triangles and overdraw hell? Nanite explodes with WPO even with the distance limiter.