Difference between revisions of "List of file formats"

From FlightGear wiki
Jump to navigation Jump to search
m (Robot: Changing Category:List to Category:Lists)
(→‎apt.dat file: updated - we use now 850, and XP uses 1000)
Line 111: Line 111:
  
 
== apt.dat file ==
 
== apt.dat file ==
See [http://data.x-plane.com/file_specs/Apt810.htm X-Plane data file definitions - Airport data (apt.dat) 810 version]
+
See [http://data.x-plane.com/file_specs/XP%20APT850%20Spec.pdf 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 format.<ref>[http://data.x-plane.com/file_specs/XP%20APT1000%20Spec.pdf ''X-Plane Airport Data (Apt.Dat) File Specification - 1000 Version, revised Apr 2013''] (PDF).</ref>
FlightGear's official scenery uses currently uses the slightly outdated apt.dat 810 file format,<ref>Robin Peel, [http://data.x-plane.com/file_specs/Apt810.htm ''X-Plane data file definitions - Airport data (apt.dat) 810 version''], 2007.  Last updated March 8, 2007.</ref> which was also used by X-Plane (version 8.10 to 8.60).  Currently X-Plane uses the newer apt.dat 850 format.<ref>[http://data.x-plane.com/file_specs/XP%20APT850%20Spec.pdf ''X-Plane Airport Data (Apt.Dat) File Specification - 850 Version, 1-Feb-11''] (PDF).</ref> You are encouraged to use the newer 850 format when updating an airport, as there is ongoing work to support the 850 format in FlightGear. See [[Airport data (apt.dat) update]] for more information.
+
 
 +
See [[Airport data (apt.dat) update]] for more information on the upgrade from 810 to 850.
  
 
== Footnotes ==
 
== Footnotes ==

Revision as of 19:32, 2 May 2014

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

This is the native format for 3D graphics[1] 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

1rightarrow.png 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 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

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

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>

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 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

1rightarrow.png 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 format.[2]

See Airport data (apt.dat) update for more information on the upgrade from 810 to 850.

Footnotes