UE5烘焙光照实战：从Lumen切换到Baked的完整指南

1. 为什么“都 Lumen 了”还要提烘焙光照

1.1 Lumen 很好看，但它不是免费性能

UE5 上线之后，很多人默认了一个结论：Lumen 已经解决了全局光照问题，烘焙光照是 UE4 时代的旧工作流，没必要再学。但真正落到地编项目里，会发现这个结论只对“高性能 PC 演示场景”成立。地编项目包含大量静态网格体、植被、建筑立面、巷道和小道具，Lumen 的 Surface Cache 需要不断更新可视范围附近的几何信息，移动视角时会产生额外的 GPU 开销；开放地形场景中，屏幕空间追踪和距离场追踪的命中率会随遮挡关系变化而波动，帧率表现并不稳定。

这时候如果切到烘焙光照，把环境里绝大部分静态物体的间接光照预先计算好，运行时每帧只需采样 lightmap 纹理，几乎不增加着色器负担。同一个场景，光照效果和目标帧率往往能同时保住。越来越多的地编项目开始采用“静态环境烘焙 + 少数动态光”的混合方案，而不是全程 Lumen。所以烘焙光照并不是“过时技术”，而是一个在成本、质量、稳定性和可控性之间做取舍的核心工具。

本文面向 UE5 地编初学者和需要做性能优化、移动端适配、开放世界关卡的美术开发者。读完你会理解烘焙光照的原理、UE5 中怎么关闭 Lumen 切换回烘焙方案、怎么搭建一个小场景完成 Build Lighting，以及遇到黑块、漏光、烘焙过慢时如何排查。

1.2 什么是烘焙光照

先给一个通俗解释。烘焙光照的本质是“把光照结果提前算好，存起来，运行时不重新计算”。

在引擎中，灯光照射到物体表面后，会产生直接光照和间接光照。传统实时渲染只计算直接光照，而间接光照需要额外手段。Lumen 的做法是运行时实时计算全局光照；烘焙光照的做法则是在编辑器里启动一个离线计算程序，模拟光线在场景中多次反弹，把最终亮度、阴影、AO 等信息写入贴图，游戏运行时直接采样。

这个“先算好、再采样”的过程就叫烘焙。烘焙后的数据通常以 lightmap（光照贴图）的形式存在，局部范围内它给出的结果非常准确，没有实时降噪带来的画面闪烁，也没有随机噪声。代价是静态物体一旦移动位置，光照必须重新烘焙；动态物体也无法直接从静态 lightmap 中获取间接光照，需要额外方案衔接。

1.3 烘焙光照在 UE5 中的定位

要理解烘焙在 UE5 中的地位，必须先看清 Lumen 和烘焙光照的分工。Lumen 是 UE5 默认的动态全局光照方案，擅长处理动态几何体、动态天空、时间变化明显的场景；烘焙光照则更适合光照条件相对固定、性能预算紧张的平台，比如移动端、低功耗设备，或者需要精确美术控制的室内场景。

从团队协作角度看，烘焙还有一个重要优势：结果确定、可评审。Lumen 在不同帧率、不同硬件、不同分辨率下可能有细微差异，烘焙结果一旦生成，所有同事打开看到的是同一张图。对于建筑可视化、影视预览、电商展示这类需要“锁版本”交付的项目，烘焙光照依然是更稳的选择。

烘焙光照在 UE5 中并没有消失，而是作为可选的 Global Illumination 方案保留下来。把它理解成“静态场景的高质量预计算方案”，是最准确的位置。

2. 环境准备与版本说明

2.1 UE5 安装与项目创建

开始实操前，先确保本机已经安装 UE5 系列引擎。打开 Epic Games Launcher，在左侧选择“虚幻引擎”，点击“安装”，选择你需要的 5.x 小版本。注意版本不需要追新到某一个特定小版本，不同小版本在光照设置界面可能有位置差异，但核心概念一致，本文以常见 UE5.1 到 UE5.4 的界面为例。

安装完成后，从启动器点击“启动”，选择“Games”分类下的“Blank”空白模板创建新项目。空白模板没有多余的范例资产，适合我们做最小化光照实验。项目默认包含一张空白关卡，可以在内容浏览器中新建/Game/LightingDemo文件夹作为实验目录。

2.2 在项目中关闭 Lumen 切换回烘焙光照

UE5 默认开启 Lumen 作为全局光照方案。要体验烘焙光照，需要先修改项目渲染设置。路径为：Edit > Project Settings > Engine > Rendering > Global Illumination。

在Dynamic Global Illumination Method下拉框中，从默认的 Lumen 切换为 Baked。同样是渲染设置里，Reflection Method如果原来是 Lumen，也需要根据目标效果切换为 Screen Space 或使用 Reflection Capture。这一步很关键：只切换 GI 方法，反射仍走 Lumen 的话，静态烘焙场景反而会多出一笔不必要的 GPU 开销。

修改项目设置后，建议保存并重启编辑器。因为 Lumen 的某些渲染管线状态、Shader 编译缓存是在项目打开时初始化的，不重启可能看到旧管线残留导致的异常。实际操作中，遇到修改后画面无变化、控制台报错找不到 Lumen 资源等情况，都可以先做一次重启排除。

2.3 烘焙光照对硬件的要求

烘焙光照对运行时硬件的要求低，但对烘焙机的 CPU 和内存要求不低。Lightmass 是离线求解器，主要靠 CPU 多线程加速。一个中等规模室内场景若无脑提高 lightmap 精度，烘焙时间可以轻松超过半小时；内存不足时还会直接报错退出。

建议开发机满足：

• 6 核以上的 CPU，烘焙时能明显缩短等待时间。
• 16GB 起步，30GB 以上更稳妥，开放地形或大面积场景建议更大内存。
• 固态硬盘，烘焙过程涉及大量文件写入和 DDC（派生数据缓存）读取。

显卡反而没那么重要。烘焙是预计算，不是实时渲染，显卡只需要留在编辑器里显示结果就行。因此日常开发时，完全可以用一台 CPU 较强、显卡中等的机器做烘焙工作。

3. 烘焙光照核心原理拆解

3.1 Lightmap：把光照信息写进纹理

Lightmap 是烘焙光照的数据载体，中文常叫光照贴图。它可以理解成一张特殊的纹理，记录了场景表面每个点的入射亮度、颜色、阴影等信息。静态物体最终渲染时，基础贴图负责颜色，lightmap 负责“这张皮上被光照亮到多少”。

在 UE 中，一个静态网格体通常有两组 UV：UV0 是美术制作时的常规纹理坐标，UV1（也叫 Lightmap UV / UV2）专门用于采样 lightmap。烘焙器会把空间中的光照结果，按照 UV1 的展开方式写入纹理，因此 UV1 的布局是否合理，直接决定烘焙结果是否有接缝、拉伸、糊成一片。

新手最容易犯的错误是：模型有 UV0 就以为能烘焙。如果静态网格体没有合法的 Lightmap UV，烘焙完成后看到的不是照明结果，而是大面积的黑色或棋盘格。后续实战里我们会实际检查这一项。

3.2 Lightmass：离线光照求解器

UE 用来计算烘焙光照的离线程序叫 Lightmass。它本质上是一个独立的光线传播求解器，接收关卡中的光源、静态几何体、材质反射属性，计算直接光照、多次弹射光照、环境光遮蔽等数据，最后输出 lightmap 和 volumetric lightmap（体积光照贴图）。

在 UE4 时代，烘焙流程已经是“点一下 Build Lighting，然后等 Lightmass 跑完”。UE5 保留了这条链路。需要注意，Lightmass 结果并不存储在某个独立文件夹里，而是与关卡绑定，打开关卡执行烘焙后，数据会写入关卡自身的 MapBuildData。保存关卡后，这个数据会一起保存到.umap文件里。团队协同开发时，负责烘焙的同事必须把保存后的.umap提交到版本库，其他人才能看到烘焙结果。

3.3 Static、Stationary、Movable 三种灯光角色

烘焙光照下，灯光的 Mobility（移动性）自己设置的。这是 UE 灯光最重要的分类方式：

烘焙光照之所以高效，核心是利用 Static 和 Stationary 光源的“间接部分预计算”。如果场景里大量使用 Movable 光源，烘焙的效果会被削弱，因为动态光源无法把间接光照写入 lightmap，需要额外的动态手段来补。

3.4 决定烘焙质量的关键参数

烘焙不是一键出结果，以下几项参数直接决定质量和耗时：

