The Road to 60 fps in The Witcher 4 Unreal Engine 5 Tech Demo

讲座来源: The Road to 60 fps in The Witcher 4 Unreal Engine 5 Tech Demo | Unreal Fest Orlando 2025

演讲者: Kevin (Epic Games 渲染团队负责人) & Yoswaf (CDPR 核心引擎技术专家)

核心目标: 在次世代主机 (PS5) 上，利用 UE5 最新特性，在保持极致画质的前提下实现稳定的 60 FPS。

1. 项目背景与合作模式

1.1 为什么选择 60 FPS？

视觉流动性 (Fluidity): 相比 30 或 40 FPS，60 FPS 能带来显著更平滑的视觉体验和操作响应。
平衡点 (Sweet Spot): 在当前硬件（PS5/Xbox Series X）和主流显示设备上，60 FPS 是画质与性能的最佳平衡点。
可行性验证: 这是一个技术 Demo（非最终游戏成品），旨在验证大规模开放世界在当前硬件限制下的技术边界。

1.2 联合开发模式 (Co-dev)

双赢策略: Epic 提供底层引擎专长，CDPR 提供构建庞大密集开放世界的实战经验。
深度集成: 双方作为“一个大团队”工作，不仅为了制作 Demo，更是为了改进 UE5 引擎本身（Engine Core improvements）。

2. 核心技术挑战与目标

在 16.6ms 的帧预算下，团队设定了以下极具挑战性的图形学目标：

2.1 动态全局光照 (Dynamic GI)

目标: 支持 硬件加速的光线追踪 (Hardware Ray Tracing)。
细节:
- 实现全动态的昼夜循环 (Dynamic Time of Day)。
- 同时处理 漫反射 (Diffuse) 和 镜面反射 (Specular) 的高质量光照。
- 支持移动物体在反射中的实时更新。

2.2 复杂植被与环境构建

压力测试对象: 云杉林 (Spruce Trees)。
- 专家注: 云杉通常几何结构复杂，Overdraw（过度绘制）严重，是极佳的压力测试资产。
规模化 (Scale): 渲染范围直达地平线，包含大量有机细节。
管线: 建立了一套能支持从资产创建到场景组装的全流程管线。

2.3 无缝体验 (Hitch-free Experience)

流式加载 (Streaming): 确保高速移动（如骑马奔跑）时，数据加载不会导致主线程卡顿。
并发处理: 将大量计算移出关键路径 (Critical Path)，利用异步 (Asynchronous) 和并行 (Parallel) 计算。

3. 性能预算 (Frame Budgeting) 哲学

对于 60 FPS 的目标，每一帧的时间极其宝贵。

3.1 黄金公式

T_{f r am e} \leq 16.66 m s

3.2 预算分配

工程师需要帮助美术和策划理解预算，以便在不牺牲帧率的前提下最大化艺术愿景：

Sim (CPU): 16.6ms 用于准备数据（游戏逻辑、动画更新、物理模拟）。
Draw (CPU/GPU): 16.6ms 用于提交绘制指令和 GPU 渲染。
- 注意: CPU 和 GPU 通常是流水线并行工作的，但任何一方超过 16.6ms 都会导致掉帧。

4. 场景类型与针对性优化

Demo 将世界分为两类典型的负载场景，分别进行针对性优化：

场景 A：荒野 (Wilderness) - GPU 密集型

特征: 长视距 (Long Vistas)、高密度自然植被、体积特效 (Volumetric Effects)。
构建技术:
- 混合了手工制作区域 (Handcrafted) 与 程序化内容生成 (PCG, Procedural Content Generation)。
- 分为离线 PCG (Offline) 和运行时 PCG (Runtime)，以平衡存储和计算。
挑战: 几何吞吐量、光影计算（尤其是动态树木的阴影）。

场景 B：集市 (Market) - CPU 密集型

特征: 视距较短，但对象密度极高。
核心负载: NPC 行为与动画。
- 数量级: 同屏 300 个 NPC。
- 计算内容: 复杂的日常行为模拟 (Daily Routines)、高保真动画状态机、动态交互。
优化方向: 这里的瓶颈通常在于 CPU 的单线程性能，需要大量依赖多线程并行更新动画和 AI 逻辑。

5. 总结与专家洞察

这份讲座的上半部分确立了 《巫师4》技术转型的基调：

