How to alias MFDs and HUDs from existing aicrafts

    • Official Post

    Hello Dino,

    currently all glass cockpit screen rendering code is written in C++ and compiled together with the Executable. So at the moment it's not yet possible for third parties to create their own EFIS or HUD renderings. We will most likely develop a scripting language in the future or provide a Visual Studio C++ solution with the required libraries so that external developers will have total freedom to develop efficient rendering code, using our own rendering engine.

    As far as materials go, I'm afraid I am not an expert on that :D


    • Official Post

    You can copy the texture_animation objects to use the PFD or similar from an existing aircraft. Let's assume you wan't to copy the A320 PFD, you would copy texture_animation object 'DisplayTexture', the graphics_animation_display object 'DisplayPilotLeft' and the display_a320 object 'EFISPilot'. Set the TextureName in the first one to your display's luminance/self-illumination texture name and edit the RenderList to contain DisplayPilotLeft.Render only. In the DisplayPilotLeft object, set the target area for the display on your texture (i.e. the area of the texture that is mapped to your display, lower left corner is 0,0 ). Set the GeometryList to the name of the display 3D object (must be a separate object in the 3D file) and remove the ND.render from the RenderList for the beginning. The most difficult part is to provide all the values the display_a320 object uses, use the a320.tmd as a reference on how generate the values in the dynamics section and how to transport them to the graphics. You can start with some basic values and add more when the display shows up correctly.

    • Official Post

    Yes, that works.

    Per texture that is rendered to a "texture_animation" object must be provided. The "TextureName" is the file name of the texture. Most of the times its the light map, the texture that determines the brightness at night, self-glowing.
    All Function-Calls listed in the RenderList are executed one after the other each render frame.

    Ergo: texture_animation calls graphics_animation_display.Render()

    In the Render function of the graphics_animation_display class its first checked if any of the 3D models listed in the GeometryList attribute are in sight (camera-view and bounding box, I believe), then output of the "InputDisplay" funtion call is converted to an index in the RenderList and the render function at that index is executed. (graphics_animation_display calls display_a320.Render())
    Internally TargetPosition and TargetSize are divided by TargetScale to get OpenGL texture coordinates before the render call. TargetPosition is the lower left corner, you can use decimal places for both x (to the right) and y (upwards). The Size is width in x direction and height in y direction, both also allow decimals. TargetScale is the size of the texture where you measured target position and size in.
    Make sure that the InputLuminance is set correctly, otherwise the renderings are dimmed to 0.0 and are not visible even if everything else is done correctly.

    The display_a320 class contains the actual drawing logic and it reads all the elements in the "Inputs"-list before each render frame. (At least currently.) If the inputs are not provided to the display_a320 object they default to 0.0 or false. With the RenderFunctionNumber we determine what to draw, a PFD, ND etc..