-
-
Notifications
You must be signed in to change notification settings - Fork 24k
Description
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)
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
Type
Projects
Status