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 在不同帧率、不同硬件、不同分辨率下可能有细微差异烘焙结果一旦生成所有同事打开看到的是同一张图。对于建筑可视化、影视预览、电商展示这类需要“锁版本”交付的项目烘焙光照依然是更稳的选择。对比项Lumen 动态全局光照烘焙光照运行开销较高GPU 压力明显极低lightmap 采样成本可忽略场景变化支持动态光源、动态物体实时响应静态光源和静态物体的结果固定视觉效果动态但可能有噪声、延迟稳定、干净、可控移动端支持不支持或代价极高成熟方案烘焙等待时间无需要离线烘焙等待时间可观适用场景PC、次世代主机、玩法交互强的场景移动端、开放世界、建筑表现、锁帧率项目烘焙光照在 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 中一个静态网格体通常有两组 UVUV0 是美术制作时的常规纹理坐标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 灯光最重要的分类方式Mobility 类型直接光照间接光照静态阴影运行时成本适用场景Static烘焙烘焙烘焙最低完全固定的环境光、太阳光Stationary动态烘焙烘焙动态阴影中太阳主光、需要角色投影的环境主光Movable动态动态完全动态最高动态点光、交互灯光、开放世界的日夜间需要变化的光烘焙光照之所以高效核心是利用 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 LightMobility 设为 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 设为 1Indirect Lighting Quality 设为 2Num 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 切回 LumenReflection Method 也切回 Lumen重新打开场景。同样的构图、同样的灯光布局观察两套方案在帧率、画面噪点、内存占用上的差异。检查项烘焙方案Lumen 方案帧率稳定几乎不受光照系统影响中低端 GPU 上明显波动阴影轮廓干净、锐利依赖实时追踪低分辨率时偏糊移动视角无闪烁可能有延迟、采样噪声光源改动成本需要重新烘焙实时生效无需等待对比后你会直观理解两者的取舍。烘焙适合“场景定稿后追求稳定”Lumen 适合“玩法还在开发、光源频繁变化”的早期阶段。很多成熟项目的做法是开发期用 Lumen接近收尾时切烘焙压性能。5. 常见问题与排查思路5.1 常见错误速查表问题现象常见原因解决思路烘焙后出现大面积黑色Lightmap UV 缺失或模型没有被识别为静态检查 Generate Lightmap UVs确认物体 Mobility 为 Static贴图边缘出现黑色接缝UV1 展开岛间距过小或纹素精度不足重新调整 UV1提高 Lightmap Resolution烘焙时间太长Static Lighting Level Scale 过低或灯光过多调整精度参数减少动态复杂灯光烘焙中途崩溃内存不足光照数据超出可承受范围缩小场景或拆分 level分批烘焙灯光一改就“全部失效”使用了 Movable 光源参与间接光将主光改为 Static 或 Stationary动态光只做点缀角色在烘焙场景里很“飘”动态物体没有接收间接光照投影开启 Distance Field Shadow或补一个柔和的环境阴影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保证大场景有稳定的直接光和间接光基础。SkyLightStatic烘焙时贡献环境的基础亮度。局部补光Static 点光负责色温和氛围但不要放太多。交互灯光Movable数量严格控制只用于玩家能明显感知的位置例如门边的灯、可开关的照明灯。混合方案的最大好处是性能开销可控同时保留玩法需要的动态响应。烘焙负责“环境底色”动态光负责“剧情高光”。6.4 团队协作与构建策略如果项目较大建议建立一套流程每天由专用构建机器执行一次完整烘焙输出统一版本避免各成员本地烘焙结果不一致。提交代码时同时提交.umap中已烘焙的 MapBuildData不要让本地未烘焙的空白关卡覆盖到版本库。光照修改需要走评审流程先出对比图再决定是否全量重烘。这套流程一开始会增加前期成本但能省下后续大量“为什么我打开和你不一样”的沟通成本。工具开发能力强的团队还可以写一个自动化构建脚本在 CI 上定时调用光照构建命令产出报告后发到协作群。6.5 安全与排查注意事项在地编项目中烘焙工具经常需要长时间占用本机资源。执行全量烘焙前先确认没有其他成员依赖这台机器的实时预览烘焙过程如果涉及仓库或构建服务器建议只在测试分支上操作避免影响主干。对存放烘焙数据的目录也应当定期备份防止异常断电导致数据损坏。修改大型 Lightmass 参数时不要一次性把所有精度翻倍否则可能跑了一小时后才发现内存不足。先缩小烘焙范围或降低关卡复杂度做一次验算确认时间与内存可接受后再对完整关卡执行最终烘焙。7. 总结与下一步这篇 UE5 地编文章围绕“烘焙光照为什么依然重要”展开。核心结论有三条第一Lumen 不是万能方案稳定性和性能预算依然是地编项目刚需第二烘焙光照的流程并不复杂但必须理解 Lightmap、Lightmass、灯光 Mobility 之间的关系第三烘焙与动态光照的最佳实践是混合使用而不是互相否定。可以从以下几步继续深入先在自己的电脑上用基础体搭一个小房间从最简单的单点光开始烘焙把 Lightmap UV 和 Lightmap Density 视图用熟然后尝试把一张外部导入的静态网格体模型接入流程体会导入资产与白盒资产的差异最后再引入 Volumetric Lightmap研究动态角色如何从烘焙环境中获取间接光。这些都是地编光照体系中非常实用的话题。如果这篇文章对你理解 UE5 光照有帮助建议收藏备用尤其遇到黑块、烘焙过慢、灯光改动失效时可以直接回来对照排查清单。下一步我还会继续拆解 Lightmap 分辨率规划、移动端光照预算等更偏工程化的内容到时候见。