从 PRT
到 Lumen

后面的内容会越来越抽象。进入公式之前，先准备六个比喻。现在不用全懂，读到对应的地方时，它们能帮你把机制挂在一个熟悉的画面上。

音响的均衡器，对应球谐函数。几个频段的旋钮就能大致还原一段音乐，光照在球面上的分布也能这样拆成几个"频段"。漫反射本来就没有"高音"，所以只需要低频的几个旋钮。后面"9 个系数就够"的结论，就是从这里来的。

民意调查，对应噪点。问一百个人会有误差，想让误差减半，得问四百个人。用随机光线估计亮度也服从同一条规律。实时渲染的光线永远不够多，所以噪点是这类方法的本性，不是 bug。

冰箱门上的便签，对应 Surface Cache。常做的菜抄在便签上贴在冰箱门，就不用每次翻菜谱。Lumen 把算过的表面光照记在"便签"上，光线撞到表面时直接读，不在现场重算。这是整篇最核心的一招。

夜里走路的测距仪，对应距离场。手里的仪器告诉你最近的墙在三米外，你就敢闭着眼走三米。到了新位置再测一次。离墙越近，步子自然越小，所以永远撞不上。

长曝光摄影，对应时间累积。快门开久一点，画面里的噪点就没了，但走动的人会变成一道虚影。Lumen 的间接光滞后、Lumen Lite 的黑块拖尾，付的都是这笔代价。

隔着墙问信息亭，对应探针遮挡。信息亭就在十米外，但中间隔着一堵墙，它给的答案就不适用于你这一侧。判断"中间有没有墙"，是所有探针方案里最要命的一步。

这张表是查阅用的，不必一次记住。遇到不认识的词，可以从目录跳回这里。

其中最重要的是一组区分：辐射亮度和辐照度。前者带方向，后者不带。后面会看到，漫反射只需要后者，正是这个结论让探针方案成为可能。

全局光照 GI

光弹过几次之后照亮的那部分画面

直接光 / 间接光

光源直接照到的 / 从别的表面弹过来的

辐射亮度 L

朝某个方向看过去有多亮，带方向

辐照度 E

这一点总共收到多少光，不分方向

反照率 ρ

表面把多少光弹回去。白墙高，沥青低

探针 Probe

空间里的一个采光点，附近的像素都来查它

辐射度缓存

存放已经算过的光，避免重算

距离场 SDF

每一点都记着离最近的表面还有多远

体素 Voxel

把空间切成小方块，像三维的像素

Clipmap

跟着相机走的多层网格，近处细、远处粗

球谐 SH

用几个数概括球面上的分布，像均衡器

八面体映射

把一个球面摊平成正方形纹理的办法

重要性采样

把有限的光线用在更可能有贡献的方向

时间累积

把前几帧的结果混进来，等于多了样本

历史失效

画面里新露出来的地方，没有历史可借

这里给的是便于理解的说法，严格定义在后面各自的小节里。

全篇十一章加四个附录，共 115 节，按顺序分成 8 个页签，就是页面顶部那一排。每个页签是一次可以坐下来读完的量，读完一个再进下一个。

每个页签开头有一张卡片，列出它包含的章节和预计时间；读到页签末尾，按钮会带你进入下一个页签。页签会记住你在里面读到哪里，切回来时接着读。也可以按数字键 1–8 直接切换，或者把地址栏里带 #t3 这样后缀的链接发给别人，对方会直接打开那个页签。

右上角的演示按钮会把同一份内容切换成一页一屏的幻灯片，用 ← → 翻页，按 N 显示讲稿，适合讲给别人听。阅读时按 T 打开目录，目录可以跨页签跳转。

每一节末尾标了出处。证据分三档：官方文档与版本说明，可以直接引用；2022 年 SIGGRAPH 演讲里的数字，结构可靠，但具体数值可能已经变了；社区报告和本文的推断，对外讲之前请自己验证。附录的最后一节列了完整的参考资料。

先把问题摆清楚。离线渲染器算一帧可以花几分钟，游戏只有十几毫秒。在这十几毫秒里，全局光照有三件事很难做到。

第一，光线数量巨大。每个像素都想知道半球上各个方向射来多少光，而每个方向都要派一条光线去看。

第二，光线打中之后还要算光。光线撞到一个表面，得先求出那里的材质，再求那一点自己收到了多少光，而后者本身又是一个全局光照问题。很多人以为光线追踪贵在"追"，其实相当一部分成本花在命中之后。

第三，结果不能提前烘焙。把光照预先算好存进贴图，在静态场景里效果极好；但光源一动、门一开、物体一挪，贴图就作废了。

Lumen 对这三件事的总体回答是：把算过的光照缓存起来，反复复用。

这句话现在还很抽象。这一章剩下的三节先把数学基础打好：间接光为什么是一个积分、为什么一算就有噪点；积分里出现的两个量到底是什么；以及这个积分为什么会"自己引用自己"。

按思路分，GI 的技术谱系大致是五条路线，每条里按时间排。年份是公开发表的大致时间；分路线是为了讲解方便，实际的发展互有交叉，比如屏幕空间的 SSAO 其实比体素路线还早。

1. 预计算光照贴图 → PRT（2002）→ 静态光照探针

   离线把积分算好存起来。画质上限最高，但几何不能动。

2. 体素LPV（约 2010）→ 体素锥追踪（2011）

   把场景装进三维网格。第一次做到全动态，但分辨率低、容易漏光。在 Lumen 里：距离场与 Voxel Lighting

3. 屏幕空间SSAO（2007）→ SSGI、SSR

   只用屏幕上现成的深度和颜色。几乎免费，但屏幕外的东西不存在。在 Lumen 里：追踪的第一级

4. 探针DDGI（2019）→ RTXGI

   在世界空间铺一张辐照度探针网格，每个探针还存遮挡信息来防漏光。在 Lumen 里：Lumen Lite 走的就是这条路

5. 光线追踪硬件光追（2018 起）→ ReSTIR（2020 起）

   求交终于能实时，噪声靠跨时空复用样本来压。在 Lumen 里：可选的求交后端，以及时空复用的思想

Lumen 同时用上了后四条，唯一放弃的是预计算，因为它的目标就是全动态。接下来按顺序看每一条：它解决了什么，又留下了什么。这一章讲预计算，其余四条在下一章。

第 1 章说过，漫反射只需要"这一点总共收到多少光"这一个数。但如果想提前存好一个位置的光照，让任意朝向的表面放到这里都能查到，就得存下"每个方向射来多少光"，也就是一张包住这一点的球形光照图。直接存一张小 HDRI 太大了。球谐函数（Spherical Harmonics，简称 SH）是用来压缩它的工具。

理解球谐最好的类比是音响的均衡器。一段音乐可以拆成低音、中音、高音几个频段，每个频段一个推子；只保留低音和中音，曲子的大致样子还在，只是细节没了。球谐对"球面上的光照"做的是同一件事：

第 0 段只有 1 个推子，是整体有多亮，相当于环境光。第 1 段有 3 个推子，描述"哪一边更亮"：上亮下暗、左亮右暗、前亮后暗。第 2 段有 5 个推子，描述更细一点的明暗变化，比如"上下都亮、腰上一圈暗"。三段一共 1 + 3 + 5 = 9 个数。

这套"比一比再叠回去"的做法能成立，靠的是这些标准图案互不干扰（数学上叫正交）：任意两种不同的图案"比一比"，结果都是零。就像均衡器的推子各管各的频段，推一个不会影响另一个。

为什么只要 9 个就够？关键在于漫反射本来就"没有高音"。辐照度是把半球里的光按"越正越重"平均起来，而平均本身就是一种模糊。高频的细节，比如一盏小灯的锐利轮廓，平均之后几乎全被抹掉了：

下面在一个圆上把这件事演一遍。圆是球的二维版本，圆上的傅里叶展开和球谐是同一个原理，只是每一段的系数个数不同。拖动段数，同时看左右两边：

9 个数够用，不是凑合，而是漫反射本身就像一个模糊滤镜，把高频全滤掉了。

Ramamoorthi 和 Hanrahan 在 2001 年给出的结论是：用这 9 个数，任意光照下辐照度的平均误差在 3% 以内。运行时还能把它整理成一个 4×4 的小矩阵，查一次光照只要一次矩阵乘法，非常便宜。

它的边界也要说清楚：镜面高光是"高音"，9 个推子根本表达不了。所以球谐只服务漫反射，反射必须另走一条路。这条边界后面会反复出现。

在 UE 里你见过它Sky Light 给物体的漫反射照明，引擎内部会先把天空压成一组球谐系数；Lightmass 烘出来的 Volumetric Lightmap，给动态物体提供间接光，存的也是球谐系数。

有了球谐，就可以讲 PRT 了。它是 Sloan 等人 2002 年提出的，全称 Precomputed Radiance Transfer，预计算辐射传输。

普通的光照贴图烘的是"这一点有多亮"，灯一动就作废。PRT 烘的是"这一点对各个方向的光有多敏感"。打个比方：光照贴图像一张拍好的照片；PRT 则记下了"这个位置头顶被遮住了多少、旁边的墙会挡掉多少、墙又会把多少光反过来"，然后无论天空怎么变，都能立刻算出这里该多亮。

具体做法是两组 9 个数，一一对应相乘再相加：

运行时的工作量，从"把半球重新积分一遍"降到了"九次乘加"。软阴影和墙面反光都是免费的，因为它们已经包在 t 里了。