从专有引擎转向 UE5 的深度定制: 这不是简单的“拿来即用”，而是对引擎核心（Core Tech）的深度改造。
对“关键路径”的执着: 为了达到 60 FPS，核心策略是识别并移除阻塞主线程的任务 (Removing things from the critical path)。
Lumen 与硬件光追的实战化: 证明了在次世代主机上，全动态、高密度的开放世界跑 60 FPS 是可行的，但需要严格的资产管理和预算控制。

关于《巫师4》UE5 技术演示中 CPU 架构、多线程策略与性能预算 部分的深度技术总结。

这部分内容对于引擎开发工程师尤为重要，因为它揭示了 CDPR 如何利用 UE5 的新特性（Mass, AnimNext, Mover）将繁重的计算任务从主线程 (Game Thread) 剥离，以支撑高密度的开放世界模拟。

迈向 60 FPS：CPU 多线程架构与帧流水线

1. 帧流水线策略 (Frame Pipelining)

为了应对开放世界中不可预测的负载波动，项目采用了一种增加输入延迟但换取帧率稳定性的策略。

三级流水线设计:
- Game Thread (游戏逻辑): 模拟第 $n$ 帧。
- Render Thread (渲染指令): 处理第 $n - 1$ 帧。
- GPU (图形渲染): 渲染第 $n - 2$ 帧。
核心目的: 这种缓冲机制允许系统吸收偶尔出现的单帧卡顿 (Hitch)，防止其直接破坏渲染节奏，确保护航 60 FPS 的平滑度。

2. Game Thread 架构：并行化与任务图

核心思想是将传统的单线程逻辑打散，利用 Worker Threads 进行大规模并行计算，仅在必要时回到主线程同步。

2.1 执行流程 (Execution Flow)

启动 (Kickstart): 由调度器（QueueTicks）初始化帧，处理 2500+ 个对象的更新顺序。
并行分叉 (Fork):
- 传统对象: 在主线程更新。
- 并行任务: 启动数十个并发任务（AI 行为、Smart Objects 交互、Skeletal Mesh Ticking）。
关键子系统更新:
- Mass Entity System (大规模实体系统): 核心管理模块。负责 NPC 的 LOD 切换、寻路请求、以及 Smart Object 交互。
- AnimNext (新一代动画系统): 并行评估动画图 (AnimGraph)。
  - 关键机制: 动画计算在后台线程完成，然后向 Game Thread 注入 Finalization Tasks (终结任务) 来同步状态（如提取 Root Motion）。
- Mover (移动组件): 结合 Root Motion 和寻路信息进行并行模拟。同样需要注入 Finalization Tasks 回主线程同步位置。
Game Thread 绑定任务: 必须在主线程运行的系统，如流式加载 (Streaming)、PCG 生成、计时器管理 (Timer Manager)。
帧结束 (End of Frame): 打包数据发送给渲染线程。

2.2 关键优化数据

Mass to AnimNext Translator: 这是一个定制处理器，接管了 800+ 个骨骼网格体 (Skeletal Meshes) 的 Tick 逻辑，取代了传统的 Tick 行为。
并行效率:
- AnimNext 并行处理了 54ms 的工作量（若在单线程早爆了）。
- 主线程仅承担 2.66ms 的同步开销。
- Mover 并行模拟后，主线程仅需 1.3ms 进行同步。

3. Render Thread 架构：依赖图与光追优化

渲染线程同样遵循“移出关键路径”的原则，大量利用并行指令生成。

3.1 渲染流程

数据接收: 接收 Game Thread 的更新数据。
可见性与 Lumen: 更新可见性缓冲和 Lumen 场景描述。
构建 RDG (Render Dependency Graph):
- 核心术语: RDG 是 UE5 现代渲染管线的核心，通过构建依赖图来自动管理资源屏障和内存。
光线追踪数据处理:
- 场景中有 20,000+ 图元 (Primitives) 和数十万个实例 (Instances)。
- 优化: 数据收集和处理被移出关键路径，完全并行化执行。
并行指令转换 (Parallel Command List Translation):
- RDG pass 的执行被分发到多个线程。
- 数据支撑: 这一点至关重要，它分担了超过 16ms 的 CPU 工作量。如果不做这一步，渲染线程会因为 RHI (Render Hardware Interface) 瓶颈而卡死。

4. 性能概览与 CPU 预算 (Profiling & Budgeting)

基于 Unreal Insights 的分析数据，展示了在次世代主机（13个可用核心）上的实际表现。

4.1 极限压力场景 (300 NPCs)

