Base-UE与Unity6全局光照方案对比

全局光照（Global Illumination，GI）是跨引擎比较时最容易吵起来的话题。UE 用户觉得 Lumen 之后这事已经解决了，Unity 用户觉得 APV 的质量和可调性更好，而两边的讨论经常不在同一个层面上——有人说的是间接光能不能实时响应光源移动，有人说的是动态物体接的间接光准不准，还有人把环境反射采样也算进了 GI。

这篇用一套统一的框架把三个引擎的方案归位：先按「光最终被预计算到哪里」分出四条传输通道，再分别展开 UE4、UE5 与 Unity 6 的具体实现，最后回到对比、症状排查和选型判断。范围是 UE 4.27 及以前、UE 5.x 稳定特性、Unity 6（6000.x）。

一、先对齐术语

GI 的两个组成部分

GI 等于间接漫反射（diffuse indirect）+ 间接镜面反射（specular indirect）。绝大多数「这里为什么这么亮」「反射为什么不对」的问题，根源都是把这两条链路的来源搞混了。后面每个引擎章节都按这两条分开讲。

四条光传输通道

不管哪个引擎，计算间接光的手段最终都落在下面四条通道里。同一个引擎的不同 GI 方案，区别只是用哪几条通道的组合。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

间接光从哪来
├── ① 预计算到表面 —— Lightmap
│     把间接光烘进静态几何的 UV2 贴图。质量最高，但只服务静态物体，光源一动全部作废。
│     UE4/UE5: Lightmass    Unity 6: Progressive / GPU Lightmapper
│
├── ② 预计算到体积 —— 探针体系
│     把间接光烘进空间中的采样点（球谐系数），运行时插值读取。
│     服务对象以动态物体为主，但读取的仍是「烘死的旧光」。
│     UE4/UE5: Volumetric Lightmap (+ILC)    Unity 6: APV / Light Probes / LPPV
│
├── ③ 屏幕空间 —— SSGI / SSR
│     用当前帧的深度、法线、颜色在屏幕内做光线步进。
│     便宜、无需烘焙，但屏幕外的信息永远缺失，物体一转出画面间接光就断。
│     UE4/UE5: SSGI（实验性/回退）    Unity 6: SSR（仅镜面）
│
└── ④ 光追 —— RTGI / Lumen
      真正的光线求交，可覆盖屏幕外，能响应动态光源与动态几何。
      分软件追踪（SDF/体素）与硬件追踪（DXR / RT Core）两条实现路径。
      UE4: RTGI（DXR）    UE5: Lumen（软件 SDF 为主，可选硬件光追）
      Unity 6: HDRP 射线追踪 GI（DXR，可选）

读法是：①② 是烘焙，静态质量高但不响应光源变化；③ 是近似实时，成本低但信息不完整；④ 是真实时，质量和成本都最高。一个引擎可以同时用多条通道，比如 UE5 用 ④ Lumen 做主线、用 ① Lightmap 对关键静态区域补强。

烘焙与实时的边界

IBL 不是 GI

IBL（Image-Based Lighting，基于图像的光照）是采样一张环境 Cubemap，用来近似环境镜面反射和一部分天空漫反射。它不计算光在场景中的传播，也不响应场景内光源的位置与强度变化。

所以 SkyLight、Reflection Capture、Reflection Probe 都属于 IBL，不是 GI 系统。它们能做的是「让金属看起来有环境反射」，做不了「红色窗帘把墙染红」这种间接光耦合。

探针的三种数据来源

三套引擎都有「探针」，但数据来源完全不同，这直接决定了质量上限：

这条区分很关键：APV 之所以比 UE4 的 VLM+ILC 质量好，一半靠视差校正，另一半靠它直接从光烘出来、少一层插值。

二、UE 的方案全景

UE4 和 UE5 的 GI 体系是继承 + 换主干的关系：烘焙那套（Lightmap、VLM、Reflection Capture、SSGI）几乎原样保留，UE5 在其上加了 Lumen 作为默认实时 GI 主干。

架构总览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

【UE4 路线】烘焙主干 + 实验性/硬件光追补丁
场景间接光
├── 漫反射
│   ├── 静态物体 → Lightmap（Lightmass 烘焙，UV2）          [通道 ①]
│   ├── 动态物体 → Volumetric Lightmap + ILC               [通道 ②]
│   └── 实时选项 → SSGI / LPV / DFGI（实验）/ RTGI（DXR）    [通道 ③④]
└── 镜面反射
    ├── 烘焙 → Reflection Capture / SkyLight（IBL）         [非 GI]
    └── 实时 → Planar Reflection / RTGI 的镜面部分