• Static Lighting Level Scale：全局光照缩放系数，数值越大代表每个纹素覆盖的世界面积越大，结果越粗糙；数值小于 1 会提高精度，但烘焙时间也会成倍增加。
• Lightmap Resolution：灯光上单独控制的烘焙精度，和全局系数叠加。实际项目中，主光、辅助光、室内点光可以给不同精度，而不是所有灯光统一一套参数。
• Num Indirect Lighting Bounces：间接光反弹次数。默认 3 次已经够大多数场景使用，增加反弹次数会明显提升色彩渗透质量，但烘焙时间也随之增加。
• Indirect Lighting Quality：间接光采样质量。数值越高，烘焙结果越干净，噪点和断痕越少。
• Use Ambient Occlusion：是否烘焙 AO。能让墙角、物体接触线、植被底部多一层柔和阴影，对地编场景的“接地感”提升非常直接。

理解这些参数后，你就不会再盲目调高“烘焙清晰度”了。正确的做法是先定场景范围，再按物体重要程度分层设置精度。

4. 完整实战：一个可复现的小烘焙场景

4.1 搭建基础场景

我们做一个能完整走通烘焙流程的小场景：一块地面、几面墙壁、两个几何组合体，再加一个主光源和一个辅助点光。不需要美术资产，用引擎自带的基础体即可。

在内容浏览器中打开Engine > Basic Shapes，拖入一个 Cube 到场景作为地面，缩放为长宽 1000、高度 20 左右。再拖入几个 Cube 和 Sphere，搭成一个类似走廊的遮挡结构。建议把体积小、张数少的几何体当作“静态物体”处理，不要让它们有碰撞和复杂属性，保持场景干净。

摆放完成后，在 World Outliner 中全选这些基础体，在 Details 面板确认 Mobility 是 Static。静态网格体的 Mobility 如果不是 Static，烘焙器会把它当动态物体跳过，最终的 lightmap 上不会出现它的信息。

4.2 放置静态灯光和天空光

场景里需要两类灯光：定向光模拟室外主光，点光模拟局部补光；再加一个 SkyLight 提供天空环境亮度。

在 Place Actors 面板搜索 Directional Light 拖入场景，设置 Mobility 为 Static，然后调整角度让它形成长影子。强度可以先按住默认值，等初步烘焙后再微调。接着放置一个 Point Light，Mobility 设为 Static，位置放在走廊转角，颜色调成偏暖，强度不宜过大，避免亮部一片惨白。

加入 SkyLight 时，建议把它拖到场景上方，Mobility 设置为 Static，并在 Details 面板中开启Cast Shadows，这样烘焙时 SkyLight 也能参与 AO 计算。如果换了天空环境贴图，需要右键 SkyLight 选择 Recreate Captured Scene，重新采集环境数据。

4.3 检查并生成 Lightmap UV

这是新手最容易踩坑的一步。在内容浏览器里双击刚才使用的基础体 Cube，打开 Static Mesh Editor。在右侧 Mesh Settings 中找到Generate Lightmap UVs，确认勾选；如果是从外部 DCC 软件导入的模型，这一步尤其重要。导入的 FBX 在没有生成 UV1 的情况下，烘焙结果一定是错的。

对于 UE 自带的基础体，通常已经自动生成了 Lightmap UV。真实项目中，美术在制作资产时就要预留好 UV1，并且保证 UV1 的范围在当前贴图分辨率下不至于过密或过疏。检查方式是在 Static Mesh Editor 里查看右上角的视图模式，切换到 Lightmap UV 染色模式，观察展开面是否有重叠、超出 0-1 范围、岛面间距过近等错误。

4.4 设置 Lightmass 参数

打开关卡后，点击顶部工具栏的World Settings按钮，展开Lightmass Settings。

本次实验先保持保守参数：Static Lighting Level Scale 设为 1，Indirect Lighting Quality 设为 2，Num Indirect Lighting Bounces 设为 3，开启 Use Ambient Occlusion。这套参数对应中等大小室内或走廊场景，兼顾速度和质量。如果场景大面积且目标真实感强，可以再单独提高 Indirect Lighting Quality，而不是盲目把 Level Scale 调低。

还需要检查 World Settings 中的Global Illumination设置。确保当前项目的 GI 方法确实是 Baked，反射方式不要依赖 Lumen。完成这些设置后保存关卡。

4.5 执行 Build Lighting Only 并验证

点击主工具栏的 Build 下拉菜单，选择Build Lighting Only。UE5 会弹出进度窗口，显示 Lightmass 正在生成 lightmap 和 volumetric lightmap。等待时观察日志窗口，若看到正在处理哪个层级、哪个 meshes，说明烘焙器已经进入工作状态。

