深度网格投影与360立体渲染：UE5 VR性能与分发实战指南

戴上头显的那一刻，画面突然卡成了幻灯片。这是很多 UE 工程师第一次把普通场景跑进 VR 时的共同记忆。桌面上明明有 100 多帧，进了头显剩下不到 40 帧，原因大家都懂：同一个场景要渲染两遍，左眼一遍、右眼一遍，再加上畸变校正、透视重投影、空间扭曲这些额外开销，性能直接对半砍。

做 VR 内容的人，每天都在跟两个基本问题较劲：一个是怎么在双倍渲染成本下保住足够高的帧率，另一个是怎么把做好的沉浸式内容变成能被播放器、手机、VR 眼镜和视频平台直接消费的 360 立体视频。这两个问题的答案，最终都指向同一个方向——深度网格投影（Depth Mesh Projection）与 360 立体渲染（360 Stereoscopic Rendering）。这两个词听起来偏渲染底层，但它们一个决定 VR 项目的性能上限，一个决定内容的分发上限，是 UE5.8 VR 工具链里真正值得投入时间理解的东西。

这篇文章以 UE5.8 的 VR 项目流程为背景，把两条技术线拆开讲：先讲清楚它们各自解决什么问题，再给你一套从深度数据接入、网格生成，到双目采集、360 立体成片的完整落地流程。如果你当前用的还是 UE5.4、5.5、5.6，文章里的核心流程同样适用，因为这两条技术线的底子在 UE5 时代是一致的。

1. 这篇文章真正要解决的问题

先说性能问题。VR 渲染的原因很简单，但不解决就会一直痛：双眼渲染意味着顶点处理、像素着色、半透明排序、后处理全部翻倍；头显还要求帧率稳定在 90 FPS 左右，低于这个值用户就会觉得晕。传统优化三板斧——LOD、遮挡剔除、实例化——确实有用，但都属于“把场景尽量变少”的思路。深度网格投影是完全不同的思路：它不再逃避深度数据，而是主动把深度作为渲染输入，用最少的三角形表达真实需要的几何，或者把昂贵的光照与遮挡计算折算成一次深度采样。

再说分发问题。你在头显里跑起来的是一个可交互的 VR 应用，但用户并不一定都有高端头显。大多数用户接触 VR 内容的方式，是看一段 360 立体视频，或者用一个轻量级网页播放器。把一个实时 VR 应用变成一段符合通用格式的 360 立体视频，涉及等距柱状投影、双目视差、左右眼同步、码率和格式封装一系列问题。这跟“在引擎里看到立体画面”完全是两个技术栈。

因此，本文适合这几类读者：

• 正在用 UE5 做 VR/XR 项目，纠结帧率和画面质量的开发者；
• 做虚拟拍摄、MR 混合现实场景重建、深度相机接入的工程师；
• 需要把 VR 内容输出为 360 全景视频，交付给播放器或视频平台的团队；
• 想系统理解 VR 渲染原理，而不是只会拖蓝图节点的初学者。

下面先解决认知问题：这两个概念到底是什么。

2. 深度网格投影的核心概念

2.1 深度图：一像素记录一段距离

深度图并不神秘。普通照片每个像素记录颜色（RGB），深度图的每个像素记录的是“这个位置离相机有多远”。在 UE 里，场景渲染时本来就会产生一份深度缓冲，也就是常说的 Scene Depth。它平时主要用来做前后遮挡判断，渲染完这一帧就被丢弃了。

深度网格投影的第一步，就是把这份“用完即弃”的深度数据捞出来，变成可以持久使用的几何数据。捞出来的方式有两种：一是在材质阶段直接采样 Scene Depth 做效果；二是把深度数据读回 CPU 或 GPU，重建出一张网格。

2.2 网格投影：从二维深度到三维几何

“投影”这个词容易让人误解。它说的不是把图片贴到球上，而是反过来——把二维图像里的深度信息，反投影回三维空间，还原出每个像素对应的世界坐标。这一步在图形学里叫反投影（Unprojection），数学上就是用一个逆投影矩阵把 NDC 坐标转换回视空间，再乘上深度。

