Skip to content

OpenXR drops view pose when GI workloads spike on startup #113827

@sorche942

Description

@sorche942

Tested versions

  • Reproducible in v4.4, v4.5 and v4.6.beta.custom_build.bb92a4c8e in linux

System information

Arch Linux - Nvidia RTX 5070 Ti (Driver Version: 580.105.08) - Quest 2 - WiVRn streaming

Issue description

When any GI system (LightmapGI, VoxelGI, or SDFGI) is enabled in an XR scene (Forward+ renderer), the scene fails to start and freezes on the first frame.

OpenXR logs “head space location not valid (check tracking?)”.

I think there might be a race condition of some kind, my best guess is that the extra startup work needed to start any GI system can produce this OpenXR timing issue. Keeping the cached render_state.views transforms even if a frame reports invalid tracking and only overwrite them on successful xrLocateViews, gating rendering on whether we ever had a valid pose (view_pose_initialized). Also make sure the temporary view array has type = XR_TYPE_VIEW before calling xrLocateViews. With that, the intermittent timing issue from GI doesn't seem to kill the XR frame loop.

Here is a very adhoc PR for doing just that: #113826. This solves the issue for me.

Steps to reproduce

  • Create a new project with Forward+ renderer.
  • Enable basic OpenXR setup: (enable openxr and shaders in the settings, set up basic script to enable xr in the current viewport, setup XROrigin and XRCamera in a basic scene).
  • Enable one of LightmapGI, VoxelGI or SDFGI.
  • Run the scene in XR mode from the editor.

Minimal reproduction project (MRP)

basic_openxr_setup.zip

This is just a very basic scene and an XROrigin and XRCamera setup with the XR init script from the docs and a lightmap.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    Status

    Up for grabs

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions