mbucchia

Where tho? Don't see it here https://github.com/mbucchia/Oasis-Driver-for-Windows-Mixed-Reality/issues/44

You've sent me the same exact message (which has no useful details btw) through 3 different forums within 2 hours. Please pick one and stick with it, this is basically spam at this point. As replied on GitHub, send a SteamVR Report.

There is a page called "deep cleaning" on the wiki explaining how to undo everything.

Oh I see. Yeah if the issue is only in DCS then that's not the distortion offset issue I pointed you too. Recommend you disable all OpenXR add-ons. I also don't know if DCS single-threaded still supports OpenVR? It might be a good test to try OpenVR instead of OpenXR.

BSB2 SteamVR should expose eye tracking data to SteamVR (I've been in contact with them about this). But I'm not sure which version or if it is public yet. One way to check is to use https://github.com/maluoi/openxr-explorer/releases, and post a screenshot (make sure SteamVR is up and running). This'll tell us whether the BSB2 driver advertises eye tracking (yet) and/or if an API layer interferes.

Did you check the troubleshooting guide that leads to this known issue, and a likely workaround: https://github.com/mbucchia/Oasis-Driver-for-Windows-Mixed-Reality/wiki/Known-Issues#cross-eye-feeling-double-vision-poor-eye-relief-issue

Hey! It's a SteamVR issue that is fixed in the SteamVR Beta branch https://store.steampowered.com/news/app/250820?emclan=103582791435040972&emgid=505086494235427751 > When a requested time querying xrLocateSpace is outside of reasonable bounds, return XR_SUCCESS with an empty pose, instead of returning XR_ERROR_TIME_INVALID. Basically the DCS 0.001 FPS loading screen was causing issues.

That folder contains your room data. Having someone else send you theirs will not work obviously. If you want to revert to Mixed Reality Portal, follow the "deep cleaning" instructions on the wiki, and reinstall Mixed Reality Portal as well.

If you're on the SteamVR Beta (2.13) please opt out for now. There's an issue with it that will be solved shortly.

Yes the eye tracking and quad views foveated rendering will work fine on AMD.

https://steamcommunity.com/app/3824490/discussions/0/592906686979854790/

This is the VR modding scene, this article was outdated barely an hour after it was published. We move really fast.

This isn't a real warning.

Not a problem, you can also go enjoy dynamic foveated rendering with DCS in your PSVR2 with the release of Bnuuy's PSVR2Toolkit, which can be used in conjunction with Quad-Views-Foveated in DCS! Anywhere you go, you can't get rid of me

I personally used a command hook strip for ages

I dont follow your math. See the log file for the megapixels math (it's done there) but also this megapixels is irrelevant to quality, since what matters is pixel density. QVFR tells the game to preserve 1:1 pixel density in the focus region (well, with your multiplier, 1.1x pixel density). We confirmed that in your log. If the game doesn't render at this density, then it's a game bug. Someone probably needs to do a deeper investigation in order to confirm. Edit: can you also look at your VD overlay? It should say something like resolution = 110%

The log just repeats the content of your config. So there's likely a user error here. For the rest you can do the math. With your focus size settings at 0.25 on both axes, it means the resolution of the focus region will be 1/4th of your stereo resolution (Godlike). 3072 / 4 = 768 Because you are using 1.1 multiplier, we need to also factor that 768 × 1.1 = 844 Which is the resolution we see being advertised to the game (in the log file). Now to look at the actual render resolution with DLSS, at quality this means input is 0.67 factor Stereo: 3072 × 0.67 = 2058 QVFR focus: 844 × 0.67 = 565 That's assuming the game is actually following the same math. One would need to enable the DLSS logging in order to check that.

The math QVFR does is to make the final stereo image at the resolution of what the focus region (inner view) would be if it covered the full FOV. So the final stereo image is 1:1 the same resolution that you have without QVFR if you set the focus multiplier to 1.0, and the pixels in that inner view are 1:1 the same resolution. I would try comparing without DLSS, because I dont know what the engine does when it has to do quad DLSS instead of stereo. It's quite possible that the "1:1 resolution" is thrown away by the engine (which isn't something I have any control on, and would be an engine bug IMO). You can perhaps post the log file so we can compare the resolution QVFR sets. This won't tell us what resolution DLSS uses though.

There is no support for OpenXR Toolkit foveated rendering on DX11 with AMD GPUs. It simply does not exist. I literally wrote the OpenXR Toolkit program and I know how it works. To use VRS on D3D11, you must use the NVAPI library (also known as NVidia VRWorks), here is the code in OpenXR Toolkit doing that: https://github.com/mbucchia/OpenXR-Toolkit/blob/6b9ecb69a4b2dc714b14a86407868af315d02531/XR_APILAYER_MBUCCHIA_toolkit/vrs.cpp#L1171 As the name indicate, NVAPI or NVidia VRWorks is exclusive to NVidia and does not work on AMD. https://developer.nvidia.com/vrworks > Variable Rate Shading (VRS) is an easy to implement rendering technique enabled by Turing GPUs. Turing = NVidia. I'm not going to have another back and forth on this. Previous user ultimately realized that they were not speaking of DCS, but instead they had used the feature in another game, a DX12 game, with their AMD card. You're probably in the game boat. Or you are thinking of ",Quad views foveated rendering" which is nothing to do with OpenXR Toolkit, and is a completely different feature (that does work on AMD with DX11).

The Quest Pro was the most uncomfortable headset I've ever owned, until I bought the Globular Cluster mod. I was having the same issue you've described, excessive head pressure which caused insta-headaches. With the Globular Cluster replacement components, that issue completely went away for me.

It's OK, more OpenXR is good, more adoption is good. My code is open source to allow that, but it would be really nice if companies using open source would take the time to follow the directions of the license

There was an additional workaround to Meta's bug that went in the Quad Views tool. It was never back-ported to OpenXR Toolkit. There is no solution to use only Turbo in Quad Views.

It is 100% confirmed to be a fork of VDXR. It's very sad that they are not giving attribution to the original code (which is technically a copyright infringement per MIT license of the original code). Edit: I should also add, it is based on a version of VDXR from 2023, so I'm not entirely sure they're even maintaining it? Otherwise why not tell people it is here? Why not pick a newer version that has more features and fixes?

This error occurs when you do not have an active OpenXR runtime. Make sure in Pimax Play you click "Set as Runtime", this should do it. Also, remove OpenXR Toolkit until you get this working without it. If neither work, search "vcredist" on google and download and install the latest version of that.

The issue with OpenXR Toolkit Turbo when removing the headset is 100% root caused to be an issue where the Quest Link OpenXR runtime violates the OpenXR standard. In other words, it's a Meta bug. I've reported it directly to their engineers over a year ago (maybe even 18 months IIRC) and they won't bother to fix it (extremely simple bug fix).