【UE5 路线】Lumen 主干 + 烘焙路线可选保留
场景间接光
├── 漫反射
│   ├── 默认 → Lumen（屏幕空间 + Surface Cache/SDF + 可选硬件光追）  [通道 ③+④]
│   ├── 可选 → Lightmap（Lightmass / GPU Lightmass）        [通道 ①]
│   └── 回退 → SSGI                                        [通道 ③]
└── 镜面反射
    ├── 默认 → Lumen Reflections（可回退 SSR / Reflection Capture）
    └── 可选 → Reflection Capture + SkyLight（IBL）

Lightmap：静态物体的间接光

Lightmass 把直接光与多次弹射的间接光烘焙到静态几何的 UV2 通道，服务对象是 Static / Stationary 光照模式下的静态部分。限制很明确：UV2 必须合理布局，接缝与拉伸会直接表现为脏迹，光源一移动就得重烘。

UE4 到 UE5 的变化有三点：引入了基于 DXR 的 GPU Lightmass，烘焙速度大幅提升且支持更多次间接弹射；支持 Virtual Texture 的 Lightmap，超大场景可以按需流送以缓解显存压力；定位从「唯一主干」降级为「可选路线」，与 Lumen 二选一。

Volumetric Lightmap 与 ILC：动态物体的间接光

• VLM（Volumetric Lightmap）：Lightmass 烘焙出的体素化间接光探针，采用「格子（Cell）+ 砖块（Brick）」的层级结构——光照变化剧烈处拆细、平坦区域合并，存储球谐（Spherical Harmonics，SH）系数。
• ILC（Indirect Lighting Cache）：可移动物体不直接做逐像素体积采样，而是通过 ILC 在物体采样点上做空间插值，质量分三档：Volume Lightmap（多个采样点，物体移动时更新）、Volume（每个物体一个插值点，最省也最差）、None（不接间接光）。
• 一个常见误解：ILC 不是时间累积缓冲，本身不产生拖影。它的问题是「采样点密度低 + 更新不是每帧全量」，导致快速移动物体的间接光跳变或滞后。真正的时序拖影在 Lumen 那一侧。
• 没有视差校正：动态物体贴墙时无法把采样点约束回有效体积内，因此漏光、发暗是这个方案的固有问题。
• 在 UE5 中的状态：VLM + ILC 仍然完整存在，但一旦启用 Lumen，动态物体的间接光就由 Lumen 接管，VLM 基本退居为「不启用 Lumen 时的旧路径」。

UE4 的三条实验性捷径

三者在 UE5 中的实际定位：DFAO 仍有价值（便宜的大尺度 AO），LPV 与 DFGI 已被 Lumen 取代，不建议在新项目中考虑。

SSGI：屏幕空间 GI

基于深度与法线在屏幕空间做光线步进，近似间接漫反射。局限也明确：只覆盖画面内可见的像素，屏幕外信息缺失，镜头一转间接光就跳；噪点需要降噪处理。

UE4 中它是实验功能。UE5 中的定位变了：不再是「实时 GI 的备选」，而是关闭 Lumen 时的低成本回退（r.Lumen.DiffuseIndirect.Allow=0 之后由 SSGI 兜底）。

Reflection Capture、SkyLight 与 Planar Reflection

• Reflection Capture：手动放置的 Cubemap 捕获点，负责局部镜面反射，摆放位置不对就会反射错位。
• SkyLight：天空环境 Cubemap，同时提供天空的漫反射（作为 GI 的一个来源）与镜面贡献。
• Planar Reflection：平面镜面反射（水面、地面），质量高但成本随平面数量线性增长。

三者中只有 SkyLight 的漫反射部分参与 GI，其余都是 IBL 近似。

硬件光追 RTGI

利用 DXR 对光线做硬件求交，可以得到真正实时的漫反射与镜面间接光。要求是 RTX 系或兼容 DXR 的显卡，并且要开启 Ray Tracing 项目设置，移动端与低端机不可用。

在 UE4 中它是可选增强，需要自己搭 Denoiser、降噪与采样策略，工程成本不低。在 UE5 中它不再单独暴露为「RTGI」，而是作为 Lumen 的硬件追踪后端（Lumen HWRT）。这条演进很重要：UE5 把硬件光追从一个独立方案变成了 Lumen 的一个质量档。

Lumen：引擎级实时 GI

Lumen 是 UE5 的默认 GI 方案，也是目前三大引擎中唯一开箱即用的完整实时 GI。它的追踪分三层，按可用性逐级回退：

几个关键事实：

