User:Ranguli/List of file formats
The following is a list of file formats used by FlightGear.
File format | Extension | Remarks |
---|---|---|
AC3D file format | .ac |
Used by the AC3D modelling software for storing 3D models. |
Example | Example | Example |
Example | Example | Example |
*.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
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.[1]
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,[2] 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.[3]
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 |
http://www.skybrary.aero/index.php/ICAO_Aerodrome_Reference_Code
http://developer.x-plane.com/wp-content/uploads/2017/02/XP-APT1050-Spec.pdf