CPU 利用率: 达到 87% (全核心)。
瓶颈分析:
- 空闲气泡 (Bubbles): 帧初期的 Worker 线程未饱和、物理模拟等待动画更新完成、RHI 提交时的串行等待。
- 关键路径: Game Thread 仍有约 2ms 的等待时间（等待动画和移动任务完成）。

4.2 平衡场景 (200 NPCs) - 推荐配置

通过减少 100 个 NPC，性能表现发生质变，展示了系统的线性扩展能力：

帧时间: 降至 11.5ms (远低于 16.6ms 的红线)。
CPU 利用率: 降至 60%。
Gameplay 预算:
- 这留出了约 5ms 的净空 (Headroom)。
- 这些空闲时间可以被用来填充更复杂的 Gameplay 逻辑，或者在物理模拟的等待间隙插入其他计算任务。

总结 (Key Takeaways)

这部分讲座传达了三个核心技术趋势：

ECS 化 (Entity Component System): 通过 Mass 系统管理大规模对象，是实现数百个高保真 NPC 的唯一出路。传统的 Actor::Tick 模式在大规模场景下已被淘汰。
异步注入模式 (Async Injection): 重计算任务（动画、移动）在 Worker 线程跑，只有极其轻量的“终结任务”回到主线程同步。这是 Game Thread 减负的关键模式。
RDG 的并行红利: 渲染线程不再是单线程提交指令。利用 RDG 进行并行的 Command List 录制是避免 Render Thread 瓶颈的必修课。

这是关于《巫师4》UE5 技术演示中 GPU 性能分析、异步计算策略以及全新的 Nanite 植被渲染管线 的深度技术总结。这一部分揭示了 Epic 如何通过架构层面的革新（如用骨骼动画替代 WPO 风场、引入体素化 LOD）来解决开放世界中最棘手的植被渲染瓶颈。

迈向 60 FPS：GPU 架构优化与 Nanite 植被革命

1. GPU 性能分析与异步计算 (Profiling & Async Compute)

为了挤出每一毫秒的性能，团队利用了 UE 5.6 全新的 Profiling 工具来最大化 GPU 的并发利用率。

1.1 Unreal Insights 5.6 新特性

双队列可视化: 现在的 GPU Profiler 可以同时显示 Graphics Queue (图形队列) 和 Async Compute Queue (异步计算队列)。
依赖关系追踪: 新增红色箭头显示不同队列中事件的 Dependencies (依赖关系)，这对于理解调度流 (Scheduling Flow) 和同步点至关重要。

1.2 异步计算策略 (Async Compute Strategy)

核心原理: GPU 的 Shader 单元很少能达到 100% 的资源利用率。Async Compute 允许在图形队列的空隙（Bubbles）中并发执行计算任务，以此缩短总帧时间。
Demo 中的优化成果:
- 节省时间: 约 1.5ms。
- 移入 Async 的任务: GPU Skin Cache 更新、风场模拟 (Wind Simulation)。
- 反直觉案例 (关键): 团队将 Lumen Reflections 从 Async 移回了 Graphics Queue。
  - 原因: 在反射计算时，没有足够的其他工作来与之重叠 (Overlap)，强行 Async 反而会导致开销增加。
- 工程教训: 不要盲目地将所有 Compute Shader 扔进 Async 队列。必须基于 Profiling 数据来决定调度策略。

2. 全新的 Nanite 植被渲染管线 (Experimental)

面对数十亿三角面的高密度森林，传统的植被渲染方法（Alpha Mask, WPO）在 Nanite 体系下已不再适用。团队为此研发了一套全新的渲染管线（预计 UE 5.7 进入主线）。

2.1 传统方法的痛点

Alpha Mask: 导致 Nanite 产生严重的 Overdraw (过度绘制)，且 Opacity Mask 函数开销昂贵。
几何体建模: 松针等细小物体若建模为几何体，会导致 Nanite 聚类 (Cluster) 效率低下。
WPO (World Position Offset): 极其不适合 Nanite。
- 原因: 顶点位置不可预测，导致 Cluster Bounds (包围盒) 必须设置得非常保守，严重破坏剔除效率。

2.2 解决方案：Nanite + Skeletal Mesh

