FG1000: Difference between revisions
m (move old PUI-based screenshot to new gallery section) |
(Add PFD) |
||
Line 16: | Line 16: | ||
== Current Status == | == Current Status == | ||
24/02/2018: | |||
* A very basic PFD is available with horizon, compass rose, altimeter, speed tape. | |||
* Initial implementation of the MFD is available on git/next. It is integrated with the [[Route Manager|route manager]], GPS and the generic NAV/COM radios. It displays engine information from a single piston engine, and can be used as an EFB. | |||
* MFD and PFD can be displayed as a GUI window under Debug menu or added to an aircraft with the GDU-1045 model as part of a 3D cockpit. | |||
There's still a huge number of pages to write, and the pages around route planning will likely be particularly challenging, but it should be far faster now these blocks are in place. . If anyone is interested in creating a specific page, please also get in touch with Stuart. The various ''Nearest... and ...Information'' pages should be quite easy to do based on the pages that have been written already. See the Design Notes for details. | There's still a huge number of pages to write, and the pages around route planning will likely be particularly challenging, but it should be far faster now these blocks are in place. . If anyone is interested in creating a specific page, please also get in touch with Stuart. The various ''Nearest... and ...Information'' pages should be quite easy to do based on the pages that have been written already. See the Design Notes for details. | ||
Line 24: | Line 25: | ||
Next steps: | Next steps: | ||
* Writing the remaining (large) number of pages | * Writing the remaining (large) number of pages | ||
* Complete the PFD function | |||
* Styling the pages - making the iconography match Garmin exactly. | * Styling the pages - making the iconography match Garmin exactly. | ||
Line 46: | Line 48: | ||
Implemented function: | Implemented function: | ||
PFD: | |||
* Basic artificial horizon, compass rose, altimeter and airspeed indicator | |||
MFD: | |||
* There is a two channel NAV/COM with an active and standby frequency and automatic ID of NAV frequencies at the top of the UI. They all integrate with the standard properties, so should work automatically with most aircraft. | * There is a two channel NAV/COM with an active and standby frequency and automatic ID of NAV frequencies at the top of the UI. They all integrate with the standard properties, so should work automatically with most aircraft. | ||
* If you have a frequency highlighted in any of the pages (e.g. WPT - AIRPORT INFORMATION) press the ENT key to load it into the standby NAV/COM frequency as appropriate. | * If you have a frequency highlighted in any of the pages (e.g. WPT - AIRPORT INFORMATION) press the ENT key to load it into the standby NAV/COM frequency as appropriate. | ||
Line 84: | Line 90: | ||
<syntaxhighlight lang="nasal"> | <syntaxhighlight lang="nasal"> | ||
var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/"; | var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/"; | ||
var interfaceController = fg1000.GenericInterfaceController. | var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance(); | ||
interfaceController.start(); | interfaceController.start(); | ||
</syntaxhighlight> | </syntaxhighlight> | ||
Line 117: | Line 123: | ||
# Create the FG1000 | # Create the FG1000 | ||
var fg1000system = fg1000.FG1000. | var fg1000system = fg1000.FG1000.getOrCreateInstance(); | ||
# Create a PFD as device 1, MFD as device 2 | # Create a PFD as device 1, MFD as device 2 |
Revision as of 21:28, 26 February 2018
Started in | 07/2017 |
---|---|
Description | G1000-based MFD emulation |
Contributor(s) | Stuart, Richard (via Emesary), Michat (UI graphics), www2 (3D artwork) [1] |
Status | Under active development as of 07/2017 |
Folders | https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Aircraft/Instruments-3d/FG1000/ |
Changelog | https://sourceforge.net/p/flightgear/fgdata/ci/next/log/?path=/Aircraft/Instruments-3d/FG1000 |
Current Status
24/02/2018:
- A very basic PFD is available with horizon, compass rose, altimeter, speed tape.
- Initial implementation of the MFD is available on git/next. It is integrated with the route manager, GPS and the generic NAV/COM radios. It displays engine information from a single piston engine, and can be used as an EFB.
- MFD and PFD can be displayed as a GUI window under Debug menu or added to an aircraft with the GDU-1045 model as part of a 3D cockpit.
There's still a huge number of pages to write, and the pages around route planning will likely be particularly challenging, but it should be far faster now these blocks are in place. . If anyone is interested in creating a specific page, please also get in touch with Stuart. The various Nearest... and ...Information pages should be quite easy to do based on the pages that have been written already. See the Design Notes for details.
Next steps:
- Writing the remaining (large) number of pages
- Complete the PFD function
- Styling the pages - making the iconography match Garmin exactly.
Gallery
A Cheat's Guide to Using the FG1000
For those without the time or interest to read the G1000 User Guide, here's a very quick run-down on navigating through the MFD:
General:
- Click on the buttons, though some are not implemented yet.
- Use the mouse wheel to scroll the knobs (NAV, HDG, ALT, COM, CRS/BARO, RANGE, FMS). For knobs with both and inner and an outer (NAV, COM, CRS/BARO, FMS), scrolling when pressing the Shift key changes the outer knob.
- Use the outer FMS knob (shift-mouse wheel on the FMS knob on the bottom right) to navigate through the page groups.
- Use the inner FMS knob (mouse wheel on the FMS knob on the bottom right) to navigate through the pages within the group. The currently selected page is shown in blue. If you stop moving the cursor, the page will be loaded in 0.5s.
- Within a page, click on the FMS knob to activate the cursor (CRSR). You you should see some element highlighted on the page, typically flashing. You can navigate around the page using the outer and inner FMS knobs. The Outer FMS knob (shift-mouse wheel) typical moves the cursor between elements. The Inner FMS knob typically changes the selected item.
- Use the RANGE knob to zoom map views in/out.
Implemented function:
PFD:
- Basic artificial horizon, compass rose, altimeter and airspeed indicator
MFD:
- There is a two channel NAV/COM with an active and standby frequency and automatic ID of NAV frequencies at the top of the UI. They all integrate with the standard properties, so should work automatically with most aircraft.
- If you have a frequency highlighted in any of the pages (e.g. WPT - AIRPORT INFORMATION) press the ENT key to load it into the standby NAV/COM frequency as appropriate.
- To set up a GPS Direct To route:
- Press the DTO button (D with an arrow through it on the right side of the panel, below the word "PAN"). This will bring up a Direct To window, allowing you to enter the ID of an airport, Fix etc. to navigate to.
- You can enter the ID in one of two ways:
- Scroll the FMS knob backwards to bring up a sub-menu of waypoints categories (FPL, NRST, RECENT, USER, AIRWAY). Use the inner FMS knob to scroll between the different categories, and the outer FMS knob to select a specific item.
- Scroll the FMS knob forwards to enter an ID manually using the FMS knob. Use the outer FMS knob to move to the next poisition in the ID.
- Once you've got an ID, press ENT which will load details into the window and highlight the ACTIVATE button.
- Press ENT once more to load the Direct-to into the GPS and activate it.
- To view airport information, select the WPT - AIRPORT INFORMATION page. Use the outer FMS knob to move between the AIRPORT, RUNWAYS and FREQUENCY boxes, and the inner FMS to edit the airport ID, scroll through available runways, or highlight a frequency.
Aircraft Installation
Adding the FG1000 to an aircraft is intended to be fairly straightforward.
Add the GDU to the cockpit
Place one or more of the display (GDU) units in your model. The XML files are in GDU104X directory and are named <model>.<device-number>.xml, e.g.
GDU-1045.1.xml GDU-1045.2.xml GDU-1045.3.xml GDU-1045.4.xml
The <device-number> is referenced later to identify which displays to used for each PFD, MFD etc. You must only used one of each <device-number> value, though you can mix and match the GDU models.
Load the Interfaces to provide data
This is used to provide airdata, navdata, NAV/COM settings, engine information to the GDUs. There is a generic interface (GenericInterfaceController) that uses the standard FG route manager, GPS, navigation data and NAV/COM settings, and engine data for a single piston engine.
You need to load it as follows:
var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/";
var interfaceController = fg1000.GenericInterfaceController.getOrCreateInstance();
interfaceController.start();
You may want to create your own version depending on what properties you are using for the NAV/COM, and your engine configuration.
Note that you should only start the interface after you've started the FG1000 as they will publish information at start of day that the displays need.
Create an EIS Display
This is the Engine Information System and displays on the left side of the MFD.
There is a generic EIS provided (see FG1000/Nasal/EIS, and FG1000/MFDPages/EIS.svg) that is intended to match a Cessna 172. If you need something different, you should create your own EIS class and SVG file.
Note that you need to pass data to/from the engine using Emesary. See Interfaces/GenericEISPublisher.nas for a reference implementation.
Load and start the FG1000 system
See FG1000/Nasal/FG1000.nas for full details, including how to pass in the EIS. A simple FG1000 using the generic EIS, and displaying PFD on device-number 1 and an MFD on device-number 2 is as follows:
var nasal_dir = getprop("/sim/fg-root") ~ "/Aircraft/Instruments-3d/FG1000/Nasal/";
io.load_nasal(nasal_dir ~ 'FG1000.nas', "fg1000");
# Create the FG1000
var fg1000system = fg1000.FG1000.getOrCreateInstance();
# Create a PFD as device 1, MFD as device 2
fg1000system.addPFD(1);
fg1000system.addMFD(2);
# Display the devices
fg1000system.display(1);
fg1000system.display(2);
# Display a GUI version of device 1 at 50% scale.
#fg1000system.displayGUI(1, 0.5);
Page Status
This is the current status of the individual pages. "Done" indicates that they are functionally complete, though the iconography is not correct.
Page | Reference | Status | Notes |
---|---|---|---|
Navigation Map | Done | See Layers below | |
Traffic Map | Done | Zoom controls unclear | |
Storm Scope | Not Started | ||
Weather Data Link | Not Started | ||
TAWS-B | Not Started | ||
Airport Information | Done | Needs additional page of AOPA information, which we don't have | |
Intersection Information | Not Started | ||
NDB Information | Not Started | ||
VOR Information | Not Started | ||
User WPT Information | Not Started | ||
Trip Planning | Not Started | ||
Utility | Not Started | ||
GPS Status | Not Started | ||
XM Radio | Not Started | ||
System Status | Not Started | ||
Active Flightplan | Not Started | ||
Flight Plan Catalog | Not Started | ||
Stored Flight Plan | Not Started | ||
Checklist 1-5 | Not Started | ||
Nearest Airports | Done | ||
Nearest Intersections | Done | ||
Nearest NDB | Done | ||
Nearest VOR | Done | ||
Nearest User Waypoints | Not Started | ||
Nearest Frequencies | Not Started | ||
Nearest Airspaces | Not Started |
This is the current status of the major functional elements
Area | Status | Notes |
---|---|---|
Navigation - FMS | Complete | |
Softkeys | Complete | |
MENU key | Not started | |
NAV/COM | 95% Complete | Volume controls to be added |
GPE Header | Not starter |
Motivation
|
The enormous variety in current glass flight decks means we really need to think of a new way of defining glass cockpit layouts.[2]
The airspace system is in the process of changing drastically [...] this isn't just a matter of throwing up a canvas showing some GPS waypoints and a magenta line. Modern navigators are astoundingly-complex devices — probably an order of magnitude more lines of code than FlightGear itself — and even their basic flight planning algorithms and databases (e.g. fly-by waypoints vs fly-over waypoints, open vs closed approach procedures, transitions into RNAV approaches, etc.) are far beyond the scope of anything we've tried, and we'd also need an up-to-date database far more complex than the ones we have now. Once you get to the extra features, like FIS-B weather or TIS-B traffic info over ADS-B, or TAWS (terrain alerting), we're probably in way over our heads trying to emulate even the simplest general-aviation IFR GPS.
This may help folks understand what the G1000 is all about: http://static.garmincdn.com/pumac/190-00498-07_0A_Web.pdf Writing a G1000 isn't that hard. Writing a feature complete G1000 is a ton of work. [3]
Depending on how we deal with this challenge, the question is whether that means that the usefulness of FlightGear will also gradually taper off. [4]
Instead of just making one-off tweaks like the consumer sims did, we (as a team) emulated entire systems like the vacuum, pitot-static, and electrical systems, so that failures would be realistic. In the RNAV age, we need to do the same thing; it's just that it's a bigger job. FlightGear will still be great for people who want to practice the mechanical parts of flying (e.g. crosswind wheel landings in a Cub), but will slip further and further behind for people who want to use it for real IFR practice.[5]
Background
|
Challenges
Performance
Nasal as such is fast, and compared with the cost of rendering the terrain, rendering a canvas display is fast on the GPU (you can test by rendering but not updating a canvas display), and unless you're doing something very inefficient, calculating a display but not writing it to the property tree is fast (you can test this by disabling the write commands). It's the property I/O which you need to structure well, and then canvas will run fast. And of course the complexity of your underlying simulation costs - if you run a thermal model underneath to get real temperature reading, it costs more than inventing the numbers. But that has nothing to do with canvas. [6]
it's a lot of work to code all these displays which someone has to do, but there's no reason to assume it'd be hopeless performance-wise.[7]
we need to be realistic here: The G1000 is a fairly significant piece of computer hardware that we're going to emulate. It's not going to be "free" particularly for those on older hardware that's already struggling. However, hopefully we can offload a chunk of the logic (route management, autopilot/flight director) to the core, and do things like offline generation of terrain maps to minimize the impact.[8]
Route Manager
that's exactly the kind of device James hopes the new code can support. He's read the G1000 pilot's manual, and *thinks* that nearly all the functions can be provided by the current GPS code It would be great if people could look over the current GPS features and indicate any pieces you think might be missing - additional commands, additional search features, extra data, or anything really. [9]
tile servers
Please keep in mind that most tile servers discourage bulk downloads. For the whole planet,oomlevel 8 is approx. 67k files, at zoomlevel 9 you have 265k, level 10 has a little over one million tiles. And one would probably want to go up to level 15 (roughly 1e9 files)[10]
Offline mode
would it be possible to provide an offline tool to pre-fetch a region, like TerraMaster, or terrasync.py? Call me old-fashioned or paranoid, but I don't want FG to go online and do stuff automatically, I prefer downloading what I need manually so that I know what gets onto my harddisk. Also - think of all the people with poor home internet which might have larger bandwidth only in a library elsewhere.[11]
that would certainly be possible - the code retrieving the data is pretty trivial and porting the Nasal code to python or some other script should be straightforward.[12]
we need some better data sources, especially with direct routing replacing airways in many areas, and having airspace data would help the map displays, but the current API is specifically designed to support G430, G1000 and similar class devices. Adding RNAV approaches is eminently doable, see the the RNavController base class which the GPS/FMS layer uses to allow new waypoint / route segments to define how they are flown and drive CDIs [13]
Getting the algorithms right, and keeping the data up to date every 7 weeks (we have only a tiny sliver of that data currently), is going to be much more of a challenge. I expect that it's probably an order of magnitude more complicated than our current flight dynamics (etc.), so we'd have to grow our contributor base, and find funding to pay at least Curt (and maybe a couple of others) full time to manage the project. Note that that's what has happened for other complex FOSS projects, like office suites and browsers, which generally end up working through a foundation, rather than our current relaxed circle-of-friends arrangement. The reason it's so much harder now is that the software *is* the product for GPS navigators, FMSs, etc. (unlike with older avionics, where the hardware was the main thing). That means that emulating even a simple unit like the GTN 650 or GNS 430W is almost difficult as building one, so we're trying to keep up with armies of full-time software developers at Garmin, Avidyne, etc.[14]
According to the Route Manager wiki page, we already have support for SID/STAR data provided from Navigraph, which is released on the AIRAC cycle, and costs a pretty small amount (9 EUR for a single download of FMS data, or 90 EUR per year) Given the relatively low cost, I don't think that we as an organiation want to get into trying to digitize data ourselves just to make it open-source or public domain. Particularly given the low cost of a download. We might want to digitize the STAR/SIDs for the default airport with each release so there are some approaches available for those who don't want to purchase the data.[15]
everyone agrees we would like to add airspace data - what we’re missing is a suitable data source with the correct license. Torsten found a raster-based source but for wider use in the sim we really need vector data, so we can render it ourselves directly. [16]
For airspace data we could use https://openflightmaps.org/ . It provides community created navigation data for many countries in (currently only) Europe with a free license.[17]
we definitely want vector data. Stuart is hoping that we might convince the source of the raster data we're using at present to provide it as raw vector data, but we haven't had any luck so far.[18]
Airport Data (US - only )
At least for the US, all required information is available in the form of regularly updated UDFF files:
- https://www.ngs.noaa.gov/AERO/aero.html
- https://www.ngs.noaa.gov/AERO/uddf/WESTERN-PACIFIC/CALIFORNIA/SFO__03B.F77
- https://www.ngs.noaa.gov/AERO/annof_7.pdf
It would seem relatively straightforward to provide a scripted parser to create the corresponding charts procedurally. As a matter of fact, this could even be done in a background thread or using a separate Python script, i.e. if we wanted to ship pre-created imagery as part of fgdata.
However, if the built-in Canvas system is extended to provide these charts, Phi could also be entirely self-contained by rendering the same airport charts without having to depend on external data sources.
Layers
Following is the list of layers displayed by the G1000 system (see page 153 of the 190-00498-07 Rev. A), and mapping to the equivalent MapStructure Layer. Many of these would also be good to have for other avionics/GUI dialogs, including the NavDisplay framework, which is currently re-implementing this functionality separately, i.e. not yet using MapStructure.
Following is the list of layers displayed by the G1000 system, based on the Garmin G1000 Integrated Flight Deck Pilot's Guide for the Cessna Nav III Garmin Site Wayback machine, page 153, and the mapping to the equivalent MapStructure Layer.
Richard mentioned that if he were to implement approach plates in the EFB he'd probably use raster images provided via http and provide an http service within FG to do this, or to allow the EFB to use any other external web service. Other content for the EFB could be also provided as SVG via http.[19]
Layer | MapStructure Layer | Status | Page | Notes |
---|---|---|---|---|
Flight Plan Route Lines | RTE | Requires styling | p.190 | |
Flight Plan Route Waypoints | WPT | Requires styling | p.190 | |
Rivers/Lakes | VFRChart | p.148 | Currently using downloaded raster from web. Perhaps generate similarly to Atlas[20], or could be vector data from scenery. Tom originally suggested to directly render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using a custom Canvas View Camera Element, based on the Hackathon Proposal: CompositeViewer and Canvas experiments (see the ideas summarized at Canvas Tile Element). Fernando agreed already that it would be straightforward to apply custom node masks, LOD ranges and even effect schemes per Compositor instance. | |
Topography Data | VFRChart | Synthetic | p.145 | Height-map at chart-resolution. Perhaps generate similarly to Atlas? Tom originally suggested to directly render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using a custom Canvas View Camera Element, based on the Hackathon Proposal: CompositeViewer and Canvas experiments (see the ideas summarized at Canvas Tile Element). Fernando agreed already that it would be straightforward to apply custom node masks, LOD ranges and even effect schemes per Compositor instance. |
International Borders | p.148 | Vector data from scenery? | ||
Track Vector | p.156 | Forward looking display of track. Look-ahead time selectable. | ||
Navigation Range Ring | p.159 | Straightforward extension of APS. | ||
Fuel Range Ring | 159 | Straightforward extension of APS. | ||
Terrain Data | 364 | Should be straightforward, with exception of obstacles. Profile view also required. | ||
Traffic | TFC | 394,423 | Various options, each with different iconography and data displayed. | |
Airways | VFRChart | 154 | Needs to be replaced with vector data | |
NEXRAD | 282 | Heaps of weather data with complex symbology. | ||
XM Lightning Data | WXR | Change to symbol for lightning? | 294 | Optional |
Airports | APT, RWY | Require re-style based on size | 149, 163 | |
Runway Labels | RWY | 148 | Needs to be added to RWY. Should be straightforward | |
Restricted | OpenAIP | 182 | Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[21]
Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[22] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [23] | |
MOA (Military) | OpenAIP | 182 | Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[24]
Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[25] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [26] | |
User Waypoints | ||||
Latitude/Longitude Grid | GRID | |||
NAVAIDs | APT, VOR, FIX, NDB | APT, requires styling | 162 | |
Class B Airspaces/TMA | OpenAIP | 182 | Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[27]
Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[28] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [29] | |
Class C Airspaces/TCA | OpenAIP | 182 | Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[30]
Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[31] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [32] | |
Class D Airspaces | OpenAIP | 182 | Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[33]
Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[34] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [35] | |
Other Airspaces/ADIZ | OpenAIP | 182 | Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[36]
Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[37] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [38] | |
TFRs | 310 | |||
Obstacles | OpenAIP | 182 | Currently using downloaded rasters. Would be better replaced with vector data, see original plans at Canvas_Maps#Vector_data. We do already have a SHP parser, that’s how the launcher loads the SHP data used in the launcher map: but loading for display is much easier than a robust ‘is point inside an arbitrary complex polygon’ tester.[39]
Using GDAL/CGAL for other features has been repeatedly discussed on the devel list, i.e. for WS 3.0 to create the meta-texture at runtime from the vector data - i.e use CGAL + GDAL to ‘paint’ the vector data into textures as they are needed. This means the resolution of the meta-texture tiles can be adaptive, which gives a trivia solution to handling roads and similar - draw them into the meta texture (or an additional one) adaptively based on distance from viewer, etc.[40] CGAL/GDAL are not so problematic to consider shipping. (They are well maintained, well supported on Windows, and have sane build systems). We would want some warning and time to handle it, but should definitely not consider this particular point to be a blocker for more advanced runtime features. [41] | |
Land/Country Text | 148 | Currently using raster data from web. Replace with POI? | ||
Cities | VFRChart | 148 | Currently using raster data from web. Perhaps generate similarly to Atlas, or could be vector data from scenery. Tom originally suggested to directly render an orthographic view of the scenery/terrain to the canvas, thus the atlas-based approach should also work using a custom Canvas View Camera Element, based on the Hackathon Proposal: CompositeViewer and Canvas experiments (see the ideas summarized at Canvas Tile Element). Fernando agreed already that it would be straightforward to apply custom node masks, LOD ranges and even effect schemes per Compositor instance. | |
Roads | VFRChart | 148 | Currently using raster data from web. Requires vector data from scenery | |
Railroads | VFRChart | 148 | Currently using raster data from web. Requires vector data from scenery | |
State/Province Boundaries | VFRChart | 148 | Currently using raster data from web. Requires vector data from scenery | |
River/Lake Names | VFRChart | 148 | Currently using raster data from web. Replace with POI? | |
Selected Altitude Intercept Arc | 161 | Simple extention to APS | ||
SafeTaxi (Optional) | RWY, TAXI | 493 | We don't currently have the data to display taxiway identifier or holding points | |
ChartView (Optional) | 503 | Rendering of PDFs. Might be possible to integrate with NaviGraph chart data? | ||
FliteChart (Optional) | 521 | Rendering of PDFs. Might be possible to integrate with NaviGraph chart data? |
Existing work
Avionics / Cockpits
Nasal / Canvas
- Canvas MFD Framework
- MapStructure
- MapStructure Layers
- Howto:Creating a Canvas GUI Widget
- Emesary
C++
- Atlas map creation
- Synthetic Vision element for rendering viewmgr views to a Canvas
- Canvas PDF element - for rendering PDF files (think EFB functionality)
Possible Work
The layers table shown above mentions a few limitations and ideas, such as:
Nasal/Canvas
- <image> tag support for svg.nas (patch: [2])
- MapStructure: Allocating selectable ranges into Canvas groups
C++
- fix up projection issues, and adopt Gijs' projection handling code for the hard-coded PUI Map, to get rid of the standard Sanson-Flamsteed projection
- adding a profile view, probably in conjunction with terrain sampling
- using atlas code to generate heightmaps/topography
- adding ESRI shapefile support to the Canvas system
- adding PDF rendering support the Canvas system
Design
The broad structure of the Nasal files in Aircaft/Instruments-3d/FG1000/Nasal is as follows:
- MFD.nas - top level MFD device, loads the other Nasal files (likely to be moved elsewhere later) and pages.
- PageGroupControllers.nas - controller for the Page Group display in the bottom right of the MFD, controlled by the FMS knob, and which allows selection between different page groups and individual pages.
- [PageName]/[PageName].nas - MFD page, inheriting from the MFDPage.nas. Creates any required MapStructure and hierarchy of softkeys.
- [PageName]/[PageName]Controller.nas - Controller for the MFD page and the MapStructure layers, inheriting from MFDPageController.nas
- [PageName]/[PageName]Style.nas - Style controls for the MapStructure layers for the given Page.
- [PageName]/[PageName]Options.nas - Options for the MapStructure layers for the given Page.
Key design notes:
- Most of the underlying Canvas MapStructure layers are now written (though they require styling, and/or would benefit from replacement with vector data).
- Emesary IPC framwork is used to link between the MFD and underlying simulation state. This should make it easy to run the MFD on a separate FG instance, and provides a good demarkation between the individual aircraft systems and the FG1000 itself.
- Various underlying UI classes are used to handle highlighting, selection and scrolling of fields. See Canvas MFD Framework for details of the elements now supported.
Resources
Related
Commits
This section is intended to help keep track of related fgdata commits, so that if/when the project should stall, people can more easily look up related changes.
- Initial Direct To page(01/2018)
- Add Config Store and MFD Header display.(01/2018)
- SVG MFD UI from miChat(01/2018)
- Use Emesary interface rather than airportinfo()(01/2018)
- Set standby COM frequency from Airport pages(01/2018)
- NAV/COM Radio support(01/2018)
- Add full set of hardkeys to fg1000 PUI dialog.(01/2018)
- extend MFDPageController to handle Emesary register(01/2018)
- Update NAV/COMM frequencies from properties(01/2018)
- Modify FG1000 EIS to use Emesary(01/2018)
- FG1000 Nearest Airports page(01/2018)
- PFD UI Elements and NearestAirports page (12/2017)
- Add AirportInfo and template pages for FG1000 (12/2017)
- Initial commit of FG1000 MFD (11/2017)
MapStructure related:
- GRID layer (10/2017)
- RWY, TAXI, TWR, PARKING (10/2017)
- STAMEN (10/2017)
- VFRChart (09/2017)
- OSM and OpenAIP (09/2017)