Application SpaceWarp (XR_FB_space_warp) causes severe hand-tracking mesh lag on Quest 3

Target Platforms XR
, ,
1

Environment

  • Unity 6000.4.5f1
  • URP 17.4.0
  • OpenXR 1.16.1 (com.unity.xr.openxr)
  • XR Hands 1.8.0, XR Interaction Toolkit 3.4.1
  • Feature enabled: Application SpaceWarp (SpaceWarpFeature Android, extension
    XR_FB_space_warp), m_enabled: 1
  • Target: Meta Quest 3, hand tracking (no controllers)

Problem

With Application SpaceWarp enabled, the tracked hand mesh visibly lags behind my real hand by multiple frames. The rest of the scene (world geometry, UI, locomotion) reprojects perfectly smooth, so the lag is isolated to the moving hand mesh and is very noticeable.

Important: this is not a framerate problem. The app holds a rock-solid 72 fps the entire time. The hand pipeline is also already on the lowest-latency path:
XRHandSkeletonDriver / XRHandTrackingEvents with UpdateType = BeforeRender, and the camera TrackedPoseDriver on UpdateAndBeforeRender. So the joint poses are latched right before render, yet the visible mesh still trails.

Isolation / repro

I conclusively isolated the cause:

  • AppSW ON → hand mesh lags heavily.
  • AppSW OFF (same build, same scene, nothing else changed) → hand tracking is
    immediately back to normal, fully responsive.

It toggles 1:1 with the SpaceWarp feature.

Motion vectors on the hand material

My hand material (the XRI Hands sample Unity_Hand_Medium) is a transparent shader (RenderType: Transparent, render queue ~3002). I also tried with the material’s XR Motion Vectors pass enabled (_XRMotionVectorsPass = 1):

  • Motion vectors disabled → hand lags (no velocity data for AppSW to reproject the
    hand).
  • Motion vectors enabled → hand turns to extreme jitter instead of lag.

So a transparent skinned hand mesh appears to have no good state under AppSW, either it lags or it jitters. I suspect transparent geometry simply can’t feed reliable motion vectors to the SpaceWarp reprojection (no single depth, blended fragments), which is the same class of issue transparents have with TAA/ASW.

Questions

  1. Is heavy lag on AppSW-synthesized frames for moving, app-rendered (non-head-locked) objects like a tracked hand mesh expected behavior, or a bug?
  2. Is there a supported way to make a transparent skinned mesh reproject correctly under AppSW (correct motion vectors), or are transparents fundamentally unsupported by SpaceWarp?
  3. The hand material has the MOTIONVECTORS pass listed under disabledShaderPasses while _XRMotionVectorsPass is 1. Is that mismatch expected on the XRI Hands sample material, or should the URP importer keep them in sync?

For now my workaround is to disable AppSW. Happy to provide a minimal repro project if useful.

2

Seems like AppSW should be able to handle transparency a bit better than that, and just smearing the background objects visible through the hands. Meta’s documentation recommends turning on the motion vector generation for important objects the player is focusing on :
https://github.com/oculus-samples/unity-appspacewarp?tab=readme-ov-file#transparent-objects

AppSW requires rendering both motion vectors and depth for the object to reproject correctly. Since the behavior changes when you toggle the motion vectors, I’m guessing it’s not outputting the hands to the depth buffer.