UE5.8 Lumen Lite 与性能优化

去年冬天，老陈的团队接了一个烂摊子：一款 UE5.4 开发的第三人称动作游戏要移植到 Switch 2。发行商咬着牙要求主机模式 1080p、掌机模式 720p，统统 60 帧。PC 版开着 Lumen High Quality，画面挺漂亮；到了 Switch 2 开发机上，Lumen 一打开，帧率直接掉到 28 帧，关掉又变成另一款游戏，美术总监当场翻脸。

美术说：「这山洞没有间接光，石头跟塑料一样。」

程序说：「Lumen HQ 在 Switch 2 上根本跑不动，要么烘焙，要么砍。」

两边僵了三天。最后老陈把项目升到 UE5.8，打开了 Lumen Lite。中文字幕从 28 帧爬到 56 帧，山洞里的光还是能看出来从裂缝漏进来。这个模式救了他们。

一、Lumen Lite 到底是什么

Epic 在 UE5.8 里给 Lumen 加了一个新档位：Global Illumination Quality 设为 Medium 时，Final Gather 会切到 Irradiance Final Gather，也就是大家口头说的 Lumen Lite。官方说法是它用了 irradiance fields 加 probe occlusion，速度大约是 Lumen High Quality 的两倍，目标平台是 Nintendo Switch 2、低端 PC，还有 Steam Deck 这类掌机。

别被名字唬住。它其实就是把原来 HQ 那套「追着像素做屏幕空间追踪 + 软件光线追踪」的管线，换成了一套「先在世界里放一堆探针，把间接光预计算到探针上，再插值回像素」的方案。

Lumen HQ 的思路很直接：屏幕上每个点，我都要知道它周围的光线是怎么反弹的。屏幕追踪、网格距离场、硬件光追，层层加码，精度高，开销也高。

Lumen Lite 的想法更实际：间接光本身变化慢、频率低，我用一张稀疏的 3D 辐照场把它存起来，像素需要的时候直接查表。Probe occlusion 负责挡住那些不该漏过去的光，让墙角、门后、物体背面别出现奇怪的光斑。

说白了，HQ 是「现场算」，Lite 是「提前算好，现场查」。

architecture-beta
    group lumen_hq(cloud)[Lumen High Quality]
        service screen_trace["屏幕空间追踪"] in lumen_hq
        service sdf_trace["网格距离场追踪"] in lumen_hq
        service hwrt["硬件光追"] in lumen_hq
        service final_gather_hq["高成本 Final Gather"] in lumen_hq
    end

    group lumen_lite(cloud)[Lumen Lite]
        service radiance_cache["World Space Radiance Cache"] in lumen_lite
        service irradiance_field["Irradiance Field"] in lumen_lite
        service probe_occlusion["Probe Occlusion"] in lumen_lite
        service final_gather_lite["低成本 Final Gather"] in lumen_lite
    end

    screen_trace:T --> final_gather_hq:T
    sdf_trace:T --> final_gather_hq:T
    hwrt:T --> final_gather_hq:T

    radiance_cache:T --> irradiance_field:T
    irradiance_field:T --> probe_occlusion:T
    probe_occlusion:T --> final_gather_lite:T

上面这张图把两套管线分开了。HQ 那边是几条追踪路径汇总到一个昂贵的 Final Gather；Lite 这边是探针缓存、辐照场、遮蔽，最后走一个轻量的 Final Gather。架构差异比参数差异大得多。

二、Irradiance Fields 与 Probe Occlusion 怎么工作

Lumen Lite 的核心是 World Space Radiance Cache。引擎会在可见像素附近动态放置一些 probe，每个 probe 预计算它那个位置收到的入射光，也就是 irradiance。像素着色的时候，不是去追光线，而是找离自己最近的几个 probe，把 irradiance 插值过来。

这个做法跟 NVIDIA 的 RTXGI 有点像，但 Lumen Lite 的 probe 是自动放的，不需要美术手动摆 probe volume。你复制一个石柱，probe 会跟着出现在新实例周围；删掉物体，probe 也会跟着消失。省了很多人工。

Probe occlusion 是另一个关键。没有遮蔽的话，墙后面的 probe 照样会被亮面照亮，光线就会穿墙。Epic 的做法是判断 probe 和像素之间有没有几何体遮挡，有遮挡的 probe 会被降权或者干脆不用。调试视图里，绿色 probe 是被自动挪出几何体的，红色 probe 还卡在几何体里，不会被参与光照。

