Real-time lightmap UVs are per-Mesh Renderer: all instances of the same mesh share the same input data, but different Mesh Renderer instances can use different real-time lightmap UVs at runtime. Unity calculates the UVs for the Realtime Global Illumination system during the precompute stage. This calculation takes per-mesh UVs as input and produces per-Mesh Renderer UVs. Unity can generate the input per-mesh UVs when you import a model, or you can provide your own data.
This works as follows:
Mesh.uv3 maps to the TEXCOORD2 shader semantic and is commonly called UV2.Mesh.uv3, but there’s data in Mesh.uv2, Unity falls back to using the data in Mesh.uv2 as input for the real-time lightmap UV calculations. Unity uses Mesh.uv2 for baked lightmap UVs. It’s common to use the baked lightmap UVs as input data for the real-time lightmap UVs.MeshRenderer.enlightenVertexStream to TEXCOORD2 in shaders, instead of the data in Mesh.uv3.Note: If you want to use Mesh.uv3 for another purpose in a mesh that uses Realtime Global Illumination, you must ensure that all Mesh Renderer components that use the mesh receive global illumination from Light Probes rather than lightmaps. Change this with the Mesh Renderer component Inspector, or the MeshRenderer.receiveGI API.
For more information, refer to Generating lightmap UVs.
This is what happens when Unity takes the per-mesh input UVs and processes them into per-Mesh Renderer output UVs.
Optionally, you can instruct Unity to merge UV charts where possible during this process. This reduces the size of the lightmaps and can improve runtime memory usage and performance.
Enable this optimization on any GameObject with a Mesh Renderer component. In the Mesh Renderer Inspector, navigate to the Lightmapping section and enable Optimize Realtime UVs.
Note: This feature can misinterpret discontinuities in the original UV mapping. For example, Unity might treat an intentionally sharp edge as a continuous surface. If this happens, disable this feature.