1. 项目概述：从“卡顿”到“流畅”的性能蜕变

在Unity项目开发的中后期，尤其是当场景复杂度提升、美术资源大量导入后，性能问题往往会像幽灵一样突然出现。最典型的症状就是“卡顿”——帧率（FPS）不稳定，画面一卡一卡的，在移动设备上可能直接导致发热和耗电剧增。很多开发者第一时间会去检查脚本逻辑、模型面数，但常常忽略了一个隐形的性能杀手：动态实时灯光。一个看似简单的方向光（Directional Light），如果照射到大量静态物体上，每一帧Unity都需要为这些物体重新计算光照，产生海量的DrawCall，这是导致CPU瓶颈和帧率波动的核心元凶之一。

“从‘卡顿’到‘流畅’”，这个标题精准地描述了灯光烘焙（Light Baking）带来的最直观收益。它不是一个高深莫测的黑科技，而是一套成熟、标准且效果立竿见影的优化流程。其核心原理，就是将场景中静态物体（Static Objects）的光照信息（包括直接光、间接光、阴影）预先计算好，并“烘焙”到这些物体自身的纹理（即光照贴图，Lightmap）上。运行时，这些物体不再需要实时计算光照，GPU直接读取烘焙好的光照贴图进行渲染，从而将原本每帧都需要进行的、昂贵的逐像素光照计算，转变为一次性的纹理采样操作。

DrawCall直降50%甚至更多，这绝非夸张。一个中等复杂度的室内场景，使用动态全局光照（如Unity的Enlighten或GPU Lightmapper实时计算），DrawCall轻松突破上千。而经过合理的静态划分和灯光烘焙后，DrawCall降到500以内是完全可以实现的。这不仅仅是数字上的变化，更是用户体验从“勉强能玩”到“流畅顺滑”的本质提升。本指南将带你深入灯光烘焙的每一个环节，从原理认知、工具配置、实操流程到避坑指南，手把手让你掌握这项让项目性能脱胎换骨的关键技能。

2. 核心原理：为什么灯光烘焙是性能优化的“王牌”

要理解灯光烘焙为何如此有效，我们必须先拆解Unity的渲染管线在遇到动态灯光和静态物体时，到底做了什么。

2.1 DrawCall的本质与动态光照的成本

DrawCall，简单理解就是CPU命令GPU“画一个东西”的指令。每次DrawCall都有固定的CPU开销。一个没有合并的网格（Mesh），使用独特的材质（Material），就会产生一次DrawCall。

当一盏动态灯光（如Directional Light, Point Light）照射物体时，Unity的渲染引擎（无论是内置管线、URP还是HDRP）为了计算该灯光对物体的影响，通常需要为这个物体准备额外的渲染通道（Pass）。例如，一个使用标准着色器（Standard Shader）的物体，被一盏动态方向光照射，除了自身的Base Pass，很可能还会增加一个额外的“Additive Pass”来叠加这盏光的效果。关键点来了：这个额外的Pass，对于每个受该灯光影响的、且未被合批的物体，都可能产生一次新的DrawCall。

假设你的场景有200个静态的箱子（每个都是独立的MeshRenderer），被一盏动态方向光照射。在不做任何优化的情况下，这200个箱子可能会产生200次DrawCall（Base Pass） + 200次DrawCall（为方向光增加的Additive Pass），总计400次。这仅仅是一盏灯的成本！如果再加上点光源、聚光灯，DrawCall数量会呈指数级增长，CPU瞬间被压垮，这就是“卡顿”的根源。

2.2 烘焙光照如何“消灭”DrawCall

灯光烘焙的思路是“以空间换时间，以预处理换实时计算”。