有了世界坐标，再按照像素的邻接关系连成三角形，就得到一张“深度网格”。它可以是粗糙的代理几何，也可以是高精度的实时重建结果。之所以强调“投影”，是因为整个过程严格依赖相机内外参数，投影矩阵一旦和深度数据不匹配，生成的网格就会变形或者错位。

2.3 它到底解决了什么问题

深度网格投影在实际项目里最常见的三种用途：

第一，MR 遮挡。在混合现实场景里，虚拟物体需要被真实世界的桌子、墙壁挡住，才算真实。用 MR 设备提供的真实场景网格，或者用深度相机实时重建一层代理网格，就能让虚拟角色正确地从真实沙发后面走出来。这是深度网格投影最典型的应用。

第二，实时场景重建。LiDAR、ToF 深度相机输出的是深度帧，单独看没有意义，累积起来重建出房间结构，才能用于导航、避障和空间漫游。UE 里跑这种功能，绕不开把深度帧变成网格这一步。

第三，360 视频的视角合成。视频流里除了颜色画面，再带上深度图，播放端可以根据用户转头角度，用深度网格重新投影出新的视角。这是全景视频领域的一种压缩与交互手段，也是“深度网格投影”这个词在内容分发侧的含义。

2.4 常见误解

需要澄清两个误区。

其一，深度网格投影不是 Z-Prepass。Z-Prepass 是提前写深度、减少像素着色开销的一种渲染优化，它不产出几何。深度网格投影是产出新几何的完整流程，两者层级完全不同。

其二，不是每一帧都要重建整张网格。实时场景重建往往只在环境变化时更新，或者用较低频率的异步任务更新。每帧全量重建深度网格，在移动端 VR 上基本撑不住。更常见的做法是维护一张长期有效的代理网格，按需增量更新。

3. 360 立体渲染的核心概念

3.1 “360”和“立体”是两回事

很多人容易把 360 视频和立体视频混为一谈，其实这是两个独立维度。

360 解决的是“看全”的问题。它用等距柱状投影（Equirectangular Projection）把整个球面视野摊平成一张 2:1 的平面图。你先在引擎里渲染六个面或者直接渲染成全景图，再转换成这种经纬度映射的格式。分辨率、码率、拼接缝都是这个环节的坑。

立体解决的是“看深”的问题。它模拟人的双眼，用两套相机分别渲染左右眼画面，两幅图之间存在视差。用户的大脑中会把视差合成为深度感，离得近的物体左右眼差异大，远的差异小。

一个 360 立体视频，必须同时满足这两个条件：画面覆盖 360 度，且每一度都有左右眼视差。

3.2 常见的立体封装格式

在实际交付中，左右眼画面必须封装在一个文件或标准结构里。最常见的几种：

选择格式取决于目标平台。视频平台通常只支持其中一两种，项目启动前就应该确认交付格式，而不是等渲染完再转。

3.3 瞳距与视差的关系

立体感的强度取决于左右眼相机的间距，也就是瞳距（IPD）。成年人平均瞳距大概在 6.3 厘米左右，这个值直接作为虚拟相机的左右偏移基准。偏移太近，立体感弱；偏移太远，用户看久了会晕。在引擎里搭建双目采集 rig 时，默认用 0.063 米作为左右眼的偏移量，再根据目标设备或播放端风格微调。

从实时 VR 渲染到 360 立体视频，中间只隔着一层封装：实时渲染时，头显直接提供左右眼 view matrix；输出视频时，需要自己把左右眼两套相机渲染到两张离屏 RT 上，再合成到标准格式里。理解了这一步，整个链路就通了。

4. UE5.8 VR 开发环境准备

4.1 硬件与系统

做 VR 开发至少需要一台能够稳定跑目标场景的 PC。NVIDIA RTX 系列显卡对 VR 的帧生成和超分辨率支持比较成熟，内存建议 32GB 起步。头显方面，无论是 Meta Quest 系列、SteamVR 设备，还是其他支持 OpenXR 的设备，UE5 都是通过 OpenXR 来接的。

需要注意，头显不一定需要一直插在电脑上。前期纯看渲染效果，可以用模拟器或引擎自带的 VR 预览模式；只有需要验证头显实际观感、延迟和畸变时，才需要真实佩戴。把开发循环拆成“不用头显先跑通逻辑”和“戴头显再调手感”两段，能大幅提升效率。

