Can DCS add QuadViews native support?

[TAIPAN_]

DCS currently can work with QuadViews, however it relies on a 3rd party app https://github.com/mbucchia/Quad-Views-Foveated

The developer has stepped down from future support https://imgur.com/a/2mLPQSy

At least one DCS update has broken it previously and required an update to the 3rd party tool.

Could DCS possibly add support for it directly similar to how some games offer foveated rendering in their VR settings menus?

[Abburo]

That's shame he is out of business, but we all have to thank him for his fantastic work !

I'm also on the same boat, kindly asking for ED to take this in consideration natively!

[GayCavalier]

8 hours ago, TAIPAN_ said:

DCS currently can work with QuadViews, however it relies on a 3rd party app https://github.com/mbucchia/Quad-Views-Foveated

The developer has stepped down from future support https://imgur.com/a/2mLPQSy

At least one DCS update has broken it previously and required an update to the 3rd party tool.

Could DCS possibly add support for it directly similar to how some games offer foveated rendering in their VR settings menus?

I came here to request exactly the same thing.

If ED could integrate the QuadViews extensions into DCS natively, that would be fantastic.. similar to what they did with Ultraleap's handtracking!

mbucchia's source code is under a MIT license, and i'm sure he'd be happy for it to be integrated directly into DCS - that way updates wouldn't cause conflicts, and QuadViews Foveated can live happily in retirement..

You could have a new option under the Special tab to enable eye-tracking (if available), and the settings slides could be similar to QuadViews Companion (TallyMouse)...

[hsth]

+1 (can't put enough of these to emphasize importance)

[Lt_Jaeger]

+1

[Gunfreak]

Yes plase

[Mr_sukebe]

+ another one please

[r2dseu]

+100
This is super important. I can't go back to running 20 fps. Not after I've tasted running 100 fps.

[mbucchia]

Let me clarify a few things, because right now you are asking the wrong things, to the wrong people, in the wrong order.

Let's start with the basics: DCS does implement quad views rendering in their engine. So the title of this thread isn't going to make sense to any one looking at it.

My guess is that Eagle Dynamics added support for it in order to enable Bionic Display on Varjo's VR-3 and XR-3 high-end professional headsets. Quad views rendering is the only option today that Varjo offers to enable Bionic Display.

 

Now here are the 3 issues that need to be addressed

 

1) DCS only implements the Bionic Display flavor of quad views, which is by nature fixed foveated rendering, because the extra video panel in the Bionic Display is fixed (it does not move with your eyes, that would require absolutely crazy mechanical tech). Now this fixed foveated rendering does not help too much with performance, because it is set up specifically for the Bionic Display usage, where the high density panel is fairly large. So in order to make a performance boost in DCS, we want to use dynamic foveated rendering with quad views. However Eagle Dynamics did not implement that. This is what my original Varjo-Foveated mod did: it forces the eye tracking capability into DCS' implementation of quad views in order to achieve dynamic foveated rendering.

So ask number 1 to Eagle Dynamics is: can you implement the dynamic foveated rendering flavor of quad views in DCS? This is a very simple change to make. Stated in technical terms: Can you add support for XR_VARJO_foveated_rendering? It's really simple, all you need to do is add a couple of extra flags when initializing the OpenXR instance, the querying the resolution for your swapchains, and querying the view pose/FOV for rendering at each frame.

 

2) DCS implementation of quad views has bugs. In particular, related to the addition of dynamic foveated rendering above, there is a bug in DCS MT version where data from the next/previous frame is being incorrectly used for the current frame. Because of this bug, the foveated region cannot work properly when eye tracking is used, because the region ends up being warped out of place when you move your eyes. I implemented a workaround to this issue in both Varjo-Foveated and Quad-Views-Foveated.

This bug was reported to @BIGNEWY on March 18th in the post linked below, with a very detailed explanation including a detailed trace log. Actually both 1) and 2) were logged in that post back in March.

 

So ask number 2 to Eagle Dynamics is to fix this bug with XrFovf submission in order to make their implementation of quad views compatible with XR_VARJO_foveated_rendering.

 

3) Quad views support is currently only implemented by Varjo in their OpenXR runtime. The quad views technique and OpenXR extensions were coined by Varjo and as a result, only they had stakes to implement it in their platforms. This means that Valve, Meta, etc do not bother implementing support for quad views applications. So even when an application like DCS implements quad views, these vendors will not be able to run the application in quad views mode. This limitation is not on Eagle Dynamics, and there is nothing they can do about it. This is why I developed my second mod, Quad-Views-Foveated, and if you read closely the description of it, it doesn't talk at all about adding anything into the application:

Quote

In technical terms:

