WMR Scaling and Dev Tools - Some Explanations

Thank you all for your kind words! I’ll try my best covering everything I can.

Please note in the video above it was only WMR OpenXR (no SteamVR OXR). I’ve tried both and with SteamVR OXR it was not the best. Having said this there seems a lot of people are wanting to try out comparing both and there is some confusion. I’ll try to explain (I might be wrong but it seems fairly unlikely).

  • OpenXR is the API the application talks to VR. It can access the HMD, get the orientation/position, send the views to the eyes etc… It doesn’t depend on any specific HMD.

  • SteamVR is the Valve API and ecosystem for VR. It manages headsets and offers a public API to the hardware (OpenVR) which resemble OpenXR with additional Valve specific features.

  • Windows Mixed Reality (WMR) is the Windows API and ecosystem for VR. It manages headsets and offers a proprietary API to the hardware.

You can therefore use the Reverb G2 with the following application stacks:

a) FS2020 -> OpenXR API -> WMR OpenXR Driver (OXR to WMR) -> WMR Portal (headset I/O) -> Reverb G2

b) FS2020 -> OpenXR API -> SteamVR OpenXR Driver (OXR to OVR) -> WMR for SteamVR (OVR to WMR) -> WMR Portal (headset I/O) -> Reverb G2

The OXR to WMR, OXR to OVR and OVR to WMR are thin translation layers because most of these API are working the same with similar parameters and feature set, which means they are not the main resource consumers. What is different in each however is the reprojection algorithms and implementation details, as well as everything related to timing, such as telling the application how long, and how, to wait before sending the next views.

I hope this will clears up some of the terminology and how this fits together.

2 Likes