TL;DR: Improving UE5’s ability to give more granular control to Fallback Bake Meshes when using Nanite.
Hi All,
I hope that this post doesn’t repeat existing discussion, but I haven’t found anything yet.
In short, I’d like to ask if Epic has plans to provide more control to users when it comes to baking lighting using Nanite enabled meshes. If not, I’ll make a case for this feature’s strong utility:
Currently, Lightmass and GPU Lightmass, to my understanding, use Nanite Fallback meshes. However, if you’re using static lighting with the aim of achieving high realism in next-gen games, this introduces some relatively noticeable artefacts. Especially in mid-poly models (which are a surprisingly fantastic use case for Nanite).
There is a workaround to this:
You must adjust the relative error of the fallback mesh, to increase its complexity and make it more similar to the Nanite mesh. This solves the Lightmass baking issue, but at the expense of a functioning fallback mesh. As a result, if you plan to ship a game that supports both DX11 and DX12, your non-nanite builds will be very geometry heavy.
The current workaround to this, with a relative error set to 0
You could, in theory, auto-generate LODs for every mesh in the project, and force the game to display LOD1 as its maximum LOD at runtime, but this doesn’t seem very precise to me.
The solution that I would love is this:
Option A) Have a setting somewhere in UE5 that allows GPU Lightmass to use Nanite meshes globally. Either in the GPU Lightmass settings panel, or per-mesh.
Option B) Have a separate Fallback Mesh that’s generated for Light Baking, stored only for the editor, that doesn’t need to be shipped. Include these settings inside the Nanite Settings area in Static Mesh, as an example.
As I write this, I recognize that there’s a fair bit of work above to lay some new systems to substitute this before provisioning Lightmass or GPU Lightmass for a bake. However, for the next few years at least, Virtual Textures, responsibly used Nanite and GPU Lightmass come together to form a really fantastic way of making games that look next-generation. For platforms like VR, that can’t quite run Lumen just yet (at least on most machines that our users would be likely to have), this is our best choice when using UE5 for projects. Same again for mobile. In short, I believe the Static Lighting workflow has a lot of utility left, before the industry moves to full realtime lighting in a few years (if ever).
If this already exists in some form, I’d love to know about it. It not, I’d love to support on getting it built somehow.
Furthermore, if anyone has any better workarounds than the one that we’ve been using, I’d love to hear that as well.
Thanks for enduring the wall of text 
Keep up the good work, Epic & everyone else reading this!
p.s. Here’s a bonus image that puts this workflow to the test, specced to run on PCVR:
