UE5 VR交互全流程：帧预算是第一约束，交互是第二约束

VR项目与平面项目的根本区别，不在于是否戴着头显，而在于帧预算从“流畅度指标”变成了“生理约束”。Quest 3 上 72Hz 意味着每一帧的全部计算——逻辑、物理、动画、立体渲染、时间扭曲——必须在 13.9ms 内完成，其中 GPU 在移动 Adreno 上的可用份额远低于桌面 GPU。这意味着 UE5 的 VR 全流程不能按“先做交互、后做优化”的顺序推进，而必须在项目创建的第一个小时就把渲染管线和帧预算钉死，交互系统在这个预算框架内设计。抓取和投掷的物理手感，本质上是在“帧预算允许的物理更新频率”和“交互直觉”之间做工程取舍。

项目配置：Forward Shading + MSAA + Instanced Stereo 不是可选项

UE 的 VR 模板默认使用延迟着色，而延迟渲染在移动 VR 上的带宽消耗和 Overdraw 成本是灾难性的，必须显式切换到前向渲染。同时，TAA 在 VR 中会引入 1 帧渲染延迟并产生头部运动时的鬼影，抗锯齿方法应改为 MSAA——在 Quest 的 Adreno GPU 上，4× MSAA 的带宽开销几乎是免费的，而在 PC VR 上前向着色配合 MSAA 的 GPU 帧时约增加 25%，但换来了无延迟的清晰度。立体渲染路径的选择同样明确：PC VR 用 Instanced Stereo（一次 DrawCall 渲染双眼，CPU 提交开销约 1.1 倍而非 2 倍），一体机用 Mobile Multi-View，两者可以同时开启，由引擎按平台自动选择。

这些设置必须在 DefaultEngine.ini 中固化，而不是依赖编辑器手动勾选：

[/Script/Engine.RendererSettings]
r.ForwardShading=True
r.AntiAliasingMethod=2          ; MSAA
vr.InstancedStereo=True
vr.MobileMultiView=True
vr.PixelDensity=1.0

[SystemSettings]
r.SeparateTranslucency=0
r.HZBOcclusion=0
r.MotionBlurQuality=0
r.EyeAdaptationQuality=0
r.AmbientOcclusionLevels=0
r.DepthOfFieldQuality=0

vr.PixelDensity=1.0 是 HMD 原生分辨率的基准，低于 1 会模糊、高于 1 会超采样降帧，不应作为性能调优的旋钮随意拨动。r.SeparateTranslucency=0 和 r.HZBOcclusion=0 关闭的是在移动 VR 填充率预算下性价比极低的功能，而不是“关掉画面效果”。

交互：抓取组件的核心不是“Attach”，而是物理状态管理

VR 抓取最容易写错的地方，是把“抓住”实现为简单的 AttachToComponent。这在视觉上成立，但投掷时物体会丢失手部的速度信息，扔出去的东西像“放”出去而不是“甩”出去。正确的实现是在 UGrabComponent 中同时维护运动学附着和物理释放两条路径：抓取时禁用物理模拟、把物体附加到手部插槽；释放时先分离、恢复物理，再把抓取期间累积的手部速度按比例传递给物体。

// GrabComponent.h
UCLASS(ClassGroup=(VR), meta=(BlueprintSpawnableComponent))
class UGrabComponent : public USceneComponent {
    GENERATED_BODY()
public:
    UFUNCTION(BlueprintCallable)
    void TryGrab(UMotionControllerComponent* Controller);

    UFUNCTION(BlueprintCallable)
    void Release();

private:
    UPROPERTY() UPrimitiveComponent* HeldPrimitive = nullptr;
    UPROPERTY() UMotionControllerComponent* OwningController = nullptr;
    TArray<FVector> VelocitySamples;
    TArray<float>  SampleTimes;
    void SampleVelocity();
};

抓取时记录 HeldPrimitive 的原始碰撞和物理设置，关闭 SetSimulatePhysics(false) 后附加到控制器的 Grip 插槽。关键在 SampleVelocity：每帧（或在 Release 前回溯数帧）采样控制器的世界位置和时间戳，用线性回归或简单差分估算释放瞬间的线速度。释放时的核心代码：

void UGrabComponent::Release() {
    if (!HeldPrimitive || !OwningController) return;

    const FVector ThrowVelocity = EstimateLinearVelocity();
    HeldPrimitive->DetachFromComponent(FDetachmentTransformRules::KeepWorldTransform);
    HeldPrimitive->SetSimulatePhysics(true);
    HeldPrimitive->SetPhysicsLinearVelocity(ThrowVelocity);
    HeldPrimitive->SetPhysicsAngularVelocityInDegrees(FVector::ZeroVector);

    HeldPrimitive = nullptr;
    OwningController = nullptr;
    VelocitySamples.Reset();
    SampleTimes.Reset();
}

EstimateLinearVelocity 取最后 3–5 帧的样本做加权平均，权重偏向最新帧，而不是直接用最后一帧的瞬时速度——手部追踪在帧间存在抖动，瞬时速度容易把物体扔出不可控的初速度。角速度的传递需要额外从控制器旋转的帧间变化估算，但 SetPhysicsAngularVelocityInDegrees 在移动端物理求解器上的行为不如线性速度稳定，初期可以置零，待手感验证后再逐步引入。

投掷手感：速度传递系数是交互设计参数，不是物理常数

物理引擎会如实执行你给它的初速度，但“如实”不等于“直觉”。真实手部甩动的峰值速度可能达到 5–8 m/s，直接传递给物体往往扔得太远、太快。工程上的做法是在 ThrowVelocity 上乘一个可配置的传递系数（通常 0.6–1.2），把这个系数作为 DataAsset 中的参数暴露给设计侧，而不是硬编码在代码里。投掷手感还需要与抓取点的位置配合：如果物体在手中被附加到偏离控制器原点 10cm 的位置，释放点就偏离了真实手掌位置，视觉上会感觉“东西从手腕飞出去”而不是从指尖。抓取插槽的偏移量应当在 GrabComponent 中针对不同尺寸的物体做适配，而不是统一附加到控制器原点。

打包与验证：ADB 部署后的第一件事是看帧时间

Android 打包依赖 Android Studio、SDK、NDK 和 JDK，UE 5.7 的 Project Launcher 可以完成 APK 构建，但构建成功不等于性能达标。部署到 Quest 后，第一轮验证不应是“走一圈看看交互是否正常”，而是用 stat unit 和 stat gpu 看帧时间分解：如果 FrameTime 超过 13.9ms，先查 GPU 侧的 Base Pass 和 Translucency，再查 CPU 侧的物理和动画更新。stat rhi 可以验证 Instanced Stereo 是否真的生效——DrawCall 数应接近单眼水平而非两倍。VR 的性能调优有一个与平面项目不同的纪律：不要等到画面“看起来卡”才优化。72Hz 的丢帧在头显里表现为抖动和晕动症，用户在画面变糊之前就已经感到不适，帧时间必须在开发过程中持续被观测，而不是在最终验收时被动发现。

VR 全流程的工程顺序可以压缩成一句话：先用 ini 把渲染管线和帧预算钉死，再用 C++ 组件把抓取和投掷的物理状态管住，最后用 ADB 部署后的帧时间分解验证每一帧是否真的在预算内。交互的“手感”不是在编辑器里调出来的，是在 13.9ms 的硬约束下，由物理参数和速度传递系数共同定义出来的。