下面这张图在一个二维的场景里真的跑了一遍 PRT：地板上一点，右边一堵墙。墙挡掉了哪些方向，离线时已经算进了 t；运行时转动灯，只用几次乘加算亮度，再和逐方向积分出来的真实值对比。

这笔交易买到的是光照可以实时换：转天光、改天气、昼夜循环，都不用重烘。没买到的是几何仍然不能动，因为 t 是对着固定的几何算出来的。而且它通常只支持低频的光照；想要光滑的材质，t 就得从 9 个数升级成一张 9×9 的表，存储量跟着暴涨。

它留给今天的遗产是球谐这个工具。2002 年的数学在今天的引擎里还活着：Lumen 的屏幕探针，照样是把六十多条光线压成 9 个球谐系数。

上一节的 l · t 是怎么来的？推一遍只要五步。每一步都配了白话，不看符号也能跟下来。

第一步，写出要算的东西。一个不动的物体泡在天光里，它某一点有多亮：

第二步，把天空压成 9 个数。用 2.4 节的球谐，天空 ≈ 9 种标准图案按推子高度叠起来：

第三步，代进去，调换先后顺序。"先叠加再积分"和"先积分再叠加"结果一样；推子高度 l_i 是常数，可以挪到积分外面：

第四步是整个推导的关键。看剩下的那个积分：里面已经没有天光了，只剩"能不能看见天空"、标准图案和斜射打折，全是几何的东西。房间不动，它就永远不变，可以离线算好存起来：

第五步，代回去。

九次乘加，结束。

这招能成立，是因为光照和几何被干净地拆开了：l 只管天空，t 只管几何。

房间不动就缓存 t，换天光只换 l。如果材质是光滑的，反射出去的光也有方向，9 个敏感度就得升级成一张 9×9 的表，存储量暴涨，下一节来算这笔账。

PRT 的死穴也写在第四步里：t 里面有 V，"能不能看见天空"。几何一动，V 就变，t 立刻全部作废。这不是性能不够，而是结构上的限制，也是 PRT 进不了动态场景的根本原因。

最后一条路线是光线追踪本身。先说标尺：离线路径追踪是"正确答案"的定义者，每个像素打成千上万条光线，一帧要几秒到几分钟。它是用来对照的标尺，不是实时方案。

2018 年起，GPU 有了光追专用单元，很多人以为问题解决了。但一条光线的成本分两半：求交，和命中点算光。硬件只解决了前一半，把 BVH 遍历和三角形求交下沉到了硬件。后一半要求出命中点的材质，还要知道那一点自己收到了多少光，往往比求交更贵，硬件完全帮不上忙。

Lumen 的答案就落在这里：求交交给硬件光追或者距离场，两个后端都行；命中点算光的那一半，换成读 Surface Cache，把算光变成查表。

硬件让求交变便宜了，没让算光变便宜。Lumen 省的是后一半。

另一个值得一提的是 2020 年起的 ReSTIR。它解决的是噪声：用蓄水池重采样，在空间和时间上复用邻居与历史的样本，把有效样本数撑起来。它最初用于直接光，之后扩展到了间接光。"复用样本"这个思想也贯穿了 Lumen：探针滤波借邻居，时间累积借历史，用的是同一招。

三层缓存回答的是"存在哪"，接下来是"按什么顺序算"。Epic 的性能指南把 Lumen 拆成三个 Pass 来做性能分析，这正好也是理解实现的主线。

Pass 1，Scene Lighting：给 Surface Cache 计算直接光和间接光。它先让缓存里"有光"，之后所有光线命中时读到的，都是它的结果。

Pass 2，Screen Probe Gather：用缓存算出漫反射 GI。粗糙表面的反射和半透明物体的 GI，也在这里顺带算掉。

Pass 3，Reflections：只为光滑表面发射专用的反射光线。

间接漫反射 + 间接高光 + 反射 = 间接光再叠加直接光，得到最终画面

三个 Pass 的成本结构完全不同，这一点调性能时很有用。Scene Lighting 的成本跟着缓存的大小和更新比例走，和屏幕分辨率无关；Screen Probe Gather 跟着屏幕上的探针数走，也就是分辨率和探针间距；Reflections 跟着画面里有多少光滑表面走，一地积水和一地泥土的反射成本可以差好几倍。4.4 节会把中间那一项算出具体的数字。

这个顺序本身就说明了依赖关系：先有缓存里的光，才有探针收集；先有漫反射的探针，粗糙反射才能直接复用它们。第 5、7、8 章分别对应这三个 Pass，中间的第 6 章讲它们共用的追踪。

前三节讲的是结构。这一节换个角度：拿默认设置算一笔账，看 Lumen 每帧到底打得起多少条光线，又是怎么把这点光线摊到两百万个像素上的。

账本只有三行。第一行是像素数：1080p 是 1920×1080，约 207 万。第二行是探针数：默认每 16×16 像素放一个屏幕探针，横向 120 个、纵向 68 个，约 8160 个。第三行是光线数：每个探针朝 8×8 = 64 个方向各打一条，合计约 52 万条。

对照一下第 1 章的结论：要得到一张干净的离线参考图，每个像素往往需要几百条光线。四分之一条和几百条，差了三个数量级。下面这张图把这笔账做成了可以拨的算盘。

差出来的三个数量级，是被三件事一层层补回来的，它们正好是第 7 章的主线：

插值借光。一个像素不只读自己头顶那一个探针，而是在周围 4 个探针之间插值。它实际用到的是 4×64 = 256 条光线的结果。

重要性采样。这 64 条光线不是平均撒的，而是按材质和上一帧的亮度，往更可能有光的方向集中。同样的数量，噪声更小。

时间累积。每帧光线的方向会抖动，结果和过去几帧叠在一起。画面不动时，有效样本数还要再乘上累积的帧数。

Lumen 的预算不是按像素算的，而是按探针算的。这就是为什么它的成本主要跟着内部分辨率和探针间距走，而跟场景里有多少盏灯、多少个物体关系不大。

还有一个容易忽略的细节：账本里没算 Surface Cache 的打光和世界缓存的更新，它们有各自的预算：前者下一章会算，后者在第 7 章有单独的更新预算。第 9 章讲的那几个旋钮，调的就是这本账上的数字。

卡片从哪来？它们在网格导入时离线生成，不是运行时临时算的。卡片决定了运行时"从哪几个方向去拍这个网格"，可以理解成一组事先摆好的捕获机位。

生成分三步。先把网格体素化成面元（surfel），每个面元记下自己的位置和朝向。再把面元聚类成卡片：用类似 K-means 的区域生长，再做一次全局优化，得到一组轴对齐的投影面。最后是兜底：聚类失败的网格，退回最简单的六面卡片。

默认每个网格生成 12 张卡片，可以在静态网格设置里用 Max Lumen Mesh Cards 调整。很小的聚类还会被合并成六面的组卡片，用在远处的建筑和碎石上。

采样时，Lumen 在 6 个朝向里按表面法线选出 3 张卡片，按深度差和法线夹角加权混合；每张卡片内部再取 4 个深度做双线性滤波。这样，即使卡片和表面并不完全贴合，读出来的值也是平滑的。

下一节把这个聚类过程画出来。

动手实现时命中点怎样挑卡片、做深度校验，以及凹面覆盖不到时怎么回退，见 。

卡片生成之后，还要把材质"拍"进去。可以把卡片想象成贴在网格外面的几块平板相机：每张卡片从一个轴向看着网格，把基础色、法线、自发光等属性画进 Surface Cache 的大图集里。

完整的流程分四个阶段：

1. 离线生成卡片。每个静态网格默认 12 张，朝向对齐坐标轴。
2. 加入场景时放置卡片。
3. 运行时用 Nanite 的多视图光栅化，把材质画进图集。所有操作都有节流，避免卡顿。
4. 每一帧对这些表面位置计算直接光和间接光，分摊到多帧完成。

不同类型的网格，待遇不一样。骨骼网格会变形，所以没有离线卡片，只在加入场景时在蒙皮前的包围盒四周放 6 张，覆盖有限。样条网格按每个实例重新拟合卡片，变形越大，质量越差。植被和实例化网格只有使用 Nanite 时才被支持。

没被卡片覆盖的部分，在 Surface Cache 视图里是粉色的，它们不反弹光，在反射里是黑的。这三类特殊网格，正是粉色最常出现的地方。

所有卡片都住在同一张图集里，而图集的大小是固定的：4096×4096，由 128×128 的物理页组成。场景里的卡片远远不止这么多，所以 Surface Cache 的分辨率不是固定的，而是按需分配：光线实际命中了哪些卡片、需要多清晰，就把对应的页和 mip 映射进图集。

这套机制和虚拟纹理非常像，是一个闭环：

1. 光线命中某张卡片。
2. 着色器写一条反馈：随机选一页，记下它需要的 mip 级别。
3. GPU 把所有请求汇总进一张哈希表。
4. CPU 读回请求，映射新页，释放不再需要的旧页。
5. Nanite 渲染这些卡片，填充新映射的物理页。

没映射到的页会回退到一组常驻的低分辨率页，所以一次采样总能取到值，不会读到空数据。

捕获本身也有预算：每帧 512×512 个纹素。Nanite 一次可见性缓冲绘制就能把所有待更新的卡片画完，比逐张绘制快约 10 倍。捕获输出包括反照率、不透明度、深度、法线和自发光。

再往里看一层：这张 4096×4096 的图集在显存里是怎么排的。

