Unity光照烘焙核心原理与实战：从Lightmap到全局光照的深度解析-尧图网络科技

1. 项目概述：为什么Unity光照烘焙是项目成败的关键

如果你做过一个稍微复杂点的Unity项目，尤其是在移动端或者对性能有严格要求的平台，那你一定对“烘焙”这个词又爱又恨。爱的是，它能把那些实时计算起来要了老命的光影效果，变成一张张轻飘飘的贴图，运行时几乎零开销；恨的是，烘焙过程本身就像开盲盒，动辄几小时甚至一晚上，出来的结果不是漏光就是黑斑，或者光照强度完全不对，反复调试能把人逼疯。

我经历过太多这样的时刻了：美术同学精心搭建的场景，在编辑器里用实时光照预览时美轮美奂，一烘焙就面目全非。性能测试报告显示Draw Call和GPU压力都达标了，但画面质感却倒退了好几年。问题的核心往往不在于美术资源本身，而在于我们对Unity这套光照烘焙系统，尤其是从Lightmap到全局光照（GI）的实现原理，理解得不够透彻。只知道点“Generate Lighting”按钮，却不知道引擎在背后做了哪些计算、有哪些关键的“开关”和“旋钮”决定了最终效果。

所以，今天我们不聊那些浮于表面的“三步出图”教程，而是深入到引擎层面，把Unity光照烘焙这口“黑箱”拆开来看。我会结合自己踩过的无数个坑，从最基础的Lightmap是什么、怎么存的，一直讲到复杂的全局光照算法（如Enlighten、Progressive Lightmapper、GPU Lightmapper）是如何工作的，以及那些藏在Quality Settings和Lighting面板深处的参数，到底在控制什么。目标是让你下次再遇到烘焙问题时，能清晰地知道该从哪个环节入手排查，甚至能预判不同设置组合会带来的结果，真正把烘焙从“玄学”变成一门可控的“科学”。

2. 核心原理拆解：光是如何被“计算”并“烘焙”成贴图的

要理解烘焙，首先得忘掉“实时渲染”那套思维。实时渲染是“现在进行时”，每一帧，光源、物体、摄像机的位置关系都被重新计算，光照效果动态变化。而光照烘焙是“过去完成时”，它的核心思想是预计算：在游戏运行之前，就把场景中静态物体之间复杂的光照交互（包括直接光照、阴影、间接光照、颜色渗透等）计算好，并把计算结果存储起来。运行时，引擎只需要去查找这些存储好的数据，而无需再进行昂贵的光线追踪或辐射度计算。

2.1 Lightmap的本质：一张特殊的“光影身份证”

很多人以为Lightmap（光照贴图）就是一张存储了明暗信息的灰度图，这其实是个很大的误解。一张标准的RGB格式Lightmap，其每个像素（更准确地说，是每个纹素）存储的信息远比“亮暗”要丰富。

它存储的是“光照贡献”。具体来说，是场景中所有光源（方向光、点光源、聚光灯等）照射到物体表面某一点后，经过该点材质属性（如颜色、光滑度）调制后，最终反射到摄像机方向的辐射亮度。这包括了：

直接光照：光源直接照射产生的亮度。
直接阴影：物体遮挡光源形成的阴影。
间接光照：光线在场景中物体表面之间多次反弹后带来的“环境光”效果，这是全局光照的核心。
环境光遮蔽：模型自身缝隙、凹陷处因难以接收到环境光而产生的自然变暗效果，能极大增强体积感。

Unity在烘焙时，会为场景中的每个静态物体（标记为Static或Contribute GI）分配一块或多块Lightmap。你可以把它想象成给每个静态物体发了一张“光影身份证”，身份证上记录了该物体表面每个点在当前光照环境下的“标准照”。运行时，引擎就通过物体的UV2（第二套纹理坐标）去这张身份证上查找对应的光影信息，然后与物体自身的漫反射贴图颜色进行乘法混合，从而得到最终渲染的颜色。

注意：这里就引出了第一个关键点——UV2的展开质量直接决定了Lightmap的精度和是否产生拉伸。如果模型自带的UV2展开得不好，存在大量重叠或严重拉伸，那么再高的Lightmap分辨率也是浪费，甚至会产生难看的接缝。通常，我们需要在三维软件中或使用Unity的Lightmap UVs自动生成功能（在模型导入设置中）来确保UV2的合理性。

2.2 全局光照系统的演进：从Enlighten到Progressive

