Unreal VR 渲染管线与立体渲染

引言

Unreal 的 VR 渲染管线和其他引擎最大的不同，是它把立体渲染做进了渲染器的底层，而不是在相机层复制一次渲染。开启 Instanced Stereo 后，一次 DrawCall 同时渲染左右眼，顶点着色器根据实例索引选择视图矩阵，CPU 提交开销几乎不翻倍。

但 Unreal 也带来独特的麻烦：延迟着色与 VR 天然冲突、后处理在立体渲染下容易出现双眼不一致、Temporal Anti-Aliasing（TAA）在头部运动时会产生鬼影。这些问题的根源在于「为平面屏幕优化的管线」被强行搬到 XR 场景。

本文按「立体渲染模式 → 着色路径 → 后处理 → 注视点渲染 → 时间扭曲 → 帧预算与配置」的顺序展开，重点给出 DefaultEngine.ini 配置与 console 变量，并说明每个开关的代价。渲染管线的通用原理可参考 延迟渲染与 Tiled/Clustered 光照剔除 ，网格着色器等新特性见 网格着色器与次世代渲染 。

目录

1. UE 的 XR 支持现状
2. 立体渲染的三种模式
3. Instanced Stereo 的实现原理
4. Mobile Multi-View 与移动端
5. 延迟着色的 VR 困境
6. 前向与前向+ 着色
7. 后处理与立体渲染冲突
8. 固定注视点渲染
9. 时间扭曲与 Late Latching
10. 帧预算与关键配置
11. 性能分析工具
12. 项目设置清单
13. 权衡取舍
14. 常见坑清单
15. 小结

1. UE 的 XR 支持现状

Unreal 的 XR 支持分两条线：

UE 5.x 已把 OpenXR 作为默认 XR 后端，厂商插件更多是提供平台专属功能（如 Meta 的手部追踪、空间锚点、Passthrough 合成层）。

一个必须提前确认的事：UE 的 VR 模板默认使用延迟着色（Deferred Shading），而在一体机上延迟着色基本不可用，必须切到前向渲染。这是新手最常见的性能灾难来源。

2. 立体渲染的三种模式

; DefaultEngine.ini
[/Script/Engine.RendererSettings]
vr.InstancedStereo=True
vr.MobileMultiView=True
vr.PixelDensity=1.0

选择规则很简单：PC VR 用 Instanced Stereo，一体机用 Mobile Multi-View。两者可以同时开启，引擎会按平台自动选择。

Multi-Pass 只应在兼容性兜底时使用，因为它在 CPU 侧让 DrawCall、剔除、阴影提交全部翻倍，在中低端 PC 上直接成为瓶颈。

2.1 如何验证立体渲染真的生效

配置写了不代表生效，必须实测：

1. stat rhi           → 看 DrawCall 数是否接近单眼水平（而非两倍）
2. RenderDoc 抓帧     → 检查是否存在两个独立的渲染通道
3. stat unit          → Draw 时间应远小于 Game 与 GPU
4. 日志搜索           → 打包日志中搜索 "Instanced Stereo enabled"

如果 DrawCall 数接近单眼的两倍，说明立体模式没生效，常见原因是平台不支持、插件冲突，或渲染器设置被项目默认值覆盖。

3. Instanced Stereo 的实现原理

Instanced Stereo 把双眼当作同一网格的两个实例：

// 引擎内部示意：顶点着色器按实例索引选择视图
#if INSTANCED_STEREO
    uint eyeIndex = GetStereoEyeIndex();       // 0 或 1
    float4x4 View = StereoViews[eyeIndex].ViewMatrix;
    float4x4 Proj = StereoViews[eyeIndex].ProjMatrix;
    float4 ClipPos = mul(mul(mul(float4(Pos,1), M), View), Proj);
#endif

关键收益：

• DrawCall 数不变：一次提交渲染两眼，CPU 侧剔除也只做一次。
• 阴影与光照可共享：视锥差异小，阴影贴图可复用。
• GPU 开销仍近似翻倍：像素数确实翻倍，这是物理必然。

因此 Instanced Stereo 解决的是 CPU 瓶颈，不解决 GPU 瓶颈。如果瓶颈在 GPU，要做的是降分辨率、注视点渲染、减光源，而不是调立体模式。

4. Mobile Multi-View 与移动端

移动端的 Multi-View 走的是「纹理数组 + 单次绘制」路线：