页有三种用法。大卡片独占一整页，就是图中的青绿色块。比一页小的卡片在页内再做子分配，就是被切成四块的那些页。还有一些页根本没有映射，画成虚线框。页边留半个纹素的边界，这样双线性采样不会串到邻居卡片上。

表里列出了每一层存什么、用什么格式、占多少内存。反照率、深度、法线、自发光，加起来不到 90 MB。深度用的是未压缩的 R16，所以最贵。

这是一笔固定开销，不随场景复杂度增长。

这正是第 2 章拿来和 PRT 对比的那一点：PRT 的存储跟着场景顶点数涨，Surface Cache 的预算是固定的，质量按需分配。

表里的不透明度层在 UE 5.8 中已经移除。第 10 章引用的数字是省下约 16 MB，这里列的 8 MB 是 2022 年演讲的口径，两者统计范围不同，以版本说明为准。

卡片里有了材质，还没有光。给它们打光是 Pass 1 的工作，叫 Scene Lighting。之后所有光线追踪命中时拿到的光照，都来自这里。

它在卡片的每个表面位置上计算两样东西：直接光，也就是灯光加阴影；以及间接光，也就是从别的卡片弹过来的光。算完写回卡片，之后不管是漫反射 GI 的光线还是反射的光线，命中这里时都直接读。

直接光这一步和普通的延迟光照很像：对每个纹素，把影响它的灯逐个加起来，再乘上阴影。不同之处在于，很多卡片表面根本不在屏幕上，没法用屏幕上的阴影信息。这时就沿着距离场向灯光追一条阴影光线，看中间有没有东西挡着。

它的开销取决于每帧更新缓存的比例。Lumen 不会每帧把整张图集都重新打一遍光，而是每帧只更新一部分，其余沿用旧值。

还有一个重要的细节：间接光读的是上一帧的结果。这个细节决定了多次反弹是怎么来的，后面两节会把它展开。

展开来看，打光分四步。

第一步，选页。每帧只更新一部分页。优先级是"最后被使用的时间减去最后更新的时间"：越是最近被光线命中、又很久没更新的页，越先轮到。2022 年演讲给出的每帧预算是直接光 1024×1024 个纹素、间接光 512×512 个纹素。当前版本改用"占整张图集的几分之一"来表示：直接光默认 1/32（约 52 万纹素，相当于 724²），间接光默认 1/64（约 26 万，正好是 512²）。直接光的默认预算比演讲时减半了，5.10 节按当前默认值算账。

第二步，直接光。以 8×8 纹素为一块 tile，每块最多处理 8 盏灯。阴影先从阴影图里取，为每盏灯生成一张 1 位的阴影遮罩；阴影图覆盖不到的地方，比如屏幕外，再用射线补。

第三步，间接光。用的是类似辐射度（radiosity）的方法：每 4×4 个纹素放一个半球探针，探针方向每帧抖动，最多累积 4 帧，插值时按平面和深度加权。

第四步，写回图集。光照存回卡片对应的位置，追踪命中这张卡片时直接读取。

间接光的输入，是本帧的直接光加上缓存里上一帧的间接光。

每多更新一轮，就多一次反弹，不必在一帧里递归。下一节把这条回路画出来。

前两节说缓存"每帧只更新一部分"。这一节把"一部分"换成具体的数字，再看它在画面上意味着什么：开一盏灯之后，房间要多久才亮透？

先算直接光。图集是 4096×4096，约 1678 万个纹素。默认每帧给其中 1/32 重新算直接光，也就是约 52 万个纹素。换句话说，整张图集轮一遍要 32 帧，60 帧每秒下大约半秒。

再算间接光。默认每帧刷新 1/64，约 26 万个纹素。5.9 节说过，每 4×4 个纹素共用一个半球探针，每个探针打 4×4 = 16 条光线。所以每帧要更新约 1.6 万个探针、26 万条光线，正好每个被刷新的纹素摊到一条。

这就是开灯时看到的现象：灯直射的墙先亮，靠反弹照亮的天花板一轮一轮地追上来。下面这张图用一个简化模型把它画了出来。

有两点要补充。第一，上面算的是最坏情况。引擎会按离镜头的距离和上次更新的时间排优先级，镜头附近的卡片刷新得勤得多，所以眼前的房间通常比曲线快，慢慢亮起来的多半是远处。第二，追赶的速度可以调：后处理体积里的 Lumen Scene Lighting Update Speed 会把这两个比例一起放大，代价是 Scene Lighting 这个 Pass 变贵。

间接光滞后不是 bug，而是"每帧只刷新一部分"这个预算的直接后果。想要它更快，就要付更多的 Scene Lighting 成本。

Lumen 的追踪是逐级降级的：先试最便宜的，不行再换贵的。一共三种求交方式：

屏幕追踪先查屏幕上已有的深度和颜色，命中了几乎不花钱。软件光追在 Lumen Scene，也就是距离场加 Surface Cache 里追踪，这是默认路径。硬件光追在有硬件支持时用真实的三角形求交，质量更高；反射里还可以选 Hit Lighting，在命中点重新算光。

不管走哪条路，命中点的光照默认都读 Surface Cache。

这三种方式的分工可以用一句话记住：屏幕追踪管看得见的，距离场管看不见但不远的，硬件光追管要精确的。屏幕追踪最便宜，但画面外和被挡住的东西它一概不知；距离场什么都知道一点，但只是近似的形状；三角形最准，也最贵。

这一章先讲屏幕追踪为什么快，再花大部分篇幅讲距离场：它怎么走、怎么存、为什么远处一定更糙、为什么薄墙一定漏光。最后把整条路径串起来，再补上一个看不见、却决定性能的环节：剔除。

每个探针只有 64 条光线，就像一幅画只给你 64 笔。均匀地朝各个方向画是浪费的：有些方向几乎什么都看不到，画在那里等于白画。重要性采样的意思就是：把笔触集中在画面里重要的地方。

什么方向重要？Lumen 看两件事。

材质觉得哪里重要。漫反射表面主要接收正面来的光，贴着表面擦过来的光贡献很小。所以朝表面正前方多派光线，朝侧面少派。

上一帧觉得哪里亮。上一帧这个探针已经看过一遍了，知道窗户在哪边、灯在哪边。亮的方向多派，暗的方向少派。没有上一帧时，就用世界空间的缓存来猜。

两件事乘在一起，就是每个方向最终能分到多少光线：

下面是一个漫反射表面上的点，头顶半圆是它看到的环境，右上方有一扇亮窗户。同样的光线条数，换三种挑方向的办法，看估计值的噪点差多少：

Lumen 实际做的还要多三件事：材质权重太低的方向直接放弃；剩下的按重要程度排序；把放弃省下来的光线，补给最重要的方向。

有一个细节不能漏：被多派了光线的方向，它的结果要打折；被少派的，要加权。否则亮的方向被数了太多次，整个画面会偏亮。这就是第 1 章蒙特卡洛公式里那个"除以 p"。

重要性采样不增加光线，只是让每一笔都画在更有用的地方。

调性能之前，先确认瓶颈在哪个 Pass：用 GPU profiling 看三个 Pass 各占多少，再去调对应的那一组旋钮。每个 Pass 最主要的成本，各有一个对应的参数：

它们和前几章一一对应。DownsampleFactor 就是第 7 章均匀网格里的那个 N，调大一倍，探针数量变成四分之一。TracingOctahedronResolution 是八面体纹理的边长，8 就是 64 条光线。世界缓存的预算决定远处的光照多快跟上变化。Scene Lighting 的更新速度决定第 5 章那条反弹回路转得多快，也就是间接光滞后有多明显。

拿 4.4 节的账本验证一下：DownsampleFactor 从 16 改成 32，探针数从约 8160 降到约 2040，光线从 52 万降到 13 万，Screen Probe Gather 的追踪成本大致也降到四分之一。但画面上付出的是更大的插值跨度，细小几何之间的阴影会被抹掉。Scene Lighting Update Speed 从 1 改成 2，每帧刷新的纹素翻倍，5.10 节那条追赶曲线快一倍，Scene Lighting 的成本也跟着涨。

每一个旋钮都是在噪声、滞后和成本之间挪位置，不存在只赚不赔的设置。

更完整的一张表，包括每个模块的预算数字和对应的调试视图，在附录 A 的"预算与旋钮速查"里。

放进项目时这些变量平时不该由美术直接改。它们分别落在可扩展性档位、设备配置和控制台哪一层、谁的值最终生效，在 D.1 节；按区域调质量要用后处理体积，在 D.2 节。

画面出问题时，先别动参数。Lumen 提供了一组可视化模式，入口在视口的 View Modes › Lumen。它们让你看到 Lumen 眼里的场景，大多数问题在这里就能定位。推荐的查看顺序是：

1. Surface Cache：确认关键物体有没有被卡片覆盖。没覆盖的区域标成粉色，那里会缺失间接光，在反射里是黑的。
2. Lumen Scene：看 Lumen 眼中的场景和真实场景差多少。它显示的是 Surface Cache 或硬件光追里质量最高的那一份。
3. Geometry Normals：检查全局距离场或 Nanite Fallback 网格有没有问题，比如墙被吞掉了、表面鼓了起来。
4. Reflection View：反射光线实际看到的场景。它的追踪距离有限，远处看不到的东西，反射里也不会有。

Overview 模式会把前三种并排叠在场景上，适合快速扫一眼。

距离场本身也可以单独看：Show › Visualize 下的 Mesh Distance Fields 和 Global Distance Field。另有两个小技巧：控制台输入 r.Lumen.Visualize.CardPlacement 1 可以显示卡片的摆放；关闭 Show › Advanced › Nanite Meshes，就能看到 Fallback 网格的真实样子。

