Thanks to everybody that has offered useful info/suggestions so far.
As I said before yesterday I tried disabling OpenXR toolkit and enabling Foveated Rendering in game and this was successful.
This morning I tried the suggestion to disable Foveated Rendering in OXRT to see if that worked with the option on and found that I have Foveated Rendering switched off anyway in OXRT.
So testing revealed that this does not work. With the game option on, an OXRT option off the game crashes to desktop, and this includes switching the game option on once I am in VR in game.
This info is with the Quest3.
Now again, I checked the fps with the game option switched on and found that the base I use for testing got 70-75 fps in cockpit on the runway, whereas with the option switched off, and therefore OXRT active, I got 90 fps in cockpit on the runway in the same plane.
So, I guess I have two questions for people far more knowledgeable than myself on this subject.
Can OXRT work alongside this option in the game, if so how?
The second question is considering what I have found so far in testing what am I missing out on if I have the option switched off, considering that the performance seems so degraded with it switched on?
You are talking high frame rates here for MSFS - without actually seeing your data I would hazard a guess that you are becoming CPU bound (quad views increases CPU overhead, especially if they haven’t got instancing).
If you enable the advanced view you should be able to see frame times for GPU and CPU. Have a look at CPU frame times and what happens between foveated rendering on/off.
I find it odd that it seems a very mixed bag for Pimax - some people like yourself are able to turn it on, for me and others it creates an instant crash.
Even someone with the same system specs as me, same driver version, same Pimax play settings… his works (fixed though, not dynamic) and mine doesn’t.
You may well be correct here that I am in that corner of the envelope that the CPU increase means that I can’t benefit from any increase in performance that the option would give me. Well, not without considerable re-evaluation of the settings that I have worked towards for months.
So that would/could account for the fps.
This leaves can OXRT work in harmony with the game FR setting?, and what does Quad Views give me over what I currently have?
I know that these may seem like basic questions to some but I have a feeling that these questions are likely to appear, in various forms, in the forums and so maybe we should ask them now to help people now and maybe prevent them being asked and answered repeatedly.
It would appear that how they have done it, it remains compatible with OXRTK (although note OXRTK is deprecated and doesn’t officially support DX12 like in MSFS so it isn’t guaranteed to be fault free quad views or not).
If you enable OXRTK with the sim foveated rendering option disabled and enabled you should be able to see the CPU frame time (performance - advanced) and confirm if that is what is causing the reversal in performance.
Quad views benefits particularly in the very specific scenario that you are GPU limited, and have sufficient CPU headroom to account for the extra overhead of rendering 4 views. One can hope that they will be able to optimise the CPU side by using instancing - we have to remember this is the very first implementation in the first beta of SU2 - there will undoubtedly be ongoing work, it’s just fantastic that it’s even on the menu now.
Thanks for the info, although I can confirm that with the FR option in OXRT disabled it still crashes as soon as VR is activated.
So if anybody comes up with a way that OXRT can co-exist with the sim option on it would be nice.
Once again, I have the Quest3 and I am using VirtualDesktop. It could be that the combination of hardware and/or software causes it.
Others have been using OXRTK with the sim foveated rendering turned on.
I can’t turn it on even with OXRTK off… so there’s obviously a lot of highly variable results at the moment. I think just give it time for the bugs to be worked out
I will do some more testing later on. I will try switching some other setting off and see if that makes a difference. I know that the FR setting is the obvious one to try but maybe there is some other option causing it.
One weird thing I did find is that with OXRT disabled and the game FR on the DLSS screen overlay display appears in VR.
Well it’s felt for a very long time that Asobo don’t give VR players much love, but when they do, my god we really get some love. Fingers crossed this will be further optimised in the future. Nice one Asobo
So, does anyone actually have the “eye tracked” part of this feature working?
I can certainly see the square in the view with higher resolution (easy to look through the edges of the lenses and see the resolution decrease) but with my QPro, I’m not seeing that square move.
Tried and tested. Pimax Crystal light and 4090 + 7800x3d is showing a performance decrease and the lines are so visible (artifacts). No go. I think this feature would be awesome for dynamic foveated rendering if it works, but no details provided from Pimax and Microsobo. Good intentions, not clear what´s this move all about RN.
This is super interesting! Could this be possibly combined with the headtracking too ? As a poor man’s dynamic foveated rendering for the non eye tracking headsets? I think it could be helpful to move the center view (a little) together with the head. Because when you move your head to the left you will most likely look to the left too , and moving the sweetspot a little could help
No, this is a dev option and it’s very cumbersome to use, you will see that it locks your mouse to a square region, which will probably make the menu and cockpit impossible to use.
This option is meant for dev testing, for example I do not have a Quest Pro anymore, so I have to test somehow
I saw your feature requests yesterday on Discord (I assume it was you ), and no personally I do not think this is useful. If you’ve ever used a bad eye tracking implementation with foveated rendering, you’ll know that its so much worse to have incorrect/inaccurate eye tracking than no eye tracking at all. Things like the acceleration and “snap back” to center would be arbitrarily calibrated. This wouldn’t be a good experience.