@Andrew Lauritzen quick Nanite question. Is the cost mostly flat or does it tend to scale linearly with the geometry count? If a dev switches to the Nanite pipeline later in development and doesn’t necessarily have high geometry assets with any level of consistency are they paying a similar performance cost as a developer who uses high geometry art more pervasively?
Not a simple question to answer unfortunately so I'll give some general info but don't latch on to too many specifics as there's a lot of variables.
Nanite itself tends to scale extremely well with scene complexity (both number of objects and complexity of objects), obviously far better than non-Nanite. Furthermore other systems that need fine-grained culling and LOD like Virtual Shadow Maps and Lumen benefit disproportionately from things being Nanite, and work less efficiently without it, which is why there is often good reasons to pair the new systems up; they have been designed to work well together.
Nanite does have some amount of fixed overhead (for having *anything* Nanite in the scene) to run the culling pipeline and such, but it is not necessarily huge. Base pass materials are even more complicated to discuss, as Nanite uses a visibility buffer the tradeoffs are a bit different there as well. Stay tuned on that front for 5.4 as well as there are a number of changes and improvements to the compute materials pipeline.
The biggest gotchas then tend to be around stuff like older systems that want to do things like render a bunch of different passes into separate shadow atlases do *not* work well with Nanite. So similar to not wanting to use VSMs without Nanite, there are potential cliffs around using Nanite with classic shadow maps. This landscape can be navigated (see Satisfactory for instance which is doing a good job of using Nanite in some places for big benefits but not necessarily converting everything over, while still avoiding many of the pitfall areas), but it requires folks to really understand how the engine systems work together.
Here's some high level guidance we give folks though on this front:
1) Once you are using any Nanite, you should generally convert all your opaque geometry to Nanite. There's not much benefit to mix-and-match.
2) Adding triangles to Nanite meshes doesn't cost very much at runtime, so use as many as you need. The main cost is more in terms of disk space (although it is well compressed) and other CAD tools not being able to handle giant meshes well.
3) While programmable raster has been supported for a while now in Nanite, this is definitely one area where people can get themselves into trouble. Alpha test is very expensive with Nanite, so geometry should be preferred wherever possible (see the fully geometric trees in Fortnite, etc). Similarly things like high density meshes together with vertex-shader-type stuff (world position offset) should be used sparingly... if WPO must be used the shader should be as simple as possible. Both of these considerations are also true for raytracing for similar reasons.
Went a bit beyond your question but wanted to give some context on the sorts of considerations that come into play.
