mbucchia

Isn't DLAA just DLSS without upscaling? Ie: you won't gain any perfomance, you will actually lose a little bit, because the game won't render any faster (same resolution) and you are actually adding an extra AA pass. So it all depends what you are trying to achieve, but AFAICT, if you are seeking performance, DLAA isn't for you.

Sounds like the infamous cursor bug with Varjo Quad Views. Can be fixed by using the multi-threaded (MT) version of DCS.

Yes. There is instructions on the wiki for that.

From the log: 2023-09-29 09:56:46 -0500: xrCreateSession: XrResult failure [XR_ERROR_RUNTIME_FAILURE] Origin: OpenXrApi::xrCreateEyeTrackerFB(session, &createInfo, &m_eyeTrackerFB) Source: D:\a\Quad-Views-Foveated\Quad-Views-Foveated\openxr-api-layer\layer.cpp:1976 2023-09-29 09:56:46 -0500: xrCreateSession failed with XR_ERROR_RUNTIME_FAILURE Which is listed in the Troubleshooting guide: Troubleshooting · mbucchia/Quad-Views-Foveated Wiki (github.com) null For short you did not follow all the instructions needed to enable Developer Mode on the Quest, probably missed the phone part. To your defense, Oculus made this absolutely ridiculously complicated for no good reason. Almost like they don't want you to use the feature...

You don't download OpenXR, it's a feature your platform already supports. All you have to do is enable it, which is explained in the first 2 posts of this thread.

I believe this is solved by reordering of loading order between Quad-Views and XRNS. At least that did the trick between Quad-Views and OXRMC. Are you using the latest Quad-Views-Foveated (1.1.1)? I made a change to the installer specifically for that, I'm curious whether it fixes the problem.

Said tool is out now: Home · mbucchia/OpenXR-Eye-Trackers Wiki (github.com) Install side-by-side with Quad-Views-Foveated (current version works with it). Yes this is spread in two tools, because eye tracking support isn't specific to Quad Views, and some people may want to use eye tracking for other stuff.

Then you will need to live without your desktop in VR... There is currently no alternative outside of SteamVR.

Beware about the term "standalone" which in the industry mostly refers to "app running on the headset (as opposed to PC)". If you are using Quad-Views-Foveated, then I assume you are using PimaxXR - which is an OpenXR implementation that "ditches SteamVR". If you want to keep using SteamVR, you may simply not use PimaxXR (toggle back to SteamVR in the PimaxXR Control Center app). However if you do that, you will need to install an additional program in order to do eye tracking with SteamVR (because SteamVR does not support eye tracking): Home · mbucchia/OpenXR-Eye-Trackers Wiki (github.com) So for short, if you want to keep using SteamVR AND also benefit from Quad-Views-Foveated, you need to: 1) Disable PimaxXR and toggle back to SteamVR 2) Have Quad-Views-Foveated installed 3) Have OpenXR-Eye-Trackers installed

Heads up for folks using Quad-Views-Foveated on Pro - there is an upcoming update that will enable Virtual Desktop brand new eye tracking support. I'll post about it when it's out.

That's just a backend driver, every headset has that too. Some get installed via Steam and are more visible (WMR, Vive, Pico), some are installed as part of the relevant platform (Oculus, Varjo, Pimax) so it looks like they don't exist, but they do!! In any case, it's a mandatory driver layer, SteamVR cannot do anything without it, regardless of whether it's WMR or not. In the case of WMR, that WMR for SteamVR driver is a simple bridge to WMR lower-level interface (aka Windows.Graphics.Holographic). At its best, its pretty lightweight (if the game does not submit any 2D UI for example) however at its worst it has to perform additional composition (if there are 2D UI or if using motion reprojection). But that is unavoidable, even the OpenXR for WMR layer has to do that.

The CPU performance issues can only be solved by ED in their game engine, for example through the use of quad instanced rendering (submit geometry for all 4 views at once). This isn't an easy undertaking, so I doubt it will happen any time soon, or ever.

You do realize that the "additional program" in your story is SteamVR. WMR, Oculus, Varjo... can all be used without SteamVR though the use of OpenXR, and that cuts off the "additional program". But you still need to have the base system running (Mixed Reality Portal, Oculus Link, Varjo Base). There isn't really a way around that. Some base systems are more lightweight than others, but in all situations, SteamVR is the extra overhead (though the definition of "extra" is actually up to interpretation, since it provides some of the features that the base system doesn't offer).

The experiment you described only proves that the PimaxXR setting is toggling your OpenXR runtime, which is the goal. I can guarantee you that OpenComposite settings makes no difference in your situation, because your game isn't trying to use OpenVR anyway. You seem to have no grasp of what OpenComposite actually does, so it's a good thing you're deleting it...

That's all you need really: this will remove the reference to SteamVR in your `%LocalAppData%\openvr\openvrpaths.vrpath` which is the only leftover. Just to be clear the toggle in PimaxXR does something 100% different than what OpenComposite does. They're not at all the same thing.

That doesn't change my statement. Make sure you are using the latest version of everything, the initial version of Quad-Views-Foveated (months ago) had lower performance with OBSMirror (but even then it wasn't anywhere near what you described). I've had at least 5 reports of Quad-Views-Foveated + OpenXR-OBSMirror working impeccably with DCS since.

This happens if you don't properly set it up via PowerShell (depends on Windows settings). Definitely a problem on your end. It's been working fine for many users, including with Quad Views.

Use https://github.com/Jabbah/OpenXR-Layer-OBSMirror which will capture the output of Quad-Views-Foveated and therefore the same exact image you see in the headset.

And the ONLY WAY to have it PROPERLY done is by having the game implementing it. So please redirect your requests to ED. That hand-to-motion-controller hack is terrible, impossible to setup, very uncomfortable to use, and that's why I abandoned it over 18 months ago...

Great to hear this is solved.

The MT version only supports OpenXR, so if you need `--force_OpenXR` then it further proves that somehow your game is running ST. The cursor isses only happen with ST, this has been confirmed many times, and every time users having issues eventually found out they run ST. You can be sure by looking for the watermark in the menu (see below). Unfortunately there is not much I can do, this is a game issue. The method I gave you has worked for everyone (you must run the game from your Steam library and not from a shortcut like you said yoi are doing). The only consistent way I know today go use MT is to uninstall the Steam version and to use the standalone OpenBeta, which does not have these weird issues

Nope, nothing missing. This bit down here is not obvious and you have to read carefully! (Doing this solved the problem for the last ~5 people who had this issue, so I'm confident it will work for you too) BTW @BIGNEWY this caveat above has confused a lot of users. Not sure why things are that way, but apparently with the Steam edition, if you run the executable in bin-mt outside of Steam it still runs ST. This is very very confusing and could be improved.

Double cursor means you are not running DCS multithreaded. It's explained in the instructions: https://github.com/mbucchia/Varjo-Foveated/wiki#dcs-world. null

Yes those multipliers in the configuration file will take the resolution DCS was about to use. When you use OpenXR Toolkit Resolution Override, that setting sets that final resolution directly. One thing I never checked is what happened if you set Pixel Density to something other than 1.0 in DCS. Idk if anybody knows.

@BIGNEWY, any opportunity to pin this post so it keeps near the top? Thanks.