UE4 工程整包迁到 UE5 以后，场景不过几秒钟就出现墙面、地面高光一阵一阵的明暗跳动，阴影边缘还会像爬虫一样在网格缝里蠕动。这种问题我接过不止一次，团队第一反应往往是检查模型、查材质、怀疑显存坏了。实际上，这类闪烁九成以上是 UE4 工程旧的灯光参数、烘焙数据在新光照管线里被重新解读后导致的兼容性冲突。这篇文章把一次完整的排查过程摊开讲，从现象分类、参数语义差异到批量修复和验证，一步一步过一遍，希望能帮正在做迁移或准备做迁移的朋友少走弯路。

1. 现象与背景：迁移后的“闪烁”到底在闪什么

1.1 闪烁最常见的三种形态

先别急着改参数，第一步得先搞明白我们说的“闪烁”是哪种视觉现象。我遇到过的迁移闪烁基本分成三类：

• 第一类是时域噪点，最典型的是高光区域出现颗粒状白色噪点，静止不动也会像老电视雪花一样闪。这种往往是抗锯齿方案切换（UE4 的 TAA 换成 UE5 的 TSR）之后，亚像素细节被过度放大的结果。
• 第二类是明暗脉冲，整个场景或者某个局部区域以几帧为周期忽明忽暗，像灯光在快速呼吸。这种多是因为自动曝光系统被局部高亮点干扰，每帧都在重新适配亮度范围。
• 第三类是阴影网格跳动，阴影边缘在物体表面慢慢游动，在法线细节较多的地面上尤其明显。这种基本是阴影算法从传统级联阴影切到 UE5 虚拟阴影贴图（Virtual Shadow Map）后，偏移参数、精度分配逻辑和旧项目不匹配。

这三种形态经常同时出现，但原因是不同的，排查路径也完全不同。所以我习惯打开项目后的第一件事不是翻灯光，而是先录一段视频、截几张图，把闪烁发生的具体位置和节奏记录下来，避免后面被“重新打开又好了”这种假象干扰。

1.2 为什么 UE4 工程一到 UE5 就“废掉”

要解释这个问题，得先承认一个事实：UE5 的光照渲染逻辑和 UE4 有本质差异，不只是版本号变了。

UE4 默认情况下，静态光照靠 Lightmass 烘焙，动态光影靠 Shadow Map，两者井水不犯河水。而 UE5 默认开启 Lumen 全局光照，它是一套基于软件光线追踪的实时 GI 系统，处理光照的方式几乎完全不同。与此同时，阴影系统也换成了按屏幕分辨率动态分配精度的虚拟阴影贴图，抗锯齿换成了时间超分 TSR，连灯光强度的物理单位都被重新定义过。

也就是说，老工程并不是坏了，而是里面的每一份旧资源都在用“语法正确但语义不同”的方式被解读。举例来说，UE4 里点光源的强度数值往往是为了美术效果凑出来的，U4 工程很多还会手动关掉平方反比衰减；到了 UE5，光源强度会被当成物理照度单位来理解，平方反比衰减默认启用，一个在 UE4 里看起来正常的光源，在 UE5 里可能变成局部过曝的光弹。加上曝光学参数、GI 参数、阴影参数全变了，旧工程量越大、灯光重叠越复杂，闪烁就越严重。

2. 排查思路：先定位，再谈修复

2.1 用二分法快速剥洋葱

面对闪烁问题，我的第一原则是：永远不要在大场景里直接调参数，一定要先把问题范围缩小到一个可以控制的最小场景。

具体做法是：把项目复制一份，在副本里打开出问题的关卡，然后按层级把无关的静态网格体全部隐藏，只留下地面、一堵墙和一个最有代表性的道具物体。灯光先全部隐藏，再一个接一个打开，观察哪一个灯打开后闪烁开始出现。这个方法虽然原始，但非常高效，尤其是大场景里面几十个光源互相影响，不做排除法根本不知道谁是元凶。