烘焙完成后，切到 Lit 显示模式看结果。正常情况应该是：主光拉出长影，墙面有柔和的反弹光，灯光的暖色在走廊角落形成渐晕，AO 在物体接触处留下“接地阴影”。按住 Alt+鼠标左键旋转视野检查各个角度，特别是 UV1 容易出问题的转折面、小球体底部、物体与地面接触线这些地方。

接着打开查看模式菜单，在 Optimization 分类下选择Lightmap Density，以颜色方式观察 lightmap 密度。绿色表示密度合理，红色代表纹理过密浪费内存，亮黄色代表某个物体密度明显不足。地编工程中，这个视图模式是最常用的检查工具之一。

4.6 用控制台命令快速调试

烘焙结果出来后，可以在编辑器底部的控制台输入命令进行调试。下面这些命令在不同 UE5 小版本间可能略有差异，但通常都能直接使用：

# 临时关闭间接光照，方便对比“只有直接光”的效果 ShowFlag.IndirectLighting 0 # 关闭 lightmap 流送，防止视角变化时动态加载造成跳变 r.LightmapStreaming 0 # 打开或关闭光线追踪相关的辅助调试信息，确认当前路径 r.RayTracing.GlobalIllumination 0

注意控制台命令是临时调试手段，不会永久改变项目配置。如果想要项目启动时默认关闭 lightmap 流送，应在Project Settings > Rendering中查找对应流送选项，或在DefaultEngine.ini中持久化配置。不同版本的枚举值不同，这里不写死数值，建议始终以编辑器界面的实际保存结果为准。

4.7 与 Lumen 方案对比

实战最后一步，我们做一个简单对比。临时回到Project Settings，把 Dynamic Global Illumination Method 切回 Lumen，Reflection Method 也切回 Lumen，重新打开场景。同样的构图、同样的灯光布局，观察两套方案在帧率、画面噪点、内存占用上的差异。

对比后你会直观理解两者的取舍。烘焙适合“场景定稿后追求稳定”，Lumen 适合“玩法还在开发、光源频繁变化”的早期阶段。很多成熟项目的做法是：开发期用 Lumen，接近收尾时切烘焙压性能。

5. 常见问题与排查思路

5.1 常见错误速查表

5.2 黑块、棋盘格和漏光怎么处理

黑块或棋盘格几乎都是 UV1 的问题。先选中静态网格体，在 Details 面板里查看Lightmass Settings，确认Lightmap Resolution没有被设成 0。然后打开 Static Mesh Editor，重新生成 Lightmap UV。对于外部导入模型，最好回到建模软件重新展 UV1，规则是岛与岛之间留出足够的空白边界，避免贴图过滤时互相采样到邻居。

漏光的常见位置在墙角、地面与墙体的交界处。根因通常是烘焙精度不够，或者 AO 采样不足。先提高 Indirect Lighting Quality，再回到场景中把墙角附近灯光的 Lightmap Resolution 提高一档。若依然漏光，可以用体积光或一个低强度的点光来压住暗部，用烘焙以外的局部手段补足。

5.3 角色怎么在烘焙环境里获得环境光

烘焙环境只解决静态几何体的间接光照，角色、怪物、可破坏物件都是动态物体，无法直接从 lightmap 拿到 AO 和反弹光。PC 项目可以用 Distance Field Shadow 让角色在地面上印出柔和阴影，再用一个或多个 Stationary 光源让角色身上有方向感；移动端更常用的做法是给角色模型单独做一张 Bent Normal AO 贴图，再配合反射探针和天空光造出“假环境光”。

这个衔接环节是地编项目中躲不开的问题，建议尽早定方案。不要让动态角色在烘焙场景里看起来像“贴上去的纸片人”，哪怕是简单的半球光照，也比完全没有间接光衔接强很多。

5.4 烘焙数据保存与协作冲突

多人团队协作时，烘焙数据最常见的问题是“我改了光照，同事那边完全没变化”。原因是烘焙结果保存在.umap内，而.umap是二进制资产，合并冲突很难处理。建议团队固定一台烘焙机或固定一名成员负责最终 Build Lighting，其他人不要反复触发烘焙。

如果不同的关卡光照逻辑差异很大，尽量用 Sublevel 拆分：主关卡负责环境烘焙，子关卡只挂动态玩法对象。这样某一层需要重新烘焙时，不会导致整关多人协作冲突。

6. 最佳实践与工程建议

6.1 什么时候必须选烘焙

至少有三类项目应该认真考虑烘焙光照：

