mbucchia

This is common to every VR headset, render higher than the panel resolution to compensate for the lens barrel distortion. This is because pixels look magnified by the lenses, and therefore you want to render at higher pixel density to counter that and keep the graphics crisp. Your G2 had the same thing, with 100% being something like 3000x3000, aka 1.4x of the panel's 2160x2160. The exact factor depends on the optics and should be advised by the vendor. Running Crystal at 1.4x is likely too challenging though, but it's up to you if you can.

I got the trace from someone else already so it's ok

> I can produce 60fps uncapped with MR off. > GPU frame times around 18-21ms That's contradictory. 1/0.021 = 47 FPS, not 60 FPS. Your 2 FPS headroom is insufficient to maintain a solid 45 FPS with MR on, hence you get dumped to 30 FPS (there is no granularity in-between, you can get half - ie 45 - or one third - ie 30). So MR isn't costing you 30 FPS, but it is costing you more than the 2 FPS headroom you have, which in turn turns into a dramatic fall to the one third mode. It's unclear whether you meant that this measurement is with MR on or off though. But regardless, this is enough for me to think that getting 30 FPS is the expected outcome given your system's performance. You can try _forcing_ the algorithm to use 45 FPS mode via OpenXR Toolkit settings as suggested above (set Motion Reprojection to On in OpenXR Toolkit and then use the Lock Motion Reprojection right below it). But assuming that you often dip just even to 44 FPS, the "forced" mode is likely going to make things worse.

Can you do the following? Preferably with Quad-Views-Foveated and no other program like OpenXR Toolkit. 1) open ADMIN command prompt 2) run `wpr -start %ProgramFiles%\OpenXR-Quad-Views-Foveated\Tracing.wprp -filemode` 3) run DCS and reproduce the crash 4) back to the command prompt, run `wpr -stop trace.etl` 5) ZIP up the `trace.etl` file (the ZIP step is important!) that was created (it is created in the current folder, aka the one you can see the prefix for in the command prompt) and send it to me Thanks.

There is no motion reprojection in OpenXR Toolkit, it's only a shortcut to control the motion reprojection of WMR. OpenXR Toolkit doesn't do any motion reprojection. SteamVR motion smoothing is only for SteamVR headsets AFAICT (Valve Index, HTC Vive) and you can't enable it with Pimax. Pimax Smart smoothing had always been a little problematic. Are you using SteamVR or PimaxXR as your OpenXR runtime?

@nikoel the only crash I got taking the headset off/on is with "double Turbo" aka having Turbo on in both Quad-Views-Foveated and OpenXR Toolkit. That's a really bad idea in the first place (and one of the reasons I ask people to reset all settings in OpenXR Toolkit). Use Turbo either in one or the other. I'm not sure this is your issue, but I couldn't get a crash unless I intentionally made that mistake.

Can you try reinstalling the component called "OpenXR for Windows Mixed Reality" (not "OpenXR TOOLS for Windows Mixed Reality). The service mentioned in that error lives in that package. Uninstall from Add or remove programs in Windows. Then reinstall from https://apps.microsoft.com/store/detail/openxr-for-windows-mixed-reality/9P9596DJJ19R

Can you tell me exact steps to reproduce? I tried yesterday with a Quest 2 (cause that's all I have that can use the Oculus runtime), and I have no issues when removing the headset.

There is nothing in OpenXR Toolkit that precludes motion reprojection (well except Turbo mode). Motion Reprojection (aka motion smoothing) is a setting in Pimax Client, completely independent of OpenXR Toolkit.

Use the Render Quality slider in Pimax Client, set it to 0.75, it will provide just enough supersampling. You always want the rendering resolution to be a bit higher than the panel resolution.

Yes unless you have setup in Pimax Client an override specifically for DCS.

Thanks for trying. Yes I should've mentioned that the purple thing is used for the foveated rendering, and instead for an "aim" thing we would be using the center. So you guessed right. Doing the crosshair isn't hard, what is difficult is how to translate the input into something usable by the game. This is truly something the game NEEDS to implement themselves. Otherwise we have to resort to faking input... - We can't really use the mouse. Let me explain why. All games have different ways of capturing mouse input, because mouse is an OS concept, and not an OpenXR one, and many of them do not follow best practices. For example games will typically use relative mouse movement upon blocking the cursor into a confined space. "Relative" movement means impossible for an external software to calibrate absolute position (and by nature your eye gaze is a point projected in absolute coordinates on a plane in front of you). This is why you can't see/use the mouse when your game window has focus (and you need to Alt-Tab or Win button to "release" the cursor to Windows). Also apps like DCS are a good example: if you look closely at DCS after Alt-Tabbing, you'll notice that the cursor on the desktop and the cursor inside DCS aren't aligned at all. This is due to the difference in absolute vs relative coordinates. It would be impossible for a "driver" to correlate these coordinate systems. - One thing that OpenXR eye tracking and the game use in common is the motion controller. There is a direct and easy way to correlate your eye gaze position and your motion controller. But this isn't practical for use. We could make your eye gaze act as a virtual motion controller, but then it comes with many issues, such as your motion controller is not "stuck to your face", but instead at arm length. So we'd have to somehow fake a certain depth for the "eye-to-controller". The problem is we don't know what the scene in the game looks like, so we'd arbitrarily pick a depth, which sometimes will be too far from the cockpit switches, and sometimes will be behind the cockpit switches. That won't be usable. - I hear there are those "pointCTRL" and @actually_fred has a software called HTCC to control it from OpenXR. I think it could in theory plumb the eye gaze input into it, but I suspect it would have the same issues described above related to motion controller usage. So it's unclear where to go from there. Idk if you have any idea based on the currently available input methods in the game, and how we could fake the input using the eye tracker, now that I've explained some of the challenges with it.

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.