数学上，单个像素收到的间接辐照度可以近似写成：

$E(p) \approx \sum_{i \in \text{neighbors}(p)} w_i(p) \cdot V(p, p_i) \cdot E_i$

其中 $E_i$ 是第 $i$ 个 probe 上预计算的辐照度，$w_i(p)$ 是插值权重，$V(p, p_i)$ 是 probe 到像素的可见性。Probe occlusion 就是要把那个 $V$ 项算对。

这个公式并不复杂，实际工程里麻烦的是 probe 放多少、更新多快、插值半径多大、遮蔽测试怎么做才稳。Epic 把这些都包在引擎里了，但参数还是给开发者留了不少口子。

三、什么时候该从 HQ 切到 Lite

不是每一个项目都要用 Lumen Lite。PC 顶配、PS5、Xbox Series X，继续 HQ 通常没问题。但以下几种情况，你可以认真考虑切：

• 目标平台是 Switch 2、Steam Deck、核显 PC，或者手游级 SoC；
• 项目追求 60 帧，而 HQ 在目标机上稳不住；
• 场景以室内、峡谷、洞穴为主，间接光不需要极高精度；
• 美术风格偏向风格化、非写实，少量漏光反而能接受；
• 同一份代码要同时跑主机和掌机，不想维护两套光照管线。

下面这张流程图是我跟老陈一起画的，用来在项目里做决策：

flowchart TD
    A[项目开始用 Lumen HQ] --> B{目标平台是否包含 Switch 2 / 掌机 / 低端 PC?}
    B -->|是| C[在目标机上 profile GI 开销]
    B -->|否| D[继续 HQ，必要时调 r.Lumen.ScreenProbeGather 参数]
    C --> E{GI 占帧时间是否超过 3ms?}
    E -->|是| F[切到 Lumen Lite]
    E -->|否| D
    F --> G[调整 probe 密度与遮蔽强度]
    G --> H{画面是否可接受?}
    H -->|是| I[锁定 Medium GI Quality，写进 DefaultDeviceProfiles]
    H -->|否| J[检查是不是反射 / 直接光背锅，别错怪 GI]
    J --> K[针对性优化 SSR、阴影、LOD]
    K --> H

这里有个坑要避开：很多人看到帧率低，第一反应就是「Lumen 太贵，切 Lite」。但实际上 SSR、接触阴影、Nanite 三角形数、贴图带宽，都可能是真凶。切 Lite 之前，先用 stat gpu 和 RenderDoc 确认一下 GI 到底吃了多少。

老陈他们第一次切完 Lite，帧率是上来了，但画面还是脏。后来发现是 SSR 在掌机模式开太高了，跟 Lumen 没关系。把 SSR 质量降了一档，HQ 其实也能跑 45 帧。不过发行商要 60，最后还是锁了 Lite。

四、平台配置与 Console Variables

UE5.8 里没有单独的「Lumen Lite」开关。你只要把 Global Illumination Quality scalability 设成 Medium，或者用控制台命令 sg.GlobalIlluminationQuality 1，就会自动切到 Irradiance Final Gather。

对应的 CVar 是 r.Lumen.FinalGatherMethod：

• 0：Irradiance Final Gather，也就是 Lite；
• 1：Screen Space Radiance Cache，对应 High Quality；
• 2：Hardware Ray Tracing Final Gather，高端光追。

反射方面也要注意。Medium Reflections（sg.ReflectionQuality 1）会禁用 Lumen Reflections，改成 SSR 加粗糙 specular。所以 Lite 模式下，镜面反射质量会掉，光滑地面、水面、金属上的反射不再走 Lumen，而是走屏幕空间。如果你的项目靠镜面反射吃饭，这里要额外评估。

我们项目里的 DefaultEngine.ini 大概是这样配的：

[/Script/Engine.RendererSettings]
r.ReflectionMethod=1
;r.Lumen.Reflections.Allow=1  ; 掌机模式关闭 Lumen Reflections

r.Lumen.FinalGatherMethod=0
r.Lumen.DiffuseIndirect.Allow=1
r.Lumen.ScreenProbeGather.RadianceCache.ProbeResolution=16
r.Lumen.ScreenProbeGather.RadianceCache.NumProbesToTraceBudget=300
r.Lumen.ScreenProbeGather.IrradianceFormat=0

