List of file formats

These file formats are some of the more obscure ones ones used in FlightGear. While some of them are unique to FlightGear, some of them are not.

*.ac files

See AC3D file format for the main article about this subject.

This is the native format for 3D graphics of the Invis AC3D application (payware with free trial version). These files contains meshes, UV-mappings, texture paths and material definitions. The format is preferred by FlightGear (in essence the best supported format). It's ASCII text and easy to edit via scripts or, to some extent, by hand. Many applications are able to import and/or export this format:

Blender

See Blender for the main article about this subject.

Blender is a powerful and free (as in beer) open source 3D model editor (among other things). Blender had built in support for importing and exporting AC3D files up to Blender 2.49b, and after that there are scripts available to do that of which some are developed by members of the FlightGear community.

In Blender 2.49b import and export would be done from the file menu as File > Import/Export > AC3d (*.ac).

Open Scenegraph Library

The osgviewer demo in the Open Scenegraph Library is very useful for quickly looking at models.

PrettyPoly

PrettyPoly (ppe) is an unmaintained object editor that uses the same graphics library as FlightGear (plib). This has the advantage that objects look very much like in FlightGear (minus shader effects and shadows). Compiling ppe may be a challenge, though, and it's only useful for viewing, but hardly for editing objects.

threedconvert

This is a converter for all plib supported 3D formats and comes with FlightGear (see utils/Modeller/3dconvert.cxx). It can read and write *.ac files, but a written file may lack UV mapping or have other defects.

*.rgb files

These files are texture files in SGI Image Format. This format supports multiple layers, transparency, compression, indexed colors, 8 bits and 16 bits per plane. Files of this format use different extensions, often to indicate the image properties, but in fact it's always the same format. The "official" extensions is *.sgi. Images with one layer are usually black/white (*.bw) or a mere alpha layer (*.a), with two layers black/white with alpha, with three layers red/green/blue (*.rgb), and with four layers red/green/blue/alpha (*.rgba). This, however, is only a convention and not mandated by the SGI image specification. SGI images can be uncompressed or RLE-compressed, which is a lossless compression method.

FlightGear uses plib to read SGI images. They must not use 16 bits per plane and must have side lengths of 2ⁿx2^m (powers of 2), the size must be at least 4 pixels when using compressed textures (automatic feature in the osg branch). For example: 64x64, 256x256 or 128x2048 (but textures have square size inside the graphic card so a 16x1024 texture is really a 1024x1024 texture). Note that other sizes will not work, and FlightGear will use a red/white chequered texture instead! FlightGear textures shall be RLE-compressed, and as 'aggressively' as possible.

All better graphics applications should be able to read and write the format, but often they load SGI images without problems, but only write them properly when the *.sgi extension is used. Here are some free applications that create SGI images, along with some usage notes:

GIMP

Using GIMP either save the image with extension *.sgi and rename it afterwards, or choose in the file dialog "Select Filetype" -> "Silicon Graphics IRIS image". Save with "Aggressive RLE". (The remark about SGI not supporting that is wrong. This is compliant with the file specification from SGI itself.)

krita/kolourpaint

KDE's krita/kolourpaint supports reading and writing of SGI images on the base library level, so all applications that can read/write images in general can also read/write SGI images. They are automatically saved in highest possible compression (more aggressive than GIMP :-)

convert

When using ImageMagick's/GraphicsMagick's convert, like with GIMP, it's necessary to either call the target file *.sgi or to specify the file type explicitly via sgi: prefix:

$ convert foo.png foo.sgi      # RIGHT
$ convert foo.png sgi:foo.rgb  # RIGHT
$ convert foo.png foo.rgb      # WRONG! This doesn't create an SGI image!

This creates SGI images with RLE compression by default.

Here is a bash script that you can run in the ./FlightGear/Aircraft directory to generate SGI image files for all of the PNG format files you have:

#!/bin/sh
for PNG in $(find -name '*.png')
  do
  SUBDIR=$(dirname $PNG)
  FILEBASE=$(echo $PNG |awk -F / '{s=$(NF); n=split(s, sa, "."); delete sa[n];  for(sk in sa) {printf("%s.",sa[sk])}}')
  RGB="$SUBDIR/${FILEBASE}rgb"
  if [ ! -f $RGB ]
      then
      convert $PNG sgi:$RGB
  fi
done

*.stg files

Update 09/2016: Stuart committed the code to enable two new STG verbs:

• OBJECT_BUILDING_MESH_ROUGH
• OBJECT_BUILDING_MESH_DETAILED

To enable the reading of these verbs you will need to set /sim/rendering/building-mesh=true and obviously reload scenery.

This entry is copied from $FG_ROOT/Docs/README.scenery, which is part of FlightGear >0.9.10.