做完这一轮，才轮到调性能或质量参数。

Surface Cache 和距离场是 Lumen 的核心优化，但它们也给内容制作带来了约束。归结起来是一句话：

Lumen "看不见"的表面，它就照不到，也反射不出来。

三条最常见的约束：

看粉色。Surface Cache 视图里的粉色表示没有卡片覆盖，那里会缺失间接光。美术和技术美术最好养成习惯，在关卡里定期打开这个视图扫一遍。

拆网格。每个网格默认最多 12 张卡片。形状复杂的网格，比如整栋建筑、带很多凹槽的构件，12 张不够覆盖。可以调高 Max Lumen Mesh Cards，更好的办法是拆成几个网格。

慎用骨骼网格。骨骼网格只在蒙皮前的包围盒四周放 6 张卡片，大幅变形时覆盖有限。角色的 GI 质量差，多半是这个原因。

放进项目时资产、实例、材质和灯光上的完整开关表，以及三条违反了也不会报错的资产规则，在 D.3 节。

把前面几章的原理，翻译成美术和技术美术可以直接对照的清单。前四条都是在"让缓存和距离场看得见"：

• 室内分件建模。墙、地、天花板各自独立；整间房做成一个网格不行。
• 墙厚至少 10 cm。几何体要闭合；极薄的面和单面网格会漏光。
• 大件拆成模块。山体、多层建筑整体做距离场，质量差，还会自遮挡。
• 高面数用 Nanite。植被和实例化网格要用 Nanite 才被支持；同时做好 LOD。

后四条是具体的设置：

• 软件光追的网格避免 WPO。World Position Offset 在软件光追下不被支持。
• 按导入尺寸设距离场分辨率。小尺寸导入、再在场景里放大的网格，要在静态网格编辑器里手动调高分辨率。
• 视角相关的材质给备用版。用到 Pixel Depth、Camera Position 这类节点的材质，用 Ray Tracing Quality Switch 给 Lumen 单独一个版本。
• 植被开启距离场光照。在 Foliage 工具里勾选 Affect Distance Field Lighting。

出问题时，配合前面的调试视图和本章最后的排错表一起用。

上一节的表是按"问题 → 原因"排的，适合查。真正排错的时候，手里只有一个症状，需要的是另一种顺序：先看哪个视图，看到什么说明是哪个原因，再按什么顺序处理。

下面把最常见的七个症状做成了路线。每条路线都遵守同一个原则：先确认几何和缓存，最后才动参数。原因后面的编号可以点，会跳回讲原理的那一节。

把七条路线放在一起看，会发现它们只落在四个地方：距离场表示不出来（漏光），卡片没覆盖（黑块、角色），预算不够（滞后、斑驳、发糊），超出范围（远处消失）。前两类只能改内容，后两类才是参数能解决的。

参数能买到的是速度和清晰度，买不到几何。墙太薄、网格太碎的问题，调多少参数都只是在压症状。

Lumen Lite 是 UE 5.8 新增的，对应可扩展性的 Medium 档。它的核心叫 Irradiance Field Gather：在像素周围放世界空间的探针，预先算好辐照度，再结合探针遮挡插值到像素。名字很陌生，但读过第 3 章就会发现，这正是 DDGI 那条探针路线。

速度上，High 档以 PS5 上 60 帧为目标，Lite 的速度大约是它的两倍。画质上的代价主要在反射：Medium 档的反射退回了屏幕空间反射（SSR），粗糙表面的高光由 Lumen 的 GI 提供。

当代掌机默认使用这一档，PC 也支持；Low 档则完全关闭 Lumen 功能。

思路依然是第 4 章那句话：能缓存就不重算。只不过这一次缓存的粒度更粗，换来的速度更多。下一节先列出它到底换了哪几块，再细看核心那一块，最后讲代价。

很多人把 Lite 理解成一个开关。其实它是四处同时改，画面会在好几个地方一起变化。下面是 High 和 Medium 两档的对照：

底层的开关是 r.Lumen.FinalGatherMethod：Medium GI 把它设为 0，最终收集就从屏幕探针换成了辐照度场。不过日常不要直接改它，用档位变量。开启方式有一个坑：要同时设置 sg.globalilluminationquality 1 和 sg.reflectionquality 1。只设 GI 那一个，并不构成完整的 Lite：反射还停在上一档，测出来的结果不可比。

5.8 里它已经可用，但 Epic 仍然标为 Beta。这一版还新增了一个蓝图函数 IsGlobalIlluminationAllowed，方便游戏按 GI 是否开启来切换后处理体积的设置。

最关键的一点来自 Epic 的 Daniel Wright：Lite 基于带探针遮挡的辐照度场，但探针放置是自动的。这是它和一般需要手摆探针的方案的根本区别，也是它能直接作为一个档位切换的前提。第 3 章算 DDGI 那笔账时已经看到，固定网格在开放世界里要么浪费、要么不够，自动放置正是冲着这个问题去的。

上一节说 Lite 的探针是自动放置的。自动放置有一个绕不开的问题：探针按网格铺下去，总有一些会落进柱子、墙体、地面里面。

落在几何体里的探针，朝哪个方向看都只能看到背面，读出来是黑的。更麻烦的是，它的深度信息也是乱的，第 3 章讲的探针遮挡靠的就是深度信息，所以遮挡测试也拦不住它。结果就是附近的像素把一个黑探针平均了进去。

Epic 的性能指南给了 Lite 的处理办法和调试视图：卡在几何体里的探针会被挪出来，挪出来的标成绿色；挪不出来的标成红色，不参与照明。下面这张图把这两件事，以及探针遮挡，拆开给你看。

拖一拖就能分清两类问题：黑块来自留在几何体里的探针，靠挪动解决；漏光来自薄墙两侧的探针被混在一起，靠遮挡解决。两样都开了，剩下的误差主要来自探针间距，比如柱子的阴影边缘被抹宽了。

看 Lite 的调试视图时，红点多的地方要特别留意：那里能用的探针少，插值只能借更远的探针，画面最容易出问题。

图里的挪动规则（在半个间距内找最近的空位）是为了演示写的简化版，Lumen Lite 实际的挪动距离和判定方式没有公开。

Lite 只是可扩展性里的一档。把五个档位放在一起看，才知道它的位置，也知道降到它下面一档会失去什么。

表里有两点值得多看一眼。

第一，从 Medium 到 Low 是一个断崖。Medium 仍然是动态 GI，只是更粗、更慢；Low 直接没有间接光，只剩一层均匀的天光，室内会一下子变平。所以对掌机和中配 PC 来说，Lite 存在的意义就是把"有 GI"的门槛往下挪了一档。

第二，在不支持辐照度场的平台上，文档给出的退路是：小尺度的遮蔽用后处理体积里的 SSAO，大尺度的遮蔽用距离场环境光遮蔽（DFAO）顶替 Lumen GI。画面会有"暗角"，但没有反弹的颜色。

注意 Lite 只改 GI 和反射这两个 sg 变量。阴影、后处理、贴图这些档位是分开的，评估时要固定住它们，否则测出的差别不全是 Lumen 的。

把前面的原理和已知的问题，落成一份可以执行的评估顺序。这一节整体是判断建议，不是官方结论。

1. 先确认档位真的生效。两个 sg 变量都要设。只设 GI 那一个，反射还停在上一档，测出来的数不可比。
2. 在 PIE 或打包版本里测。编辑器视口会掩盖问题，已有报告说同样的场景在打包版本里明显得多。
3. 把动态场景排在最前。快速转镜头、移动载具、开关灯、可破坏物。Lite 的主要代价出现在运动中，静态截图看不出来，这和评估画质的习惯正好相反。
4. 反射单独立一项。Lite 下反射是 SSR，屏幕外的内容反射不出来。玻璃、水面、光滑地面是重灾区。
5. 半透明与雾也单独看。它们走第三个采集域，同样被换成了加速路径，雾重的场景要专门过一遍。
6. 别拿 High 的调参经验去套。换掉的是整套最终收集算法，不是同一条质量曲线上的低档，"探针多一点就好"那类直觉不适用。

如果 Lite 的画面不达标，还有一条备选路线：用 High 档配合降低探针预算，可能比 Lite 更可控。这是社区的建议，没有经过验证。

常有人问：Lite 是不是就是"手机版 Lumen"？不是。Lite 的目标平台是 Switch 2 这类掌机和中配 PC。手机上的 Lumen 是另一件事，而且路线完全不同。

移动端的 Lumen 从 UE 5.4 开始提供，至今仍是实验性功能。它没有为手机另写一套算法，做法是：让高端安卓手机直接跑桌面渲染器，再在上面开 Lumen。所以手机上跑的，就是附录 A 代码地图里那棵桌面的调用树，一个函数都没换。

这决定了它的门槛：

• 只支持安卓，需要 Vulkan 和 Shader Model 5。文档列出的 GPU 是三星 Xclipse 9xx、高通 Adreno 7xx、ARM Mali G7xx 这几代。
• iOS、iPadOS、tvOS 上不能用。苹果设备虽然有 Metal 版的桌面渲染器（Beta），但文档明确说 Lumen 目前在上面不工作。
• 移动端自己的渲染器里没有 Lumen。Mobile Forward 和 Mobile Deferred 这两条移动渲染路径不支持它，必须切到桌面渲染器。
• 软件光追需要距离场（r.DistanceFields）；硬件光追要把 r.RayTracing.RequireSM6 关掉，因为手机走的是 SM5。