在隐藏灯光的同时，我还会做另一个对照实验：在场景中间临时放一个原生造型球（Sphere Mesh），给它一个标准材质，亮度数值取默认值。这个“标准球”是参考系，如果这个球也闪，说明是全局面光源、曝光、后处理的问题；如果球不闪而场景里的资产闪，说明是某个材质、模型或特定光源参数的问题。参考系的做法能省掉大量来回猜的时间。

2.2 区分编辑器闪烁和打包后闪烁

还有一个容易踩的坑：编辑器里闪烁不代表打包后也闪，反过来也一样。很多时序性闪烁问题只在实时渲染循环里出现，但编辑器里会叠加视图窗口、调试覆盖、离屏渲染等多种状态，表现和打包版本并不一致。

我遇到过一种情况，编辑器视角下完全正常，打包给测试时室内部分开始高频闪烁。后来查下来是光照贴图在构建时没有重新生成，编辑器里用的纹理流送池和打包程序的处理方式不一样，旧的烘焙数据在发布版被读取后出现了异常的采样结果。所以排查时必须把编辑器表现和打包表现分开记录，最好用同一个固定机位各录一段慢动作视频对比，不要凭印象判断。

2.3 检查工程级渲染配置与插件兼容性

在进入灯光参数之前，先把这组配置认真过一遍，往往能直接发现问题：

• Project Settings → Rendering → Global Illumination Method：是 Lumen 还是 None/Lightmap。
• Reflection Method：是 Lumen 还是 Screen Space 或 None。
• Shadows：Virtual Shadow Maps 是否启用。
• Antialiasing Method：是 TSR 还是 TAA。
• Generate Mesh Distance Fields：是否勾选，距离场数据是否重新生成。
• 硬件光线追踪是否被意外打开，而项目原本没有按光追场景来设计。

顺便检查一下工程里有没有因为升级被禁用或半失效的光照类插件，比如某些旧的体积雾、光线追踪辅助模块。插件兼容问题经常伪装成灯光闪烁出现，尤其是那些在渲染线程里做了自定义处理的旧插件，禁用掉再测一下，闪烁可能直接消失。

3. 灯光参数的底层差异：为什么数值没变效果却天翻地覆

前面的排查如果能定位到“某个或某几个光源参与时闪烁更明显”，那核心工作就在这一节了。几乎所有迁移约 flash 的深层原因，都可以归结为几组参数的语义改变。

3.1 光源强度单位的重新定义

UE5 给非平行光引入了物理光照单位（Lumens、Candela、EV100），而 UE4 普通灯光默认是任意单位加简单衰减。迁移后旧数值会原封不动带过来，但它背后的“物理含义”已经变了。

举个例子：UE4 引擎里一个点光源强度设 5000，可能只是因为美术觉得“这个值调到五千看着亮”；放回 UE5，系统认为这个点光源以坎德拉为单位对外发光，配合平方反比衰减，离灯 2 米处的照度会急剧下降，而离灯 0.5 米内的表面则会瞬间过曝。结果就是场景里亮的地方刺眼，暗的地方一片死黑。此时自动曝光为了照顾全局，会在过曝的高光和死黑的暗部之间反复折中，表现出来就是整个画面明暗波动，也就是我们看到的脉冲式闪烁。

这里我给不出一个“乘以多少系数就搞定”的万能公式，因为每个项目的旧数值体系都不一样，尤其受旧工程是否关闭了物理衰减影响。但我推荐一个可靠校准法：先建一个空的测试关卡，用 UE5 默认的灯光创建一个标准照明环境，记下默认光源强度和实际画面亮度；然后把出问题的灯光逐盏搬进测试关卡，不断调整强度，直到亮度感受和 UE4 原版场景接近。批量处理时再用脚本按记录下来的换算系数统一改写，比手工一盏一盏调快得多。

3.2 平方反比衰减和衰减半径的连锁反应

UE4 很多项目为了布光方便，会把点光源、聚光灯的 Inverse Square Falloff（平方反比衰减）关掉，改用相对线性的衰减，同时把 Attenuation Radius（衰减半径）拉得很大，让灯光能照顾到更大的范围。这种“不讲物理但讲效果”的做法在 UE4 很常见，升到 UE5 后问题很严重。