• 移动端项目。当前主流移动设备跑 Lumen 很不现实，烘焙光照几乎是高质量间接光的常用解法。
• 固定视角或固定时间场景。比如摄影机路径固定的建筑漫游、展示视频、VR 巡间，烘焙能保证每一帧都是确定性画面。
• 追求帧率稳定性的开放世界。大场景里光照变化通常只发生在日出日落阶段，可以通过切换多套烘焙数据模拟时间变化，而不是全程动态计算。

反过来，如果玩法高度依赖可交互光源，或者场景光照随时可能被玩家改变，那 Lumen 更合适；并且要接受它带来的性能开销。

6.2 Lightmap 分辨率规划

地编最常见的性能问题，不是“光照不够亮”，而是“整个场景烘焙精度一刀切”。规划思路是：

• 主视觉焦点物体：比如玩家常站立的地面、建筑入口、核心交互台，给予最高精度。
• 中景环境物体：墙面、装饰摆件，给中等精度。
• 远景大件：山体、远景楼群，用低精度甚至关闭 lightmap，只保留基础色。

记住一个原则：lightmap 是显存资源，每张贴图都有内存成本和采样成本。与其让全场景都清晰，不如把有限的精度预算花在玩家看得见的地方。每个静态网格体的Lightmap Resolution都不要凭感觉乱填，先在场景中用 Lightmap Density 视图模式扫一遍，把红的区域精准降一档。

6.3 动态与静态混合照明原则

烘焙和动态光照不是二选一，而是可以组合。推荐的分层原则是：

• 太阳主光：优先 Static 或 Stationary，保证大场景有稳定的直接光和间接光基础。
• SkyLight：Static，烘焙时贡献环境的基础亮度。
• 局部补光：Static 点光负责色温和氛围，但不要放太多。
• 交互灯光：Movable，数量严格控制，只用于玩家能明显感知的位置，例如门边的灯、可开关的照明灯。

混合方案的最大好处是，性能开销可控，同时保留玩法需要的动态响应。烘焙负责“环境底色”，动态光负责“剧情高光”。

6.4 团队协作与构建策略

如果项目较大，建议建立一套流程：

• 每天由专用构建机器执行一次完整烘焙，输出统一版本，避免各成员本地烘焙结果不一致。
• 提交代码时，同时提交.umap中已烘焙的 MapBuildData；不要让本地未烘焙的空白关卡覆盖到版本库。
• 光照修改需要走评审流程，先出对比图，再决定是否全量重烘。

这套流程一开始会增加前期成本，但能省下后续大量“为什么我打开和你不一样”的沟通成本。工具开发能力强的团队，还可以写一个自动化构建脚本，在 CI 上定时调用光照构建命令，产出报告后发到协作群。

6.5 安全与排查注意事项

在地编项目中，烘焙工具经常需要长时间占用本机资源。执行全量烘焙前，先确认没有其他成员依赖这台机器的实时预览；烘焙过程如果涉及仓库或构建服务器，建议只在测试分支上操作，避免影响主干。对存放烘焙数据的目录，也应当定期备份，防止异常断电导致数据损坏。

修改大型 Lightmass 参数时，不要一次性把所有精度翻倍，否则可能跑了一小时后才发现内存不足。先缩小烘焙范围或降低关卡复杂度做一次验算，确认时间与内存可接受后，再对完整关卡执行最终烘焙。

7. 总结与下一步

这篇 UE5 地编文章围绕“烘焙光照为什么依然重要”展开。核心结论有三条：第一，Lumen 不是万能方案，稳定性和性能预算依然是地编项目刚需；第二，烘焙光照的流程并不复杂，但必须理解 Lightmap、Lightmass、灯光 Mobility 之间的关系；第三，烘焙与动态光照的最佳实践是混合使用，而不是互相否定。

可以从以下几步继续深入：先在自己的电脑上用基础体搭一个小房间，从最简单的单点光开始烘焙，把 Lightmap UV 和 Lightmap Density 视图用熟；然后尝试把一张外部导入的静态网格体模型接入流程，体会导入资产与白盒资产的差异；最后再引入 Volumetric Lightmap，研究动态角色如何从烘焙环境中获取间接光。这些都是地编光照体系中非常实用的话题。

如果这篇文章对你理解 UE5 光照有帮助，建议收藏备用，尤其遇到黑块、烘焙过慢、灯光改动失效时，可以直接回来对照排查清单。下一步我还会继续拆解 Lightmap 分辨率规划、移动端光照预算等更偏工程化的内容，到时候见。