• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

Contributing to FlightGear

I'm writing something geared toward existing flight sim scenery developers in order to see if anyone is interested in creating for FlightGear. This is the first step, please let me know what you think should be improved as I'm eventually planning on adding this to the FlightGear wiki.


Every day, FlightGear becomes a more sophisticated simulation as a result of the users who spend their time making it better. In the recent version, upgrades including graphics, aircraft and weather which interacts with the scenery have made FlightGear a simulation worthy of a second or third glance from people who use commercial simulators.

Unfortunately, scenery is perhaps FlightGear's weakest point. At the same time, it is the area of FlightGear in which a developer can quickly make a large impact in improving the simulation, especially when it comes to creating objects.

First of all, FlightGear needs Objects. There are only 2258 unique objects in the FlightGear Object repository as of September 2011, many of them generic. Even one well-detailed object can make a great landmark even when the underlying terrain needs significant improvement.

For instance, this was New York City in FlightGear, with only three non-generic buildings:

This is New York City after a call for landmarks in June 2011:

This 'after' screenshot demonstrates both the amount of work which is needed to be done even on a well-known place like New York to get the scenery up to par with even older simulators, and how a contribution of one single building can make a difference in terms of the setting.

Considering there is not really a "core development team" for FlightGear scenery, any models are more than welcome.

Second of all, FlightGear needs Terrain. Terrain is created using shapefiles, which is the "Microsoft Word Document" of spatial data. Most of the FlightGear world is covered in accurate, but not precise, free spatial data.

The elevation data is contributed using SRTM data, the inaccuracy of which is the cause for the giant hill in the middle of Manhattan.

However, there are areas such as TNCM: http://mapserver.flightgear.org/map/?lon=-63.109573&lat=18.04086&zoom=12&layers=B000000TFFFFTTTFTFFF and KSEA: http://mapserver.flightgear.org/map...855264147&zoom=12&layers=B000000TFFFFTTTFTFFF which have higher-resolution terrain data in the server.

Finally, FlightGear needs Airports (and airport objects, such as Taxiway signs). Development is under way to bring FlightGear into compliance with X-Plane 8.50 airport data. FlightGear currently uses a forked version of the X-Plane 8.10 database, since it is released under the GPL.

While most airports are up-to-date, not all airports are - and even "good" airports may need AI ground networks.

==How Scenery is Handled==
Considering FlightGear is an open-source project, all scenery data is handled centrally, through either the Scenery Object repository, which stores object data, or the FlightGear mapserver, which stores terrain data.

This means to add an object, you would send your .ac (and possibly .xml) file into the maintainers of the database. Once the object is in the database, people who download scenery 'on-the-fly' will be able to see your object within 24 hours of its upload time.

Adding terrain is unfortunately more difficult and requires a "clipping polygon" so the terrain can be seamlessly merged into the existing spatial data on the server. Furthermore, the most recent worldwide terrain update was late 2008 (v1.0.1) and many different areas have seen improvements since then.

Fortunately, once the terrain is added to the server it is easy to download a chunk of the world and compile it yourself using TerraGear.

Due to the fork, airports are currently being handled by the scenery object database maintainers. Taxiway signs are considered objects.

All scenery which is added to the database must be GPL-licensed and be created with copyright in mind - this means a license similar to OpenStreetMap's data contribution (cannot use Google Maps or Google Earth imagery to help you model or place your object, for instance - but Yahoo! Maps is okay). This rule is unfortunate, but screening data for potential copyright violations before it is added to the scenery repository is easier than going back and removing it, especially once it is distributed.

Releasing your scenery under the GPL is easy, and as long as you hold the copyright you can release your objects or terrain under a different license as well. This means you can release your work as payware or freeware - limited distribution for a commercial flight simulation while still being able to upload the same work to FlightGear's database.

You can also create scenery for FlightGear as an add-on WITHOUT contributing any data to the database. FlightGear supports different scenery directories. However, because of the directory structure, this is generally not recommended, especially because it does not directly help the base project.

Conflicts between objects and terrain being modeled more than once are rare, but have occurred - generally the "better" model will be accepted to the database.


Resource contributor
I'd love to contribute, BUT I'd start more on the bottom of things - namely the terrain engine itself.

Need to get into the FG source code first though.
FlightGear uses git to update the source code - shouldn't be hard, just search for 'FlightGear repository'.

The terrain files are all .btg (hope I got that extension right) meshes. The engine is actually capable of doing some amazing things: http://flightgear.org/forums/viewtopic.php?f=19&t=11612 (scroll down for the best screenshots).

Obviously features such as terrain blending aren't good yet but there's been some work on that front.

The underlying New York City terrain is generically awful. That is in the process of being fixed.


Staff member
FSDevConf team
Resource contributor

Interesting. You mention using OpenStreetMap data, has that been done in the standard scenery already? I think that would be an relatively easy way to make the standard scenery look better. I know found it hard to recognise parts of the Netherlands. I am tempted to try to insert some OSM data in the future.
There have been some European sceneries generated with OSM data. We're not importing the OSM data over the vmap0 terrain data we use already, though, because even though vmap0 data is not very precise, it's consistent over the whole world.

There's a very good scenery of the Netherlands using Corine data with OSM roads and rivers out, for instance.

For instance, OSM data may not be very good in, say, Ecuador - and the vmap0 data won't be either - but at least the vmap0 data has been "vetted" for "accuracy".

Plus you have to figure out which OSM roads and rivers to take and which to "throw away" as depending on the data set it can be too detailed in some places which could be a problem with the terrain engine.

There are also distribution issues with the OSM license - not sure about their new license but I'm sure it's better with their old one.
A little update on the NYC scenery, I'm currently working on the terrain. All work in progress as of now, but you can already see OSM data (motorway, primary, secondary and railroad) and more detailed landclassing.

We still need a lot of custom buildings (the images below do not contain generic buildings, like Statto's images in the opening post) and some better textures. And the landclassing itself isn't done either, so expect to see more parks/lakes over the next week(s).