1. 预处理计算：在编辑器模式下（即开发阶段），Unity的灯光烘焙系统（如Progressive Lightmapper）会模拟光线在场景中的传播，包括直接照射、反射（间接光照）、阴影等所有光学现象，为每一个静态物体表面上的点，计算出一个最终的颜色值。
2. 生成光照贴图：这些计算好的颜色值不会凭空消失，而是被编码成一张或多张2D纹理——这就是光照贴图（Lightmap）。每个静态物体会被分配一个光照贴图上的特定区域（UV区块），用来存储它自身的光照信息。
3. 运行时替换：游戏运行时，这些静态物体使用的材质，其光照信息不再来自实时光源计算，而是直接采样绑定好的光照贴图。这意味着，渲染这200个箱子，不再需要为那盏方向光提交额外的Additive Pass DrawCall。它们很可能通过静态合批（Static Batching）被合并，最终渲染所有箱子所需的DrawCall可能只有个位数。

性能收益对比表：

注意：灯光烘焙并非万能。它只对标记为“Static”的物体生效。动态物体（玩家、NPC、可移动道具）无法享受此优化，它们仍需依赖实时光或光照探针（Light Probes）来与烘焙环境融合。因此，“动静分离”的设计思想是使用烘焙光照的前提。

2.3 核心工具：Unity的Lightmapping系统

Unity提供了两套主流的灯光烘焙系统：

• 渐进式光照贴图（Progressive Lightmapper）：这是当前的主流和默认选择。它提供交互式预览，所见即所得，非常适合迭代。它使用CPU或GPU进行路径追踪计算，质量高，但烘焙速度相对较慢，尤其对于大场景。
• Enlighten（旧版）：Unity旧版的默认烘焙系统，已被逐渐淘汰。它烘焙速度较快，但预览和迭代体验较差，且在某些间接光照场景下效果不如渐进式。

对于绝大多数项目，坚持使用Progressive Lightmapper（GPU模式）是最佳选择。它平衡了质量、易用性和性能。要启用它，只需打开Window > Rendering > Lighting窗口，在Lightmapping Settings中将Lightmapper选项改为Progressive GPU（如果显卡支持）或Progressive CPU。

3. 实战准备：场景与资源的标准化处理

在点击“Generate Lighting”按钮之前，大量的准备工作决定了烘焙的成败和效率。盲目烘焙只会得到糟糕的视觉效果和巨大的贴图资源。

3.1 物体的静态标记（Static Flag）策略

这是最关键的一步。在Hierarchy中选中一个物体，在Inspector右上角勾选Static复选框。但这其实是一个复合选项，点击下拉箭头，你会看到：

• Everything：将物体完全静态化，参与光照烘焙、遮挡剔除（Occlusion Culling）、导航网格（Navigation Static）等所有静态系统。
• Lightmap Static：我们最常用的选项。仅标记物体参与光照烘焙，但不一定参与其他静态系统。对于只希望烘焙光照但可能仍需移动（如通过脚本控制）的物体，不要勾选此项。
• Occluder Static / Occludee Static：参与遮挡剔除。
• Navigation Static：参与导航网格生成。

实操心得：不要滥用“Everything”我曾在一个项目初期，为了方便，给所有环境物体都勾选了“Everything”。结果后来需要为敌人生成导航网格时，发现一些本该可移动的障碍物也被算成了静态导航障碍，导致AI路径异常。正确的做法是：只勾选你确定该物体需要的静态属性。对于绝大多数静态环境美术资产（墙壁、地板、岩石、树木），只勾选Lightmap Static和Occluder Static（如果是大物体）即可。

3.2 光照贴图UV的生成与校验

光照贴图需要第二套UV坐标（UV1）来存储光照信息。Unity可以自动为没有第二套UV的模型生成“光照贴图UV”（Generate Lightmap UVs）。

操作路径：在Project窗口选中模型文件，在Inspector的Model分页下，找到Generate Lightmap UVs选项并勾选。然后点击Apply。

注意事项：自动生成的UV可能有问题自动生成算法（如“Pack Margin”）虽然方便，但对于复杂模型（如带有许多细小结构的雕塑、镂空家具）很容易产生UV重叠、拉伸或过大的间距。这会导致烘焙时出现难看的接缝、光斑或浪费光照贴图空间。