[ConsoleVariables]
; Switch 2 手持模式
Switch_Handheld.sg.GlobalIlluminationQuality=1
Switch_Handheld.sg.ReflectionQuality=1
Switch_Handheld.r.ScreenPercentage=83

; Switch 2 底座模式
Switch_Docked.sg.GlobalIlluminationQuality=2
Switch_Docked.sg.ReflectionQuality=2
Switch_Docked.r.ScreenPercentage=100

; 低端 PC
PC_Low.sg.GlobalIlluminationQuality=1
PC_Low.sg.ReflectionQuality=1

这段配置不到五十行，但把三个平台的档位都分开了。底座模式保留 HQ，手持模式切 Lite，低端 PC 也走 Lite。同一套内容，三套性能预算，靠 Device Profile 切换。

五、Switch 2 60 帧实战

Switch 2 的 GPU 性能跟 PS5 差距明显，但 Epic 官方文档确实把 Lumen Lite 当成 Switch 2 跑 60 帧动态 GI 的方案，包括掌机模式。老陈的目标很清晰：16.67 毫秒一帧，GI 不能超过 2.5 毫秒。

他们用了几个具体手段：

1. 把 Lumen 计算分辨率降下来

r.Lumen.ScreenProbeGather.DownsampleFactor 默认是 1，Switch 2 上我们改成 2。Final Gather 以半分辨率跑，再插值回来。间接光低频，半分辨率几乎看不出。

2. 控制 probe 数量

r.Lumen.ScreenProbeGather.RadianceCache.NumProbesToTraceBudget 从默认的 512 压到 300。Probe 少了，更新轻了，漏光风险会稍微增加，但帧时间实打实少了 0.8 毫秒。

3. 减少 screen probe 的 trace 距离

r.Lumen.ScreenProbeGather.MaxTraceDistance 默认很大，Switch 2 上没必要。室内场景 50 米足够了，远处间接光用天空球补。这个参数对性能影响很明显。

4. 关 Lumen Reflections，让 SSR 顶上

掌机模式 sg.ReflectionQuality 1 会自动关掉 Lumen Reflections。SSR 成本低很多，光滑表面会有屏幕空间反射，边缘缺失的问题靠 TAAU/TSR 抹一下，玩家看不出来。

调完之后，中文字幕洞里一个典型镜头：Lumen HQ 吃 4.2 毫秒，28 帧；Lumen Lite 吃 1.9 毫秒，56 帧。画面差距主要是远距离细节和金属反射，整体氛围还在。

六、渲染管线的时序

为了理解这些参数在帧里是怎么跑的，我跟老陈画了一张序列图。图里简化了不少，但关键步骤都在：

sequenceDiagram
    participant CPU as 游戏线程
    participant RHI as RHI / GPU 调度
    participant GBuffer as GBuffer Pass
    participant Depth as Depth Buffer
    participant Probes as Probe Placement & Update
    participant Irr as Irradiance Compute
    participant Occ as Probe Occlusion
    participant FG as Final Gather
    participant Comp as Composite / TSR

    CPU->>RHI: 提交场景裁剪与 Draw Calls
    RHI->>GBuffer: 基础 Pass：Base / Normal / Roughness
    GBuffer->>Depth: 输出 Depth
    RHI->>Probes: 根据可见像素放置 Radiance Cache Probes
    Probes->>Irr: 计算每个 Probe 的 Irradiance
    Irr->>Occ: 执行 Probe Occlusion Test
    Occ->>FG: 半分辨率 Irradiance Final Gather
    FG->>Comp: 合并直接光、间接光、SSR、反射
    Comp->>RHI: TSR / FSR 上采样到目标分辨率
    RHI->>CPU: 帧结束，Present

从这张图能看到，Lumen Lite 把「追踪」这件事前置到了 probe 更新阶段，而不是每个像素都去追。像素阶段只查表、插值、合成，所以 GPU 的压力小很多。CPU 这边也没什么额外负担，probe 的放置和更新都在 GPU 上完成。

七、视觉质量对比：哪些地方会露馅

Lumen Lite 不是免费午餐。画面差异主要集中在几个方面：

细节丢失：墙角、缝隙、细小几何体附近的间接光会比较糊。HQ 能追到一根管子的遮挡，Lite 靠 probe 插值，精度受 probe 密度限制。

漏光：Probe occlusion 能挡住大部分，但快速移动的物体、复杂室内结构、薄墙仍然可能漏。老陈他们山洞里有几处薄木栅栏，Lite 下光线会穿过来，最后加了一层厚度才解决。

