UE5不靠超分辨率也能3倍提帧：原生渲染优化实战

先说明：我不打算在文章里和谁吵架，也不打算证明“超分辨率无用”。本文想做的事情很简单——把一个 UE5 项目放到“原生渲染分辨率”下，通过一系列渲染配置、场景设置和资源层面的优化，把帧率从约 30fps 提到接近 90fps。这个结果说明一个问题：UE5 的帧率提升路径并不只有超分辨率这一条，至少在特定场景里，原生渲染优化同样可以拿到接近 3 倍的收益。

经常看到一种说法：UE5 项目“不开超分就没法玩”，帧率只能靠 TSR、DLSS、FSR 这类技术硬拉。这种说法有一定背景，因为 UE5 默认的 Lumen、虚拟阴影贴图（Virtual Shadow Maps）等特性确实非常消耗 GPU，降渲染分辨率确实是最快的提速手段。但“最快”不等于“唯一”。如果项目画质起点太高、很多高开销效果其实对画面贡献不大，那原生渲染下同样有大量可回收的 GPU 预算。

下面这份教程不推荐“无脑解锁最大画质再开超分”的路线，而是走一条更工程化的路径：先定位瓶颈，再按收益逐个裁剪开销，最后把稳定有效的配置固化到项目里。无论你是 UE5 新手，还是已经做过基础优化、想更进一步控制帧预算的开发者，这份流程都可以直接套用。

1. 背景：超分辨率到底帮我们解决了什么问题

1.1 超分辨率的本质是“用低分辨率渲染换帧率”

先明确概念。本文说的超分辨率，不是图像处理里的单张图片超分重建，而是游戏渲染中的时间/空间超分辨率技术：

• TSR：UE5 内置的 Temporal Super Resolution，中文常翻译为“时序超分辨率”。
• DLSS：NVIDIA 的深度学习超采样技术，需要插件和对应显卡。
• FSR：AMD 的 FidelityFX Super Resolution，同样需要插件或引擎支持。

它们的共同思路是：不按 100% 屏幕分辨率渲染，而是先把渲染分辨率降到 50%～70%，再用各种重建算法把画面“拉回”到目标分辨率。因为低分辨率下 GPU 需要算的像素少了很多，帧率自然上升。

这个思路没有错，也很实用，但要注意：真正带来帧率提升的不是“超分算法”本身，而是它背后那个低分辨率渲染。开了超分之后，GPU 渲染的像素负担变小了，画面细节靠重建算法补回来。

1.2 不开超分辨率时，帧率去哪找

如果不使用超分辨率，我们的约束条件就变成了：

• 渲染分辨率保持 100%，也就是r.ScreenPercentage=100。
• 不使用 TSR、DLSS、FSR 等重建方案。
• 不通过动态分辨率把渲染分辨率临时调低。

那么剩下的优化空间就只能从“渲染开销”本身去挖。UE5 里有很多功能在带来画质提升的同时，也带来了远超预期的 GPU 消耗。只要愿意在画质和性能之间重新做一次取舍，不需要降分辨率也能释放出大量帧预算。

这里要先打破一个误区：很多人打开 UE5 模板后，看到默认的 Lumen、虚拟阴影、体积雾、TSR 全开着，就以为“这就是 UE5 的画质底线”。其实 UE5 是高度可配置的引擎。同样的场景，Open World 模板和 First Person 模板呈现出来的画质方案完全不同。所谓“默认全开”，只是模板为了让新手更容易看到效果，不是性能基准。

1.3 3 倍帧率是不是噱头

从 30fps 到 90fps 确实挺夸张，但这个结果取决于起点。如果项目本身的渲染配置里堆了大量高开销特性，比如：

• 全局光照使用 Lumen 动态 GI；
• 反射使用 Lumen 反射；
• 阴影开启虚拟阴影贴图；
• 体积雾全开；
• TSR 或 TAA 之外还挂着大量后处理；
• 场景网格体数量巨大且没有合理 LOD；