• 检查方法：在模型导入设置的Preview窗口，将UV Channel切换到1，查看生成的UV1布局是否均匀、无重叠。
• 解决方案：对于重要的、大面积的静态模型（如主建筑墙面、独特的地板），强烈建议由美术人员在3D建模软件（如Maya, 3ds Max, Blender）中手动展好第二套UV。手动展的UV利用率更高，烘焙质量更好。

3.3 材质与着色器的适配

确保你的静态物体使用的材质/着色器支持光照贴图。Unity的标准着色器（Standard）、通用渲染管线（URP）的Lit着色器、高清渲染管线（HDRP）的Lit着色器都默认支持。

• 检查项：在材质的Inspector中，确保Global Illumination属性设置为Baked或Both（如果该物体同时接受烘焙光和实时光）。如果设置为Realtime，则该材质将忽略烘焙光照。
• 自定义着色器：如果你使用了自定义Shader，需要确保其包含了光照贴图的采样逻辑。通常需要声明unity_Lightmap和unity_LightmapST等内置变量，并在片元着色器中采样。

4. 手把手烘焙流程：参数详解与性能权衡

一切准备就绪，现在打开Window > Rendering > Lighting窗口（Unity 2022+可能在Window > Rendering > Lighting Settings），我们进入核心操作区。

4.1 环境光与天空盒设置

在Environment标签页下：

• Source：设置环境光的来源。选择Color可以简单指定一个颜色，选择Gradient可以设置天空、地平线、地面的颜色渐变，选择Skybox则使用指定的天空盒材质。这里的环境光会作为间接光照的重要来源被烘焙进光照贴图。
• Environment Lighting>Intensity Multiplier：控制环境光的强度。值太大会使场景看起来平淡、缺乏对比；值太小则阴影区域会死黑。通常从1.0开始调试。
• Environment Reflections>Source：同样可以设置为天空盒，烘焙的反射探针会捕获天空盒信息，影响物体的反射效果。

提示：使用一个HDR（高动态范围）的天空盒或颜色，可以提供更丰富、更真实的间接照明信息，尤其是在室内场景，从窗户透入的天光会更有层次感。

4.2 灯光烘焙参数深度解析

切换到Lightmapping Settings标签页，这里是控制烘焙质量和性能的核心。

1. 灯光贴图分辨率（Lightmap Resolution）这是最重要的参数之一，单位是“纹素/单位”（texels per unit）。它定义了世界空间中每单位长度（通常是米）分配多少个光照贴图像素。

• 值越高：光照细节越丰富，阴影和间接光越平滑，但生成的光照贴图尺寸越大，内存占用越高，烘焙时间越长。
• 值越低：贴图尺寸小，内存占用低，烘焙快，但细节丢失，可能出现像素化（马赛克）的阴影。
• 常用参考值：
  • 室内精细场景（如房间内饰）：20 - 40
  • 室外建筑/中景物体：10 - 20
  • 大型地形、远景山脉：2 - 5

2. 灯光贴图尺寸（Lightmap Size）定义单张光照贴图的最大尺寸（如1024, 2048, 4096）。Unity会自动将多个静态物体的光照信息“打包”到一张或多张这个尺寸的贴图中。

• 策略：通常使用2048或4096。更大的尺寸可以减少贴图张数（即减少DrawCall），但单张贴图内存翻倍。不建议使用超过4096，因为很多移动设备不支持那么大的非2次幂尺寸贴图，且内存压力大。
• 打包效率：在烘焙后，查看Lighting窗口的Lightmaps标签，可以看到打包图（Atlas）的利用率。利用率过低（如低于50%）说明有很多空白空间，可以尝试提高Lightmap Resolution或调整物体的Scale In Lightmap参数。

3. 间接光照质量相关参数