This software enables OpenXR apps developed with XR_VARJO_quad_views and optionally XR_VARJO_foveated_rendering to be used on platforms that do not typically support those extensions. It composes each quad view projection layer into a stereo projection layer, and uses the eye tracking support on the device to make the inner projection views follow the eye gaze.

What does that mean? It means that Quad-Views-Foveated does not fill a gap in the application (DCS), but instead it fills a gap in the platform (Oculus, Pimax, etc...).

Yes, Eagle Dynamics could pull in the entire quad views on top of stereo emulation framework that I created, but it's way outside of the scope of what any normal game engine should do and I would not expect (or even encourage) any game developer to do that. In addition, there are many challenges linked to eye tracking, because just like Meta, Valve, etc did not implement quad views support in their OpenXR runtimes, they also did not implement eye tracking support in them. Only Varjo implements the proper OpenXR interface for eye tracking (XR_EXT_eye_gaze_interaction). Meta chose to only expose social eye tracking data through a proprietary extension in Developer Mode only and recently Steam Link also only forwards eye tracking via a non-standard OSC interface. This is what a 3rd project of mine, OpenXR-Eye-Trackers, aimed at fixing. This is a complete nightmare for any game developer to have to deal with this mess and they really don't have to put up with it.

It's not Eagle Dyamics you need to ask the feature to: it's Meta, Valve, Pimax, etc. instead. They are the ones who need to build support for XR_VARJO_quad_views and XR_VARJO_foveated_rendering into their platforms.

Summary

- Eagle Dynamics, please resolve issue 1) and 2) described above in order to offer an implementation of dynamic foveated rendering that can work out-of-the-box on platforms like Varjo and Somnium. Resolving these two issues is a very small matter than could be achieved with little effort.

- Meta, Valve and other major platform vendors, please provide support for quad views configuration type out-of-the-box in your PC runtimes. Only by having major vendors with mass volume of users supporting the technology out-of-the-box we will encourage developers like Eagle Dynamics and others to provide support for this great technology that really benefits the end users.

Until all vendors align with providing quad views support in their OpenXR runtimes, I am afraid my Quad-Views-Foveated mod is going to remain the only way to do dynamic foveated rendering in DCS for Quest Pro, Reverb G2 Omnicept and Pimax Crystal users, and this is not a problem Eagle Dynamics can fix.

Edited February 27 by mbucchia

[Hammer3246]

You're  ************, love this!

[BIGNEWY]

Hi all, quad views in DCS require some more work, we do have a report open for it and when the team have time they will make changes. 

thanks

[TAIPAN_]

2 hours ago, mbucchia said:

Let me clarify a few things, because right now you are asking the wrong things, to the wrong people, in the wrong order.

Let's start with the basics: DCS does implement quad views rendering in their engine. So the title of this thread isn't going to make sense to any one looking at it.

My guess is that Eagle Dynamics added support for it in order to enable Bionic Display on Varjo's VR-3 and XR-3 high-end professional headsets. Quad views rendering is the only option today that Varjo offers to enable Bionic Display.

 

Now here are the 3 issues that need to be addressed

 

1) DCS only implements the Bionic Display flavor of quad views, which is by nature fixed foveated rendering, because the extra video panel in the Bionic Display is fixed (it does not move with your eyes, that would require absolutely crazy mechanical tech). Now this fixed foveated rendering does not help too much with performance, because it is set up specifically for the Bionic Display usage, where the high density panel is fairly large. So in order to make a performance boost in DCS, we want to use dynamic foveated rendering with quad views. However Eagle Dynamics did not implement that. This is what my original Varjo-Foveated mod did: it forces the eye tracking capability into DCS' implementation of quad views in order to achieve dynamic foveated rendering.

So ask number 1 to Eagle Dynamics is: can you implement the dynamic foveated rendering flavor of quad views in DCS? This is a very simple change to make. Stated in technical terms: Can you add support for XR_VARJO_foveated_rendering? It's really simple, all you need to do is add a couple of extra flags when initializing the OpenXR instance, the querying the resolution for your swapchains, and querying the view pose/FOV for rendering at each frame.

 

2) DCS implementation of quad views has bugs. In particular, related to the addition of dynamic foveated rendering above, there is a bug in DCS MT version where data from the next/previous frame is being incorrectly used for the current frame. Because of this bug, the foveated region cannot work properly when eye tracking is used, because the region ends up being warped out of place when you move your eyes. I implemented a workaround to this issue in both Varjo-Foveated and Quad-Views-Foveated.

This bug was reported to @BIGNEWY on March 18th in the post linked below, with a very detailed explanation including a detailed trace log. Actually both 1) and 2) were logged in that post back in March.

 

So ask number 2 to Eagle Dynamics is to fix this bug with XrFovf submission in order to make their implementation of quad views compatible with XR_VARJO_foveated_rendering.

 

