如果你刚接触 UE5 地编，大概率已经看过很多把 Lumen 当作“UE5 光照王牌”的教程。默认新建项目一打开，室内场景在 Lumen 下确实很惊艳，光照会随着墙角、门缝和物体间来回反弹，看起来比 UE4 时代自然得多。但真正进入项目阶段后，你会遇到一个和教程里完全不同的现实问题：场景复杂度上来之后，Lumen 的实时计算开销一直在 GPU 上烧着，移动端和低配机器根本扛不住，最终还是要回到“烘焙光照”这条路上来。
这里要先给一个明确判断：烘焙光照不是 UE4 时代的遗留技术，而是 UE5 地编必须掌握的一项工程能力。它真正的价值不是“回归传统”，而是把光照效果从“每帧计算”变成“预先计算好的结果”，用确定性换性能。盲目迷信 Lumen，很可能会让项目在后期优化时付出比一开始就想清楚光照方案大得多的代价。
这篇文章会围绕几个问题展开：烘焙光照到底烘焙了什么？它和 Lumen 的本质差异在哪里？什么项目应该用烘焙光照？在 UE5 中怎么做烘焙光照工作流？以及烘焙后如何验证效果、排查常见问题。如果你是刚开始学 UE5 地编的新人，按这个顺序读下来，应该能少走很多弯路。
1. 为什么 UE5 中还要重新认识烘焙光照
很多新人因为看多了“Lumen 是 UE5 最大亮点”的宣传，会下意识觉得烘焙是旧方案，是 UE4 时代被迫使用的妥协做法。这种直觉有道理，但不完全对。
Lumen 改变的其实是“全局光照的计算时机”。它把光线在场景中的多次反弹放到运行时来做，好处是灯光改了、物体移动了、门开了关了，光照都能实时反应。但这个“实时”是有代价的：每一帧都要消耗 GPU 资源去追踪光线、维护缓存、做降噪处理。场景越大、光线反弹越复杂、物体越多，这个代价就越明显。
烘焙光照则反过来。它在编辑器阶段用 Lightmass 或者 GPU Lightmass 离线计算光线传播，把结果存进光照贴图，游戏运行时只需要做一次低开销的采样。你看到的仍然是三维场景里的真实光照效果，不是贴了一张假图，但计算过程被提前完成了。
明白了这一点，你就能理解为什么说烘焙光照在 UE5 中依然重要：它解决的是 Lumen 最尴尬的问题，也就是运行时性能。如果你的场景基本不变化，光照几乎固定，你为什么要每帧重复计算一遍雷同的结果？省下来的 GPU 预算可以用来提升角色特效、粒子、材质，或者让帧率更稳定。
从工程角度看，烘焙光照还有一个隐含优势：结果可预期。同一套灯光、同一个关卡，烘焙出来的效果是固定的，美术可以一条条确认并打磨。而实时全局光照因为跟渲染顺序、缓存、降噪器有关，某些情况下会出现帧与帧之间的噪声抖动，问题排查起来更复杂。对于上线项目来说，“结果稳定”本身就是一种宝贵的工程特性。
所以在 UE5 地编的工作里，真正值得学的不是“Lumen 比烘焙更高级”，而是“什么时候该用 Lumen，什么时候该用烘焙，两者如何组合”。这比盲目跟风默认设置重要得多。
2. 烘焙光照的核心原理与 Lumen 的差异
先补一个基础概念：全局光照，官方英文叫 Global Illumination，简写 GI。它的意思是光不仅从光源直接照到物体表面，还会在物体之间反弹。一个最简单的例子：你把一张白纸放在红色的墙旁边，白纸靠近墙的一侧会微微发红，这就是墙壁把红色光线反弹到了白纸上。全局光照负责的正是这部分间接光照。
在 UE5 中实现全局光照的主要方式有两种：
| 维度 | 烘焙光照 | Lumen |
|---|---|---|
| 计算时机 | 编辑器阶段离线计算 | 运行时实时计算 |
| 灯光变化 | 不能实时反应，需要重新构建 | 灯光移动、变色、开关都能即时响应 |
| 运行时开销 | 很低，主要是采样光照贴图 | 较高，依赖软件/硬件光线追踪和缓存 |
| 场景修改成本 | 每次修改都要重新构建 | 改完立刻可以看到结果 |
| 动态物体支持 | 动态物体接收间接光照较弱 | 动态物体也能比较自然地接收间接光 |
| 适合平台 | 移动端、低配 PC、主机都可接受 | 需要较好 GPU 预算，常用于高配 PC/主机 |
| 美术调试速度 | 慢，烘焙等待时间长 | 快，所见即所得 |
| 最终效果稳定性 | 高，结果可预期 | 依赖实时降噪，偶有噪声或闪烁 |
再解释一个关键词：光照贴图，英文 Lightmap。烘焙光照并不是把你看到的画面存成一张纹理直接贴上去。UE5 会为场景中的静态网格体准备一套额外的 UV 展开，然后把光照计算结果写入到这套 UV 对应的纹理里。运行时，材质系统读取这张贴图，把亮度叠加到物体表面。所以你会看到，一个灯光照射下的白色墙壁，Lightmap 中对应的区域是人眼难以直接看懂的亮度色块，但在场景中显示出来就是正确的光照效果。
这里有个地编新手最容易误解的地方：光照贴图和漫反射贴图是两回事。漫反射贴图决定物体表面本身的颜色，光照贴图决定物体表面接收到的光照量。烘焙光照时你并没有把一张“火焰效果图”贴在墙上，而是把光线计算后的亮度信息存进了一个独立的贴图通道。
另一个容易混淆的概念是“直接光照”和“间接光照”。直接光照是光源直接照到物体表面，阴影清晰；间接光照是光线经过一次或多次反弹后照到物体表面，阴影柔和，色彩会受环境影响。烘焙光照里通常两者都会处理，但“间接光照”才是 Lightmass 花时间计算的大头。
Lumen 和烘焙光照在视觉上的差异主要集中在动态变化的部分。Lumen 能处理开着门时阳光射进室内的动态变化，能处理汽车开过时灯光照到墙壁上产生的颜色偏移。烘焙光照里，这些都只能靠美术手动模拟，或者用其他动态灯补充。看到区别后你就知道，烘焙并不总能替代 Lumen，它更适合自己擅长的那一类场景。
3. 哪些项目适合用烘焙光照
判断一个项目要不要用烘焙，核心看三个条件：目标平台是什么，场景变化是否频繁，性能预算是否紧张。
先从目标平台看。手机游戏，尤其是低端安卓设备，GPU 能力有限，跑 Lumen 的实时全局光照会非常吃力。UE5 虽然能导出移动端项目，但 Lumen 的 CPU/GPU 消耗对大部分移动端设备仍然偏大。大多数移动端 UE5 项目都会采用烘焙光照，或者只保留少量动态点光源来补充角色周围的效果。除了移动端，一些面向低配 PC 或集成显卡的项目、电竞类对帧率稳定性要求极高的项目，也倾向于烘焙。
再从场景类型看。如果你的关卡是室内建筑、走廊、密室、医院、学校、住宅，这些场景里绝大多数物体是静态的，灯光位置固定，照射关系稳定，那就是烘焙光照的典型适用场景。烘焙出来的效果既能做到柔和、真实，又能保证低开销。反过来，如果是个开放世界，要求有昼夜循环和动态天气，或者玩家可以破坏墙体、开关大门、搬运光源，那烘焙光照就会很痛苦，因为场景里几乎没有东西是“固定不变”的。
第三看项目迭代方式。烘焙光照有个明显缺点：改一次灯光就要重新构建，等待时间长。如果你的项目还在频繁调整场景布局，先用 Lumen 直接摆灯光确实是更快的调试方式。但如果项目接近上线，灯光方案已经确定，那尽早切成烘焙光照会更好，因为它在性能和稳定性上的收益能真正体现出来。
地编实际项目中还有一种很常见的混合方案：大面积静态建筑和地形用烘焙光照，角色和需要高光表现的物件旁边再加可移动的实时点光源或者反射捕获。这样做的好处是，静态场景用烘焙兜底，动态区域用实时光补足，最终能兼顾性能和表现。很多手游和风格化作品都用这个思路。
如果你正处于项目选型阶段，建议先不要凭感觉定方案，而是用一个有代表性的房间或者街区原型，分别用 Lumen 和烘焙各做一遍，测帧率、测内存、测迭代舒适度。测试数据比任何教程判断都可靠。
4. UE5 环境准备与光照路径选择
开始做烘焙前，先确保你的环境适合这个工作流。UE5 的安装这里不展开细说，版本以实际项目为准。本文演示的核心是烘焙光照思路，5.0 到 5.4 的主流程基本一致，但不同小版本的菜单名称和默认设置可能略有差异，实际操作时以你本地编辑器界面为准。
打开 UE5 编辑器后，先做一件事：打开项目设置。具体路径是 Edit菜单下的 Project Settings，然后找到 Engine 分类下的 Rendering 设置。渲染设置里通常有一组和全局光照相关的选项，比如 Global Illumination Method 和 Reflections Method。默认情况下，UE5 新建项目会启用 Lumen，你需要根据项目目标决定是否把它切换为无 Lumen 或传统模式。
这里有个细节要特别注意：把全局光照从 Lumen 切走后，场景中的反射效果会立刻变弱。Lumen 不仅负责间接光照，也负责一部分反射。切到烘焙光照后，你需要用其他手段补充反射表现，比如放置 Reflection Capture 反射捕获组件，或者启用屏幕空间反射。很多地编第一次切换后觉得“画面变丑了”，其实不是因为烘焙不好，而是因为反射方案没有同步调整。
除了项目设置，还要检查静态网格体的 Lightmap UV 是否齐全。关于 Lightmap UV，上一节已经解释过，它是一套额外的 UV 通道，负责承接光照贴图。大部分建模软件导出的模型只有一套常规 UV，这时导入 UE5 时，需要勾选 Generate Lightmap UVs 让引擎自动生成第二套 UV。如果模型没有这套 UV，烘焙时要么不亮，要么出现奇怪的UV拉伸和黑斑。
如果你是从 UE4 项目升级到 UE5，还需要格外检查材质中使用的高光模型是否需要调整。UE5 默认光照模型和 UE4 不完全一致，升级后烘焙结果可能略有变化。一般来说，升级后的第一件事应该是重新构建光照，再对照前后截图差异。
环境准备阶段最后要做的事，是确定关卡中灯光的移动性。UE 中有三种灯光移动性：可移动、固定、静态。你可以在关卡中选中灯光的 Details 面板里找到 Mobility 属性。烘焙光照通常推荐把灯设置为“固定”而不是“静态”，原因我们下一步详细讲。
5. 烘焙光照地编实操流程
下面进入完整的实操流程。为了便于学习和排查，建议用一个简单房间关卡作为测试场景，先不要在复杂大世界里直接尝试。
5.1 项目级光照模式设置
在项目设置里把 Global Illumination Method 调整为无 Lumen 或传统静态光照模式。如果没有这个选项，至少确认当前项目不是强制开启 Lumen 的状态。把 Reflections Method 也确认一遍，避免烘焙后反射缺失。
这里真正容易踩坑的地方是：很多人只关了 Lumen，忘记关闭 Virtual Shadow Maps 或者高成本阴影选项。烘焙光照本来是为了省性能，如果阴影方案和反射方案仍然开着高开销配置，帧率优化效果就会打折扣。不过不同版本的默认阴影方案不同，具体以实际项目设置为准，不要机械照搬教程配置。
5.2 设置灯光移动性
在关卡中放置主要光源，例如方向光 DirectionalLight 作为太阳光，天空光 SkyLight 作为环境光。对于室内场景，再加补光用的点光源或聚光灯。
推荐把主要灯光 Mobility 设置为“固定”。固定灯的效果是：间接光照部分烘焙进光照贴图，但直接光照和阴影仍然有一定动态能力。这样室内静态物体上的柔和反光稳定且性能低，动态物体靠近光源时也能产生动态阴影，视觉衔接相对自然。
如果只追求极致的低开销，可以把灯光设为“静态”，但静态灯的动态能力更弱，角色走过去可能得不到灯光的动态阴影，看起来会比较假。所以实际项目中“固定”用得更多。
5.3 检查 Lightmap UV
选中场景中要参与烘焙的静态网格体，在细节面板里找到 Lightmap UV 相关设置。如果网格体是从外部导入的，确认导入时已经勾选自动生成 Lightmap UV，或者导入后在 Static Mesh 编辑器里重新生成。
这一步做错的话，烘焙完成后常见的现象是：有些地板非常亮，有些墙面却完全是黑色，而且 UV 展开不合理的地方会出现明显拉伸线条。排查时先选中出问题的网格体，在 Mesh Editor 里看第二套 UV 是否存在，以及是否重叠或超出 0 到 1 的范围。
5.4 布置灯光与阴影参数
灯光布置尽量模拟真实场景。方向光给主基调，天空光负责填满没有直接光照的阴影区，点光和聚光灯重点照亮需要视觉表现突出的区域。烘焙光照对阴影的清晰度敏感，阴影参数里 Shadow Bias 过大会让接触阴影产生偏移，过小又会出现阴影闪烁。比较稳妥的方法是先用默认值，发现影子漂浮或者漏光时再微调。
5.5 调整 Lightmass 构建质量
在编辑器工具栏的 Build 下拉菜单里，可以选择 Lighting Quality，常见档位有 Preview、Medium、High、Production。Preview 质量低但速度快，适合测试布局；Production 质量高但构建时间长，适合最终出效果。
在 World Settings 面板里也能找到 Lightmass 相关选项，例如间接光照质量、间接光照平滑度、静态光照强度缩放等。这些参数会直接影响烘焙亮度和平滑度。第一次做烘焙时，先用默认值跑通，再一点点调参数，不要一开始就追求复杂设置。
5.6 执行 Build Lighting 并检查结果
确定关卡中的灯光都放好后，点击 Build 菜单下的 Build Lighting。编辑器会进入构建阶段，视情况可以看到 CPU Lightmass 或 GPU Lightmass 的工作进度。构建完成后，场景光照会自动刷新。如果编辑器顶部出现“Lighting needs to be rebuilt”的提示，说明关卡中还有灯光或地块被修改过，需要重新构建一次。
初次烘焙时如果发现场景过暗，优先检查天空光的强度以及 Indirect Lighting Scale 这类全局参数。如果发现某些模型不接收间接光，优先检查该模型的 Lightmap UV 和是否参与静态光照计算。
6. 配置示例与常用命令
虽然 UE5 地编大部分工作是在编辑器界面里用鼠标完成的，但一个合格的地编还是要懂一些配置和命令，方便快速排查问题、接入团队管线。
6.1 项目设置中的示意配置
如果你的团队希望把光照模式固定下来，通常会在 DefaultEngine.ini 或者项目基础配置里固定相关设置。这里给一个排查思路用的示意片段，不是让你直接照抄到生产项目，因为不同小版本的字段名可能不一样：
; DefaultEngine.ini（示意，版本和字段名以编辑器面板为准） [/Script/Engine.RendererSettings] ; 允许静态光照参与构建 r.AllowStaticLighting=1 ; 全局光照方法切换为无 Lumen 或传统静态光照 ; 具体取值根据 UE 版本确认 r.DynamicGlobalIllumination.Method=0推荐的实际操作方式不是直接改 ini，而是在 Project Settings 的 Rendering 面板中修改对应选项，然后让引擎自己写入配置。你只需要知道:当团队代码审查或版本排查时，可能会有人打开 ini 查看这些渲染开关，因此看到这类字段要知道它大概在决定什么。
6.2 编辑器控制台常用命令
在 UE5 编辑器或运行时，可以按键盘左上角波浪号“`”打开控制台，输入命令观察渲染状态。
stat GPU stat unit r.DynamicGlobalIllumination.Method 0stat GPU会显示 GPU 各模块的耗时拆分。烘焙光照生效后，你可以看到与全局光照相关模块的GPU耗时明显下降。stat unit则显示帧率以及 CPU 和 GPU 的帧耗时，判断当前瓶颈在哪里。最后一个命令是运行时强制关闭动态全局光照的一种尝试，但实际项目中更推荐在项目设置里固定方案，而不是运行时临时切。
6.3 命令行启动与日志观察
如果需要查看启动时的光照设置和渲染日志，可以用命令行方式启动项目：
UnrealEditor.exe "D:/MyProject/MyProject.uproject" -log -NoSplash打开日志后搜索 Lightmass 或者 Lighting 相关关键词，能确认关卡是否曾执行过构建、构建过程中有没有报错。开始接触 CI 自动化构建时，这条命令的价值会更明显。
如果你确实需要在命令行里触发烘焙，官方文档中通常能找到对应 Commandlet 或构建参数。但因为不同版本的命令名称有变动，直接在生产环境中盲猜命令是很危险的。稳妥做法是：先在编辑器里手动点一次 Build Lighting，观察日志输出；再由 TA 或程序同学根据官方文档确认自动化命令参数。
6.4 关于 GPU Lightmass
UE5 中烘焙光照的计算由 Lightmass 完成，分为 CPU Lightmass 和 GPU Lightmass。GPU Lightmass 利用显卡并行计算，速度更快，适合反复迭代。使用 GPU Lightmass 时需要确认项目插件已经启用，并且电脑显卡支持相应计算能力。
从地编体验看，GPU Lightmass 让“烘焙后还能继续快速迭代”这件事成为可能，这也是 UE5 下烘焙工作流不至于太痛苦的重要原因。
7. 烘焙效果的验证与性能评估
烘焙完成后，不要只看“哇，场景亮了”就结束。要验证两个层面：视觉正确性和性能收益。
视觉上，先绕场景走一圈，重点检查四类问题。第一，看接触阴影和墙角阴影是否显得脏或者飘。第二，看 Lightmap 接缝处有没有明显的亮度断层。第三，看深色材质和浅色材质交接的位置有没有漏光。第四，让一个动态角色走进烘焙区域，观察角色身上是否出现明显的不协调感，比如脚下没有接触阴影，或者靠近墙面时身上没有间接光颜色影响。如果发现异常，说明场景中某些部分需要调度动态补充光，或者 Lightmap UV 处理不到位。
性能上，先打开控制台执行stat unit和stat GPU。在相同场景、相同视角下，分别记录 Lumen 模式和烘焙模式下的帧耗时。如果帧号波动很大，说明性能瓶颈不在光照上，可能是材质或模型面数问题；如果开启烘焙光照后帧率稳定在某一个更合理范围，说明优化有效。
内存方面，也需要看一下光照贴图占用。烘焙光照会把所有 Lightmap 纹理加载进内存。场景越大、Lightmap 分辨率越高，内存占用越高。遇到内存压力时，优先降低大面积远处物体的 Lightmap 分辨率，而不是一刀切全部降低。
最后一点：烘焙完成后，检查关卡中是否还有“Lighting needs to be rebuilt”提示。有这个提示意味着当前关卡的光照数据已经过期，正式打包前必须重新构建，否则可能会出现画面与性能不一致的异常情况。
8. 常见问题与排查方法
烘焙光照的问题往往不是出在“按一下 Build”这个动作上，而是出在流程前面的准备阶段。下面整理地编高频问题：
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 烘焙后场景一片黑 | 灯光未参与静态光照，或天空光强度过低 | 检查灯光的 Mobility 是否为 Static/Fixed；确认 Lightmap UV | 将灯光设为固定或静态，重新构建 |
| 局部物体不接收间接光 | 该模型缺少 Lightmap UV | 进入 Static Mesh Editor 查看第二套 UV | 导入时勾选 Generate Lightmap UVs，或手动生成 |
| 墙面和地面出现黑色纹路 | Lightmap UV 拉伸或重叠 | 在 Mesh Editor 中展开 UV，查看是否在 0-1 范围且不重叠 | 修复模型 UV，或提高 Lightmap 分辨率 |
| Lightmap 接缝明显 | 不同模型分辨率不一致或 UV chart 边界接缝 | 检查接缝处两张表面的分辨率设置 | 统一相邻模型的光照贴图分辨率，添加材质接缝修复 |
| 烘焙时间特别长 | 场景过大、灯光太多、质量档位过高 | 查看 Build Lighting 日志，定位占用较高的子关卡 | 拆分子关卡分区烘焙，先 Preview 档验证 |
| 关闭 Lumen 后反射消失 | 反射方案未补 | 检查 Reflections Method 和场景中 Reflection Captures 数量 | 摆放反射捕获组件，或者启用屏幕空间反射 |
| 动态角色在室内感觉像“浮起来” | 动态物体没有接触阴影 | 检查动态角色脚下阴影是否有实时光源支持 | 在角色附近补充可移动点光源/方向光，或调整动态阴影设置 |
| 改完灯光后画面没有变化 | 没有重新构建光照 | 查看关卡是否有 Lighting needs rebuilt 提示 | 点击 Build Lighting 重新生成 |
这些问题是地编学习烘焙光照过程中比较典型的，但也不必把表格当成万能诊断书。遇到问题首先要看日志，其次是缩小排查范围，用简单的小房间测试场景复现问题，而不是在一个巨大场景里瞎猜。
如果你的 UE5 版本较新，界面里可能把菜单名字改成了 Build 或者 Lighting 相关的其他位置，操作时多用搜索框搜关键词，可以少走很多弯路。
9. 地编工程最佳实践
知识原理讲完之后，说说工程上怎么避坑。
第一，尽早决定光照方案。如果你的项目明确目标是移动端或低配平台，那么在搭建第一个原型关卡时就把 Lumen 关掉，直接用烘焙工作流。到后期再切方案会牵涉大量模型 UV、灯光设置、反射捕获和性能预算调整，返工成本非常高。
第二，模块化构建关卡。很多地编习惯把整个大世界放在一个关卡里，结果每次改一盏灯都要全图重新烘焙，时间长得让人崩溃。更合理的做法是按照区域拆分子关卡，用 Level Streaming 加载。烘焙的时候可以只针对当前区域构建，其他区域的光照数据保留。这个习惯在场景规模变大后会显著提升效率。
第三，控制光照贴图分辨率。大的墙体、地面和地形不需要特别高的 Lightmap 分辨率，而玩家经常贴近观察的关键物体，比如桌子上的装饰、门框、柱子，值得分配更高分辨率。地编项目里最容易出现的问题就是无差别全场景提高分辨率，最后内存爆了、烘焙时间长了，画面却看不出明显提升。
第四，养成版本管理习惯。烘焙数据属于资产的一部分，和蓝图、模型一样应该纳入版本控制。多人协作时，尽量让同一个人在同一时间段负责同一区域的灯光和烘焙，避免两个人同时修改一个场景导致不断触发重新构建。
第五，动态物体补偿。烘焙光照下动态物体的间接光响应会变弱，不要等到项目后期才处理。最常用的做法是给角色身上挂一个小的可移动点光源，或者在关键交互区域补一盏点亮动态元素的灯。另一种做法是使用光照探针或反射捕获来补充动态物体周围的环境颜色信息，让角色和场景之间的视觉关系更自然。
第六，保留一套快速预览档位。项目里可以预先存一套低质量光照构建存档，专门用于白天开发和测试玩法。正式出画面时才切换到高质量烘焙。这样既不牺牲最终效果，也不会让每次操作都被烘焙时间打断。
这些最佳实践未必都能在第一个项目里全部实施，但至少要有这个意识。地编能力提升到后期，比的不是谁能打开编辑器拖一个好看的光影，而是谁能稳定、快速地交付高质量场景。
10. 总结：地编不要把“实时”当成唯一标准
回到开头的问题上来。烘焙光照在 UE5 中依然重要的原因，不是因为它是某个老版本沿袭下来的传统，而是因为它背后代表了一种工程路径：离线计算光照，锁定结果，降低运行时成本，获得可控的画面。Lumen 代表另一种路径：实时计算光照，追求动态变化，付出性能代价。两者之间没有绝对的先进与落后，只有适合与不适合。
地编工作真正考验的是你在一开始就能判断项目适合哪条路径，并且有能力把该路径下的工作流跑通。如果你现在正在学习 UE5，建议先找一个小房间模型，用烘焙光照从头到尾做一遍：检查模型 Lightmap UV，布置灯光，切换固定移动性，点击 Build Lighting，再用 stat GPU 对比 Lumen 模式下的性能差异。亲手操作一遍，比看十篇理论文章都有效。
后面你可以继续深入三个方向：Lightmass 参数对效果的具体影响、Volumetric Lightmap 在动态物体间接光照上的应用、以及烘焙光照与 Virtual Shadow Maps 如何配合。理解层次越深，你在不同项目之间切换光照方案时就会越有底气。