4.2 启用 OpenXR 插件

UE5 里 VR 的基础支持由 OpenXR 插件提供，插件默认没有启用。打开步骤是：Edit → Plugins，搜索 OpenXR，启用后重启编辑器。如果要针对 Quest 做顺滑调试，通常还需要对应的设备 SDK 插件，但最基础的项目，OpenXR 插件加头显运行环境就够了。

启用后，在 Project Settings 里确认“Start in VR”类选项已打开。这样每次点击 Play，画面就会进入头显而不是普通窗口。如果是纯做 360 视频输出，不涉及头显会话，可以不开这个选项。

4.3 渲染路径选择

VR 项目里，渲染路径的选择会直接影响帧率和抗锯齿效果。UE5 默认使用延迟渲染，配合 TAA 或 TSR。但延迟渲染在 VR 里有几个问题：材质带宽占用高、边缘闪烁相对明显、对半透明和大世界支持繁琐。

很多 VR 团队会选择 Forward Shading（前向渲染）配合 MSAA。前向渲染在高频像素着色场景下带宽更友好，MSAA 又能提供稳定的几何边缘抗锯齿，在 VR 这种对闪烁极其敏感的场景里体验更好。开启位置在 Project Settings → Rendering → Forward Shading。需要注意的是，前向渲染会限制一些延迟专属特性，比如部分后处理和全屏反射。

这个选择没有绝对正确，取决于你的场景复杂度。建议项目早期在两个路径下各跑一遍同样的测试场景，用下面这张表做决策：

4.4 常用控制台命令

用编辑器跑 VR 项目时，下面几个控制台命令会经常用到：

# 打开帧时间面板，查看 Game/CPU/GPU 分别占了多少毫秒 stat unit # 查看 GPU 各渲染 pass 的耗时 stat gpu # 查看当前 Draw Call 数量 stat RHI # 关闭 TAA，方便观察裸渲染效果（配合 MSAA 场景使用） r.TemporalAA.Quality 0

在测试时先跑高负载场景，观察 GPU 是否接近垂直同步限制。长期偏离目标帧率，就不是微调的事，而是要从场景复杂度、资源密度和渲染路径层面重新评估。

5. 深度数据接入与深度网格投影完整实现

5.1 深度数据从哪来

在 UE 里拿深度数据，有三个层次。

第一层是材质内采样。后处理材质里可以用 SceneTexture 节点读 SceneDepth，做深度可视化、雾气距离计算、边缘检测这些效果。这一层不产生新几何，适合做效果验证。

第二层是场景网格。MR 设备的 SDK 提供了真实环境的网格模型，相当于设备帮你把环境重建好了。你只需要把它接入 UE，用于遮挡或碰撞，不需要自己写重建算法。

第三层是外部深度传感器。LiDAR、结构光或 ToF 相机输出深度图，经过标定和同步之后，在 UE 运行时转成网格。这是最灵活、也最复杂的方式，需要处理相机内参、外参和帧同步。

下面用一个最小示例，演示如何把一帧深度图转成 Procedural Mesh。这不是完整的生产方案，但足够让你理解整个数据链路。

5.2 深度网格生成器头文件

// 文件路径：Source/VRDepthTools/Public/DepthMeshGenerator.h #pragma once #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "DepthMeshGenerator.generated.h" class UProceduralMeshComponent; UCLASS() class VRDEPTHTOOLS_API ADepthMeshGenerator : public AActor { GENERATED_BODY() public: ADepthMeshGenerator(); UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "DepthMesh") UProceduralMeshComponent* MeshComponent; /** * 根据一帧深度数据生成网格。 * @param DepthValues 深度数组，按行优先排列，长度必须等于 Width * Height * @param Width 深度图宽度 * @param Height 深度图高度 * @param MaxRange 有效深度上限，超过该值会被截断 * @param InvProjectionMatrix 相机的逆投影矩阵 * @param CameraTransform 相机世界变换 */ UFUNCTION(BlueprintCallable, Category = "DepthMesh") void GenerateMeshFromDepthData( const TArray<float>& DepthValues, int32 Width, int32 Height, float MaxRange, const FMatrix& InvProjectionMatrix, const FTransform& CameraTransform); };

5.3 深度网格生成器实现

