[BUG/FEATURE] 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)

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