We actually have a workaround now.
-
Set the Nanite Fallback relative error to be 0, so the fallback has the exact same quality as the Nanite mesh. We now have a polygon-perfect LOD0
-
Add an aggressive LOD profile to the mesh. We have created a couple of our own for high-poly and medium-poly Nanite assets. LOD1 might be between 1% and 6% of LOD0.
-
Add a MinLOD profile per-platform. Now, for specific platforms, the extremely large LODs will never be rendered if you need to fall back from Nanite.
Finally, you need to make sure that you add r.StaticMesh.StripMinLodDataDuringCooking=1 to your config. It isn’t really exposed as a command, but works very well in 5.3. Haven’t tested in 5.4 yet. This command make sure that you don’t cook those massive fallback LOD0s, so that you don’t have a lot of mesh data in the project, even if it isn’t rendered.
Its worked beautifully as a pipeline to start at Nanite, and work down to support simpler platforms, whilst having great static lighting. You’ll still be somewhat constrained by the simpler platforms with regards to level design complexity, but the meshes scale well.
Hope that helps a little
It isn’t the beautiful and seamless Static Lighting design flow that I’d like. I think we have another 5 years of static lighting being relevant at least, until we can pull off realtime lighting at Mobile and XR friendly framerates. So I’d love for Epic to do one last push to get GPU Lightmass ready for production, with Nanite-friendly static lighting.