stg files ("static terragear") define the static elements of a scenery "tile", including the terrain elevation data, airport geometry, and all static objects placed on this tile. Four of the available key words are followed by a string and four numbers. The meaning of these numbers is always the same and described under OBJECT_SHARED.

OBJECT_BASE lines

Specifies the terrain elevation data file. These files are generated by the TerraGear using the BTG file format, and have file extension ".btg" ("binary terragear"; there used to be an "*.atg" file, too, where the 'a' stood for ASCII).

Example:

OBJECT_BASE 942050.btg

The entry may be anywhere in the 942050.stg file, on a separate line.

OBJECT lines

Specifies airport geometry 'drop-in' files. The scenery elevation file has cut out holes for airports, that are filled with such objects. They are usually called after the airport ICAO id:

Example:

OBJECT KSFO.btg

These files are, again, created by TerraGear tools and are usually gzipped, so you'll find that file stored as KSFO.btg.gz.

OBJECT_SHARED lines

Adds shared objects to the tile.

Example:

 OBJECT_SHARED Models/Airport/tower.xml -122.501090 37.514830 15.5 0.00

Syntax:

 OBJECT_SHARED <object-path> <longitude> <latitude> <elevation-m> <heading-deg> <pitch-deg> <roll-deg>

• <object-path> is relative to the data directory (FG_ROOT).
• <longitude> and <latitude> are in degrees using WGS-84 standard coordinate systems, available from most online-maps.
• <elevation-m> is in meter and relative to mean sea-level (in the fgfs world).
• <heading-deg> is in degree, counter-clockwise with North being 0.0.
• <pitch-deg> and <roll-deg> are in degree and optional.

Note that this differs from about every other place in FlightGear, most notably the /orientation/heading-deg entry in the property system, which is normally increasing in the clockwise direction. OBJECT_SHARED models are cached and reused. They are only once in memory and never freed. (See also the next section.)

OBJECT_STATIC lines

Adds static objects to the tile, just like OBJECT_SHARED. There are three differences to OBJECT_SHARED (apart from the name):

• the path is relative to the tile directory where the *.stg file with this entry is located. For example, relative to 130n30/w123n37/. This usually means that all 3D object files, textures, and XML animation files are in this tile directory, too.

• these objects are *not* cached and kept loaded, but rather freed with the tile (that is, when you leave that area).

• the animation XML files may contain Nasal blocks <nasal><load> and <nasal><unload> which are executed on loading/unloading.

Example:

 OBJECT_STATIC ggb-fb.xml -122.4760494 37.81876042 0 105

OBJECT_SIGN lines

See Signs for the main article about this subject.

Defines taxiway or runway signs. The syntax is like that of OBJECT_SHARED entries, except that the path is replaced with a sign contents specification. This specification will probably be changed. Look at $FG_ROOT/Docs/README.scenery if you need to use this entry.

apt.dat file

See X-Plane data file definitions - Airport data (apt.dat) 850 version, currently used by FlightGear's official scenery which was also used by X-Plane (version 8.10 to 8.60). Currently X-Plane uses the newer apt.dat 1000 (or 10) format, which includes new codes to define the airport taxiway/runway network for AI/ATC. The current TerraGear parser ignores any code it doesn't understand, including these new ones. So it's possible to read and parse the latest v10.0 datafile just fine, but not all of its features are supported.

Surface Type Codes

• 1 Asphalt
• 2 Concrete
• 3 Turf or grass
• 4 Dirt (brown)
• 5 Gravel (grey)
• 12 Dry lakebed (for example at Edwards Air Force Base, KEDW)
• 13 Water runways
• 14 Snow or ice
• 15 Transparent

...maps to Materials/default/global.xml  ??

Size codes for groundnets and ramp/gate parking

ramp start metadata. lines start with: 1301. see: XP-APT1050-Spec.pdf

Group	Wingspan (ft)	Example Aircraft
A	< 49	Cessna 172, Beechcraft A36
B	49 - 78	Saab 2000, EMB-120, Saab 340, Canadair RJ-100
C	79 - 117	Boeing 737, MD-80, Airbus A320
D	118 - 170	Boeing 757, Boeing 767, Airbus A300
E	171 - 213	Boeing 747, Boeing 777, MD-11, Airbus A340
F	214 - 262	Airbus A380

External links

• http://www.skybrary.aero/index.php/ICAO_Aerodrome_Reference_Code
• http://developer.x-plane.com/wp-content/uploads/2015/11/XP-APT850-Spec.pdf
• http://developer.x-plane.com/wp-content/uploads/2017/02/XP-APT1050-Spec.pdf
• https://developer.x-plane.com/article/airport-data-apt-dat-file-format-specification/

Related contents

• Flightplan XML formats