打开它分三步：在 Project Settings › Platforms › Android › Build 里勾选 Support Vulkan Desktop [Experimental]；把 r.Android.DisableVulkanSupport 和 r.Android.DisableVulkanSM5Support 都设为 0；重启编辑器之后，像桌面一样开 Lumen。

哪些手机会走这条路，由设备配置（Device Profile）决定。引擎自带了 Android_Vulkan_SM5 和三个按 GPU 细分的配置，要把别的机型归进来，就在 DeviceProfiles.ini 里加一条匹配规则：

; 让 Adreno 7xx、安卓 10 以上的机型使用 SM5 配置
+MatchProfile=(Profile="Android_Adreno_Vulkan_SM5",Match=(
    (SourceType=SRC_GpuFamily, CompareType=CMP_Regex, MatchString="Adreno \(TM\) 7[0-9][0-9]"),
    (SourceType=SRC_AndroidVersion, CompareType=CMP_GreaterEqual, MatchString="10")
    ; ……引擎自带的规则里还会检查 SM5 是否可用
))

[Android_Vulkan_SM5 DeviceProfile]
DeviceType=Android
BaseProfileName=Android
+CVars=sg.GlobalIlluminationQuality=2   ; GI = High
+CVars=sg.ReflectionQuality=2           ; 反射 = High
+CVars=sg.ShadowQuality=2

注意最后两行：SM5 配置默认把 GI 和反射都设成 2，也就是 High，走的是 Screen Probe Gather 加 Lumen Reflections 这条完整路径，而不是 Lite。

成本方面，文档没有给数字，只给了两句定性的话：桌面渲染器在手机上本身就比移动渲染路径贵得多，Lumen 还要再加一层；Epic 目前不建议用它发布产品。

把上面几节放在一起，不同设备上的 GI 选择其实很清楚：

对要发布的手机项目，现实的选择仍然是移动渲染器加上烘焙光照、光照探针、反射捕获这一套"第 2 章"的方法。动态 GI 在手机上还处于试验阶段。

如果想在高端安卓机上试，有一个值得测的方向：手机走的是桌面那棵调用树，所以理论上可以在设备配置里把 GI 和反射设成 1，让它走 Lite。文档没有说这样是否受支持，这是本文的推断，需要在真机上验证；如果可行，第 10.5 节讲的那些动态场景里的问题，在手机的低帧率下只会更明显。

一句话：Lite 是给掌机和中配 PC 的；手机上的 Lumen 是"把桌面原样搬上去"，今天只适合做试验。

收尾之前，纠正几句常听到的话。每一条都能对回前面的某一章。

"Lumen 就是光线追踪。"光追只是它可选的一个求交后端，默认走的是距离场。它真正的新东西是 Surface Cache。（第 3、4 章）

"开了 Lumen，画面就自动更准。"它放弃预计算换来了全动态，精度其实是降的。纯静态的场景里，烘焙依然更好。（第 2 章）

"用了 Lumen 就不用管美术规范了。"恰恰相反。墙要够厚、网格要分件、植被要开距离场，否则漏光和黑斑一定会出现。（第 6、9 章）

"画面有噪点，是引擎的 bug。"噪点是蒙特卡洛采样的本质。实时渲染只能靠复用和滤波把它压低，不可能消除。（第 1、7 章）

"Lumen Lite 就是把画质调低一档。"它换掉的是整套最终收集算法，画面特征和 High 不在同一条质量曲线上，调参经验不通用。（第 10 章）

"间接光反应慢，是机器性能不够。"这是设计使然。缓存和探针都靠跨帧累积，灯光一突变，就一定有一个追赶的过程。（第 5、7 章）

"Lumen 已经能上手机了。"手机上的 Lumen 是 5.4 起的实验性功能，靠把桌面渲染器原样搬上高端安卓机，iOS 不支持，Epic 不建议用来发布。Lite 的目标是掌机和中配 PC，不是手机。（第 10 章）

"开了异步计算，Lumen 就变便宜了。"异步只是把 Lumen 的工作藏进别的 Pass 的空隙里，工作量一点没少。空隙不够时照样拖长帧时间；做性能分析时还要先把它关掉。（附录 B）

这些误解有一个共同点：把 Lumen 当成"更准的渲染"。它其实是一套在固定预算里，尽量把光照摊匀的工程方案。

回到开场那个房间。地板弹亮了墙，墙弹亮了天花板，每个表面的亮度都依赖别的表面。第 1 章把它写成了一个自己引用自己的积分；第 2、3 章看了二十年里绕开它的五条路线；之后五章拆开了 Lumen 的回答。压成四句话：

1. Surface Cache 把"命中点要算光"变成"读缓存"。这是 Lumen 唯一真正新的东西。
2. Screen Probe 只在稀疏的探针上追踪，降噪也在探针空间里完成。
3. World Radiance Cache 负责远场光照，被许多帧、许多像素共享。
4. 反射按粗糙度分流，只有够光滑的表面才单独花光线。

5.8 的 Lumen Lite 保留了第一句，换掉了第二、四句：漫反射改用跨帧慢更新的辐照度场，反射退回 SSR。它更便宜，代价是运动中的滞后和屏幕外反射的缺失。

Lumen 不是单一的算法，而是一套围绕缓存组织起来的管线。理解了缓存在哪一层、每帧更新多少、哪里覆盖不到，就能解释大部分的画面问题和性能问题。

正文到这里结束。后面四个附录换成工程视角：附录 A 把部件拼回系统流图和代码地图；附录 B 讲这些 Pass 在 UE 的一帧里哪些必要、怎样调度；附录 C 带你按八个里程碑自己写一遍，并列出一路上的坑；附录 D 讲程序和美术怎样分层控制它、怎样按区域调。

能缓存，就不重算。

Lumen 的工程部分可以拆成六条线，外加单独的一条 Lumen Lite。每条线都按同一个顺序走：先懂原理，再看数据，然后动手验证，最后记住常见的坑。格子里的编号可以点，直接跳到对应的小节。

想自己从零写一遍的，这六条线在附录 C 里各有对应的里程碑，顺序就是施工顺序。

六条线不必齐头并进。美术和技术美术最该先走通"场景表示"和"追踪"两条，因为大多数画面问题出在这里；程序先走"最终收集"，它是性能的大头；做技术选型的人看最后两条。

这张图把前面讲过的所有部件放在一起。从左到右是数据的流向：输入生成持久的场景表示，Pass 1 往里写光，Pass 2、3 从里面读光，最后合成。

三种用法。点模块：看它读谁、写谁、预算多少、在哪调、出问题看哪个视图，并能跳到讲它的小节。按一帧的顺序播放：九步依次点亮，每一步只亮参与的模块和它们之间的连线。切到 Lumen Lite：看哪两块被换掉了。

最该记住的是橙色的线：写回 Surface Cache 的那两条。光照写进缓存，下一帧再被读出来，Lumen 的多次反弹和间接光滞后都来自这条回路。

同一张图，切到 Medium 档。虚线框是被换掉的两块：Screen Probe Gather 换成了 Irradiance Field Gather，Lumen Reflections 换成了 SSR。卡片、图集、距离场这一套照旧保留，半透明走了更省的路径。

按一帧播放时注意第 4、5 步。探针跨帧慢慢更新，像素只做插值，这是它速度约为 High 两倍的原因；遮挡信息跟着探针走、落后于几何，这是黑块拖尾的来源。两件事出自同一个设计。

官方公开的描述是：探针来自世界空间辐射度缓存，放在像素周围，自动放置，卡在几何里的会被挪出，最终带探针遮挡插值到像素（5.8 性能指南）。图里 Lite 内部的更新顺序是按第 3 章 DDGI 那一类方法整理的，仍属推断。附录 A 的代码地图可以切到 Lite 路径，看调用树里换掉了哪两棵子树。

前面两张流图是按"数据"画的。想去源码里对照着读时，需要的是另一张图：一帧里哪个函数先被调用，它在哪个文件，调的是哪些变量。

读源码时有三个入口最值得先打断点：BeginUpdateLumenSceneTasks 决定这一帧要捕获哪些卡片；RenderLumenSceneLighting 决定这一帧给哪些页打光；r.Lumen.FinalGatherMethod 那个分支决定走屏幕探针还是辐照度场。画面上看到的大部分问题，都能在这三处找到源头。

Profiler 里对应的三个大块是 Lumen Scene Lighting、Lumen Screen Probe Gather 和 Lumen Reflections。用 stat GPU 看总账、ProfileGPU 看细分；想单独测 Lumen 时，先用 r.Lumen.AsyncCompute 0 关掉异步计算，否则它的耗时会和别的 Pass 重叠在一起。

把散在各章的数字、旋钮和调试视图收进一张表。调性能时先用 GPU Profiler 找到最贵的 Pass，再来这里找它对应的那一行。

"档"一列是证据档位：一档来自官方文档，二档来自 2022 年的演讲，结构可靠，但具体数值在新版本里可能已经变了，以你项目里实测的为准。

最后把 Lumen 放回时间线上。它不是一次成型的，读资料时要注意数字属于哪一代。

5.1 到 5.3 以及 5.5 也都有 Lumen 的改动，但本文没有逐版核实，所以没有列出。从 5.6 开始，方向已经很清楚：软件光追只保留全局距离场这一条，更高的精度交给硬件光追；同时往下用 Lite 覆盖中低端设备。升级引擎时，请以对应版本的发布说明为准，并重测一遍上一节表里的基线。

