EFIS Screens Problems and Solutions for higher legibility


I’d like you to consider the following suggestions (see below for bug description):

  • Provide an option to rendering the EFIS screens using XrCompositionLayerQuad*
  • Adjust the EFIS render resolution from the Post-Process resolution instead of the Render resolution.
  • Provide user setting for the EIFS rendering resolution independently of the TAA Render resolution.

Brief description of the issue:

When exploring different combinations of Render Scaling (FS2020) vs Super Sampling (SteamVR or OpenXR) I came to the conclusion unless having a Reverb G2 and a 3090, we have no other choice finding a balance in legibility. In short, keeping overall performance equal, I can either get:

  • Good external visuals at a distance and great analogue gauges (SS > 150%) but fuzzy EFIS screens (TAA 70%).
  • Sharp EFIS (TAA 100%) but less detailed external visuals and analogue gauges (SS < 80%).
  • Balanced EFIS, external visuals and analogue gauges with TAA and SS 100% but with a performance cost.

In effect, FS2020 is rendering each frame at the Render Res. resolution (TAA) prior enlarging it to the Post Process Res. (SteamVR SS or OpenXR RS). When enlarging the rendered frame, the pixels are interpolated not just using a bilinear filter (fuzzy) but the CAS Shader (see link below). It is nice yet there is no magic: you can’t restore the resolution of a native 2Kx2K image from a 1Kx1K source.

However when rendering the views at the TAA Render Res., it is also reducing the legibility of the EFIS screens for two reasons I can identify:

  • CAS Shader is conflating the fine lines of the EFIS displays
  • FS2020 is reducing the render resolution of the EFIS displays proportionally.

Detail steps to solve the issue encountered:

1. In using Composition Layer Quads:

In using the Composition Layer Quad, FS2020 could be rendering razor sharp EFIS because the resolution would be based on the Post Process Res. (SS) while for the rest, it would use the TAA value which we set lower than 100% to preserve performance. In effect, my tests show using TAA70+SS150 for example gives better visual at the distance than TAA100+SS80 on the Index, despite the former having less rendered pixels than the later (thanks to CAS). It might even be neutral in terms of rendering time because although the simulator would not be rendering the EFIS in the 3D geometry twice at lower res (1 per eye) and would instead send a single EFIS picture once for both eyes at higher res, the OpenXR driver would just be compositing the single EFIS layer twice.

NB: the drawback in doing so is loosing the benefits of rendering the EFIS in the 3D screens, like loosing the reflections and FS2020 should accommodate a different way to handling the screen luminosity (not hard to do though). Nevertheless, trading reflections for razor sharp EFIS and maybe additional fps is something I’d like being able to try out and compare, and maybe many others as well.

2. In using the Post-Process resolution instead of the Render resolution:

Rendering the EFIS screens with higher resolution would allow them being displayed in the cockpit in VR at the lower rendering resolution (lower than 100%) with a quality similar to what you get when doing super sampling. It is very effective with EFIS screens where small lines and features often get aliased otherwise.

Furthermore this should have marginal impact on the performance: I’ve tested altering the asobo-vcockpits-core\html_ui\Pages\VCockpit\Core\VCockpit.js code in order to display all the A320 EFIS at twice their resolution and there was no difference in fps in VR. (NB: commenting out all A320 gauges in the panel.cfg file though increases the fps a lot, showing the most demanding is the JS code, not the rendering).

3. In using a user setting resolution scale factor:

This will be the same as the above, except instead of using a fixed value depending on the post-process resolution only, it would be user adjustable and providing fine tuning for one’s hardware and preferences.

Provide Screenshot(s)/video(s) of the issue encountered:

Here are the links to some of my discussion explaining the differences using TAA render scale and VR render scale and some strategies to maximizing the experience:

Valve Index - SteamVR:
My 2070 SUPER VR settings and suggestions (Index - SteamVR)

I’m recommending the following render scaling settings:

FS2020 SteamVR Comments
TAA 60% SS 220% Breathtaking visuals and crisp enough EFIS with solid fps (my fav)
TAA 100% SS 78% Best for Airliners where EFIS sharpness is more important than external view
TAA 70% SS 100% Best for analog gauges GA aircraft with good and detailed outside view.

Reverb G2 - WMR:

I’m recommending the following render scaling settings:
My 2070 SUPER VR settings and suggestion (Reverb G2 - WMR)

FS2020 OpenXR Comments
TAA 70% SS 70% Well balanced gauges and external visuals with solid fps
TAA 80% SS 60% Best for Airliners where EFIS sharpness is more important than external view
TAA 60% SS 100% Best for analog gauges GA aircraft with super detailed outside view.

Please note: these are selected to match the unique Index/G2 resolution and might not always apply to other headsets. TAA ## means FS2020 Render Scaling, SS ## means SteamVR/OpenXR Render Scale.

Further Information:

XrCompositionLayerQuad is he OpenXR API FS2020 is most likely using when displaying flat textured rectangles as floating windows, like the “Settings” window, or the popup windows like the ATC, Map etc…

XrCompositionLayerQuad - OpenXR Manual Page
What is the Timothy Lottes CAS Shader implemented in FS2020 (doc and demo)

Loving your work Cpt. Many thanks for your in-depth analysis on this and many other issues.

Does that mean that this is something modders could address (to some extent), in lieu of Asobo addressing the broader issue?

1 Like

Thank you for your kind words!

This is not something you can mod unfortunately because there is nothing we can re-code in the default JS code base which would change it.

There is indeed a provision to change the EFIS rendering resolution but it is failing to work as expected and I have not gotten any feedback yet about this specific bug (just “this is how it is supposed to work”). But I hope they’ll address this bug, after all, they’re in contact with hundreds of other 3rd party developers* doing aircraft and there is no way none of them hasn’t reported this very basic panel.cfg issue yet isn’t it? :face_with_symbols_over_mouth: :smiling_imp:

PS: the bug is in panel.cfg not honoring the pixel_size parameter (so it seems).

*according to the latest Q&A (not me though, so I can only report on forums and Zendesk)

1 Like

This is a really important concept for those of us running on somewhat modest hardware. It made the VR list, so hopefully it will get some attention!

1 Like

Can multiple rendering scales be implemented?

I often fly B747 in VR mode.
That experience is extremely realistic and fun!

In doing so, I drop the rendering scale to 70 in order to increase the FPS.
The visibility of the main panels such as the PFD is significantly reduced, but I have no complaints at all about the resolution of the scenery outside the windows and the 3D cockpit.
Especially for the scenery outside the window, it looks good even with the render scale set to 50.

View outside the window = Render Scale 50
3D cockpit = render scale 70
Main panel (PFD/ND/FMC) = Render Scale 100

As mentioned above, I would like to see the implementation of the ability to set any rendering scale for each layer.

Thank you.

Best way to incremet fps is single pass rendering mode.
Single Pass Stereo rendering allows the GPU to share culling for both eyes. The GPU only needs to iterate through all the GameObjects in the Scene once for culling purposes, and then renders the GameObjects that survived the culling process.

1 Like

Hi CptLucky8,

Happy to find this thread here.
I was facing the same challenge with the fidelity of the digital panels in VR mode using the scaled down TAA or even DLSS sampling.
I decided to try another approach: I created a custom toolbar panel and managed to instantiate the VCockpit.js inside the custom panel and then load any HTML instrument (including the data from the xml file). This seems to work so far. I can open the panel from the panels menu and the HTML instrument is rendered not as part of the 3D cockpit, but as a custom panel.

In theory, it is possible to grab and move the custom panel in 3D inside the VR cockpit. This makes it possible to position the panel on top of the 3d cockpit panel, and even removing the 3d panel from cockpit.cfg file.

However , I’m still facing some issues with accurately positioning the toolbar panels in 3D and also persisting those 3D positions over MSFS restarts.

If you are still working on this topic, let me know.
I created a separate topic for accurate 3D positioning of panels in VR mode