mbucchia

@Jive @Phantom711 The use if the section is optional, any setting outside of a section (beginning of the file) will apply to all runtime/apps. To use sections, refer to https://github.com/mbucchia/Quad-Views-Foveated/wiki/Advanced-Configuration#general-notes Sections with the syntax [<string>] are matched against the OpenXR runtime name. Use the log file (see Troubleshooting) and search for string Using OpenXR runtime: to find the name of your runtime. Only matching one word is sufficient, for example if your OpenXR runtime is "Varjo OpenXR Runtime 3.10.1" then using the section name [Varjo] is sufficient. I don't recall the runtime name for VDXR, but you can look it up the log file as explained. I think it's [VirtualDesktopXR].

Report said: > The version of the Meta Quest Link app software with the fix is: 68.0.0.474.361

I have received signals that Meta is going to release a hotfix in PTC. Will still be v68<something>, but should have the particular fix to the issue. Edit: I have now received users reports that the hotfix is live on PTC.

Definitely not

Neither eye tracking nor hand tracking are usable on PC with Pico headsets.

Virtual Desktop Classic (the only version that works with a G2) is Desktop streaming only, doesn't let you stream VR games

See the latest update here

Creating a thread for visibility and cc @BIGNEWY. I received confirmation from Meta that the issue in their runtime preventing usage of OpenXR API layers such as OpenXR Toolkit, will be fixed in v69, and they are taking steps to add specific tests for this scenario

Yes, Virtual Desktop works fine with the OpenXR API layers. Virtual Desktop is made BY gamers FOR gamers.

There are many threads about this. Meta introduced a blatant bug in their update that breaks many of the OpenXR API layers out there (OpenXR Toolkit, QVFR, HTCC, OXRMC...). Then after I reported the issue to them, they ignored me. Time to move to Virtual Desktop, where the developers care and properly look after their software.

PSVR2 will only release with a SteamVR driver, which means that you can use OpenXR via SteamVR, therefore WITHOUT most benefits of OpenXR in terms of lightweightness and performance. Things like Quad Views should work, but in fixed foveated mode since it doesn't look like Sony is releasing an SDK to allow developers to access things like the eye tracker.

It's the same reason, QVFR, OpenXR-Toolkit and even a few mods not developed by me (OXRMC, HTCC) will break on v68 due to Meta's bug. Meta is breaking something fundamental that many OpenXR API layers use. I've reported the issue 1 week ago directly to the devs on the OpenXR chat. They haven't acknowledged my message Correct. I'll be checking on the status of this soon, and otherwise try a workaround.

You should be able to use Varjo's built-in option (registry change). You won't be able to tweak any settings this way however. So if you rely on custom settings, keeping Varjo-Foveated is probably a good option.

Code is 100% done in VDXR. But unfortunately it is currently blocked on an unforeseen limitation of Virtual Desktop's compositor. There's currently no guarantee this will be resolved.

Quest Link is really just a "devkit" of Meta's standalone (Android) platform. You should get that hint from the fact that you need to enable developer mode to even get these features Virtual Desktop and VDXR on the other hand are fully optimized for what people actually care about and use. We take the eye tracking data at the beginning of each frame and send it as quickly as possible to the application. No B.S in between. So I'm not quite surprised if you find it better. Haven't done any analysis myself, but I can only imagine this isn't even a thing Meta tests on PC beyond their Avatars SDK that no one else seems to use (good product though, just not what people actually care about).

Here's a very comprehensive explanation: https://github.com/mbucchia/VirtualDesktop-OpenXR/wiki/Oculus-"Runtimes"

Good insight, but no, none of this is actionable by ED, that's not code they have any reach into.

The issue is specific to "dynamic projection" ie when the foveated viewport moves from frame to frame. That only happens with eye tracking.

FWIW I investigated this issue (even though I do not work on this anymore and have 0 plan to try to fix it). The explanation is here:

Is DCS ST that bad btw? Cause that would be the easiest workaround, switch from MT to ST. Does ST still have the "cursor bug" double-vision?

OpenXR Toolkit VRS foveated rendering is 100% different technique from Quad Views foveated rendering. VRS is low-medium GPU gains at no CPU cost. Quad Views is high GPU gains at medium-high CPU cost. In your case the trade-off doesn't play well with QVFR and the CPU cost outweighs your GPU gains. There is no such problem with VRS since you have no CPU cost, so you only reap the GPU gains. https://github.com/mbucchia/Quad-Views-Foveated/wiki/What-is-Quad-Views-rendering%3F

Because you are likely CPU-limited when using QVFR (which requires the game to submit the geometry twice).

No, it's purely a "correctness" change, at any point in time in DCS MT there may be data from 2 "in-flight" frames, and DCS was incorrectly mixing up the data used for the foveated rendering, causing the visual glitches when the foveated viewport followed your eye gaze. There is no performance implications with the change. See full technical details:

The change in the unsigned DLL only enables the workaround for ED's bug like it did before. Your micro-stuttering issue is unrelated to any of it. There is no connection between Quad Views and OpenXR Toolkit.

Good question, and it shouldn't matter whether the workaround is still active. Also, assuming ED didn't revert the app name change, then the workaround won't be activated anyway. What matters more is to remove the unsigned DLL (for those who installed it) and reinstall the original (signed) qvfr.