mbucchia

very weird indeed. As you can see in the log file you are rendering 63% less pixels... so unclear why the game would be working harder. I've been adding all sorts of performance instrumentation in a new version (not published yet), once I release that you'll have to try again. I don't think anybody else has reported such issue so far, the only known performance issue is with OBSMirror and that tanks the CPU frame times, not GPU

Can you try disabling all other software you have, like XRNS? Even if they are not running.

Please give us the full log from Quad-Views-Foveated

You are likely CPU-limited. Foveated Rendering only helps with GPU performance, if your CPU is the bottleneck, Foveated Rendering will not help, and actually Quad Views will increase your CPU load, and make your performance worse. Use the DCS performance graph to see where you are - but everything you said is pointing to you being utterly CPU-limited.

I think they meant "for the price" G2 is outdated and quality/features from Aero/Crystal certainly beat it, but they are also 4-5x the price tag

The accuracy of the eye trackers in those devices is enough for coarse pointing, but in something as dense as in a virtual cockpit, you won't go very far, especially if the pointing isn't implemented in the game (where the game could snap onto game elements). I haven't tried Quest Pro - but I think that's what you have? If so, if you download the latest version of my Quad-Views-Foveated (formerly Meta-Foveated), you can enable a debug option `debug_eye_gaze=1` in the settings that will show a purple dot where you are looking. You will be able to judge the accuracy and also the "stability" of pointing. Let me know what you think. Doing it myself on Aero, Crystal and G2 Omnicept, I can tell that pointing isn't good enough for a crowded cockpit. You can stare at something, and the dot is always "close" but not quite there. So if you have a bunch of knobs very close to each other, you wouldn't be able to precisely pick one. You will also see how "shaky" the pointing is, the dot is always doing slight movements. It's too sensitive, though that part can maybe improved by filtering. For a solution like that to work out, you'd need a way to declutter the cockpit (less dense amount of controls) which would be less realistic. You would need the game to implement the pointing feature, so that it would "snap on" to the closest control. It would be great if a game developer tried, but I think there are many challenges before this can be an even remotely pleasant experience.

It will do some sort of fixed foveated rendering when eye tracking is not available, but to be frank I have not tweaked at all the fixed foveated rendering settings so it does probably look bad indeed XD This is really meant to be used with eye tracking!

I actually released last night! So as soon as Pimax releases their eye tracking to the public, you can jump in: https://github.com/mbucchia/Quad-Views-Foveated/wiki

That sounds like issues you need to report to the author of the mod. Please remember that my DFR support isn't really doing much at the game level, it's doing thing at the OpenXR/platform level. So this type of "visuals aren't correct" are bugs of the content (game or mods).

Sorry I only have a Quest 2 - hopefully someone with a QP will see your message and reply!

Yes that's called ASW on Quest, and you can also configure it to be locked with a tool called Oculus Tray Tool for example.

Don't worry about that, it's just the way the menu is drawn in safe mode to make sure it'll be visible. You're only going to be in safe mode for like 30 seconds, just to go get this Restore defaults, then you'll leave Safe mode.

Can you try it today? 1) you want to make sure Meta-Foveated was installed AFTER OpenXR Toolkit. If you are unsure, just reinstall Meta-Foveated. 2) enable OpenXR Toolkit and toggle Safe mode. 3) start DCS... it should work and not crash. 4) in the OpenXR Toolkit menu, go to the Menu tab and choose Restore defaults. 5) disable Safe mode and restart DCS. Now if this works, you should have both programs working at the same time, but there are some options in OpenXR Toolkit that you really need to avoid, like the Foveated Rendering, the FOV adjustment, the Zoom... some of these options will either cause crashes or just produce incorrect visuals... Let me know if that works.

You're GPU is pretty fast already, so VRS-style Foveated Rendering isn't going to help that much.

https://mbucchia.github.io/OpenXR-Toolkit/

oh OK then it sounds like that problem instead: Not quite sure this is something in my control - I don't do anything at all about tracking.

Does it happen when you remove your headset by any chance? This looks like an issue with Turbo mode that's on my todo list. Meanwhile you can disable Turbo mode in the config file and see if it helps.

Smart smoothing works as far as I can tell, but "how well it works" from my experience is very subjective and every individual has their own opinion... I don't think you can know for sure if it is acceptable to your standard unless you try it

Lol no that didn't offend me or nothing, just wanted to point out the nuance about the beta software in question. I think his point there is that he is running at something like 4k x 4k per eye and hitting 90 FPS, but surely this doesn't look like the most scenery you've ever seen lol. I'm sure there will be more benchmarks and demos once both Pimax and my software roll out.

He is using special beta software given to him by me. Quad views DFR is the bomb, ask almost any DCS user with an Aero or a Quest Pro. He is testing the Crystal version of that same DFR software which has a proven track record of doing a pretty good job. Agreed on the lack of precise benchmark though (side-by-side comparisons like Lukas has done for Quest Pro would have looked great). That said I can tell you first hand, the gains and performance are great with the eye tracking and foveated rendering on Crystal.

Values for the option a NEGATIVE, try "left" instead of "right" (eg: Ctrl+F1 is using the default keyboard bindings).

AFAICT it works if you are using SteamVR OpenXR. It can work with PimaxXR but for now you need to use "Compulsive Smoothing" aka lock the framerate. There are otherwise issues with dynamic framerate scaling. So it's usable IMO. If I remember correctly, this is also how Varjo motion smoothing works (like you can only do motion smoothing with v-sync enabled to half or lower).

I'll take a quick look next week BUT even if the interactions worked I am pretty sure you will not be having a good experience. But I guess we can't be sure until we try.

No, the config file is only read at start-up. The challenge is that the main things driven by the config options (like the multipliers and region size) directly feed into the resolution of the image for the quad views. Therefore these settings are equivalent to changing the resolution of your headset... which is something that can only be done with cooperation from the game. Some of the other settings like sharpening or transition thickness would require some sort of keyboard/menu user experience in game (like OpenXR Toolkit), which I dont think has value here. You really probably don't need to change them anyway.

Honestly it's 99% likely my bug. But as I said that feature in my program is pretty much abandoned and hasn't had development in a year.