// 文件路径：Source/VRDepthTools/Private/DepthMeshGenerator.cpp #include "DepthMeshGenerator.h" #include "ProceduralMeshComponent.h" ADepthMeshGenerator::ADepthMeshGenerator() { PrimaryActorTick.bCanEverTick = false; MeshComponent = CreateDefaultSubobject<UProceduralMeshComponent>(TEXT("MeshComponent")); RootComponent = MeshComponent; } void ADepthMeshGenerator::GenerateMeshFromDepthData( const TArray<float>& DepthValues, int32 Width, int32 Height, float MaxRange, const FMatrix& InvProjectionMatrix, const FTransform& CameraTransform) { if (DepthValues.Num() != Width * Height || Width < 2 || Height < 2) { UE_LOG(LogTemp, Warning, TEXT("深度数据尺寸不匹配，跳过网格生成")); return; } TArray<FVector> Vertices; TArray<int32> Triangles; TArray<FVector> Normals; TArray<FVector2D> UVs; TArray<FColor> VertexColors; Vertices.Reserve(Width * Height); UVs.Reserve(Width * Height); for (int32 Y = 0; Y < Height; ++Y) { for (int32 X = 0; X < Width; ++X) { const int32 Index = Y * Width + X; const float Depth = FMath::Clamp(DepthValues[Index], 0.0f, MaxRange); // 像素坐标转 NDC 坐标，范围 [-1, 1] const float NDCX = (X + 0.5f) / Width * 2.0f - 1.0f; const float NDCY = 1.0f - (Y + 0.5f) / Height * 2.0f; // 用逆投影矩阵把 NDC 坐标还原到视空间射线 FVector4 ClipPos(NDCX, NDCY, 1.0f, 1.0f); FVector4 ViewPos = InvProjectionMatrix.TransformFVector4(ClipPos); ViewPos /= ViewPos.W; // 视空间里 X 轴是相机前方，归一化后乘以深度即得到目标点 FVector RayDir = FVector(ViewPos.X, ViewPos.Y, ViewPos.Z) / ViewPos.X; FVector ViewSpacePos = RayDir * Depth; // 视空间转到世界空间 const FVector WorldPos = CameraTransform.TransformPosition(ViewSpacePos); Vertices.Add(WorldPos); const float U = static_cast<float>(X) / (Width - 1); const float V = static_cast<float>(Y) / (Height - 1); UVs.Add(FVector2D(U, V)); } } // 按网格顺序生成两个三角形，注意绕序朝向相机 for (int32 Y = 0; Y < Height - 1; ++Y) { for (int32 X = 0; X < Width - 1; ++X) { const int32 IndexA = Y * Width + X; const int32 IndexB = IndexA + 1; const int32 IndexC = IndexA + Width; const int32 IndexD = IndexC + 1; Triangles.Add(IndexA); Triangles.Add(IndexC); Triangles.Add(IndexB); Triangles.Add(IndexB); Triangles.Add(IndexC); Triangles.Add(IndexD); } } MeshComponent->CreateMeshSection( 0, Vertices, Triangles, Normals, UVs, VertexColors, TArray<FProcMeshTangent>(), false); }

5.4 代码逻辑说明

这段代码的核心是把深度图的像素坐标还原成世界坐标。理解三个关键点就够了：

第一，NDC 坐标。像素坐标（X, Y）除以宽高，映射到 [-1, 1] 区间。注意图像 Y 轴和 NDC Y 轴方向相反，所以要用 1 减去它。

第二，逆投影矩阵。ClipPos 的 Z 取 1，表示远平面。逆投影矩阵会把齐次裁剪坐标转换成视空间坐标，除以 W 之后得到一条从相机出发的射线方向。在 UE 视空间里，X 轴是相机前方，所以射线方向要除以 X 分量，归一成“深度每增加 1，射线前进 1”的比例关系。

第三，绕序。三角形顶点的绕序决定了面的朝向。示例里默认相机看向网格，如果你发现网格发黑或者背面剔除后看不到，大概率是绕序反了，把 IndexA、IndexB、IndexC 的拼接顺序对调即可。

5.5 接入时的性能提醒

