Yes it’s fixed for me with stationary lights, but still gives problems with movable lights. If you change the directional light in the 5.4 VR template to movable it still gives buggy shadows in one of the eyes. Didn’t happened in 5.3. And apparently it’s still not solved in 5.5 preview (comments in the bug report liked avobe) (update: I’ve just seen in that page that you’re already aware of it).
I’m using Meta Quest Link as OpenXR runtime.
Hi!
I faced the issue that after the first PIE/Vr Preview motion controllers are always being stuck at 0 position with tracking lost.
I am using Quest 3 with Virtual Desktop VDXR.
After a bit of digging to the source code I have found that after the first run condition fails inside of the FOpenXRHMD::GetPoseForTime implementation:
if (DeviceLocation.locationFlags & XR_SPACE_LOCATION_ORIENTATION_VALID_BIT &&
DeviceLocation.locationFlags & XR_SPACE_LOCATION_POSITION_VALID_BIT)
This is my first experience with OpenXR so I would ask for any support/solution or links to documentation/best practices, literally anything.
I’ve got looked through that one: Developing for XR Experiences in Unreal Engine | Unreal Engine 5.5 Documentation | Epic Developer Community
Sadly didn’t help a lot.
A common pitfall with OpenXR is that inputs will only become active when the application session is in the focused state. It varies between runtimes, but any system overlays being active, or taking off the headset can drop the application out of focus. It can also take several frames before the inputs become active again after the application is focused, so debugging can show misleading transient states if you are only debugging the first frame.
If you still get the same results after several frames, and the CurrentSessionState member of FOpenXRHMD is set to focused, it could probably be an issue with the runtime. An options is to try other runtimes besides VDXR and see if they have the same issue.
Hello Rectus and thank very much you for your response!
My problem is not caused by debugger. The Game is ticking, it is in foreground, it just doesn’t track controllers after PIE/VR preview restart.
I’ve noticed that cycling the power of a controller while the game is ticking fixes the issue.
It seems like the editor build is missing some (re)initialization for the controllers. I can confirm the same behavior with the Reverb G2 + WMR + OpenXR.
Packaged builds work fine, and switching levels doesn’t trigger the problem. It’s just a quality-of-life issue for UE Editor users — but it’s quite annoying.
I haven’t encountered this particular issue in a long time. Unless a recent Unreal version has introduced it, it is more than likely an issue with those specific runtimes. The OpenXR plugin closes the session between VR Preview restarts, which it doesn’t do when changing levels, which would explain the different behavior in the packaged build.
The controller initialization is largely handled on the runtime side and is driven by the OpenXR session state, so checking that the state transitions correctly could help narrow down the issue. You can make the plugin log the state transitions in the console with the command log LogHMD Verbose.
Recently updated the engine to test the new VR template released by epic in 5.6 By default, the template uses the OpenXR plugin on direct11.
However, I was having issues playing the template on my pimax hmd, basically getting greeted by a black screen( the hmd was projecting black, was not turned off).