核心技术 1：Nanite Assemblies (部件组装)
- 原理: 将树木拆分为多个“树枝”实例的组合。
- 优势: 解决了磁盘占用问题。即便是一棵 4100万三角形 的“英雄树”，也可以通过复用 2000 多个枝干实例高效存储。
核心技术 2：无缝体素化 (Seamless Voxelization)
- 原理: 在远处，Nanite 不再渲染三角形，而是无缝切换为 Pixel-sized Voxels (像素级体素)。
- 效果: 解决了远处极高密度几何体的抗锯齿和渲染效率问题，且视觉上不可察觉。
核心技术 3：骨骼动画风场 (Bone-driven Wind)
- 变革: 废弃 WPO，改用 Skeletal Mesh (骨骼网格体) 驱动风场。
- 优势: 可以使用 Fixed Function Nanite (固定管线 Nanite)，拥有最优的 Cluster Bounds。
- 性能: 整个视口 10万根骨骼的更新仅需 0.1ms (GPU Compute Shader)。

3. Nanite 性能优化实战技巧 (Best Practices)

Kevin 分享了针对 Nanite 的底层优化原则，核心在于减少软件光栅化的开销和避免 Helper Lanes。

3.1 减少 Helper Lanes (辅助像素)

背景: GPU 通常以 2x2 像素块 (Quad) 为单位计算微分。对于高密度网格，这会产生大量无效的 Helper Lanes。
优化: 尽可能使用 Analytical Derivatives (解析微分)。
- 这允许 Nanite 跳过 Helper Lanes 的启动，大幅减少 Pixel Shader 的调用次数。
工具: 使用 Nanite Visualizer -> Overdraw 或 Stats 检查 Helper Lanes 数量（目标是接近 0）。

3.2 保持“快速路径” (Fast Path)

原则: 避免使用 Programmable Rasterization (可编程光栅化)。
避免: Masked 材质、WPO、Pixel Depth Offset (PDO)。这些特性会迫使 Nanite 退出高效的固定管线模式。
工具: 使用调试视图检查哪些物体是非 Fast Path。

3.3 谨慎使用 Tessellation (曲面细分)

风险: 如果材质中的 Displacement Range (置换范围) 设置得比实际效果大，会导致 Nanite 极大地扩张 Cluster Bounds，导致剔除失效和光栅化浪费。
案例: 本 Demo 仅在地形 (Landscape) 上使用了 Nanite Tessellation。

总结

植被渲染的范式转移: 我们正在见证从“插片+WPO”向“全几何体+骨骼动画”的转变。通过 Nanite Assemblies 和 Voxels，实现了真正的无限几何细节。
GPU 调度的精细化: Async Compute 不再是“银弹”，需要像玩俄罗斯方块一样，根据具体的 Pass 耗时和依赖关系进行精细填空。
硬件友好的材质编写: 美术资源的制作必须更懂硬件（如避免 WPO 以优化 Bounds，使用解析微分以减少 Quad Overdraw），这需要 TA 和引擎程序制定严格的规范。

这一章节详细解释了如何在有限的显存和计算预算下，利用 分层结构 (Tiered Structure) 和 代理几何体 (Proxies) 来实现全动态的次世代光照。

Lumen 与硬件光线追踪：60 FPS 的优化艺术

1. 光追场景架构 (Ray Tracing Scene Architecture)

为了在主机上维持性能，Demo 并没有将所有物体放入同一个光追结构中，而是采用了近景与远景分离的策略。

1.1 近场 (Near Field)

范围: 摄像机周围 $150 m$ 。
内容: 包含地形、植被、静态网格体和动态几何体。
预算管理:
- RT Geometry Pool: 预算约 400MB (实际峰值约 300MB)。
- 更新开销: 约 $0.5 m s$ ，全部运行在 Async Compute (异步计算) 上，不占用图形队列时间。

1.2 远场 (Far Field)

结构: 独立的 TLAS (Top Level Acceleration Structure)。
内容: 仅包含静态几何体（如 HLODs、地形、大型布景）。
优化策略:
- 无需逐帧更新: 因为全是静态物体。
- 仅遮蔽 (Occlusion Only): 在远场追踪时，Lumen 被配置为仅计算遮蔽可见性，而不计算击中点的光照着色 (Lighting)，大幅降低开销。

2. 动态物体处理策略 (Dynamic Geometry)

动态物体（角色、变形地形）是光追更新 (BLAS Update/Refit) 的性能杀手。

2.1 角色与骨骼网格体