3) Quad views support is currently only implemented by Varjo in their OpenXR runtime. The quad views technique and OpenXR extensions were coined by Varjo and as a result, only they had stakes to implement it in their platforms. This means that Valve, Meta, etc do not bother implementing support for quad views applications. So even when an application like DCS implements quad views, these vendors will not be able to run the application in quad views mode. This limitation is not on Eagle Dynamics, and there is nothing they can do about it. This is why I developed my second mod, Quad-Views-Foveated, and if you read closely the description of it, it doesn't talk at all about adding anything into the application:

What does that mean? It means that Quad-Views-Foveated does not fill a gap in the application (DCS), but instead it fills a gap in the platform (Oculus, Pimax, etc...).

Yes, Eagle Dynamics could pull in the entire quad views on top of stereo emulation framework that I created, but it's way outside of the scope of what any normal game engine should do and I would not expect (or even encourage) any game developer to do that. In addition, there are many challenges linked to eye tracking, because just like Meta, Valve, etc did not implement quad views support in their OpenXR runtimes, they also did not implement eye tracking support in them. Only Varjo implements the proper OpenXR interface for eye tracking (XR_EXT_eye_gaze_interaction). Meta chose to only expose social eye tracking data through a proprietary extension in Developer Mode only and recently Steam Link also only forwards eye tracking via a non-standard OSC interface. This is what a 3rd project of mine, OpenXR-Eye-Trackers, aimed at fixing. This is a complete nightmare for any game developer to have to deal with this mess and they really don't have to put up with it.

It's not Eagle Dyamics you need to ask the feature to: it's Meta, Valve, Pimax, etc. instead. They are the ones who need to build support for XR_VARJO_quad_views and XR_VARJO_foveated_rendering into their platforms.

On this front, there are 2 noteworthy developments:

a) Somnium has announced that their OpenXR runtime will have support for XR_VARJO_quad_views and XR_VARJO_foveated_rendering, which will put them at the same level of support as Varjo I believe. However, due to issues 1) and 2), users will still need the extra Varjo-Foveated mod in order to use dynamic foveated rendering in DCS.

b) Khronos (the organization behind OpenXR) is currently pushing quad views to become a core feature in OpenXR 1.1. This is a good news, because it means the name quad views will no longer be associated with Varjo only. However, in itself, it will not directly help the end-users: quad views remains an optional feature that is implemented at the discretion of the platform vendor. So Meta, Valve, etc will still be free to ignore that quad views is a thing and to not implement support for it in their platform.

 

Summary

- Eagle Dynamics, please resolve issue 1) and 2) described above in order to offer an implementation of dynamic foveated rendering that can work out-of-the-box on platforms like Varjo and Somnium. Resolving these two issues is a very small matter than could be achieved with little effort.

- Meta, Valve and other major platform vendors, please provide support for quad views configuration type out-of-the-box in your PC runtimes. Only by having major vendors with mass volume of users supporting the technology out-of-the-box we will encourage developers like Eagle Dynamics and others to provide support for this great technology that really benefits the end users.

Until all vendors align with providing quad views support in their OpenXR runtimes, I am afraid my Quad-Views-Foveated mod is going to remain the only way to do dynamic foveated rendering in DCS for Quest Pro, Reverb G2 Omnicept and Pimax Crystal users, and this is not a problem Eagle Dynamics can fix.

This is great info, thank you!

I don't know enough about the implementation and never could have conveyed this myself.

But it's certainly making a lot more sense now that you've broken down how it all fits together.

I hope the items in the summary can be actioned by ED & the vendors.

Thanks also to @BIGNEWY for confirming it's being looked at

[VirusAM]

Let me clarify a few things, because right now you are asking the wrong things, to the wrong people, in the wrong order.
Let's start with the basics: DCS does implement quad views rendering in their engine. So the title of this thread isn't going to make sense to any one looking at it.
My guess is that Eagle Dynamics added support for it in order to enable Bionic Display on Varjo's VR-3 and XR-3 high-end professional headsets. Quad views rendering is the only option today that Varjo offers to enable Bionic Display.
 
Now here are the 3 issues that need to be addressed
 
1) DCS only implements the Bionic Display flavor of quad views, which is by nature fixed foveated rendering, because the extra video panel in the Bionic Display is fixed (it does not move with your eyes, that would require absolutely crazy mechanical tech). Now this fixed foveated rendering does not help too much with performance, because it is set up specifically for the Bionic Display usage, where the high density panel is fairly large. So in order to make a performance boost in DCS, we want to use dynamic foveated rendering with quad views. However Eagle Dynamics did not implement that. This is what my original Varjo-Foveated mod did: it forces the eye tracking capability into DCS' implementation of quad views in order to achieve dynamic foveated rendering.
So ask number 1 to Eagle Dynamics is: can you implement the dynamic foveated rendering flavor of quad views in DCS? This is a very simple change to make. Stated in technical terms: Can you add support for XR_VARJO_foveated_rendering? It's really simple, all you need to do is add a couple of extra flags when initializing the OpenXR instance, the querying the resolution for your swapchains, and querying the view pose/FOV for rendering at each frame.
 