这个示例是教学级写法，不是生产级写法。真正接到项目里要注意：不要每帧全量重建；用低分辨率深度图生成低模代理网格，再配合法线贴图或材质细节；深度数据中的无效点要先处理，否则会在遮挡区域生成跨越整个场景的细长三角形。另外，ProceduralMeshComponent 的网格更新会触发物理体的重建，如果不需要碰撞，记得把 Section 的碰撞关闭，或者改用不生成碰撞的 UpdateMeshSection 方式。

6. 360 立体渲染的实现与输出

6.1 三条采集路线怎么选

在 UE 里做 360 立体渲染，取决于你要实时还是离线，要预览还是成片。

如果你的目标是“把引擎里的世界输出成一段能播放的 360 立体视频”，最灵活的是第二条路线：自己搭一个双目采集 rig，用两套 SceneCapture 模拟左右眼，渲染后合成为标准格式。这条路线也可以作为理解 Movie Render Queue 输出方式的底层模型。

6.2 双目采集组件实现

下面是一个可复用的双目采集 rig，左右眼各挂一个 SceneCaptureComponent2D，瞳距默认 0.063 米。

// 文件路径：Source/VR360Capture/Public/StereoCaptureRig.h #pragma once #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "StereoCaptureRig.generated.h" class USceneCaptureComponent2D; class UTextureRenderTarget2D; UCLASS() class VR360CAPTURE_API AStereoCaptureRig : public AActor { GENERATED_BODY() public: AStereoCaptureRig(); UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Capture") USceneCaptureComponent2D* LeftEyeCapture; UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Capture") USceneCaptureComponent2D* RightEyeCapture; /** 瞳距，单位：米。默认 0.063 约为成年人平均瞳距 */ UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Capture") float EyeDistance = 0.063f; UFUNCTION(BlueprintCallable, Category = "Capture") void CaptureStereoFrame(); private: UTextureRenderTarget2D* CreateRenderTarget2D(int32 Width, int32 Height); void ConfigureEyeCapture(USceneCaptureComponent2D* Capture, float EyeOffset); };

// 文件路径：Source/VR360Capture/Private/StereoCaptureRig.cpp #include "StereoCaptureRig.h" #include "Components/SceneCaptureComponent2D.h" #include "Engine/TextureRenderTarget2D.h" namespace { constexpr int32 CaptureWidth = 4096; constexpr int32 CaptureHeight = 2048; } AStereoCaptureRig::AStereoCaptureRig() { PrimaryActorTick.bCanEverTick = false; RootComponent = CreateDefaultSubobject<USceneComponent>(TEXT("Root")); LeftEyeCapture = CreateDefaultSubobject<USceneCaptureComponent2D>(TEXT("LeftEyeCapture")); RightEyeCapture = CreateDefaultSubobject<USceneCaptureComponent2D>(TEXT("RightEyeCapture")); ConfigureEyeCapture(LeftEyeCapture, -EyeDistance * 0.5f); ConfigureEyeCapture(RightEyeCapture, EyeDistance * 0.5f); } void AStereoCaptureRig::ConfigureEyeCapture(USceneCaptureComponent2D* Capture, float EyeOffset) { Capture->CaptureSource = ESceneCaptureSource::SCS_FinalColorLDR; Capture->TextureTarget = CreateRenderTarget2D(CaptureWidth, CaptureHeight); Capture->bCaptureEveryFrame = false; Capture->bImplicitUpdate = false; Capture->SetupAttachment(RootComponent); Capture->SetRelativeLocation(FVector(0.0f, EyeOffset, 0.0f)); } UTextureRenderTarget2D* AStereoCaptureRig::CreateRenderTarget2D(int32 Width, int32 Height) { UTextureRenderTarget2D* RT = NewObject<UTextureRenderTarget2D>(this); RT->InitAutoFormat(Width, Height); return RT; } void AStereoCaptureRig::CaptureStereoFrame() { if (LeftEyeCapture && RightEyeCapture) { LeftEyeCapture->CaptureScene(); RightEyeCapture->CaptureScene(); } }

6.3 关键设计解释

左右眼的偏移方向是 Y 轴，而不是 X 轴。UE 里 X 轴是相机前方，Y 轴是右方，人的双眼是左右排列的，所以偏移必须沿 Y 轴。偏移量用瞳距的一半：左眼往负方向偏移，右眼往正方向偏移，两个相机之间的距离正好等于瞳距。