附录 A 的系统流图回答"数据怎么流"。这一节换一个问题：在 UE 里，Lumen 每帧到底要跑哪些 Pass？哪些是骨架，关了整个 GI 就塌；哪些是可以拿掉的增强，关了只是丢一部分画质、省一部分时间？

下面这张图按一帧的先后从左到右排开。实线框是必要的；虚线框是可选、默认开的；点线框是可选、默认关的；左边加粗的是取决于追踪方式的。点一个方块看它为什么在这里；对可选的方块再点一次，就能把它关掉，看连线怎么断、丢掉了什么、对应哪个变量。

把三种配置都切一遍，会看到一个很稳定的结构：默认配置下必要的方块是 7 个，归起来只有四件事。场景表示要更新（卡片捕获，加上软件光追的距离场或硬件光追的 TLAS）；缓存要打直接光；收集要有放探针、场景追踪、滤波这条主干（Lite 下换成一整块 Irradiance Final Gather）；最后要合成。其余的都是增强。

这些增强分两类，取舍思路完全不同：

省时间的大刀：Lumen Reflections 和半透明体积。前者整块换成 SSR，后者让半透明和雾失去 GI。场景里没有大面积光滑表面、没有雾的项目，这两刀几乎不影响画面，却能省下一整个 Pass。

省得少、丢得多的小刀：屏幕追踪、Short Range AO、Radiosity。它们本身不贵，关掉后的损失却很直观：近处的接触光变糊、物体浮在地上、室内变暗。它们更适合在排查问题时临时关掉做对照，而不是拿来省性能。

先砍整块的 Pass，再调预算；不要先关那些便宜却决定观感的小步骤。

Lite 那一栏只画出了 Epic 公开的部分：Pass 2 换成 Irradiance Final Gather，Pass 3 换成 SSR，其余照旧。社区有报告说 Medium 档只走软件光追，但 Epic 没有确认，图里只在读数里提示。

知道了哪些 Pass 要跑，下一个问题是它们什么时候跑。现代 GPU 有两条可以同时干活的队列：图形队列负责光栅化，异步计算队列可以在旁边并行地跑计算着色器。Lumen 的大部分工作都是计算着色器，所以它能被挪到异步队列上，藏进别的 Pass 的空隙里。

能不能挪，取决于它在等谁：

• Scene Lighting 只需要卡片已经捕获好，不需要这一帧的 GBuffer。所以它可以和 Base Pass 同时跑。
• Screen Probe Gather 要在 GBuffer 的深度和法线上放探针，还要读 Scene Lighting 写好的缓存，所以必须等这两样都完成。它正好可以和阴影、直接光照并行，因为那两步不读它，它也不读那两步。
• Reflections 要复用 Screen Probe Gather 的结果，所以排在它后面。默认留在图形队列上。
• 合成要等间接光和直接光都好了，是汇合点，回到图形队列。

对应的四个变量都在源码里，默认值是：r.Lumen.AsyncCompute 1 总开关；r.LumenScene.Lighting.AsyncCompute 1；r.Lumen.DiffuseIndirect.AsyncCompute 1；r.Lumen.Reflections.AsyncCompute 0。总开关还要再过一道硬件检查：平台必须支持高效的异步计算；用硬件光追时，只有 Inline 光追才能走异步，走光线追踪管线就会整体退回图形队列。

工程上有两个直接的推论。第一，分析性能时要先关异步：r.Lumen.AsyncCompute 0，否则 Lumen 的耗时和 Base Pass、直接光照叠在一起，stat GPU 里分不清是谁慢。第二，直接光照很重的场景（灯多、阴影多），Screen Probe Gather 和 Reflections 会在图形队列上互相挤，官方建议这时把三个异步开关都打开，让整个 Lumen 跑在异步队列上。

异步计算不减少 Lumen 的工作量，只是把它藏进别的 Pass 的空隙里。空隙不够大时，它一样会拖长帧时间。

把前两节涉及的开关汇总成一张表，方便写进设备配置或可扩展性设置。这些变量大多带 ECVF_Scalability 标记，可以按档位设置。

用这张表时有一个顺序：先在后处理体积和可扩展性档位里调（Lumen Scene Detail、Final Gather Quality、反射质量），它们按区域和档位生效，最可控；确认是哪一块慢、而且那一块对画面贡献不大时，再用控制台变量把它整块关掉。直接改变量，是全局的、对所有场景一刀切。

前面讲的都是 GPU。Lumen 还有一部分开销在 CPU 上，而且常常是卡顿的来源：每帧决定哪些卡片要重新捕获、哪些距离场要重建，再把它们排进绘制命令。A.4 代码地图里的 BeginUpdateLumenSceneTasks 就是这一段的入口。

它贵在什么时候？官方性能指南和 Epic 员工的回复给了几种典型情况：

• 镜头附近的网格：卡片更新针对的是相机附近的网格，不管它们动没动。附近物件很碎、很多时，每帧的卡片请求就多。
• 移动静态物体：会让距离场的静态缓存失效，代价可能很大。开了"影响距离场光照"的可移动物体，同样会触发距离场的动态更新。
• 镜头快速移动：新进入范围的区域要补距离场页和卡片。
• 硬件光追：TLAS 每帧重建，实例越多越贵。

排查时，按这个顺序打开调试工具：

1. 看卡片在更新谁：r.Lumen.Visualize.CardPlacement 1 显示正在处理的卡片，它和 Unreal Insights 里卡片更新任务的来源基本一一对应。r.LumenScene.SurfaceCache.LogUpdates 1 打印更新日志，设为 2 会带上网格名。
2. 看距离场在重建谁：ShowFlag.VisualizeGlobalDistanceField 1 打开全局距离场视图，配合 r.GlobalDistanceField.Debug.DrawModifiedPrimitives 1 高亮被更新的物体；r.GlobalDistanceField.Debug.ShowStats 1 显示统计，r.GlobalDistanceField.Debug.LogModifiedPrimitives 1 打日志。
3. 压范围：卡片更新的剔除距离，软件光追看 r.LumenScene.GlobalSDF.ClipmapExtent，硬件光追看 r.RayTracing.Culling.Radius。r.LumenScene.SurfaceCache.CardMinResolution 和后处理里的 Lumen Scene Detail 决定多小的物体还会进场景。
4. 快镜头段落：可以对这些段落打开 r.AOGlobalDistanceField.FastCameraMode。

Epic 员工的原话是：后处理体积里的设置，是按区域在质量和性能之间取舍的最好办法。控制台变量留给定位问题。

这份讲解里的内容，证据强度并不一样。阅读和转述的时候，请分清三档。

一档：可以直接引用。Epic 的官方文档，以及 Epic 工程师的公开说明，比如 Daniel Wright 说 Lumen Lite 基于带探针遮挡的辐照度场。

二档：结构可靠，数字会变。论文和演讲。机制描述是可靠的，但其中的分辨率、内存、毫秒耗时都是当年那个版本的。比如 5.8 已经移除了表面缓存的不透明度层，而 2022 年的演讲里它还在。

三档：需要自己验证。社区报告和本文的推断，以及附录 C 里标"建议"的实现选择。比如 Lumen Lite 的几条画面症状来自一个论坛提问帖，Epic 并没有确认它是 bug；黑块的成因解释、评估清单的顺序，也都是本文基于前面原理的判断。

Epic 官方（均在 dev.epicgames.com 的 UE 文档下，按版本查阅）

• Lumen Technical Details
• Lumen Performance Guide
• Lumen Global Illumination and Reflections
• Unreal Engine 5.8 Release Notes
• Using Lumen Global Illumination on Mobile
• Using the Desktop Renderer on Mobile
• Nanite and Lumen for XR

论文与演讲

• Wright 等，Lumen: Real-time Global Illumination in Unreal Engine 5，SIGGRAPH 2022 Advances in Real-Time Rendering 课程
• Sloan, Kautz, Snyder，Precomputed Radiance Transfer for Real-Time Rendering in Dynamic, Low-Frequency Lighting Environments，2002
• Sloan 等，Clustered Principal Components for Precomputed Radiance Transfer，2003
• Ramamoorthi, Hanrahan，An Efficient Representation for Irradiance Environment Maps，2001
• Majercik 等（NVIDIA），Dynamic Diffuse Global Illumination with Ray-Traced Irradiance Fields，2019
• Kaplanyan, Dachsbacher，Cascaded Light Propagation Volumes for Real-Time Indirect Illumination，2010
• Crassin 等，Interactive Indirect Illumination Using Voxel Cone Tracing，2011
• Bitterli 等，Spatiotemporal Reservoir Resampling for Real-Time Ray Tracing with Dynamic Direct Lighting（ReSTIR），2020

社区与二手资料（不是一手资料，引用前请回到原始出处核对）

• Tom Looman，《UE 5.8 Performance Highlights》
• Daniel Wright（Epic）关于 Lumen Lite 的公开说明
• Unreal Engine 开发者论坛：Medium 档 GI 画面问题的提问帖
• DDGI 的实现与评估（捷克理工大学学位论文），本文 DDGI 公式的直接来源
• Tom Looman，《UE 5.7 Performance Highlights》：Detail Tracing 弃用、MaxRayIntensity 默认值等
• Epic 开发者论坛，Lance Chaney（Epic）关于 Lumen 场景更新开销的回复（2025.10）：附录 B.4 的调试变量
• Epic 开发者论坛：Irradiance Field Gather 的世界缓存更新开销提问帖（2026.05）
• UE 5.4 控制台变量说明（ue544 cvar wiki，按源码整理）：附录 B、C 中变量名与默认值的出处
• How UE Renders a Cube（源码阅读笔记）：附录 A.4 代码地图中函数与文件名的出处

