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.
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
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)
(flag with ICAO) Or this GRT
EFIS (pink tower) Also, as
noticeable, there is wide variation in High Way In the Sky styles, like this
L3 Smartdeck Or this Proline
21
Or these UNS displayshttps://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.