那么 GPU 时间很可能超过 30ms，30fps 左右徘徊。把这些“画质堆叠”逐个拆掉，只保留对当前场景真正有贡献的效果，GPU 时间从 30ms 降到 10ms 并不是不可能。3 倍帧率就是从这种巨大的冗余优化空间里挤出来的。

本文后面的实战案例就是一个最典型的“高起点”场景。如果你做的项目本身画质已经比较克制，那 3 倍就不现实，但也可能拿到 30%～50% 的提升。关键不是追求固定的倍数，而是掌握排查和优化的方法。

2. 优化前的准备：环境、版本与性能基线

2.1 开发环境与版本说明

本文示例使用的环境如下：

• 引擎版本：UE5.1 以上版本，我用的是 UE5.2/5.3 分支测试；
• 项目模板：第三方模板或空模板均可，重点是导入一个静态网格较多的场景；
• 操作系统：Windows 10/11；
• GPU：NVIDIA RTX 系列或同级别显卡；
• 不需要在项目里安装任何超分辨率插件。

不同 UE5 小版本的渲染器设置项位置略有差异，尤其是 UE5.0、UE5.1、UE5.2 之间的“Virtual Shadow Maps”“Nanite”“Lumen”配置入口不完全一致。在阅读下面的路径时，如果与自己项目对不上，以项目实际版本为准。

2.2 准备一个测试场景

性能优化不能靠感觉，也不能在编辑器和打包后各测一次就下结论。建议准备一个固定场景，场景里需要包含你项目中常见的元素：

• 静态模型：建筑、地面、植被或道具；
• 动态物体：玩家角色、几盏会动的光源或可破坏物；
• 一定数量的小物件：碎石、路边灯、树杈，用来放大 Draw Call 和阴影压力；
• 至少一束平行光作为主光源。

这个场景会作为底稿。后面每调整一项配置，都在同一个位置、同一个视角下记录帧率，否则数据没意义。

我准备的测试场景以城市街道为主体，包含 1800 个静态网格体、50 盏灯光、大量植被和两段动画蓝图。初始项目开启了 Lumen、虚拟阴影、体积雾，抗锯齿方式是 TSR，整体是典型的“UE5 默认质感拉满”状态。

2.3 掌握三种性能分析工具

在动配置之前，先学会读数据。UE5 中最常用的三个工具是：

• stat unit：观察 Frame、Game、Draw、GPU 四个时间；
• stat gpu：查看渲染各阶段的 GPU 耗时；
• Unreal Insights：抓取一段 Trace，分析 CPU 和 GPU 的整体耗时分布。

控制台快捷键是键盘左上角的Tab或~键。在视口里输入stat unit，左上角会出现类似下面这样的一行：

Frame: 33.3 ms Game: 5.2 ms Draw: 6.1 ms GPU: 23.5 ms

这里的判断规则很简单：

• 如果 GPU 时间接近甚至超过 Frame 时间，说明瓶颈在 GPU，优先砍渲染功能；
• 如果 Game 时间高，说明蓝图、物理或动画脚本消耗过多 CPU；
• 如果 Draw 时间高，说明渲染线程提交的 Draw Call 太多，需要合并网格、减少组件数量；
• 如果三者都不高，但 Frame 时间依然高，可能是t.MaxFPS、垂直同步或等待线程导致的帧率限制。

stat gpu更细，它能列出BasePass、ShadowDepths、Lighting、Translucency、PostProcess等阶段的耗时。我在优化前打开它，看到 Lightness、Reflection 和 Shadow Depths 三项占有明显比例，说明 Lumen 和阴影正是大头。

3. UE5 渲染开销拆解：帧时间都花在哪了

3.1 Lumen 是最大的“帧率黑洞”

Lumen 是 UE5 主推动态全局光照方案，它能做到实时间接光照和反射，画面效果很好，但开销也非常大。开启 Lumen 后，GPU 需要实时计算场景中大量像素的间接光源信息，并且随着场景复杂度上升，耗时增长明显。

