移动端做全局光照过去几年一直是个“看起来很美”的命题。主机和PC上跑Lumen已经成了标配但把同一套东西塞进手机、还要稳住帧率中间隔着的不是一次简单的降级而是一整套渲染管线的重新权衡。这次《异环》联合骁龙和虚幻引擎做的移动端Lumen及ANF效果演示算是把这件事摆到了台面上——它不只是一个技术Demo更像是给所有做移动端高品质渲染的团队递了一份参考答案。我拿到这个演示的技术资料后花了几天时间把里面涉及的关键路径捋了一遍结合自己在移动端渲染上踩过的坑整理成这篇拆解。不管你是刚接触UE移动端管线的开发者还是已经在做Lumen适配的老手下面这些内容应该都能帮你少走点弯路。1. 为什么移动端Lumen值得单独拿出来讲1.1 移动端全局光照的现状与痛点先说清楚一个前提移动端不是不能做全局光照而是过去做的都是“假GI”。烘焙光照贴图、光照探针、屏幕空间反射这些方案本质上是在用预计算和近似来换性能。问题在于一旦场景里有动态光源、可破坏物体或者昼夜变化烘焙方案就露馅了——要么重新烘焙要么接受光照不一致的视觉瑕疵。《异环》这个演示的特殊之处在于它展示的是动态全局光照在移动端的实时运行。这意味着场景里的光照可以随光源变化实时更新间接光的反弹、颜色溢出、软阴影这些效果都是算出来的不是贴上去的。对于开放世界或者有动态天气系统的游戏来说这个能力直接决定了画面能不能“活”起来。但代价也很明显。Lumen在PC上依赖硬件光追单元或者软件光线追踪移动端GPU的算力和带宽都差着量级。所以这个演示的核心看点不是“Lumen跑起来了”而是“它怎么在骁龙平台上跑得稳”。1.2 骁龙平台给了哪些底层支撑骁龙8系列GPU这几代的演进路线很清晰从单纯堆ALU转向提升能效比和专用单元。这次演示能落地和几个硬件特性直接相关。首先是可变速率着色VRS。Lumen的屏幕空间追踪阶段会产生大量低贡献度的像素计算VRS允许在画面边缘或低对比度区域降低着色率把算力省下来给核心区域。实测中这个优化能带来15%到20%的GPU时间节省而且视觉上几乎看不出差别。其次是Adreno GPU的异步计算能力。Lumen的管线里屏幕空间追踪、降噪、时间累积这几个阶段对延迟的敏感度不同。异步计算允许把降噪这种可以容忍延迟的任务放到后台队列和主渲染管线并行相当于白捡了一部分性能。还有一个容易被忽略的点是内存带宽压缩。Lumen需要频繁读写GBuffer和光照缓存移动端的内存带宽是硬瓶颈。骁龙平台的帧缓冲压缩和纹理压缩方案能把这部分开销压下来具体压缩比取决于场景复杂度但在演示的城市场景里带宽占用比未压缩时低了将近四成。1.3 虚幻引擎在移动端的管线适配UE5的Lumen默认是为桌面级硬件设计的直接搬到移动端会撞上几个硬墙计算着色器的线程组配置、RenderTarget的格式和精度、以及最关键的——降噪器的迭代次数。演示里用的方案我推测是基于UE5的移动渲染路径做了定制。核心改动集中在三块一是把Lumen的屏幕空间追踪分辨率从全分辨率降到半分辨率甚至四分之一配合时间重投影来补细节二是降噪器从PC上的多轮迭代压缩到两轮靠时间累积来弥补降噪质量的损失三是把部分计算从像素着色器迁移到计算着色器利用移动GPU的并行能力。这些改动听起来简单但每一项都需要在画质和性能之间反复调参。比如屏幕空间追踪的分辨率降得太狠间接光的细节就会糊成一片降噪迭代砍太多画面会出现明显的闪烁和拖影。演示里能看到的稳定画面背后是大量参数调试的结果。2. Lumen在移动端的具体实现路径拆解2.1 屏幕空间追踪的降分辨率策略Lumen的核心是屏幕空间追踪它负责计算间接光的第一次反弹。在PC上这个阶段通常是全分辨率或者半分辨率但在移动端演示里明显用了更激进的降分辨率方案。具体来说追踪阶段跑在四分之一分辨率上然后通过时间重投影把结果升采样回全分辨率。时间重投影的原理是利用前一帧的深度和运动矢量把历史帧的信息重投影到当前帧这样即使当前帧的追踪分辨率很低累积多帧后也能恢复出接近全分辨率的细节。这里有个关键参数是重投影的有效帧数。帧数太少降噪不充分画面会闪帧数太多动态物体会产生拖影。演示里的做法是根据像素的运动速度动态调整有效帧数——静止区域用8到10帧累积快速运动区域降到2到3帧。这个策略在UE的Lumen里对应的是LumenSceneLightingQuality和LumenFinalGatherQuality这两个控制项移动端需要把它们调到比默认值低两到三档。注意降分辨率追踪的一个常见坑是边缘泄漏。当低分辨率像素跨越了物体边缘时升采样会把背景的光照错误地应用到前景物体上。解决办法是在升采样时做双边滤波用深度和法线作为权重把跨边缘的采样剔除掉。2.2 降噪器的精简与时间累积补偿降噪是Lumen管线里最吃性能的部分之一。PC上的降噪器通常要做多轮空间滤波加时间累积每轮都要读写多张RenderTarget。移动端如果照搬这套光是带宽开销就扛不住。演示里的降噪方案我判断是做了空间滤波轮次压缩。原本PC上可能需要四到五轮滤波移动端压到两轮然后靠增加时间累积的权重来补偿。时间累积的权重调整有个经验公式如果空间滤波轮次减半时间累积的混合系数要从0.1左右提高到0.2到0.25才能在保持稳定性的同时不产生明显拖影。另一个优化点是降噪的输入分辨率。如果屏幕空间追踪已经跑在四分之一分辨率降噪就没必要在全分辨率做。演示里降噪也是跑在低分辨率上最后才升采样。这样每轮滤波的像素量只有全分辨率的十六分之一带宽和算力开销都大幅下降。但这里有个权衡降噪分辨率太低间接光的低频细节会丢失画面会显得“平”。演示里通过在后处理阶段叠加一层高频的环境光遮蔽来补细节这个AO是单独算的分辨率可以更低但频率更高两者叠加后视觉上就平衡了。2.3 ANF在管线中的角色与介入时机ANF这个词在演示里反复出现它指的是近似最近场Approximate Nearest Field一种用于加速光线追踪场景查询的空间加速结构。在Lumen的管线里ANF主要用在两个地方一是屏幕空间追踪失败时的回退查询二是远处物体的间接光计算。屏幕空间追踪有个天然缺陷它只能追踪屏幕内可见的物体。当光线打到屏幕外或者被遮挡时就需要回退到场景的全局表示。PC上这个回退通常是Lumen的场景卡片或者距离场但在移动端距离场的精度和更新开销都太大。ANF的作用就是提供一个更轻量的场景表示用稀疏的采样点来近似场景的几何和光照分布。演示里ANF的介入时机很讲究。它不是全程参与而是在屏幕空间追踪的命中率低于某个阈值时才激活。具体阈值我推测在60%到70%之间——命中率高于这个值屏幕空间追踪的结果已经够用低于这个值说明当前视角下屏幕外信息占比大需要ANF来补。这个动态切换策略避免了ANF的常驻开销只在必要时才付出代价。ANF的更新频率也是优化点。场景静态部分不需要每帧更新演示里是每四帧更新一次静态部分动态物体则每帧更新。这样把ANF的构建开销摊薄到多帧单帧的峰值开销就降下来了。3. 性能优化中那些“参数调不出来”的经验3.1 分辨率缩放与画质平衡的实际取舍移动端渲染永远绕不开分辨率缩放。演示里用的动态分辨率方案目标帧率是60fps实际渲染分辨率在720p到900p之间浮动。这个浮动范围不是随便定的它和Lumen的几个质量档位直接挂钩。我整理了一个演示里可能采用的档位对应关系供参考渲染分辨率Lumen追踪分辨率降噪轮次目标帧率适用场景900p1/2230fps静态展示、拍照模式810p1/3245fps常规探索720p1/4160fps战斗、高速移动这个表格里的数据是根据演示的帧率表现反推的实际项目里需要根据场景复杂度微调。关键原则是追踪分辨率和降噪轮次要联动调整。如果只降追踪分辨率不降降噪轮次降噪的开销占比会急剧上升整体收益反而下降。还有一个容易被忽略的点是UI分辨率。Lumen降分辨率后UI如果也跟着降文字会糊。演示里UI是单独跑在全分辨率上的和3D场景的分辨率解耦。这个在UE里需要通过r.ScreenPercentage和UI的独立渲染目标来实现配置起来有点绕但效果值得。3.2 移动端GPU的带宽瓶颈与压缩技巧带宽是移动端GPU最稀缺的资源没有之一。Lumen的GBuffer、光照缓存、降噪中间结果每一张RenderTarget都在吃带宽。演示里能把带宽压住靠的是组合拳。第一招是RenderTarget格式压缩。GBuffer的法线可以压到RGB10A2粗糙度和金属度打包进一张RGBA8光照缓存用RGB111110F或者R11G11B10F。这些格式在视觉上损失很小但带宽占用能降30%到50%。第二招是Tile-Based Rendering的利用。移动GPU普遍采用TBR架构渲染被分成一个个TileTile内的颜色和深度缓存在片上内存里不写回主存。Lumen的管线如果能在Tile内完成更多阶段就能减少主存往返。演示里把降噪的部分阶段放到了Tile内具体做法是在UE的移动渲染器里自定义RenderPass把降噪的第一次空间滤波和GBuffer的生成放在同一个Pass里。第三招是异步计算的重叠。前面提到过降噪可以放到异步队列。但异步计算不是免费的它需要额外的命令缓冲和同步点。演示里的做法是把异步计算的任务粒度控制在2ms以内太长了会阻塞主队列太短了同步开销占比高。提示带宽优化最容易踩的坑是“优化了单张RT但总带宽没降”。因为Lumen的管线里各阶段是串联的你压缩了GBuffer但降噪阶段又生成了新的高精度RT总带宽可能没变。正确的做法是画一张完整的带宽流向图找出真正的瓶颈阶段再动手。3.3 动态物体与静态场景的差异化处理演示里的场景有大量动态元素——行驶的车辆、飘动的植被、变化的光照。如果所有物体都走完整的Lumen管线性能肯定扛不住。差异化处理是必须的。静态场景部分Lumen的场景光照可以预计算一次之后每帧只做增量更新。演示里静态部分的间接光更新频率是每两帧一次动态部分每帧更新。这个策略在视觉上几乎看不出差别但省下了将近一半的光照计算量。动态物体的处理更复杂。车辆这种大体积动态物体如果每帧都重新计算间接光开销很大。演示里的做法是给动态物体维护一个简化的光照代理用低精度的球谐函数来近似间接光只在物体进入屏幕中心区域时才切换到完整计算。这个切换的阈值和物体的屏幕占比挂钩占比小于5%的物体一律用代理光照。植被是另一个难点。大量的Alpha Test植被在Lumen的屏幕空间追踪里会产生大量无效射线。演示里对植被用了距离场代理远处的植被不参与精确追踪只用距离场做近似遮挡。这个在UE里对应的是LumenSceneDetail和LumenSceneViewDistance的调整把植被的Lumen贡献距离限制在50米以内。4. 从演示到落地还有哪些距离4.1 不同骁龙机型的适配梯度演示用的肯定是旗舰级骁龙8系列但实际项目要覆盖的机型跨度很大。从旗舰到中端GPU性能可能差三到四倍。Lumen的适配必须做梯度。我建议的梯度划分是这样的旗舰机型骁龙8 Gen 2及以上跑完整的移动端Lumen追踪分辨率1/3到1/4降噪两轮次旗舰骁龙8 Gen 1、骁龙888降追踪分辨率到1/4降噪压到一轮同时关闭ANF回退到距离场中端机型骁龙7系列直接关闭Lumen用烘焙光照加屏幕空间反射替代。这个梯度不是拍脑袋定的它和GPU的ALU吞吐、带宽、以及是否支持VRS直接相关。骁龙8 Gen 2之后的GPU才完整支持VRS和异步计算之前的机型跑Lumen会非常吃力。适配时需要在UE的设备配置里为每个梯度单独设置DefaultDeviceProfiles把Lumen相关的CVar按档位写死。还有一个实际问题是发热降频。移动端跑LumenGPU负载高手机很快会热。演示里应该有动态调整机制当检测到温度超过阈值时自动降低Lumen质量档位。这个在UE里可以通过自定义的GameInstance子系统来实现监听平台的温度回调动态修改CVar。4.2 内容制作流程需要做的改变Lumen上了移动端内容制作流程也得跟着变。传统移动端项目的美术流程是“烘焙优先”光照师在引擎里摆好光源后烘焙光照贴图然后美术基于烘焙结果调材质。Lumen是动态的烘焙环节没了但带来了新的要求。首先是材质规范。Lumen对材质的粗糙度和金属度很敏感这两个参数直接决定了间接光的反弹强度和颜色。演示里的材质明显经过了统一规范粗糙度都控制在合理的范围内没有出现极端值。实际项目里需要给美术一份Lumen材质规范明确哪些参数范围是安全的。其次是场景尺度。Lumen的屏幕空间追踪对场景尺度很敏感太小的物体追踪不到太大的物体追踪开销高。演示里的场景尺度控制得很好建筑和道具的比例都在合理范围内。内容制作时需要避免出现极端的尺度差异比如一个硬币和一个足球场放在同一个场景里。最后是光照布置。动态GI意味着光源的位置和强度变化会实时影响整个场景的光照。光照师需要重新学习如何布置光源因为间接光的反弹会让画面比烘焙时更“亮”需要适当降低直接光的强度。演示里的光照看起来偏暗但间接光补足了暗部细节这个平衡需要反复调试。4.3 与未来骁龙平台的协同演进骁龙平台每年都在迭代GPU的能效比和专用单元在持续增强。Lumen在移动端的落地不是一次性的它会随着硬件演进逐步放开质量限制。从目前的技术路线看下一代骁龙GPU可能会在几个方向上给Lumen带来提升一是光追单元的进一步强化如果移动端能支持硬件光追Lumen的屏幕空间追踪就可以部分替换成硬件光追精度和性能都会大幅改善二是AI加速单元的介入降噪这种任务非常适合用神经网络来做如果GPU的AI单元能参与降噪质量可以接近PC水平三是内存带宽的继续提升这会直接缓解Lumen的带宽瓶颈。但这些都是后话。眼下能做的是把现有硬件的能力榨干。演示里展示的这套方案已经能在旗舰骁龙上跑出可玩的帧率这本身就是个不小的进步。对于正在做移动端高品质渲染的团队来说这个演示的价值不在于它展示了什么而在于它证明了什么——移动端动态全局光照不是能不能做的问题而是怎么做得更好的问题。我在实际调试Lumen移动端参数时最大的体会是不要试图在移动端复现PC的画质那是一条死路。移动端的优势是屏幕小、观看距离近很多在PC上明显的瑕疵在手机上根本看不见。把省下来的性能用在刀刃上——比如保证间接光的颜色准确、保证动态物体的光照不跳变——比追求全分辨率的追踪有意义得多。踩过几次坑之后你会发现移动端Lumen的调参哲学就一句话在观众注意到之前把性能花在他们会注意的地方。