• 0
Sign in to follow this  

Sparse Grid Super Sampling Causing Issues with Displays


1 answer to this question

Recommended Posts

  • 0
Posted (edited)

The rendering technology the TFDi Design 717 uses (Direct2D) is not compatible with SGSS in the environment it's in within Prepar3D. In future products, we may refrain from using this technology. For now, SGSS is not compatible with the TFDi Design 717. More information is available here: https://tfdidesign.com/index.php/knowledgebase/36/TabletorInstruments-not-displaying-properly.html.


The full, technical explanation is below.

More specifically,  SGSS isn't a native function of the official NVIDIA tools/drivers. It requires a third-party utility (NVIDIA Inspector) to enable. This already puts it a disadvantage. Beyond that, the problem exists, apparently, due to use of the Microsoft Direct2D 2D rendering library on our gauges. This decision was originally made (years ago) with the intent to offer better performance than GDI+ gauges (as it is more GPU based, and could offload some of the load from the CPU). Evidently, this was a mistake, as Direct2D has continually proven to be at the center of various complaints. In the future, we won't use it, but converting the TFDi Design 717's code from Direct2D to GDI+ (or another library) would require a major re-work of every single display (all 6 DUs, the tablet, the standby, MCDUs, and annunciators) to complete. The problem with SGSS seems to be due to multi-pass antialiasing/sampling between when our gauges are drawn and when the simulator renders them (as this happens in several steps). The reason other products on the market don't experience this is that we are one of very few who use Direct2D (again, now we have an idea why that might be). Other products outside of these simulators don't have this issue as they are in control of the rendering pipeline in a way that we are not.

Versions of the product in Prepar3D v3, etc. did not experience this issue because there was the option to choose between hardware and software rendering on the displays. This allowed a user to circumvent the issue by changing the rendering pipeline. This option is no longer compatible with Prepar3D v4, as we've switched to using the PDK rendering surfaces. This was to increase visual fidelity (which it did) and improve performance (which it did). Unfortunately, removing this option also removed the workaround for SGSS.

This leaves us with two choices: offer a less performant, lower quality version of our product or completely re-write our display system. Either of these choices seems unreasonable when the goal is to support an unofficial antialiasing method, especially when others are available.

Edited by turbofandude
Further information.

Share this post

Link to post
Share on other sites
This topic is now closed to further replies.
Sign in to follow this