• 漫反射与镜面都由 Lumen 接管。开启 Lumen 后，Reflection Capture 与 SSR 退化为回退方案。
• 能响应动态光源与动态几何，这是它与烘焙方案的本质差别。
• 不强制要求 RTX 显卡，默认走软件 SDF 追踪，硬件光追是可选项。
• 强依赖时序累积：输出经过时序降噪，因此高度依赖 TSR/TAA。关闭时序抗锯齿会看到明显噪点与闪烁。
• 不需要 UV2，这是相对 Lightmap 工作流的一大解放，美术不必再为间接光维护第二套 UV。

能力限制也要提前知道：

MegaLights 不是 GI

UE5.5+ 的 MegaLights 支持大量动态光源（成百上千个点光/聚光）与软阴影，解决的是传统延迟管线光源数量上限的问题。它只负责直接光与阴影，间接光仍由 Lumen 承担，两者是互补关系，不是替代关系。截至 5.x 仍属实验与逐步成熟阶段，接入前需要评估。

UE 的路线选择：Lightmap 还是 Lumen

这是 UE 项目最关键的 GI 决策，两者不能叠加——同一区域的间接光只会由一条主线负责。

实践中常见的折中是：主线用 Lumen，局部关键区域用 Lightmap 或补光做质量补强；或者主线用 Lightmap，动态物体走 VLM+ILC（等同 UE4 路线）。

UE4 与 UE5 的能力边界

三、Unity 6 的方案全景

架构总览

1
2
3
4
5
6
7
8
9
10
11

场景间接光
├── 漫反射
│   ├── 静态物体 → Lightmap（Progressive / GPU Lightmapper）    [通道 ①]
│   ├── 动态物体 → APV（Adaptive Probe Volumes，主推）          [通道 ②]
│   │              ├── 取代传统 Light Probes（旧）
│   │              └── 取代 LPPV（过渡方案，旧）
│   └── 可选实时 → HDRP 射线追踪 GI（DXR，非默认路径）           [通道 ④]
└── 镜面反射
    ├── 烘焙 → Reflection Probes（Cubemap，IBL）                [非 GI]
    ├── 实时 → SSR（HDRP；URP 需通过 Renderer Feature）
    └── 可选实时 → HDRP 射线追踪反射

Enlighten 的现状

Enlighten 的实时 GI 已经在 Unity 6 中移除。它是「预计算 + 运行时快速重建」的方案，能响应光源旋转，但预计算时间长、内存占用大、移动端受限。Enlighten 的烘焙部分同样在逐步退出，官方推荐 Progressive Lightmapper 与 GPU Lightmapper。

后果是：Unity 6 的默认 GI 全链路都是烘焙的，运行时只做读取与插值。这是它与 UE5 最大的路线差异。

Lightmap 烘焙

数据源有两个：Progressive Lightmapper（CPU，可增量、可边改边烘）和 GPU Lightmapper（快，需要支持的显卡）。服务对象是 Baked / Mixed 光照模式下的静态物体，限制同样是 UV2 必须展开、光源变化需重烘、不支持动态物体承接。

需要留意的是 Mixed 模式：方向光的直接光与阴影可以走实时 Shadowmap，但间接光永远是烘焙的。

传统 Light Probes 与 LPPV（均已过时）

Light Probes 是手动放置在场景中的球谐探针组，为动态物体提供间接光。硬伤是密度固定、需手工摆放、没有视差校正，因此贴墙时漏光或发暗。Unity 6 中官方推荐用 APV 取代，但 Light Probes 仍作为 APV 体积之外区域的兜底存在。

LPPV（Light Probe Proxy Volume）是过渡方案：在局部区域放置代理体积，用虚拟探针插值已有 Light Probes 数据，提供局部更高密度的间接光。它本身不参与烘焙，只是对现有数据的二次插值，精度受制于源探针，且同样没有视差校正，已被 APV 取代。

APV：Unity 6 的 GI 主干

APV（Adaptive Probe Volumes，自适应探针体积）是 Unity 6 中动态物体间接光的标准方案，也是这套体系里工程质量最高的一环。

APV 的边界要说清楚：它是烘焙方案，不是实时 GI。Scenario Blending 解决的是「在几套预设之间过渡」，不是「光源可以随便动」。真正的自由昼夜循环仍然需要 HDRP 射线追踪或外部方案。

反射探针与 SSR

Reflection Probes 是烘焙的 Cubemap（IBL），负责局部镜面反射，需要合理摆放与混合。SSR 在 HDRP 中内置，URP 通过 Renderer Feature 提供，可用性随版本变化，需按目标版本确认。SSR 只覆盖画面内可见像素，且只解决镜面反射，不是 GI。

HDRP 射线追踪 GI

这里要纠正一个常见误解：Unity 6 并非完全没有实时 GI 能力，只是它不在默认路径上。

