如果你刚接触 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.AllowStaticLighting1 ; 全局光照方法切换为无 Lumen 或传统静态光照 ; 具体取值根据 UE 版本确认 r.DynamicGlobalIllumination.Method0推荐的实际操作方式不是直接改 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 LightmassUE5 中烘焙光照的计算由 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 如何配合。理解层次越深你在不同项目之间切换光照方案时就会越有底气。 
长河君 · 2026/10/1 17:02:11 · 阅读 1.2k UE5地编必会：烘焙光照原理与Lumen差异及实操指南
如果你刚接触 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.AllowStaticLighting1 ; 全局光照方法切换为无 Lumen 或传统静态光照 ; 具体取值根据 UE 版本确认 r.DynamicGlobalIllumination.Method0推荐的实际操作方式不是直接改 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 LightmassUE5 中烘焙光照的计算由 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 如何配合。理解层次越深你在不同项目之间切换光照方案时就会越有底气。