Unity-Lightmap烘焙与数据流
Lightmap（光照贴图）把部分光传输结果提前算好，再由运行时 Shader 按表面坐标读取。它节省的是运行时重复计算，交换条件是烘焙时间、存储和对场景变化的限制。
理解流程时应追踪输入、烘焙与解码三个环节。只记住 Lighting 窗口里的参数，遇到自定义 Shader、UV 接缝或管线升级时仍容易失去判断依据。这里以传统 Unity 2022.3 工作流整理原笔记，其他版本应核对对应管线。
1. 烘焙器需要什么
几何决定遮挡与反弹路径，材质反照率决定光被反射多少，发光与灯光提供能量。反照率不是“光子数量”，Albedo Boost 之类调整也不应当作物理上多产生了几束光。
烘焙器可能采用不同求解方法，不能因为都生成 Lightmap 就断言所有实现都是同一种光追算法。先确认项目实际使用的后端，再解释采样、降噪与版本特性。
原笔记配图：旧版 Lighting 窗口中的环境光与反射设置；图中数值是历史配置示例。
2. UV 与图集为什么重要
光照 UV 通常需要独立、无意外重叠的展开，合理的 texel density 和 chart 间距。在 Unity Mesh 数据中常称 uv2，对应 Shader 的 TEXCOORD1；不要把名称里的 2 当作第三套 UV。
图集中的每个 Renderer 还需要 scale/offset，把自己的 UV 映射到正确区域。只绑定一张 Lightmap，而遗漏图集变换，会采到别的物体。
Padding 用来隔离过滤足迹。分辨率降低、压缩或 Mipmap 会扩大渗色风险，不能只靠把 UV 岛贴到一起节省空间。薄墙漏光也不全是 UV 问题，还可能涉及几何厚度和采样。
3. Meta Pass 提供材质贡献
Meta Pass 向烘焙流程提供 Albedo、Emission 等材质信息，回答的是“这个表面对间接光有什么贡献”，并不是再次运行完整实时光照。
自定义材质若运行时颜色和烘焙输出不同，可能出现物体看着发光但环境不受影响，或反弹颜色不对。动画、视角相关效果和程序化纹理，也需要明确烘焙时如何取值。
Meta Pass 的具体写法与烘焙后端支持相关。URP/HDRP 不应直接复制 Built-in 的 include 和宏而不核验。
原笔记配图：Albedo Boost、Indirect Intensity 等旧版参数。它们调整材质或间接光贡献，不应解释为凭空增加光子。
4. Baked 与 Mixed 模式
完全 Baked 的灯光把规定范围内的光照预计算下来。Mixed Lighting 则在烘焙与实时之间拆分职责，Baked Indirect、Shadowmask 和 Subtractive 的行为不同，并非简单地“多输出一张图”。
选择模式时，应分别回答直接光、间接光、静态阴影和动态物体阴影由谁提供。Shadowmask 存储遮挡信息，不是可以直接相加的颜色光照。
5. 运行时采样与解码
1 | |
RGBM、dLDR 和 HDR 路径由平台、项目与管线选择决定，不能认定所有 Lightmap 都是 Gamma 编码。是否发生硬件 sRGB 解码，也要与 Shader 解码函数配套检查，防止重复转换。
Directional Lightmap 增加方向相关的信息，使法线扰动可以影响间接光重建，但不等于完整保存每个方向的入射光，也不是动态重烘焙。
6. 参数怎样对应问题
噪声首先看采样与降噪，细节不足看 texel density，UV 接缝看展开、padding 与压缩，过亮或偏色则检查材质贡献、曝光和重复叠加。
增加采样数不会自动修复错误 UV；提高图集尺寸不会自动解决错误色彩解码。每次调整都应先说明它改变了哪一段数据。
动态物体通常通过探针等方式获得间接光。Lightmap 是表面存储，探针是空间采样，两者的接缝和遮挡表现需要一起验收。
原记录图解
原笔记配图：烘焙采样数、反弹次数等参数的旧界面示例，不是推荐默认值。
原笔记配图：直接光与间接光的降噪、过滤选项，具体可用项取决于版本和烘焙后端。
原笔记配图：原记录中 Max Distance 为 0 的画面，作为当时场景的 AO 参数观察样本。
原笔记配图：原记录中 Max Distance 为 1 的画面；与上一图比较时应注意原截图未提供完整一致的测试配置。
原笔记配图：烘焙 AO 的距离与贡献参数界面。烘焙 AO 与实时屏幕空间 AO 需要分别理解。
总结
Lightmap 的完整工作流是“正确的几何和材质输入—合适的离线求解—一致的运行时采样”。把 UV、Meta Pass、编码和混合模式分别说明，排查时才不会把所有问题都归咎于采样数。