在实际项目中，Lumen 适合那些确实需要动态 GI 的场景，比如昼夜交替、动态光源大量变化、室内多光源混合。如果你的场景以静态烘焙为主，或者只在个别区域有动态光源，Lumen 可能根本没提供太多可见收益，反而是帧率的主要负担。

优化时可以先在项目设置里把 Global Illumiation 从 Lumen 改成 Screen Space Global Illumiation（SSGI）或者直接关闭，再做光照烘焙。如果场景依赖动态调节光源，也应该评估“动态光照区域”之外的范围是否真的需要 Lumen。

3.2 阴影：隐藏的 GPU 大户

UE5 新版本里，虚拟阴影贴图（Virtual Shadow Maps）能处理非常精细的阴影，但代价是更高的运行时开销，尤其是在植被、建筑等小三角形较多的场景里，每一帧都要维护阴影场景和筛选页面，动辄吃掉 3ms～8ms 的 GPU 时间。

如果不使用虚拟阴影贴图，而是选择传统的级联阴影贴图（CSM），则需要关注四个参数：

• 级联数量：默认 4 级，很多场景 2 级就够；
• 阴影距离：动态阴影距离越大，需要渲染的阴影范围越大；
• 阴影分辨率：通常 1024 或 2048 足够；
• Contact Shadow：接触阴影精细但很贵，性能敏感时可以关闭。

要注意的是，阴影优化不是越低越好，而是让阴影在“玩家看得见的地方”保持清晰，在远处或者非交互区域果断减少开销。盲目把阴影全关，画面会变平，观感反而不如保留中等阴影。

3.3 屏幕空间效果：分辨率越翻倍，成本越翻倍

屏幕空间反射（SSR）、环境光遮蔽（AO）、体积雾、景深、泛光、运动模糊这些效果，绝大多数是在屏幕像素分辨率这一层计算的。它们的优势和超分辨率相反：屏幕分辨率越高，这些效果越贵。哪怕不开启超分，只要把分辨率设置为 100%，这些效果的成本就会被放大。

所以在原生渲染分辨率下，屏幕空间相关的效果要“按需开通”：

• 泛光（Bloom）：轻度使用可以，但质量等级太高没有实际收益；
• 体积雾（Volumetric Fog）：除非画面核心表达是“体积光束、晨雾”，否则关掉能省下可观时间；
• 运动模糊（Motion Blur）：绝大多数竞技类和模拟类项目不建议开；
• 景深（Depth of Field）：电影化演出片段可以单独用，平时关闭；
• 环境光遮蔽（AO）：GTAO 或 SSAO 在某些模型精度不高的场景里反而会产生脏污感，可以考虑降一档或按优先级分层。

3.4 CPU 侧的 Draw Call 与 Tick 负担

帧率低不只是 GPU 的锅。在大世界项目里，如果场景有上万个 Actor，即使不渲染，CPU 也要处理组件更新、剔除、物理、蓝图 Tick 等任务。stat unit中 Draw 时间高，通常意味着渲染线程被大量 Draw Call 压住了；Game 时间高，则往往来自蓝图、动画蓝图、寻路或物理系统。

如果你在stat unit中看到 Game 或 Draw 已经超过 10ms，那么光调渲染配置是救不回来的。CPU 瓶颈下，需要：

• 减少每帧 Tick 的 Actor 数量；
• 使用 Actor 分组、禁用不可见 Actor 的 Tick；
• 合并相近的静态网格，减少 Draw Call；
• 用 LOD 和 HLOD 降低远处物体的复杂度；
• 对粒子、动画、物理设置合理的距离剔除。

4. 原生分辨率下的六大优化方向

4.1 关闭 Lumen，改用烘焙光照或 SSGI

Lumen 最适合快速开发阶段和展示型场景。如果项目对动态 GI 没有要求，建议直接关闭 Lumen，换回静态烘焙。

操作路径：

1. 打开 Project Settings；
2. 选择 Rendering；
3. 在 Global Illumination 中选择 “Screen Space Global Illumiation”；
   如果想要更好的质量且场景以静态光为主，可以选 “Lumen – Software” 之外，再把反射方案设置为 “Screen Space Reflections”。