• Indirect Resolution：通常设置为Lightmap Resolution的1/2到1倍。它控制间接光照（光线反弹）的计算精度。对于室内场景，间接光重要，可以设高些（如与分辨率相同）；对于室外，可以设低些。
• Lightmap Padding：物体在光照贴图上UV区块之间的间隔。防止纹理采样时“ bleed ”（颜色渗漏）。默认2-4像素通常足够，如果出现边缘渗色，可以适当增加到4-8。
• Direct Samples / Indirect Samples / Environment Samples：这些是渐进式光照贴图器的采样数。采样数直接决定最终质量和烘焙时间。编辑器预览（Bake按钮）可以用较低采样（如64-256）快速查看效果。最终发布烘焙（Generate Lighting）则需要高采样（如512-1024甚至更高）来消除噪点。

4. 压缩与编码

• Compression：勾选此选项会对光照贴图进行压缩，大幅减少磁盘和内存占用，但会引入轻微的压缩失真。发布版本务必勾选。
• Ambient Occlusion：在烘焙过程中计算环境光遮蔽（AO），让角落、缝隙更暗，增加物体的体积感和真实度。强烈建议勾选，它几乎不增加额外成本，但视觉效果提升显著。
• Directional Mode：选择Directional或Non-Directional。
  • Non-Directional：只烘焙光照颜色信息，存储量小。
  • Directional：额外烘焙主要光照方向信息，用于支持法线贴图（Normal Map）在烘焙光照下的细节表现，效果更真实，但贴图尺寸会增大（通常是4倍）。如果你的场景大量使用法线贴图，选择Directional；否则用Non-Directional以节省内存。

4.3 执行烘焙与监控

设置好参数后，可以先点击Bake按钮进行快速预览。在Progressive Lightmapper模式下，你可以在Scene视图实时看到光照逐渐计算、收敛的过程。

烘焙过程监控：

• 查看Lighting窗口底部的进度条和状态信息。
• 在Console窗口，切换到Lighting标签页，可以看到详细的烘焙日志，包括打包信息、警告（如重叠的UV）等。
• 烘焙时间可能从几分钟到数小时不等，取决于场景复杂度、分辨率和采样数。在迭代期，务必使用低分辨率、低采样进行快速烘焙。

当预览效果满意后，进行最终烘焙：点击Generate Lighting按钮（或者勾选Auto Generate然后触发一次烘焙）。最终的光照贴图会保存在项目目录的LightingData文件夹或指定的文件夹中。

5. 高级优化技巧与参数微调

掌握了基础烘焙后，这些进阶技巧能让你在质量和性能间找到更佳的平衡点，并解决一些特定问题。

5.1 按物体调整：Scale In Lightmap

不是所有物体都需要同样的光照细节。一个远处的石头和一个近处的精美雕像，应该区别对待。在物体的MeshRenderer组件上，有一个Scale In Lightmap参数（在Lighting部分）。

• 默认值为1，表示使用全局的Lightmap Resolution设置。
• 对于重要的、近处的、表面细节丰富的物体（如主角常接触的桌面、关键道具），可以将其提高到2或4，让它在光照贴图上占据更多像素，获得更精细的光影。
• 对于次要的、远处的或表面平滑的物体（如远景山体、大块平地），可以将其降低到0.5甚至0.25，节省宝贵的光照贴图空间。

实操心得：分级管理我会在场景中建立不同的空物体作为父节点，如“_HighResLM”、“_MidResLM”、“_LowResLM”，将不同重要性的静态物体拖入。然后可以写一个简单的编辑器脚本，批量修改同一父节点下所有物体的Scale In Lightmap值，效率极高。

5.2 解决漏光与阴影瑕疵

烘焙后常见问题之一是“漏光”（Light Leaking），即光线穿透了本应封闭的墙体或角落。

• 原因：模型本身有缝隙（建模问题）；或者烘焙时用于计算光线的“射线”穿过了过薄的单面墙体。
• 解决方案：
  1. 检查模型：确保所有封闭结构（如房间）的模型是严丝合缝的，没有破面或重叠面。
  2. 增加墙体厚度：在建模时，给墙体一定的厚度，而不是单一片面。
  3. 调整世界设置：在Lighting窗口的Lightmapping Settings中，找到Advanced Parameters（或类似名称），调整Bounces（反弹次数）和Filtering（过滤）参数。有时降低反弹次数或启用过滤可以缓解问题，但非根本解决。
  4. 使用光照贴图通道（Lightmap Channels）：对于复杂嵌套结构，可以尝试将内外部分离到不同的光照贴图通道，但这属于较高级的用法。