; 移动端关键配置
[/Script/Engine.RendererSettings]
r.MobileHDR=True
r.Mobile.ShadingPath=0            ; 0 = 前向
r.Mobile.EnableStaticAndCSMShadowReceivers=True
r.Mobile.AllowDistanceFieldShadows=False
vr.MobileMultiView=True

移动端要额外注意：

• 必须前向着色：移动渲染器本身只支持前向，这也顺便避开了延迟着色的 VR 问题。
• 阴影开销大：移动端建议只保留一个方向光阴影，其余用烘焙。
• MSAA 优于 TAA：移动端 TAA 成本高且鬼影明显，用 MSAA 4x 更稳。

4.1 移动端分辨率策略

; 动态分辨率（配合注视点渲染）
r.MobileContentScaleFactor=0.8     ; 相对原生分辨率
r.MobileDynamicResolution=1
r.Mobile.DynamicResolution.MinScreenPercentage=70
r.Mobile.DynamicResolution.MaxScreenPercentage=100

内容缩放系数是最简单有效的性能旋钮：0.8 意味着渲染像素减少 36%，而在一体机上观感损失有限，因为镜片本身会做光学模糊。

5. 延迟着色的 VR 困境

延迟着色在 VR 里有四个硬问题：

1. G-Buffer 带宽翻倍：双眼各自需要 G-Buffer，移动 GPU 的带宽本就紧张。
2. MSAA 不可用：延迟着色与 MSAA 天然不兼容（G-Buffer 无法多重采样），只能靠 TAA，而 TAA 在 VR 里鬼影严重。
3. 透明物体仍需前向：延迟管线里透明物体要单独走前向路径，管线变复杂。
4. 立体渲染支持差：Instanced Stereo 对延迟着色的支持有额外限制，容易出现双眼不一致。

结论：VR 项目默认不要用延迟着色。UE 里通过以下配置切到前向：

[/Script/Engine.RendererSettings]
r.DefaultFeature.Bloom=True
r.Mobile.ShadingPath=0                 ; 移动端前向
r.ForwardShading=True                  ; PC 端前向（UE5 用 r.ForwardShading）
r.MSAACount=4                          ; 开启 MSAA

PC 端 UE5 的前向渲染由 r.ForwardShading=1 开启，配合 r.MSAACount=4 获得干净的边缘，代价是复杂光照场景下性能下降，需要控制实时光源数量。

5.1 带宽估算

延迟着色的代价可以直接算出来：

G-Buffer 典型布局（每像素）：
  BaseColor 32 bit + Normal 32 bit + Roughness/Metallic 16 bit
  + Depth 32 bit + Velocity 16 bit ≈ 128 bit = 16 字节

Quest 3 单眼 2064×2208 ≈ 4.55 M 像素
单眼 G-Buffer 写入  = 4.55M × 16 B ≈ 73 MB
双眼 G-Buffer 写入  = 146 MB（写入一次）
加上后续光照读取（再读一遍）→ 约 292 MB 每帧

90 Hz → 26 GB/s 仅用于 G-Buffer
Quest 3 内存带宽约 68 GB/s（LPDDR5 共享）

结论一目了然：光 G-Buffer 就吃掉近 40% 的整机内存带宽，再叠加纹理采样与帧缓冲，必然成为瓶颈。这就是移动 VR 必须用前向的根本原因。

6. 前向与前向+ 着色

前向渲染的主要缺点是「每像素对所有光源计算」，光源多时开销线性增长。解决方案是分簇光照剔除（Clustered Forward）：

在 UE 里，前向渲染配合 r.ForwardShading=1 已包含分簇光照路径，因此在 VR 场景里可以放心用几十个动态光源，只要它们不集中在同一簇内。

工程经验值（一体机）：

实时光源（带阴影）  : ≤ 1 个方向光
实时光源（无阴影）  : ≤ 8 个
烘焙光源            : 不限
反射捕获            : ≤ 2 个

7. 后处理与立体渲染冲突

后处理是 VR 里最容易出问题的一环，因为很多后处理算法假设单视图：

; VR 必须关闭的后处理
r.DefaultFeature.MotionBlur=False
r.DefaultFeature.AutoExposure=False    ; 自动曝光在 VR 里造成亮度跳变
r.DepthOfFieldQuality=0
r.LensFlareQuality=0
r.SSR.Quality=0

