Navigation display
| IMPORTANT: Some, and possibly most, of the features/ideas discussed here are likely to be affected, and possibly even deprecated, by the ongoing work on providing a property tree-based 2D drawing API accessible from Nasal using the new Canvas system available since FlightGear 2.80 (08/2012). Please see: NavDisplay for further information
You are advised not to start working on anything directly related to this without first discussing/coordinating your ideas with other FlightGear contributors using the FlightGear developers mailing list or the Canvas subforum |
|
Status
As of FlightGear 2.99/3.0, also see NavDisplay. This one can be considered to be deprecated: we strongly recommend switching to the Canvas NavDisplay at this point, the C++ one is never going to receive any maintenance or updates. [1]
Background
There's a new 'NavDisplay' instrument, which is another kind of dynamic texture, along with ground-radar. It is designed to show navigation type info (route, waypoints, traffic, airports, navaids) in a customisable way, and hence be used to simulate the navigation modes of various modern cockpits.
The 'NavDisplay' code in FlightGear 2.6 is already fully generic - using XML and some clever PNGs, it should be able to approximate most moving-map type displays - Honeywell/Boeing, Airbus, a basic Garmin (maybe not a G1000), or various military displays. Right now.
You should be able to get the ND showing TCAS, waypoints, the route path, VORs and airports. I would hope the symbol definitions and textures you need can be borrowed from the A380 and converted, otherwise I have the 777 versions (which are definitely different!) or they're in the main 777 repo.
The navigation display (ND) instrument provides a texture resembling the display of the navigation or map displays found in many digital cockpits and GPS units. The instrument tries to be sufficiently generic, to approximate many different real-world displays. Fortunately, most real-world displays are quite similar to each other, with some systems offering additional features that will be added later.
Since the ND system simply displays entities (AI objects, navaids, etc), in an area into a 2D display, it's hoped that it can be reused for some other kinds of cockpit display.
Weather radar (WXR) and terrain (TERR / EGPWS) layers are planned as complementary textures, which would be displayed beneath the ND texture.
Status
Prototype code exists, which is in the process of being re-written to provide a more configurable system. Navaid, airport, waypoint, route and traffic (TCAS) data can be displayed. Current screenshot
Updates
- 04/2012: FMS related features are being actively worked on and discussed with Scott. Especially the storing of speeds / altitudes, and handling terminal procedures sanely. And handling of multiple routes (flight plans) is coming too, so you can have active, secondary and save and load these. What I'm working out is how much to do in C++, and how much to leave for Nasal to help with. If you message me your email address, I'll CC you on any discussions with Scott about the API. The only issue is if it reaches a 'good enough' state in time for 2.8 - I hope so. [1]
Configuration
The ND instrument has a number of configuration properties, most of which can be changed dynamically to reflect display state changes. Importantly, the logical origin on the display can be moved to simulate ARC versus centred modes, the 'up' heading can be set to allow for PLAN vs up-is-aircraft-track vs up-is-aircraft-heading modes. Similarly the range (in nm) can be set.
Certain values cannot be changed at runtime - principally the output texture size and related properties. The output texture size is intended to model the real-world device's physical resolution, i.e you can create an artificially pixelated display by choosing a low size. (The size should still be a power of two) Very large sizes may have a performance impact - to be tested.
Symbols
Symbols are the main display element of the ND. Each symbol can have a textured quad, positioned and rotated on the display, with a color assignment, and optionally a text label. The main configuration task in creating a ND, is to define the symbols.
At runtime, the ND code finds potential display items, and then locates the best matching symbol rule(s) to use for them. Many symbols are small - for example identifying an obstacle, VOR or waypoint. The design intentionally allows for large symbols, to achieve various effects - for example a tuned VOR might have a large symbol rotated along the selected radial.
It's also assumed that occasionally multiple symbols might be used to create the appearance for one on-screen element - eg for a TCAS element, the traffic type and vertical-speed arrow might be defined by separate rules, overlaid at runtime.
Selection
Symbol rules apply to a particular type or types of item. The list of types (and some other information available) is given below, but should be straightforward. Adding more types is possible, if requested (and FlightGear supports them!)
In addition to the type-selection, each item to be displayed has various states computed, to allow more precise rule selection. For example a VOR might be in the 'tuned' state (and also the 'tuned-nav1' state), to indicate the Nav1 receiver is currently tuned to it. Similarly a waypoint might have states 'active', 'inactive', 'on-flightplan', and so on.
When you write rules, you specify the types it applies to, and the states that must be present or absent for the rule to apply.
Each rule has a regular conditional element which decided if it should be considered at all. This can be used to switch between symbols based on modes. For example, the 777 ND displays departure and destination airports differently if the selected range is above 80nm. This can be achieved with two symbol rules, enabled based on a greater-than and less-than conditionals on the selected display range.
Texture
Each symbol must define its rectangle in logical pixels, and the area of the symbol texture it comes from. The rectangle can be positioned anywhere, relative to the 0,0 point which is the symbol location. Most symbols will be centred on their origin, but there is no requirement for the rectangle to be symmetric, or even include the origin.
If the item being displayed exposes a heading, the rectangle can be rotated by this. This allows runway, traffic or tuned-navaid symbols to include 'tails' showing their orientation.
The symbol supports a Z-order value to arrange items during rendering.
Text
Custom symbols
In addition to the build-in symbol sources, you can define your own symbol items in a property tree. This is to allow custom items on the display, which can be used to achieve most aircraft-specififc customisation. Items can be positioned in display pixel coordinates (X/Y), lat/lon or relative to another point. This allows for items such as the INS / GPS position icons on the Boeing display, climb/descend point symbols on the active route, or additional lubber/track/heading lines.
In general you will write some Nasal or XML to update these properties each frame (eg, reading the simulated INS position or calculated top-of-climb position) and write that into a property node, supplying the type and state values. Symbol rules with then be applied as normal.