mbucchia

It's alright I am about to go to bed

Using the quad views is turning on all sorts of code in DCS that you have never used before. It's making the game behave differently, regardless of what Meta-Foveated itself does. Best you can provide is to make an ETL trace when the issue happens: 1) open an Administrator command prompt 2) navigate to `Program Files\OpenXR-Meta-Foveated` 3) run the command `wpr -start tracing.wprp -filemode` 4) capture a few seconds of the issue, make sure to move your headset around so we can see the tracking data passed from Oculus to the game 5) back to the command prompt run `wpr -stop trace.etl` 6) compress the file `trace.etl` and send it over to me

There is nothing in Meta-Foveated that does anything about tracking data. It relays the head tracking data as-is to the game. It certainly _does not touch at all anything related to motion controllers_. You might be looking at a DCS bug here.

This has been said quite a few times, but DCS MT enables OpenXR by default, which on Varjo will automatically enable a mode called "quad views". This mode is incompatible with OpenXR Toolkit. This is listed on my website: Compatibility | OpenXR Toolkit (mbucchia.github.io) You can either - disable "quad views" by using something called OpenXR-InstanceExtensionsWrapper, - embrace quad views and enhance it via Home · mbucchia/Varjo-Foveated Wiki (github.com) in order to take advantage of eye tracking

Not easily. The settings are stored per-app by using the app self-proclaimed (meaning chosen by the app developer) name. Both ST and MT specify the same "DCS World" name. I don't plan on changing that logic.

Can anyone file a bug report or start a thread for this NVG bug? Now that more people are using this quad views mode in DCS, maybe ED will be more inclined to fix the issue?

Thank you all! Seeing a lot of you folks from this thread made very generous contributions! This will for sure help me cover some of my past costs (like new GPU) and future costs (signing certificates which just quadrupled in price this year...). Much appreciated!

TL;DR: I'm still undecided about this one. Long version (because y'all know I love to write up the details): Varjo-Foveated was comparatively simple. It 100% relies on Varjo's own quad views support in their OpenXR runtime. All Varjo-Foveated does is: - Add the necessary setup for foveated rendering on top of quad views - that DCS isn't doing otherwise - that's the primary bit of magic; - Add the ability to override the focus region pixel density. size etc, which people love to play with; - Implement a workaround for DCS incorrect frame metadata submission introduced by MT. There is nothing that requires to touch any of the pixels. So there is no set-up in the code to do Direct3D stuff. This is also why Varjo-Foveated took maybe 1/5th of the time to implement compared to Meta-Foveated. Meta-Foveated does all the above too, but it cannot leverage existing quad views support (it's not in the Oculus OpenXR runtime). So it has to reimplement it, including: - Hooking into the eye tracker to tell DCS how to render the 4 views properly. Fortunately this code is 100% reused from OpenXR Toolkit for the eye tracker part and 100% reused from PimaxXR for the view projections calculations. So that bit was easy. - Compositing the 4 views into a stereo view. Now that's the complex one. This one requires to do some drawing of my own. First because the Oculus OpenXR runtimes lacks of certain features (which Pimax supported for example, and therefore I did not have to implement them in PimaxXR) and second because there are edge cases in the Oculus OpenXR runtime (for example submitting multiple stereo layers seems to preclude ASW). So for that last one, there is quite some significant code needed to set up drawing via Direct3D, pull data from the DCS backbuffers, setup new backbuffers to receive the produced views etc. That code does not exist in Varjo-Foveated, nor in PimaxXR. With all of that set up for Meta-Foveated, adding CAS was pretty trivial (I think it took an hour). There's also Varjo being an odd-ball which caused quite a few issues in the past, the way they manage OpenXR backbuffers internall is 100% different than other OpenXR implementations, and it requires additional logic. It would be complex to add this into Varjo-Foveated. Not impossible, but probably 2-3 days of work. I know, I sound terrible, because 2-3 days of work sound like nothing but they are 2-3 days where I'm not doing something else. I'm literally that busy. So wait and see... Right now I will focus on applying my learnings from Meta-Foveated back into PimaxXR for Crystal support. Ideally I can find a solution where Quest Pro/Varjo Aero/Pimax Crystal/others all share the same solution without having additional maintenance costs. For example, I have Meta-Foveated working on G2 Omnicept - but releasing that is an additional maintenance cost (which I deem not worth it due to low volume of users). Ideally, there would be >1 maintainer to do work like this - eg someone passionate about G2 Omnicept support willing to spend a couple of hours a month to maintain it. <long brain dump over>

Are you using wireless? That could be cause for latency.

Wut??