自动曝光必须关闭：头部转动导致画面内容变化，自动曝光会不断调整亮度，产生「忽明忽暗」的强烈不适。固定曝光并在关卡里手动调好亮度。

7.1 立体渲染下的后处理执行顺序

UE 的后处理链在 XR 下会插入「按眼分离」的步骤，理解顺序有助于定位问题：

1. 基 Pass 渲染（双眼，Instanced / Multi-View）
2. 逐眼后处理（Bloom、色调映射等在眼内独立完成）
3. 立体合成：写入双眼纹理数组
4. 交给运行时：畸变校正 + 时间扭曲 + 面板输出

易错点：
  屏幕空间效果若在步骤 1 与 2 之间做了跨眼全屏采样，
  会把另一只眼的像素采进来，产生「幽灵影像」。

判断方法：单独遮住一只眼，若另一只眼的画面出现异常内容，说明存在跨眼采样错误。

8. 固定注视点渲染

UE 支持固定注视点渲染（FFR），在一体机上收益显著：

; 固定注视点渲染
vr.PixelDensity=1.0
r.FoveationMethod=2              ; 2 = 固定注视点
r.FoveatedRendering.Pattern=0    ; 0 = 中心优先
vr.FoveationLevel=2              ; 0~4，越高越激进

收益参考（Quest 2 实测量级）：

推荐从等级 2 开始，在真机上让非开发者试戴判断。动态注视点渲染（DFR） 需要眼动数据，UE 里通过厂商插件或 OpenXR 扩展接入，收益比 FFR 多 10 到 15 个百分点，但依赖眼动可靠性，眼动精度与延迟的硬件基础见 XR 显示光学与头部眼动追踪 。

9. 时间扭曲与 Late Latching

Unreal 支持 Late Latching，把「读取最新头部位姿」的时刻推迟到 GPU 提交前的最后一刻：

; Late Latching（需要 OpenXR / 厂商插件支持）
vr.LateLatching=True

原理是让渲染命令缓冲中的视图矩阵延迟到最后一刻才写入，从而用更接近光子出射时刻的位姿。代价是需要驱动与图形 API 支持（Vulkan 与 D3D12 支持较好），并且会占用一部分命令缓冲的灵活性。

时间扭曲本身由运行时（OpenXR 运行时或厂商合成器）完成，应用侧不需要实现，但要注意：

• 时间扭曲只能处理旋转（旋转可以重投影），位置变化无法修正，因此玩家平移时的延迟仍会暴露。
• 时间扭曲需要深度信息才能做正确的前后关系，UE 会输出深度供合成器使用。

图形 API 层面的同步细节可参考 Vulkan 命令缓冲与同步 ，这对理解 Late Latching 的实现约束很有帮助。

9.1 时间扭曲能修什么

时间扭曲的数学本质：用新位姿重投影旧图像
  p_new = K · R_new · R_old⁻¹ · K⁻¹ · p_old

能修正：
  头部旋转（绕 X/Y/Z 任意轴）        ← 完全可修正
  轻微平移（用深度做视差补偿）        ← 部分可修正，边缘易露馅

不能修正：
  大范围平移（走出原图像范围）
  物体自身运动（属于应用逻辑，非相机）
  遮挡变化（新出现的区域没有像素）

因此「位置追踪的延迟」是时间扭曲的盲区。这也是为什么坐姿或小范围站立的 VR 体验明显优于大空间走动：平移量小，盲区暴露得少。舒适度设计的完整讨论见 VR 舒适度与晕动症工程对抗 。

10. 帧预算与关键配置

以 Quest 3 的 90 Hz（11.1 ms）为例：

关键 console 变量：

stat unit              → 查看 Game / Draw / GPU 三个时间
stat gpu               → GPU 各阶段耗时明细
stat rhi               → DrawCall、三角形、显存
r.ScreenPercentage 80  → 降分辨率（最有效的手段之一）
r.Shadow.MaxResolution 1024
r.VolumetricFog 0      → 体积雾在移动端极贵
r.SSR.Quality 0
r.SkinCache.CompileShaders 1

stat unit 的三行数值就是排障起点：Game 高说明 CPU 逻辑重，Draw 高说明提交多，GPU 高说明着色贵。

11. 性能分析工具

一体机上推荐用 ODH 的实时监视叠加，它直接显示 GPU 时间、帧率与温度，是快速判断「是否已降频」的最方便手段。

12. 项目设置清单

一份可直接抄的 VR 项目配置：

