Problem with Fixed Foveated Rendering, both eyes are always using the left eye ring

[oleuzop]

Hi,

I’m a developer of Falcon BMS (falcon-bms.com). A free mod, made by hobbyist like me in the last 25 years, of Falcon 4.0 (flight simulator from 1998)

In the last months I’ve added OpenXR support and, sincerely, I must say that it works like a charm. So thanks for making the standard and support in the past months.

The problem is that using OpenXR Toolkit I cannot get to work Fixed Foveated Rendering correctly in headsets with asymmetrical frustum (anything besides Pico4, which has symmetrical frustum for both eyes).

Let me explain the problem:

I cannot make the right eye FFR to work, both eyes seem to me that they are using the left eye FFR’s mask.

The following image is from a Quest 3, I’ve added CULL in the OpenXR Toolkit middle ring so it’s easier to see where it’s located.

It’s easy to see that both rings are the same, for the left and right eyes, and that the left one is centered (OTK menu is in the middle of the circle) and the right eye is not centered.

I believe this is due to the fact that both eyes are being rendered at the same time, to their own RenderTarget DX11 textures and then, right before xrEndFrame(), both RTTs are being copied to OpenXR’s SwapChain RTTs.

A simple diagram of the rendering pipeline to clarify the above concept:

In brief:

My question is if there is any way to force FFR eye with some parameter in the RTT or similar? Maybe something related to TextureArrays?

or is it mandatory to render between each acquired XrSwapChain?

If anyone can throw a little bit of light in this I appreciate it a lot!

I prefer to ask before refactoring a 25+ years sources with several contributors through the years is waaay faaaaaaaar from easy.

The expected result should be something like this:

Last words:

I know this is a forum about pure OpenXR but since OTK Discord is closed I don’t know where to ask this question. I’ve been trying to solve this problem for a while without success and I don’t know which other place I could address.

Sorry in advance for this.

If you consider this is not the right place feel free to delete this topic and sorry for the inconvenience!

Kind regards and thank you in advance for any help!!

[mbucchia1]

Don’t rely on OpenXR Toolkit, it’s no longer maintained. The goal of the tool was to demonstrate how this sort of features would benefit VR when game developers were not paying attention.

The issue you’re having right now is that OpenXR Toolkit is trying to guess which render target is left eye and right eye during rendering. This guess is not going to be bulletproof, and as you can see, it isn’t guessing correctly with your engine.

Foveated rendering is not meant to be injected/forced via external means.

If you’re the developer of BMS, then what you should do instead is properly integrate VRS into your game (without the need for an extra mod) where you know exactly which render pass does what and whether the renderpass needs to use a left eye VRS map or right eye, and whether the renderpass better skip doing VRS to avoid glitches.

[oleuzop]

I really thank you for your answer (and for creating OTK!)

I have thought of this possibility but since most of the community still uses OTK I wanted to give it a try.

With Pico4 (as said, the only headset that works correctly because of its symmetrical frustum), in the upcomming version which is much more GPU bounded, using FFV, it gives an increase of 25-30% in FPS. Which is considerable!

I’ll implement Variable rate shader, that’s probably the best solution.

Thanks again for your help and for all your contributions to the OpenXR community!

[oleuzop]

I just wanted to thank you again for your help.

With a little bit of research and programming it has been super easy to integrate FFV (and NIS) inside BMS simulator.

Still some tweaking and so on to be finished, but working fine, even better, because now, for example, I can exclude shadow maps and other RTTs that should not have FFV.

Thanks again!!

Kind regards!

[mbucchia1]

This is great to hear. Doing it in the app is always the right option, both for performance/quality and also user experience!