Unity的全局光照系统并非一成不变，它经历了多次核心算法的迭代，理解这些算法的差异是进行正确技术选型的基础。

2.2.1 Enlighten：曾经的王者与它的“预计算”阶段在Unity 5.x到2017.x时代，Enlighten是默认的全局光照解决方案。它的工作流程非常独特，分为两个阶段：

预计算阶段：这个阶段耗时极长。Enlighten会将场景的几何结构简化成一个个“表面元素”，并计算它们之间的相互可见性和光能传递系数，生成一个名为“光照传输数据”的文件（.exr文件）。这个过程是纯CPU计算，且复杂度与场景中静态物体的数量和复杂度呈几何级数增长。
实时阶段：运行时，Enlighten利用预计算好的传输数据，结合当前光源的颜色和强度（这些是可以实时变化的！），快速解算出整个场景的间接光照结果。这正是Enlighten最大的卖点——支持实时动态全局光照，比如太阳下山时天空盒颜色变化，整个场景的间接光色调也会随之温暖地变化。

然而，Enlighten的缺点也很明显：预计算慢如蜗牛，对场景结构改动极其敏感（挪动一个静态物体就可能需要全部重新预计算），且黑盒化严重，调试困难。在追求快速迭代的开发流程中，它逐渐成为瓶颈。

2.2.2 Progressive Lightmapper：高画质与可交互的权衡从Unity 2018开始，Progressive Lightmapper（渐进光照烘焙器）成为了新的默认选项。顾名思义，它是“渐进式”的。

工作原理：它采用路径追踪算法。想象一下，从摄像机发射出无数条光线，这些光线在场景中碰撞、反弹、吸收，最终追溯到光源。PLM通过持续发射这些光线并累积计算结果，画面会从充满噪点逐渐变得清晰平滑。你在烘焙窗口看到的实时更新，就是这个累积过程。
优势：
- 所见即所得：可以随时暂停、继续，光照效果渐进清晰，便于调试。
- 高质量：路径追踪是物理正确的渲染方法，能产生非常真实、自然的软阴影和间接光效果，尤其是对于复杂的表面和细节。
- 确定性：同样的场景和参数，烘焙结果每次都一样。
劣势：
- 速度：虽然比Enlighten的预计算阶段直观，但要达到低噪点的洁净效果，仍然需要大量的采样（光线数量），耗时很长，尤其是需要高质量烘焙时。
- 纯烘焙：它计算出的Lightmap是静态的，不支持Enlighten那种光源颜色强度实时影响间接光照的功能（但光源的Mode改为Mixed时，它仍能贡献实时直接光）。

2.2.3 GPU Lightmapper：速度的革命GPU Lightmapper是Progressive Lightmapper的变体，它将路径追踪的计算从CPU搬到了GPU。利用GPU数以千计的核心进行并行光线追踪，速度相比CPU版本的Progressive有数量级的提升，经常能达到近乎实时的烘焙速度（针对简单场景或预览质量）。

使用场景：它是快速迭代的神器。美术同学调整灯光位置、强度或颜色后，几秒到几十秒就能看到大致的烘焙效果，极大提升了工作效率。
注意事项：GPU Lightmapper的结果和CPU Progressive Lightmapper在物理上是一致的，但由于GPU浮点数精度和架构差异，在极端复杂的场景或极高采样下，两者可能会有肉眼难以察觉的细微差别。对于最终发布版本，很多团队仍倾向于使用CPU Progressive进行最终烘焙以确保绝对的确定性。

2.3 核心参数背后的数学与物理

Lighting面板里密密麻麻的参数不是摆设，每一个都对应着底层算法的一个控制开关。这里解析几个最核心也最容易出错的：

2.3.1 Indirect Resolution（间接光照分辨率）这是最容易让人困惑的参数之一。它不是指Lightmap图片的最终分辨率，而是指场景单位面积（通常是一平方米）内，用于计算间接光照的采样点密度。单位是Texels Per Unit（每单位纹素）。

如何工作：Unity会在场景中生成一个不可见的、均匀的“光照探针网格”或“表面采样点网格”。Indirect Resolution的值越高，这个网格就越密，采样点越多，间接光照的计算就越精细，颜色过渡越平滑，但预计算数据量也越大，烘焙时间越长。
与Lightmap Resolution的关系：Lightmap Resolution（在物体Lightmap静态属性处设置）决定了光影信息存储的贴图精度。Indirect Resolution决定了计算间接光照时的采样精度。两者需要匹配。如果Indirect Resolution太低，即使Lightmap分辨率很高，存储的间接光信息也是粗糙、有锯齿的。