UE5 的默认物理模型里，光的衰减更严格，强度随距离快速衰减。如果旧工程把衰减半径调得极大，多盏灯的贡献范围会大面积重叠，局部叠加亮度就可能超过曝光上限；再加上 Lumen 的实时 GI 会把这些高能量区域再次弹射到周围，形成亮度反馈循环，画面在几帧内跳来跳去就一点也不奇怪了。

处理方式分两步走。第一步，把所有光源的 Attenuation Radius 缩小到合理范围，原则是光源实际照亮范围覆盖半径的 1.5 到 2 倍即可，不要为了照顾远处细节无限拉大。第二步，把平方反比衰减统一打开，让场景回到物理衰减模型上。短期内画面会变暗，这恰恰是校准光源强度的最佳时机，按照前面说的测试关卡重新换算强度即可。

3.3 Lumen 烘焙光照与静态光照的叠加冲突

判断项目到底走哪条路，是迁移时绝对不能含糊的问题。

如果项目决定继续使用 UE4 风格的传统静态烘焙（Lightmap），那就要在项目设置里明确把 GI 设为非 Lumen，然后重新 Build Lighting。很多人迁移后不重新烘焙，老的 Lightmap 数据被 UE5 读取后会出现采样不一致，静态阴影和光照信息在低分辨率区域就会闪。这种情况下重新烘焙一次光照，能解决大量表面闪烁问题。

如果项目决定全面拥抱 Lumen，那就必须接受一个事实：所有移动性设为 Static 的光源在 Lumen 下没法产生正确的实时 GI。旧工程里大批摆在室内的 Static 补光，在 UE5 里会变成“看起来有光，但光不参与 Lumen 计算”的尴尬状态，场景亮暗信息断层，局部区域因此出现动态跳变。解决办法是把这些 Static 光源改成 Movable 或 Stationary，让 Lumen 能正确读取它们的能量贡献，再通过灯光强度和范围重新校准整体照明。

另外，Lumen 依赖 Mesh Distance Field 做软件追踪，升级后的工程如果距离场数据还是旧的，或者项目设置里 Generate Mesh Distance Fields 没打开，Lumen 的追踪结果就会产生大量时域噪声。菜单里 Build → Build Distance Fields，重新生成一次，效率会好很多。

3.4 虚拟阴影贴图与 Contact Shadow 参数

UE5 默认开启 Virtual Shadow Map 时，很多 UE4 时代的阴影参数会失效或表现完全不同。最典型的例子是 Directional Light 的 Cascade Shadow 相关设置，比如 Dynamic Shadow Distance、Shadow Cascades、Shadow Distance Scale，这些在老项目里为了性能和安全距离调过很久，但在 VSM 体系里它按屏幕分辨率动态管理所有阴影，老的级联逻辑只留下部分影响，边缘和远距离的阴影质量会变得飘忽。

如果场景里大量使用 Contact Shadow（接触阴影），迁移后更应该重点检查。UE5 的 VSM 精度分配和 UE4 不同，Contact Shadow Length 和 Contact Shadow Intensity 若沿用旧值，容易在模型细节密集处产生一帧有一帧没有的影子，尤其是法线贴图转折多的墙面、砖缝、地砖这些区域。我的经验是：旧项目的接触阴影长度经常偏大，迁移后先缩小 30% 到 50%，再把强度从默认 1.0 降到 0.5 左右，观察时域噪点是否降低。

3.5 自动曝光与后处理导致的“伪闪烁”

有一类闪烁和光源本身关系不大，纯粹是后处理系统在“抽风”。UE5 里的自动曝光使用 EV100 测光体系，和 UE4 的处理方式差异很大。旧场景里如果有几个局部高亮点——比如一个过亮的自发光材质、一盏没改衰减的灯、一个高光很强的金属面，就会让测光区域的平均亮度剧烈波动，表现在画面上就是整个视角忽明忽暗。

