mbucchia

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.

Oh did I not mention that because it's the quad views method, it's completely agnostic of the GPU, and there's no reason it wouldn't work on AMD card too?

I'm still very much pissed at them for 2 things: - developer mode fiasco, hiding your features behind this very unreliable developer mode which is causing a lot of people coming to me with their issues (while it's a Meta issue) - most importantly they are the vendor in the best position to make a positive impact to the PCVR gaming industry, yet they seem to create more barriers instead of taking them down. The eye tracking data as a vendor-specific API is a great example of how you discourage developers from implementing these techs. What I'm doing with the upcoming "Meta-Foveated" project, I am not doing it for them. I am doing it to promote the streamlining of these technologies. I'm doing it because I want more developers to use these techs and implement foveated rendering in their games. I'm doing it because I think we deserve a good PCVR gaming Ecosystem. Because you deserve a delightful VR experience!! And in the process, I can say I wrote this project in 4 evenings, on a laptop, while watching garbage TV with my wife and my bunny. If I can do that, then Meta's large $$$ has no excuses to not be doing it themselves. Edit: don't get me wrong, I am not disparaging the skills and competence of Meta's engineers. I've met them and they are great. Their leadership is probably asking them to not spend resources on PCVR, which is the issue. FYI the first version will not be compatible with ASW. It looks like the Oculus runtime cannot do ASW when you submit multiple projections. I'm looking into an alternative. Edit: Taking this ASW thing back. Solved it, it will be supported Day 1.

Well your disappointment would be short I hope. Due to the persistence of a certain user on my Discord (who should remain nameless ), I have implemented the quad views support extensions for Quest Pro. It is currently in final beta testing and should be released in the next few days. So far the feedback is pretty good so hopefully it will make it worth your while and also signal Meta to wake up when it comes to supporting feature on their PCVR runtime.

I think we all agree the question is poorly asked. But that doesn't matter, the results speak for themselves and I think OpenVR support will be gone for good now (or rather will not be revived into MT).

I heard this statement too but unclear how reliable. This was posted on my Discord as a screenshot from some Pico forum I think? (Not my post) EDIT: Reverse-engineered from the screenshots: https://developer-global.pico-interactive.com/community/post/7238474317217398789 My guess is it will be based on Monado perhaps? (That's the runtime they use on Android). Monado support on Windows has not really been useful, but I keep hearing it's supposed to get massive upgrades soon. And I know of a couple of vendors currently porting their streaming solutions as Monado drivers.

"OpenXR Tools for Windows Mixed Reality" won't do anything for an Oculus Quest. You need to uninstall that application and instead change the settings in the Oculus PC app, or use something like Oculus Tray Tools.

See https://forum.dcs.world/topic/299598-trying-to-connect-the-individuals-that-made-the-performance-enhancement-in-vr-to-the-dcs-devs/ for getting MSFS-like DFR. That was ignored for over a year. Anyway even with that, you wouldn't be getting anywhere near the gains we are getting on Aero (where I used a completely different technique than the one I used for MSFS, which yields much much better gains). The set of features supported on Quest Pro is just very poor when it comes to implementing this stuff, and their prerequisites for enable eye tracking are super bogus. Quest Pro is obviously in my opinion not a platform that Meta wants to succeed for PCVR. Do yourself a favor and swap it for an Aero if you want to enjoy good DFR in DCS and great PCVR in all games!

Any reason for this unwarranted adjective? You're more than encouraged to participate to the development of the tool. It's open source. Be part of the solution, not the problem.

It varies from engine to engine but the most likely explanation is that there is more geometry being culled. Zooming reduces the field of view as mentioned in the post above yours, and before attempting to render anything, the engine will perform what is called a "culling pass", and it will completely remove from its list of things to draw anything that is not at all visible due to that lower field of view. Less geometry to draw will translate into less work to do on the CPU (because the CPU is responsible for enqueuing commands to the GPU for all the triangle lists to draw). It won't affect as much your GPU because in the end the same number of pixels end up being filled (can still vary due to poorly optimized z-ordering, but let's ignore that). It's all about how complex it was to assemble the geometry that produces these pixels. You can't really leverage that property to optimize things no, unless you are willing to significantly reduce your field of view (there are options to do that in SteamVR/OpenXR, though they probably produce much less gain since they won't reduce FOV as much as zooming does).

Oculus mode (OVR) is now deprecated, and even Oculus themselves don't want developers to keep using it. I would not expect anyone in 2023 to keep writing/maintaining support for Oculus mode in their app. ED is doing the right thing here. If you have issues with OpenXR and the Oculus runtime (or perhaps Virtual Desktop), you need to report them to Oculus or to GGodin, this is the only way things can be improved. My 2c.

That's 100% correct yes.

The question in the thread is highly ambiguous because SteamVR can be used through either OpenVR or OpenXR... so anyone picking SteamVR as the answer could mean either OpenVR or OpenXR... Cc @BIGNEWY, because I feel the question is poorly asked.

"Automatic" was never what you think it is. It literally just meant "Always on" if the app was Flight Sim 2020, or Disabled otherwise. "Always on" means always on standby and ready to kick in if you drop below 90. The rate is then selected "best as possible" given the frame times. The new version 113 keeps the Disabled option, adds an Enabled (which replaces "Always on" and works exactly like it before), then adds a "Limit to X rate" if you want to force the frame rate to a given maximum.

100% sure. Do you happen to perhaps have Motion Reprojection enabled through OpenXR Toolkit? That setting takes precedence over the OpenXR Tools one. That Automatic is getting removed in the newer release btw (which had been out for a few weeks already, so you shouldn't even be seeing Automatic anymore if you are on version 113).