2.3.2 Lightmap Resolution 与 Texel Density在场景视图中，你可以使用Baked Lightmap视图模式，看到场景物体上覆盖着一层彩色网格。这个网格的密度就是Texel Density（纹素密度）。

计算：对于一个物体，它的Texel Density等于分配给它的那块Lightmap的像素数量除以该物体在场景中的表面积。单位是Texels Per Unit。
调试意义：均匀的纹素密度是保证光照质量一致性的关键。一个巨大的墙面和一个细小的装饰品，如果使用相同的Lightmap Resolution设置，墙面的纹素密度会非常低（看起来网格很大），导致光照细节模糊；而装饰品的纹素密度可能极高（网格很小），造成存储浪费。因此，我们需要根据物体在画面中的重要性、大小来差异化设置每个物体的Scale In Lightmap参数（物体Lightmap静态属性中），以平衡质量和内存。

2.3.3 Max Distance 与 Max Bounces这两个参数控制着光线在场景中“旅行”的规则。

Max Distance（最大距离）：一条光线在场景中传播的最大距离。超过这个距离，光线即使没有碰到任何物体也会被终止。这主要用于优化性能，防止光线在无限大的开放空间中无意义地追踪。对于室内场景，可以设置得比房间尺寸稍大；对于户外，则需要根据需求调整。
Max Bounces（最大反弹次数）：光线在物体表面之间最多可以反弹多少次。每一次反弹都贡献着间接光照。增加反弹次数会让间接光更充分、更柔和，特别是颜色渗透（如红墙旁边的白墙会泛红）效果更明显，但计算量呈指数增长。通常，室内场景需要3-5次反弹才能有不错的效果，而简单的室外场景1-2次可能就够了。

3. 标准工作流与参数配置实战

理解了原理，我们把它落地到一套可复用的标准工作流上。这套流程能帮你规避80%的常见问题。

3.1 烘焙前的场景准备：打好地基

烘焙出问题，十有八九是前期准备没做好。在点击“Generate Lighting”之前，请完成以下检查清单：

物体静态化：确认所有需要参与烘焙的物体，其Static复选框已被勾选。或者，更精细地控制：勾选Contribute Global Illumination（贡献GI）和Receive Global Illumination（接收GI）。对于仅接收但不贡献GI的物体（如地面），可以只勾选后者。
UV2检查：在模型导入设置中，确保Generate Lightmap UVs已勾选。对于重要模型，建议在三维软件中精心拆分好第二套UV（UV2），并导入Unity。在场景中，可以通过物体的Mesh Renderer组件查看Lightmap Scaling的预览，检查是否有严重拉伸。
灯光模式设置：这是核心决策点。
- Realtime：纯实时灯光，不参与烘焙，每帧计算。用于动态物体或需要完全动态变化的光源。
- Baked：纯烘焙灯光。光源的所有信息（直接光、阴影）都会被“烤”进Lightmap。运行时该灯光物体可以被禁用，对性能零开销。适用于静态场景的主光源（如太阳、室内顶灯）。
- Mixed：混合模式。这是最复杂也最强大的模式。Mixed灯光会将其直接光照部分以实时方式渲染，而将其间接光照部分烘焙到Lightmap中。同时，它还能提供一种称为“Shadowmask”或“Distance Shadowmask”的实时阴影混合技术。简单说，Mixed模式让静态物体既能拥有高质量的烘焙间接光和静态阴影，又能从该光源接收到动态的直接光照，并且动态物体也能在该光源下投射出与静态场景融合度很高的阴影。
光照贴图参数：不要每次都从头调参。在Project面板中创建Lightmap Parameters资产。这是一个参数预设，你可以为不同层级的场景（如远景、中景、特写）创建不同配置（如“HighQuality_CloseUp”、“LowQuality_FarAway”），然后在物体的Lightmap Static属性或Lighting面板中快速应用。

3.2 Lighting面板参数逐项精讲

打开Window > Rendering > Lighting，我们重点看Lightmapping Settings。