反射降级：Medium Reflections 走 SSR，离开屏幕的反射信息就没了。金属走廊、镜面地面会明显变弱。

动态光源响应延迟：Probe 更新不是逐帧全量重建，快速变化的光源可能会有半帧到一帧的延迟。爆炸、闪电这种效果要配合直接光和粒子，别指望间接光立刻跟上。

不过，对于 60 帧掌机游戏，这些妥协通常可以接受。玩家更在意帧率稳不稳、操作跟不跟手。间接光氛围在，细节差一点，问题不大。

八、平台关系与项目选型

下面这张图把不同平台和 Lumen 档位的对应关系画了出来，方便跟策划、美术开会时讲道理：

graph LR
    A[Lumen 全局光照] --> B[Lumen High Quality]
    A --> C[Lumen Lite]
    B --> D[PS5 / Xbox Series X\S]
    B --> E[高端 PC]
    B --> F[Switch 2 底座模式可选]
    C --> G[Nintendo Switch 2 手持]
    C --> H[Steam Deck]
    C --> I[低端 PC / 核显]
    C --> J[风格化 / 60 帧项目]

    style C fill:#2d3748,stroke:#4a5568,stroke-width:2px,color:#fff
    style G fill:#1a365d,stroke:#2b6cb0,stroke-width:2px,color:#fff

HQ 和 Lite 不是替代关系，是同一套系统在不同预算下的两个表现。PC 上你可以做画质档位，主机上你可以做底座 / 手持切换，掌机上你可以直接默认 Lite。项目规划阶段就要想清楚：哪些平台必须 60 帧，哪些平台允许 30 帧，哪些平台可以关 Lumen 用烘焙。

老陈的团队最后定了一个原则：主机和 PC 用 HQ，Switch 2 手持强制 Lite，Steam Deck 默认 Lite 但允许玩家手动开 HQ（代价是帧率不稳）。这样美术只需要审一次内容，程序不用维护两套资产。

九、一个具体的调试流程

如果你也打算在项目里试 Lumen Lite，我建议按这个顺序来：

第一步，确认你真的在 Lite 模式。控制台输入 sg.GlobalIlluminationQuality 1，然后 r.Lumen.FinalGatherMethod 应该显示 0。不是 0 的话，检查 scalability 配置有没有被覆盖。

第二步，开调试视图。Lumen irradiance cache visualize 1 能看到 probe 分布。红色 probe 卡在几何体里，说明那里可能漏光或者缺光。绿色 probe 是被自动修正过的。

第三步，用 stat gpu 看 Lumen 和 Indirect Lighting 的耗时。如果还是高，逐个调 DownsampleFactor、NumProbesToTraceBudget、MaxTraceDistance。

第四步，对比 HQ 和 Lite 的截图。把同一个镜头两个模式各截一张，放大看墙角、金属、远景。让美术一起审，确定哪些差异能忍，哪些要修。

第五步，把最终参数写进 Device Profile，不要靠控制台命令上线。上线后玩家手动改 CVar 的不多，设备配置文件才是稳定的基础。

十、几个容易踩的坑

开了 Lumen Lite 不代表万事大吉。实际做的时候你会发现，有些地方特别容易翻车。

坑一：以为是 GI 的问题，其实是反射在捣乱。

很多人切到 Lite 之后，看到画面变差就怪间接光。其实 Medium Reflections 把 Lumen Reflections 关了，光滑表面的反射从屏幕空间取，质量掉得比 GI 还明显。老陈的团队最初就犯了这个错，把 GI 参数来回调，最后发现是金属地面的 SSR 分辨率太低。把 r.SSR.Quality 从 4 调到 3，再补一点粗糙度 bias，画面反而回来了。

坑二：probe 密度不够，墙角全糊。

室内场景如果 probe 放得太稀疏，墙角、门洞、家具边缘的间接光会变成一坨。调试视图里看到大片区域没有绿色 probe，就要考虑降 r.Lumen.ScreenProbeGather.DownsampleFactor 或者提高 probe 预算。这里要算笔账：probe 多了画质好，但帧时间涨；少了省性能，但糊。没有统一答案，只能逐个镜头调。

坑三：薄墙漏光，靠美术加厚模型解决。

Lite 的 probe occlusion 对厚墙有效，薄栅栏、门板、布帘这种单面或者很薄的物体容易漏光。老陈他们山洞里的木栅栏就是典型。最后美术把栅栏模型加厚了一倍，程序侧不用改任何参数，漏光就消失了。这种修法的成本比改 CVar 低。