准确的表述是：Unity 6 的默认 GI 路线是烘焙，实时 GI 只在 HDRP + DXR 硬件这条窄路径上可用，成熟度与易用性明显低于 UE5 Lumen。

Unity 6 的能力边界

四、三方核心对比

总表

动态物体间接光：三套实现的机理差异

• UE4（VLM + ILC）：体积体素（烘焙）→ 物体采样点插值。精度受体素密度与 ILC 质量档限制，无视差校正，贴墙发暗。
• UE5（Lumen）：实时追踪（屏幕空间 + Surface Cache/SDF + 可选 HWRT）。响应即时，但带时序噪点，薄几何精度差。
• Unity 6（APV）：体积探针（烘焙，直接从光烘出）→ 带视差校正的采样。读取层面响应即时，但光源一动就失效，贴墙质量最好。

一句话概括：UE4 的问题是「旧光 + 没校正」，UE5 的问题是「实时但有时序代价」，Unity 6 的问题是「质量好但光不能动」。

贴墙与半封闭空间的质量

这是 TA 最常撞上的一类问题，三个引擎叫法不同，根因是同一件事：采样点落在墙外或落在无效体积里，间接光取到了错误的值。

同一个问题在三个引擎里有三套名字和三个数量级的排查难度。Unity 6 的 APV 调试视图是目前最好用的定位工具，UE4 基本靠经验，而 UE5 的问题性质已经变了——从「数据错」变成了「收敛不够」。

调试与可观测性

性能与成本档位

一个实用判断：12 GB 级显存能不能开硬件光追，通常取决于加速结构 + Surface Cache / 反射分辨率的总和，而不是单一开关。 先用软件路径跑通质量基线，再逐项开硬件追踪，比一上来全开更容易定位瓶颈。

工作流与迭代速度

• Unity 6：APV 自动化程度高（拖 Volume、自动自适应密度），配合调试视图形成「烘焙 → 看问题 → 修」的闭环，迭代体验最好。
• UE4：VLM 偏黑盒，排查靠经验，Reflection Capture 需手动摆放，整体迭代慢。
• UE5：Lumen 改光即时可见，迭代最快；代价是要处理噪点、时序与性能调优，属于「另一种工作量」。

五、能力边界与选型

什么时候「必须」用真·实时 GI

实时性评分

决策路径

1. 目标平台含移动端？ 是的话只能走烘焙（Unity 6 Lightmap+APV 或 UE 的 Lightmap+VLM），到此为止。
2. 光照会动态变化（昼夜、可破坏、光源移动）？
   • 否 → 烘焙。优先 Unity 6 APV（质量与可调性最好）或 UE 的 Lightmap+VLM。
   • 是 → 进入第 3 步。
3. 能接受引擎绑定到 UE5？
   • 能 → UE5 Lumen，目前唯一开箱即用的完整实时 GI。
   • 不能且必须在 Unity → HDRP 射线追踪 GI（需 DXR 硬件，工程量与风险都更高）。
   • 不能且必须在 UE4 → 自建 RTGI 管线，或升级到 UE5。
4. 只是偶尔需要动态光照而非全程？ 考虑 Unity 的 Scenario Blending 或 UE 的混合策略，用烘焙换性能。

按项目类型选

六、症状速查

七、术语表

总结

把三个引擎的 GI 放在一起看，真正的分歧只有一句话：间接光的来源是预先烘好的，还是每帧算出来的。

UE4 与 Unity 6 走的是同一条路线——静态靠 Lightmap，动态靠探针读取烘焙数据，差别在于探针的质量与可调试性：UE4 的 VLM+ILC 无视差校正且偏黑盒，Unity 6 的 APV 从光直接烘出、带视差校正，还配了专用调试视图。UE5 则把主干换成了 Lumen，代价是强依赖时序降噪、薄几何质量差、移动端不可用。

选型时可以按这个顺序问自己：目标平台有没有移动端、光照会不会动、能不能接受绑定到 UE5。三个问题答完，方案基本就定死了，剩下的都是在这个方案内部的调优问题，而不是方案之争。

最后一点提醒：三个引擎的小版本迭代都很快，Lumen 的限制清单、APV 的 Scenario Blending / Streaming 可用范围、HDRP 射线追踪的平台支持都可能变化，落地前以官方文档复核。性能结论尤其要在目标硬件上实测帧时间，不要直接套用任何人的经验值。

参考资料

• Lumen 技术文档
• Lightmass 全局光照
• Volumetric Lightmaps
• Mesh Distance Fields
• Temporal Super Resolution
• Nanite 虚拟几何
• Unity APV 使用文档
• Unity APV 可视化与调整
• Unity APV Streaming
• Unity Lightmapping