Lightmapper：根据你的需求选择。快速迭代用GPU，最终出品用CPU Progressive。Enlighten除非维护老项目，否则不再推荐。
Indirect Resolution：如前所述，这是质量关键。室内小场景可以从20-40开始，大型户外场景可能2-5就够了。预览时可以用低值（如2），最终烘焙用高值。
Lightmap Resolution：这个参数已废弃，其功能被分散到每个物体的Scale In Lightmap属性中。不要再纠结这里。
Lightmap Padding：同一张Lightmap图集上，不同物体UV块之间的间隔。防止纹理采样时“渗色”。默认2通常够用，如果出现边缘光晕，可以增加到4或8。
Lightmap Size：单张Lightmap图集的最大尺寸（如1024, 2048, 4096）。引擎会尝试将多个物体的光照信息打包到一张或多张这个尺寸的图集上。尺寸越大，能打包的物体越多，但内存占用也越大。需要与Scale In Lightmap配合使用。
Compress Lightmaps：是否压缩Lightmap。压缩可以显著减少内存和包体大小，但会引入轻微的色块和噪点。移动平台强烈建议开启，PC/主机平台可根据质量要求决定。
Ambient Occlusion：环境光遮蔽设置。这里的AO是全局AO，计算的是场景中物体相互之间的遮挡。Max Distance控制AO的影响范围，Indirect Contribution控制AO对间接光的影响强度。想要更强烈的缝隙阴影，就调高Indirect Contribution。

3.3 烘焙、验证与优化

开始烘焙：点击Generate Lighting。如果是Progressive/GPU Lightmapper，你可以观察渐进过程。噪点很多时是正常现象，耐心等待采样数累积。
验证结果：
- 在Scene视图下拉菜单选择Baked Lightmap，查看光照贴图的实际覆盖和纹素密度。
- 选择Global Illumination视图模式，可以单独查看直接光照、间接光照、环境光遮蔽等各个通道的效果，便于排查问题。
- 检查常见的瑕疵：漏光（光线穿过模型缝隙）、黑斑（采样不足或模型面数过低）、阴影偏移（Lightmap UV有误或物体缩放非1）。
优化策略：
- 分层烘焙：对于超大型场景，不要一次性烘焙所有内容。可以将场景分成多个部分（如分房间、分区域），分别烘焙。运行时通过加载/卸载Lightmap数据来切换。这需要脚本控制LightmapSettings.lightmaps数组。
- 差异化Scale：如前所述，给前景重要物体设置更高的Scale In Lightmap（如4），给远景或次要物体设置更低的Scale（如0.5），在保证视觉中心质量的同时节约图集空间。
- 使用光照探针：对于动态物体（玩家、NPC），它们无法使用静态Lightmap。这时就需要光照探针。光照探针是在场景空间中放置的一系列采样点，烘焙时它们会记录该点的光照信息（球谐函数形式）。运行时，动态物体通过插值附近探针的数据来获得近似的光照效果。光照探针是连接静态烘焙场景与动态物体的桥梁，必不可少。

4. 高级话题与疑难杂症排查

当你掌握了基础流程后，下面这些高级技巧和问题排查指南能让你更上一层楼。

4.1 混合光照与Shadowmask详解

Mixed灯光模式是性能与质量平衡的艺术。它衍生出两种关键的灯光工作流：Shadowmask和Distance Shadowmask。它们在Project Settings > Quality > Shadowmask Mode中设置。

Baked Shadows（烘焙阴影）：这是最简单的理解。Mixed光源的阴影被完全烘焙到Lightmap中。动态物体不会向静态物体投射实时阴影（但可以接收烘焙阴影），静态物体也不会向动态物体投射阴影。性能最好，但动态静态物体交互感弱。
Shadowmask：Unity会生成一张额外的Shadowmask贴图，与Lightmap配合使用。这张贴图记录了“哪些静态区域应该受到实时阴影的影响”。当动态物体在Mixed光源下运动时，它能向静态地面投射实时阴影，并且这个阴影能与Lightmap中烘焙的静态阴影完美融合。这需要额外的纹理内存和带宽。
Distance Shadowmask：这是Shadowmask的智能版。在摄像机近处，它使用Shadowmask模式（动态阴影是实时的）；在摄像机远处，它自动切换回Baked Shadows模式以节省性能。你需要设置一个Shadow Distance阈值来控制切换距离。这是开放世界或大场景的推荐模式，在视觉质量和性能间取得了最佳平衡。

4.2 常见烘焙瑕疵与修复方案

下面是一个快速排查表格，列出了最常见的问题、可能的原因和解决方案：