坑四：Device Profile 优先级被覆盖。

有时候你在 DefaultEngine.ini 里配好了 Switch_Handheld.sg.GlobalIlluminationQuality=1，进游戏却发现没生效。大概率是 DefaultGameUserSettings.ini 或者代码里某处调了 sg.GlobalIlluminationQuality。上线前最好全局搜一下，把所有改 scalability 的地方列个清单。

坑五：只测静态镜头，没测移动镜头。

Probe 更新有开销预算，相机快速转动或者角色高速移动时，probe 分布会跟着变。如果更新跟不上，画面会出现一闪一闪的间接光变化。Switch 2 上我们限制了相机最大角速度，同时把 r.Lumen.ScreenProbeGather.TemporalInterpolation 打开，让变化平滑一些。

十一、内存与带宽：Switch 2 上的另一道坎

帧时间只是性能的一部分。Switch 2 的内存带宽比 PS5 小很多，Lumen Lite 虽然减少了计算，但 probe 缓存、辐照场纹理、深度缓冲这些资源照样占带宽。

老陈他们测下来，Lumen Lite 在 Switch 2 上大概要多占 30 到 45 MB 显存，主要花在 Radiance Cache 和 Irradiance Field 上。这个数字比 HQ 小，但也不算零成本。如果你的项目内存已经吃紧，开 Lite 之前要算一下总账。

带宽方面，probe update pass 会读写一些 3D 纹理。Switch 2 的 LPDDR5X 带宽有限，密集树林里大量 probe 同时更新时，带宽占用会往上跳。解决办法有几个：

• 限制 r.Lumen.ScreenProbeGather.RadianceCache.ProbeResolution，从 32 降到 16，缓存大小直接减到四分之一；
• 降低 NumProbesToTraceBudget，减少每帧要更新的 probe 数量；
• 避免在单屏内塞太多细小动态物体，动态物体越多，probe 重排越频繁。

我还见过一个项目，开了 Lite 之后帧率达标，但转场景时卡顿。后来查出来是probe 缓存没有预热，切场景第一帧要临时分配大量资源。他们把关卡切换时预渲染一帧黑屏，让 Lumen 先把 probe 布好，卡顿就消失了。

十二、写在最后

UE5.8 的 Lumen Lite 对中低端平台来说是一剂及时的止痛药。它没走简单降参数的路子，而是换了一条更便宜的算法路径。Irradiance fields 加 probe occlusion 这套组合，让 Switch 2 跑 60 帧动态 GI 从「不可能」变成了「得调」。

老陈的项目上个月通过了发行商的验收。山洞那关掌机模式 60 帧，间接光还在，美术总监也没再摔键盘。他说：「这功能早两年出来，我们能少熬不少夜。」

对于同时做主机、掌机、PC 的团队，Lumen Lite 最大的价值是让你不用为了性能把 Lumen 整个关掉。你可以 keep the look，只是换了一种更省的方式算。这跟过去 UE5 早期「要画质就没帧率，要帧率就关灯」的窘境相比，已经是很大的进步。

它也有自己的边界。镜面反射、细小遮挡、快速变化的光源，都会暴露 Lite 的短板。评估的时候别只看平均帧，要看最差镜头、漏光最严重的角落、玩家停留最久的区域。

做跨平台项目，最忌讳的是程序一个人闷头调参数，调完甩给美术验收。Lumen Lite 的画质取舍需要程序和美术一起定，哪些细节可以糊、哪些反射可以没、哪些墙角必须准，都是艺术决策，不是纯技术问题。老陈后来每周开一次「光照取舍会」，程序和美术各带一版参数，现场投票，效率反而比来回踢皮球高得多。

UE5.8 是 UE5 最后一个大型版本，Lumen Lite 算是 Epic 留给中低端平台的一份礼物。用好了，主机、掌机、低端 PC 能共用同一套动态光照管线；用不好，它就是另一个让你熬夜调参数的坑。工具始终只是工具，关键还是看用的人有没有把性能预算和画面目标对齐。

如果你正在纠结要不要给项目开 Lumen Lite，我的建议很简单：先在 Switch 2 或最低配 PC 上跑十分钟，把 sg.GlobalIlluminationQuality 1 输进去，再拿 stat gpu 看数字。数字不会骗人，眼睛也不会。两者都对得上，再往下调参数。