5.3 光照探针（Light Probes）混合动态物体

烘焙光照只作用于静态物体。那么动态物体（玩家、车辆）如何融入这个烘焙好的光照环境呢？答案就是光照探针（Light Probes）。

• 作用：光照探针在场景空间中采样烘焙好的光照信息（颜色和强度）。动态物体会根据其位置，从周围最近的几个探针中插值获取光照数据，从而让动态物体看起来像是处在烘焙光照的环境中。
• 布置技巧：
  • 在光照变化剧烈的区域（如门口、走廊拐角、灯光下）需要密集放置。
  • 在开阔、光照均匀的区域可以稀疏放置。
  • 使用Light Probe Group组件，在场景中可视化地放置探针点。一个常用的技巧是沿着角色的行动路径和活动区域进行布置。
  • 确保动态物体的MeshRenderer组件上勾选了Use Light Probes。

5.4 遮挡剔除（Occlusion Culling）的协同优化

灯光烘焙优化了渲染状态切换（DrawCall），而遮挡剔除优化的是根本不用渲染那些看不到的东西。两者结合，效果最佳。

• 原理：将大型静态物体（如建筑、山体）标记为Occluder Static，在烘焙阶段预计算其可见性。运行时，相机看不到的物体根本不会进入渲染队列。
• 操作：在Window > Rendering > Occlusion Culling中烘焙。对于大型开放世界，遮挡剔除的收益可能比灯光烘焙还要大。但需要注意，动态物体通常不作为遮挡物，且烘焙参数（如单元格大小）需要根据场景尺度仔细调整。

6. 性能验证与DrawCall分析实战

烘焙完成不是终点，我们必须用数据验证优化成果。

6.1 使用Frame Debugger逐帧分析

Unity的Frame Debugger（窗口 > 分析 > Frame Debugger）是分析DrawCall的终极利器。

1. 在Game视图运行游戏。
2. 打开Frame Debugger，点击Enable。
3. 逐帧（或逐DrawCall）步进，你可以清晰地看到每一帧GPU到底绘制了什么，以及为什么绘制。

对比分析：

• 烘焙前：你会看到大量名为“Render Forward: Additive”或类似名称的DrawCall条目，每一个都可能对应一个物体为某盏实时光进行的额外绘制。
• 烘焙后：这些“Additive”的DrawCall会大量消失。静态物体的绘制通常被合并到少数几个“Render Forward: Opaque”的DrawCall中，后面明确写着“Static Batching”。

在我的一个优化案例中，一个室内场景烘焙前，仅渲染静态家具的DrawCall就超过300次。烘焙并启用静态合批后，这些家具的DrawCall被合并为3次。这就是标题中“DrawCall直降50%”甚至90%以上的直观体现。

6.2 使用Profiler定位性能瓶颈

Profiler（窗口 > 分析 > Profiler）用于宏观性能分析。

• 查看Rendering区域：关注SetPass Calls（大致等同于DrawCall）和Batches的数量变化。烘焙优化后，这两个数值应有显著下降。
• 查看CPU Usage区域：观察RenderThread（渲染线程）和WaitForPresent（等待GPU）的时间。DrawCall减少会直接降低CPU的渲染准备工作负载，使RenderThread时间缩短，帧率更稳定。
• 内存考量：在Profiler的Memory区域，检查Texture Memory的增长。烘焙后，会新增光照贴图纹理内存。你需要权衡DrawCall降低带来的CPU性能提升和内存增长带来的负担。对于移动平台，尤其要注意光照贴图的总体尺寸和压缩格式。

6.3 目标平台的真机测试