挑战: 场景中角色众多，全量更新会导致 RT Scene Update 爆炸。
交错更新 (Staggered Updates):
- 限制每帧更新的动态三角形数量（约 40,000 个）。
- 优先更新靠近摄像机的重要角色。
GPU Skin Cache 优化:
- Skin Cache 运行在 Async Compute 上。
- 按需计算: Skin Cache 的更新与光追场景绑定。如果角色不在光追场景中（被剔除），则完全不进行蒙皮计算，避免浪费计算资源。

2.2 地形 (Landscape)

处理方式: 地形被视为动态物体（因为涉及 LOD 变形）。
优化: 采用时间分片 (Time-sliced) 更新 LOD，并且在光追场景中使用比主视野更低 LOD 的网格。

3. 植被的特殊光追管线 (Foliage Proxies)

这是针对大规模森林场景的核心优化。

痛点: 4100万面的“英雄树”如果直接进光追结构，或者在光追中做风场动画，性能无法承受。
解决方案: Ray Tracing Proxies (光追代理)。
实现原理:
- 不进行动画: 光追场景中的树木是静止的（放弃树叶微动，换取性能）。
- 几何体云 (Triangle Cloud): 不使用原始网格，而是生成一个能近似匹配原物体遮蔽密度 (Occlusion Density) 的简化三角云。
- 极致简化: 4100万面的树 $\to$ 光追中仅 225 个三角形。
权衡: 这种近似在镜面反射中效果较差（看着像一团块），但在粗糙反射和水面反射（有波纹掩盖）中效果完全可以接受，且极大地保证了间接光照（GI）的正确遮蔽。

4. Lumen 性能陷阱与解决方案

Kevin 列举了两个常见的导致 Lumen 性能骤降的场景及其修复方案。

4.1 陷阱一：无限制的反射光线 (Unbounded Reflection Rays)

问题: 对于高光泽度（低 Roughness）材质，Lumen 会发射昂贵的硬件光线追踪反射。如果满屏都是湿漉漉的泥地或水坑，开销巨大。
优化: Roughness Threshold (粗糙度阈值)。
- 设定一个阈值（例如 0.4）。
- 机制: 粗糙度高于此值的像素，不再发射光追光线，而是回退到 Lumen Radiance Cache (辐射缓存) 进行插值查询。
- 收益: 速度提升 3倍，且视觉差异几乎不可察觉。

4.2 陷阱二：单层水体下的过度计算 (Single Layer Water)

问题: 渲染半透明水体时，Lumen 会先计算水底物体的光照，再计算水面的光照。且水底物体通常是“湿润”的（低粗糙度），会触发上述的昂贵反射计算。
优化: 深度剔除 (Depth Culling)。
- 提供一个深度阈值，将深水区域视为不透明 (Opaque)。
- 机制: 直接剔除深水区域下方的 Lumen 贡献计算。
- 收益: 在深水场景（如湖泊、海洋）中节省超过 $1 m s$ 。

5. 建议：拥抱硬件光追 (HW vs. SW)

讲座最后明确了 Epic 的技术路线图：Hardware Ray Tracing (HW RT) 是未来。

不再推荐软件光追 (Software Tracing):
- 软件光追依赖 Mesh Distance Fields (网格距离场)，这需要额外的内存，且不支持骨骼动画。
- 很难同时维护两套光照资产（一套给 SDF，一套给三角形）。
硬件光追优势:
- 质量: 更高的求交精度。
- 功能: 原生支持骨骼网格体 (Skeletal Meshes)。
- 内存: 可以删除静态距离场数据，节省大量内存。
实证: 《堡垒之夜》已在当前主机上以 60 FPS 运行硬件光追 Lumen，证明了其成熟度。

💡 核心术语表

TLAS (Top Level Acceleration Structure): 顶层加速结构，用于组织场景中的实例。
Ray Tracing Geometry Pool: 专门用于存储光追几何体数据的显存池。
Async Compute: 异步计算，利用 GPU 空闲算力并行处理非图形任务。
Lumen Radiance Cache: Lumen 的低频光照缓存，用于处理漫反射或高粗糙度反射，速度快但细节少。

迈向 60 FPS：VSM 阴影优化与 TSR 分辨率策略

1. 虚拟阴影贴图 (Virtual Shadow Maps - VSM) 优化

VSM 与 Nanite 是天作之合，但在动态且树木茂密的开放世界中，阴影渲染开销巨大。团队通过以下 bespoke（定制）优化来降低消耗。

1.1 几何体与剔除优化

