Board index FlightGear Development Aircraft Autopilot and route manager

Waypoints shown on ND

Designing a stable autopilot is one of the hardest things. Need help?

Waypoints shown on ND

Postby Gijs » Fri May 23, 2008 4:37 pm


I wondered if there's a plane in FlightGear that shows the waypoints/fixes on the ND? A real ND have a line that connects the waypoint so the pilot knows how to fly. Is this already in FG to, or do I need to make it myself for the 747 (which will not be a great succes I think ;) ). I know the 787 got a pretty good ND, but it does not include the line. Below is an example of what i'm looking for.

Thank you,

Airports: EHAM, EHLE, KSFO
Aircraft: 747-400
User avatar
Posts: 9376
Joined: Tue Jul 03, 2007 2:55 pm
Location: Delft, the Netherlands
Callsign: PH-GYS
Version: Git
OS: Windows 10

Re: Waypoints shown on ND

Postby Hooray » Fri May 23, 2008 6:18 pm


To my knowledge, FlightGear so far doesn't provide any support for real-life based glass cockpit-type avionics, this includes both: flight management systems, and the ND or more generally: the EFIS.

So, even most modern aircraft in FlightGear that are normally "glass" in RL, are usually equipped with "steam-based" instrumentations or very simplistic glass versions (i.e. there's a very basic EHSI for the 787).

IIRC, This also seems to be backed up by a page on the wiki which specifically talks about adding such features to FG.

In fact, even the library of steam-based instruments doesn't appear entirely complete yet, i.e. there doesn't appear to be an RDMI? ( Given that this instrument is simply an integrated version of two different instruments (DME readout & RMI), it would be pretty simple to implement, though.

Similarly, RNAV equipment appears also to be hardly modeled right now.

Maybe, we need a list of existing instruments and those still missing, possibly in some sort of "Instruments" or "Avionics" sub forum?

Anyway, simply creating such glass avionics isn't very straight forward, because you first need to provide the corresponding low level infrastructure.

About two years ago, I did something like this for a FlightGear related project - back then, this was simply a special hardcoded instrument type that could show various dynamic layers (textures) on top of eachother, these layers were mainly:
  • airports
  • VORs
  • NDBs
To create the corresponding maps using a proper scale, you need to take several things into account:

- range configured for your virtual ND (i.e. 20 nm)
- the position of your aircraft (GPS coordinates, at the middle of your 2D screen)
- each GPS position for each navaid or fix

Then you have to convert these 3D positions to 2D screen/texture coordinates, taking into account that your aircraft is usually depicted in the middle of the screen, i.e. at the center of a 20nm radius circle. IIRC, there's already code in FG or SG to do this for you, though (I think the hardcoded GPS has some sort of 3D->2D conversion stuff in it, too).

Back then, I settled for this approach because Navigational Displays usually provide a way to only show/hide certain types of symbols on the display, so that it isn't too cluttered. So, each individual layer could be disabled/enabled by setting a corresponding property, so that only certain layers would be shown.

However, this was still a pretty crude implementation that not only lacked proper textual labels for all symbols, but also caused several OpenGL issues, that resulted in the cockpit not being rendered properly anymore, in addition I didn't know how to add a spatial search to update the symbol map, so that I ended up using a linear search that would go through all of the DB at 2 hz, to update the textures accordingly - this was another very crude hack.

The screen artefacts, I attribute mainly to my lack of familiarity with OpenGL back then, though.
So, at some point I simply forgot about this and didn't play with it anymore until the code got lost during a harddisk upgrade.

However, based on what I read on the wiki some time ago, we are no longer supposed to make any "raw OpenGL calls" in our code, so while this policy may address such issues, it would be outside of my expertise to provide such functionality without using GL calls.

Also, while what I did 2 yrs ago was very simple (similar to the very first XPlane FMC), it didn't provide support for the magenta line you are asking for; this would need to be drawn dynamically (probably, base on the active FMC route) using some sort of line from point to point algorithm.

To summarize: it is certainly possible to implement this, and I am sure we could come up with something in a couple of weeks, however you need to work with different parts of FG to get this to work properly, and I am afraid I couldn't provide something that we acceptable for inclusion in CVS.
Please don't send support requests by PM, instead post your questions on the forum so that all users can contribute and benefit
Thanks & all the best,
Help write next month's newsletter !
pui2canvas | MapStructure | Canvas Development | Programming resources
Posts: 12190
Joined: Tue Mar 25, 2008 8:40 am

Return to Autopilot and route manager

Who is online

Users browsing this forum: No registered users and 0 guests