List of file formats

From FlightGear wiki
Revision as of 13:16, 11 August 2012 by Papillon81 (talk | contribs) (remove runway signs)
Jump to navigation Jump to search

*.ac

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

Blender

See File->Import/Export->AC3d (*.ac). Blender is a free and very powerful (some say: too powerful) 3D editor.

Open Scenegraph Library

The osgviewer demo is very useful for quickly looking at models.

ppe

This 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

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 2nx2m (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

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)

KDE 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 (ImageMagick/GraphicsMagick)

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

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

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

specifies an airport geometry 'drop-in' file. 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

add static object 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>

The <object-path> is relative to the data directory (FG_ROOT). <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 clockwise. OBJECT_SHARED models are cached and reused. They are only once in memory and never freed. (See also the next section.)

OBJECT_STATIC

add 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

1rightarrow.png See Signs for the main article about this subject.

defines taxiway or runway sign. 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

See X-Plane data file definitions - Airport data (apt.dat) 810 version