排查方法是先把 Post Process Volume 里的 Auto Exposure 关掉或者手动固定 Exposure Compensation，观察闪烁是否立刻停止。如果停止，说明问题在测光逻辑。这里我会把 Auto Exposure Method 设成 Manual 或固定 EV100 范围，然后把 Adaptation Speed Up 和 Adaptation Speed Down 放慢，让亮度变化更平滑。更稳的做法是检查场景里每一个发光材质和 Light Function，把所有过亮的高亮点控制回来，让测光区域的亮度分布更均匀——这属于治本。

4. 实操修复方案与验证流程

4.1 用脚本批量校准灯光强度与衰减半径

手工一盏一盏调光源在游戏场景里不现实，一次排查往往涉及几百盏灯。UE5 的编辑器 Python API 可以帮我们快速遍历场景里所有灯光，并按类型批量调整关键属性。下面是一个我实际用过的脚本思路，供参考：

import unreal actors = unreal.EditorLevelLibrary.get_all_level_actors() conversion_factor = 0.6 # 每盏灯独立的换算系数，根据测试关卡标定结果填入 for actor in actors: if isinstance(actor, unreal.PointLight) or isinstance(actor, unreal.SpotLight): # 读取旧强度 old_intensity = actor.get_editor_property('intensity') # 按换算系数更新强度 actor.set_editor_property('intensity', old_intensity * conversion_factor) # 修正衰减半径：对 UE5 物理衰减模型，范围不需要过大 actor.set_editor_property('attenuation_radius', 500.0) elif isinstance(actor, unreal.DirectionalLight): # 平行光在这里保持现有强度，但检查阴影参数 contact_shadow_length = actor.get_editor_property('contact_shadow_length') actor.set_editor_property('contact_shadow_length', contact_shadow_length * 0.6)

脚本写完先不要全场景跑，挑一盏灯手动试，对比测试关卡里的参考值，确认换算系数合理后，再批量执行，并在执行前用源码管理做好版本快照方便回滚。

4.2 光照构建与 Lumen 配置的参数清单

无论选烘焙还是选 Lumen，构建数据都要重新走一遍。继续烘焙路线的话，World Settings 里的 Lightmass 设置要重点检查这几项：

• Static Lighting Level Scale：建议调成 1，不要沿用 UE4 里为性能压缩的 2 或 4，否则光照贴图分辨率不够，大面积低亮区域容易闪。
• Num Indirect Lighting Bounces：建议 3 起步，场景大的可以到 5，反弹次数太少会让间接光在角落出现跳变。
• Indirect Lighting Quality：设到 4 以上，作为迁移后的基准值。
• 确认所有灯光的光照贴图分辨率（Lightmap Resolution）没有继承异常，静态网格体的 UV2 通道完整。

选择 Lumen 路线的话，项目设置里建议这样配置：

• Global Illumination Method：Lumen
• Reflection Method：Lumen
• Virtual Shadow Maps：开启
• Generate Mesh Distance Fields：开启并重建一次
• Final Gather Quality：至少 Medium，大场景用 High

Lumen 是实时系统，不需要预烘焙，但它需要稳定几何信息，如果场景里大量使用动态生成的网格体，或者有程序化生成的建筑模块，建议把这些对象的 Collision 和复杂性保持合理，避免 Lumen 追踪时产生大量无效计算——这也会间接导致 GI 噪点增多。

4.3 后处理与抗锯齿方案的取舍

抗锯齿方面，我不建议一上来就把 TSR 关掉。TSR 本身没问题，但它对移动物体、高光细节的时域累积更敏感，旧工程材质里大量高频法线细节、细小的高光纹理图案会在 TSR 下产生像素级闪烁。先尝试把屏幕百分比（Screen Percentage）从 100 调到 75 或 50，观察闪烁是否减少。如果确实减少，说明问题在于高频高光细节过密，与其关 TSR，不如降低材质 Specular 强度，或者给高光贴图加一点模糊，让亚像素细节不再那么极端。

后处理体积参数我建议统一过一次：Exposure Compensation 固定在一个合理值（比如 0 到 1），Auto Exposure Min/Max EV100 分别设置在合理的上下界，比如 -4 和 +8，限制曝光动态范围，避免个别过热点拖垮整个场景亮度。此外把 Bloom 的强度调回 UE4 工程原本的水平，这事经常被忽略——UE5 默认 Bloom 会增强高光，让闪烁显得更刺眼。