前面的章节回答"Lumen 为什么这样做"。这个附录换成工程师的问题：如果要我自己写一个，从哪里开始、按什么顺序、每一步怎么知道自己写对了、会踩哪些坑。

先说结论：不要一上来就照着 Lumen 全套写。Lumen 是多年迭代的产物，很多部件是为了解决大规模场景、几十种平台和边角案例才长出来的。自己写，应该先做一个能跑通的最小闭环，再一块一块加回去。

最小闭环是这样的：场景用卡片和距离场表示；卡片打直接光；屏幕上放探针，探针的光线在距离场里追踪，命中后读卡片；结果滤波、插值到像素。做到这里，你就已经有了动态的单次反弹 GI。再把卡片的间接光接回去，就有了多次反弹。

有几样东西建议第一版直接砍掉，等闭环稳定了再加：硬件光追（先只做软件路线）、卡片的聚类生成（先用 6 面）、虚拟化的图集分页（先用固定大小的简单打包）、自适应探针、重要性采样（先均匀余弦采样）、反射和半透明。每一样都能单独加回去，而且加回去的时候，你会很清楚它解决的是哪个问题。

需要的硬件能力：计算着色器、3D 纹理（或者能模拟它的大纹理）、间接派发（indirect dispatch）、原子操作。没有间接派发也能做，但追踪阶段会浪费大量线程。

写 GPU 系统最容易翻车的地方，是边写边加缓冲区，最后谁读谁写一团乱。动手之前，先把要用到的资源列成一张表：它存什么、谁写、谁读、活多久。

两条容易被忽视的约定，最好一开始就定死：

光照的单位和曝光。所有缓存里的光照都存线性的、未曝光的 HDR 值。如果你的引擎把场景颜色存成"预曝光"的（乘过当前曝光值，UE 就是这样做的），那么屏幕追踪从场景颜色里读到的值，必须先除回曝光再用。否则自动曝光一变化，间接光就跟着闪。

坐标系和深度的约定。卡片里存的深度是"沿卡片朝向的距离"，屏幕深度是"相机空间的深度"，距离场是"世界空间的距离"。三套深度混用的 bug 非常难查，建议每种都写成一个带名字的函数，不在着色器里手写换算。

先画资源表，再写着色器。资源表就是你的系统设计图，后面每个 Pass 只是在这张表上读和写。

第一个里程碑做的是第 5 章那份缓存。目标很朴素：每个网格从几个方向被"拍"成卡片，卡片住进一张图集，之后任何一点都能查到它表面的材质。

生成卡片。起步时，每个网格直接用包围盒的 6 个面当卡片：+X、−X、+Y、−Y、+Z、−Z 各一张，朝向网格中心拍。这样做覆盖不了凹进去的地方（下一节的交互图会演示），但足够跑通闭环。等闭环稳定了，再换成第 5 章讲的面元聚类：把表面采样成带朝向的面元，按朝向和位置聚类，每类拟合一张卡片。

分配图集。卡片的分辨率按它在屏幕上的大小决定，近大远小。起步用最简单的"架子"打包（按高度排序，一行一行摆），预留固定比例的空位。Lumen 用的是 128² 的物理页加虚拟映射，能按需换页；这一步可以晚点再做。

捕获。对每张卡片做一次正交投影的光栅化：相机放在卡片外侧，朝卡片方向看，视锥就是卡片的包围盒。输出写进图集里这张卡片的矩形区域。

// 顶点着色器：把网格投到卡片的正交相机里
float4 VS(float3 localPos) {
    float3 p = mul(card.worldToCard, mul(instance.localToWorld, localPos));  // 卡片空间
    float2 uv = (p.xy - card.min.xy) / (card.max.xy - card.min.xy);          // 0..1
    float  z  = (p.z  - card.min.z ) / (card.max.z  - card.min.z );          // 沿朝向的深度
    float2 atlas = card.atlasRect.xy + uv * card.atlasRect.zw;                // 写到图集里的位置
    return float4(atlas * 2 - 1, z, 1);
}
// 像素着色器：只写材质，不算光
void PS(..., out float4 albedo, out float4 normal, out float4 emissive, out float depth) {
    albedo   = float4(BaseColor * (1 - Metallic), Opacity);  // 当作纯漫反射，不存高光
    normal   = EncodeNormal(WorldNormal);                    // 存世界空间法线，省得采样时再转
    emissive = Emissive;
    depth    = z;                                            // 采样时做深度校验要用
}

采样。任意一点要读缓存时，先按它的法线挑出朝向合适的卡片（6 个轴里最多 3 个），把点投进每张卡片，按"深度对不对得上"和"朝向有多正"加权混合。这一步是 M4 的内容，单独放在下一节之后。

第二个里程碑是第 6 章的距离场，分两半：离线为每个网格生成距离场，运行时把它们合成一张跟着相机走的全局距离场。第三个里程碑是在里面走光线。

离线生成。对网格包围盒（四周外扩几个体素）里的每个体素中心，求它到最近三角形的距离，这一步用 BVH 做最近点查询。难的是符号：这个点在网格里面还是外面？游戏资产大多不是水密的，"射一条线数穿过几次"的教科书做法会大面积出错。6.5 节讲过 Lumen 的办法：从这个点向几十个方向发射线，数一数命中的是三角形的背面还是正面，背面多就算在里面。

for (voxel in PaddedBounds(mesh, padVoxels = 4)) {
    float3 p = VoxelCenter(voxel);
    float  d = ClosestDistance(meshBVH, p);              // 无符号距离
    if (d > NarrowBand) continue;                        // 窄带：远离表面的体素不存
    int back = 0, hits = 0;
    for (int i = 0; i < 64; i++) {                       // 均匀球面方向
        Hit h = RayCast(meshBVH, p, SphereDir(i));
        if (!h.valid) continue;
        hits++;
        if (dot(SphereDir(i), h.triNormal) > 0) back++;  // 打到背面
    }
    bool inside = hits > 0 && back > hits * InsideRatio; // 比例按资产质量调
    Store(voxel, Quantize8(inside ? -d : d, NarrowBand));// 一个字节，±几个体素的范围
}

运行时合成全局距离场。全局距离场的每个体素，取所有覆盖它的实例的距离的最小值。实例可能被旋转、缩放，所以要先把点变换到实例的局部空间，读出局部距离，再换算回世界距离。

float d = ClipmapVoxelSize * 4;                          // 没有物体时给一个"足够远"的上限
for (inst in InstancesOverlapping(brick)) {              // 先用粗网格剔除，不要遍历全场景
    float3 local = mul(inst.worldToLocal, p);
    float  dl    = SampleMeshSDF(inst.mesh, local);      // 出了网格包围盒：用到包围盒的距离代替
    d = min(d, dl * inst.minAxisScale);                  // 非均匀缩放：用最小的轴缩放，保证不会走过头
}
GlobalSDF[clipmap][voxel] = d;

追踪。就是 6.3 节的 sphere tracing，但有三处必须加的细节：起点要沿法线偏移，避免一出发就撞上自己；命中阈值随走过的距离放大，对应 6.7 节的"表面扩张"；步数要有上限。

float t = NormalBias;                                    // ① 起点偏移：约一个体素
for (int i = 0; i < MaxSteps; i++) {
    float3 p = origin + dir * t;
    float  d = SampleGlobalSDF(p);                       // 自动选覆盖 p 的最细一层 clipmap
    float  expand = min(t * ExpandSlope, VoxelSize(p) * 0.87);   // ② 越远扩张越大，上限半个体素对角线
    if (d < expand + MinHitDistance) return Hit(p, t);
    t += max(d, MinStep);                                // 掠射时 d 很小，强制最小步长
    if (t > MaxDistance) return Miss();
}
return HitAtStepLimit(origin + dir * t);                 // ③ 步数用尽：当作命中还是未命中，要统一约定

光线停下来了，接下来要回答"那里有多亮"。这一步把第 5 章的缓存和第 6 章的追踪接在一起，是整个系统里最容易出隐蔽 bug 的地方。

先要知道撞到的是哪个物体。在单个网格的距离场里追踪时，你天然知道是哪个实例，可以直接去找它的卡片。在全局距离场里追踪时，所有物体被合成了一张图，你不知道撞到的是谁，所以 Lumen 在这种情况下改读 6.8 节的 Voxel Lighting。自己实现时有两个选择：第一版只追网格距离场（用一个粗的空间网格做剔除），命中就知道实例；或者在全局距离场旁边存一张"最近实例编号"的体素图。

知道了实例，再从它的卡片里挑出朝向合适的几张，把命中点投进去，用深度校验判断这张卡片拍到的是不是这一点。下面这张图是一个带凹槽的物体的剖面，拖动命中点，看每张卡片怎么判定。

第五个里程碑让缓存亮起来。它分三件事：每帧挑哪些页来更新，给这些页算直接光，再算它们之间的反弹。

挑页。按 5.8 节的规则给每页一个优先级：最近被光线用过、又很久没更新的页优先。每帧只取预算内的前若干页。实现上，最省事的是在 GPU 上做一个优先级直方图，从高到低累加，找到刚好装满预算的那个阈值，再派发一次只处理阈值以上的页。