[/Script/Engine.RendererSettings]
r.ForwardShading=True
r.MSAACount=4
r.DefaultFeature.MotionBlur=False
r.DefaultFeature.AutoExposure=False
r.DefaultFeature.Bloom=True
r.Shadow.CSM.MaxCascades=1
r.Shadow.MaxResolution=1024
r.SSR.Quality=0
r.VolumetricFog=0
r.SkinCache.CompileShaders=1

vr.InstancedStereo=True
vr.MobileMultiView=True
vr.PixelDensity=1.0
vr.FoveationLevel=2
vr.LateLatching=True

[/Script/Engine.PhysicsSettings]
bSubstepping=True              ; 物理子步进，避免高速物体穿透

物理子步进在 VR 里尤其重要：低帧率下物体高速运动会穿透，而 VR 里玩家挥动手柄的速度很快。

12.1 设备配置文件分层

用 Device Profiles 为不同设备维护不同配置，避免一份配置通吃：

; DefaultDeviceProfiles.ini
[Quest3 DeviceProfile]
+CVars=r.MobileContentScaleFactor=0.85
+CVars=vr.FoveationLevel=2
+CVars=r.Shadow.MaxResolution=1024

[Quest2 DeviceProfile]
+CVars=r.MobileContentScaleFactor=0.75
+CVars=vr.FoveationLevel=3
+CVars=r.Shadow.MaxResolution=512

分层的价值在于同一份内容能在多代设备上跑，旧设备自动降级而不是掉帧。打包前务必用 -deviceprofile 参数验证目标设备的配置真的被应用。

13. 权衡取舍

• 延迟与前向：延迟光源多但 VR 不友好，前向光源少但立体渲染干净，VR 选前向。
• Instanced Stereo 与 Multi-Pass：前者省 CPU 但需平台支持，后者兼容但翻倍。
• TAA 与 MSAA：前者省性能但鬼影，后者干净但昂贵，VR 优先后者。
• FFR 等级：等级越高省越多但边缘越糊，从 2 开始按真机观感调。
• Late Latching：降低延迟但依赖驱动支持，且调试更困难。
• 动态分辨率与固定分辨率：前者保帧率但画质波动，后者稳定但可能掉帧。
• 内容缩放与注视点渲染：两者都省 GPU，可叠加但叠加后边缘质量下降明显。

14. 常见坑清单

• 用默认延迟着色做 VR：G-Buffer 带宽爆炸且 MSAA 不可用，必须切前向。
• 开着运动模糊：VR 里必然引起不适，必须关闭。
• 开着自动曝光：转头时亮度跳变，必须关闭并固定曝光。
• 后处理链过长：每级后处理都是全屏采样，立体渲染下成本翻倍。
• 体积雾未关：移动端单帧可能多耗 3 到 5 ms，是最常见的性能黑洞。
• 阴影级联数过多：VR 视锥宽，多级联浪费，建议 1 级。
• 忽视 Late Latching 的平台差异：部分驱动不支持，需做能力检测。
• 物理不做子步进：快速挥动手柄导致物体穿透，交互手感崩坏。
• 用 TAA 而不看鬼影：头部运动时的拖影会被用户直接感知为「画面脏」。
• 只在编辑器里测性能：编辑器开销与打包版本差异大，必须用打包版本在真机测。

15. 小结

Unreal 的 VR 渲染主线是：切前向着色 → 开启 Instanced Stereo 或 Mobile Multi-View → 关掉 VR 不友好的后处理 → 打开固定注视点渲染 → 用 stat unit 定位瓶颈 → 按瓶颈降分辨率或减光源。所有优化的前提是先定位瓶颈在 CPU 还是 GPU，否则容易在错误的方向上花时间。

三个最有效的单点改动：内容缩放系数降到 0.8、注视点渲染开到等级 2、关闭体积雾。这三项在一体机上通常能一起带来 30% 以上的帧时间下降。

下一步如果要在移动芯片上做更系统的性能预算管理，读 一体机 XR 性能优化实战 ；如果关注交互层的实现，读 Unity XR Interaction Toolkit 交互体系 。

延伸阅读

• 一体机 XR 性能优化实战 — 移动端性能预算
• XR 显示光学与头部眼动追踪 — 注视点渲染的硬件基础
• 延迟渲染与 Tiled/Clustered 光照剔除 — 着色路径的原理
• Vulkan 命令缓冲与同步 — Late Latching 的 API 基础