4. 如果完全不需要动态 GI，也可以选择 “None”，然后只保留直接光照。

关闭 Lumen 后，灯光和材质会重新编译，场景可能在视觉上会变暗一些。这是正常现象，因为间接光照没了。你可以通过以下方式弥补：

• 在场景中补充增补光，例如增加平行的蓝冷调环境光；
• 使用 Lightmass 做光照烘焙，把静态网格体的间接光信息存到 Lightmap 中；
• 调整后处理体积的曝光、对比度，让画面不至于发闷。

对追求稳定帧率的移动端项目或线上项目来说，烘焙光照仍然是主流选择。动态 GI 的开销，并不是每个项目都承担得起。

4.2 阴影降档：控制级联、分辨率与距离

先处理主方向光的阴影设置。选中主光源，在 Details 面板中找到 Cast Shadows、Shadow Settings 相关选项：

• Dynamic Shadow Distance：从默认的 3000 以上降到你实际需要看清阴影的最远距离，一般 1000～1500 就够；
• Max CSM Cascades：设置为 1 或 2；
  如果场景里只有一个主光源，2 级级联通常比 4 级便宜很多；
• Shadow Resolution Scale：保持在 0.5～1.0 之间，不要盲目开 2.0；
• Contact Shadow：如果用的是 Contact Shadow Length，性能敏感时关闭。

然后再处理点光源和聚光灯。很多美术同学会把场景里的每个灯都开启投射阴影，结果就是阴影深度渲染多次，GPU 瞬间被打爆。合理的做法是：

• 只让玩家视野中最重要的 2～3 盏灯投射阴影；
• 小体积补光灯一律把 Cast Shadow 勾掉；
• 远处灯光用 IES、静态照明模拟即可，不参与动态阴影。

4.3 干掉不必要的体积与图像效果

后处理体积（Post Process Volume）是容易超支的地方。检查项目里所有 Post Process Volume，确认它的Post Process Settings里哪些项目被覆盖了：

• Bloom：建议 Intensity 保持 0.3～0.6，不要每个场景都拉满；
• Auto Exposure：如果用固定曝光，可以减少自适应曝光带来的亮度波动和性能开销；
• Depth of Field / Motion Blur：不是叙事演出重点就关闭；
• Ambient Occlusion：按场景复杂度决定，我用默认 GTAO 中档；
• Volumetric Fog：在 World Settings 中关闭。

体积雾是很容易漏掉的一项。r.VolumetricFog=0或项目设置里关掉 Volumetric Fog 后，在老实街景这种室外场景中几乎无感知，但能省下约 1.5ms 的 GPU 时间。

4.4 抗锯齿不用 TSR，也能有不错的观感

在“不用超分辨率”的前提下，TSR 自然不在考虑范围内。抗锯齿方面可选方案：

• FXAA：性能开销极低，画质偏软，适合高速动作游戏；
• TAA：比 FXAA 清晰，但会有一部分重影问题；
• MSAA：静态 Mesh 效果不错，但在半透明、粒子等 Pass 上支持不完整；
• 关闭 AA，配合后处理缩放抖动？一般不推荐，画面会明显有锯齿。

我的建议是 FXAA 或 TAA。在 UE5 中通过控制台设置：

r.AntiAliasingMethod=1

1 对应 FXAA，2 对应 TAA。如果你希望在不开 TSR 的情况下保持清晰边缘，可使用 TAA，再配合小小的锐化（后处理 Shim）。

渲染分辨率统一保持 100%，也就是：

r.ScreenPercentage=100 r.DynamicRes.Enabled=0

这样即使引擎里装了 DLSS/FSR 插件，也不会被默认触发。

4.5 场景侧优化：LOD、剔除、Nanite 的合理使用

