[BUG]UEVR (openXR mode) + VRto3D conv setting dont work

[Asxcvbn]

Describe the bug

The problem is that on UEVR's openxr mode, the VRto3D 's convergence settings (default hotkey: Ctrl + F5, Ctrl + f6) dont seems to work on 3d part of the game, only UI does moves accordingly. Depth/Separation Ctrl + F3, Ctrl + F4 settings seems to work properly and on setting we can see objects moves on depth setting change and the nearer the faster.

I believe that extrinsic parameters transfered are correct, but intrinsic parameters in openxr mode of UEVR appears to be incorrect handled because:

• VR headset should work well on both methods since they should have been tested alot. Most VR headsets dont need to change extrinsic parameters in this way
• the other parameter of VR to 3D, depth/seperation, which can be set with hotkey Ctrl + F3, Ctrl + F4, works well on both modes
• even in openXR mode, 2D UI objects work with convergence well but 3D objects don't, so it is unlikely a VRto3D issue because VRto3D should only handle frames provided by steamVR and are quite final.

Hope this idea can be a little bit helpful to

Identify the UEVR version

Tested with vrto3d latest release(v3.3.0) and UEVR latest nightly (UEVR Nightly 01107, UEVR Nightly 01106 and a fairly old version 3b206447ac202795afd99c0e5391cac28823920c)

To Reproduce

The issue is found on at least Palworld, IronHeart, and a bad game Between Two Castles - Digital Edition. I believe this issue should work on most games that UEVR supports.

Normal setup for VRto3D and we first use uevr's openvr mode.

Check SBS content on VRto3D's window entitled Headset Window Use Ctrl + F5 or Ctrl + F6 to change VRto3D's convergence setting and we should see faraway objects moving according to the setting. Now close the game and switch to openXR mode, and changing convergence settings again dont appear to work.

Expected behavior

openXR mode should behave like openVR mode here

Screenshots

If applicable, add screenshots to help explain your problem.

PC Specs (please complete the following information):

• OS win11 24h2 (26100.4652)
• Graphics card RTX 4060 laptop
• CPU i7-14650HX
• Headset Model VR to 3D
• OpenXR or OpenVR OpenXR
• If using OpenXR, the runtime (SteamVR)

[Asxcvbn]

Here is log for running openxr mode and for running openvr mode. What i did here is:

• Open game and wait for titlescreen
• In uevrInjector.exe select game pid, openxr/openvr setting and inject
• Wait for VRto3D window and optionally use win + shift + rightarrow to move it away
• New game and wait for it to load
• Press ctrl + f3, ctrl + f4 a couple of times
• Press ctrl + f5, ctrl + f5 a couple of times
• In uevrInjector.exe kill injectee

log - vr - censor.txt log - xr - censor.txt

[Asxcvbn]

Could @oneup03 have a look and see where the issue might be(i.e., indeed not on VRto3D side)? thanks!

[oneup03]

The problem is that either UEVR or perhaps even Unreal Engine itself don't like dynamic Field of View (FoV) changes, which is what the convergence is tweaking. Even some official VR Unreal Engine games don't like the FoV being changed dynamically. VR headsets will pretty much never change their FoV, although I know there are some plugins people use to reduce it but that's not changed dynamically.

REFramework and NoMoreFlat are perfectly happy to accept dynamic FoV changes for whatever reason. Launching UEVR in OpenVR mode kind of allows some FoV changing, but generally introduces black bars as well. You can use the Reinitialize Runtime button to properly apply FoV changes. I have a whole section on my wiki working around this issue in UEVR: https://github.com/oneup03/VRto3D/wiki/UEVR#adjusting-depth-and-convergence

I haven't attempted to look into the UEVR code as I am not familiar with it and the workarounds are mostly good enough.

[Asxcvbn]

Thanks! Then it is a known issue. Sorry for not checking that (I only checked VRto3D's github issues and saw no much relavant). Tested and it helps. Thank you and praydog for your amazing work!

[Asxcvbn]

I tried changing UEVR's source code and it gives satisfying results: https://github.com/praydog/UEVR/pull/372. The posed version here tries to force fov sync every 100 frames. So on ctrl + F5 or ctrl+F6, you will see ui move very quick and then after around 1s, the 3d content jumps to the ui location. This behaviour is not very good but it proves this problem fixable

here is a build incase you need it UEVR my build.zip

[oneup03]

Awesome, you dug into it!

Maybe you could store off the last FoV values and check if current ones are different?

[Asxcvbn]

Awesome, you dug into it!

Maybe you could store off the last FoV values and check if current ones are different?

I updated it in this way (you might have seen it in the PR). A build is provided here in case you want to try it. (based on my pr, so may not sync with latest main here)

UEVR my build_cache_fov_for_refresh.zip