plane icon Welcome to Microsoft Flight Simulator’s SDK Q&A Platform!

You have questions regarding the SDK? DevMode Tools? SimConnect? You would like to submit an idea for future improvements, seek help or exchange knowledge? You’re in the right place.


Please take a moment to read the platform’s guidelines before you get started!


question

JB3DG avatar image
JB3DG asked JB3DG edited

Access to DX APIs in WASM

Having seen some of the other posts here about various display rendering possibilities, something that could be really helpful for developers is supporting D3D11/D3D12/D3D11on12 APIs in WASM, with the gauge callback providing a struct to the necessary object pointers (In D3D11, the ID3D11Device, ID3D11DeviceContext, and ID3D11RenderTargetView for the active texture the WASM callback is connected to. In D3D12 it would be the ID3D12Device, ID3D12CommandQueue, and ID3D12Resource for the active texture. These D3D12 objects can then be used to create D3D11On12 objects for DX11's API's ease of use). I understand XBox won't allow for runtime compiling of shaders, but does allow pre-compiled shaders according to an Asobo dev I spoke to a few years ago. This would open up considerable capability for highly complex glass displays like Proline Fusions and other displays, as well as easier back support for developers that have their own proprietary DX based display rendering libraries.

NanoVG has its limitations as does GDI+, especially for batch rendering of numerous display elements (most often on maps, but can also provide more efficient rendering for tape and rose displays as well as text), and both only allow for 2D displays rather than custom 3D displays. Also, drawing complex items like terrain displays is highly inefficient and performance intensive when done with CPU based APIs compared to shader based.

wasmnanovg
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

FlyingRaccoon avatar image
FlyingRaccoon answered

Hello @JB3DG

This is not planned.

Regarding features, like drawing 3D terrain, I'd say extending and improving the existing API is more likely to happen.
What limitations prevents you from using our MapView API for this?
MapView API (flightsimulator.com)

Regarding optimizations, it's up to our engine to batch rendering commands in the most optimized way possible.
If you encounter any performance issue that you think can be related to our implementation, feel free to report it here and we'll have some engine programmers have a look.

Regards,
Sylvain

10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

JB3DG avatar image
JB3DG answered JB3DG edited

The MapView API doesn't provide any control for variations of styles of map symbology (airport/navaid data etc) which can vary considerably from one aircraft to another. That forces an extra loop into the process, (first loop for gathering the data for the map display from ICAO databases, the new loop for rendering both a sprite object and a text object), while shader based code can take care of a good amount of the processing in sprite and text selection and the developer only needs to upload the array of symbol enumeration and text data for each object. This sort of render batching is vastly more efficient as it cuts the amount of processing on the CPU end in half.

Another limitation of the MapView API that I can see for terrain rendering is twofold. Firstly, the terrain resolution. TAWS/EGPWS maps tend to be much lower resolution than Garmin style terrain maps, resulting in a more blocky view), and secondly, TAWS/EGPWS maps have varying dot density patterns, not just solid colors for different warning/caution altitude layers. To render this via GDI+ or NanoVG involves loops that draw on the level of single pixels, or numerous very small primitives a few pixels in size. In contrast, custom shaders can be created where a single channel R32bit texture is uploaded containing altitude elevation data, which a pixel shader can then process vastly more efficiently into the output color.

Finally, on the 3D side of things, there is again considerable variation between avionics systems in their terrain coloring, texturing, resolution, and airport/object symbology.

Eg this Proline fusion's display of airports (the white dome at distance, runways close up)

plfsvs.png

Vs Garmin (flag with ICAO)g1k-airport.png Or this GRT EFIS (pink tower)

grtsvs.png


Also, as noticeable, there is wide variation in High Way In the Sky styles, like this L3 Smartdeck
smartdeck.jpg

Or this Proline 21lj60pl21.png

Or these UNS displays

https://i.imgur.com/EyJh11p.png


If direct access to DirectX APIs is not possible, an acceptable alternative would be a custom API to provide custom shaders, vertex and other buffers for said shaders, as well as texture objects to mimic a 3D rendering capability.


g1k-airport.png (1.6 MiB)
plfsvs.png (838.8 KiB)
grtsvs.png (125.5 KiB)
smartdeck.jpg (102.4 KiB)
lj60pl21.png (31.6 KiB)
10 |10000

Up to 5 attachments (including images) can be used with a maximum of 4.8 MiB each and 23.8 MiB total.

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 5 attachments (including images) can be used with a maximum of 19.1 MiB each and 23.8 MiB total.