UE5 的 Nanite 确实能处理海量三角形，但 Nanite 不是万能药。当场景里有大量细碎物体，如草叶、碎石、栏杆，Nanite 的集群和渲染管线同样有明显开销；而且 Nanite Mesh 默认不支持某些材质特性，细节贴图采样和像素曲率效果可能受限。

如果你使用的是传统静态网格体，务必把 LOD 的距离设置清楚：

• 在静态网格体编辑器里自动生成 LOD；
• 把 LOD 0 到 LOD 3 的距离分配合适；
• 在 World Settings 中开启大世界 HLOD（Hierarchical Level of Detail），把远处的多个 Mesh 合并成一个粗略实例；
• 把项目的 “Occlusion Culling” 打开，确保不在视线内的物体被提前剔除；
• 检查r.AllowOcclusionQueries是否被手动关闭。

LOD 的收益非常大。在我的测试场景里，光是把所有静态网格体的 LOD 距离从 20000 改成 800/2000/5000 三档，GPU 时间就下降了约 2ms。

4.6 CPU 与 Game Thread 优化

最后不要忘了，帧率是一个综合指标。即使 GPU 时间降到 8ms，如果 Game Thread 在蓝图里卡顿，整体帧率依然上不去。

在 CPU 侧，我优先处理这几件事：

• 把蓝图 Tick 里每一帧都执行的逻辑改为“按需执行”或“计时器触发”；
• 用 “Actor 休眠” 或 “Set Tick Enable” 控制远处 AI；
• 动画蓝图如果不需要每帧更新，就降低更新频率；
• 检查场景里是否存在大量可见性无关的 Actor，例如隐藏但仍在计算的逻辑体；
• 用 “Level Streaming” 拆分大场景，避免一次性加载所有资产。

5. 实战复盘：从 30fps 到 90fps 的完整步骤

5.1 测试场景与基线数据

下面进入实战。我用的场景是一个中等规模的街道街区，包含：

• 1800 个静态网格体；
• 60 盏灯光，其中 4 盏投射阴影；
• 两个动画蓝图控制的人形角色；
• 开启动态天空和大气散射；
• 画质设置为 Epicscalability 档位。

初版配置下的性能数据：

Frame: 33.3 ms Game: 5.8 ms Draw: 6.2 ms GPU: 23.1 ms FPS: ~30

这个数据很明显：GPU 时间 23.1ms，是绝对瓶颈。所以接下来的优化围绕渲染层级进行。

5.2 第一步：控制台命令快速试算

在 UE5 视口中打开控制台，输入以下命令，快速查看不同配置的效果：

r.DynamicRes.Enabled=0 r.ScreenPercentage=100 r.AntiAliasingMethod=2 r.ShadowQuality=1 r.Shadow.CSM.MaxCascades=2 r.Shadow.MaxResolution=1024 r.Shadow.DistanceScale=0.6 r.ContactShadows=0 r.VolumetricFog=0 r.BloomQuality=3 r.MotionBlurQuality=0 r.AmbientOcclusionLevels=1 r.Lumen.DiffuseIndirect.Allow=0 r.Lumen.Reflections.Allow=0

注意：这里先把抗锯齿调成 TAA，不用 TSR。Lumen 相关 CVar 在部分版本中可能需要配合项目设置一起使用。输入完这些命令后，立刻跑stat unit：

Frame: 16.2 ms Game: 5.4 ms Draw: 5.9 ms GPU: 11.8 ms FPS: ~62

帧率从约 30 提升到 62，接近 2 倍。这个阶段最大的收益来自关闭 Lumen 和虚影相关的高开销渲染层，以及降低级联阴影。

5.3 第二步：把有效配置固化进项目

控制台命令只管当前会话，重启编辑器后会丢。如果想长期使用，需要把 CVar 写入项目配置。

推荐在Config/DefaultEngine.ini底部增加如下内容：

[SystemSettings] r.DynamicRes.Enabled=0 r.ScreenPercentage=100 r.AntiAliasingMethod=2 r.ShadowQuality=1 r.Shadow.CSM.MaxCascades=2 r.Shadow.MaxResolution=1024 r.Shadow.DistanceScale=0.6 r.ContactShadows=0 r.VolumetricFog=0 r.BloomQuality=3 r.MotionBlurQuality=0 r.AmbientOcclusionLevels=1 r.Lumen.DiffuseIndirect.Allow=0 r.Lumen.Reflections.Allow=0

