最近在 UE5 项目里最容易出现的一个性能误区，是把“提高帧率”直接等同于“打开超分辨率”。不少团队遇到帧率不达标，第一反应就是开启 DLSS、TSR 这类后处理重建技术，寄希望于一个开关把 20 FPS 变成 60 FPS。这个想法本身没有错，但它低估了一件事：超分辨率解决的是“输出分辨率带来的 GPU 开销”，解决不了 CPU 瓶颈、DrawCall 过重、Gameplay 逻辑拖慢帧线程、资源流送卡顿这类更常见的问题。
这篇文章想给出的判断很明确：在 UE5 中要实现接近 3 倍帧率的提升，最可靠的路线不是求助于超分辨率，而是先诊断瓶颈，再从渲染管线、CPU 开销、帧率管理三个方向做整体优化。超分辨率可以作为最后一段画质恢复手段，但不应该成为性能问题的第一责任人。本文会围绕 UE5 自带的功能、控制台变量、命令行参数和性能分析工具，提供一套可以落地的通用优化流程。读者看完之后，至少能回答三个问题：当前项目的瓶颈到底在 CPU 还是 GPU；不借助超分技术时有哪些有效降载手段；优化之后如何验证 3 倍帧率目标是否达成。
先说清楚适用范围。本文讨论的是 UE5 项目，包含编辑器、打包后的可执行程序，也涉及常见的移动端和桌面端设置。不同 UE5 小版本的控制台变量会有些差异，但优化思路是通用的。文中代码和配置都以“先理解再使用”为前提，团队落地时应该以自己的项目版本和性能基准确认为准。
1. 先搞清楚：超分辨率能解决什么，不能解决什么
1.1 超分辨率的本质是后处理重建
超分辨率，包括常见的 TSR、DLSS、FSR、XeSS，核心目标是在低内部分辨率渲染的基础上，通过时序累积和空间插值重建出更接近高分辨率输出画面的效果。换句话说，它在做的事是“让低分辨率画面看起来像高分辨率画面”。这个技术方向与“图像超分辨率重建”属于同一类问题，例如医学影像中 AI 对 CT 超分辨率重建、安防视频中的监控图像超分辨率重建，本质上都是把低信息量图像补成高信息量图像。
但在游戏引擎里，超分辨率并不是原生的性能优化手段。它只是让引擎在更低的渲染分辨率下工作时，把画面的模糊感和锯齿控制在一个可接受范围内。真正的性能收益来自更低的内部分辨率，而不是超分辨率算法本身。所以如果一个项目 GPU 端开销本来就高，超分确实能降低像素着色压力；但如果项目卡在 Game 线程、RHI 线程或 CPU 逻辑上，超分几乎是帮不上忙的。
1.2 超分辨率解决不了的三大问题
结合 UE5 项目的实际表现，超分辨率对以下三类问题几乎无效。
第一类是 CPU 瓶颈。UE5 在大量 Actor、复杂蓝图、频繁 Tick、动态生成物体、路径寻路、物理和网络同步集中爆发时，多线程负载会压在 Game 线程上。此时哪怕 GPU 很空闲，帧率也上不去。打开超分只会让 GPU 更快完成渲染，但 CPU 依然在限制总帧耗。
第二类是 DrawCall 与渲染状态切换开销。移动端尤其明显，每帧提交的 DrawCall 数量如果超出平台承受范围，即使降低分辨率，RHI 线程的提交压力也不会显著下降。超分不会减少场景中静态网格体的数量，也不会减少材质变体和着色器状态的切换。
第三类是资源流送和加载卡顿。大世界项目里纹理流送、网格体流送、PSO 编译引起的卡顿，和分辨率没有直接关系。超分可以降低分辨率，却不能解决磁盘、内存带宽或者着色器编译造成的帧率尖刺。
| 问题类型 | 超分辨率是否能解决 | 更好的思路 |
|---|---|---|
| GPU 像素填充率不足 | 能降低内部分辨率，间接缓解 | 配合超分做整体画质预算 |
| CPU/Game 线程瓶颈 | 基本无效 | 优化蓝图、Tick、组件数量 |
| DrawCall 过重 | 效果有限 | 合并资产、减少材质变体 |
| 资源流送卡顿 | 基本无效 | 调整流送池和预加载策略 |
| PSO 编译卡顿 | 无效 | 预编译缓存，避免运行时编译 |
| 时间戳与帧率不稳定 | 无效 | 固定目标帧率，调整同步策略 |
1.3 3 倍帧率到底应该怎么理解
标题里的“3 倍帧率”如果只是简单地把 20 FPS 设置成 60 FPS 目标，那需要做的不是某个开关，而是一整套性能预算调整。更靠谱的理解方式是：先记录优化前每个阶段的帧耗时占比，然后针对耗时最高的模块做削减，直到总耗时降为原来的三分之一。例如原帧耗时 50ms，要提升到 16.7ms 左右，才算是达到 3 倍帧率目标。3 倍不是玄学，而是一个非常具体的性能预算数字。
2. UE5 性能优化的第一原则：先定位瓶颈，再动配置
2.1 用内置命令快速区分 CPU 和 GPU 瓶颈
UE5 编辑器运行时或打包程序中，按下键盘左上角的波浪键~可以打开控制台。控制台命令stat unit是最常用的诊断入口，它会显示一帧的 Game 线程耗时、Draw 线程耗时、GPU 耗时、RHI 线程耗时。通过分段对比，可以直接判断瓶颈在哪个线程。
stat unit stat game stat gpu stat rhi stat streaming如果显示Game耗时接近整帧耗时，说明 CPU/Gameplay 逻辑是瓶颈；如果GPU耗时接近整帧耗时，说明渲染负载是瓶颈；如果Draw或RHI耗时高，则需要关注渲染线程提交压力。真正开始优化之前，一定要先把这一行数据记录下来，否则后面优化很容易做到错误方向。
2.2 用 Unreal Insights 做更细粒度的性能分析
如果项目已经进入中期或后期，建议启用 Unreal Insights 做离线性能分析。UE5 支持通过命令行参数开启性能追踪，运行一段时间后会把数据导出到.utrace文件。在编辑器中可以打开 Window 菜单下的 Unreal Insights 界面，加载该文件后能查看到详细的耗时层级，包括每个 Actor 的 Tick 时间、每个渲染模块的耗时、内存分配情况、异步加载事件等。
UnrealEditor.exe "YourProject.uproject" -game -log -trace=default打开 Unreal Insights 后，可以重点看三类信息：
- Game 线程中耗时最高的函数或蓝图节点；
- RHI 线程提交的渲染命令数量；
- Streaming 线程中加载耗时较高的资源。
这一步的作用不是马上改配置，而是把优化目标从“凭感觉降低画质”转变成“根据证据削减具体模块耗时”。
3. 渲染层优化：不依赖超分辨率降低 GPU 负载
3.1 理解控制台变量的优先级
UE5 中设置渲染参数有很多入口，包括项目设置的Engine.ini、自定义的ConsoleVariables.ini、蓝图中动态执行控制台命令、启动命令行参数、游戏内控制台手动输入。优先级从高到低通常是：控制台手动输入最高，接着是运行时动态设置，然后是启动参数，最后是配置文件。
所以如果发现某个数值改了不生效，先确认是不是被更高优先级的入口覆盖了。团队协作时，为了保证优化结果可控，建议把通用性能配置写入ConsoleVariables.ini，同时在代码或蓝图中尽量避免频繁修改全局变量。
3.2 常见渲染开销开关与场景取舍
以下是 UE5 项目中最常见的渲染可调点，实际使用时需要看项目当前版本是否支持同名变量。
| 功能 | 常见控制台变量 | 优化思路 |
|---|---|---|
| 阴影质量 | r.ShadowQuality | 降低阴影分辨率，或关闭接触阴影 |
| 体积雾 | r.VolumetricFog | 场景中非必要特效可关闭 |
| 反射 | r.ReflectionMethod | 从 Lumen 反射切到 SSR 或关闭反射 |
| 全局光照 | r.Lumen.DiffuseIndirect.Allow | 关闭或降低 Lumen 采样质量 |
| Nanite | r.Nanite.MaxPixelsPerEdge | 控制 Nanite 网格体内部细分密度 |
| 动态分辨率 | r.DynamicRes.Enabled | 非必要场景可关闭 |
如果项目对画面精度要求较高，不建议直接全关所有特效。更合理的做法是设置级别策略：性能模式、画面模式、极致模式。性能模式可以关闭体积雾、降低阴影和反射，但不影响核心玩法表现。
3.3 r.ScreenPercentage 不是超分辨率，但它能恢复帧率
r.ScreenPercentage也会被一些开发者误解为超分辨率。实际上它控制的是渲染内部分辨率相对输出分辨率的比例，例如设置为 70 时，画面先以 70% 分辨率渲染，再放大到输出分辨率。它和 TSR 的差异在于，TSR 在放大时会做时序重建，而直接改r.ScreenPercentage会导致更明显的模糊和闪烁。
在性能优化中，这个变量可以作为紧急降载手段，但最好不要作为长期方案。长期方案建议优先减少额外特效，而不是降低基础分辨率。
3.4 材质复杂度与着色器开销
很多帧率问题来自材质本身。项目里有大量复杂 PBR 材质、多层贴图采样、动态分支、全屏后处理材质时，即使场景物体不多，GPU 负载也可能很高。这种情况下，优先检查材质复杂度，而不是马上关闭渲染功能。
常用的排查方式是在控制台打开材质复杂度视图：
vis MaterialComplexity切换后场景会以颜色梯度显示每个物体的材质指令数，红色区域往往是需要重点优化的目标。优化手段包括减少贴图采样次数、去掉不必要的像素深度偏移、把动态材质改成静态材质，以及尽量复用半透明材质而不是创建大量单独实例。
4. CPU 与 Gameplay 层优化：3 倍帧率的关键常常在这里
4.1 DrawCall 与 Actor 数量控制
实际项目里，GPU 负载很高但 CPU 也没闲着的情况很常见。大量重复网格体如果分散为多个独立 Actor，每一帧都会产生多份渲染状态提交成本。更推荐的方式是：尽量使用合并网格体、实例化网格体或 HISM 组件。UE5 自带 HISM（Hierarchical Instanced Static Mesh）组件，适合植被、道具、装饰物这类重复资产。
// 在 C++ 中创建 HISM 组件并批量添加实例 UHierarchicalInstancedStaticMeshComponent* HISM = NewObject<UHierarchicalInstancedStaticMeshComponent>(Actor); HISM->SetupAttachment(RootComponent); HISM->SetStaticMesh(StaticMesh); HISM->AddInstances(TreeTransforms, /* bWorldSpace= */ true);蓝图里也可以直接用“Add Instances”节点批量添加实例，这样比反复 Spawn Actor 高效得多。如果场景里普通 Actor 数量超过合理范围，帧线程的更新压力会明显上升。
4.2 频繁 Tick 和蓝图死循环
蓝图中的Event Tick节点每帧执行一次，是 CPU 开销的常见来源。优化时应当先统计哪些 Actor 每帧都在更新，它们是否真的需要每帧更新。对于 UI、冷却时间、非玩家远处的 NPC 动画等，可以切到Set Timer by Event或只在特定事件触发时计算。
一个典型的错误是在Event Tick里遍历场景中所有敌人，然后每个敌人再执行一段逻辑。如果敌人数量到达几百甚至上千，Game 线程耗时很容易翻倍。优化方式是分批更新、距离裁剪、状态机限制，而不是一帧内处理全部内容。这里涉及蓝图入门阶段的循环逻辑，真正有效率的循环应该是小范围、短周期、无重复遍历的。
4.3 合并与剔除
UE5 的剔除系统可以很大程度减少不可见物体的渲染成本。项目设置中可以调整剔除距离、LOD 切换距离、遮挡剔除绑定方式。较大场景里，建议确认以下几点：
- 静态网格体是否设置了合理的 LOD；
- 是否启用了距离剔除或预计算可见性；
- 遮挡剔除是否在 Open World 场景中正常工作。
如果场景中有很多小物件永远不需要在远距离显示，可以把剔除距离调低。如果场景建筑复杂，需要验证遮挡剔除没有失效，否则很容易出现“站在室内却渲染了整个街区”的问题。
5. 帧率目标管理与动态质量调节
5.1 固定目标帧率比无限高帧率更重要
“帧率越高越好”在某些场景里并不完全正确。帧率波动过大时，玩家会感觉到画面卡顿，因为相邻两帧的耗时差异太大。即使平均帧率很高，只要出现明显的尖峰或掉帧，体验依然不好。
在实际工程中，更推荐限定目标帧率，比如 60 FPS 或 30 FPS。UE5 控制台命令t.MaxFPS可以直接限制最大帧率。延迟过高时，还可以通过调整帧率同步策略来获得更稳定的帧间隔。
; 示例：锁定目标帧率为 60 t.MaxFPS=60如果项目涉及视频渲染、推流或者实时数据预览，固定目标帧率会更重要。降帧率时如果没有同步调整时间戳，画面和音频节奏容易完全对不上。这也是很多视频处理项目里“降帧率导致时间戳间隔不对”的原因。
5.2 在蓝图中运行时动态切换画质模式
游戏运行时允许玩家切到低画质模式时，可以用Execute Console Command节点执行控制台命令。
r.ShadowQuality=1 r.VolumetricFog=0 r.ReflectionMethod=0 r.ScreenPercentage=80 t.MaxFPS=60把上面的命令合并成字符串，在蓝图里拉出Execute Console Command节点，填入字符串作为 Command，选择Specific Player Controller或“目标即可。这里注意，命令里的逗号分隔在某些版本中支持，但在蓝图中逐个执行更稳妥。
5.3 时间步长与帧率稳定性
UE5 的默认时间步长由引擎自动计算，但如果为了视频录制或同步需求希望做固定时间步长，可以在项目设置中的General目录找到Fixed Frame Rate相关配置。不建议在游戏运行过程中频繁修改固定帧率，否则物理和动画系统的累积误差会增加。
如果做联网同步，帧率变化会影响 RPC 的发送节奏和拥有者复制频率。这种情况下的优化不能只追求高帧率，而要同时保证时间步长稳定，否则移动端表现会比固定帧率项目更差。
6. 完整示例：一套不依赖超分辨率的 UE5 性能优化配置
6.1 示例目标
这里给出一套可以直接放进项目根目录的ConsoleVariables.ini配置。它不是一个“无脑通用配置”，而是一个优化基线，适用场景是：场景中静态网格体负载较高，全局光照需求中等，阴影不必极高，且画面允许在性能模式下降级。
6.2 文件路径与基础配置
文件路径为项目根目录下的Config/ConsoleVariables.ini。如果没有该文件，可以直接新建。UE5 启动项目时会自动加载。
; 文件路径：Config/ConsoleVariables.ini ; 仅以 UE5 通用 Console Variables 为例，不同小版本可能命名有差异 ; 启动时会被项目设置覆盖，适合作为团队性能基线 ; 渲染基础 r.ScreenPercentage=100 r.AntiAliasingMethod=2 ; 阴影 r.ShadowQuality=1 r.Shadow.MaxCSMResolution=1024 r.ContactShadows=0 ; 全局光照 r.Lumen.DiffuseIndirect.Allow=1 r.Lumen.Reflections.Allow=0 ; 特效与后处理 r.VolumetricFog=0 r.AmbientOcclusion.Method=1 r.DynamicRes.Enabled=0 ; Nanite r.Nanite.MaxPixelsPerEdge=8 ; 帧率目标 t.MaxFPS=60写入后重新启动项目，就已经完成了一个基础性能模式的配置。如果某些命令在当前版本中不存在，引擎会在日志里给出提示，可以按需查阅当前版本的控制台变量文档进行替换。
6.3 通过启动命令行参数覆盖配置
团队内部测试时，不一定要修改配置文件。可以用启动参数临时验证效果：
UnrealEditor.exe "YourProject.uproject" -game -log -ExecCmds="r.ShadowQuality 1,r.VolumetricFog 0,t.MaxFPS 60"打包程序的执行文件同样支持这类参数：
YourProject.exe -ExecCmds="r.ScreenPercentage 100,r.ReflectionMethod 0,t.MaxFPS 60"这种方式适合快速验证，不会污染项目配置。确认某组参数有效之后，再写入正式的配置文件。
6.4 蓝图动态执行控制台命令
运行时不想重启项目，可以加一个简单的 UI 按钮，点击后执行不同画质档位的命令。
- 高性能模式命令：
r.ShadowQuality 1,r.VolumetricFog 0,r.ScreenPercentage 70,t.MaxFPS 60 - 平衡模式命令：
r.ShadowQuality 2,r.VolumetricFog 1,r.ScreenPercentage 100,t.MaxFPS 60 - 极致画质命令：
r.ShadowQuality 5,r.VolumetricFog 1,r.ScreenPercentage 100,t.MaxFPS 120
在蓝图中，使用Execute Console Command节点执行即可。这里需要关注的是命令并不会马上生效，阴影、全局光照等模块可能需要一两帧重新编译和缓存，所以画面切换时出现短暂性能波动是正常现象。
6.5 运行与验证方式
配置写入后，建议在Play模式下开启控制台输入：
stat unit stat fps记录两种状态的帧耗时：当前配置和原配置。对比时保持场景完全相同：镜头位置、角色状态、天气、动态物体、同屏人员数量都必须一致。否则数据没有可比性，3 倍帧率的结论也很难成立。
7. 常见问题与排查思路
| 问题现象 | 可能原因 | 排查方式 | 解决方案 |
|---|---|---|---|
| 控制台变量配置不生效 | 配置优先级被覆盖 | 在控制台输入变量名查看当前值 | 删除更高优先级设置，或改用启动参数 |
| 帧率没有明显变化 | 瓶颈在 CPU 或 DrawCall | 查看stat unit和stat rhi | 优先优化蓝图和 Actor 数量 |
| 画面模糊严重 | r.ScreenPercentage设置过低 | 检查当前实际渲染分辨率 | 回调分辨率，并使用 TSR 恢复画质 |
| 启动时黑屏 | ExecCmds中命令有误 | 查看日志和命令行提示 | 检查命令拼写和引号分隔 |
| Lumen 关闭后场景变暗 | 反射模式变化 | 查看反射和间接光照表现 | 用烘焙光照或调整环境光强度 |
| 移动端掉帧严重 | DrawCall 和半透明材质过多 | 使用 GPU 抓帧工具 | 合并材质、减少半透明对象 |
| 帧率波动但平均帧率不低 | 时间步长不稳定 | 查看stat unit耗时曲线 | 锁定目标帧率，固定帧间隔 |
| 视频项目时间戳错位 | 降帧率后没有同步刷新时间戳 | 检查输出时间戳间隔 | 用固定帧率或补齐采样时钟 |
如果启动后命令没有生效，第一个要看的不是代码，而是日志文件。UE5 项目日志通常位于Saved/Logs目录下，文件名是YourProject.log。搜索Console相关记录，能看到哪些命令被拒绝了，哪些变量不存在。这是排查配置问题的最直接路径。
8. 最佳实践与工程建议
8.1 先建立基准版本
无论目标是 3 倍帧率还是 20% 帧率提升，第一件事都是建立基准版本。把当前场景、当前画质、当前帧耗时记录成表。后续每一步优化只改动一个变量，然后重新测量，记录前后耗时。这样可以清晰看到哪个改动真正有效，哪个改动看起来有效实际上没有意义。
8.2 不要在编辑器里做最终性能测试
编辑器启动的 Play 模式会包含大量调试信息和编辑器的额外开销，不能代表真实发布程序的表现。优化到一定阶段后，应该打包成 Development 或 Shipping 构建，在目标环境上复测。移动端要区分真机和模拟器，模拟器数据只能做趋势参考，不能做最终结论。
8.3 优化不是越暗越好
很多开发者把“性能模式等于把画面调到最差”当成默认思路，这并不完全正确。优化的核心是在视觉容忍度和性能成本之间找到平衡。例如关闭体积雾对性能帮助很大，但场景氛围会明显变化；关闭反射对金属质感的物体影响很大。实际项目中应该由美术和技术一起决定哪些功能可降级、降级到什么程度。
8.4 网络同步项目中谨慎使用动态帧率
如果项目是多人联网，t.MaxFPS调整需要非常谨慎。复制的频率、移动预测的插值时间、RPC 发送节奏都与帧率相关。动态切换帧率可能会导致玩家看到的角色位置出现异常跳变。这种情况下，更推荐锁定一个固定目标帧率，如客户端统一 60 FPS 或 30 FPS，并通过网络同步设置限制复制频率，而不是放任帧率自由波动。
8.5 把优化做成流程而不是一次性事件
UE5 项目随着开发推进会不断加入新资产和新功能，性能会持续变化。每次合入大功能时都应该跑一轮基准测试。如果团队有条件，可以用自动化脚本导出数据，在性能回归时快速定位是哪些资源或逻辑导致帧率下降。这个习惯比掌握再多优化技巧都重要。
9. 总结与下一步学习方向
回到最初的问题：不用超分辨率能不能实现 3 倍帧率？答案是，在很多 UE5 项目中完全可能，前提是找准瓶颈。超分适合在 GPU 像素填充成为主要瓶颈时使用，但它不是优化起点。真正有效的是先通过stat unit和 Unreal Insights 拆分出耗时来源，然后针对阴影、反射、体积雾、材质复杂度、Nanite、蓝图 Tick、Actor 数量、DrawCall 和帧率同步做整体预算调整。
下一步建议按照本文第七节的流程先跑一个场景的基准版本，尝试把场景中的阴影、体积雾、Lumen 反射分别关掉，观察stat unit数据的变化。再用 Unreal Insights 查看 Game 线程中最耗时的函数和资源加载热点。如果希望继续深入，可以从资源流送与 PSO 编译优化、材质指令数控制、目标平台上的 GPU 抓帧分析这几个方向展开。性能优化没有一次性解法，但按流程来，3 倍帧率的目标至少可以被一步步验证、逼近和达成。