It will always depend on user to user. If you were only getting a 10% gain then you are on the very low end of the spectrum... What quad views does is help reduce the overhead of 1) pixel shading and 2) pixel rasterization. In you are not in a situation (game settings, resolution, GPU) where these are your bottleneck, then you won't see as much improvements. It's similar to CPU vs GPU bound. Your sig shows you are on a GTX 1080... I suspect such an old system will have many more bottlenecks than just 1) and 2).

Possibly the reason but also quite possibly my bug too. OpenXR Toolkit DFR on Quest Pro doesn't need that offset for some reason ^^ It's probably something I need to get to the bottom of, but was OK to release as-is for now.

I'm not sure. Remember that I don't have a Quest Pro. I use very similar code between my projects and the headsets I support (Pimax/Omnicept/Quest Pro). Somehow this bias isn't needed on the other ones. Not sure why it is on Quest Pro. I trust my beta testers! Sharpening-only has a very little cost. I haven't even tested without it, but with it I found the end-to-end overhead of the entire API layer to be less than 200 microseconds (it was closer to 160 microseconds on my 4070, and I rounded up). I suspect if you remove CAS you probably go down to 80-100 microseconds. The performance gain is likely imperceptible, but I'm sure the quality will suffer more... Thanks, fixed! That's a typo. The parsing would probably just ignore it at this point and still see 0.25.

It varies from people to people, it's not universal. Though both with Aero and Quest Pro so far, it looks like the large majority of people are fine with the defaults. Be sure to disable the two "bad" options in DCS, 'VR' -> 'Bloom effect' and 'System' -> 'Lens Effects' because the make things worse. Also, you may have noted that there is a lighting bug in DCS that may create a different contrast between the two views. Nothing we can do except hope ED will fix that.

There's an entire page describing what it means on my site. Have you considered trying the lower resolution that everyone else is using and have a good experience with so far? You're currently making the assumption that 1 pixel = 1 pixels, but this isn't what foveated rendering does. If you are irritated, please uninstall the software

Nice, so was it just the Developer mode on phone app? I am adding a section to Troubleshooting with your exact error message so we hopefully catch this easier!

That is the "your Developer Mode isn't correctly setup" issue. Not something I can do anything about and this is part of my rant about "why are you doing this to us Meta?". Best I can advise you is to: - Make sure Developer mode is enabled from both the PC and Android app. - Try a hard reset of your device and set up the Developer mode again. - Send a bug report to Oculus. IT IS THEIR PROBLEM TO FIX. Hopefully you get some luck. That would be great though I don't have a Quest Pro so I don't even know where to do that. If you can provide some screenshots of the process, I'm happy to add them to the wiki! Thanks! EDIT: Is it this menu (screenshot from Google):

"Try and see". I've had conflicting reports of it working/not working. So just try. Starting it in Safe mode to clear out the previous configuration (that you used in stereo mode) is a good idea.

You can try adding a line "debug_focus_view=1" in the settings file, which will only show the foveated view and make it really obvious whether it's following your gaze.

This is a bug in DCS itself. Not much can be done about it unfortunately (maybe more people can report it to ED now). If you own Pavlov VR (the other game with quad views support) the bug isn't there and it shows you how it's meant to be done). One solution might be to slightly increase the size of the focus view, but this will cost you performance. AFAIK the Aero users haven't found this bug too bothersome though. Did you make sure to disable the 2 effects listed in the instructions? > In the DCS World settings, you must disable 'VR' -> 'Bloom effect' and 'System' -> 'Lens Effects' as they produced poor visuals when using foveated rendering

I fixed that. The initial version did prevent ASW from working, but then I found a way to make it work! Glad to hear it's working well for you so far!

I posted in the other thread (the one actually titled something "foveated rendering"). @nikoel I have not tested on AMD card because I was too lazy to pull the card out of my computer, put the AMD card in, etc. I think it should work as-is with AMD, if not, then it's probably a silly little Direct3D bug in my programming, and that should be fixable. So please let me know if you can get this to work on your AMD card!

It is live now! It comes with some very comprehensive instructions, please read the steps for enabling the eye tracking feature in the Oculus software, and all the notes about incompatible game options. Home · mbucchia/Meta-Foveated Wiki (github.com)

And big thanks to you! @mimamema has been my prime beta tester, helped find issues and fine-tune the experience! I wouldn't go quite far without folks like you helping!

The first version of foveated rendering for Quest Pro will release very soon. It will be a separate tool, incompatible with OpenXR Toolkit. However it includes its own CAS sharpening and Turbo mode, two of the most appreciated features of OpenXR Toolkit. Compatibility with OpenXR Toolkit may happen later. Also to be very clear on the expectations: it will NOT work with Virtual Desktop. This is out of my control: Virtual Desktop uses SteamVR, and the SteamVR OpenXR support doesn't let you do eye tracking. It will require the use of Air Link or Link Cable.