注意：不同的 UE5 小版本对 CVar 的名称和支持情况会有差异。比如r.Lumen.DiffuseIndirect.Allow在 UE5.0 和 UE5.3 中行为基本一致，但如果遇到版本更新后某些 CVar 失效，需要打开项目设置里对应选项确认。

同时还要在项目设置界面修改渲染方案：

• Global Illumination 选择 “None” 或者 “Screen Space Global Illumiation”；
• Reflections 选择 “Screen Space”；
• 抗锯齿方式选择 “TAA”；
• 关闭动态分辨率；
• 在 World Settings 里关闭 Volumetric Fog。

5.4 第三步：继续压制 CPU 与 Draw Call

到 62fps 后，GPU 时间降到 11.8ms，但 Draw 时间仍然接近 6ms。继续优化场景侧：

1. 把所有静态网格体生成 LOD；
2. 把道路两侧路灯、花坛、垃圾桶等小物件数量降低 30%；
3. 把同类模型使用 Instance Static Mesh 合批；
4. 检查蓝图 Tick：把非玩家附近的范围检测逻辑改成间隔触发；
5. 动画蓝图关闭不必要的 IK 和物理模拟。

这一步之后，Draw 时间从 5.9ms 降到 4.5ms，帧率进一步提升到 75fps 左右。

5.5 最终数据对比

最终跑出来的数据：

Frame: 11.2 ms Game: 4.6 ms Draw: 4.4 ms GPU: 7.5 ms FPS: ~89

从 30fps 到 89fps，接近 3 倍。

这里我把各阶段收益整理一下，方便理解：

这个结果是在我的测试环境中得到的，不代表所有项目复现同样倍数。但它说明一个非常关键的事实：当 GPU 被无关效果占满时，原生渲染分辨率下同样有非常多可以压缩的空间。

6. 常见问题与排查思路

6.1 为什么按这些命令设置了，帧率变化不大

如果stat unit中 GPU 时间不高，但 Frame 时间依然很高，说明瓶颈在 CPU。常见原因：

• 蓝图 Tick 或动画蓝图过于复杂；
• 粒子系统、物理模拟消耗过大；
• Draw Call 数量太多，渲染线程卡在提交阶段；
• t.MaxFPS或垂直同步限制了帧数。

我建议先看Game和Draw两个值。如果 Game 高，排查脚本；如果 Draw 高，排查网格体数量和合批；如果 GPU 不高但 Frame 高，检查垂直同步。

6.2 关闭 Lumen 后场景变暗

这是正常现象。Lumen 提供了实时间接光照，关闭后再也没有间接光反弹效果。应对方案：

• 用光烘焙（Lightmass）重建 Lightmap；
• 在场景里补环境光或加多一些低频补光；
• 调整后处理体积的对比度和曝光值。

如果项目需要动态光照但又买不起 Lumen 的 GPU 开销，可考虑只对“动态物体”提供简易实时 GI，而静态场景保持烘焙。

6.3 阴影闪烁或网格边缘出现黑线

通常是因为阴影分辨率太低、级联距离太小，或者 LOD 切换太激进。按以下顺序调整：

• 把r.Shadow.MaxResolution从 512 提到 1024；
• 增加r.Shadow.CSM.MaxCascades到 3；
• 检查静态网格体的 LOD 距离是否过近，LOD 跳变会导致边缘跳动；
• 如果使用 Virtual Shadow Maps，关闭后请确保传统 CSM 参数符合场景规模和预期。

6.4 命令行设置重启后失效

把 CVar 写进DefaultEngine.ini。如果在编辑器里测试，也可以写到Saved/Config/Windows/Engine.ini，但重启后可能丢失。正式项目应保持在版本管理下，使用项目级配置文件。