Nanite Voxel Representation: Nanite 自身的体素化表示天然加速了阴影深度的渲染。
Receiver Masks (接收者遮罩):
- 原理: 将每个 VSM 页面 (Page) 细分为 64 个 Tiles 进行更紧密的剔除 (Culling)。
- 效果: 显著降低阴影深度 (Shadow Depth) 渲染成本，且不改变视觉效果。
静态缓存策略 (Static Caching):
- 远处的树木停止动画 $\to$ 标记为静态 $\to$ 阴影贴图可以被缓存，无需每帧重绘。

1.2 动态质量平衡 (Automatic Quality Balancing)

景深感知降质 (DOF-aware Quality Drop):
- 在对话或过场动画中，位于焦外 (Out of Focus) 模糊区域的阴影自动降低 VSM 质量。
- 收益: 为高质量的角色面部特写腾出 GPU 预算。
VSM Throttling (VSM 节流阀):
- 问题: 传统动态分辨率 (Dynamic Res) 是“全屏连坐”，一旦阴影变慢，整个画面分辨率都下降。
- 方案: 当阴影超预算时，优先仅降低 VSM 的质量/分辨率，保持主画面清晰度。

1.3 非 Nanite 物体优化 (Non-Nanite Optimization)

GPU Skin Cache Bounds:
- 在计算蒙皮时，顺便在 GPU 上重新计算精确的包围盒 (Bounds)。
- 收益: 比 CPU 端保守的包围盒更紧凑，大幅提升了剔除效率。

2. 分辨率与上采样策略 (Resolution & Upscaling Strategy)

为了在 4K 输出下维持 60 FPS，团队设计了一套复杂的两级上采样流水线。

2.1 基础架构：TSR (Temporal Super Resolution)

主分辨率 (Primary Resolution): 渲染几何体、光照的基础分辨率。
动态分辨率 (Dynamic Resolution): 根据上一帧的 GPU 耗时，动态调整主分辨率。
- 范围: 800p ~ 1080p。
- 逻辑: 设定在 1080p 是为了保证 TSR 的上采样倍率控制在 2x 以内（这是保证画质的甜点区）。

2.2 创新点：二级屏幕百分比 (Secondary Screen Percentage)

为了避免后处理 (Post Processing) 在 4K 下产生的巨大开销，引入了二级缩放。

流程对比:
- 传统做法: 1080p (渲染) $TSR $ 4K (后处理 & UI)。
  - 缺点: 后处理 pass 在 4K 下极慢。
- Demo 做法: 1080p (渲染) $TSR $ 1440p (后处理) $Sp a t ia l U p sc a l e $ 4K (UI)。
收益: 节省了约 1ms 的 GPU 时间。
权衡: 牺牲了一点点后处理的锐度，但比让动态分辨率降低主渲染分辨率（导致主画面变糊）要划算得多。

3. 抗卡顿与稳定性 (Hitching Mitigation)

虽然平均帧率达标，但在镜头切换 (Camera Cuts) 时极易掉帧。

3.1 镜头切换掉帧的原因

历史数据丢失: 遮挡剔除 (Occlusion Culling) 依赖上一帧的深度数据 (HZB)。
过绘制爆炸: 镜头突变后，没有上一帧数据做剔除，GPU 必须渲染视锥体内的所有东西，导致严重的 Overdraw。

3.2 解决方案：数据预热 (Priming)

Ray Tracing Priming:
- 在镜头切换后的第一帧，利用光线追踪场景 (Ray Tracing Scene) 的低分辨率数据来“伪造”深度信息。
- 效果: 虽然不如真实的上一帧数据完美，但比完全裸奔要好得多，显著减少了 Overdraw 导致的峰值卡顿。

总结 (Final Takeaways)

通过这部分讲座，我们看到了 CDPR 和 Epic 如何通过精细化的预算管理来达成技术指标：

分级降质: 不是所有东西都需要高质量。焦外的阴影、远处的树木都可以牺牲，把算力留给刀刃（近景角色、光照）。
分辨率不再是单一数字: 理解 Primary Resolution (渲染) vs Secondary Resolution (后处理) vs Output Resolution (显示) 的区别，并在其中找到最佳的性能/画质平衡点，是现代图形优化的关键。
消除峰值 (Flattening the Curve): 60 FPS 不止是平均帧率，更重要的是消除最差帧 (Worst Case)。VSM Throttling 和 Camera Cut Priming 都是为了“削峰填谷”。

NothingToSay0031

Explorer

Graph View

《巫师4》UE5 技术演示：迈向 60 FPS 之路