Good topic, but I want to push back a bit on framing Nanite as a natural fit for competitive arenas. In practice, competitive titles live or die on frame times and input latency, not raw polygon counts. Nanite’s whole value proposition—streaming billions of triangles from virtualized clusters—introduces overhead that matters when you’re chasing a locked 240Hz. The engine still needs to build a virtualized mesh description per frame, and while culling and streaming are smarter than traditional LODs, you’re trading deterministic draw overhead for a more complex CPU-side workload. If you’re prototyping a competitive map, I’d cap Nanite usage to hero props and environmental detail rather than going all-in on whole levels, otherwise you’ll see stutter during heavy action where dozens of clusters get re-evaluated simultaneously.
On the hardware side, people undersell the platform requirements here. Nanite acceleration is hardware-assisted on RTX 30-series and newer (plus RDNA2 and later), which offloads a chunk of the traversal cost. On older or non-accelerated silicon you’ll feel the penalty hard, and mobile is completely unsupported regardless of how you slice it. For a real competitive build, I’d also factor in that Nanite doesn’t play nicely with certain real-time deformations or dynamic occlusion patterns you’ll want for gameplay. My recommendation: use it selectively for
"Just click their heads." – Ancient CS wisdom"