每个 SceneCapture 的 TextureTarget 设置为 4096x2048，这是标准的 2:1 等距柱状分辨率。两个 RT 加起来是 4096x4096，符合上下格式的最终尺寸。CaptureSource 选 FinalColorLDR，对视频输出来说是合理选择；如果要追求更高动态范围，可以用 HDR 源，但后续编码流程要额外处理色调映射。

bCaptureEveryFrame 为 false 表示不要每帧自动捕获，避免 360 采集 rig 拖垮主场景性能。需要某一帧时手动调用 CaptureStereoFrame，按需触发左右眼同步捕获。真正的生产项目里，左右眼捕获之间要注意时序稳定性，最好在同一帧内完成，否则视差会出现撕裂。

6.4 合成为上下格式视频

左右眼各渲染出一张 4096x2048 的 PNG 序列后，用 ffmpeg 纵向拼接成 4096x4096 的上下格式视频。Windows 命令行用^做换行，macOS/Linux 用\。

ffmpeg -y ^ -i left_eye_%04d.png ^ -i right_eye_%04d.png ^ -filter_complex "[0:v]scale=4096:2048[left];[1:v]scale=4096:2048[right];[left][right]vstack=inputs=2[vout]" ^ -map "[vout]" -c:v libx264 -preset slow -crf 18 -pix_fmt yuv420p stereo_360.mp4

这个命令的意思是：左右眼序列分别缩放裁剪为 4096x2048，然后按垂直方向堆叠，上半部分是左眼、下半部分是右眼。CRF 18 属于质量较高的编码档位，发布到视频平台时，可以按平台要求调整码率。

6.5 Web 端播放验证

输出完成后，最快速的验证方式是用支持 360 立体模式的播放器直接打开。如果你要做网页分发，video.js 搭配 videojs-vr 插件是目前比较常见的开源方案。下面是一个最小页面。

<!-- 文件路径：player-demo/index.html --> <!DOCTYPE html> <html lang="zh-CN"> <head> <meta charset="UTF-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>360 立体视频播放验证</title> <link href="https://unpkg.com/video.js/dist/video-js.min.css" rel="stylesheet"> <link href="https://unpkg.com/@videojs/vr/dist/videojs-vr.css" rel="stylesheet"> </head> <body> <video id="vrVideo" class="video-js vjs-fluid" playsinline controls> <source src="stereo_360.mp4" type="video/mp4"> </video> <script src="https://unpkg.com/video.js/dist/video.min.js"></script> <script src="https://unpkg.com/@videojs/vr/dist/videojs-vr.js"></script> <script> var player = videojs('vrVideo', { fluid: true }); player.vr({ projection: '360', frameMode: 'top-bottom' }); </script> </body> </html>

投影类型设为 360，帧模式设为 top-bottom。如果你输出的是左右格式，把 frameMode 改成 left-right 即可。这个页面既能用来给团队内部验收，也能作为交付演示的最小原型。

7. 运行结果与效果验证

7.1 深度网格的验证方法

生成深度网格后，第一件事不是看材质，而是打开 Wireframe 模式，检查网格是否贴合场景轮廓。判断标准有三个：网格是否出现大范围的孔洞，遮挡边缘是否出现超长三角形，相机移动后网格是否明显漂移。

还可以用编辑器右下角的 Stats 面板查看三角形数量。一张低分辨率深度图生成的低模网格，顶点数应该在可接受范围内。如果一眼望过去全是密集网格，说明深度图分辨率设置过高，超过 VR 项目的预算。

7.2 立体视频的验证方法

立体视频不是“左右两张图拼在一起”就成功了，要验证的是视差是否正确。最简单的方法：把视频暂停在某一帧，对比上下半部分的同一物体，它的水平位置应该有差异。离相机近的物体左右眼水平偏移更大，远处的物体偏移接近零。

如果左右眼画面完全相同，说明瞳距设置成了 0，或者两套相机实际没有分开，视差没有生成。如果物体的偏移方向反了，左右眼装反了，用户会看到怪异的“凹进去”的立体效果。

7.3 性能验证