单位。动手之前把单位定下来，否则π会在你的系统里到处乱飞。建议约定：直接光和间接光都以辐照度（E，单位面积接收到的光）存；最终光照存出射辐射亮度（L，别人看过来时看到的亮度）。对漫反射表面：

用余弦加权的方向采样半球时，"间接辐照度 ÷ π"恰好就是这些样本亮度的平均值，代码里不用再出现π。

// 直接光：逐纹素累加灯光
float3 E_direct = 0;
for (light in LightsTouchingTile(tile)) {                 // 8×8 纹素一块，每块限定灯数
    float  ndl    = saturate(dot(n, light.dir(p)));
    float  shadow = InShadowMapFrustum(p, light) ? ShadowMap(p, light)
                                                 : SDFShadowRay(p + n * Bias, light);  // 屏幕外用距离场补
    E_direct += light.radiance(p) * ndl * shadow;
}
// 多次反弹：每 4×4 纹素一个半球探针，读上一轮的最终亮度
float3 meanL = 0;
for (int i = 0; i < 16; i++) {
    float3 dir = CosineHemisphere(i, FrameJitter, n);    // 余弦加权：平均值就等于 E/π
    Hit h = TraceSDF(p + n * Bias, dir);
    meanL += h.valid ? SampleSurfaceCache(h) : SkyRadiance(dir);   // 读的是上一轮写进去的 FinalLighting
}
meanL /= 16;
float3 Eind_over_pi = TemporalBlend(history, meanL);   // 最多累积几帧，压噪
FinalLighting[texel] = Albedo * (E_direct / PI + Eind_over_pi) + Emissive;

这个循环有一个必须亲手验证的性质：它是一个反馈系统。每转一轮，最终亮度乘以反照率再喂回自己。只要反照率小于 1，它就收敛；反照率等于或大于 1，它就发散。下面这个白炉测试是检验它最简单的办法：一个封闭的房间，所有表面反照率相同、自发光相同，理论上最终亮度会收敛到 自发光 ÷（1 − 反照率）。

到这里缓存已经有光了。第六个里程碑把它送到屏幕上：第 7 章的 Screen Probe Gather。它是一条五段的流水线，每段一个 Pass，中间结果都存在探针空间的小纹理里。

第一段，放探针。屏幕切成 16×16 像素的格子，每格选一个像素当探针，记下它的深度、法线和世界坐标。选哪个像素每帧抖动一下，长期看就覆盖了整个格子。落在天空上的格子标记为无效。

第二段，生成光线。每个探针一张 8×8 的八面体小图，每个纹素一个方向。第一版不做重要性采样：用八面体映射覆盖整个球面，每个纹素在自己的范围内随机抖动一个方向，指向表面以下的方向直接跳过。

float2 OctEncode(float3 d) {
    d /= abs(d.x) + abs(d.y) + abs(d.z);                 // 压到八面体上
    float2 p = d.xy;
    if (d.z < 0) p = (1 - abs(d.yx)) * select(p >= 0, 1, -1);   // 下半球向外翻折
    return p * 0.5 + 0.5;
}
float3 OctDecode(float2 uv) {
    float2 f = uv * 2 - 1;
    float3 d = float3(f, 1 - abs(f.x) - abs(f.y));
    float  t = saturate(-d.z);
    d.xy += select(d.xy >= 0, -t, t);
    return normalize(d);
}

第三段，追踪。先在屏幕上追（6.2 节的 HZB），找不到再进距离场。关键是从屏幕追踪停下的地方接着追，而不是从探针重新出发，否则同一段路会被算两次，还可能撞上探针自己所在的表面。

float3 TraceProbeRay(Probe pr, float3 dir) {
    float3 o = pr.worldPos + pr.normal * Bias;
    ScreenHit s = TraceScreenHZB(o, dir, MaxScreenDistance, Thickness);   // 厚度测试：防止"打到"物体背后
    if (s.hit) return SampleSceneColor(s.uv) / PreExposure;              // 读上一帧画面，先除回曝光
    float tStart = s.lastValidT;                                         // 从屏幕追踪停下处接着走
    WorldHit w = TraceSDF(o + dir * tStart, dir);
    float3 L = w.valid ? SampleSurfaceCache(w) : SkyRadiance(dir);
    return min(L, MaxRayIntensity);                                      // 单条光线的亮度上限：压萤火虫
}

第四段，滤波。每个探针和上下左右的邻居混合。邻居和自己深度差太大（不在同一个表面上）就降权；邻居某个方向的命中点离得很近时，它这个方向的结果不适合拿来用，也要降权。

第五段，积分到像素。每个探针的 64 个方向压成 3 阶球谐的 9 个系数。每个像素找周围 4 个探针，按 7.7 节的平面距离加权，用像素自己的法线求值。求值时乘上余弦核的三个系数，得到的就是辐照度。

// 余弦核卷积后的系数：第 0 阶 π，第 1 阶 2π/3，第 2 阶 π/4（第 2 章推导过）
float3 IrradianceFromSH(SH9 sh, float3 n) {
    float3 E = PI * sh[0] * Y00
             + (2 * PI / 3) * (sh[1] * Y1m1(n) + sh[2] * Y10(n) + sh[3] * Y11(n))
             + (PI / 4) * (sh[4] * Y2m2(n) + sh[5] * Y2m1(n) + sh[6] * Y20(n) + sh[7] * Y21(n) + sh[8] * Y22(n));
    return max(E, 0);                                     // 低阶球谐会"振铃"，结果可能为负，钳到 0
}
// 着色时：DiffuseIndirect = Albedo / PI * E

到 M6 为止的画面是对的，但很噪。第七个里程碑把过去几帧的结果借过来。它是让画面"看起来能用"的最后一步，也是最容易引入拖影的一步。

做法就是 7.8 节的四步：每帧抖动光线方向，用运动矢量找到上一帧的位置，校验那里是不是同一个表面，可信就混合、不可信就丢掉。工程上的关键是第三步的校验，以及丢掉历史之后怎么办。

float2 prevUV = uv - MotionVector(uv);
bool valid = all(prevUV >= 0 && prevUV <= 1);
if (valid) {
    float dPrev = LinearDepth(PrevDepth, prevUV), dNow = LinearDepth(Depth, uv);
    valid = abs(dPrev - dNow) < dNow * 0.02                   // 深度相差 2% 以内
         && dot(PrevNormal(prevUV), Normal(uv)) > 0.9;        // 法线基本一致
}
float  n    = valid ? min(HistoryLength(prevUV) + 1, MaxFramesAccumulated) : 1;
float3 hist = valid ? HistoryIrradiance(prevUV) : 0;
float3 cur  = CurrentIrradiance(uv);
float3 outE = lerp(hist, cur, 1.0 / n);                       // 历史越长，新样本权重越小
WriteHistory(uv, outE, n);                                     // 历史长度也要存下来
// 历史短（刚被拒绝过）的像素：下游的空间滤波加大半径，补偿噪声

前七个里程碑是骨架，这一个是四块可以独立加回去的增强。它们彼此不依赖，可以按项目需要挑着做。

世界缓存。屏幕探针只追到一个半径为止，半径以外的光交给空间里的世界探针（7.10 节）。世界探针只放在屏幕探针"请求"过的地方，所以总是贴着表面。屏幕探针的光线走到半径边界时，在那个位置、沿那个方向去插值世界探针。

WorldHit w = TraceSDF(o, dir, /*maxT=*/ ScreenProbeTraceRadius);
if (w.valid) return SampleSurfaceCache(w);
float3 farPos = o + dir * ScreenProbeTraceRadius;
MarkRadianceCacheProbesUsed(farPos);                   // 本帧请求：下一帧这些探针会被安排更新
return SampleRadianceCache(farPos, dir);               // 在 clipmap 里三线性插值周围 8 个世界探针

世界探针被很多帧、很多屏幕探针共享，所以它可以每个探针追很多光线、慢慢更新。代价是它的分辨率是空间上的，墙两侧的世界探针离得很近，插值时就会漏光。

反射。按粗糙度分流（8.1 节）：粗糙像素直接用屏幕探针沿反射方向求值，光滑像素单独发一条 GGX 采样的光线，追踪和取光复用前面的全部函数。反射的时间累积不能直接用运动矢量：反射里的东西随视角移动的方式和表面不同，要用命中距离算出"反射点"再重投影，否则会拖出一片糊。

半透明。在相机前方放一个和屏幕对齐的体积网格（froxel），每格一个小探针，用同一套追踪和缓存。它的分辨率低，适合雾和半透明的大致照明。

硬件光追。如果前面的追踪都藏在一个接口后面，硬件光追就只是换一个实现：输入一条光线，返回命中的实例、位置、法线。8.5 节说过 Lumen 的命中只取法线和缓存坐标，命中后照样读 Surface Cache，所以第 4、5 个里程碑完全不用改。

struct TraceResult { bool valid; uint instance; float3 pos; float3 normal; float t; };
TraceResult Trace(float3 o, float3 d, float maxT) {
#if USE_HARDWARE_RT
    return TraceInlineRayQuery(o, d, maxT);       // Inline 光追：才能走异步计算（见 B.2）
#else
    return TraceDistanceFields(o, d, maxT);
#endif
}

八个里程碑做完，你手里有十几个 Pass。最后一步是把它们排进一帧：谁先谁后、读什么写什么、哪些可以挪到异步队列。这一步不难，但排错了，bug 会表现为"偶尔闪一下"，极难复现。

下面这张表就是一份可以直接照着搭的帧列表。顺序和附录 A.4 的 UE 调用顺序基本一致，队列关系对应 B.2 节的时间线。