A few quick VR things

Just for the sake of completeness:

  • Elite Dangerous does not (yet) use the OpenXR API to address any VR runtime -- only those proprietary to OVR (Oculus), and OpenVR (SteamVR).
  • All three of the most common VR runtimes (Oculus, OpenVR, WMR) can now be addressed using the OpenXR API, as an alternative to their own APIs.
  • If you play Elite through OpenXR, that is not directly, buy by way of one wrapper or other, that intercepts OpenVR calls from the game, and "translates" them to OpenXR equivalents (they are similar enough, in many ways). Whether this incurs any significant overhead, depends on whether your chosen active OpenXR-compliant VR runtime is the one your HMD talks to, or whether you have E.g. SteamVR chosen, even though you are using an Oculus headset, so that you still go through SteamVR, on top of OVR, anyway, negating the whole point of the procedure.
  • What you lose, by bypassing SteamVR, is its overlay system, which will not matter if you do not use any such overlays in any case. :7
Thanks!
And super interesting.
  • All three of the most common VR runtimes (Oculus, OpenVR, WMR) can now be addressed using the OpenXR API, as an alternative to their own APIs.
Thinking of SteamVR games like SkyrimVR or Fallout4 VR that we're playing atm. Neither directly use OVR. In SteamVR it says Current OpenXR runtime: Oculus.

To help get my dumb head around this...
So, if I had to go though SteamVR for instance, I would be using OpenVR but OpenVR would need to go through OVR(Oculus) which I presume would need some form of translation as there isn't addressing?
But with the OXR API, that does have addressing to OVR so it consequently doesn't need to go through such a complex translation process therefore performs better?

Has anyone tested the impact of the SteamVR overlay? If it does make a difference, is there a linky to how turn off the overlay?

Thanks!
 
...But with the OXR API, that does have addressing to OVR so it consequently doesn't need to go through such a complex translation process therefore performs better?

Has anyone tested the impact of the SteamVR overlay? If it does make a difference, is there a linky to how turn off the overlay?
Not I, I'm afraid, but I figure there is bound to be plenty of people who have recorded their performance difference between playing a game on OVR directly, and through SteamVR "on top of" OVR, although they may not always have been aware that this is the comparison they have been making, and instead thought it to be the difference between OVR or SteamVR (EDIT: ...and consequently made misconstrued judgements about comparative efficiency).

When running an OpenVR-targetted application with a non-OpenVR-native HMD, OpenVR defers many functions (...such as lens correction, and reprojection...) to equivalents in the... hmm..: "hosting" runtime, but there is a minimum bit of functionality that remains, including at least the basics of the compositor, which is what draws all those overlays onto the frame.

I would assume comparisons made have been with the SteamVR compositor "running idle", with almost nothing overlaid - maybe just the SteamVR Dashboard, some room boundaries, and the pop-up keyboard; maybe additionally a frame-time counter and achievment pop-up (no idea how many of these may be deferred to their equivalents in OVR's (...or other's) own compositor), but overlays of course come in many shapes and sizes, such a the oil-painting-simulator: "Vermillion", which can be run in an "overlay mode", where instead of providing its own environment, its easel is drawn on top of the world of another simultaneously running game, and that is bound to suck down a fair bit more juice than just the aforementioned "light" examples. (It is believed that a future update to the SteamVR compositor will (...like OVR's compositor already does...) take a depth buffer from the running game, so that e.g. Skyrim's, or Elite's NPCs can walk in front of things like that overlaid easel, and not just be clipped by it, like by a 2D mask).

So eliminating SteamVR's compositor, and its overlays with it, is part of what happens when one use e.g. OpenComposite, to retarget/translate/wrap the game's OpenVR calls to the active OpenXR runtime, instead of letting them go to their destined SteamVR. OpenComposite is not a full runtime itself, and does not have its own compositor - it just wraps the API dialogue, pretending to the game to be OpenVR, and translating the calls (...like, say: GetRecommendedRenderTargetSize()...), and their responses, to equivalent OpenXR functions, within the active OpenXR runtime -- think WINE for Linux, rather than something like an emulator.
 
Last edited:
An absolutely brilliant read!

Thank you very much Jojon :7

I would be astonished if Valve didn't make their basic dashboard as efficient as possible and with that in mind I seriously doubt the dashboard's basic overlays would be performance heavy.

Nice
 
...and with that in mind I seriously doubt the dashboard's basic overlays would be performance heavy.
Probably not, but every nanosecond counts, when you have only 11ms to produce a frame pair, and get it to the headset displays, and then you get the "hosting" runtime's own overlays in addition. Apparently people see immediately noticeable performance savings, when bypassing SteamVR's being an extra middle man, between game and non-SteamVR-native HMD; How much of those savings are from removing SteamVR's compositing stage, and how much is from removing other SteamVR aspects of the "supply chain", I have no idea. :7
 
Hi CMDR, sorry I took so long - I had no idea how to give you 'the settings' given there's so many.
Here are the most important settings I tweaked, in order of how I arrived at my current setup...

1. Oculus​

I'll assuming you also have a Meta headset and you bought the game on Steam (as I did):
  • Do not launch the game using SteamVR.
  • Instead, use the Oculus runtime to launch the game.
Running SteamVR on top of Oculus tanks my performance, so I bypass Steam entirely.
I recommend using the Oculus Debug Tool to get a performance overlay - useful when tweaking settings later.

2. In-game settings​

Normally there's a lot to tweak here, but for now - set it to the 'VR Low' preset.
This is to provide a baseline for...

3. vrperfkit​

https://github.com/fholger/vrperfkit

This is a vr performance toolkit that finally allowed me to play in VR again.
I won't go into detail, so please read their own page on how to actually use it.

But generally:
  • Download it and put it in your installation folder (...\Elite Dangerous\Products\elite-dangerous-odyssey-64\).
  • Launch the game and sit in a busy station.
  • Tweak the vrperfkit settings using your keyboard.
  • Tweak in-game settings at the same time.
  • Keep a note on what combination of settings work well.
    (This is a lot easier with OculusDebugTool's performance overlay on.)


My settings​

Yeah, there's an art to finding the right combination of settings.

The goal was to get HMD Image Quality (in-game) as high as possible.
Using vrperfkit, I got enough performance to go up to 1.75.
Yes. 1.75x HMD Image Quality.
I have no idea what magic they're doing in that thing.

I don't recommend you follow my settings 1:1, but here's my settings for reference anyway...
In-game (this is ED Profiler if you're not familiar):
View attachment 364046

In vrperfkit, I arrived at these settings for 'upscaling':
  • 'method': cas (note: keep in-game upscaling to Normal, i.e disabled)
  • 'renderScale': 0.7
  • 'sharpness': 1.0
Also, vrperfkit talks a lot about foveated rendering but AFAIK it doesn't work in ED yet.



Hm.... hope that made any semblance of sense.
Sorry for the stupid question, but how do i do this:
  • Do not launch the game using SteamVR.
  • Instead, use the Oculus runtime to launch the game.
 
Very interesting and helpful. I will have to try this out tomorrow. It's still a chore to set up ED, everytime I have to reinstall the game or my hmd changes ( Dk2 > CV1 > Quest 2 currently) my VR experience goes downhil. Vr needs more love. Thanks for the post, O7
 
Back
Top Bottom