问题现象	可能原因	排查与修复方案
漏光	模型本身有缝隙或非流形几何；Lightmap UV壳之间有重叠。	1. 检查模型网格，确保是“水密”的。在三维软件中检查并修复。 2. 检查UV2，确保不同部分的UV块在0-1空间内没有重叠，并留有足够padding。
黑斑/噪点	采样不足；模型面数过低；光照反弹次数太少；Indirect Resolution太低。	1. 增加Lightmapper的`Samples`（采样数）或`Filtering`（滤波）强度。 2. 对于重要模型，适当增加面数或使用平滑组。 3. 增加`Max Bounces`（如从2到3）。 4. 提高`Indirect Resolution`。
阴影边缘锯齿	Lightmap分辨率（物体Scale）太低；UV2展开有拉伸。	1. 提高该物体的`Scale In Lightmap`值。 2. 优化模型的UV2展开，减少拉伸。使用`Lightmap Visualization`模式查看纹素密度是否均匀。
间接光过亮/过暗	光源强度不合适；材质反光度（Albedo）设置不当；天空盒或环境光过强。	1. 调整光源`Intensity`，特别是用于烘焙的`Baked Intensity`。 2. 检查材质球，确保漫反射颜色（Albedo）不是纯白（1,1,1）或纯黑。纯白会反射所有光，导致间接光溢出；纯黑则不反射光。使用中间值。 3. 调整`Environment`面板中的`Environment Lighting`的`Intensity Multiplier`。
烘焙时间过长	场景过大过复杂；Indirect Resolution等参数设置过高；使用了CPU Progressive。	1. 尝试使用GPU Lightmapper进行预览和迭代。 2. 分层烘焙，只烘焙当前工作的区域。 3. 适当降低`Indirect Resolution`和`Max Bounces`。对于远处物体，降低其`Scale In Lightmap`。
动态物体与场景光照不融合	没有放置或烘焙光照探针。	1. 在场景中关键位置（房间角落、走廊、明暗交界处）创建`Light Probe Group`并放置探针。 2. 确保在烘焙前，探针组是启用的，并且执行了光照烘焙（探针数据也需要烘焙）。

4.3 性能分析与内存管理

烘焙不仅关乎画面，也关乎性能。你需要关注两点：

运行时内存：Lightmap是纹理，会占用显存/内存。一张2048x2048的RGBA Half Float格式Lightmap，占用内存约为2048 * 2048 * 8 bytes/channel * 4 channels / (1024*1024) ≈ 128 MB。压缩后（如BC7）可大幅减少。在Quality Settings中，可以设置Lightmap Compression和Lightmap Max Size来限制内存开销。
Draw Call与合批：使用Lightmap本身不会增加Draw Call。但是，Unity的静态合批和动态合批机制对使用了Lightmap的物体有特殊规则。静态合批需要物体不仅标记为Static，还要共享相同的材质和Lightmap。如果合批失败，Draw Call就会上升。使用Frame Debugger工具可以精确查看每一帧的Draw Call来源，检查是否因Lightmap使用不当导致合批中断。

5. 面向未来的光照技术栈

Unity的光照技术仍在快速演进。除了传统的烘焙，现代项目越来越多地采用混合方案：

Enlighten Realtime GI的替代品：Unity新的Enlighten Realtime Global Illumination系统已经 deprecated。社区和官方更倾向于使用光照探针体积或基于屏幕空间的方案（如SSGI）来模拟动态间接光。
Baked GI + 实时反射探针：对于光滑表面的全局光照，烘焙的Lightmap无法处理精确的镜面反射。这时需要布置反射探针，它可以烘焙场景的立方体贴图，为物体提供基于位置的精确反射环境，与Lightmap相辅相成。
GPU Driven Rendering：随着Unity DOTS/ECS和SRP（可编程渲染管线，如URP/HDRP）的成熟，完全由GPU驱动、包含复杂光照计算的渲染流程正在成为可能。这可能会在未来改变我们预计算光照的方式。

说到底，Unity的光照烘焙不是一个“一键完美”的魔法按钮，而是一套需要精心调校的物理模拟系统。从理解Lightmap的本质，到选择合适的光照器，再到配置每一个参数背后的意义，最后到解决实际生产中的各种“坑”，这个过程本身就是一次对计算机图形学和项目工程管理的深度实践。我的经验是，建立一个标准化的场景检查清单和参数预设库，能节省大量重复调试的时间。把每次遇到的诡异烘焙问题及其解决方案记录下来，你会逐渐形成自己的“光照直觉”，到那时，你就从烘焙的“受害者”变成了它的“掌控者”。