无论做实时 VR 还是离屏采集，都要用数据说话。跑起来之后执行stat unit，看 Game/CPU/GPU 三个耗时。VR 项目里 GPU 耗时通常最先打满，这时再执行stat gpu，找到耗时的渲染 pass，去判断是场景过载、阴影质量太高，还是后处理占了大头。

有一点容易忽略：离屏采集 rig 本身也在消耗性能。SceneCapture 每多一个，场景就要多渲染一遍。双 SceneCapture 相当于把主视图、左眼视图、右眼视图渲染了三次。如果只是导出视频，建议在独立关卡或独立进程中做，避免和实时 VR 测试互相干扰。

8. 常见问题与排查方法

9. 最佳实践与工程建议

9.1 深度网格的工程建议

• 用低分辨率深度图生成低模代理网格，视觉细节交给材质，不要追求深度图原生分辨率。
• 网格更新频率要克制。静止环境生成一次即可，动态环境用异步任务更新，避免阻塞游戏线程。
• 深度数据的无效点必须显式处理。可以先做连通域过滤，再把异常深度折叠到相机附近，防止生成横跨场景的大三角形。
• 代理网格默认不参与复杂的物理碰撞。如果只是遮挡用途，关闭碰撞即可；需要真实碰撞的部分，单独抽取碰撞网格。
• 在接入外部深度传感器时，先验证相机内参与外参，再进入引擎流程。参数标定错误导致的漂移，后期用代码很难补救。

9.2 360 立体输出的工程建议

• 上线前先确认目标平台的立体格式。不同平台对上下、左右、双流的支持不同，用错了格式等于白输出一遍。
• 瞳距不要拍脑袋调。先用 0.063 米默认值，再用样片在目标设备上测试，观察近景物体的视差是否舒适。
• 场景的近裁剪面和远裁剪面要稳定。360 视频在球面投影下，近处物体和远处物体的画面占比差距很大，近远裁剪面处理不好会出现穿插或闪烁。
• 分辨率与码率挂钩。4K 分辨率配合过低的码率，远景会糊成一团；8K 分辨率局部清晰，但编码和播放压力都大，要按实际分发渠道权衡。
• 批量导出时，使用序列帧而不是直接录屏。序列帧可以保证左右眼严格同步，也方便后期调色和重新合成。

关于片源和合规，这里多提醒一句：360 立体视频的分发链路中，素材版权问题经常被忽略。项目里应优先使用自研画面、已授权素材或自行搭建的 UE 场景输出内容。来源不明的 VR 视频文件不仅存在合规风险，还可能在播放端触发安全告警，这与技术选型无关，但在工程化交付时必须纳入评估。

9.3 团队协作与配置管理

VR 项目里，项目设置的变更会直接影响所有成员的体验。建议把常用的 VR 设置、控制台命令和启动参数沉淀成文档，放进仓库。涉及到设备 SDK 版本、OpenXR 运行时版本、显卡驱动版本变更时，统一记录在 ReadMe 的“版本基线”一节。很多玄学渲染问题，最后查出来都是版本不一致导致的。

9.4 先跑通再优化

最后一条建议，也是所有实验性项目通用的原则：先用最小示例跑通完整链路，再谈优化。深度网格先用一张静态测试图验证反投影是否正确，360 输出先用单帧测试上下格式是否被播放器识别。等整条链路都通了，再往里面填真实场景。这个顺序能让你少排查一半的问题。

10. 总结与后续学习方向

这篇文章的核心就两件事：把深度数据变成有用的几何，把实时 VR 画面变成可分发的 360 立体视频。前者的关键是理解反投影和网格生成，后者的关键是理解左右眼视差和封装格式。两个技术点看似独立，实际上都服务于同一个目标——让 VR 内容既跑得动，又发得出去。

如果你是第一次接触这两条技术线，建议先照着最小示例跑通一次流程。深度网格方面，重点观察反投影矩阵和三角形绕序带来的影响；360 输出方面，重点验证瞳距和左右眼同步。跑通之后，再去深入 OpenXR 的场景网格 API、Movie Render Queue 的批量渲染、以及 stat 系列命令的性能剖析。

这两块技术在未来很长时间内都不会过时。实时 VR 再发展，也绕不开把深度转化为几何；360 视频再普及，也绕不开双目视差的生成。对做 UE VR 的开发者来说，早一点把这两条链路吃透，项目里能踩的坑就少一大半。