View source for User:Ranguli/List of file formats

The following is a list of file formats used by FlightGear.

{| class="wikitable"
|-
! File format !! Extension !! Remarks
|-
|  [[The_AC3D_file_format|AC3D file format]] || <code>.ac</code> || Used by the [[AC3D]] modelling software for storing 3D models.
|-
| Example || Example || Example
|-
| Example || Example || Example
|}

== *.rgb files ==
These files are texture files in [http://en.wikipedia.org/wiki/Silicon_Graphics 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 <tt>*.sgi</tt>. Images with one layer are usually black/white (<tt>*.bw</tt>) or a mere alpha layer (<tt>*.a</tt>), with two layers black/white with alpha, with three layers red/green/blue (<tt>*.rgb</tt>), and with four layers red/green/blue/alpha (<tt>*.rgba</tt>). This, however, is only a convention and not mandated by the SGI image specification. SGI images can be uncompressed or [http://en.wikipedia.org/wiki/Run-length_encoding RLE-compressed], which is a lossless compression method.

FlightGear uses [http://plib.sourceforge.net/ plib] to read SGI images. They must not use 16 bits per plane and must have side lengths of 2<sup>n</sup>x2<sup>m</sup> (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 <tt>*.sgi</tt> extension is used. Here are some free applications that create SGI images, along with some usage notes:

=== GIMP ===
Using [http://www.gimp.org/ GIMP] either save the image with extension <tt>*.sgi</tt> 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 ===
[http://www.kde.org/ 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 [http://www.imagemagick.org/ ImageMagick's]/[http://www.graphicsmagick.org/ GraphicsMagick's] convert, like with [[GIMP]], it's necessary to either call the target file <tt>*.sgi</tt> or to specify the file type explicitly via <tt>sgi:</tt> prefix:

<syntaxhighlight lang="sh">
$ 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!
</syntaxhighlight>

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:

<syntaxhighlight lang="sh">
#!/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
</syntaxhighlight>

== *.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.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/35385866/ 
  |title  =  <nowiki> Re: [Flightgear-devel] osm2city integration (was Re: Maldives, once
 again ; ) </nowiki> 
  |author =  <nowiki> Stuart Buchanan </nowiki> 
  |date   =  Sep 22nd, 2016 
  |added  =  Sep 22nd, 2016 
  |script_version = 0.40 
  }}</ref>


<div id="STG"></div>
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 [http://www.terragear.org/ TerraGear] using the [[BTG File Format|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 ===
{{main article|Signs}}
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 [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 (or 10) 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> 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.<ref>{{forum link|title=Move to 850 format for airports||p=208286}}</ref>

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


{| class="wikitable"
! Group !! Wingspan (ft) !! Example Aircraft
|-
| A || < 49 || [[Cessna 172]], Beechcraft A36
|-
| B || 49 - 78 || Saab 2000, [[Embraer EMB-120 Brasilia|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]]
|}

http://www.skybrary.aero/index.php/ICAO_Aerodrome_Reference_Code

http://developer.x-plane.com/wp-content/uploads/2017/02/XP-APT1050-Spec.pdf

== Footnotes ==
<references/>

== Related contents ==
* [[Flightplan XML formats]]

[[Category:Lists]]
[[Category:Software]]