4.4 验证修复效果：视角、时段、打包三关

修复不经过验证等于没修。我会按下面三个维度做最终确认：

• 视角覆盖：在地图里放至少 6 个固定机位，覆盖室内、室外、朝向主光源、背向主光源、俯视大面积地表、仰视天花板等典型视角，每个机位录 30 秒视频，检查闪烁是否全部消失。
• 时间与光源变化：如果项目有日夜循环或者动态改变太阳方向的功能，要把一天内最关键的几个时间段都跑一遍，因为定向光角度变化会直接影响 VSM 精度分配和 Lumen 追踪结果，有些闪烁只在特定角度出现。
• 打包验证：编辑器里不闪远远不够，用 Development 配置打一个包，在目标平台上重新录视频，尤其注意阴影和 GI 在打包版本中的表现是否和编辑器一致。

在验证过程中，我还会用控制台命令做 A/B 对比，比如：

• r.Shadow.Virtual.Enable 0和1对比，定位 VSM 是否参与闪烁。
• r.Lumen.DiffuseIndirect.Allow 0和1对比，定位 Lumen GI 是否参与。
• r.AntiAliasingMethod 0或2对比，定位抗锯齿是否参与。

哪个命令能消除闪烁，元凶就在哪个系统里，这比盲猜参数高效得多。

5. 常见问题速查表与避坑心得

5.1 迁移闪烁问题速查表

5.2 容易被忽略的几个隐藏坑

第一，材质里用了高频法线贴图且 Specular 数值偏高，迁移后 TSR 会把这些细节当成时域噪声放大。严格来说不是灯光问题，但它看起来就是灯光在闪。排查灯光排查到一无所获时，把材质高光的“粗糙度映射”和“镜面反射强度”调低试试。

第二，引擎升级后“定向光默认强度”的具体数值不要依赖。UE4 和 UE5 对方向光强度的物理定义不同，如果场景里加了一个“新人心安理得放一个默认值”的定向光，它可能会变成 Lumen 系统里一个巨大的能量源，整个场景的曝光被这盏灯拽着走，闪烁也因此产生。正确的做法是自定义一个项目模板，把常用灯光数值固定成经过测量的标准值。

第三，升级前一定在 UE4 工程里把光照、距离场、Lightmap UV 全部重新构建一次再迁移。很多闪烁问题本质上是脏数据被 UE5 读取后以更高精度的算法暴露出来，重建一次能剔除大量隐患。虽然费点时间，但比迁过去以后再排查省太多力气。

5.3 迁移前值得建立的“基准板”习惯

经过这次排查，我最大的收获是建立了“基准板”工作流。具体做法是：在工程里单独建一个空关卡，放一排不同材质球体（纯白、金属、粗糙、自发光各一个），地面用普通网格片，加上一盏定向光、一盏点光、一盏聚光灯，所有参数用团队统一标准。迁移完新版本，先打开基准板看渲染表现，再进大场景。

基准板的价值在于：它把所有变量压缩到最小，一旦大场景出问题，先在基准板里复现同一现象，能快速判断是管线本身的默认行为变了，还是老场景里的个别参数导致。这个习惯我在后续好几个迁移项目里都用得上，遇到闪烁盲区，基准板几乎每次都能帮我找到抓手。

我个人在处理这类问题时还有一个小心得：不要执着于“完美还原 UE4 的画面”。UE5 的光照模型更接近物理真实，很多旧场景的布光做法本来就是靠非物理衰减和过曝来撑效果的，强行把闪烁修到彻底消失，画面也往往已经大变样。更好的思路是先接受新管线的默认语义，放弃旧参数，按新管线重新布一遍光，虽然前期工作量大，但得到的结果会更稳定，后续维护也不再是随时会爆的雷。先将每个光源的移动性、单位、衰减方式统一理顺，再精细化表现，这才是真正能落地的迁移策略。