2) DCS implementation of quad views has bugs. In particular, related to the addition of dynamic foveated rendering above, there is a bug in DCS MT version where data from the next/previous frame is being incorrectly used for the current frame. Because of this bug, the foveated region cannot work properly when eye tracking is used, because the region ends up being warped out of place when you move your eyes. I implemented a workaround to this issue in both Varjo-Foveated and Quad-Views-Foveated.
This bug was reported to @BIGNEWY on March 18th in the post linked below, with a very detailed explanation including a detailed trace log. Actually both 1) and 2) were logged in that post back in March.
[/url]  
So ask number 2 to Eagle Dynamics is to fix this bug with XrFovf submission in order to make their implementation of quad views compatible with XR_VARJO_foveated_rendering.
 
3) Quad views support is currently only implemented by Varjo in their OpenXR runtime. The quad views technique and OpenXR extensions were coined by Varjo and as a result, only they had stakes to implement it in their platforms. This means that Valve, Meta, etc do not bother implementing support for quad views applications. So even when an application like DCS implements quad views, these vendors will not be able to run the application in quad views mode. This limitation is not on Eagle Dynamics, and there is nothing they can do about it. This is why I developed my second mod, Quad-Views-Foveated, and if you read closely the description of it, it doesn't talk at all about adding anything into the application:

In technical terms:
This software enables OpenXR apps developed with XR_VARJO_quad_views and optionally XR_VARJO_foveated_rendering to be used on platforms that do not typically support those extensions. It composes each quad view projection layer into a stereo projection layer, and uses the eye tracking support on the device to make the inner projection views follow the eye gaze.

What does that mean? It means that Quad-Views-Foveated does not fill a gap in the application (DCS), but instead it fills a gap in the platform (Oculus, Pimax, etc...).
Yes, Eagle Dynamics could pull in the entire quad views on top of stereo emulation framework that I created, but it's way outside of the scope of what any normal game engine should do and I would not expect (or even encourage) any game developer to do that. In addition, there are many challenges linked to eye tracking, because just like Meta, Valve, etc did not implement quad views support in their OpenXR runtimes, they also did not implement eye tracking support in them. Only Varjo implements the proper OpenXR interface for eye tracking (XR_EXT_eye_gaze_interaction). Meta chose to only expose social eye tracking data through a proprietary extension in Developer Mode only and recently Steam Link also only forwards eye tracking via a non-standard OSC interface. This is what a 3rd project of mine, OpenXR-Eye-Trackers, aimed at fixing. This is a complete nightmare for any game developer to have to deal with this mess and they really don't have to put up with it.
It's not Eagle Dyamics you need to ask the feature to: it's Meta, Valve, Pimax, etc. instead. They are the ones who need to build support for XR_VARJO_quad_views and XR_VARJO_foveated_rendering into their platforms.
On this front, there are 2 noteworthy developments:
a) Somnium has announced that their OpenXR runtime will have support for XR_VARJO_quad_views and XR_VARJO_foveated_rendering, which will put them at the same level of support as Varjo I believe. However, due to issues 1) and 2), users will still need the extra Varjo-Foveated mod in order to use dynamic foveated rendering in DCS.
b) Khronos (the organization behind OpenXR) is currently pushing quad views to become a core feature in OpenXR 1.1. This is a good news, because it means the name quad views will no longer be associated with Varjo only. However, in itself, it will not directly help the end-users: quad views remains an optional feature that is implemented at the discretion of the platform vendor. So Meta, Valve, etc will still be free to ignore that quad views is a thing and to not implement support for it in their platform.
 
Summary
- Eagle Dynamics, please resolve issue 1) and 2) described above in order to offer an implementation of dynamic foveated rendering that can work out-of-the-box on platforms like Varjo and Somnium. Resolving these two issues is a very small matter than could be achieved with little effort.
- Meta, Valve and other major platform vendors, please provide support for quad views configuration type out-of-the-box in your PC runtimes. Only by having major vendors with mass volume of users supporting the technology out-of-the-box we will encourage developers like Eagle Dynamics and others to provide support for this great technology that really benefits the end users.
Until all vendors align with providing quad views support in their OpenXR runtimes, I am afraid my Quad-Views-Foveated mod is going to remain the only way to do dynamic foveated rendering in DCS for Quest Pro, Reverb G2 Omnicept and Pimax Crystal users, and this is not a problem Eagle Dynamics can fix.
Always good info from Mbucchia, I would love if vendors would agree on a common sets of features and APIs