6.5 画面出现锯齿

如果关闭了 TSR 且 AA 使用 FXAA，锯齿会比之前明显。优化思路：

• 提升 AA 到 TAA；
• 开启后处理体积中的细微锐化；
• 调低屏幕锐化溢出量，减少色边。

7. 最佳实践与工程建议

7.1 先做性能预算，再动手优化

不要一边调配置一边看帧率。先在项目层面定一个目标，例如：

• 目标平台：中端 PC；
• 目标帧率：60fps 或 90fps；
• 目标分辨率：1920×1080，原生渲染；
• 帧预算：16.6ms / 11.1ms。

然后分配预算：

• Game Thread 最多 3ms；
• Draw Thread 最多 4ms；
• GPU 最多 8ms；
• 剩下时间留给读取、流送和余量。

有了预算表，优化就不再是玄学，而是“哪里超支补哪里”。

7.2 每一项优化都单独记录收益

在一个工程里，不要一次性把所有配置改完再测。那样你不知道究竟是哪一项救活了帧率。正确做法是：

1. 记录基线数据；
2. 改一项，测一项，记录一项；
3. 保留一份“优化开关”说明文档；
4. 必要时写成配置版本，方便回滚。

我在实际项目里会准备一个 Excel 表，列名大致是：

7.3 用 Scalability 分级，而不是写死一套配置

不要把所有优化项写死成“项目唯一配置”。同一个项目，开发机可能跑 120fps，玩家电脑可能只有 40fps。更合理的方式是：

• 用Scalability.ini分成 Low、Medium、High、Epic 档位；
• 把 Lumen、阴影距离、体积雾、AA 等配置放进可扩展性分组；
• 玩家端自动检测硬件并选择对应档位；
• 保留一个“极致画质”模式给高端显卡用户。

这样既保证了低端机的帧率，也不至于让高端用户失去画质。相关设置可以放在Config/BaseScalability.ini或项目自己的DefaultScalability.ini里。

7.4 用 Unreal Insights 做最终回归

控制台看瞬时帧率只能发现“现在卡”，但无法定位“卡在哪个函数”。建议每隔一段时间录制一段 Unreal Insights Trace：

1. 在编辑器菜单打开 Window -> Unreal Insights；
2. 在 Editor 中运行项目；
3. 设置 Trace 开始/结束；
4. 在 Insights 中查看 Game Thread、Render Thread、RHI Thread、GPU Timeline。

Unreal Insights 会还原出最耗时的函数，这样就能把优化从“配置调参”推进到“代码级优化”。

7.5 不要为了帧率砍掉必要的画质表达

优化过程中很容易走上另一个极端：把所有效果全关，画面变成“灰模”。这会带来美术返工和玩家投诉。我建议每次调整画质参数后，都要从玩家视角问两个问题：

• 这个效果在这个场景里，玩家是否能察觉？
• 如果关掉，游戏的核心视觉语言是否受损？

例如，恐怖游戏里的体积雾是氛围核心，不能无脑关；但竞技射击游戏里的运动模糊，关掉后反而提升清晰度。性能优化永远是在画质和帧率之间做取舍，而不是单方面牺牲画面。

8. 最后想说的一点

对我来说，UE5 性能优化的乐趣不只是让帧率数字变高，而是能弄清楚每一帧时间的去向，再用最少的画质代价换来最多的性能。TSR、DLSS 和 FSR 都是优秀的工具，但它们不应该被当成唯一的救命稻草。

如果你也遇到“UE5 项目默认画质下帧率感人”的问题，我建议你先不要急着找超分插件，而是打开stat unit和stat gpu，看看时间到底花在哪儿了。也许你会发现，真正吃掉帧率的不是渲染分辨率，而是那些默认打开却根本没人在意的 Lumen、虚拟阴影和体积雾。

关闭超分辨率不等于放弃画质，更不等于放弃帧率。它只是要求我们更仔细地对待每一帧 GPU 预算。希望这份优化流程能帮到正在和 UE5 帧率搏斗的你。