编辑器中的数据仅供参考，最终性能表现必须在目标平台（尤其是安卓/iOS真机）上验证。

• 构建开发包：使用Development Build选项，并勾选Autoconnect Profiler和Deep Profiling。
• 连接真机Profiler：在Unity编辑器的Profiler窗口中，选择真机设备进行性能分析。
• 关注指标：除了帧率（FPS），更要关注帧时间的稳定性（有无卡顿 spikes）、内存占用、以及发热情况。一个成功的烘焙优化，应该带来更平滑的帧时间曲线和更低的CPU占用率。

7. 常见问题排查与避坑指南

即使按照流程操作，也难免会遇到各种“坑”。这里记录了一些典型问题及其解决方案。

问题1：烘焙后物体变黑或全白。

• 可能原因A：物体没有正确标记为Lightmap Static。检查Static标记。
• 可能原因B：物体的材质着色器不支持光照贴图，或者材质的Global Illumination属性设置错误。检查并确保其为Baked。
• 可能原因C：光照贴图UV（UV1）有问题，如重叠、翻转或未生成。检查模型的UV1通道。
• 可能原因D：场景中没有任何被标记为Baked或Mixed模式的灯光。至少需要一盏参与烘焙的灯。

问题2：光照贴图有接缝或像素化。

• 可能原因A：Lightmap Resolution设置过低。尝试提高分辨率。
• 可能原因B：物体的Scale In Lightmap值太小，导致分配到的像素不足。对于该物体，提高此值。
• 可能原因C：Lightmap Padding太小，导致纹理采样时边缘颜色渗漏。适当增加此值。
• 可能原因D：模型自身的UV1展开不当，存在拉伸或岛屿间距离太近。需要回3D软件调整UV。

问题3：动态物体在烘焙场景中颜色突兀或不匹配。

• 可能原因A：没有放置或正确放置光照探针（Light Probes）。动态物体需要光照探针来获取环境光。
• 可能原因B：光照探针放置太稀疏，或者没有覆盖动态物体的活动区域。在关键位置增加探针密度。
• 可能原因C：动态物体使用的材质对光照反应过强或过弱。调整其材质的反射率、金属度等参数，或使用后处理（Post-Processing）进行全局色调调和。

问题4：烘焙时间过长。

• 优化策略A：在迭代阶段，将Lightmap Resolution和所有采样数（Direct/Indirect Samples）调到最低，使用Bake按钮快速预览。
• 优化策略B：使用Progressive GPU模式（如果显卡支持），通常比CPU模式快很多。
• 优化策略C：将场景分块烘焙。对于超大型场景，可以将其分成多个子场景（使用Addressables或场景分块加载），分别烘焙光照。
• 优化策略D：检查场景中是否有不必要的、面数极高的物体被标记为Static，或者灯光数量是否过多。优化模型和精简灯光是根本。

问题5：构建后光照效果与编辑器不一致。

• 可能原因A：构建时没有包含光照数据。确保在Player Settings>Player>Other Settings中，Lightmap Encoding和Lightmap Stream等选项设置正确，并且光照数据被打包进构建。
• 可能原因B：使用了Directional模式的光照贴图，但目标平台的图形API不支持所需的纹理格式。尝试切换到Non-Directional模式。
• 可能原因C：某些自定义Shader在构建时没有正确处理光照贴图相关的变体（Variants）。检查Shader的编译日志和变体数量。

灯光烘焙是Unity性能优化中投入产出比极高的一环。它要求开发者对场景结构、资源管理和光照原理有更深的理解，而不仅仅是点击一个按钮。这个过程充满了权衡：分辨率与内存、质量与时间、静态与动态。但当你看到Profiler中骤降的DrawCall曲线和游戏中稳定流畅的画面时，所有这些细致的调整和等待都是值得的。记住，优化是一个持续的过程，灯光烘焙是其中坚实的第一步，它为后续的GPU优化、内存管理打下了坚实的基础。开始对你项目中那个最卡顿的场景动手吧，用数据见证从“卡顿”到“流畅”的蜕变。