FlightGear wiki - User contributions [en]

Howto:Create WS3.0 terrain

2026-04-16T15:51:20Z

Fahim Dalvi: Update running instructions to match latest release

{{WS30 Navbar}}
This article provides instructions on how to generate basic WS3.0 terrain.

WS3.0 terrain consists of three parts:

# A terrain mesh consisting of a landclass texture draped over an elevation model.
# A high resolution water raster used to show water features such as rivers, lakes and coastline with more definition
# Line features such as roads and railways.

The terrain is generated by a set of tools that are packaged in a docker image for convenience.[[File:Diagram-export-21-12-2023-16 29 37.png|thumb|Basic WS3.0 Scenery Generation Process]]

== Prerequisites ==

=== Set up a Workspace ===
Create a directory with the following sub-directories:

* <code>cache</code>
* <code>data</code>
* <code>output/vpb</code>
* <code>output/Terrain</code>

=== Docker ===

# Install [https://docs.docker.com/get-started/ Docker] on your platform.
#Pull the docker image by running the following command

docker pull flightgear/ws30-vpb-generator:latest
Optionally, if you are hitting rate limits:
#Create an account on https://hub.docker.com/. (Note that you will need to click on an email verification link before you can log in for the first time)
#Run <code>docker login</code> before the '''docker pull''' command above

== Getting the base data ==
You need two pieces of data for the area of scenery you are generating:

# An elevation model (aka DEM). This indicates what altitude each point of the surface is.
# Landclass data showing what type of terrain is at each point of the surface. This is often either a Raster (effectively a texture), or vector data.

=== Elevation Model ===
Download the NASADEM elevation model for the area of scenery you wish to generate. This is available in 1x1 degree blocks from [https://lpdaac.usgs.gov/products/nasadem_hgtv001/ here], and with an interactive browser [https://search.earthdata.nasa.gov/search here].

Unzip the files into the <code>data</code> directory.

=== Landclass Raster ===
Download an landclass raster for the area of scenery you wish to generate.

* For Europe, use of [https://land.copernicus.eu/pan-european/corine-land-cover/clc2018 CORINE] is recommended.
* For the USA [https://www.mrlc.gov/viewer/ NLCD] is recommended
* Sentinel-2 data is available for the entire world via [https://livingatlas.arcgis.com/landcoverexplorer/ ESRI], but has limited set of landclasses.

Put these into the <code>data</code> directory.

More detailed terrain can be created by modifying the landclass raster, and/or generating a new raster from vector data. These processes are discussed below.

== Generating Terrain ==
To generate terrain you need to run the tools within the docker container we installed above. The docker image is like a small, independent virtual computing environment running within your system. This particular docker image has all the scenery generation tools already installed.

=== Running the docker container ===
Firstly, get the container running from the directory containing your <code>cache</code>, <code>data</code> and <code>output</code> directories:
docker run --rm --mount "type=bind,source=`pwd`/data,target=/home/flightgear/data,readonly" --mount "type=bind,source=`pwd`/output,target=/home/flightgear/output" --mount "type=bind,source=`pwd`/cache,target=/home/flightgear/cache" -it flightgear/ws30-vpb-generator:latest /bin/bash

You should now find yourself in a bash shell within your container. You should see data and output directories which are linked to the directories you created earlier:
flightgear@ddcac77f7d5e:~$ ls
cache data output bin scripts

=== Building the terrain ===
To build the terrain mesh, use the <code>genVPB.py</code> tool from inside the docker container:

Usage: genVPB.py --raster <input-raster> [ option ... ]
Usage: genVPB.py --bbox <lat0> <lon0> <lat1> <lon1> --sentinel --reclass <reclass> [ option ... ]

Arguments:
--raster RASTER Input landclass raster.
--bbox lat0 lon0 lat1 lon1 Bounding box of scenery to be generated
--sentinel Use Sentinel2 landclass tiles
--sentinel-dir SENTINEL_DIR Directory for Sentinel Data. Default /home/flightgear/data/Sentinel-2
--hgt-dir HGT_DIR Directory containing HGT DEM files. Default /home/flightgear/data/NASADEM
--output-dir OUTPUT_DIR Set output directory. Default /home/flightgear/output
--download-sentinel Download Sentinel2 tiles if needed
--reclass RECLASS Reclassify raster using file <reclass>. See ./scripts/mappings/
--coastline COASTLINE Clip against coastline against polygon (.osm)
--shrink-water SHRINK_WATER Shrink water bodies (landclasses 40, 41) by <pixels> pixels
--generate-water-raster Generate a water raster from OSM data
--generate-line-features Generate a water raster from OSM data
--cache-dir CACHE_DIR Directory for OSM data cache. Default /home/flightgear/cache/
--nasadem-server NASADEM_SERVER Set server to download NASADEM data from. Default https://e4ftl01.cr.usgs.gov/MEASURES/NASADEM_HGT.001/2000.02.11/)
--nasadem-user NASADEM_USER NASA Earthdata username.
--nasadem-password NASADEM_PASSWORD NASA Earthdata password.
--debug Debug output

For example, to generate a piece of terrain around Edinburgh (latitude 55.5, longitude 3 degrees West):
./scripts/genVPB.py --bbox 55 -4 56 -3 --raster ./data/uk_wgs84_10m_N54.tif

If you are using anything other than a CORINE raster you will need to reclassify the data to match the landclasses used by FlightGear. Those classes are defined in [https://gitlab.com/flightgear/fgdata/-/tree/next/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml]. You can reclassify them using the files in the [https://gitlab.com/flightgear/fgmeta/-/tree/next/ws30/mappings/ scripts/mappings] directory. E.g. to reclassify NLCD2019 data you can use <code>--reclassify ./scripts/mappings/nlcd2019.txt</code>.

genVPB.py will output the data to the output/vpb directory, in which you should find a series of files and directories.

=== Adding water ===
The terrain mesh does not have highly detailed water features - as typically the source data has a resolution of 10-25m. Water features are generated from OpenStreetMap data. To generate water features simply run the <code>genwaterraster.py</code> command.

Usage: genwaterraster.py [-h] --bbox lat0 lon0 lat1 lon1 [--debug] [--output-dir OUTPUT_DIR] [--cache-dir CACHE_DIR]

Arguments:
--bbox lat0 lon0 lat1 lon1 Bounding box of scenery to be generated
--debug Debug output
--output-dir OUTPUT_DIR Directory to write files into. Default /home/flightgear/output
--cache-dir CACHE_DIR Directory for OSM data cache. Default /home/flightgear/cache

For example, to generate water for the area around Edinburgh:
./scripts/genwaterraster.py --bbox 55 -4 56 -3

Inside the ./output/vpb directory there should be a set of directories and .png files.

=== Adding roads and railways ===
The terrain mesh does not have any line features - things like roads. These are generated separately from OpenStreetMap data. To generate line features simply run the <code>genroads.py</code> command:

Usage: ./scripts/genroads.py [-h] --bbox lat0 lon0 lat1 lon1 [--debug] [--threads THREADS] [--cache-dir CACHE_DIR] [--output-dir OUTPUT_DIR]

Arguments:
--bbox lat0 lon0 lat1 lon1 Bounding box of scenery to be generated
--debug Debug output
--threads THREADS Number of parallel threads to run. Defaults to 1
--cache-dir CACHE_DIR Directory for OSM data cache. Default /home/flightgear/cache/
--output-dir OUTPUT_DIR Set output directory. Default /home/flightgear/cache/

For example, to generate roads for the area around Edinburgh:
./scripts/genroads.py --bbox 55 -4 56 -3

Inside the ./output/Terrain directory there should be a set of directories and, .STG files text files.

==Running FlightGear with the new WS3.0 Terrain==
To test the new terrain, simply include the output directory in your scenery path and run FlightGear with the <code>--prop:/scenery/use-vpb=true</code> to enable WS3.0.

== Advanced Techniques ==
The following sections describe more complex techniques to generate higher quality WS3.0 terrain. Almost all of them involve using different data sources to generate a more detailed landclass raster before running the final scenery generation processes described above. Generating a highly detailed landclass raster is where the magic happens.

Most techniques use gdal or grass to modify the raster/vector data, typically using the QGIS program.

=== Using a different elevation model ===
If you are using another elevation model other than NASAEM, then you may need to re-project it using QGIS/gdalwarp to the WGS84 CRS (aka EPSG:4326).

=== Landclass Data Requirements ===
For any landclass data we need to ensure the data is in the correct format. That means:

# Is a Raster (geotiff) rather than Vector data. This raster will become the texture on the terrain that the terrain shaders do their magic on.
# Uses the WGS84 Coordinate Reference System. The ensures that the terrain generation step is efficient.
# Has the correct landclass values for each terrain type. We use a set of values based on the CORINE raster set, defined in [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml].

Below is a quick table showing what steps you need to take for common landclass data sources.
{| class="wikitable"
|+
!Landclass Data
!Warp to WGS84 required?
!Landclass re-classification Required?
!Raster Simplification Required?
!Conversion to Raster Required?
|-
|CORINE Raster
|Yes
|No
|No
|No
|-
|CORINE Vector
|Yes
|Yes
|No
|Yes
|-
|NLCD
|No
|Yes
|Yes
|No
|-
|Sentinel-2
|Yes
|Yes
|No
|No
|}
Conversion to Raster must be done manually. Converting to WGS84 and the correct landclasses ''can'' be done by the genVPB.py script, but slows down scenery generation. Therefore if you are planning to generate scenery multiple times it is best to pre-process the files yourself.

The easiest way to do these operations is using QGIS, which is available for most platforms. If you are scripting a toolchain, the QGIS tools include command-line equivalents for all commands.

When using QGIS, set the Project CRS to WGS84 (aka EPSG:4326). You can then add layers of Raster or Vector data from files from the <code>Layer->Add Layer</code> menu. When performing any operations, <u>always</u> write out the data to a real file so you can go back to it later. Disk space is cheap :).

=== Warping Raster Layers to WGS84 ===
genVPB.py will automatically convert to WGS84 if it detects a landclass raster with a different Coordinate System. However, you may wish to do so manually instead so all your data is on the same coordinate system.

In QGIS you can warp a raster layer to a different CRS using the Raster->Projections-Warp (Reproject) tool.

Select the following options in the dialog:

* Input Layer - Check you have selected the correct layer. The CRS is shown at the right.
* Target CRS - set to <code>EPSG:4326 - WGS84</code>, which should be your project CRS.
* Resampling Method to Use - Nearest Neighbour. (Landclass data is not like normal images. You don't want to interpolate between values.)
* Nodata value for output bands - 0.0 (This means that any data at the edges will be Ocean, usually a reasonable default)
* Advanced Parameters - No Compression
* Output data type - Byte
* Reprojected - Choose a target filename

Alternatively you can do this step from the commandline.
gdalwarp -t_srs EPSG:4326 -dstnodata 0.0 -r near -ot Byte -of GTiff -co COMPRESS=NONE -co BIGTIFF=IF_NEEDED /home/stuart/FlightGear/VPB/data/CORINE/u2018_clc2018_v2020_20u1_raster100m/DATA/U2018_CLC2018_V2020_20u1.tif /home/stuart/FlightGear/VPB/data/scratch/corine_WGS84.tif

=== Warping Vector Layers to WGS84 ===
genVPB.py will automatically convert to WGS84 if it detects a landclass raster with a different Coordinate System. However, you may wish to do so manually instead so all your data is on the same coordinate system.

In QGIS you can warp a vector layer using Vector->Data Management Tools->Reproject Layer.

Set the following options in the dialog:

* Input Layer - Check you have selected the correct layer. The CRS is shown at the right.
* Target CRS - set to <code>EPSG:4326 - WGS84</code>, which should be your project CRS.
* Reprojected - Choose a target filename

=== Reclassifying Vector Layers ===
For CORINE vector data in particular, the attributes used in the vector data are not the same as those used by the CORINE Raster data. So we need to create a new attribute on the data.
[[File:Field Calculator.png|thumb|QGIS Field Calculator]]
To do this

* Select <code>Layer->Open Attribute Table</code>. You should see a table with multiple columns. Each row represents a feature in the data.
* Click on <code>Toggle Editing Mode</code> (Ctrl + E), on the top left of the dialog
* Click on <code>New Field</code> (Ctrl+W) and create a new field called Landclass of type "Whole Number (Integer)". This will create a new column which we will populate with the correct landclass data
* Click on the <code>Open Field Calculator</code> button (Ctrl + I). (If you get an error about only being able to create Virtual fields, go back to the Layer menu, export it and open the exported file).
* Select the following options:
** Update Existing Field
** Select the Landclass field you just created.
** Copy the contents of https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/mappings/corine_vector.txt into the Expression box (without the comment lines starting with <code>#</code>). This is just some simple code to set the attribute correctly. The code should be correct for CORINE vector data. If your data is from other sources you will need to work out how you want to map your source data landclasses to the CORINE ones. [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml] can be used as a guide.
* Select <code>OK</code>. You should see that your landclass column is now populated with the landclass data.
* Select <code>Layer->Save Layer Edits</code> to save you changes

=== Creating a Raster from a Vector Layer ===
To create a Raster from a Vector Layer select <code>Raster->Conversion->Rasterize (Vector to Raster)</code>.
[[File:QGIS Rasterize (Vector to Raster).png|thumb|Creating a Raster from a Vector Layer - QGIS Rasterize]]
Select the following options:

* Input Layer - correct layer, check CRS
* Field to use for burn-in value - select the <code>Landclass</code> column you created above.
* Output raster size units. This is going to set the resolution of your raster. You can work out the resolution in two different ways:
** Select "Georeferenced units" and determine how many degrees each pixel is in latitude and longitude.
** Select "Pixels" and determine the size of raster you want in pixels. [https://www.nhc.noaa.gov/gccalc.shtml This] is a good calculator to help. You input e.g. SE and SW coordinates and calculate to get the distance in Km. Then you multiply by thousand and devide by the number of metres per pixel (e.g. 5) -> resolution for width.
* Width/Horizontal Resolution. Enter the values you've calculated for the horizontal resolution (longitudinal), or the width of the raster
* Height/Vertical Resolution. Enter the values you've calculated for the vertical resolution (latitude or the height of the raster)
* Output extent - Select an option from the box on the right. You can edit the text afterwards (NB: East, West, South, North). Best practise is to create long thin strips of 1 degree latitude in height, as this makes subsequent processing much easier.
* Assign a specific nodata value to output bands - Select 0.0 for Ocean. CORINE vector data in particular has a lot of nodata for Oceans
* Advanced Parameters - No Compression
* Output data type - Byte
* Rasterized - Select a new filename

=== Simplifying a Raster Layer ===
Some Raster Landclass data (NLCD included) has too much noise - in particular large US highway systems are identified as Urban areas.

To smooth it out we can use the GRASS <code>n.neighbors</code> function from the Processing Toolbox in QGIS.

Select the following options:

* Input Layer - correct layer, check CRS
* Neighborhood operation - median. (This is not a normal image, so using an average will result in weird values)
* Neighborhood size - 5.
* Neighbors - Select a new filename.

=== Clipping a Raster Layer with OSM Data for Land (Corine) ===
The Corine dataset does not match OSM coastlines exactly. The following multi-stage process makes sure, that no Corine land-use is in the water as defined by OSM.

==== Download OSM Land Data ====

Download land polygons based on OSM data as a Shapefile from [https://osmdata.openstreetmap.de/data/land-polygons.html Land Polygons] and make sure to pick the WGS84 projected download with split polygons ("Large polygons are split, use for larger scales"). Once downloaded unzip the content into a directory.

==== Reclassifying the OSM Land Data Vector Layer ====
I QGIS make sure that only the layer for the raster for land data is selected (e.g. <code>land-polygons-split-4326</code>) -> in the map view you will see the whole earth. NB: typically you do this reclassify only once after download and can reuse the result for future processing.

Then:

* Select <code>Layer->Open Attribute Table</code>. You should see a table with multiple columns. Each row represents a feature in the data.
* Click on <code>Toggle Editing Mode</code> (Ctrl + E), on the top left of the dialogue
* Click on <code>New Field</code> (Ctrl+W) and create a new field called Landclass of type <code>Integer (32 bit)</code>. This will create a new column which we will populate with the correct land class data
* On top of the table on the left side choose "Landclass" in the drop-down menu, then input <code>2</code> into the field to the right and then press button "Update" all to the left of this field.
* Wait a bit and the close the dialogue.
* Select <code>Layer->Save Layer Edits</code> to save your changes (overwrite e.g. <code>land-polygons-split-4326</code>).

==== Convert the Land Data from Vector to Raster ====
Do the same as in chapter "Creating a Raster from a Vector Layer" above. The only difference is that the Input layer will be the land data polygons and you need to choose a different file name for the "Rasterized" (e.g. osm_land_scotland_5m.tif)

==== Remove Novalue Entries in the Land Data Raster ====
To do this:

* Select <code>Processing->Toolbox</code>. You should see a new box on the right side.
* Write "gdal_calc" in the search box and you should see an entry "Raster calculator". Double click on it and you will get a new dialogue window.
* In this dialogue:
** For "Input layer A" choose the raster from the previous chapter ((e.g. osm_land_scotland_5m.tif)
** In field "Calculation in gdalnumeric ..." write: <code>greater(A,0) * A</code>
** In field "Output raster type" choose <code>Byte</code>
** In field "Advanced Parameters" choose Profile <code>No compression</code>
** In field "Additional command-line parameters" write: <code>--hideNoData</code>
** In field "Calculated" choose a file (e.g. osm_land_scotland_allvalues_5m.tif)
** (In the "GDAL/OGR console call" it will have something similar to the follwing - just with different paths: <code>gdal_calc.py --overwrite --calc "greater(A ,0) * A" --format GTiff --type Byte -A /home/vanosten/custom-fg-scenery/data/osm_land_scotland_5m.tif --A_band 1 --co COMPRESS=NONE --co BIGTIFF=IF_NEEDED --hideNoData --outfile /home/vanosten/custom-fg-scenery/data/osm_land_scotland_allvalues_5m.tif</code>
** Press the "Run" button - and when complete close the dialogue.

You should now see a map only black and white. You can check for correctness by pressing <code>CTRL+SHIFT+I</code> to get a cursor with an arrow and an "i". First make sure the new raster is selected on the left side. Next click on the sea/ocean and then check in the "Identify Results" window on the right that the value is < 2. The click on the land and check that the value is 2.

==== Create the Final Clipped Corine Raster Against OSM Land Data =====
Do the following:

* In QGIS make sure that you have only the following two layers: the basis Corine raster (see chapter "Creating a Raster from a Vector Layer" - here e.g. corine_raster_scotland_5m.tif) and plus the raster from the previous step (e.g. osm_land_scotland_allvalues_5m.tif)
* Select <code>Raster->Raster Calculator ...</code> and a corresponding dialogue will open showing on the left hand side the two rasters.
* Choose a new "Output layer" (e.g. corine_raster_scotland_clipped_5m.tif).
* In the "Raster Calculator Expression" field input: <code>if ("osm_land_scotland_all_data_5m@1" < 2, 44, "corine_raster_scotland_5m@1")</code>
* Press button "OK" and wait a while (you will see a new dialogue with showing the progress.

Done. You have now a raster (e.g. corine_raster_scotland_clipped_5m.tif) which does not have land in areas, where OSM data has sea/ocean.

=== Reclassifying a Raster Layer ===
WS3.0 uses CORINE landclass values. If using data from other sources it needs to be reclassified to the correct values. genVPB.py has an option to do this, but you may wish to do so manually.

To do this select <code>GRASS->Raster->r.reclass</code> from the Processing Toolbox.

Select the following options:

* Input Raster Layer - correct layer, check CRS
* Reclass rules text - copy in the contents of https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/mappings/nlcd2019.txt. Or an appropriate mapping from your landclass data to CORINE. Note that you can also reference a file using the "File containing reclass rules" option. Note a mapping of 22 24 = 1 is the same as 22 and 24 = 1. For a range of 22 to 24 use 22 23 24 = 1.
* Reclassified - Select a new filename.

(If this doesn't work a similar function is available in the Processing Toolbox under <code>Raster analysis->Reclassify by table</code>. However this doesn't save your table once you close the dialog, and entries have to be manually entered individually which takes a lot of effort)

=== Step By Step Procedure for Processing NLCD for the USA using the Raster Calculator, Up sampling and GRASS r.neighbors===

'''NOTE: This "raster calculator" process or method is considered suboptimal to the Python script method below. The Python script method below has newer smoothing processes. However, this method does contain useful knowledge on how to use the raster calculator. It needs to be updated to match the Python script method.'''

We will use a predetermined file naming convention throughout this procedure for simplicity. You can use a naming convention of your choice.
The below python script produces more refined scenery than this method. I left this documentation though as it is a good starting point and has examples of how you can manipulate rasters using the calculator. It was the first steps I took to learn how all this stuff works. It could be updated to match all the steps used in the python script method.

Obtain your NLCD_2019_Land_Cover from source of choice, https://www.mrlc.gov/viewer/

NLCD_2019_Land_Cover data = NLCD_2019_Land_Cover_California-Southern.tiff

Obtain your NLCD_2016_Tree_Canopy from source of choice, https://www.mrlc.gov/viewer/

NLCD_2016_Tree_Canopy data = NLCD_2016_Tree_Canopy_California-Southern.tiff

Make Deciduous Layer 255 to 0 EPSG:5070 - NAD83 - Raster Calculator

("NLCD_2016_Tree_Canopy_California-Southern@1" = 255) * 0 + ("NLCD_2016_Tree_Canopy_California-Southern@1" != 255) * "NLCD_2016_Tree_Canopy_California-Southern@1"

Output CRS = EPSG:5070 - NAD83

Output Layer = California-Southern_deciduous-coast-clipped.tiff

OK

Make Tree Canopy Layer EPSG:5070 - NAD83 - Raster Calculator

Use the prevailing tree type, for Deciduous use * 41, for Evergreen use * 42, for MixedForest use 43.

Later we add this Tree Canopy layer to the raster where there is currently no trees in the NLCD

If ocean bordering with index 255 -

("California-Southern_deciduous-coast-clipped@1" != 0) * 42

Else

("NLCD_2016_Tree_Canopy_California-Southern@1" != 0) * 42

Output CRS = EPSG:5070 - NAD83

Output Layer = California-Southern_deciduous.tiff

OK

Make Clipped Ocean Frontage EPSG:5070 - NAD83 - GIMP

Source = NLCD_2019_Land_Cover_California-Southern.tiff

Flood fill index 11 (blue) with 0 (black)

Export tiff = California-Southern_coast-clipped.tiff

Warp NLCD Deciduous and Base NLCD from EPSG:5070 - NAD83 / Conus Albers NLCD to Project CRS: EPSG:4326 - WGS 84 - WARP

If ocean bordering with index 255

Warp California-Southern_coast-clipped.tiff

Else

Warp NLCD_2016_Tree_Canopy_California-Southern.tiff

and

Warp Deciduous NLCD from EPSG:5070 - NAD83 / Conus Albers NLCD to Project CRS: EPSG:4326 - WGS 84

Warp California-Southern_deciduous.tiff

Raster -> Projection - > Warp

Target CRS = EPSG:4326 - WGS 84

Resampling method to use = Nearest Neighbour

Output data type = byte

Reprojected = California-Southern_4326-84.tiff and California-Southern_deciduous_4326-84.tiff

Run

Combine "California-Southern_deciduous_4326-84.@1" and "California-Southern_4326-84@1" - Raster Calculator

This step adds the Tree Canopy layer to the existing NLCD raster only where there is currently no existing tree land cover.

(("California-Southern_4326-84@1" > 0 AND "California-Southern_4326-84@1" != 41 AND "California-Southern_4326-84@1" != 42 AND "California-Southern_4326-84@1" != 43) AND "California-Southern_deciduous_4326-84@1" > 0) * "California-Southern_deciduous_4326-84@1" + ("California-Southern_4326-84@1" = 41 OR "California-Southern_4326-84@1" = 42 OR "California-Southern_4326-84@1" = 43 OR "California-Southern_deciduous_4326-84@1" <= 0) * "California-Southern_4326-84@1"

Output CRS = EPSG:4326 - WGS 84

Output Layer = California-Southern_adjusted.tiff

OK

Re-class urban 21, 22, 23, 24 = grass 26 - Raster Calculator

This step is being used to erase all the man made clutter on the raster with grassland. Instead of grassland you can replace it with any type of prevailing groundcover in the area your processing.

For example this places a road easement of grass on all the road clutter that was originally in the raster. If your processing a desert area you might want to use dirt or sand instead of grassland. For Arctic areas maybe use tundra.

Part of the clutter gets replaced later in the process.

("California-Southern_adjusted@1" = 11) * 41 + ("California-Southern_adjusted@1" = 12) * 34 + ("California-Southern_adjusted@1" = 21) * 26 + ("California-Southern_adjusted@1" = 22) * 26 + ("California-Southern_adjusted@1" = 23) * 26 + ("California-Southern_adjusted@1" = 24) * 26 + ("California-Southern_adjusted@1" = 31) * 27 + ("California-Southern_adjusted@1" = 41) * 26 + ("California-Southern_adjusted@1" = 42) * 24 + ("California-Southern_adjusted@1" = 43) * 25 + ("California-Southern_adjusted@1" = 51) * 30 + ("California-Southern_adjusted@1" = 52) * 29 + ("California-Southern_adjusted@1" = 71) * 26 + ("California-Southern_adjusted@1" = 72) * 32 + ("California-Southern_adjusted@1" = 73) * 31 + ("California-Southern_adjusted@1" = 74) * 31 + ("California-Southern_adjusted@1" = 75) * 32 + ("California-Southern_adjusted@1" = 81) * 18 + ("California-Southern_adjusted@1" = 82) * 19 + ("California-Southern_adjusted@1" = 90) * 25 + ("California-Southern_adjusted@1" = 95) * 35

Output CRS = EPSG:4326 - WGS 84

Output Layer = California-Southern_reclass-grass.tiff

OK

Make Urban layer

("California-Southern_adjusted@1" = 21) * 10 + ("California-Southern_adjusted@1" = 22) * 1 + ("California-Southern_adjusted@1" = 23) * 1 + ("California-Southern_adjusted@1" = 24) * 2

Output CRS = EPSG:4326 - WGS 84

Output Layer = California-Southern_urban.tiff

OK

Remove the road clutter with r.neighbor

GRASS/Raster/r.neighbor

Neighborhood operation = median

Neighborhood size = 7

Neighbors = California-Southern_urban-only.tiff

Run

Combine "California-Southern_reclass-urban@1" and "California-Southern_reclass-grass@1"

This step replaces the "cleaned up" urban areas back into the raster.

("California-Southern_urban-only@1" < 1) * "California-Southern_reclass-grass@1" + ("California-Southern_urban-only@1" != 0) * "California-Southern_urban-only@1"

Output CRS = EPSG:4326 - WGS 84

Output Layer = California-Southern_adjusted-combined.tiff

OK

Up sample California-Southern_adjusted-combined.tiff 2x, 4x or 8x resolution 0.00008309125

Active Layer = California-Southern_adjusted-combined.tiff

Layer/Save As

2x Horizontal = 0.00008309125

2x Vertical = 0.00008309125

4x Horizontal = 0.00010637625

4x Vertical = 0.00010637625

8x Horizontal = 0.00005318812

8x Vertical = 0.00005318812

File Name = California-Southern_final-prep-4x.tiff

OK

Simplify California-Southern_4326-84-hd.tiff with r.neighbor

GRASS/Raster/r.neighbor

Neighborhood operation = median

Neighborhood size = 7

Neighbors = California-Southern_urban-only.tiff

Run

Reclass index 0 to 44, leave the rest the same

("California-Southern_4326-84-hd@1" = 0) * 44 + ("California-Southern_4326-84-hd@1" != 0) * "California-Southern_4326-84-hd@1"

Output CRS = EPSG:4326 - WGS 84

Output Layer = California-Southern_4326-84-hd-corrected.tiff

OK

<big>Optional HD Fresh Water Option</big>
*Step 1 - Obtain and load hi resolution vector layer
Make sure that the vector layer and the raster layer you will eventually merge to have the same projection. ** Extent can be different if you use the option below.
#Use Top Menu: "Raster" -> "Conversion" -> "Rasterize (vector to raster)" or Processing Toolbox: GDAL -> "Vector conversion" -> "Rasterize (vector to raster)"
# Input layer = Southern-California_water_4326-84
#Fixed value to burn = 41 (water)
# Output raster size units = "Georeferenced units"
#Width/Horizontal resolution = 0.00008309125 (4x the base NLCD resolution )
#Height/Vertical resolution = 0.00008309125 (4x the base NLCD resolution)
#<nowiki>** Output extent = Select the raster layer you will eventually merge with as the "Output extent".</nowiki>
#Under "Rasterized" choose a new filename to save the new raster to. We'll use Southern-California_4326-84-hd-water.tiff.

Click "Run" to generate the hi resolution raster layer.

*Step 2 - Reclass hi res, smoothed water to grass
# Open Raster Calculator
#Under "Output layer" choose a new filename to save the new raster to. We'll use Southern-California_4326-84-hd-nowater.tiff.
#Copy the following into the "Raster Calculator Expression" box. Where Southern-California_4326-84-hd is the name of your hi resolution, smoothed NLCD that includes the water data.
"Southern-California_4326-84-hd@1" * ("Southern-California_4326-84-hd@1" != 41) + 26 * ("Southern-California_4326-84-hd@1 = 41")

Click on "OK". When finished you will have a new raster with the water layer changed to grassland. Another choice would be to change it to sand.

*Step 3 - Combine the hi resolution no water raster and the hi resolution water raster.
# Use Top Menu: "Raster" -> "Miscellaneous" -> "Merge" or Processing Toolbax: GDAL -> Raster Miscellaneous -> Merge
#Input layers = Select "Southern-California_4326-84-hd-nowater@1" and Southern-California_4326-84-hd-water.tiff
#Output data type = "byte".
# Under "Merged" choose a new filename to save the new raster to. We'll use Southern-California_4326-84-hdwater.tiff.

Click "Run" to generate the new merged hi resolution raster layer.

=== Optional Python script to process NLCD for the USA ===
You can optionally process the NLCD by loading this script in the python console of the QGIS Desktop program.
This python script method produces more refined data than by using the python calculator method above and it is more automated.
If you run this script outside the python console you will need to modify it to locate the data you are processing.
If you save the NLCD tiff's using the same consistent naming convention used in this example it is fairly simple to generate final WS3.0 tiff's to use to generate the scenery.

You will start with an original tree layer and a land cover layer from the MRLC.gov site. See the section "Obtaining NLCD" in the above "Step By Step Procedure for Processing NLCD for the USA using the Raster Calculator" topic.

For example, to start with you will have a couple files named...

NLCD_2016_Tree_Canopy_Alaska141-140_60.tiff

NLCD_2016_Land_Cover_Alaska141-140_60.tiff

In the QGIS program the layer names you start with will be...

NLCD_2016_Tree_Canopy_Alaska141-140_60

NLCD_2016_Land_Cover_Alaska141-140_60

which will refer to the tiff files.

Running this script will generate a bunch of intermediate files including the last file, that will be the final finished file for running in the VPB script or VPB build environment Docker image.

The last file for this example for New York would be, NLCD_2016_Alaska141-140_60_Smoothed-HD-Compressed_4326.tiff

<syntaxhighlight lang="python">
from qgis.core import QgsApplication, QgsCoordinateTransform, QgsProject, QgsRasterLayer, QgsCoordinateReferenceSystem, QgsProcessingException, QgsRasterBlock, QgsRectangle
from qgis.analysis import QgsRasterCalculator, QgsRasterCalculatorEntry
from qgis import processing
from processing.core.Processing import Processing
from osgeo import gdal, osr, ogr
import os
import numpy
import numpy as np
import subprocess

# Define input layer names, change according to your file names
path = 'G:/Scenery/ws3.0/';
year = '2016';
state = 'Alaska';
part = '141-140_60';

################################## IMPORTANT ###############################
# Beginning filename of the NLCD from the source needs to be
# NLCD_' + year + '_Tree_Canopy_' + state + part + '.tiff'
# Also note that "/data/" is hardcoded into the path as well
# I needed the existing path structure to process it by state.
# For Alaska I used one lat and a few lon sections per chunck built.
# I will likly do the entire NLCD coverage area the same in future runs.
# Example beginning NLCD source:
# NLCD_2016_Tree_Canopy_Alaska141-140_60.tiff
# Full path and filename to source example is:
# G:/Scenery/ws3.0/Alaska/data/NLCD_2016_Tree_Canopy_Alaska141-140_60.tiff
# Final output path to last processed file is:
# G:/Scenery/ws3.0/Alaska/data/NLCD_2016_Alaska141-140_60_Smoothed-HD-Compressed_4326

#IMPORTANT NOTE:
# On any subprocess.run(command, shell=True) process, when using the script in Linux
# you need to change to subprocess.run(command). Remove the shell=True.

#You can try using the following syntax for both Windows and Linux
#subprocess.run([
# 'gdal_calc.py',
# '-A', input_path,
# '--outfile', output_path,
# '--calc', expression,
# '--type', 'Byte'
#], check=True)
############################################################################

################################################## Step 1: Reclass tree canopy to one landcover type 41, 42, or 43 #########################################
#FG NLCD
#23 DeciduousBroadCover 41
#24 EvergreenForest 42
#25 MixedForest 43

# Define input and output paths
input_path = path + state + '/data/NLCD_' + year + '_Tree_Canopy_' + state + part + '.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Trees-Combined.tiff'

expression = (
'((A > 0) & (A < 255)) * 43 + '
'(A <= 0) * A'
)
command = [
'gdal_calc.py',
'-A', input_path,
'--outfile', output_path,
'--calc', expression,
'--type', 'Byte'
]
subprocess.run(command, shell=True)

print("Step 1: Calculate result_tree_canopy completed. (NLCD_" + year + "_" + state + part + "_Trees-Combined)")

############################################################# Step 2: Warp tree canopy to 4326 #############################################################

input_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Trees-Combined.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Tree_Canopy_4326.tiff'

processing.run(
"gdal:warpreproject",
{
'INPUT':input_path,
'SOURCE_CRS':None,
'TARGET_CRS':QgsCoordinateReferenceSystem('EPSG:4326'),
'RESAMPLING':0,
'NODATA':None,
'TARGET_RESOLUTION':None,
'OPTIONS':'',
'DATA_TYPE':1, # GDAL GDT_Byte
'TARGET_EXTENT':None,
'TARGET_EXTENT_CRS':None,
'MULTITHREADING':False,
'EXTRA':'',
'OUTPUT':output_path
}
)

print("Step 2: Warp tree_canopy completed. (NLCD_" + year + "_" + state + part + "_Tree_Canopy_4326)")

################################################################### Step 3: Warp land cover 4326 ############################################################

input_path = path + state + '/data/NLCD_' + year + '_Land_Cover_' + state + part + '.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Land_Cover_4326.tiff'

processing.run(
"gdal:warpreproject",
{
'INPUT':input_path,
'SOURCE_CRS':None,
'TARGET_CRS':QgsCoordinateReferenceSystem('EPSG:4326'),
'RESAMPLING':0,
'NODATA':None,
'TARGET_RESOLUTION':None,
'OPTIONS':'',
'DATA_TYPE':1, # GDAL GDT_Byte
'TARGET_EXTENT':None,
'TARGET_EXTENT_CRS':None,
'MULTITHREADING':False,
'EXTRA':'',
'OUTPUT':output_path
}
)

print("Step 3: Warp land_cover completed. (NLCD_" + year + "_" + state + part + "_Land_Cover_4326)")

################################################################ Step 4: Combine land cover 4326 and tree canopy 4326######################################

input_path_a = path + state + '/data/NLCD_' + year + '_' + state + part + '_Tree_Canopy_4326.tiff'
input_path_b = path + state + '/data/NLCD_' + year + '_' + state + part + '_Land_Cover_4326.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Tree_Land_Combined_4326.tiff'

expression = (
'(((B > 0) & (B < 255)) & (B != 41) & (B != 42) & (B != 43) & (A > 0)) * A + '
'((B == 41) | (B == 42) | (B == 43) | (A <= 0)) * B'
)
command = [
'gdal_calc.py',
'-A', input_path_a,
'-B', input_path_b,
'--outfile', output_path,
'--calc', expression,
'--type', 'Byte'
]
subprocess.run(command, shell=True)

print("Step 4: Combine tree canopy and land cover completed. (NLCD_" + year + "_" + state + part + "_Tree_Land_Combined_4326)")

############################################################## Step 5: Replace urban and clutter with grass ###################################################

input_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Tree_Land_Combined_4326.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Grass-Only_4326.tiff'

expression = (
'(A == 0) * 44 + '
'(A == 11) * 44 + '
'(A == 12) * 34 + '
'(A == 21) * 26 + '
'(A == 22) * 26 + '
'(A == 23) * 26 + '
'(A == 24) * 26 + '
'(A == 31) * 27 + '
'(A == 41) * 23 + '
'(A == 42) * 24 + '
'(A == 43) * 25 + '
'(A == 51) * 30 + '
'(A == 52) * 29 + '
'(A == 71) * 26 + '
'(A == 72) * 32 + '
'(A == 73) * 31 + '
'(A == 74) * 31 + '
'(A == 75) * 32 + '
'(A == 81) * 18 + '
'(A == 82) * 19 + '
'(A == 90) * 25 + '
'(A == 95) * 35'
)
command = [
'gdal_calc.py',
'-A', input_path,
'--outfile', output_path,
'--calc', expression,
'--type', 'Byte'
]
subprocess.run(command, shell=True)

print("Step 5: Replace urban and clutter with grass completed. (NLCD_" + year + "_" + state + part + "_Grass-Only_4326)")

################################################################## Step 6: Reclass urban 21, 22, 23 or 24 ###########################################################

input_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Tree_Land_Combined_4326.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Reclassed-Urban_4326.tiff'

expression = (
'(A == 21)*10 + '
'(A == 22)*1 + '
'(A == 23)*1 + '
'(A == 24)*2'
)
command = [
'gdal_calc.py',
'-A', input_path,
'--outfile', output_path,
'--calc', expression,
'--type', 'Byte'
]
subprocess.run(command, shell=True)

print("Step 6: Reclass urban completed. (NLCD_" + year + "_" + state + part + "_Reclassed-Urban_4326)")

################################################################ Step 7: Remove clutter and roads from urban ###########################################################

input_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Reclassed-Urban_4326.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Urban-Only_4326.tiff'

processing.run(
"grass7:r.neighbors",
{
'input':input_path,
'selection':None,
'method':1, #1=median, 2=mode
'size':7,
'gauss':None,
'quantile':'',
'-c':False,
'-a':False,
'weight':'',
'output':output_path,
'GRASS_REGION_PARAMETER':None,
'GRASS_REGION_CELLSIZE_PARAMETER':0,
'GRASS_RASTER_FORMAT_OPT':'',
'GRASS_RASTER_FORMAT_META':''
}
)

print("Step 7: Remove clutter and roads from urban. (NLCD_" + year + "_" + state + part + "_Urban-Only_4326)")

############################################################## Step 8: Combine grass only and clean urban #########################################################

input_path_a = path + state + '/data/NLCD_' + year + '_' + state + part + '_Urban-Only_4326.tiff'
input_path_b = path + state + '/data/NLCD_' + year + '_' + state + part + '_Grass-Only_4326.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Combined-Clean_4326.tiff'

expression = (
'((A > 0) & (B > 0)) * A + '
'((A <= 0) | (B <= 0)) * B'
)
command = [
'gdal_calc.py',
'-A', input_path_a,
'-B', input_path_b,
'--outfile', output_path,
'--calc', expression,
'--NoDataValue', '0'
]
subprocess.run(command, shell=True)

print("Step 8: Combined and clean completed. (NLCD_" + year + "_" + state + part + "_Combined-Clean_4326)")

################################################################## Step 9: Upsample to HD #################################################################

input_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Combined-Clean_4326.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Combined-Clean-HD_4326.tiff'

# Open the original raster
ds = gdal.Open(input_path)
gt = ds.GetGeoTransform()

# Extract the original resolution
original_xRes = gt[1]
original_yRes = abs(gt[5])

# Define the percentage to resize by (e.g., 0.50 for 50%, 2.0 for 200%)
percentage = 8.0 # Adjust this as needed

# Calculate the new resolution
new_xRes = original_xRes / percentage
new_yRes = original_yRes / percentage

# Perform the warp (resampling)
gdal.Warp(
output_path,
input_path,
xRes=new_xRes,
yRes=new_yRes,
outputType=gdal.GDT_Byte # Set the output type to uint8
)

print("Step 9: Upsample to. (NLCD_" + year + "_" + state + part + "_Combined-Clean-HD_4326)")

################################################################## Step 10: Smooth all features in original dataset #################################################################

input_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Combined-Clean-HD_4326.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Smoothed-HD_4326.tiff'

processing.run(
"grass7:r.neighbors",
{
'input':input_path,
'selection':None,
'method':1, #1=median, 3=mode
'size':11,
'gauss':None,
'quantile':'',
'-c':False,
'-a':False,
'weight':'',
'output':output_path,
'GRASS_REGION_CELLSIZE_PARAMETER':0,
'GRASS_RASTER_FORMAT_OPT':'',
'GRASS_RASTER_FORMAT_META':''
}
)

print("Step 10: Smooth all features in original dataset completed. (NLCD_" + year + "_" + state + part + "_Smoothed-HD_4326)")

################################################################## Step 11: Convert to 8Bit #################################################################

input_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Smoothed-HD_4326.tiff'
output_path = path + state + '/data/NLCD_' + year + '_' + state + part + '_Smoothed-HD-Compressed_4326.tiff'

processing.run(
"gdal:translate",
{
'INPUT':input_path,
'TARGET_CRS':None,
'NODATA':0,
'COPY_SUBDATASETS':False,
'OPTIONS':'',
'EXTRA':'',
'DATA_TYPE':1,
'OUTPUT':output_path,
'OPTIONS': 'COMPRESS=LZW'
}
)

result_urban_layer = QgsRasterLayer(output_path, 'NLCD_' + year + '_' + state + part + '_Smoothed-HD-Compressed_4326')
QgsProject.instance().addMapLayer(result_urban_layer)

print("Step 11: Reclass no-data (nan) to 41. (NLCD_" + year + "_" + state + part + "_Smoothed-HD-Compressed_4326)")
</syntaxhighlight>

===Generating the Terrain using osgdem===
Instead of using genVPB.py, you may wish to run osgdem directly.

In the Windows/Docker platform you can send the generate tile command directly to osgdem.exe, one tile at a time.

Using the NLCD raster processing convention from above, following is the the final step after creating the raster and entering bash shell with the windows version of "docker run..."

osgdem --TERRAIN --image-ext png --RGBA --no-interpolate-imagery --disable-error-diffusion --geocentric --no-mip-mapping -t ./data/California-Southern_4326-84-hd-corrected.tiff -d ./SRTM-3/N32W115.hgt -b -115 32 -114 33 --PagedLOD -l 7 --radius-to-max-visible-distance-ratio 3 -o ./output/vpb/w120n30/w115n32/ws_w115n32.osgb

Note: the --image-ext png --RGBA flags are critical to successfully building correctly placed landclasses in the final VPB generated scenery.

If you prefer to run the scenery generation manually, running the VPB osgdem process is described in more detail here: [[Virtual Planet Builder#Running VPB]].

After doing this you should have an output directory containing files of the form <code>output/vpb/w010n50/w004n50/ws_w004n50.osgb</code>, plus a host of sub-directories. Each one of these is a 1x1 tile of terrain.

to leave the container simply type <code>exit</code>.

===Packaging the Scenery===
Once you have the terrain and line features they should be packaged in a scenery directory in vpb and Terrain sub-directories respectively. E.g.
MyCoolScenery/Terrain
MyCoolScenery/vpb
It is good practise to document the data sources used in scenery generation. Some source licenses require attribution of the original data source for anything derived, published or distributed.

To assist in fulfilling these license obligations, you can create a source.xml file in the scenery directory which includes attribution information. This will then be available from within the simulator under Help->Scenery Sources, and <u>may</u> fulfil the attribution requirements of your license. '''Note that you are responsible for fulfilling any license requirements from the data, not FlightGear'''.

The format of the file is straightforward:
<?xml version="1.0"?>
<PropertyList>
<nowiki><source></nowiki>
<name>Corine Land Cover (CLC) 2018, Version 2020_20u1</name>
<nowiki><link></nowiki><nowiki>http://web.archive.org/web/20221112175615/https://land.copernicus.eu/pan-european/corine-land-cover/clc2018?tab=metadata%2A</nowiki><nowiki></link></nowiki>
<license>GMES Open License</license>
<nowiki></source></nowiki>
<nowiki><source></nowiki>
<name>NASADEM Merged DEM Global 1 arc second V001</name>
<nowiki><link></nowiki><nowiki>https://www.earthdata.nasa.gov/</nowiki><nowiki></link></nowiki>
<license>Public Domain</license>
<nowiki></source></nowiki>
<nowiki><source></nowiki>
<name>OpenStreetMap</name>
<nowiki><link></nowiki><nowiki>https://www.openstreetmap.org/copyright</nowiki><nowiki></link></nowiki>
<license>Open Data Commons Open Database License</license>
<nowiki></source></nowiki>
</PropertyList>

File:July 2025 SOTM.png

2025-08-29T10:30:54Z

Fahim Dalvi: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Mid-day Innsbruck take off, FlightGear Next + HDR}}
|date=2025-07-04
|source={{own}}
|author=[[User:Fahim Dalvi|Fahim Dalvi]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:Screenshot of the month]]

User:Fahim Dalvi

2025-03-16T12:06:27Z

Fahim Dalvi:

{{User
|name = Fahim Imaduddin Dalvi
|location = Doha,Qatar
|age = 17
|job = Student
|interests = Programming, Computers, FlightGear
|callsign = Fahim

}}

Spare-time FlightGear developer since late 2007.
I Have Been Working on the Following Projects:
* '''Aircraft'''
** Airbus A380
** LCA

* '''Scenery'''
** Singapore
** Carribean
** Courchevel
** Monuments Around the world

Misc Links:

https://www.bitwisetech.com/fgfs/fgdata/Input/Joysticks/Logitech/

Changelog 2020.3

2023-10-28T06:16:35Z

Fahim Dalvi: Added to changelog for 2020.3.19

{{changelogs|prev=2020.1|next=2022.1}}

Available in: [[Changelog_2020.3|English]], [[Pl/Changelog_2020.3|Polish]], [[Zh/2020.3|Chinese]]

Please help us translate into other languages!

----
The FlightGear development team is delighted to announce the v2020.3 LTS release of FlightGear, the free, open-source flight simulator. This is the second Long Term Support release for FlightGear, since the project changed to offering both Long Term Support releases, and more cutting-edge Preview releases. This release represents the culmination of two years of development effort by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

Major enhancements since the v2020.3 LTS include:
* a developer preview of the upcoming Compositor graphical rendering framework as a separate pre-built binary,
* enhancements to both the JSBSim and YASim flight dynamics models
* DDS texture caching to reduce load times
* faster loading and more memory efficient buildings
* improved aircraft carrier support

Additionally 30 completely new aircraft have been added to the official hangar, and a further 71 have received major updates.

{{Disclaimer|id=final-fixed-function-release}}

Founded in 1997, FlightGear features more than 700 aircraft, a worldwide scenery database, a multiplayer environment, detailed sky modelling, a flexible and open aircraft modelling system, varied networking options, multiple display support, a powerful scripting language, and an open architecture. Best of all, being open-source, the simulator is owned by the community and everyone is encouraged to contribute.

FlightGear - Fly Free!

----

== Launcher ==
* Addition of a welcome screen on first launch, providing helpful information to first time users.
* Aircraft can now be marked as Favourites, and filtered, making it easier to see find your favourite aircraft out of the hundreds available.
* The launcher now supports aircraft carriers, including selecting a carrier and setting a start position.
* {{key press|Ctrl|F}} shortcut for when you just want to Fly!
* Improved support for helipads and seaports, including detection of current aircraft type.
* Numerous bugfixes and stability improvements, in particular for the aircraft and addons tabs.

== Graphics ==
* To provide a developer preview, the [[Compositor]] renderer is included as part of this release. It provides a fully XML-configurable multi-pass rendering pipeline that is compatible with ALS and includes clustered shading.
* Support for DDS Texture Cache, improving loading times for texture files.
* Star visibility is configurable based on magnitude of star and atmospheric conditions.
* Use of non-directional point sprites as a fallback for drivers that do not support triangles of point sprites is now supported by setting <code>/rendering/triangle-directional-lights=false</code>.
* A new Tower AGL view has been added. This is similar to Tower View, except that it keeps both the aircraft and the ground immediately below the aircraft in view, zooming and panning smoothly as the aircraft moves. Good for viewing landings.
* Improved airport grass textures
* Implemented tidal movement for littoral areas.
* Updated regional material definitions for California, Asia, Northern Brazil, Iceland, Jan Mayen island.
* Active volcanoes - Katla, Eyjafjallajokull, Surtsey.
* Instanced-based random and OpenStreetMap buildings, improving performance and graphical quality significantly.
* Improvements to the Wingflex Shader.
* Users may enable/disable the pilot model from the View Options dialog.

== JSBSim ==
* Added the ability to set up the starter and acceleration times of a turbine (parameters <code><n1spinup></code>, <code><n2spinup></code>, <code><n1startrate></code>, <code><n2startrate></code>).
* The <code><integrator></code> filter can now be reset to 0.0 by setting its <code><trigger></code> property to a negative value.
* The integration scheme of the <code><integrator></code> filter can now be chosen among <code>rect</code> (Euler), <code>trap</code> (Trapezoidal), <code>ab2</code> (2nd order Adams-BashForth) and <code>ab3</code> (3rd order Adams-Bashforth)
* The following functions can now be used in <code><function></code>: <code>floor</code>, <code>ceil</code> and <code>fmod</code>. Their functionalities are the same than the corresponding C/C++ functions.
* <code><function></code> now checks the number of its arguments.
* New system component linear_actuator
* Export the fuel density to the property tree
* Added cyclic clipping for FCS components
* Added the ability to control the turbine engines spin down factor
* [Backward compatibility breakage] Gyros are now measuring rotation rates instead of rotational accelerations. Gyros that measure rotational accelerations do not exist in the real world.
* Output properties of flight control elements are no longer tied. This saves a lot of spurious warning messages and allows direct references of the same properties among several flight controls.
* Water vapor in the atmosphere is now managed through its mass fraction rather than its partial pressure. The former being the physical quantity that is conserved when pressure and temperature vary.
* Check that there are at least 3 contacts before trying to trim on ground.
* Added optional transmission of the simulation time for FG UDP interface
* The existence of the property that is used for table independent vars is now checked during execution rather than when the XML definition is parsed. This relaxes the order in which filters, table and more generally flight controls need to be declared in the XML definition files.
* Electric engines RPM is now exported in UDP sockets.
* The parameter <code><ignitionn2></code> now affects N2 rather than N1.
* A warning is now given when max < min in a <code><clipto></code> rather than throwing an exception
* Added the ability to log properties in a CSV file with the new fgfs executable argument <code>--jsbsim-output-directive-file</code>

== YASim ==
* Ground friction (stiction) changes
* Support for transonic flow effects.
* Control initial gear state directly by setting <code>/fdm/yasim/respect-external-gear-state=true</code>, rather then YASim settings this depending on whether the aircraft is in the air or on the ground.
* Electric engines are now supported.

== Weather and Environment ==
* Increased turbulence will be encountered near active volcanoes.
* Configurable METAR URL.
* METAR strings are decoded and displayed in a human-readable form in the weather dialog.

== Carriers ==
* Two new carrier-specific starting options are supported in the launcher: <code>carrier-takeoff</code> and <code>carrier-approach</code>.
* A new <code>--carrier-position</code> command-line argument has been added. This can be used to select the aircraft start position on an aircraft carrier. Either a catapult (e.g. <code>cat-1</code>), a parking position (e.g. <code>park-1</code>), on final approach on the FLOLS (<code>flols</code>) or abeam the carrier (<code>abeam</code>).
* MPCarrier can now be detected by the GUI even if not available on startup. To enable this feature set <code>/sim/mp-carriers/auto-attach=true</code>.

== AI ==
* New fgcommands <code>add-aiobject</code> and <code>remove-aiobject</code> for adding/removing objects to the AI subsystem.
* New AI aircraft, including 747 Freighter, CRJ900, SR-71, Saab 340.
* Numerous updates to AI traffic schedules and airline liveries.
* Space Shuttle TAEM and approach at KEDW scenario.
* Accurate Britten-Norman Islander performance data, from an Islander pilot.

== Multiplayer ==
* Connection to VATSIM via swift is now available via the GUI.
* FGCom now supports both COM1 and COM2, as well as volume settings.
* The views defined by the user's aircraft (Pilot view, Helicopter view, Tower view etc) can now be used with multiplayer aircraft. Viewing a particular multiplayer aircraft is done by clicking in the Pilot List dialogue's "view' column (see the "Multiplayer/Pilot List" menu).
* <code>--disable-hold-short</code> option which allows the user to force a start on the runway when multiplayer is enabled. This option should be used with caution - it can give other pilots and ATC a nasty fright to find an aircraft materialize on the runway!
* Support for recording multiplayer data

== Nasal Scripting ==
* Configurable load order for core Nasal modules.
* Improvements and bug fixes to Emesary, the messaging interface.
* Improvements to the core libraries.
* Garbage collection improvements to reduce frame stuttering
* Re-loadable Nasal modules
* Canvas EFIS framework
* New methods in Canvas Image to set colors of pixels in the image.

== Aircraft ==
* FG1000 Glass Panel improvements include user-configurable VFR transponder codes, volume controls, new fascia, UI is now resizeable, support for custom SVG files (e.g. for a G500). The FG1000 is now available on the Cessna 182T, J3 Cub, Diamond DA40.
* Improved glider vario instrument.
* New Aircraft:
** Airbus A320 - airliner
** Alisport Silent2Electro - glider with electric sustainer motor
** Bombardier Q400 DHC8-402 - shorthaul turboprop airliner
** Breguet Atlantic BR 1150 - long-range maritime patrol aircraft
** Cessna 140 - GA aircraft
** Cessna 208B Caravan - short range passenger, freighter and utility aircraft
** Cirrus SR22T - GA aircraft
** Diamond DA40 NG - GA aircraft, including FG1000 glass panel cockpit
** Diamond DA62 Twinstar- Twin engine GA aircraft
** Diamond HK36 Super Dimona - motorglider
** Dornier DO 28 Skyservant - Twin engine STOL utility aircraft
** Douglas TBD Devastator - WWII Torpedo bomber
** Draco Wilga - turboprop taildragger bush plane
** Fokker T.V - twin engine bomber
** Glasfluegel H201B Standard Libelle - glider
** Grumman F11-Tiger - carrier-based fighter
** Grumman HU-16A Albatross - twin engine amphibian
** Petliakov PE-8 (Ant-42/TB-7) - WWII bomber
** Piper PA28-161 Warrior II - GA aircraft
** Pipistrel Alpha Electro - electric training aircraft
** Pipistrel Taurus Electro G2.5 - glider with electric sustainer motor
** Rolladen Schneider LS8sc neo - standard glider with electric sustainer motor
** Robin DR400 Ecoflyer - GA Aircraft
** Scheibe Bergfalke II/55 - training glider
** Schempp-Hirth Arcus S - high performance glider
** Schleicher Ka6(CR) "Rhoensegler" - training glider
** SEPECAT Jaguar GR.1 - jet attack aircraft
** SUMPAC - Human powered airplane
** Supermarine Swift - jet fighter
** Yak 52 - training aircraft
* Major updates to over 70 aircraft. Including 737-100, 737-300, 777, A-26-Invader, AR-234, ASG29, ASK13, ASK21, Aero-Commander, Aichi-D3A, B-17, B-24-Liberator, B-25, Bombardier-415, CH750STOL, CRJ700-family, Cessna-208-Caravan, Cessna Citation II, Cessna-L19, Cirrus-SR22, Concorde, DO-228, DO-335, Diamond-Da40, Diamond-Da42, Dragonfly, Embraer-ERJ-145, F-15, Fairchild-Metroliner, Falcon-50, Fokker-S-11, Fw200, H4-Hercules, Harrier-GR3, Horten-Ho-IX, Hughes-XF11, J3Cub, JA37, JAS39-Gripen, Jaguar, LS4, Lancair-235, Lionceau, Lockheed-NF104A, Lockheed-P38, ME-262, Mirage-2000, MirageIV, Northrop-xb35, PC-12, Piaggio-P166, Piper-PA-28, Potez-630, R44, Ryan-Navion, SIAI-Marchetti-SF.260, Socata-ST10, SpaceShuttle, Starship, Tecnam-P2006T, UH-1, Yak-18T, Zlin-50lx, an24b, bluebird, c182s, dhc1, f-14b, f16.

== Miscellaneous ==
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Map dialog displays heliports and allows configurable cursor key panning
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* Change screenshot filename to have date and time
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.1=
Changes since the 2020.1 preview release include:
* Various launcher improvements including a Welcome screen and a keyboard shortcut ({{key press|Ctrl|F}}) to Fly!
* Improved regional definitions for California, Iceland and Northern Brazil and better grass textures.
* Implemented tidal movement for littoral areas.
* New AI model for the 747 Freighter, and numerous AI livery and traffic updates.
* Updates to the FG1000 glass panel display including configurable VFR transponder codes, volume controls, a new fascia, resizeable UI and support for custom SVG files.
* A hangar full of new aircraft: HU-16A-Albatross, LS8, Embraer-ERJ-145, Cessna 208B Caravan, PZL 104 wilga 2000 Draco, Scheibe Bergfalke, Taurus, f16, Dornier Do 28 Skyservant, Petliakov Pe 8 (Ant 42/DB 7), Grumman F.11 Tiger
* Updates to a large number of aircraft including CRJ700, Dragonfly, Mirage 2000, Jaguar GR1, H4 Hercules, JA37, Supermarine Swift, A320, Cirrus-SR22, Cessna Citation, J3Cub
* Updated Chinese, Dutch, French, German, Italian, Polish and Slovak translations.
* Faster Terrasync: Download a tarball of airport information on first start and only check for updates every 24 hours rather than every simulator run.
* GPS fly-by mode
* Sentry.io integration to provide centralized crash reporting.
* New thread safe particle manager -- should reduce random crashes around particles.

=Updates since 2020.3.0=

As 2020.3 is a long term supported release, there are ongoing bug-fixes and small improvements happening, based on user feedback and automatic reporting of crashes and issues. Significant fixes are listed below:

==2020.3.1==
* Add help page to the launcher
* Fix handling of helipads at heliports
* Migrate installed aircraft packages, when migrating to the new stable catalog
* TerraSync: improve startup performance on Windows

==2020.3.2==
* TerraSync waits for Models to be completely sync-ed, to avoid missing models when starting
* First-run screen: add a 'scroll to the bottom' hint icon
* Tides fixes from Erik Hofman
* Use nicer scrollbar for the launcher, fixes some issue with long aircraft lists
* Support Apt.dat v1000 comm frequencies
* Fix an ATC crash when repositioning
* Many translations fixes identified by Michael Danilov
* Greatly improve the Brazilian cerradio areas (near SBMQ)
* Russian translation updates
* Iceland materials fixes

==2020.3.3==
* Fix accidental mouse picks while using a right-mouse-drag to look around
* Fix the download location we recommend in the 'setup root' dialog

==2020.3.4==
* Handle more METAR strings correctly, including wind sensor failures
* Fix airmass velocity being applied to sub-models twice (eg, when dropping payloads in a cross-wind)
* Fix crash on shutdown in the properties code
* Spanish translation updates
* Disable flights to EGEL to avoid crashes in traffic code

==2020.3.5==
* Change default Windows download location to %USERS%\FlightGear\Downloads, to avoid problems with Windows Defender blocking un-trusted applications from writing to Documents, which was the previous location.
* Fix a crash when returning to FlightGear from another application and scrolling or clicking
* Avoid crashing with UIUC-based aircraft such as the Wright Flyer
* Fix a crash on macOS when a joystick failed to open
* Update the macOS application icon
* Fix Nasal crash on reset
* Canvas: allow anisotropic filtering
* Larger, improved moon texture
* UFO speed goes to 11
* Fix taxiway markings disappearing in specific graphics settings

==2020.3.6==
* Fixed crash downloading the default aircraft catalog
* Fix a hang starting at scenery in the ocean
* Fix incorrect sky & cockpit rendering with certain METAR values
* Add getting-started hints to the launcher (English only for now)
* Fix Shuttle AI scenarios
* Improvements to flight-planning mode
* Sun / moon scaling fixes
* Fix initial position of submodels
* macOS: warn if running with app translocation
* Windows: detect missing OpenGL drivers
* Fix UIUC FDM crashes
* Fix crash with invalid view numbers
* Catch FDM NaN errors more gracefully
* KAP-140 approach mode improvements
* Traffic+AI livery updates

== 2020.3.7 ==
* Enable OSM2City buildings via TerraSync for the whole planet
* C172 bug-fixes and updates
* Improved regional material definitions for Europe, California
* Allow chat box to be re-positioned
* Fix crashes related to particle systems
* Fix selection of time-zone around Beijing
* Fix display of non-Latin1 strings in Canvas displays
* Fix Multi-player mode runway-start logic to select hold-short position correctly
* macOS: fix crash on text with certain fonts
* Fix launcher language selection when the UI language include a script specifier (eg zh-Hans-CN)
* Fix aircraft-id property when loading from a hangar ( https://sourceforge.net/p/flightgear/codetickets/2502/ )
* Improve checks for out-of-date Intel Graphics drivers on Windows

== 2020.3.8 ==
* Fix behaviour of <code><local></code> particle systems
* Fix autumn tree appearance

== 2020.3.9 ==
* Fix crash in Swift
* Corrections to MP protocol timing
* Correct URL to FGData
* Fix bug in cache reload dialog
* Improvements to ATC dialog to display frequencies with 3 decimal places correctly
* Improve material definitions for Africa, Mediterranean regions
* Add updated ocean and water visual effects

== 2020.3.10 ==
* Transponder: make standby mode work
* Launcher: pick up scenery and aircraft paths from the command line
* Launcher: store locations differently, to avoid problems when running multiple FlightGear versions and switching between them.
* Launcher: add 'restart on quit' option
* Fix NavCache errors loading ShapeFile data
* Fix NavCache errors when running multiple copies of FlightGear

== 2020.3.11 ==
* Fix a crash introduced in 2020.3.10
* Improve error message when no aircraft search paths are available
* Fix a crash with misconfigured traffic taxi routes
* Update AI traffic schedules

== 2020.3.12 ==
* Add aircraft directory name validation
* Add an extra step of antialiasing (8x)
* Add feature allowing aircraft to define custom fonts for osg::Text
* Add generic combined ALS procedural lights and Compositor lights
* Add new regional materials for Australia
* Fix Basic Weather producing invalid pressure altitudes
* Fix bug in path searching for previews
* Fix bug in sound system when approaching max-dist range
* Fix crashes after reset
* Fix crash when AI aircraft has invalid destination runway
* Fix Mapstructure error in RTE layer
* Fix <code>--view-offset</code> to use the correct property
* HUD: make vertical gauges look the same as horizontal ones
* Improved Russian and Spanish translations
* Miscellaneous improvements to weather dialog
* Property browser: display values for folders in verbose mode
* Route manager: select correct waypoint when duplicate waypoints exist
* Update AI traffic schedules and add new AI models

== 2020.3.13 ==
* Fix for the disappearing MP pilot list
* Fix JSBsim linear actuators behaving badly in certain conditions

== 2020.3.14 ==
* Support for add-on paths
* Instant audio queue
* Allow canvas dialogs to not grab focus away from FG (more like how focus in PUI dialogs behaves)

== 2020.3.15 ==
* Fix radio audio morse issue.

== 2020.3.16 ==
* Fix audio indent issue.

== 2020.3.17 ==
* Navradio: disable low-pass filter when changing selected freq or leaving GPS slave mode. When the selected frequency is changed or when leaving GPS slave mode, disable the low-pass filter applied to signal quality.
* Navradio: fix regression and optimize older code. Fix a little regression introduced in previous commit. Add: changing the standby frequency disabled the low-pass filter for the next call to updateReceiver(); this must happen when the selected frequency is changed but not when the standby frequency is changed.
* AP input: add property-path support to Inputs. Allow making the AP source indirect (via a string property), so that the actual source property can be configured or adjusted from a -set.xml, or at runtime.
* Replace displaying in Launcher `--on-ground=false` to `--in-air` for on final. The option`--on-ground=false` doesn't exist which can be misleading.

== 2020.3.18 ==

* Added photoscenery capability.
* New basic autopilot system.
* Fix crash with a 'between' type constraint in Navigraph procedure files

== 2020.3.19 ==
* Add AI submodel collision
* Fix crash with invalid METAR strings
* Fix rendering bug where OSM buildings appeared blue under certain graphics settings

== References ==
{{Appendix}}

[[Category:FlightGear changelogs‎]]
[[pl:Changelog_2020.3]]
[[Zh:2020.3]]

User:Fahim Dalvi/Compiling on Apple Silicon

2023-10-18T17:48:12Z

Fahim Dalvi:

Dump of initial commands, to be improved...

== Prerequisites: ==
* `brew` for packages (https://brew.sh)

== Building FlightGear: ==
Move to your directory of choice.

=== Setup the build directory ===
<syntaxhighlight lang="bash">
mkdir build
PREFIX=`pwd`/build
</syntaxhighlight>

=== Clone and compile `openscenegraph` ===
<syntaxhighlight lang="bash">
brew install cmake freetype

git clone --branch fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg-custom-36
cd osg-custom-36
mkdir build.osg
cd build.osg
cmake \
-D CMAKE_BUILD_TYPE="Release"\
-D CMAKE_CXX_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_C_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_INSTALL_PREFIX:PATH="${PREFIX}"\
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOLEAN="true" -G "Unix Makefiles" ..
make -j 8
make install
cd ../..
</syntaxhighlight>

=== Clone and compile `simgear` ===
<syntaxhighlight lang="bash">
brew install boost

git clone --branch next https://git.code.sf.net/p/flightgear/simgear simgear
cd simgear
mkdir build.simgear
cd build.simgear
cmake \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE=Release \
-G "Unix Makefiles" ..
make -j 8
make install
cd ../..
cp simgear/simgear/math/simd.hxx build/include/simgear/math/
cp simgear/simgear/math/simd_neon.hxx build/include/simgear/math/
cp simgear/simgear/math/simd4x4_neon.hxx build/include/simgear/math/
</syntaxhighlight>

=== Clone and compile `plib` ===
<syntaxhighlight lang="bash">
brew install svn automake
svn checkout https://svn.code.sf.net/p/plib/code/trunk plib
cd plib
./autogen.sh
./configure --disable-pw --disable-sl --disable-psl --disable-ssg --disable-ssgaux --prefix=${PREFIX} CXXFLAGS="-arch arm64 -mmacosx-version-min=13.1" CFLAGS="-arch arm64 -mmacosx-version-min=13.1"
# use of undeclared identifier 'finite'; did you mean 'isfinite'
# Add `#define finite isfinite` to src/sg/sg.cxx
make install
cd ..
</syntaxhighlight>

=== Clone and compile `flightgear` ===
<syntaxhighlight lang="bash">
brew install qt@5
brew install speex speexdsp
brew install dbus libevent # not working for swift yet
git clone --branch next https://git.code.sf.net/p/flightgear/fgdata fgdata
git clone --branch next https://git.code.sf.net/p/flightgear/flightgear flightgear
cd flightgear
</syntaxhighlight>

===== Changes to compile on Apple silicon =====
<syntaxhighlight lang="dpatch">
CMakeLists.txt
@@ -438,7 +438,13 @@ if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "Ap
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG")

- set(SIMD_COMPILER_FLAGS "-msse2 -mfpmath=sse -ftree-vectorize -ftree-slp-vectorize")
+ if (X86 OR X86_64)
+ set(SIMD_COMPILER_FLAGS "-msse2 -mfpmath=sse")
+ endif()
+ set(SIMD_COMPILER_FLAGS "${SIMD_COMPILER_FLAGS} -ftree-vectorize -ftree-slp-vectorize")
+
+ # set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++")
+ # set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
set(WARNING_FLAGS_C "-Wall")
endif()

src/GUI/CocoaHelpers.mm
@@ -35,6 +35,10 @@
#include <Foundation/NSLocale.h>
#include <AppKit/NSAlert.h>

+#if defined(HAVE_QT)
+# include <GUI/QtLauncher.hxx>
+#endif
+
// simgear
#include <simgear/misc/sg_path.hxx>
#include <simgear/debug/logstream.hxx>
@@ -46,10 +50,6 @@
#include <Main/locale.hxx>
#include <Main/globals.hxx>

-#if defined(HAVE_QT)
-# include <GUI/QtLauncher.hxx>
-#endif
-
</syntaxhighlight>

===== Continue with compilation =====
<syntaxhighlight lang="bash">
mkdir build.flightgear
cd build.flightgear
cmake \
-E env CFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" CXXFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" \
cmake \
-DFG_DATA_DIR=../../fgdata \
-DSYSTEM_SPEEX=ON \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE="Release" \
-DQt5_DIR=$(brew --prefix qt5)/lib/cmake/Qt5 \
-DWITH_FGPANEL=false \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-G "Unix Makefiles" ..
make -j 4 install
cd ../..
</syntaxhighlight>

== Running compiled FG ==
<syntaxhighlight lang="bash">
# Make sure you are in the top level directory (with subdirectories like `build`, `flightgear`, `simgear` etc)

DYLD_LIBRARY_PATH=`pwd`/build/lib:$DYLD_LIBRARY_PATH FG_HOME=`pwd`/fghome build/fgfs.app/Contents/MacOS/fgfs --fg-root=`pwd`/fgdata/ --launcher
</syntaxhighlight>

User:Fahim Dalvi/Compiling on Apple Silicon

2023-10-18T17:47:28Z

Fahim Dalvi:

Dump of initial commands, to be improved...

== Prerequisites: ==
* `brew` for packages (https://brew.sh)

== Building FlightGear: ==
Move to your directory of choice.

=== Setup the build directory: ===
<syntaxhighlight lang="bash">
mkdir build
PREFIX=`pwd`/build
</syntaxhighlight>

=== Clone and compile `openscenegraph`: ===
<syntaxhighlight lang="bash">
brew install cmake freetype

git clone --branch fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg-custom-36
cd osg-custom-36
mkdir build.osg
cd build.osg
cmake \
-D CMAKE_BUILD_TYPE="Release"\
-D CMAKE_CXX_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_C_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_INSTALL_PREFIX:PATH="${PREFIX}"\
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOLEAN="true" -G "Unix Makefiles" ..
make -j 8
make install
cd ../..
</syntaxhighlight>

=== Clone and compile `simgear`: ===
<syntaxhighlight lang="bash">
brew install boost

git clone --branch next https://git.code.sf.net/p/flightgear/simgear simgear
cd simgear
mkdir build.simgear
cd build.simgear
cmake \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE=Release \
-G "Unix Makefiles" ..
make -j 8
make install
cd ../..
cp simgear/simgear/math/simd.hxx build/include/simgear/math/
cp simgear/simgear/math/simd_neon.hxx build/include/simgear/math/
cp simgear/simgear/math/simd4x4_neon.hxx build/include/simgear/math/
</syntaxhighlight>

=== Clone and compile `plib`: ===
<syntaxhighlight lang="bash">
brew install svn automake
svn checkout https://svn.code.sf.net/p/plib/code/trunk plib
cd plib
./autogen.sh
./configure --disable-pw --disable-sl --disable-psl --disable-ssg --disable-ssgaux --prefix=${PREFIX} CXXFLAGS="-arch arm64 -mmacosx-version-min=13.1" CFLAGS="-arch arm64 -mmacosx-version-min=13.1"
# use of undeclared identifier 'finite'; did you mean 'isfinite'
# Add `#define finite isfinite` to src/sg/sg.cxx
make install
cd ..
</syntaxhighlight>

=== Clone and compile `flightgear`: ===
<syntaxhighlight lang="bash">
brew install qt@5
brew install speex speexdsp
brew install dbus libevent # not working for swift yet
git clone --branch next https://git.code.sf.net/p/flightgear/fgdata fgdata
git clone --branch next https://git.code.sf.net/p/flightgear/flightgear flightgear
cd flightgear
</syntaxhighlight>

===== Changes to compile on Apple silicon =====
<syntaxhighlight lang="dpatch">
CMakeLists.txt
@@ -438,7 +438,13 @@ if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "Ap
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG")

- set(SIMD_COMPILER_FLAGS "-msse2 -mfpmath=sse -ftree-vectorize -ftree-slp-vectorize")
+ if (X86 OR X86_64)
+ set(SIMD_COMPILER_FLAGS "-msse2 -mfpmath=sse")
+ endif()
+ set(SIMD_COMPILER_FLAGS "${SIMD_COMPILER_FLAGS} -ftree-vectorize -ftree-slp-vectorize")
+
+ # set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++")
+ # set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
set(WARNING_FLAGS_C "-Wall")
endif()

src/GUI/CocoaHelpers.mm
@@ -35,6 +35,10 @@
#include <Foundation/NSLocale.h>
#include <AppKit/NSAlert.h>

+#if defined(HAVE_QT)
+# include <GUI/QtLauncher.hxx>
+#endif
+
// simgear
#include <simgear/misc/sg_path.hxx>
#include <simgear/debug/logstream.hxx>
@@ -46,10 +50,6 @@
#include <Main/locale.hxx>
#include <Main/globals.hxx>

-#if defined(HAVE_QT)
-# include <GUI/QtLauncher.hxx>
-#endif
-
</syntaxhighlight>

===== Continue with compilation =====
<syntaxhighlight lang="bash">
mkdir build.flightgear
cd build.flightgear
cmake \
-E env CFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" CXXFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" \
cmake \
-DFG_DATA_DIR=../../fgdata \
-DSYSTEM_SPEEX=ON \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE="Release" \
-DQt5_DIR=$(brew --prefix qt5)/lib/cmake/Qt5 \
-DWITH_FGPANEL=false \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-G "Unix Makefiles" ..
make -j 4 install
cd ../..
</syntaxhighlight>

== Running compile FG: ==
<syntaxhighlight lang="bash">
# Make sure you are in the top level directory (with subdirectories like `build`, `flightgear`, `simgear` etc)

DYLD_LIBRARY_PATH=`pwd`/build/lib:$DYLD_LIBRARY_PATH FG_HOME=`pwd`/fghome build/fgfs.app/Contents/MacOS/fgfs --fg-root=`pwd`/fgdata/ --launcher
</syntaxhighlight>

User:Fahim Dalvi/Compiling on Apple Silicon

2023-10-15T06:23:47Z

Fahim Dalvi:

Dump of initial commands, to be improved...

<syntaxhighlight lang="bash">
mkdir build
PREFIX=`pwd`/build

brew install cmake freetype

git clone --branch fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg-custom-36
cd osg-custom-36
mkdir build.osg
cd build.osg
cmake \
-D CMAKE_BUILD_TYPE="Release"\
-D CMAKE_CXX_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_C_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_INSTALL_PREFIX:PATH="${PREFIX}"\
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOLEAN="true" -G "Unix Makefiles" ..
make -j 8
make install
cd ../..

brew install boost

git clone --branch next https://git.code.sf.net/p/flightgear/simgear simgear
cd simgear
mkdir build.simgear
cd build.simgear
cmake \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE=Release \
-G "Unix Makefiles" ..
make -j 8
make install
cd ../..
cp simgear/simgear/math/simd.hxx build/include/simgear/math/
cp simgear/simgear/math/simd_neon.hxx build/include/simgear/math/
cp simgear/simgear/math/simd4x4_neon.hxx build/include/simgear/math/

# Plib
brew install svn automake
svn checkout https://svn.code.sf.net/p/plib/code/trunk plib
cd plib
./autogen.sh
./configure --disable-pw --disable-sl --disable-psl --disable-ssg --disable-ssgaux --prefix=${PREFIX} CXXFLAGS="-arch arm64 -mmacosx-version-min=13.1" CFLAGS="-arch arm64 -mmacosx-version-min=13.1"
# use of undeclared identifier 'finite'; did you mean 'isfinite'
# Add `#define finite isfinite` to src/sg/sg.cxx
make install
cd ..

# Flightgear
brew install qt@5
brew install speex speexdsp
brew install dbus libevent # not working for swift yet
git clone --branch next https://git.code.sf.net/p/flightgear/fgdata fgdata
git clone --branch next https://git.code.sf.net/p/flightgear/flightgear flightgear
cd flightgear

# Changes to compile on Apple silicon

CMakeLists.txt
@@ -438,7 +438,13 @@ if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "Ap
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG")

- set(SIMD_COMPILER_FLAGS "-msse2 -mfpmath=sse -ftree-vectorize -ftree-slp-vectorize")
+ if (X86 OR X86_64)
+ set(SIMD_COMPILER_FLAGS "-msse2 -mfpmath=sse")
+ endif()
+ set(SIMD_COMPILER_FLAGS "${SIMD_COMPILER_FLAGS} -ftree-vectorize -ftree-slp-vectorize")
+
+ # set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++")
+ # set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
set(WARNING_FLAGS_C "-Wall")
endif()

src/GUI/CocoaHelpers.mm
@@ -35,6 +35,10 @@
#include <Foundation/NSLocale.h>
#include <AppKit/NSAlert.h>

+#if defined(HAVE_QT)
+# include <GUI/QtLauncher.hxx>
+#endif
+
// simgear
#include <simgear/misc/sg_path.hxx>
#include <simgear/debug/logstream.hxx>
@@ -46,10 +50,6 @@
#include <Main/locale.hxx>
#include <Main/globals.hxx>

-#if defined(HAVE_QT)
-# include <GUI/QtLauncher.hxx>
-#endif
-

mkdir build.flightgear
cd build.flightgear
cmake \
-E env CFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" CXXFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" \
cmake \
-DFG_DATA_DIR=../../fgdata \
-DSYSTEM_SPEEX=ON \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE="Release" \
-DQt5_DIR=$(brew --prefix qt5)/lib/cmake/Qt5 \
-DWITH_FGPANEL=false \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-G "Unix Makefiles" ..

-DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
</syntaxhighlight>

User:Fahim Dalvi/Compiling on Apple Silicon

2023-10-12T13:58:24Z

Fahim Dalvi:

Dump of initial commands, to be improved...

<syntaxhighlight lang="bash">
mkdir build
PREFIX=`pwd`/build

brew install cmake freetype

git clone --branch fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg-custom-36
cd osg-custom-36
mkdir build.osg
cd build.osg
cmake \
-D CMAKE_BUILD_TYPE="Release"\
-D CMAKE_CXX_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_C_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_INSTALL_PREFIX:PATH="${PREFIX}"\
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOLEAN="true" -G "Unix Makefiles" ..
make -j 8
make install
cd ../..

brew install boost

git clone --branch next https://git.code.sf.net/p/flightgear/simgear simgear
cd simgear
mkdir build.simgear
cd build.simgear
cmake \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE=Release \
-G "Unix Makefiles" ..
make -j 8
make install
cd ../..

# Plib
brew install svn automake
svn checkout https://svn.code.sf.net/p/plib/code/trunk plib
cd plib
./autogen.sh
./configure --disable-pw --disable-sl --disable-psl --disable-ssg --disable-ssgaux --prefix=${PREFIX} CXXFLAGS="-arch arm64 -mmacosx-version-min=13.1" CFLAGS="-arch arm64 -mmacosx-version-min=13.1"
# use of undeclared identifier 'finite'; did you mean 'isfinite'
# Add `#define finite isfinite` to src/sg/sg.cxx
make install
cd ..

# Flightgear
brew install qt@5
brew install speex speexdsp
brew install dbus libevent # not working for swift yet
git clone --branch next https://git.code.sf.net/p/flightgear/fgdata fgdata
git clone --branch next https://git.code.sf.net/p/flightgear/flightgear flightgear
cd flightgear

# Changes to compile on Apple silicon

CMakeLists.txt
@@ -438,7 +438,13 @@ if (CMAKE_CXX_COMPILER_ID STREQUAL "Clang" OR CMAKE_CXX_COMPILER_ID STREQUAL "Ap
set(CMAKE_CXX_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG")
set(CMAKE_C_FLAGS_RELWITHDEBINFO "-O3 -g -DNDEBUG")

- set(SIMD_COMPILER_FLAGS "-msse2 -mfpmath=sse -ftree-vectorize -ftree-slp-vectorize")
+ if (X86 OR X86_64)
+ set(SIMD_COMPILER_FLAGS "-msse2 -mfpmath=sse")
+ endif()
+ set(SIMD_COMPILER_FLAGS "${SIMD_COMPILER_FLAGS} -ftree-vectorize -ftree-slp-vectorize")
+
+ # set(CMAKE_XCODE_ATTRIBUTE_CLANG_CXX_LIBRARY "libc++")
+ # set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=libc++")
set(WARNING_FLAGS_C "-Wall")
endif()

src/GUI/CocoaHelpers.mm
@@ -35,6 +35,10 @@
#include <Foundation/NSLocale.h>
#include <AppKit/NSAlert.h>

+#if defined(HAVE_QT)
+# include <GUI/QtLauncher.hxx>
+#endif
+
// simgear
#include <simgear/misc/sg_path.hxx>
#include <simgear/debug/logstream.hxx>
@@ -46,10 +50,6 @@
#include <Main/locale.hxx>
#include <Main/globals.hxx>

-#if defined(HAVE_QT)
-# include <GUI/QtLauncher.hxx>
-#endif
-

mkdir build.flightgear
cd build.flightgear
cmake \
-E env CFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" CXXFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" \
cmake \
-DFG_DATA_DIR=../../fgdata \
-DSYSTEM_SPEEX=ON \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE="Release" \
-DQt5_DIR=$(brew --prefix qt5)/lib/cmake/Qt5 \
-DWITH_FGPANEL=false \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-G "Unix Makefiles" ..

-DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
</syntaxhighlight>

User:Fahim Dalvi/Compiling on Apple Silicon

2023-10-12T13:53:29Z

Fahim Dalvi:

User:Fahim Dalvi/Compiling on Apple Silicon

2023-10-12T13:35:17Z

Fahim Dalvi:

Dump of initial commands, to be improved...

<syntaxhighlight lang="bash">
git clone --branch fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg-custom-36
mkdir build.osg
cd build.osg
cmake \
-D CMAKE_BUILD_TYPE="Release"\
-D CMAKE_CXX_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_C_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_INSTALL_PREFIX:PATH="${PREFIX}"\
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOLEAN="true" -G "Unix Makefiles" ..
make -j 8
make install
cd ../..

brew install boost

git clone --branch next https://git.code.sf.net/p/flightgear/simgear simgear
cd simgear
mkdir build.simgear
cd build.simgear
cmake \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE=Release \
-G "Unix Makefiles" ..
make -j 8

cmake \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE=Release \
-G "Unix Makefiles" ..
make -j 4

make install

# Plib
svn checkout https://svn.code.sf.net/p/plib/code/trunk plib
cd plib
./autogen.sh
./configure --disable-pw --disable-sl --disable-psl --disable-ssg --disable-ssgaux --prefix=${PREFIX} CXXFLAGS="-arch arm64 -mmacosx-version-min=13.1" CFLAGS="-arch arm64 -mmacosx-version-min=13.1"
# use of undeclared identifier 'finite'; did you mean 'isfinite'
make install
cd ..

# Flighrgear
brew install --cask qt@5
brew install speex speexdsp
brew install dbus libevent # not working for swift yet
git clone --branch next https://git.code.sf.net/p/flightgear/flightgear flightgear
cd flightgear
mkdir build.flightgear
cd build.flightgear
cmake \
-E env CFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" CXXFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" \
cmake \
-DFG_DATA_DIR=/Users/devmachine/Desktop/src/fgdata \
-DSYSTEM_SPEEX=ON \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE="Release" \
-DQt5_DIR=$(brew --prefix qt5)/lib/cmake/Qt5 \
-DWITH_FGPANEL=false \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-G "Unix Makefiles" ..

-DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
</syntaxhighlight>

User:Fahim Dalvi/Compiling on Apple Silicon

2023-10-12T13:33:06Z

Fahim Dalvi: Created page with "Dump of initial commands, to be improved... git clone --branch fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg-custom-36 mkdir build.osg cd build.osg cmake \ -D CMAKE_..."

Dump of initial commands, to be improved...

git clone --branch fgfs-osg-36-1 https://github.com/zakalawe/osg.git osg-custom-36
mkdir build.osg
cd build.osg
cmake \
-D CMAKE_BUILD_TYPE="Release"\
-D CMAKE_CXX_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_C_FLAGS_RELEASE="-O3 -pipe"\
-D CMAKE_INSTALL_PREFIX:PATH="${PREFIX}"\
-D CMAKE_INSTALL_RPATH_USE_LINK_PATH:BOOLEAN="true" -G "Unix Makefiles" ..
make -j 8
make install
cd ../..

brew install boost

git clone --branch next https://git.code.sf.net/p/flightgear/simgear simgear
cd simgear
mkdir build.simgear
cd build.simgear
cmake \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE=Release \
-G "Unix Makefiles" ..
make -j 8

cmake \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE=Release \
-G "Unix Makefiles" ..
make -j 4

make install

# Plib
svn checkout https://svn.code.sf.net/p/plib/code/trunk plib
cd plib
./autogen.sh
./configure --disable-pw --disable-sl --disable-psl --disable-ssg --disable-ssgaux --prefix=${PREFIX} CXXFLAGS="-arch arm64 -mmacosx-version-min=13.1" CFLAGS="-arch arm64 -mmacosx-version-min=13.1"
# use of undeclared identifier 'finite'; did you mean 'isfinite'
make install
cd ..

# Flighrgear
brew install --cask qt@5
brew install speex speexdsp
brew install dbus libevent # not working for swift yet
git clone --branch next https://git.code.sf.net/p/flightgear/flightgear flightgear
cd flightgear
mkdir build.flightgear
cd build.flightgear
cmake \
-E env CFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" CXXFLAGS="-Wno-deprecated-declarations -Wno-inconsistent-missing-override" \
cmake \
-DFG_DATA_DIR=/Users/devmachine/Desktop/src/fgdata \
-DSYSTEM_SPEEX=ON \
-DCMAKE_OSX_ARCHITECTURES="arm64" \
-DCMAKE_OSX_DEPLOYMENT_TARGET=13.1 \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_TYPE="Release" \
-DQt5_DIR=$(brew --prefix qt5)/lib/cmake/Qt5 \
-DWITH_FGPANEL=false \
-DCMAKE_CXX_STANDARD=17 \
-DCMAKE_CXX_STANDARD_REQUIRED=ON \
-DCMAKE_CXX_EXTENSIONS=OFF \
-G "Unix Makefiles" ..

-DCMAKE_OSX_SYSROOT=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/

Howto:Create WS3.0 terrain

2023-04-20T13:39:09Z

Fahim Dalvi: Change references to docker image (it has been renamed to fix a typo)

{{WS30 Navbar}}
This article provides instructions on how to generate base WS3.0 terrain.

WS3.0 terrain consists of two parts:

# A landclass texture draped over an elevation model. This is the terrain mesh.
# Line features such as roads, railways and rivers. This is draped over the terrain mesh at runtime.

== Getting the base data ==
First, you need two pieces of data for the scenery area you are generating:

# An elevation model (aka DEM). Use of the "NASADEM" with 30m resolution is recommended, and is available from [https://lpdaac.usgs.gov/products/nasadem_hgtv001/ here], and with an interactive browser [https://search.earthdata.nasa.gov/search here].
# Landclass data showing what type of terrain is at each point of the surface. This is often either a Raster Geotiff (effectively a texture), or vector data. For Europe, use of [https://land.copernicus.eu/pan-european/corine-land-cover/clc2018 CORINE] is recommended. For the USA NLCD is recommended
Put these files into a <code>data</code> directory and create an <code>output</code> directory next to it. This is where the scenery will be generated..

== Pre-processing the Elevation Model ==
If you are using NASADEM, then the elevation model is already using WGS84 and is ready to use as-is.

If you are using another elevation model, then you may need to re-project it using QGIS/gdalwarp to the WGS84 CRS (aka EPSG:4326).

== Pre-processing the Landclass Data ==
For any landclass data we need to ensure the data is in the correct format. That means:

# Uses the WGS84 Coordinate Reference System. The ensures that the terrain generation step is efficient.
# Is a Raster (geotiff) rather than Vector data. This raster will become the texture on the terrain that the terrain shaders do their magic on.
# Has the correct landclass values for each terrain type. Different landclass systems use different values. At present we use the CORINE values, defined in [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml].

Below is a quick table showing what steps you need to take for common landclass data sources.
{| class="wikitable"
|+
!Landclass Data
!Warp to WGS84 required?
!Landclass re-classification Required?
!Raster Simplification Required?
!Conversion to Raster Required?
|-
|CORINE Raster
|Yes
|No
|No
|No
|-
|CORINE Vector
|Yes
|Yes
|No
|Yes
|-
|NLCD
|No
|Yes
|Yes
|No
|}
The easiest way to do these operations is using QGIS, which is available for most platforms. If you are scripting a toolchain, the QGIS tools include command-line equivalents for all commands.

When using QGIS, set the Project CRS to WGS84 (aka EPSG:4326). You can then add layers of Raster or Vector data from files from the <code>Layer->Add Layer</code> menu. When performing any operations, <u>always</u> write out the data to a real file so you can go back to it later. Disk space is cheap :).

=== Warping Raster Layers to WGS84 ===
This is applicable to CORINE Raster data

You can warp a raster layer to a different CRS using the Raster->Projections-Warp (Reproject) tool.

Select the following options in the dialog:

* Input Layer - Check you have selected the correct layer. The CRS is shown at the right.
* Target CRS - set to <code>EPSG:4326 - WGS84</code>, which should be your project CRS.
* Resampling Method to Use - Nearest Neighbour. (Landclass data is not like normal images. You don't want to interpolate between values.)
* Nodata value for output bands - 0.0 (This means that any data at the edges will be Ocean, usually a reasonable default)
* Advanced Parameters - No Compression
* Output data type - Byte
* Reprojected - Choose a target filename

Alternatively you can do this step from the commandline.
gdalwarp -t_srs EPSG:4326 -dstnodata 0.0 -r near -ot Byte -of GTiff -co COMPRESS=NONE -co BIGTIFF=IF_NEEDED /home/stuart/FlightGear/VPB/data/CORINE/u2018_clc2018_v2020_20u1_raster100m/DATA/U2018_CLC2018_V2020_20u1.tif /home/stuart/FlightGear/VPB/data/scratch/corine_WGS84.tif

=== Warping Vector Layers to WGS84 ===
You can warp a vector layer using Vector->Data Management Tools->Reproject Layer.

Set the following options in the dialog:

* Input Layer - Check you have selected the correct layer. The CRS is shown at the right.
* Target CRS - set to <code>EPSG:4326 - WGS84</code>, which should be your project CRS.
* Reprojected - Choose a target filename

=== Reclassifying Vector Layers ===
For CORINE vector data in particular, the attributes used in the vector data are not the same as those used by the CORINE Raster data. So we need to create a new attribute on the data.
[[File:Field Calculator.png|thumb|QGIS Field Calculator]]
To do this

* Select <code>Layer->Open Attribute Table</code>. You should see a table with multiple columns. Each row represents a feature in the data.
* Click on <code>New Field</code> (Ctrl+W) and create a new field called Landclass of type "Whole Number (Integer)". This will create a new column which we will populate with the correct landclass data
* Click on the <code>Open Field Calculator</code> button (Ctrl + I). (If you get an error about only being able to create Virtual fields, go back to the Layer menu, export it and open the exported file).
* Select the following options:
** Update Existing Field
** Select the Landclass field you just created.
** Copy the contents of https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/mappings/corine_vector.txt into the Expression box. This is just some simple code to set the attribute correctly. The code should be correct for CORINE vector data. If your data is from other sources you will need to work out how you want to map your source data landclasses to the CORINE ones. [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml] can be used as a guide.
* Select <code>OK</code>. You should see that your landclass column is now populated with the landclass data.
* Select <code>Layer->Save Layer Edits</code> to save you changes

=== Creating a Raster from a Vector Layer ===
To create a Raster from a Vector Layer select <code>Raster->Conversion->Rasterize (Vector to Raster)</code>.
[[File:QGIS Rasterize (Vector to Raster).png|thumb|Creating a Raster from a Vector Layer - QGIS Rasterize]]
Select the following options:

* Input Layer - correct layer, check CRS
* Field to use for burn-in value - select the Landclass column you created above.
* Output raster size units. This is going to set the resolution of your raster. You can work out the resolution in two different ways:
** Select "Georeferenced units" and determine how many degrees each pixel is in latitude and longitude.
** Select "Pixels" and determine the size of raster you want in pixels. [https://www.nhc.noaa.gov/gccalc.shtml This] is a good calculator to help.
* Width/Horizontal Resolution. Enter the values you've calculated for the horizontal resolution (longitudinal), or the width of the raster
* Height/Vertical Resolution. Enter the values you've calculated for the vertical resolution (latitude or the height of the raster
* Output extent - Select an option from the box on the right. You can edit the text afterwards.
* Assign a specific nodata value to output bands - Select 0.0 for Ocean. CORINE vector data in particular has a lot of nodata for Oceans
* Advanced Parameters - No Compression
* Output data type - Byte
* Rasterized - Select a new filename

=== Simplifying a Raster Layer ===
Some Raster Landclass data (NLCD included) has too much noise - in particular large US highway systems are identified as Urban areas.

To smooth it out we can use the GRASS <code>n.neighbors</code> function from the Processing Toolbox in QGIS.

Select the following options:

* Input Layer - correct layer, check CRS
* Neighborhood operation - median. (This is not a normal image, so using an average will result in weird values)
* Neighborhood size - 5.
* Neighbors - Select a new filename.

=== Reclassifying a Raster Layer ===
WS3.0 uses CORINE landclass values. If using data from other sources it needs to be reclassified to the correct values.

To do this select <code>GRASS->Raster->r.reclass</code> from the Processing Toolbox.

Select the following options:

* Input Raster Layer - correct layer, check CRS
* Reclass rules text - copy in the contents of https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/mappings/nlcd2019.txt. Or an appropriate mapping from your landclass data to CORINE. Note that you can also reference a file using the "File containing reclass rules" option. Note a mapping of 22 24 = 1 is the same as 22 and 24 = 1. For a range of 22 to 24 use 22 23 24 = 1.
* Reclassified - Select a new filename.

(If this doesn't work a similar function is available in the Processing Toolbox under <code>Raster analysis->Reclassify by table</code>. However this doesn't save your table once you close the dialog, and entries have to be manually entered individually which takes a lot of effort)

=== Step By Step Procedure for Processing NLCD for the USA using the Raster Calculator, Up sampling and GRASS r.neighbors===

We will use a predetermined file naming convention throughout this procedure for simplicity. You can use a naming convention of your choice.

* Step 1 - Re-class from NLCD values to FlightGear values and all man made data to "grasscover" for a clean land cover base.
# Open Raster Calculator
# Under "Output layer" choose a new filename to save the new raster to. We'll use Kansas_reclass-grass.tiff.
# Copy the following into the "Raster Calculator Expression" box. Where Kansas_4326-84@1 is the name of your raw, correct CRS NLCD.

("Kansas_4326-84@1" = 11) * 41 + ("Kansas_4326-84@1" = 12) * 34 + ("Kansas_4326-84@1" = 21) * 26 + ("Kansas_4326-84@1" = 22) * 26 + ("Kansas_4326-84@1" = 23) * 26 + ("Kansas_4326-84@1" = 24) * 26 + ("Kansas_4326-84@1" = 31) * 27 + ("Kansas_4326-84@1" = 41) * 23 + ("Kansas_4326-84@1" = 42) * 24 + ("Kansas_4326-84@1" = 43) * 25 + ("Kansas_4326-84@1" = 51) * 30 + ("Kansas_4326-84@1" = 52) * 29 + ("Kansas_4326-84@1" = 71) * 26 + ("Kansas_4326-84@1" = 72) * 32 + ("Kansas_4326-84@1" = 73) * 31 + ("Kansas_4326-84@1" = 74) * 31 + ("Kansas_4326-84@1" = 75) * 32 + ("Kansas_4326-84@1" = 81) * 18 + ("Kansas_4326-84@1" = 82) * 19 + ("Kansas_4326-84@1" = 90) * 25 + ("Kansas_4326-84@1" = 95) * 35

Click on "OK". When finished you will have a new raster with all man made clutter removed and changed to "grasscover".

* Step 2 - Make a new Urban layer of all all man made clutter.
# Open Raster Calculator
# Under "Output layer" choose a new filename to save the new raster to. We'll use Kansas_urban.tiff.
# Copy the following into the "Raster Calculator Expression" box. Where Kansas_4326-84@1 is the name of your raw, correct CRS NLCD.

("Kansas_4326-84@1" = 21) * 10 + ("Kansas_4326-84@1" = 22) * 10 + ("Kansas_4326-84@1" = 23) * 1 + ("Kansas_4326-84@1" = 24) * 1

Click on "Run". When finished you will have a new raster with only all man made clutter.

* Step 3 - Make a new raster of leaving only towns and larger man made structures.
# Click on the Kansas_urban-only layer so it is the active layer.
# Click on GRASS -> Raster (r.*) -> r.neighbors
# Change the "Neighbourhood operation" to "median" and the "Neighbourhood size" to "7". You might have to adjust the size value to get your desired results.
# Under Neighbors choose a new filename to save the new raster to. We'll use Kansas_urban-only.tiff.

Click on "Run". When finished you will have a new raster with only towns and larger man made structures.

* Step 4 - Combine the clean, raw, reclassed base raster and the new town and larger structure raster into a new raster.
# Open Raster Calculator
# Under "Output layer" choose a new filename to save the new raster to. We'll use Kansas_adjusted-combined.tiff.
# Copy the following into the "Raster Calculator Expression" box. Where Kansas_urban-only@1 and Kansas_reclass-grass@1 are the names of previously processed step 1 and step 3 data.

("Kansas_urban-only@1" < 1) * "Kansas_reclass-grass@1" + ("Kansas_urban-only@1" != 0) * "Kansas_urban-only@1"

Click on "OK". When finished you will have a new raster with only towns and larger man made structures, road easements of grasscover and other default unsmoothed land cover.

* Step 5 - Upsample 4x to a new higher resolution raster that can then be smoothed.
# Click on the Kansas_adjusted-combined layer.
# Under Layer "File name" choose a new filename to save this new raster to. We'll use Kansas_final-prep-4x.tiff.
# Change the "Resolution (Current:layer) -> Horizontal and Vertical to a value that equals, current "Layer Resolution" / 4.

Click on "OK". When finished you will have a new up-scaled higher resolution raster.

* Step 6 - Smooth the Upsampled "final prep" layer.
# Click on the Kansas_final-prep-4x layer so it is the active layer.
# Click on GRASS -> Raster (r.*) -> r.neighbors
# Change the "Neighbourhood operation" to "median" and the "Neighbourhood size" to "7". You might have to adjust the size value to get your desired results.
# Under "Neighbors" choose a new filename to save the new raster to. We'll use Kansas_4326-84-hd.tiff.

Click on "Run". When finished you will have the final smoothed, higher resolution raster to use for building your scenery.

<big>Optional HD Water Option</big>
* Step 7 - Obtain and load hi resolution vector layer
Make sure that the vector layer and the raster layer you will eventually merge to have the same projection. ** Extent can be different if you use the option below.
# Use Top Menu: "Raster" -> "Conversion" -> "Rasterize (vector to raster)" or Processing Toolbax: GDAL -> "Vector conversion" -> "Rasterize (vector to raster)"
# Input layer = Kansas_water_4326-84
# Fixed value to burn = 41 (water)
# Output raster size units = "Georeferenced units"
# Width/Horizontal resolution = 0.00008309125 (4x the base NLCD resolution )
# Height/Vertical resolution = 0.00008309125 (4x the base NLCD resolution)
# ** Output extent = Select the raster layer you will eventually merge with as the "Output extent".
# Under "Rasterized" choose a new filename to save the new raster to. We'll use Kansas_4326-84-hd-water.tiff.

Click "Run" to generate the hi resolution raster layer.

* Step 8 - Reclass hi res, smoothed water to grass
# Open Raster Calculator
# Under "Output layer" choose a new filename to save the new raster to. We'll use Kansas_4326-84-hd-nowater.tiff.
# Copy the following into the "Raster Calculator Expression" box. Where Kansas_4326-84-hd is the name of your hi resolution, smoothed NLCD that includes the water data.
"Kansas_4326-84-hd@1" * ("Kansas_4326-84-hd@1" != 41) + 26 * ("Kansas_4326-84-hd@1 = 41")

Click on "OK". When finished you will have a new raster with the water layer changed to grassland. Another choice would be to change it to sand.

* Step 9 - Combine the hi resolution no water raster and the hi resolution water raster.
# Use Top Menu: "Raster" -> "Miscellaneous" -> "Merge" or Processing Toolbax: GDAL -> Raster Miscellaneous -> Merge
# Input layers = Select "Kansas_4326-84-hd-nowater@1" and Kansas_4326-84-hd-water.tiff
# Output data type = "byte".
# Under "Merged" choose a new filename to save the new raster to. We'll use Kansas_4326-84-hdwater.tiff.

Click "Run" to generate the new merged hi resolution raster layer.

== Setting up Virtual Planet Builder using docker ==
Generating the scenery uses an OSG tool called Virtual Planet Builder. Fortunately, there is a docker image so you don't need to build this yourself. Instead it will run as a container inside docker.

To set this up:

# Install [https://docs.docker.com/get-started/ Docker] on your platform.
# On your own machine, pull the docker image
docker pull flightgear/ws30-vpb-generator:latest

You now have a docker image on your own machine you can run.

Optionally, if you are hitting rate limits:
# Create an account on https://hub.docker.com/. (Note that you will need to click on an email verification link before you can log in for the first time)
# Run the following before the '''docker pull''' command above
docker login

== Running the Container ==
To generate terrain you need to run the Virtual Planet Builder tool within the container.

Firstly, get the container running from the directory containing your <code>data</code> and <code>output</code> directories:
docker run --rm --mount "type=bind,source=`pwd`/data,target=/home/flightgear/data,readonly" --mount "type=bind,source=`pwd`/output,target=/home/flightgear/output" -it flightgear/ws30-vpb-generator:latest /bin/bash
You should now find yourself in a bash shell within your container. You should see data and output directories with are linked to the directories you created earlier:
flightgear@ddcac77f7d5e:~$ ls
data output

== Generating the Terrain ==
Once the data is pre-processed, we can generate 1x1 tiles of terrain. For example:
osgdem --TERRAIN \
--image-ext png \
--no-interpolate-imagery \
--disable-error-diffusion \
--geocentric \
--no-mip-mapping \
-t /home/flightgear/data/corine/corine_WGS84.tif \
-d /home/flightgear/data/SRTM90/srtm_34_02.tif \
-d /home/flightgear/data/SRTM90/srtm_35_01.tif \
-d /home/flightgear/data/SRTM90/srtm_35_02.tif \
-d /home/flightgear/data/SRTM90/srtm_36_01.tif \
-d /home/flightgear/data/SRTM90/srtm_36_02.tif \
-b -4 55 -3 56 \
--PagedLOD \
-l 7 \
--radius-to-max-visible-distance-ratio 3 \
-o /home/flightgear/output/vpb/w010n50/w004n55/ws_w004n55.osgb
Running osgdem is in more detail here: [[Virtual Planet Builder#Running VPB]].

After doing this you should have a file <code>output/vpb/w010n50/w004n50/ws_w004n50.osgb</code>, plus a host of sub-directories. This is a 1x1 tile of terrain.

to leave the container simply type <code>exit</code>.

== Creating line features ==
Line features such as roads, railways and rivers are simply stored as a series of lat/lon points in an STG file using a specific STG verb. We get the data of this from Openstreetmap, and we have some simple scripts to generate the files.

The scripts are already included in the docker image at <code>/home/flightgear/scripts/</code>.
=== Running the scripts ===
The genroads.py script generates all line features. Simply set the output directory and the lat/lon box. Note that the output directory should be a "Terrain" directory. E.g.
./scripts/genroads.py ./output/Terrain -4 55 -3 56

== Packaging the Scenery ==
Once you have the terrain and line features they should be packaged in a scenery directory in vpb and Terrain sub-directories respectively. E.g.
MyCoolScenery/Terrain
MyCoolScenery/vpb
It is good practise to document the data sources used in scenery generation. Some source licenses require attribution of the original data source for anything derived, published or distributed.

To assist in fulfilling these license obligations, you can create a source.xml file in the scenery directory which includes attribution information. This will then be available from within the simulator under Help->Scenery Sources, and <u>may</u> fulfil the attribution requirements of your license. '''Note that you are responsible for fulfilling any license requirements from the data, not FlightGear'''.

The format of the file is straightforward:
<?xml version="1.0"?>
<PropertyList>
<nowiki><source></nowiki>
<name>Corine Land Cover (CLC) 2018, Version 2020_20u1</name>
<nowiki><link></nowiki><nowiki>http://web.archive.org/web/20221112175615/https://land.copernicus.eu/pan-european/corine-land-cover/clc2018?tab=metadata%2A</nowiki><nowiki></link></nowiki>
<license>GMES Open License</license>
<nowiki></source></nowiki>
<nowiki><source></nowiki>
<name>NASADEM Merged DEM Global 1 arc second V001</name>
<nowiki><link></nowiki><nowiki>https://www.earthdata.nasa.gov/</nowiki><nowiki></link></nowiki>
<license>Public Domain</license>
<nowiki></source></nowiki>
<nowiki><source></nowiki>
<name>OpenStreetMap</name>
<nowiki><link></nowiki><nowiki>https://www.openstreetmap.org/copyright</nowiki><nowiki></link></nowiki>
<license>Open Data Commons Open Database License</license>
<nowiki></source></nowiki>
</PropertyList>

== Running FlightGear with the new WS3.0 Terrain ==
To test the new terrain, simply include the appropriate scenery directory (e.g. MyCoolScenery) in in your scenery path and run FlightGear with the <code>--prop:/scenery/use-vpb=true</code> to enable WS3.0.

Howto:Create WS3.0 terrain

2023-04-15T10:50:38Z

Fahim Dalvi: Fixes to command for scenery generation inside the docker container

{{WS30 Navbar}}
This article provides instructions on how to generate base WS3.0 terrain.

WS3.0 terrain consists of two parts:

# A landclass texture draped over an elevation model. This is the terrain mesh.
# Line features such as roads, railways and rivers. This is draped over the terrain mesh at runtime.

== Getting the base data ==
First, you need two pieces of data for the scenery area you are generating:

# An elevation model (aka DEM). Use of the "NASADEM" with 30m resolution is recommended, and is available from [https://lpdaac.usgs.gov/products/nasadem_hgtv001/ here], and with an interactive browser [https://search.earthdata.nasa.gov/search here].
# Landclass data showing what type of terrain is at each point of the surface. This is often either a Raster Geotiff (effectively a texture), or vector data. For Europe, use of [https://land.copernicus.eu/pan-european/corine-land-cover/clc2018 CORINE] is recommended. For the USA NLCD is recommended
Put these files into a <code>data</code> directory and create an <code>output</code> directory next to it. This is where the scenery will be generated..

== Pre-processing the Elevation Model ==
If you are using NASADEM, then the elevation model is already using WGS84 and is ready to use as-is.

If you are using another elevation model, then you may need to re-project it using QGIS/gdalwarp to the WGS84 CRS (aka EPSG:4326).

== Pre-processing the Landclass Data ==
For any landclass data we need to ensure the data is in the correct format. That means:

# Uses the WGS84 Coordinate Reference System. The ensures that the terrain generation step is efficient.
# Is a Raster (geotiff) rather than Vector data. This raster will become the texture on the terrain that the terrain shaders do their magic on.
# Has the correct landclass values for each terrain type. Different landclass systems use different values. At present we use the CORINE values, defined in [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml].

Below is a quick table showing what steps you need to take for common landclass data sources.
{| class="wikitable"
|+
!Landclass Data
!Warp to WGS84 required?
!Landclass re-classification Required?
!Raster Simplification Required?
!Conversion to Raster Required?
|-
|CORINE Raster
|Yes
|No
|No
|No
|-
|CORINE Vector
|Yes
|Yes
|No
|Yes
|-
|NLCD
|No
|Yes
|Yes
|No
|}
The easiest way to do these operations is using QGIS, which is available for most platforms. If you are scripting a toolchain, the QGIS tools include command-line equivalents for all commands.

When using QGIS, set the Project CRS to WGS84 (aka EPSG:4326). You can then add layers of Raster or Vector data from files from the <code>Layer->Add Layer</code> menu. When performing any operations, <u>always</u> write out the data to a real file so you can go back to it later. Disk space is cheap :).

=== Warping Raster Layers to WGS84 ===
This is applicable to CORINE Raster data

You can warp a raster layer to a different CRS using the Raster->Projections-Warp (Reproject) tool.

Select the following options in the dialog:

* Input Layer - Check you have selected the correct layer. The CRS is shown at the right.
* Target CRS - set to <code>EPSG:4326 - WGS84</code>, which should be your project CRS.
* Resampling Method to Use - Nearest Neighbour. (Landclass data is not like normal images. You don't want to interpolate between values.)
* Nodata value for output bands - 0.0 (This means that any data at the edges will be Ocean, usually a reasonable default)
* Advanced Parameters - No Compression
* Output data type - Byte
* Reprojected - Choose a target filename

Alternatively you can do this step from the commandline.
gdalwarp -t_srs EPSG:4326 -dstnodata 0.0 -r near -ot Byte -of GTiff -co COMPRESS=NONE -co BIGTIFF=IF_NEEDED /home/stuart/FlightGear/VPB/data/CORINE/u2018_clc2018_v2020_20u1_raster100m/DATA/U2018_CLC2018_V2020_20u1.tif /home/stuart/FlightGear/VPB/data/scratch/corine_WGS84.tif

=== Warping Vector Layers to WGS84 ===
You can warp a vector layer using Vector->Data Management Tools->Reproject Layer.

Set the following options in the dialog:

* Input Layer - Check you have selected the correct layer. The CRS is shown at the right.
* Target CRS - set to <code>EPSG:4326 - WGS84</code>, which should be your project CRS.
* Reprojected - Choose a target filename

=== Reclassifying Vector Layers ===
For CORINE vector data in particular, the attributes used in the vector data are not the same as those used by the CORINE Raster data. So we need to create a new attribute on the data.
[[File:Field Calculator.png|thumb|QGIS Field Calculator]]
To do this

* Select <code>Layer->Open Attribute Table</code>. You should see a table with multiple columns. Each row represents a feature in the data.
* Click on <code>New Field</code> (Ctrl+W) and create a new field called Landclass of type "Whole Number (Integer)". This will create a new column which we will populate with the correct landclass data
* Click on the <code>Open Field Calculator</code> button (Ctrl + I). (If you get an error about only being able to create Virtual fields, go back to the Layer menu, export it and open the exported file).
* Select the following options:
** Update Existing Field
** Select the Landclass field you just created.
** Copy the contents of https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/mappings/corine_vector.txt into the Expression box. This is just some simple code to set the attribute correctly. The code should be correct for CORINE vector data. If your data is from other sources you will need to work out how you want to map your source data landclasses to the CORINE ones. [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml] can be used as a guide.
* Select <code>OK</code>. You should see that your landclass column is now populated with the landclass data.
* Select <code>Layer->Save Layer Edits</code> to save you changes

=== Creating a Raster from a Vector Layer ===
To create a Raster from a Vector Layer select <code>Raster->Conversion->Rasterize (Vector to Raster)</code>.
[[File:QGIS Rasterize (Vector to Raster).png|thumb|Creating a Raster from a Vector Layer - QGIS Rasterize]]
Select the following options:

* Input Layer - correct layer, check CRS
* Field to use for burn-in value - select the Landclass column you created above.
* Output raster size units. This is going to set the resolution of your raster. You can work out the resolution in two different ways:
** Select "Georeferenced units" and determine how many degrees each pixel is in latitude and longitude.
** Select "Pixels" and determine the size of raster you want in pixels. [https://www.nhc.noaa.gov/gccalc.shtml This] is a good calculator to help.
* Width/Horizontal Resolution. Enter the values you've calculated for the horizontal resolution (longitudinal), or the width of the raster
* Height/Vertical Resolution. Enter the values you've calculated for the vertical resolution (latitude or the height of the raster
* Output extent - Select an option from the box on the right. You can edit the text afterwards.
* Assign a specific nodata value to output bands - Select 0.0 for Ocean. CORINE vector data in particular has a lot of nodata for Oceans
* Advanced Parameters - No Compression
* Output data type - Byte
* Rasterized - Select a new filename

=== Simplifying a Raster Layer ===
Some Raster Landclass data (NLCD included) has too much noise - in particular large US highway systems are identified as Urban areas.

To smooth it out we can use the GRASS <code>n.neighbors</code> function from the Processing Toolbox in QGIS.

Select the following options:

* Input Layer - correct layer, check CRS
* Neighborhood operation - median. (This is not a normal image, so using an average will result in weird values)
* Neighborhood size - 5.
* Neighbors - Select a new filename.

=== Reclassifying a Raster Layer ===
WS3.0 uses CORINE landclass values. If using data from other sources it needs to be reclassified to the correct values.

To do this select <code>GRASS->Raster->r.reclass</code> from the Processing Toolbox.

Select the following options:

* Input Raster Layer - correct layer, check CRS
* Reclass rules text - copy in the contents of https://sourceforge.net/p/flightgear/fgmeta/ci/next/tree/ws30/mappings/nlcd2019.txt. Or an appropriate mapping from your landclass data to CORINE. Note that you can also reference a file using the "File containing reclass rules" option. Note a mapping of 22 24 = 1 is the same as 22 and 24 = 1. For a range of 22 to 24 use 22 23 24 = 1.
* Reclassified - Select a new filename.

(If this doesn't work a similar function is available in the Processing Toolbox under <code>Raster analysis->Reclassify by table</code>. However this doesn't save your table once you close the dialog, and entries have to be manually entered individually which takes a lot of effort)

=== Step By Step Procedure for Processing NLCD for the USA using the Raster Calculator, Up sampling and GRASS r.neighbors===

We will use a predetermined file naming convention throughout this procedure for simplicity. You can use a naming convention of your choice.

* Step 1 - Re-class from NLCD values to FlightGear values and all man made data to "grasscover" for a clean land cover base.
# Open Raster Calculator
# Under "Output layer" choose a new filename to save the new raster to. We'll use Kansas_reclass-grass.tiff.
# Copy the following into the "Raster Calculator Expression" box. Where Kansas_4326-84@1 is the name of your raw, correct CRS NLCD.

("Kansas_4326-84@1" = 11) * 41 + ("Kansas_4326-84@1" = 12) * 34 + ("Kansas_4326-84@1" = 21) * 26 + ("Kansas_4326-84@1" = 22) * 26 + ("Kansas_4326-84@1" = 23) * 26 + ("Kansas_4326-84@1" = 24) * 26 + ("Kansas_4326-84@1" = 31) * 27 + ("Kansas_4326-84@1" = 41) * 23 + ("Kansas_4326-84@1" = 42) * 24 + ("Kansas_4326-84@1" = 43) * 25 + ("Kansas_4326-84@1" = 51) * 30 + ("Kansas_4326-84@1" = 52) * 29 + ("Kansas_4326-84@1" = 71) * 26 + ("Kansas_4326-84@1" = 72) * 32 + ("Kansas_4326-84@1" = 73) * 31 + ("Kansas_4326-84@1" = 74) * 31 + ("Kansas_4326-84@1" = 75) * 32 + ("Kansas_4326-84@1" = 81) * 18 + ("Kansas_4326-84@1" = 82) * 19 + ("Kansas_4326-84@1" = 90) * 25 + ("Kansas_4326-84@1" = 95) * 35

Click on "OK". When finished you will have a new raster with all man made clutter removed and changed to "grasscover".

* Step 2 - Make a new Urban layer of all all man made clutter.
# Open Raster Calculator
# Under "Output layer" choose a new filename to save the new raster to. We'll use Kansas_urban.tiff.
# Copy the following into the "Raster Calculator Expression" box. Where Kansas_4326-84@1 is the name of your raw, correct CRS NLCD.

("Kansas_4326-84@1" = 21) * 10 + ("Kansas_4326-84@1" = 22) * 10 + ("Kansas_4326-84@1" = 23) * 1 + ("Kansas_4326-84@1" = 24) * 1

Click on "Run". When finished you will have a new raster with only all man made clutter.

* Step 3 - Make a new raster of leaving only towns and larger man made structures.
# Click on the Kansas_urban-only layer so it is the active layer.
# Click on GRASS -> Raster (r.*) -> r.neighbors
# Change the "Neighbourhood operation" to "median" and the "Neighbourhood size" to "7". You might have to adjust the size value to get your desired results.
# Under Neighbors choose a new filename to save the new raster to. We'll use Kansas_urban-only.tiff.

Click on "Run". When finished you will have a new raster with only towns and larger man made structures.

* Step 4 - Combine the clean, raw, reclassed base raster and the new town and larger structure raster into a new raster.
# Open Raster Calculator
# Under "Output layer" choose a new filename to save the new raster to. We'll use Kansas_adjusted-combined.tiff.
# Copy the following into the "Raster Calculator Expression" box. Where Kansas_urban-only@1 and Kansas_reclass-grass@1 are the names of previously processed step 1 and step 3 data.

("Kansas_urban-only@1" < 1) * "Kansas_reclass-grass@1" + ("Kansas_urban-only@1" != 0) * "Kansas_urban-only@1"

Click on "OK". When finished you will have a new raster with only towns and larger man made structures, road easements of grasscover and other default unsmoothed land cover.

* Step 5 - Upsample 4x to a new higher resolution raster that can then be smoothed.
# Click on the Kansas_adjusted-combined layer.
# Under Layer "File name" choose a new filename to save this new raster to. We'll use Kansas_final-prep-4x.tiff.
# Change the "Resolution (Current:layer) -> Horizontal and Vertical to a value that equals, current "Layer Resolution" / 4.

Click on "OK". When finished you will have a new up-scaled higher resolution raster.

* Step 6 - Smooth the Upsampled "final prep" layer.
# Click on the Kansas_final-prep-4x layer so it is the active layer.
# Click on GRASS -> Raster (r.*) -> r.neighbors
# Change the "Neighbourhood operation" to "median" and the "Neighbourhood size" to "7". You might have to adjust the size value to get your desired results.
# Under "Neighbors" choose a new filename to save the new raster to. We'll use Kansas_4326-84-hd.tiff.

Click on "Run". When finished you will have the final smoothed, higher resolution raster to use for building your scenery.

<big>Optional HD Water Option</big>
* Step 7 - Obtain and load hi resolution vector layer
Make sure that the vector layer and the raster layer you will eventually merge to have the same projection. ** Extent can be different if you use the option below.
# Use Top Menu: "Raster" -> "Conversion" -> "Rasterize (vector to raster)" or Processing Toolbax: GDAL -> "Vector conversion" -> "Rasterize (vector to raster)"
# Input layer = Kansas_water_4326-84
# Fixed value to burn = 41 (water)
# Output raster size units = "Georeferenced units"
# Width/Horizontal resolution = 0.00008309125 (4x the base NLCD resolution )
# Height/Vertical resolution = 0.00008309125 (4x the base NLCD resolution)
# ** Output extent = Select the raster layer you will eventually merge with as the "Output extent".
# Under "Rasterized" choose a new filename to save the new raster to. We'll use Kansas_4326-84-hd-water.tiff.

Click "Run" to generate the hi resolution raster layer.

* Step 8 - Reclass hi res, smoothed water to grass
# Open Raster Calculator
# Under "Output layer" choose a new filename to save the new raster to. We'll use Kansas_4326-84-hd-nowater.tiff.
# Copy the following into the "Raster Calculator Expression" box. Where Kansas_4326-84-hd is the name of your hi resolution, smoothed NLCD that includes the water data.
"Kansas_4326-84-hd@1" * ("Kansas_4326-84-hd@1" != 41) + 26 * ("Kansas_4326-84-hd@1 = 41")

Click on "OK". When finished you will have a new raster with the water layer changed to grassland. Another choice would be to change it to sand.

* Step 9 - Combine the hi resolution no water raster and the hi resolution water raster.
# Use Top Menu: "Raster" -> "Miscellaneous" -> "Merge" or Processing Toolbax: GDAL -> Raster Miscellaneous -> Merge
# Input layers = Select "Kansas_4326-84-hd-nowater@1" and Kansas_4326-84-hd-water.tiff
# Output data type = "byte".
# Under "Merged" choose a new filename to save the new raster to. We'll use Kansas_4326-84-hdwater.tiff.

Click "Run" to generate the new merged hi resolution raster layer.

== Setting up Virtual Planet Builder using docker ==
Generating the scenery uses an OSG tool called Virtual Planet Builder. Fortunately, there is a docker image so you don't need to build this yourself. Instead it will run as a container inside docker.

To set this up:

# Install [https://docs.docker.com/get-started/ Docker] on your platform.
# Create an account on https://hub.docker.com/. (Note that you will need to click on an email verification link before you can log in for the first time)
# On your own machine, log into docker, and then pull the docker image
docker login

docker pull flightgear/ws30-vbp-generator:latest
You now have a docker image on your own machine you can run.

== Running the Container ==
To generate terrain you need to run the Virtual Planet Builder tool within the container.

Firstly, get the container running from the directory containing your <code>data</code> and <code>output</code> directories:
docker run --rm --mount "type=bind,source=`pwd`/data,target=/home/flightgear/data,readonly" --mount "type=bind,source=`pwd`/output,target=/home/flightgear/output" -it flightgear/ws30-vbp-generator:latest /bin/bash
You should now find yourself in a bash shell within your container. You should see data and output directories with are linked to the directories you created earlier:
flightgear@ddcac77f7d5e:~$ ls
data output

== Generating the Terrain ==
Once the data is pre-processed, we can generate 1x1 tiles of terrain. For example:
osgdem --TERRAIN \
--image-ext png \
--no-interpolate-imagery \
--disable-error-diffusion \
--geocentric \
--no-mip-mapping \
-t /home/flightgear/data/corine/corine_WGS84.tif \
-d /home/flightgear/data/SRTM90/srtm_34_02.tif \
-d /home/flightgear/data/SRTM90/srtm_35_01.tif \
-d /home/flightgear/data/SRTM90/srtm_35_02.tif \
-d /home/flightgear/data/SRTM90/srtm_36_01.tif \
-d /home/flightgear/data/SRTM90/srtm_36_02.tif \
-b -4 55 -3 56 \
--PagedLOD \
-l 7 \
--radius-to-max-visible-distance-ratio 3 \
-o /home/flightgear/output/vpb/w010n50/w004n55/ws_w004n55.osgb
Running osgdem is in more detail here: [[Virtual Planet Builder#Running VPB]].

After doing this you should have a file <code>output/vpb/w010n50/w004n50/ws_w004n50.osgb</code>, plus a host of sub-directories. This is a 1x1 tile of terrain.

to leave the container simply type <code>exit</code>.

== Creating line features ==
Line features such as roads, railways and rivers are simply stored as a series of lat/lon points in an STG file using a specific STG verb. We get the data of this from Openstreetmap, and we have some simple scripts to generate the files.

The scripts are already included in the docker image at <code>/home/flightgear/scripts/</code>.
=== Running the scripts ===
The genroads.py script generates all line features. Simply set the output directory and the lat/lon box. Note that the output directory should be a "Terrain" directory. E.g.
./scripts/genroads.py ./output/Terrain -4 55 -3 56

== Packaging the Scenery ==
Once you have the terrain and line features they should be packaged in a scenery directory in vpb and Terrain sub-directories respectively. E.g.
MyCoolScenery/Terrain
MyCoolScenery/vpb
It is good practise to document the data sources used in scenery generation. Some source licenses require attribution of the original data source for anything derived, published or distributed.

To assist in fulfilling these license obligations, you can create a source.xml file in the scenery directory which includes attribution information. This will then be available from within the simulator under Help->Scenery Sources, and <u>may</u> fulfil the attribution requirements of your license. '''Note that you are responsible for fulfilling any license requirements from the data, not FlightGear'''.

The format of the file is straightforward:
<?xml version="1.0"?>
<PropertyList>
<nowiki><source></nowiki>
<name>Corine Land Cover (CLC) 2018, Version 2020_20u1</name>
<nowiki><link></nowiki><nowiki>http://web.archive.org/web/20221112175615/https://land.copernicus.eu/pan-european/corine-land-cover/clc2018?tab=metadata%2A</nowiki><nowiki></link></nowiki>
<license>GMES Open License</license>
<nowiki></source></nowiki>
<nowiki><source></nowiki>
<name>NASADEM Merged DEM Global 1 arc second V001</name>
<nowiki><link></nowiki><nowiki>https://www.earthdata.nasa.gov/</nowiki><nowiki></link></nowiki>
<license>Public Domain</license>
<nowiki></source></nowiki>
<nowiki><source></nowiki>
<name>OpenStreetMap</name>
<nowiki><link></nowiki><nowiki>https://www.openstreetmap.org/copyright</nowiki><nowiki></link></nowiki>
<license>Open Data Commons Open Database License</license>
<nowiki></source></nowiki>
</PropertyList>

== Running FlightGear with the new WS3.0 Terrain ==
To test the new terrain, simply include the appropriate scenery directory (e.g. MyCoolScenery) in in your scenery path and run FlightGear with the <code>--prop:/scenery/use-vpb=true</code> to enable WS3.0.

Howto:Create WS3.0 terrain

2022-01-23T11:56:16Z

Fahim Dalvi: Fix formatting

This article provides instructions on how to generate base WS3.0 terrain.

WS3.0 terrain consists of two parts:

# A landclass texture draped over an elevation model. This is the terrain mesh.
# Line features such as roads, railways and rivers. This is draped over the terrain mesh at runtime.

=== Creating the terrain mesh ===

==== Getting the base data ====
First, you need two pieces of data for the scenery area you are generating:

# An elevation model (aka DEM). Use of the "NASADEM" with 30m resolution is recommended, and is available from [https://lpdaac.usgs.gov/products/nasadem_hgtv001/ here], and with an interactive browser [https://search.earthdata.nasa.gov/search here].
# A landclass geotiff. For Europe, use of [https://land.copernicus.eu/pan-european/corine-land-cover/clc2018 CORINE] is recommended. This needs to be RASTER data, and could be generated from vector data using QGIS. Note that the landclass assignments much match your [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml] file. This will be the case of CORINE data, but other data sources will need to be remapped in QGIS.
Put these files into a <code>data</code> directory and create an <code>output</code> directory next to it. This is where the scenery will be generated..

==== Setting up Virtual Planet Builder using docker ====
Generating the scenery uses an OSG tool called Virtual Planet Builder. Fortunately, there is a docker image so you don't need to build this yourself. Instead it will run as a container inside docker.

To set this up:

# Install [https://docs.docker.com/get-started/ Docker] on your platform.
# Create an account on https://hub.docker.com/. (Note that you will need to click on an email verification link before you can log in for the first time)
# On your own machine, log into docker, and then pull the docker image
docker login

docker pull flightgear/ws30-vbp-generator:latest
You now have a docker image on your own machine you can run.

==== Generating Terrain ====
To generate terrain you need to run the Virtual Planet Builder tool within the container.

Firstly, get the container running from the directory containing your <code>data</code> and <code>output</code> directories:
docker run --rm --mount "type=bind,source=`pwd`/data,target=/home/flightgear/data,readonly" --mount "type=bind,source=`pwd`/output,target=/home/flightgear/output" -it flightgear/ws30-vbp-generator:latest /bin/bash
You should now find yourself in a bash shell within your container. You should see data and output directories with are linked to the directories you created earlier:
flightgear@ddcac77f7d5e:~$ ls
data output
From here you can run the osgdem process to build terrain:
osgdem --TERRAIN \
--compressor-nvtt \
--compression-quality-highest \
--no-interpolate-imagery \
--disable-error-diffusion \
--geocentric \
-t /home/flightgear/data/CORINE/u2018_clc2018_v2020_20u1_raster100m/DATA/U2018_CLC2018_V2020_20u1.tif \
-d /home/flightgear/data/SRTM90/srtm_34_02.tif \
-d /home/flightgear/data/SRTM90/srtm_35_01.tif \
-d /home/flightgear/data/SRTM90/srtm_35_02.tif \
-d /home/flightgear/data/SRTM90/srtm_36_01.tif \
-d /home/flightgear/data/SRTM90/srtm_36_02.tif \
-b -4 55 -3 56 \
--PagedLOD \
-l 7 \
--radius-to-max-visible-distance-ratio 3 \
-o /home/flightgear/output/vpb/w010n50/w004n55/ws_w004n55.osgb
Running osgdem is in more detail here: [[Virtual Planet Builder#Running VPB]].

After doing this you should have a file <code>output/vpb/w010n50/w004n50/ws_w004n50.osgb</code>, plus a host of sub-directories. This is a 1x1 tile of terrain.

to leave the container simply type <code>exit</code>.

=== Creating line features ===
Line features such as roads, railways and rivers are simply stored as a series of lat/lon points in an STG file using a specific STG verb. We get the data of this from Openstreetmap, and we have some simple scripts to generate the files.

The scripts are already included in the docker image at <code>/home/flightgear/scripts/</code>.
==== Running the scripts ====
The genroads.py script generates all line features. Simply set the output directory and the lat/lon box. Note that the output directory should be a "Terrain" directory. E.g.
./scripts/genroads.py ./output/Terrain -4 55 -3 56

=== Running FlightGear with the new WS3.0 Terrain ===
To test the new terrain, simply include the output directory in in your scenery path and run FlightGear with the <code>--prop:/scenery/use-vpb=true</code> to enable WS3.0.

Howto:Create WS3.0 terrain

2022-01-22T14:15:25Z

Fahim Dalvi: Updated page to reflect changes in docker image and python scripts

This article provides instructions on how to generate base WS3.0 terrain.

WS3.0 terrain consists of two parts:

# A landclass texture draped over an elevation model. This is the terrain mesh.
# Line features such as roads, railways and rivers. This is draped over the terrain mesh at runtime.

=== Creating the terrain mesh ===

==== Getting the base data ====
First, you need two pieces of data for the scenery area you are generating:

# An elevation model (aka DEM). Use of the "NASADEM" with 30m resolution is recommended, and is available from [https://lpdaac.usgs.gov/products/nasadem_hgtv001/ here], and with an interactive browser [https://search.earthdata.nasa.gov/search here].
# A landclass geotiff. For Europe, use of [https://land.copernicus.eu/pan-european/corine-land-cover/clc2018 CORINE] is recommended. This needs to be RASTER data, and could be generated from vector data using QGIS. Note that the landclass assignments much match your [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/Materials/base/landclass-mapping.xml Materials/base/landclass-mapping.xml] file. This will be the case of CORINE data, but other data sources will need to be remapped in QGIS.
Put these files into a <code>data</code> directory and create an <code>output</code> directory next to it. This is where the scenery will be generated..

==== Setting up Virtual Planet Builder using docker ====
Generating the scenery uses an OSG tool called Virtual Planet Builder. Fortunately, there is a docker image so you don't need to build this yourself. Instead it will run as a container inside docker.

To set this up:

# Install [https://docs.docker.com/get-started/ Docker] on your platform.
# Create an account on https://hub.docker.com/. (Note that you will need to click on an email verification link before you can log in for the first time)
# On your own machine, log into docker, and then pull the docker image
docker login

docker pull flightgear/ws30-vbp-generator:latest
You now have a docker image on your own machine you can run.

==== Generating Terrain ====
To generate terrain you need to run the Virtual Planet Builder tool within the container.

Firstly, get the container running from the directory containing your <code>data</code> and <code>output</code> directories:
docker run --rm --mount "type=bind,source=`pwd`/data,target=/home/flightgear/data,readonly" --mount "type=bind,source=`pwd`/output,target=/home/flightgear/output" -it flightgear/ws30-vbp-generator:latest /bin/bash
You should now find yourself in a bash shell within your container. You should see data and output directories with are linked to the directories you created earlier:
flightgear@ddcac77f7d5e:~$ ls
data output
From here you can run the osgdem process to build terrain:
osgdem --TERRAIN \
--compressor-nvtt \
--compression-quality-highest \
--no-interpolate-imagery \
--disable-error-diffusion \
--geocentric \
-t /home/flightgear/data/CORINE/u2018_clc2018_v2020_20u1_raster100m/DATA/U2018_CLC2018_V2020_20u1.tif \
-d /home/flightgear/data/SRTM90/srtm_34_02.tif \
-d /home/flightgear/data/SRTM90/srtm_35_01.tif \
-d /home/flightgear/data/SRTM90/srtm_35_02.tif \
-d /home/flightgear/data/SRTM90/srtm_36_01.tif \
-d /home/flightgear/data/SRTM90/srtm_36_02.tif \
-b -4 55 -3 56 \
--PagedLOD \
-l 7 \
--radius-to-max-visible-distance-ratio 3 \
-o /home/flightgear/output/vpb/w010n50/w004n55/ws_w004n55.osgb
Running osgdem is in more detail here: [[Virtual Planet Builder#Running VPB]].

After doing this you should have a file <code>output/vpb/w010n50/w004n50/ws_w004n50.osgb</code>, plus a host of sub-directories. This is a 1x1 tile of terrain.

to leave the container simply type <code>exit</code>.

=== Creating line features ===
Line features such as roads, railways and rivers are simply stored as a series of lat/lon points in an STG file using a specific STG verb. We get the data of this from Openstreetmap, and we have some simple scripts to generate the files.

The scripts are already included in the docker image at `/home/flightgear/scripts/`.
==== Running the scripts ====
The genroads.py script generates all line features. Simply set the output directory and the lat/lon box. Note that the output directory should be a "Terrain" directory. E.g.
./scripts/genroads.py ./output/Terrain 55 -4 56 -3
Note that the lat/lon order is reversed from osgdem.

=== Running FlightGear with the new WS3.0 Terrain ===
To test the new terrain, simply include the output directory in in your scenery path and run FlightGear with the <code>--prop:/scenery/use-vpb=true</code> to enable WS3.0.

User:Fahim Dalvi/Howto: Complete TerraGear example using Docker

2021-02-18T07:30:27Z

Fahim Dalvi: Fahim Dalvi moved page User:Fahim Dalvi/Howto: Complete TerraGear example using Docker to FlightGear wiki:Howto:Complete TerraGear example using docker: A few people have indicated that this is useful in its current state, so moving to the main wiki will make it more accessible.

#REDIRECT [[FlightGear wiki:Howto:Complete TerraGear example using docker]]

Howto:Complete TerraGear example using docker

2021-02-18T07:30:27Z

This article aims to serve as a quick starting point for people wanting to build scenery using the dockerized version of the TerraGear scenery toolchain. This will allow users to build scenery on all popular operating systems including Windows, macOS and Linux without the hassle of building the terragear toolchain themselves. This is in no way a comprehensive introduction, but should be enough to get one used to the scenery generation process.

[[File:Saint Helena Island generated using dockerized TerraGear.jpg|thumb|Saint Helena island generated using the docker image for the TerraGear toolchain]]

== Background ==
TerraGear requires three pieces of data for scenery generation:

# Elevation data: This data defines how high each point in the scenery or land is. One source for such data is http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm.
# Landclass data: This data defines what kind of "land" is under each point in the scenery or land is. For example, some point might be "urban" class, or "forest" class. One source for such data is http://download.geofabrik.de/, which is derived from OSM.
# Airport data: This data defines the position of runways, taxiways and other assorted airport information. One source for such data is the XPlane gateway.

TerraGear consists of five tools:

# hgtchop - Processing elevation data
# terrafit - Processing elevation data
# genapts - Processing airport data
# ogr-decode - Processing landclass data
# tg-construct - Generating the final scenery.

== Scenery location ==
We will build Saint Helena Island, an island in the Atlantic Ocean. Specifically, we will be building the island around [https://en.wikipedia.org/wiki/Saint_Helena_Airport Saint Helena Airport] (ICAO: '''FHSH''').

Its location is: DMS 15° 57′ 33″ S, 5° 38′ 45″ W, Decimal -5.645833 -15.959167

A good vantage point to see progress is to start FG with the following options:

--lon=-5.62000000 --lat=-16.00000000 --altitude=4000 --heading=310

The bounds for our build will be:
* Latitude: -6 to -5
* Longitude: -17 to -15

Let <code>$SCENERY_BUILD_DIR</code> be the directory containing all of our working files for this project.

== Getting docker running ==
The first step is to have docker installed and accessible through the command line. Run the following command to fetch the terragear toolchain:
docker pull flightgear/terragear:ws20

Next, start a docker container to access the terragear tools:

docker run -i -v $SCENERY_BUILD_DIR:/terragear-work/ -t flightgear/terragear:ws20 /bin/bash

Once this command runs successfully, the command line will now be a "window" into the docker container, allowing you to run the entire terragear toolchain. Because of the <code>-v</code> argument (bind mount), the container can see the contents of <code>$SCENERY_BUILD_DIR</code> will be visible at <code>/terragear-work/</code> inside the container.

== Process Elevation Data ==
The elevation data can be obtained from [http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm ViewFinderPanoramas], specifically, the [http://viewfinderpanoramas.org/dem3/SD30.zip SD30] and [SE30 http://viewfinderpanoramas.org/dem3/SE30.zip] tiles cover this island.

Extract and add to <code>$SCENERY_BUILD_DIR/data/SRTM-3/*.hgt</code>. Run the following commands in the docker container:

cd /terragear-work/
for f in data/SRTM-3/*.hgt; do hgtchop 3 "${f}" " work/SRTM-3"; done
terrafit work/SRTM-3

== Process Airport Data ==
'''FHSH''' is not available in FlightGear's <code>apt.dat</code>, so the airport information has to be fetched from elsewhere. The XPlane gateway is one possible source. For this sample project, we can use the following data from https://github.com/accek/fg-nav-fixups:

1 1023 1 0 FHSH St Helena
100 45.00 2 0 0.00 1 2 1 02 -15.96694276 -005.64575428 100 0 2 9 0 2 20 -15.94934298 -005.64615237 300 0 2 9 0 2
110 1 0.00 358.7100 New Taxiway 4
111 -15.96166211 -005.64927678
111 -15.96340503 -005.64926307
111 -15.96340434 -005.64836151
111 -15.96290056 -005.64836043
111 -15.96284142 -005.64854134
111 -15.96265507 -005.64854103
113 -15.96155909 -005.64854086
110 2 0.00 358.7100 New Taxiway 3
111 -15.94934844 -005.64635879 3 102
111 -15.94935248 -005.64663563 3 102
111 -15.94995561 -005.64662024 3 102
113 -15.95019415 -005.64634336
110 2 0.00 358.7100 New Taxiway 2
111 -15.96693818 -005.64554618 3 102
111 -15.96693596 -005.64524600 3 102
111 -15.96628657 -005.64526997 3 102
113 -15.96603006 -005.64556883
110 2 0.00 358.7100 New Taxiway 1
111 -15.96305635 -005.64765837 3 102
111 -15.96240410 -005.64767341 3 102
112 -15.96226078 -005.64761762 -15.96220044 -005.64756860 3 102
111 -15.96219925 -005.64745814 3 102
111 -15.96219005 -005.64624609 3 102
112 -15.96223439 -005.64613746 -15.96227201 -005.64609544 3 102
111 -15.96236947 -005.64606567
111 -15.96184016 -005.64607709 3 102
112 -15.96195708 -005.64616687 -15.96199469 -005.64621034 3 102
111 -15.96199881 -005.64627387 3 102
111 -15.96200448 -005.64744540 3 102
112 -15.96197248 -005.64759953 -15.96193665 -005.64765444 3 102
111 -15.96183543 -005.64768917 3 102
111 -15.96154350 -005.64769949 3 102
111 -15.96155909 -005.64854086
111 -15.96265507 -005.64854103
111 -15.96265481 -005.64818499
113 -15.96306600 -005.64818480 3 102
130 Airport Boundary
111 -15.95876878 -005.64712051
111 -15.96005216 -005.64729370
111 -15.96043831 -005.64731000
111 -15.96048880 -005.64864132
111 -15.96154716 -005.64921198
111 -15.96159626 -005.65014384
111 -15.96388391 -005.64953797
111 -15.96430513 -005.64699927
111 -15.96882642 -005.64692255
111 -15.96885682 -005.64412109
111 -15.94564642 -005.64456651
113 -15.94563863 -005.64716916
120 Hold
111 -15.96200516 -005.64660225 4 103
115 -15.96218383 -005.64660129
120 Linear Feature 5
111 -15.96210864 -005.64767019 1 101
112 -15.96206007 -005.64782922 -15.96201482 -005.64792776 1 101
115 -15.96188449 -005.64810582
120 Linear Feature 4
111 -15.96210864 -005.64767019 1 101
112 -15.96213878 -005.64782592 -15.96215760 -005.64789051 1 101
115 -15.96229199 -005.64808544
120 Linear Feature 3
111 -15.96156820 -005.64813668 20
111 -15.96263721 -005.64810368 20
111 -15.96263233 -005.64792345 20
115 -15.96304480 -005.64791075
120 Linear Feature 2
111 -15.96210864 -005.64767019 1 101
111 -15.96210128 -005.64660525 1 105
115 -15.96209919 -005.64630388
120 Linear Feature 1
111 -15.96154408 -005.64588717 1 105
111 -15.96184445 -005.64588139 1 105
112 -15.96204503 -005.64596036 -15.96210198 -005.64604073 1 105
111 -15.96209919 -005.64630388 1 105
112 -15.96217524 -005.64595582 -15.96225060 -005.64588070 1 105
111 -15.96236918 -005.64587174 1 105
115 -15.96269552 -005.64586403
21 -15.95361317 -005.64657631 3 180.0000 3.0 Papi
21 -15.95359638 -005.64551140 2 180.0000 3.0 Papi
21 -15.96347774 -005.64645343 2 -1.2600 3.0 Papi
20 -15.96192491 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
20 -15.96225995 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
14 -15.96312208 -005.64867411 82.02 0 Tower Viewpoint
15 -15.96179344 -005.64822577 -50.36 Ramp Start 1
1300 -15.96238032 -005.64819725 -129.45 gate jets Ramp Start 2
15 -15.96285880 -005.64779046 -181.04 Ramp Start 3
19 -15.95196179 -005.64670036 0 New Windsock 2
19 -15.96603475 -005.64630065 0 New Windsock 1

Copy and paste the above into <code>$SCENERY_BUILD_DIR/data/airports/FHSH.dat</code>. We can now run <code>genapts</code>:

genapts850 --input=data/airports/FHSH --work=./work --dem-path=SRTM-3 --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15
genapts850 --input=data/airports/FHSH.dat --work=./work --dem-path=SRTM-3 --airport=FHSH

== Process Landclass Data ==
We can download landclass data from GeoFabrik, specifically from http://download.geofabrik.de/africa/saint-helena-ascension-and-tristan-da-cunha.html. Download the *.shp files and extract them into <code>$SCENERY_BUILD_DATA/data/shapefiles</code>. Each type of file should go into its own folder. For example, copy all <code>gis_osm_places_a_free_1.*</code> files into <code>$SCENERY_BUILD_DATA/data/shapefiles/gis_osm_places_a_free_1/*</code>, as this is the format that TerraGear expects the files to be in. Usually, we would use a landmass (See Notes below) shapefile as our Default, but to simplify things for this tutorial, we can use the <code>gis_osm_places_a_free_1.shp</code> file, as the landmass file and this file are identical for this particular island. We are now ready to run <code>ogr-decode</code>:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/gis_osm_places_a_free_1/

We have to run <code>ogr-decode</code> for every land class (so urban, forest, lakes, roads etc). At each time, we need to specify the shapefile (the last argument in the above command) and the corresponding area material type that FlightGear recognizes ("Default") in the above command. For this tutorial, we will run the command just once to get the construct the entire island as a "Default" landclass.

== Bringing it all together ==
We can finally run <code>tg-construct</code> to bring everything together
tg-construct --priorities=/usr/local/share/TerraGear/default_priorities.txt --work-dir=./work --output-dir=./output/Terrain --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15 AirportArea AirportObj Default SRTM-3

The <code>$SCENERY_BUILD_DIR/output</code> will now contain the built scenery. Point your FG instance to this path using <code>--fg-scenery</code> and take a look at the built scenery!

== Notes ==
* There are two docker images, <code>flightgear/terragear:ws20</code> and <code>flightgear/terragear:latest</code>. The former corresponds to the 2.0 world scenery build, while the later points to the latest code. The latest container has several improvements and GDAL tools which can be used to manipulate shapefiles, but also unfortunately has bugs in the hgtchop and terrafit tools for SRTM-3 data. The best way is to use <code>flightgear/terragear:ws20</code> for elevation data processing, and <code>flightgear/terragear:latest</code> for everything else.
* The [https://osmdata.openstreetmap.de/data/land-polygons.html OSM coastlines data] is a good source for the landmass ("Default") terrain, but is a single file for the entire world.
* You can use the following command (found in the latest terragear docker image) to "crop" the shapefile to an area of interest:
ogr2ogr -clipsrc -6 -17 -5 -15 cut_landmass.shp land_polygons.shp
* As mentioned in the introduction, this tutorial is just a starting point. Have a look at the other TerraGear wiki articles. A good resource is also provided [https://forum.flightgear.org/viewtopic.php?t=35618 on the forum], which uses TerraGear GUI. You can use the concepts learned from there and run the commands in the docker image.

Howto:Complete TerraGear example using docker

2021-01-06T18:04:49Z

Fahim Dalvi:

Howto:Complete TerraGear example using docker

2021-01-06T09:56:40Z

Fahim Dalvi:

This article aims to serve as a quick starting point for people wanting to build scenery using the dockerized version of the TerraGear scenery toolchain. This will allow users to build scenery on all popular operating systems including Windows, macOS and Linux without the hassle of building the terragear toolchain themselves. This is in no way a comprehensive introduction, but should be enough to get one used to the scenery generation process.

[[File:Saint Helena Island generated using dockerized TerraGear.jpg|thumb|Saint Helena island generated using the docker image for the TerraGear toolchain]]

== Background ==
TerraGear requires three pieces of data for scenery generation:

# Elevation data: This data defines how high each point in the scenery or land is. One source for such data is http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm.
# Landclass data: This data defines what kind of "land" is under each point in the scenery or land is. For example, some point might be "urban" class, or "forest" class. One source for such data is http://download.geofabrik.de/, which is derived from OSM.
# Airport data: This data defines the position of runways, taxiways and other assorted airport information. One source for such data is the XPlane gateway.

TerraGear consists of five tools:

# hgtchop - Processing elevation data
# terrafit - Processing elevation data
# genapts - Processing airport data
# ogr-decode - Processing landclass data
# tg-construct - Generating the final scenery.

== Scenery location ==
We will build Saint Helena Island, an island in the Atlantic Ocean. Specifically, we will be building the island around [https://en.wikipedia.org/wiki/Saint_Helena_Airport Saint Helena Airport] (ICAO: '''FHSH''').

Its location is: DMS 15° 57′ 33″ S, 5° 38′ 45″ W, Decimal -5.645833 -15.959167

A good vantage point to see progress is to start FG with the following options:

--lon=-5.62000000 --lat=-16.00000000 --altitude=4000 --heading=310

The bounds for our build will be:
* Latitude: -6 to -5
* Longitude: -17 to -15

Let <code>$SCENERY_BUILD_DIR</code> be the directory containing all of our working files for this project.

== Getting docker running ==
The first step is to have docker installed and accessible through the command line. Run the following command to fetch the terragear toolchain:
docker pull flightgear/terragear:ws20

Next, start a docker container to access the terragear tools:

docker run -i -v $SCENERY_BUILD_DIR:/terragear-work/ -t flightgear/terragear:ws20 /bin/bash

Once this command runs successfully, the command line will now be a "window" into the docker container, allowing you to run the entire terragear toolchain. Because of the <code>-v</code> argument (bind mount), the container can see the contents of <code>$SCENERY_BUILD_DIR</code> will be visible at <code>/terragear-work/</code> inside the container.

== Process Elevation Data ==
The elevation data can be obtained from [http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm ViewFinderPanoramas], specifically, the [http://viewfinderpanoramas.org/dem3/SD30.zip SD30] and [SE30 http://viewfinderpanoramas.org/dem3/SE30.zip] tiles cover this island.

Extract and add to <code>$SCENERY_BUILD_DIR/data/SRTM-3/*.hgt</code>. Run the following commands in the docker container:

cd /terragear-work/
for f in data/SRTM-3/*.hgt; do hgtchop 3 "${f}" " work/SRTM-3"; done
terrafit work/SRTM-3

== Process Airport Data ==
'''FHSH''' is not available in FlightGear's <code>apt.dat</code>, so the airport information has to be fetched from elsewhere. The XPlane gateway is one possible source. For this sample project, we can use the following data from https://github.com/accek/fg-nav-fixups:

1 1023 1 0 FHSH St Helena
100 45.00 2 0 0.00 1 2 1 02 -15.96694276 -005.64575428 100 0 2 9 0 2 20 -15.94934298 -005.64615237 300 0 2 9 0 2
110 1 0.00 358.7100 New Taxiway 4
111 -15.96166211 -005.64927678
111 -15.96340503 -005.64926307
111 -15.96340434 -005.64836151
111 -15.96290056 -005.64836043
111 -15.96284142 -005.64854134
111 -15.96265507 -005.64854103
113 -15.96155909 -005.64854086
110 2 0.00 358.7100 New Taxiway 3
111 -15.94934844 -005.64635879 3 102
111 -15.94935248 -005.64663563 3 102
111 -15.94995561 -005.64662024 3 102
113 -15.95019415 -005.64634336
110 2 0.00 358.7100 New Taxiway 2
111 -15.96693818 -005.64554618 3 102
111 -15.96693596 -005.64524600 3 102
111 -15.96628657 -005.64526997 3 102
113 -15.96603006 -005.64556883
110 2 0.00 358.7100 New Taxiway 1
111 -15.96305635 -005.64765837 3 102
111 -15.96240410 -005.64767341 3 102
112 -15.96226078 -005.64761762 -15.96220044 -005.64756860 3 102
111 -15.96219925 -005.64745814 3 102
111 -15.96219005 -005.64624609 3 102
112 -15.96223439 -005.64613746 -15.96227201 -005.64609544 3 102
111 -15.96236947 -005.64606567
111 -15.96184016 -005.64607709 3 102
112 -15.96195708 -005.64616687 -15.96199469 -005.64621034 3 102
111 -15.96199881 -005.64627387 3 102
111 -15.96200448 -005.64744540 3 102
112 -15.96197248 -005.64759953 -15.96193665 -005.64765444 3 102
111 -15.96183543 -005.64768917 3 102
111 -15.96154350 -005.64769949 3 102
111 -15.96155909 -005.64854086
111 -15.96265507 -005.64854103
111 -15.96265481 -005.64818499
113 -15.96306600 -005.64818480 3 102
130 Airport Boundary
111 -15.95876878 -005.64712051
111 -15.96005216 -005.64729370
111 -15.96043831 -005.64731000
111 -15.96048880 -005.64864132
111 -15.96154716 -005.64921198
111 -15.96159626 -005.65014384
111 -15.96388391 -005.64953797
111 -15.96430513 -005.64699927
111 -15.96882642 -005.64692255
111 -15.96885682 -005.64412109
111 -15.94564642 -005.64456651
113 -15.94563863 -005.64716916
120 Hold
111 -15.96200516 -005.64660225 4 103
115 -15.96218383 -005.64660129
120 Linear Feature 5
111 -15.96210864 -005.64767019 1 101
112 -15.96206007 -005.64782922 -15.96201482 -005.64792776 1 101
115 -15.96188449 -005.64810582
120 Linear Feature 4
111 -15.96210864 -005.64767019 1 101
112 -15.96213878 -005.64782592 -15.96215760 -005.64789051 1 101
115 -15.96229199 -005.64808544
120 Linear Feature 3
111 -15.96156820 -005.64813668 20
111 -15.96263721 -005.64810368 20
111 -15.96263233 -005.64792345 20
115 -15.96304480 -005.64791075
120 Linear Feature 2
111 -15.96210864 -005.64767019 1 101
111 -15.96210128 -005.64660525 1 105
115 -15.96209919 -005.64630388
120 Linear Feature 1
111 -15.96154408 -005.64588717 1 105
111 -15.96184445 -005.64588139 1 105
112 -15.96204503 -005.64596036 -15.96210198 -005.64604073 1 105
111 -15.96209919 -005.64630388 1 105
112 -15.96217524 -005.64595582 -15.96225060 -005.64588070 1 105
111 -15.96236918 -005.64587174 1 105
115 -15.96269552 -005.64586403
21 -15.95361317 -005.64657631 3 180.0000 3.0 Papi
21 -15.95359638 -005.64551140 2 180.0000 3.0 Papi
21 -15.96347774 -005.64645343 2 -1.2600 3.0 Papi
20 -15.96192491 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
20 -15.96225995 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
14 -15.96312208 -005.64867411 82.02 0 Tower Viewpoint
15 -15.96179344 -005.64822577 -50.36 Ramp Start 1
1300 -15.96238032 -005.64819725 -129.45 gate jets Ramp Start 2
15 -15.96285880 -005.64779046 -181.04 Ramp Start 3
19 -15.95196179 -005.64670036 0 New Windsock 2
19 -15.96603475 -005.64630065 0 New Windsock 1

Copy and paste the above into <code>$SCENERY_BUILD_DIR/data/airports/FHSH.dat</code>. We can now run <code>genapts</code>:

genapts850 --input=data/airports/FHSH --work=./work --dem-path=SRTM-3 --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15
genapts850 --input=data/airports/FHSH.dat --work=./work --dem-path=SRTM-3 --airport=FHSH

== Process Landclass Data ==
We can download landclass data from GeoFabrik, specifically from http://download.geofabrik.de/africa/saint-helena-ascension-and-tristan-da-cunha.html. Download the *.shp files and extract them into <code>$SCENERY_BUILD_DATA/data/shapefiles</code>. Each type of file should go into its own folder. For example, copy all <code>gis_osm_landuse_a_free_1.*</code> files into <code>$SCENERY_BUILD_DATA/data/shapefiles/gis_osm_landuse_a_free_1/*</code>, as this is the format that TerraGear expects the files to be in. Usually, we would use a landmass (See Notes below) shapefile as our Default, but to simplify things for this tutorial, we can use the <code>gis_osm_landuse_a_free_1.shp</code> file, as the landmass file and this file are identical for this particular island. We are now ready to run <code>ogr-decode</code>:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/gis_osm_landuse_a_free_1/

We have to run <code>ogr-decode</code> for every land class (so urban, forest, lakes, roads etc). At each time, we need to specify the shapefile (the last argument in the above command) and the corresponding area material type that FlightGear recognizes ("Default") in the above command. For this tutorial, we will run the command just once to get the construct the entire island as a "Default" landclass.

== Bringing it all together ==
We can finally run <code>tg-construct</code> to bring everything together
tg-construct --priorities=/usr/local/share/TerraGear/default_priorities.txt --work-dir=./work --output-dir=./output/Terrain --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15 AirportArea AirportObj Default SRTM-3

The <code>$SCENERY_BUILD_DIR/output</code> will now contain the built scenery. Point your FG instance to this path using <code>--fg-scenery</code> and take a look at the built scenery!

== Notes ==
* There are two docker images, <code>flightgear/terragear:ws20</code> and <code>flightgear/terragear:latest</code>. The former corresponds to the 2.0 world scenery build, while the later points to the latest code. The latest container has several improvements and GDAL tools which can be used to manipulate shapefiles, but also unfortunately has bugs in the hgtchop and terrafit tools for SRTM-3 data. The best way is to use <code>flightgear/terragear:ws20</code> for elevation data processing, and <code>flightgear/terragear:latest</code> for everything else.
* The [https://osmdata.openstreetmap.de/data/land-polygons.html OSM coastlines data] is a good source for the landmass ("Default") terrain, but is a single file for the entire world.
* You can use the following command (found in the latest terragear docker image) to "crop" the shapefile to an area of interest:
ogr2ogr -clipsrc -6 -17 -5 -15 cut_landmass.shp land_polygons.shp
* As mentioned in the introduction, this tutorial is just a starting point. Have a look at the other TerraGear wiki articles. A good resource is also provided [https://forum.flightgear.org/viewtopic.php?t=35618 on the forum], which uses TerraGear GUI. You can use the concepts learned from there and run the commands in the docker image.

Howto:Complete TerraGear example using docker

2021-01-06T09:56:22Z

Fahim Dalvi:

This article aims to serve as a quick starting point for people wanting to build scenery using the dockerized version of the TerraGear scenery toolchain. This will allow users to build scenery on all popular operating systems including Windows, macOS and Linux without the hassle of building the terragear toolchain themselves. This is in no way a comprehensive introduction, but should be enough to get one used to the scenery generation process.

[[File:Saint Helena Island generated using dockerized TerraGear.jpg|thumb|An island generated using the docker image for the TerraGear toolchain]]

== Background ==
TerraGear requires three pieces of data for scenery generation:

# Elevation data: This data defines how high each point in the scenery or land is. One source for such data is http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm.
# Landclass data: This data defines what kind of "land" is under each point in the scenery or land is. For example, some point might be "urban" class, or "forest" class. One source for such data is http://download.geofabrik.de/, which is derived from OSM.
# Airport data: This data defines the position of runways, taxiways and other assorted airport information. One source for such data is the XPlane gateway.

TerraGear consists of five tools:

# hgtchop - Processing elevation data
# terrafit - Processing elevation data
# genapts - Processing airport data
# ogr-decode - Processing landclass data
# tg-construct - Generating the final scenery.

== Scenery location ==
We will build Saint Helena Island, an island in the Atlantic Ocean. Specifically, we will be building the island around [https://en.wikipedia.org/wiki/Saint_Helena_Airport Saint Helena Airport] (ICAO: '''FHSH''').

Its location is: DMS 15° 57′ 33″ S, 5° 38′ 45″ W, Decimal -5.645833 -15.959167

A good vantage point to see progress is to start FG with the following options:

--lon=-5.62000000 --lat=-16.00000000 --altitude=4000 --heading=310

The bounds for our build will be:
* Latitude: -6 to -5
* Longitude: -17 to -15

Let <code>$SCENERY_BUILD_DIR</code> be the directory containing all of our working files for this project.

== Getting docker running ==
The first step is to have docker installed and accessible through the command line. Run the following command to fetch the terragear toolchain:
docker pull flightgear/terragear:ws20

Next, start a docker container to access the terragear tools:

docker run -i -v $SCENERY_BUILD_DIR:/terragear-work/ -t flightgear/terragear:ws20 /bin/bash

Once this command runs successfully, the command line will now be a "window" into the docker container, allowing you to run the entire terragear toolchain. Because of the <code>-v</code> argument (bind mount), the container can see the contents of <code>$SCENERY_BUILD_DIR</code> will be visible at <code>/terragear-work/</code> inside the container.

== Process Elevation Data ==
The elevation data can be obtained from [http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm ViewFinderPanoramas], specifically, the [http://viewfinderpanoramas.org/dem3/SD30.zip SD30] and [SE30 http://viewfinderpanoramas.org/dem3/SE30.zip] tiles cover this island.

Extract and add to <code>$SCENERY_BUILD_DIR/data/SRTM-3/*.hgt</code>. Run the following commands in the docker container:

cd /terragear-work/
for f in data/SRTM-3/*.hgt; do hgtchop 3 "${f}" " work/SRTM-3"; done
terrafit work/SRTM-3

== Process Airport Data ==
'''FHSH''' is not available in FlightGear's <code>apt.dat</code>, so the airport information has to be fetched from elsewhere. The XPlane gateway is one possible source. For this sample project, we can use the following data from https://github.com/accek/fg-nav-fixups:

1 1023 1 0 FHSH St Helena
100 45.00 2 0 0.00 1 2 1 02 -15.96694276 -005.64575428 100 0 2 9 0 2 20 -15.94934298 -005.64615237 300 0 2 9 0 2
110 1 0.00 358.7100 New Taxiway 4
111 -15.96166211 -005.64927678
111 -15.96340503 -005.64926307
111 -15.96340434 -005.64836151
111 -15.96290056 -005.64836043
111 -15.96284142 -005.64854134
111 -15.96265507 -005.64854103
113 -15.96155909 -005.64854086
110 2 0.00 358.7100 New Taxiway 3
111 -15.94934844 -005.64635879 3 102
111 -15.94935248 -005.64663563 3 102
111 -15.94995561 -005.64662024 3 102
113 -15.95019415 -005.64634336
110 2 0.00 358.7100 New Taxiway 2
111 -15.96693818 -005.64554618 3 102
111 -15.96693596 -005.64524600 3 102
111 -15.96628657 -005.64526997 3 102
113 -15.96603006 -005.64556883
110 2 0.00 358.7100 New Taxiway 1
111 -15.96305635 -005.64765837 3 102
111 -15.96240410 -005.64767341 3 102
112 -15.96226078 -005.64761762 -15.96220044 -005.64756860 3 102
111 -15.96219925 -005.64745814 3 102
111 -15.96219005 -005.64624609 3 102
112 -15.96223439 -005.64613746 -15.96227201 -005.64609544 3 102
111 -15.96236947 -005.64606567
111 -15.96184016 -005.64607709 3 102
112 -15.96195708 -005.64616687 -15.96199469 -005.64621034 3 102
111 -15.96199881 -005.64627387 3 102
111 -15.96200448 -005.64744540 3 102
112 -15.96197248 -005.64759953 -15.96193665 -005.64765444 3 102
111 -15.96183543 -005.64768917 3 102
111 -15.96154350 -005.64769949 3 102
111 -15.96155909 -005.64854086
111 -15.96265507 -005.64854103
111 -15.96265481 -005.64818499
113 -15.96306600 -005.64818480 3 102
130 Airport Boundary
111 -15.95876878 -005.64712051
111 -15.96005216 -005.64729370
111 -15.96043831 -005.64731000
111 -15.96048880 -005.64864132
111 -15.96154716 -005.64921198
111 -15.96159626 -005.65014384
111 -15.96388391 -005.64953797
111 -15.96430513 -005.64699927
111 -15.96882642 -005.64692255
111 -15.96885682 -005.64412109
111 -15.94564642 -005.64456651
113 -15.94563863 -005.64716916
120 Hold
111 -15.96200516 -005.64660225 4 103
115 -15.96218383 -005.64660129
120 Linear Feature 5
111 -15.96210864 -005.64767019 1 101
112 -15.96206007 -005.64782922 -15.96201482 -005.64792776 1 101
115 -15.96188449 -005.64810582
120 Linear Feature 4
111 -15.96210864 -005.64767019 1 101
112 -15.96213878 -005.64782592 -15.96215760 -005.64789051 1 101
115 -15.96229199 -005.64808544
120 Linear Feature 3
111 -15.96156820 -005.64813668 20
111 -15.96263721 -005.64810368 20
111 -15.96263233 -005.64792345 20
115 -15.96304480 -005.64791075
120 Linear Feature 2
111 -15.96210864 -005.64767019 1 101
111 -15.96210128 -005.64660525 1 105
115 -15.96209919 -005.64630388
120 Linear Feature 1
111 -15.96154408 -005.64588717 1 105
111 -15.96184445 -005.64588139 1 105
112 -15.96204503 -005.64596036 -15.96210198 -005.64604073 1 105
111 -15.96209919 -005.64630388 1 105
112 -15.96217524 -005.64595582 -15.96225060 -005.64588070 1 105
111 -15.96236918 -005.64587174 1 105
115 -15.96269552 -005.64586403
21 -15.95361317 -005.64657631 3 180.0000 3.0 Papi
21 -15.95359638 -005.64551140 2 180.0000 3.0 Papi
21 -15.96347774 -005.64645343 2 -1.2600 3.0 Papi
20 -15.96192491 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
20 -15.96225995 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
14 -15.96312208 -005.64867411 82.02 0 Tower Viewpoint
15 -15.96179344 -005.64822577 -50.36 Ramp Start 1
1300 -15.96238032 -005.64819725 -129.45 gate jets Ramp Start 2
15 -15.96285880 -005.64779046 -181.04 Ramp Start 3
19 -15.95196179 -005.64670036 0 New Windsock 2
19 -15.96603475 -005.64630065 0 New Windsock 1

Copy and paste the above into <code>$SCENERY_BUILD_DIR/data/airports/FHSH.dat</code>. We can now run <code>genapts</code>:

genapts850 --input=data/airports/FHSH --work=./work --dem-path=SRTM-3 --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15
genapts850 --input=data/airports/FHSH.dat --work=./work --dem-path=SRTM-3 --airport=FHSH

== Process Landclass Data ==
We can download landclass data from GeoFabrik, specifically from http://download.geofabrik.de/africa/saint-helena-ascension-and-tristan-da-cunha.html. Download the *.shp files and extract them into <code>$SCENERY_BUILD_DATA/data/shapefiles</code>. Each type of file should go into its own folder. For example, copy all <code>gis_osm_landuse_a_free_1.*</code> files into <code>$SCENERY_BUILD_DATA/data/shapefiles/gis_osm_landuse_a_free_1/*</code>, as this is the format that TerraGear expects the files to be in. Usually, we would use a landmass (See Notes below) shapefile as our Default, but to simplify things for this tutorial, we can use the <code>gis_osm_landuse_a_free_1.shp</code> file, as the landmass file and this file are identical for this particular island. We are now ready to run <code>ogr-decode</code>:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/gis_osm_landuse_a_free_1/

We have to run <code>ogr-decode</code> for every land class (so urban, forest, lakes, roads etc). At each time, we need to specify the shapefile (the last argument in the above command) and the corresponding area material type that FlightGear recognizes ("Default") in the above command. For this tutorial, we will run the command just once to get the construct the entire island as a "Default" landclass.

== Bringing it all together ==
We can finally run <code>tg-construct</code> to bring everything together
tg-construct --priorities=/usr/local/share/TerraGear/default_priorities.txt --work-dir=./work --output-dir=./output/Terrain --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15 AirportArea AirportObj Default SRTM-3

The <code>$SCENERY_BUILD_DIR/output</code> will now contain the built scenery. Point your FG instance to this path using <code>--fg-scenery</code> and take a look at the built scenery!

== Notes ==
* There are two docker images, <code>flightgear/terragear:ws20</code> and <code>flightgear/terragear:latest</code>. The former corresponds to the 2.0 world scenery build, while the later points to the latest code. The latest container has several improvements and GDAL tools which can be used to manipulate shapefiles, but also unfortunately has bugs in the hgtchop and terrafit tools for SRTM-3 data. The best way is to use <code>flightgear/terragear:ws20</code> for elevation data processing, and <code>flightgear/terragear:latest</code> for everything else.
* The [https://osmdata.openstreetmap.de/data/land-polygons.html OSM coastlines data] is a good source for the landmass ("Default") terrain, but is a single file for the entire world.
* You can use the following command (found in the latest terragear docker image) to "crop" the shapefile to an area of interest:
ogr2ogr -clipsrc -6 -17 -5 -15 cut_landmass.shp land_polygons.shp
* As mentioned in the introduction, this tutorial is just a starting point. Have a look at the other TerraGear wiki articles. A good resource is also provided [https://forum.flightgear.org/viewtopic.php?t=35618 on the forum], which uses TerraGear GUI. You can use the concepts learned from there and run the commands in the docker image.

File:Saint Helena Island generated using dockerized TerraGear.jpg

2021-01-06T09:56:18Z

Fahim Dalvi: /* {{int:filedesc}} */

=={{int:filedesc}}==
{{Information
|description={{en|1=Saint Helena island generated using the docker image for the TerraGear toolchain}}
|date=2021-01-06
|source={{own}}
|author=[[User:Fahim Dalvi|Fahim Dalvi]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:TerraGear]]
[[Category:Docker]]
[[Category:Scenery]]

File:Saint Helena Island generated using dockerized TerraGear.jpg

2021-01-06T09:55:14Z

Fahim Dalvi: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=An island generated using the docker image for the TerraGear toolchain}}
|date=2021-01-06
|source={{own}}
|author=[[User:Fahim Dalvi|Fahim Dalvi]]
|permission=
|other versions=
}}

=={{int:license-header}}==
{{self|cc-by-sa-4.0}}

[[Category:TerraGear]]
[[Category:Docker]]
[[Category:Scenery]]

Howto:Complete TerraGear example using docker

2021-01-06T09:50:13Z

Fahim Dalvi: Created page with "This article aims to serve as a quick starting point for people wanting to build scenery using the dockerized version of the TerraGear scenery toolchain. This will allow users..."

This article aims to serve as a quick starting point for people wanting to build scenery using the dockerized version of the TerraGear scenery toolchain. This will allow users to build scenery on all popular operating systems including Windows, macOS and Linux without the hassle of building the terragear toolchain themselves. This is in no way a comprehensive introduction, but should be enough to get one used to the scenery generation process.

== Background ==
TerraGear requires three pieces of data for scenery generation:

# Elevation data: This data defines how high each point in the scenery or land is. One source for such data is http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm.
# Landclass data: This data defines what kind of "land" is under each point in the scenery or land is. For example, some point might be "urban" class, or "forest" class. One source for such data is http://download.geofabrik.de/, which is derived from OSM.
# Airport data: This data defines the position of runways, taxiways and other assorted airport information. One source for such data is the XPlane gateway.

TerraGear consists of five tools:

# hgtchop - Processing elevation data
# terrafit - Processing elevation data
# genapts - Processing airport data
# ogr-decode - Processing landclass data
# tg-construct - Generating the final scenery.

== Scenery location ==
We will build Saint Helena Island, an island in the Atlantic Ocean. Specifically, we will be building the island around [https://en.wikipedia.org/wiki/Saint_Helena_Airport Saint Helena Airport] (ICAO: '''FHSH''').

Its location is: DMS 15° 57′ 33″ S, 5° 38′ 45″ W, Decimal -5.645833 -15.959167

A good vantage point to see progress is to start FG with the following options:

--lon=-5.62000000 --lat=-16.00000000 --altitude=4000 --heading=310

The bounds for our build will be:
* Latitude: -6 to -5
* Longitude: -17 to -15

Let <code>$SCENERY_BUILD_DIR</code> be the directory containing all of our working files for this project.

== Getting docker running ==
The first step is to have docker installed and accessible through the command line. Run the following command to fetch the terragear toolchain:
docker pull flightgear/terragear:ws20

Next, start a docker container to access the terragear tools:

docker run -i -v $SCENERY_BUILD_DIR:/terragear-work/ -t flightgear/terragear:ws20 /bin/bash

Once this command runs successfully, the command line will now be a "window" into the docker container, allowing you to run the entire terragear toolchain. Because of the <code>-v</code> argument (bind mount), the container can see the contents of <code>$SCENERY_BUILD_DIR</code> will be visible at <code>/terragear-work/</code> inside the container.

== Process Elevation Data ==
The elevation data can be obtained from [http://viewfinderpanoramas.org/Coverage%20map%20viewfinderpanoramas_org3.htm ViewFinderPanoramas], specifically, the [http://viewfinderpanoramas.org/dem3/SD30.zip SD30] and [SE30 http://viewfinderpanoramas.org/dem3/SE30.zip] tiles cover this island.

Extract and add to <code>$SCENERY_BUILD_DIR/data/SRTM-3/*.hgt</code>. Run the following commands in the docker container:

cd /terragear-work/
for f in data/SRTM-3/*.hgt; do hgtchop 3 "${f}" " work/SRTM-3"; done
terrafit work/SRTM-3

== Process Airport Data ==
'''FHSH''' is not available in FlightGear's <code>apt.dat</code>, so the airport information has to be fetched from elsewhere. The XPlane gateway is one possible source. For this sample project, we can use the following data from https://github.com/accek/fg-nav-fixups:

1 1023 1 0 FHSH St Helena
100 45.00 2 0 0.00 1 2 1 02 -15.96694276 -005.64575428 100 0 2 9 0 2 20 -15.94934298 -005.64615237 300 0 2 9 0 2
110 1 0.00 358.7100 New Taxiway 4
111 -15.96166211 -005.64927678
111 -15.96340503 -005.64926307
111 -15.96340434 -005.64836151
111 -15.96290056 -005.64836043
111 -15.96284142 -005.64854134
111 -15.96265507 -005.64854103
113 -15.96155909 -005.64854086
110 2 0.00 358.7100 New Taxiway 3
111 -15.94934844 -005.64635879 3 102
111 -15.94935248 -005.64663563 3 102
111 -15.94995561 -005.64662024 3 102
113 -15.95019415 -005.64634336
110 2 0.00 358.7100 New Taxiway 2
111 -15.96693818 -005.64554618 3 102
111 -15.96693596 -005.64524600 3 102
111 -15.96628657 -005.64526997 3 102
113 -15.96603006 -005.64556883
110 2 0.00 358.7100 New Taxiway 1
111 -15.96305635 -005.64765837 3 102
111 -15.96240410 -005.64767341 3 102
112 -15.96226078 -005.64761762 -15.96220044 -005.64756860 3 102
111 -15.96219925 -005.64745814 3 102
111 -15.96219005 -005.64624609 3 102
112 -15.96223439 -005.64613746 -15.96227201 -005.64609544 3 102
111 -15.96236947 -005.64606567
111 -15.96184016 -005.64607709 3 102
112 -15.96195708 -005.64616687 -15.96199469 -005.64621034 3 102
111 -15.96199881 -005.64627387 3 102
111 -15.96200448 -005.64744540 3 102
112 -15.96197248 -005.64759953 -15.96193665 -005.64765444 3 102
111 -15.96183543 -005.64768917 3 102
111 -15.96154350 -005.64769949 3 102
111 -15.96155909 -005.64854086
111 -15.96265507 -005.64854103
111 -15.96265481 -005.64818499
113 -15.96306600 -005.64818480 3 102
130 Airport Boundary
111 -15.95876878 -005.64712051
111 -15.96005216 -005.64729370
111 -15.96043831 -005.64731000
111 -15.96048880 -005.64864132
111 -15.96154716 -005.64921198
111 -15.96159626 -005.65014384
111 -15.96388391 -005.64953797
111 -15.96430513 -005.64699927
111 -15.96882642 -005.64692255
111 -15.96885682 -005.64412109
111 -15.94564642 -005.64456651
113 -15.94563863 -005.64716916
120 Hold
111 -15.96200516 -005.64660225 4 103
115 -15.96218383 -005.64660129
120 Linear Feature 5
111 -15.96210864 -005.64767019 1 101
112 -15.96206007 -005.64782922 -15.96201482 -005.64792776 1 101
115 -15.96188449 -005.64810582
120 Linear Feature 4
111 -15.96210864 -005.64767019 1 101
112 -15.96213878 -005.64782592 -15.96215760 -005.64789051 1 101
115 -15.96229199 -005.64808544
120 Linear Feature 3
111 -15.96156820 -005.64813668 20
111 -15.96263721 -005.64810368 20
111 -15.96263233 -005.64792345 20
115 -15.96304480 -005.64791075
120 Linear Feature 2
111 -15.96210864 -005.64767019 1 101
111 -15.96210128 -005.64660525 1 105
115 -15.96209919 -005.64630388
120 Linear Feature 1
111 -15.96154408 -005.64588717 1 105
111 -15.96184445 -005.64588139 1 105
112 -15.96204503 -005.64596036 -15.96210198 -005.64604073 1 105
111 -15.96209919 -005.64630388 1 105
112 -15.96217524 -005.64595582 -15.96225060 -005.64588070 1 105
111 -15.96236918 -005.64587174 1 105
115 -15.96269552 -005.64586403
21 -15.95361317 -005.64657631 3 180.0000 3.0 Papi
21 -15.95359638 -005.64551140 2 180.0000 3.0 Papi
21 -15.96347774 -005.64645343 2 -1.2600 3.0 Papi
20 -15.96192491 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
20 -15.96225995 -005.64660719 90.0000 0 3 {@R}20-02{@@}{@Y}APRON
14 -15.96312208 -005.64867411 82.02 0 Tower Viewpoint
15 -15.96179344 -005.64822577 -50.36 Ramp Start 1
1300 -15.96238032 -005.64819725 -129.45 gate jets Ramp Start 2
15 -15.96285880 -005.64779046 -181.04 Ramp Start 3
19 -15.95196179 -005.64670036 0 New Windsock 2
19 -15.96603475 -005.64630065 0 New Windsock 1

Copy and paste the above into <code>$SCENERY_BUILD_DIR/data/airports/FHSH.dat</code>. We can now run <code>genapts</code>:

genapts850 --input=data/airports/FHSH --work=./work --dem-path=SRTM-3 --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15
genapts850 --input=data/airports/FHSH.dat --work=./work --dem-path=SRTM-3 --airport=FHSH

== Process Landclass Data ==
We can download landclass data from GeoFabrik, specifically from http://download.geofabrik.de/africa/saint-helena-ascension-and-tristan-da-cunha.html. Download the *.shp files and extract them into <code>$SCENERY_BUILD_DATA/data/shapefiles</code>. Each type of file should go into its own folder. For example, copy all <code>gis_osm_landuse_a_free_1.*</code> files into <code>$SCENERY_BUILD_DATA/data/shapefiles/gis_osm_landuse_a_free_1/*</code>, as this is the format that TerraGear expects the files to be in. Usually, we would use a landmass (See Notes below) shapefile as our Default, but to simplify things for this tutorial, we can use the <code>gis_osm_landuse_a_free_1.shp</code> file, as the landmass file and this file are identical for this particular island. We are now ready to run <code>ogr-decode</code>:

ogr-decode --max-segment 500 --area-type Default work/Default data/shapefiles/gis_osm_landuse_a_free_1/

We have to run <code>ogr-decode</code> for every land class (so urban, forest, lakes, roads etc). At each time, we need to specify the shapefile (the last argument in the above command) and the corresponding area material type that FlightGear recognizes ("Default") in the above command. For this tutorial, we will run the command just once to get the construct the entire island as a "Default" landclass.

== Bringing it all together ==
We can finally run <code>tg-construct</code> to bring everything together
tg-construct --priorities=/usr/local/share/TerraGear/default_priorities.txt --work-dir=./work --output-dir=./output/Terrain --min-lon=-6 --max-lon=-5 --min-lat=-17 --max-lat=-15 AirportArea AirportObj Default SRTM-3

The <code>$SCENERY_BUILD_DIR/output</code> will now contain the built scenery. Point your FG instance to this path using <code>--fg-scenery</code> and take a look at the built scenery!

== Notes ==
* There are two docker images, <code>flightgear/terragear:ws20</code> and <code>flightgear/terragear:latest</code>. The former corresponds to the 2.0 world scenery build, while the later points to the latest code. The latest container has several improvements and GDAL tools which can be used to manipulate shapefiles, but also unfortunately has bugs in the hgtchop and terrafit tools for SRTM-3 data. The best way is to use <code>flightgear/terragear:ws20</code> for elevation data processing, and <code>flightgear/terragear:latest</code> for everything else.
* The [https://osmdata.openstreetmap.de/data/land-polygons.html OSM coastlines data] is a good source for the landmass ("Default") terrain, but is a single file for the entire world.
* You can use the following command (found in the latest terragear docker image) to "crop" the shapefile to an area of interest:
ogr2ogr -clipsrc -6 -17 -5 -15 cut_landmass.shp land_polygons.shp
* As mentioned in the introduction, this tutorial is just a starting point. Have a look at the other TerraGear wiki articles. A good resource is also provided [https://forum.flightgear.org/viewtopic.php?t=35618 on the forum], which uses TerraGear GUI. You can use the concepts learned from there and run the commands in the docker image.

Howto:Work with AC3D files in Blender

2020-11-07T13:26:37Z

Fahim Dalvi: Added latest blender version (2.9) to explicitly show support of importer

Many [[FlightGear]] [[aircraft]] modellers prefer [[Blender]] as their 3D-modelling editor. Blender is a powerful, robust and open-source 3D modelling suite. FlightGear primarily uses the [[AC3D_file_format|AC3D file format]] (<code>.ac</code>) to model aircraft, [[scenery]] models, and many other things. With the AC3D file format first released in 1996<ref>http://fileformats.archiveteam.org/wiki/AC3D_Model</ref>, modern versions of Blender do not bother maintaining support for the format. However, add-ons exist to extend Blender's functionality in order to allow the import and export of these files.

{{TOC limit|3}}

== Importing and exporting AC3D files ==
{{note| Modern versions of Blender (2.5+) require an add-on to work with AC3D (<code>.ac</code>) files.}}
=== Addons ===

The prominent add-on for using AC3D files in Blender is called ''Blender-AC3D''. It has been forked from its original to provide support for Blender 2.8.

{| class="wikitable"
|-
! Blender version !! Addon !! Remarks
|-
| 2.80 - 2.90 || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=2.80|text=NikolaiVChr/Blender-AC3D (GitHub)}}. || NikolaiVChr's fork of majic79's add-on, with a special branch for Blender 2.80
|-
| 2.63 - 2.7a || {{github source|user=NikolaiVChr|repo=Blender-AC3D|branch=master|text=NikolaiVChr/Blender-AC3D (GitHub)}} || NikolaiVChr's fork of majic79's add-on. For more information read {{forum link|t=13442|title=Blender 2.6 AC3D Importer & Exporter}}
|-
| 2.62 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.62|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.62 (Abandoned)
|-
| 2.60 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.60|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.60 (Abandoned)
|-
| 2.59 || {{github source|proj=majic79|repo=Blender-AC3D|branch=BL2.59|text=majic79/Blender-AC3D (GitHub)}} || Branch of majic79's plugin targeting Blender 2.59 (Abandoned)
|-
| <2.5 || N/A || Versions of Blender below 2.5 include out of the box support for the AC3D file format, simply enable the add-on in <code>Preferences > Addons</code>
|}

==== Notes ====
* Before you export a model with this addon, make sure that you set the UV map and texture inside the material, not just inside the UV editor. See the video tutorial [https://www.youtube.com/watch?v=URMjoFSm5pk here].
* Before you export make sure to exit ''Edit Mode'' or some of your last changes won't be exported.
* Inside Blender when you want to see the textures, be sure to set the shader to GLSL (or for 2.7+ just set view mode to materials). Alternatively set textured solid in solid view.
* To see textured surfaces as they will be shown in FlightGear, go into the material texture and set the blend type to ''Multiply'' instead of the default ''Mix'' (the importer will also do this automatically). An example plane that will look very different if this is not done is the FGAddon aircraft {{fgaddon source|path=Aircraft/ASK13|commit=1363|text=ASK-13}}, notice the wingtips.
* The final model might display color mismatches (Texture color vs Material color) when viewed in Flightgear. Hand editing the [[AC files: Basic changes to textures and colors#Materials|materials]] section of the exported AC3D file might fix this.
* If you wonder where to put the scripts you could open blender's user preferences ({{Key press|Ctrl|Alt|U}}, or ''File > User Preferences'') tick for example Import/Export and extent the information concerning an existing script. Usually this throws the path. For for example Ubuntu 14.04LTS/Blender 2.79b it is: <code>/usr/share/blender/scripts/addons/</code>.
* Be aware that Blender only has greyscale for emission and ambient colors. If you want to export/import a color for those, import/export options gives you capability to choose to use Blenders mirror color for that.
* The importer will not fail if it does not locate a texture, instead it will issue warnings. Pull down the top bar to see if there was any, they will be orange lines.
* The exporter will not fail if it tries to save a texture without data, instead it will issue warnings. Pull down the top bar to see if there was any, they will be orange lines. Notice that since AC3D only support 1 texture per object, if multiple textures are attached to an object in Blender the last of the textures that has any data, if any, will be the one that get exported, but it will still warn about the missing data in the others, so take care.
* Orientation: The default settings in the plugin correspond to the FlightGear coordinate system (-X forward and Z up, also see: [[Howto:3D_Aircraft_Models]]). The default settings are: Forward -Z and Up Y.

You can report bugs with the addon [https://github.com/NikolaiVChr/Blender-AC3D/issues here], but please include problematic <code>.ac</code>/<code>.blend</code> files and their textures.

=== Importing ===

{{main article|Working with FlightGear models in Blender}}
{{note|If you do not see the option for <code>AC3D (.ac)</code> under <code>File > Import</code>, your add-on is either not installed, or not working correctly.}}
Once the add-on is installed, AC3D models can be imported in the same manner as any other model foramat into Blender by using the <code> File > Import > AC3D (.ac)</code> dialog.
[[File:Blender AC3D import dialog.png|thumb|This figure demonstrates how to import an AC3D model in Blender using a third-party addon.]]

{{Appendix}}
{{3d}}
[[Category:Modeling]]

Areas populated with osm2city scenery

2018-06-25T18:07:34Z

Fahim Dalvi: Fixed incorrect link for California scenery

This is a list of areas having [[osm2city.py|osm2city]] generated scenery available for download. The [http://osm2city.readthedocs.io/en/latest/using.html manual] describes how to use the sceneries in FlightGear.

== FlightGear Versions ==
The FlightGear version mentioned in the table below means:

{| class="wikitable"
! Version !! Compatibile FG versions !! Effects !! Choose which objects to show !! Remarks
|-
| (not given → most probably before 2017.1) || "all" || limited || all or nothing || large number of files and size
|-
| 2017.1 || 2017.x || limited || yes || (ditto)
|-
| 2017.2 || 2017.2 || traffic, regionalization || yes || For use with FG version 2017.2.1 you need the copy the following two files (texture atlas and corresponding light-map) into [[FGData]]/Textures/osm2city: [https://my.pcloud.com/publink/show?code=XZlBqaZeLq96OJd84Sidom3mWmEbhjIlJbk atlas_facades.png] and [https://my.pcloud.com/publink/show?code=XZqBqaZPWznrMcsdLJQ8zmtM60NRLJLXQBX atlas_facades_LM.png]
|}

== Available areas ==
{| class="wikitable"
! Download link !! Area !! In [[TerraSync]] !! Forum thread !! Min. FG version !! Created Date !! Created By !! [[Project3000]]<ref>Meaning that the scenery was generated respecting objects placed by Project3000, but does not contain it</ref> !! Remarks
|-
| [https://1drv.ms/u/s!AuIh-169bDZ9tlKlP3GQ1Ez1r64p w060n10]
| bottom=10 left=-60 top=20 right=-50 (Barbados) || || || 2017.2 || 2017-11-04 || dutchguy || ||
|-
| [https://1drv.ms/u/s!AuIh-169bDZ9tlPnC1UGd7CjdgMf w070n10]
| bottom=10 left=-70 top=20 right=-60 (Eastern Caribbean) || || || 2017.2 || 2017-11-04 || dutchguy || ||
|-
| [https://my.pcloud.com/publink/show?code=XZa8Nk7Z5jaeflLeCvS9VpyVWS3k28jKEASV LKPR]
| Area around LKPR Prague airport 14-14.75 East, 49.875-50.25 North || || || 2017.2 || 2017-10-08 || vanosten || March 2017 || Used parameter BUILDING_FORCE_EUROPEAN_INNER_CITY_STYLE=True. Contains a folder Roads_red, which when renamed to Roads shows in red where roads would not be lit (for testing)
|-
| [https://my.pcloud.com/publink/show?code=XZrMy3Ze3rXYVgAurYFp96YIHMj9X9ptLoy Switzerland]
| Swiss national boundaries || || || 2017.2 || 2017-05-23 || vanosten || March 2017 ||
|-
| [https://my.pcloud.com/publink/show?code=XZqjqaZtxBUwA5KJr5CeuqTYzk9Yk9KXbDk KBOS]
| bottom=59 left=4.5 top=62 right=6 || || || 2017.2 || 2017-05-20 || vanosten || March 2017 ||
|-
| [https://my.pcloud.com/publink/show?code=XZaSqaZsbS9ltAfHozgY335PnEIE4sPwutV ENBR]
| bottom=42.125 left=-72 top=42.625 right=-70.5 || || || 2017.2 || 2017-05-20 || vanosten || March 2017 ||
|-
| [https://onedrive.live.com/redir?resid=7d366cbd5efb21e2!1642&authkey=!APsD2Zn-Jq3m5OA&ithint=folder%2czip The Netherlands]
| [[File:EHoutline.png|thumb|150px]] || || || || || || ||
|-
| [https://onedrive.live.com/redir?resid=7d366cbd5efb21e2!1645&authkey=!AAx41T78jYrL4KI&ithint=file%2czip Southern UK]
| [[File:EGOutline.png|thumb|150px]] || || || || || || ||
|-
| [https://onedrive.live.com/redir?resid=7d366cbd5efb21e2!1646&authkey=!AFAFUx-rFpUiRPk&ithint=file%2czip Ireland]
| [[File:EIOutline.png|thumb|150px]] || || || || || || ||
|-
| [https://onedrive.live.com/redir?resid=7D366CBD5EFB21E2!1651&authkey=!APsD2Zn-Jq3m5OA&ithint=file%2czip Switzerland]
| [[File:LSOutline.png|thumb|150px]] || || || || || || ||
|-
| [https://drive.google.com/open?id=0B2CN49kDuXHgZ3U0LUFnU2ZJREE Phuket]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=30113 || || || || ||
|-
| [https://dl.dropboxusercontent.com/u/24846517/fg/osm2city/LOWI_OSM_buildings_20140928.tgz LOWI]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=19625 || || || || ||
|-
|-
| [https://drive.google.com/file/d/1aR1jF0AbeLkKk21SZc-Tg-0f3-GSg5nc/view?usp=sharing Europe/Spain]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32062&start=15 || 2017.2 || || || ||
|-
|-
| [https://drive.google.com/open?id=0B5TeZxXfefn3NUp4NkM2b1hPVDQ African/Canary islands]
| || || || || || || ||
|-
|-
| [https://drive.google.com/open?id=0B5TeZxXfefn3Vll5cGVEcndZMTg Europe/Portugal]
| || || || || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Poland]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Slovakia]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Lithuania]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Latvia]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Estonia]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Bulgaria]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Hungary]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [http://zorba-osm2city.s3-website.eu-central-1.amazonaws.com/ Europe/Romania]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32172 || 2017.1 || || || ||
|-
| [https://drive.google.com/open?id=0B5TeZxXfefn3VkViMDlCMXlrQUU Us/California]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32187 || 2017.1 || || || ||
|-
| [https://sites.google.com/site/ecuadorflightgear/ Ecuador]
| || || https://forum.flightgear.org/viewtopic.php?f=5&t=32254 || 2017.2 || 2017-11-20 || || ||
|}

[[Category:Scenery]]
[[Category:Lists]]

Shader requests

2011-05-24T06:16:36Z

Fahim Dalvi:

Please post your shader requests here, so that other people can more easily track what's going on, hopefully avoiding duplicate efforts.

= Currently work in progress =
== Water shader by gral (11/2010) ==
Please see: http://flightgear.org/forums/viewtopic.php?f=47&t=9386

= Open shader requests =

== Flags ==
is it possible to simulate the fluttering of flags in the wind using a shader?
I'd like to place some flags in the scenery for our FSWeekend presentation showing the logo of our sponsor. But attaching a flat surface to a a flagpole looks just to cheap.

See: http://flightgear.org/forums/viewtopic.php?f=47&t=9789

== Contaminated runways and taxiways (10/2010) ==
Ok I have no idea if this is possible, but this idea just came up in my mind: wouldn't it be very cool to apply this shader (actually a similar version of it) to runways and taxiways when it's raining? I know there's not much sunshine when it's raining, but I mean just the light-reflecting idea.

And you could get the visual effect of a wet runway or snow based on weather settings. (http://flightgear.org/forums/viewtopic.php?f=6&t=7383&p=70239#p70254)

To clearify the aspect/feature override part mentioned above here's a different use case I have in mind.
In a scene where it is raining you typically would want to show all material as being wet.
This can be implemented at several levels of realism. For a quick start I would increase specular reflection
and maybe darken diffuse in the top level StateSet. The darkening of materials could be made different for
several materials in the scene simply by setting a different uniform darkening value. Some objects in the scene
might implement wetness with a specular cubemap. In case of a road it might even contain puddles and use a planar
reflection of the scene. All these shader pieces implement the aspect "wetness" in different ways, where higher
fidelity implementations lower in the scene tree override the default implementation in the top level stateset.
And in case you want to disable "wetness" for the whole scene it should be possible to do so at the top level
stateset similar to how we are used to disable texturing, lighting etc. [http://flightgear.org/forums/viewtopic.php?f=47&t=10088&p=102583#p102583]

See: http://flightgear.org/forums/viewtopic.php?f=47&t=9386&start=120#p1005044

== Runway skid marks ==
It would be interesting to see if and how this mechanism could possibly be used to dynamically place skid marks on runways at runtime, so that landing aircraft can cause their own, new skid marks during touchdown.

See:
* http://flightgear.org/forums/viewtopic.php?f=5&t=2258&hilit=skid+marks&start=15#p30741
* http://flightgear.org/forums/viewtopic.php?f=6&t=7383&p=70239

== Precipitation effects for cockpit windows ==
Something like this could be very useful for my idea to get a decent rain / snow / ice effect to the cockpit glass with working wipers by simply changing the textures of an overlaying model.

See: http://flightgear.org/forums/viewtopic.php?f=6&t=7383&p=70239

= Ideas =

== Engine wake ==
Used to be available for a very alpha version of the 777-200 back in 2008, Although it was no longer supported by the sim. Perhaps someone who created it could enlighten us on what was the basis behind it and how we can create a new shader for engine wake.

== sky / atmosphere scattering ==
has implication on other shaders, and as far as I know, the sky dome can't have effects for the moment [http://flightgear.org/forums/viewtopic.php?f=47&t=10088&p=102583#p102583]
Ralf Stokholm Nielsen has implemented something similar in his thesis: [http://www2.imm.dtu.dk/pubdb/views/edoc_download.php/2554/pdf/imm2554.pdf]

== other material types ==
not all the world should have the "plastic" look of the OpenGL default shading equation ). Crops should have a fur-like lighting response. A first step has already occurred in the reflection shader that should have a metallic look. Research Cook-Torrance (should tell something to blender users) and Fresnel if you want references. First step here : http://wiki.gamedev.net/index.php/D3DBook:Lighting . Oren-Nayar should be perfect for seat fabric. [http://flightgear.org/forums/viewtopic.php?f=47&t=10088&p=102583#p102583]

== geometry shader for transforming to billboarded trees ==
geometry shader to transform points into huge number of billboarded trees (a la Outerra). The code should be modified to generate the set of points following the terrain in the first place, but something similar already exists to create night point lights. [http://flightgear.org/forums/viewtopic.php?f=47&t=10088&p=102583#p102583]

== procedural runway markings ==
set on top a dumb concrete/asphalt/whatever texture/material

== post-processing effects ==
(glow, motion blur, depth of field ) We already have redout/blackout, but could be enhanced by having a circular fading shape (you know when your field of view begins to shrink and you are not able to see on your sides) instead of a constant one [http://flightgear.org/forums/viewtopic.php?f=47&t=10088&p=102583#p102583]

== animation of roads ==
Especially during night, cars on roads and motorways can usually be seen very well. Wouldn't it be a great feature if cars could be simulated with shaders? That means, that during days, differently colored cars move on streets, and during night some lights are visible? Is that doable with shaders?
[[User:Stanisak|Stanisak]] 21:43, 4 December 2010 (UTC)

== motion blur, bloom & HDR ==

See forum post:

http://www.flightgear.org/forums/viewtopic.php?f=47&t=11229

Building FlightGear - Debian

2010-08-08T12:02:24Z

Fahim Dalvi: /* FlightGear data */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or GIT on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver.<BR>

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.org!)
*git, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (Not available for Lenny atm, see [[#Boost Library|Boost Library]] below.)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or GIT in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. <BR>
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions you have to replace these with the local paths or even <code>export</code> them during the process.

Follow the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively large (GIT about 3.5 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear GIT as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

Or to Fetch A bundle that can be Downloaded in parts :
cd $prefix
wget http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle

or
cd $prefix
wget http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle

the MD5 checksum is
2996221BD2B8AB7740F332F49396CF56

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun/fgrun/
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Building FlightGear - Debian

2010-08-07T18:29:10Z

Fahim Dalvi:

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or GIT on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver.<BR>

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.org!)
*git, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (Not available for Lenny atm, see [[#Boost Library|Boost Library]] below.)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or GIT in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. <BR>
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions you have to replace these with the local paths or even <code>export</code> them during the process.

Follow the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively large (GIT about 3.5 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear GIT as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

GIT:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and GIT:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

Or to Fetch A bundle that can be Downloaded in parts :
cd $prefix
wget http://peter-server.homelinux.net/fgdata/fgdata/fgdata.bundle

or
cd $prefix
wget http://flightgear.mxchange.org/pub/fgfs/fgdata.bundle

the MD5 checksum is
2996221BD2B8AB7740F332F49396CF56

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun/fgrun/
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Howto:Understand console output

2010-08-02T11:07:05Z

Fahim Dalvi:

This document lists '''[[FlightGear]] errors''', how to get rid of them and other '''console output'''. If FlightGear quits but does not give you any error, try increasing the [[FlightGear Launch Control#Debugging|Log Level]].

Errors can appear in various locations, but the most common one is the console (a black window), which pops up when you run fgfs.exe.

==Errors with known solutions==
===Airports/.... ... Done===
This is not an error. The message lets us know that [[TerraSync]] is updating the <tt>[[$FG_SCENERY]]/Airports</tt> directory.

===Base package check failed ... Found version [none] at: ...<br>Please upgrade to version:===
* FlightGear was unable to find the [[$FG_ROOT]] directory. Set it using the <tt>--fg-root=</tt> commandline option.
* When using [[CVS]] with binaries, the data must match the binary. You cannot use data from a different date than the binary's release date.

===condition: comparison without property[1] or value===
A condition (like <tt><less-than></tt> or <tt><equals></tt>) exists, without either:
* a property to check
* a value to check the property against

===Could not find at least one of the following objects for animation:===
This means that FlightGear is unable to find an object in a .ac file. Check the .xml file (where the animation is stored) to see if the object-names match those in the .ac file. If you are not the aircraft's author you can safely ignore such warnings.

===creating 3D noise texture... DONE===
Tells you that a new noise texture is created. It is not an error and can be ignored.

===Error: [Screen #0] GraphicsWindowWin32::setPixelFormat() - No matching pixel format found based on traits specified====
Try changing the [[FlightGear Launch Control#Page Four - Options and Run|BPP]] value of your FlightGear setup. If that does not work, your graphics card is probably not able to run FlightGear 1.9 and higher. Another graphics card, or an older FlightGear version will likely "fix" the problem.

===Error: bind() failed in make_server_socket()===
When using [[Howto: Multiplayer|multiplayer]] or socket input, this usually means you specified an invalid ip address or the port is in use. Note: for multiplayer, you don't need to use the ''--multiplay=in,...'' option at all, FlightGear (since version 1.0) figures out the proper setting automatically. Only use when you know what you are doing.

===Error Building Technique: findAttr: could not find attribute bool===
Make sure that your data and source (or binary) match. They must be from the same date, to provide the best performance.

===Error: connect() failed in make_client_socket()<br>SG_IO_OUT socket creation failed===
Your computer is not connected with the internet.

===Error: RenderTexture requires the following unsupported OpenGL extensions...===
Your graphics card doesn't support some graphics feature that FG requires. Update your drivers, change the BPP value and/or try disabling some of the visual goodies like [[3D Clouds]].

===Failed to find .... in apt.dat.gz===
You need to edit ATC/default.tower and ATC/default.atis. You can open these files with any text editor. Either remove or fix the entries containing your airports ICAO code (like KSFO).

===Failed to open file ...===
Check if the file exists on your system. If the missing file is a scenery object; be sure you have the latest [http://scenemodels.flightgear.org/download/SharedModels.tgz Shared Models] from the [[FlightGear Scenery Database]].

===Fatal error: mismatched tag ...===
In some .xml file, an opening tag (like <tt><sim></tt>) does not match its closing tag (like <tt></sim></tt>). This error is hard to track down, best method is to comment (place code between <nowiki></nowiki>) most of the aircraft. Then uncomment code one by one, until the error appears again.

===Fatal error: name must begin with alpha or '_'===
This error comes up when a property should be formed of which the name does not start with a letter of the alphabet or _. If this error only happens with certain planes, contact their authors.

===Fatal error: unclosed token===
A token (<nowiki></nowiki>) has been started, but not closes. Add <nowiki>--></nowiki> at the correct line.

===FGMultiplayMgr::MP_ProcessData: No such file or directory===
This is telling you that there's someone online on the multiplayerserver, using a plane that you do not have installed on your own system. In order to remove the error (and see the other plane) you have to install the plane that the other pilot is using.

===FGMultiplayMgr - No receiver port, Multiplayermode disabled===
FlightGear [[Howto: Multiplayer|multiplayer]] has not been set.

===FGPropertyManager::GetNode() No node found for ...<br> In component: ... unknown property ... referenced. Aborting===
FlightGear found a reference in the [[FDM]] to a non-existing property.

===FGPropertyManager::GetNode() No node found for ...<br> The property ... is undefined.===
FlightGear found a reference in the [[FDM]] to a non-existing property. Keep in mind that JSBSim reads the FDM from top to bottom. Properties should always be created before they are needed somewhere.

===Fgtzfile_read(): : Invalid argument<br>Fatal error: Timezone reading failed===
This one is caused by wrong line ending in a timezone file. Solution might be to download the Timezone/time.tab file manually from [http://gitorious.org/fg/fgdata/blobs/raw/master/Timezone/zone.tab Gitorious] (Right mouseclick > Save target as) and overwrite the file in <tt>[[$FG_ROOT]]/Timezone/time.tab</tt> with it.

===Found unexpected subsystem: system exiting. JSBSim failed to load aircraft and/or engine model===
You are probably trying to run an aircraft on a out-of-date version of FlightGear. The planes on the official download page are intended to be used with the latest version of FlightGear. Usage on any older systems may not work.

===freeglut (fgfs): Unable to create direct context rendering for window 'FlightGear'<br>This may hurt performance===
This reports that you do not have proper hardware accelerated 3D (direct rendering) configured.

===Gate ... doesn't seem to have routes associated with it===
A startup location in the [[Interactive Traffic#Ground networks|groundnetwork]] is not (properly) connected to a taxi route. Contact the airport author, or import the network to [[TaxiDraw]] and run the Verify network command to find the corrupted gate.

===glLinkProgram "" Failed===
Update your drivers; they have to support atleast OpenGL 2.0 for FlightGear 2.0 and later.

===loading scenario '...'===
This is not an error. It shows that an [[AI Systems#AI Models|AI scenario]] is loaded.

===Model not found: ...===
This one tells you that FlightGear was unable to find a certain file. The nice thing is that it also tells you excactly what file.

# Check if the file really does not exist at your computer.
# Try to locate the file in which the missing file is referenced. This is likely to be <tt>-set.xml</tt> in the root directory of the loaded [[aircraft]]. Between the <model> tags, the base model file is referenced. This file references to all other models that are displayed with the aircraft.
# Contact the aircraft author with a detailed bug-report, in which you state the excact location of the missing file and (if you found it) the file in which it is referenced.

===Nasal runtime error: nil used in numeric context===
This error is [[Nasal]] triggered by a Nasal file (the console should show what file (and line) and from where it was referenced). The Nasal script tried to do something with a [[Property Tree|property]] with an empty value. A solution is to fill the property before the Nasal is loaded. This can be done by setting the property in an [[aircraft]]'s <tt>-set.xml</tt> file or by adding a [[Nasal scripting language#Listeners and Signals|listener]] to the script.

[[Howto: Contact the developers|Contact the developers]] if this error is shown for a <tt>[[$FG_ROOT]]/Nasal/</tt> script.

===Near camera not rendering===
[[Image:Near_camera_off.png|500px]]

If you screen looks like the image above; make sure you have at least [[OSG]] version 2.7.6.

===No render bin name specified in render bin section===
Update [[SimGear]] (or binary) and your data directory.

===No render bin number specified in render bin section===
Update [[SimGear]] (or binary) and your data directory.

===... not a valid win32 application===
This Windows error could have various reasons to pop up. Usually, the file that is causing troubles is mentioned. Re-installing this file might solve the problem.

===OBJECT_SIGN: unsupported glyph `.'===
Check the OBJECT_SIGN lines in the .stg file of the tile that was loaded when this error showed up.

===OpenAL error <AL_INVALID_VALUE>: bind source <alGenSources><br>Failed to generate audio source.===
This error is probably displayed because of some misdirected audio settings in the [[aircraft]]s setup. Check the -sound.xml file of the aircraft and see if all files refered to really exist. If not, try to contact the author of the plane, so he can fix the problem in the [[FlightGear CVS|CVS]] version or solve the problem yourself and let someone commit the patch.

===OpenAL error (AL_INVALID_VALUE): constructor (alBufferData)<br>Fatal error: Failed to buffer data.===
Disabling sound is a temporarily solution for this problem.

===osgDB ac3d reader: could not find texture...===
See [[#Failed to open file ...|Failed to open file ...]]

===osgDB ac3d reader: detected surface with less than 3 vertices!===
In one of the loaded models a non-existing surface is found. This can be a single line (sometimes used to simulate thin wires) or a fault in the model.

===Program's vertex attrib binding ..., usrAttr...===
Tells you that an effect binded certain attributes to a [[Shaders|shader]].

===QNAN===
(Q)NAN stands for (Quiet) Not A Number, produced by 0/0 or other floating point break downs. There can be various causes for this:
* Using a "flap start" value of 0 in the [[YASim]] [[FDM]]. Use some small value like 0.001 instead.

===Scaling image...===
This means a texture, whether in the scenery on your aircraft or anyone elses (when multiplayer is enabled), is not sized to powers of two. All textures in FlightGear have to be sized to power of two (eg. 16*16, 32*64, 32*1024). As of version 1.9 textures are resized automaticly, but it does slow your computer down, so it's better to resize the noted textures.

===ssgInit called without a valid OpenGL context===
In short, your GL libraries are broken. So far only Red Hat 7.x users have experienced this (see http://www.redhat.com/bugzilla/show_bug.cgi?id=18867). The only solutions are possibly complicated ones: you can either change distributions (most of us prefer Debian) or upgrade/downgrade your Mesa libs.

===The system cannot find the file specified===
If you are running Windows Vista; start by looking in <tt>C:\Users\Owner\AppData\Local\VirtualStore</tt> and seeing if you have a folder called FlightGear in there. If you do, cut-and-paste (merge) that one with <tt>C:\Program Files\Flightgear</tt> and try to launch FlightGear again.

'''Hint:''' you may need to go under Tools and Folder Options to specify "Show Hidden/System Files and Folders" in order for AppData to be visible.

===Time zone reading failed===
This is probably caused by a line-ending problem in the timezone files. Win32 users can resolve the problem by downloading a DOS to UNIX conversion utility available at http://www.nottingham.ac.uk/~eazdluf/d2u.zip. Run as `d2u *.tab` from within the timezone directory to fix your timezone files

===Traffic manager could not find airport===
There is either an airport missing from apt.dat, or there is a wrong ICAO code in a [[Interactive Traffic#Building Traffic Files|traffic file]]. An airport missing from apt.dat could be due to a recent opening.

===Unable to choose requested pixel format===
Error should be solved as of version 1.9. If not, try changing your [[FlightGear Launch Control#Page Four - Options and Run|BPP]] and/or resolution.

===Unable to find airport details for .... in FGTower::Init()===
This error can be surpressed by disabling [[Interactive Traffic|AI Traffic]], via the AI/ATC [[menu]].

The error appears when an airport in <tt>[[$FG_ROOT]]/Airports/apt.dat.gz</tt> cannot be found in <tt>[[$FG_ROOT]]/ATC/default.tower</tt> and <tt>[[$FG_ROOT]]/ATC/default.atis</tt>. Renaming the airports in the apt.dat.gz file ór in both default ATC files will fix the problem.

===Unable to open aircraft directory===
The [[aircraft]] that you are trying to run most likely relies on another aircraft, which you did not install (yet). The error shows what aircraft, so go download that one!
=== Unexpected tag '...' found in YASim aircraft description===
FlightGear found a non-existing tag in the [[FDM]] of the aircraft you are trying to launch. If you have not changed the original aircraft, contact the aircraft author. Else, check the FDM througly for mistakes.

=== Unknown ... aircraft: ... defaulting to C172 ===
FlightGear is unable to load the forced [[FDM]] (set through <tt>--fdm=...</tt> or via <tt>Advanced > Flight Model</tt> in [[FGRun]]) for this aircraft. FlightGear automatically picks the right FDM for each aircraft, so there is no need to set it manually, unless you know what you are doing. In the Flight Model dialog of FGRun, set the FDM to <tt>jsb</tt>; that is the "auto setting".

===Unknown exception to the main loop. Aborting... <br>Possible cause: No such file or directory===
This error could have a variety of sources, among them missing files but also other things. Increasing the [[FlightGear_Launch_Control#Debugging|log level]] to debug and repeating excactly what you did when the error came up, might provide some more information on what FlightGear was doing when the error occurred.
* Setting your [[FlightGear Launch Control#Page Four - Options and Run|BPP]] to a lower value might work.
* Changing the resolution to a smaller one might work as well.

===WARNING: Couldn't convert texture...===
You are trying to run an aircraft not compatible with your FlightGear version. Most of the time, this error appears when you fly an aircraft, textured with .png files on versions older than 1.9. Convert the textures manually to .rgb or upgrade your FlightGear version.

===Warning: Picked up TriangleIntersect===
Reduce your [[FlightGear Launch Control#Debugging|Log Level]] to alert. Or [[Showstoppers|send the fgfs output to /dev/null (unix systems) or 2>nul (Windows)]]. The errors might still be shown, but do not affect the sim anymore.

===Warning: TangentSpaceGenerator: unknown primitive mode 9===
This is an [[OSG]] error, showing up when an effect needs tangent vectors, but polygons are not support. The error itself can be ignored, altough some [[shaders]] may look wrong. Shader developers should try to minimise the use of polygons and use triangles and quads instead.

===YASim SOLUTION FAILURE: Solution failed to converge after 10000 iterations===
Some control in the [[YASim]] [[FDM]] is too weak, according to YASim, to control the aircraft. An effectiveness tag will be required in the FDM to solve this error.

===YASim SOLUTION FAILURE:<br>Zero length fuselage===
There is a problem in the [[FDM]]. A fuselage section with similar ax and ay was created. Change the ax and/or ay values to match the aircraft.

==Errors without known solutions==
Please take a look at the upcoming errors and see if you know a solution to get rid of them. Your additions are grealy appreciated!

===AL Error (fx): Invalid Value at pitch and gain===

===AL Error (sound manager): Invalid Operation at update===

===AL Error (sound manager): Invalid Value at buffer add data<br>No such buffer!===

===Failed to execute command nasal===

===Failed to tie property ... to object methods===
A JSBSim error.

===FGMultiplayMgr::MP_ProcessData - message from ... has invalid length!===

===FGMultiplayerMgr::Open - Failed to bind recieve socket===

===GPS: malformed route, index=1===

===Mesa 7.3 implementation error: bad texture level in r300UploadSubImage===
http://www.flightgear.org/forums/viewtopic.php?f=2&t=6706&start=0&st=0&sk=t&sd=a

===Nasal runtime error: stack overflow===

===No image file for texture, using white===
A [[Shaders|shader]] error

===No path in /sim/sound/path===

===OpenAL error (AL_ILLEGAL_COMMAND): set_source_pos===

===OpenAL error (AL_ILLEGAL_COMMAND): set_volume===

===PT_vs_hpt: ran out of layers===

===Warning: detected OpenGL error 'invalid value' after RenderBin::draw(,)===

===Warning: GraphicsWindowWin32::grabFocus() - Failed grabbing the focus===

===WARNING: PUI: Too many live puInterfaces open at once!===
Appears when printing large outputs (very) frequently on the screen.

===Warning: State::drawQuads(0, 154400) too large handle in remapping to ushort glDrawElements===

[[Category:Howto|Get rid of common errors]]

[[fr:Howto: Débarrassez-vous des erreurs les plus fréquentes]]

Building FlightGear - Debian

2010-08-01T15:50:40Z

Fahim Dalvi: /* fgrun */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or CVS on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver.<BR>

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.org!)
*cvs, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (Not available for Lenny atm, see [[#Boost Library|Boost Library]] below.)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or CVS in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. <BR>
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions you have to replace these with the local paths or even <code>export</code> them during the process.

Follow the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively large (CVS about 2 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear CVS as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

CVS:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and CVS:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

CVS:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and CVS:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

Or to Fetch A bundle that can be Downloaded in parts :
cd $prefix
wget http://peter-server.homelinux.net/fgdata/fgdata/fgdata.bundle

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun/fgrun/
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Using TerraGear

2010-07-31T19:07:12Z

Fahim Dalvi: /* Elevation data */ Small Typo

[[Image:Terragearprocesschart.png|thumb|TerraGear Process Flow Chart]]
The [[TerraGear]] software project supports [[FlightGear]] by creating the files used by FlightGear to represent the elevation and texture of the earth, including airports, cities, fields, forests, rivers, roads and so on. The TerraGear software reads data files containing ground elevation, airport locations and layouts, geographical land-cover data, and more, and produces the scenery files used by FlightGear to represent the terrain of the world.

For simplicity and convenience, most FlightGear users simply download the plug-and-play scenery files from the FlightGear scenery server, or use [[TerraSync]] to automatically download scenery as needed. But there is a variety of reasons you might want to use TerraGear to produce your own terrain files, rather than downloading the standard FlightGear scenery.

For instance, if you use [[TaxiDraw]] to modify/improve information about an [[:Category:Airports|airport]]'s taxiway/apron layout, you might wish to see how that modified airport would look in the scenery before deciding you're happy with the results. Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher-resultion vector data (vmap1, Tiger, osm) to get better roads/streams. For all these reasons, learning how to use TerraGear is a good idea.

==Obtaining TerraGear==
You can either build TerraGear yourself, or download a pre-compiled binary. The later is the easiest and advised for starters.

* '''Option 1 - Download TerraGear pre-compiled (recommended for beginners) on Windows'''
*# Download the latest TerraGear-cs-Win..-....zip file (check what bits version you run!) from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/.
*# Create or choose a directory to hold the TerraGear tools.
*# Unzip the package into a sub-directory named <tt>Terragear/</tt> in the base directory.

* '''Option 2 - Compile TerraGear from source code''' as explained in [[Building TerraGear|this article]].

''Note:'' You might need default_priorities.txt from the mapserver [http://mapserver.flightgear.org/git/?p=terragear-cs;a=blob_plain;f=src/BuildTiles/Clipper/default_priorities.txt;h=4bb644a265ffc978a4303aad79169ace7ec1f043;hb=61ac48f3e56941b82aeb35960252c6ec4b7388d4 Git respository] See this forum thread for details: [http://www.flightgear.org/forums/viewtopic.php?f=5&p=77950]

==Using TerraGear==
First, choose the boundaries for the area of scenery you want to build, in terms of latitude and longitude. The smaller the area of scenery you generate, the smaller the amount of data you will need, and the less CPU time it will take. For example, if you are just interested in generating a new airport layout at 12.3W 34.4N, then simply generating the scenery between 12W 34N and 13W 35N would be sufficient.

Write down the bounding box (minimum and maximum longitude and latitude) for the scenery you want to generate. Remember that West and South are negative - i.e. 4W 10S would be -4, -10. Try not to get mixed up, otherwise you'll end up generating scenery or airports on the other side of the planet!

You'll be dealing with multiple different types of data in various formats. Create a new directory for your scenery work. Within that directory, create the following sub-directories:

* '''data/''' - for raw and pre-processed data (eg elevation files)
* '''output/''' - for the scenery files you will create
* '''work/''' - for data that has been processed (eg by shape-decode) and is ready to be munged into scenery

===Obtaining and processing data===
Terragear uses three different kinds of information to generate scenery:

# The elevation of the land (provided by SRTM)
# The location and layout of airports (provided by apt.dat or a custom .dat)
# Whether a given lat/lon is sea, land, city, forest, town, road, railway (provided by VMAP0, CORINE etc. or custom shapefiles)

This article describes how obtain and process each of these types of data in order, and bring it together for use by FlightGear. The order of these steps is important. For example, the airport data step needs the elevation data to determine the elevation of the airports and thus you should start with preparing elevation data.

'''<u>Please note:</u> for inclusion in the official FlightGear scenery, all data <u>must</u> come from [[GNU GPL]] compatible sources!'''

====Elevation data====
The best elevation data currently available is from the Shuttle Radar Topography Mission (SRTM). There are two types of SRTM data:
* Highly accurate 1-arcsecond resolution data, known as SRTM-1, for the USA
* Less accurate 3-arcsecond data, known as SRTM-3, for the rest of the world.
From now on, we'll assume you are using SRTM-3 data. Unless otherwise noted, the process for SRTM-1 is identical.

You can download the appropriate data from http://dds.cr.usgs.gov/srtm/version2_1/. You want all .hgt.zip files covering your region of interest. Depending on the size of your scenery, there may be quite a few. Download them to <tt>data/SRTM-1/</tt>(or SRTM-3/SRTM-30 depending on the type you downloaded) in your base directory. (Genapts looks for a few known, hardcoded elevation data directories in it's working directory. SRTM-30 is one of them and this is the least confusing in that list. Note: W.E.F. 31st July 2010, the genapts tool now also looks for SRTM-1/SRTM-3 directories. If you are using an older version, please supply the directories using --dem-path)

Now we've got the data, we need to convert it into something of use to TerraGear. First, you need to unzip each of the .hgt files. After that, open the commandline (Windows: <tt>Start > Run > cmd.exe</tt>) and change into the base directory (<tt>cd .../.../TerraGear</tt>).
* '''NOTE:''' If you want to create a batch-file, replace <tt>%f</tt> with <tt>%%f</tt>, see [http://technet.microsoft.com/en-us/library/bb490909.aspx]
* '''NOTE:''' For SRTM-1 data, replace the <tt>3</tt> by a <tt>1</tt> in the first argument to hgtchop

For Windows:
for %f in (./data/SRTM-30/*.hgt) do ./Terragear/hgtchop.exe 3 %f ./work/SRTM-30

For Linux:
for i in $PWD/data/SRTM-3/*.hgt; do ./Terragear/hgtchop 3 $i $PWD/work/SRTM-3; done

Now you will get a lot of .arr.gz files in your work/SRTM-3/ directory. We need to convert these to the .fit.gz format. Run the commandline again with
* '''NOTE:''' the space and dot at the and are important!

For Windows:
./Terragear/terrafit.exe work/SRTM-3

For Linux:
./Terragear/terrafit work/SRTM-3

====Airport data====
Now we've got elevation data, we can generate our airports. First, create a <tt>data/airports/</tt> directory and copy in your apt.dat file. This may be direct from your FlightGear data package (though you'll need to unzip it), or it may be one that you've modified with [[TaxiDraw]].

The command to create airports is "genapts". Run it without any arguments to see the various command-line options.

If it is simply run with a specified apt.dat and work directory, it will generate airport layouts for every airport in the file, which can take a long time.

If you are just creating a single airport and you know the ICAO ID (e.g. [[KSFO]], EGPH, EG32), use is as follows from your root scenery directory (i.e. the directory above your data, work and output directories). If you use an apt.dat file with one single airport in it you should omit the "--airport" parameter.

genapts --input=data/airports/apt.dat --work=./work --airport=<AIRPORT_ID>

If you are generating a larger set of scenery, then you can specify the minimum and maximum longitude and latitude.

Genapts will create two sub-directories in your work directory:
* AirportArea/
* AirportObj/

These contain the definitions of the airport layout and any objects present (e.g. windsocks).

====Landuse data====
The final piece of data we need to generate is the landuse data. In general, this is taken from the VMAP0 dataset as shapefiles from the scenery database mapserver, but other sources can also be used.

The landuse data can be split into a number of different types:

* '''Landmass''' separates the land from the sea. It is used as a mask for all other data. The most commonly used is the VMAP0 Landmass, but GSHHS can also be used.
* '''Land use data:''' defines whether a piece of land is forest, urban, sand, lava, glacier etc. These are usually VMAP0 data, defined as polygons.
* '''Line data:''' includes railroads, streams, roads. Typically VMAP0, but also Open Street Map for roads.
* '''Point data:''' is currently only used for defining towns.

By far the easiest way to get this data is to download shapefiles from the wonderful [http://mapserver.flightgear.org MapServer]. The MapServer lets you download the shapefiles for any selected scenery area. Click on the "Download Shapefiles" link (or go direct: http://mapserver.flightgear.org/download.psp). Enter in the bounding box of the scenery you want to generate, select the type of shapefile data you want, and click download. For basic scenery, get everything listed under VMap0 (with prefix v0_).

Download each shapefile into a <tt>data/shapefiles/</tt> directory.

You can load these shapefiles into a GIS editor such as [[QGIS]] or GRASS to view and edit. This is a good idea to verify you have the correct files! Later on, you can experiment with replacing various shapefiles with other versions (GSHHS for coastline, OSM for roads etc.).

The next step is to decode the shape-files into TerraGear format using the '''ogr-decode''' command.

There are three important command-line arguments for ogr-decode:
* the destination directory for the decoded data
* the location of the shapefile's directory
* the material type

Each shape-file corresponds with one of the material types defined in the materials.xml files. The mapping is pretty obvious. For example, v0_mixedcroppasturecover maps to MixedCropPastureCover. Note that the material types are case-sensitive, so it is a good idea to refer to the <tt>[[$FG_ROOT]]/materials.xml</tt> file to hand so you can check. The exception is v0_landmass, which MUST be mapped onto the type Default.

Additionally, there are a number of optional arguments, to indicate the width of line data (for roads, streams, railways), how large to make point data (for towns) and how long the longest straight line is allowed to be.

For example, to decode the v0_landmass shapefile, you use the following command:

ogr-decode --max-segment 500 --area-type Default work/Landmass data/shapefiles/v0_landmass

To create streams of width 10 metres

ogr-decode --max-segment 500 --line-width 10 --area-type Stream work/Stream data/shapefiles/v0_stream

To generate some towns about 1km across

ogr-decode --point-width 500 --area-type Town work/Town data/shapefiles/v0_town

Run this command for each shapefile in the set.

==Generating scenery==
You will now have a work directory looking something like this:

AirportArea SRTM-30
AirportObj Stream
Bog IrrCropPastureCover Town
Lake Urban Landmass
Railroad DryCropPastureCover Road
EvergreenBroadCover Marsh Sand
MixedCropPastureCover ScrubCover
GrassCover MixedForestCover Shared

Now we can actually generate the scenery. This is done by the fgfs-construct command. Run the command with "--help" to get usage information.

We need to define:
* the work (--work-dir) and output (--output-dir) directories
* the center of the scenery we want to generate (--lat, --lon)
* the radius (--xdist, --ydist) from which to generate
* All the work directories to include in the scenery.

For example:
fgfs-construct --work-dir=./work --output-dir=./output --lon=55 --lat=60 --xdist=3 --ydist=3 \
AirportArea SRTM-30 AirportObj Stream Bog IrrCropPastureCover Town Lake Urban Landmass Railroad \
DryCropPastureCover Road EvergreenBroadCover Marsh Sand MixedCropPastureCover ScrubCover GrassCover \
MixedForestCover

When this finishes, the output directory will contain a scenery sub-tree.

Point to it by setting either [[$FG_SCENERY]] or by using the --fg-scenery command-line option to fgfs, and give your new scenery a try!

==Troubleshooting==
Below is a list of common problems and solutions. If in doubt - Google it. Many problems (particularly when compiling TerraGear) have been hit before:

* Crashes in genapts. Sometimes genapts will crash when dealing with a particular airport. In that case, try running it again with the --start-id argument to start at the airport it failed on, and the --nudge argument which tries to nudge the calculations in the right direction.
* fgfs-construct Killed. The fgfs-construct process may kill itself if it is using too many system resources. Increasing the values for setrlimit in src/BuildTiles/Main/main.cxx is the best solution.
* Airports appear in the bottom of holes, or there are spaces between the airports and the scenery. This typically happens when genapts is unable to find the correct elevation data, or the elevation data changed between running genapts and shape-decode. Try generating a single airport in your scenery area using genapts, and look at the output. In particular, make sure there is a work/SRTM-30 directory.
* Only the airports appear in the scenery. There are three typical causes for this:
** You didn't download the correct shapefiles for the area.
** You haven't run shape-decode on the v0_landmass shapefile as Default
** You didn't include the correct directories in fgfs-construct.
* Generate scenery includes data removed from the shapefiles. If you are editing shapefiles, you need to delete the appropriate work subdirectory before running shape-decode. Otherwise your changes will be in addition to those already present.
* All the scenery is flat and at sea-level. Typically this is because you didn't include any elevation data in your fgfs-construct command. Make sure there's a STRM-30 directory included in the command-line.
* All terrain copies the material of a certain shapefile. You have probably forgotten to put each of the downloaded shapefiles in a seperate directory inside the Data/shapefiles directory.

{{Terra}}

[[Category:Scenery enhancement]]

Using TerraGear

2010-07-31T19:06:37Z

Fahim Dalvi: /* Elevation data */

[[Image:Terragearprocesschart.png|thumb|TerraGear Process Flow Chart]]
The [[TerraGear]] software project supports [[FlightGear]] by creating the files used by FlightGear to represent the elevation and texture of the earth, including airports, cities, fields, forests, rivers, roads and so on. The TerraGear software reads data files containing ground elevation, airport locations and layouts, geographical land-cover data, and more, and produces the scenery files used by FlightGear to represent the terrain of the world.

For simplicity and convenience, most FlightGear users simply download the plug-and-play scenery files from the FlightGear scenery server, or use [[TerraSync]] to automatically download scenery as needed. But there is a variety of reasons you might want to use TerraGear to produce your own terrain files, rather than downloading the standard FlightGear scenery.

For instance, if you use [[TaxiDraw]] to modify/improve information about an [[:Category:Airports|airport]]'s taxiway/apron layout, you might wish to see how that modified airport would look in the scenery before deciding you're happy with the results. Maybe the official scenery is too detailed for your slow machine, and you'd like to build terrain using a digital elevation model (DEM) with poorer resolution, to decrease the number of polygons and thus improve your framerates. Or maybe you've got a fantastically fast machine, and you want to build your own terrain using higher-resultion vector data (vmap1, Tiger, osm) to get better roads/streams. For all these reasons, learning how to use TerraGear is a good idea.

==Obtaining TerraGear==
You can either build TerraGear yourself, or download a pre-compiled binary. The later is the easiest and advised for starters.

* '''Option 1 - Download TerraGear pre-compiled (recommended for beginners) on Windows'''
*# Download the latest TerraGear-cs-Win..-....zip file (check what bits version you run!) from ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/.
*# Create or choose a directory to hold the TerraGear tools.
*# Unzip the package into a sub-directory named <tt>Terragear/</tt> in the base directory.

* '''Option 2 - Compile TerraGear from source code''' as explained in [[Building TerraGear|this article]].

''Note:'' You might need default_priorities.txt from the mapserver [http://mapserver.flightgear.org/git/?p=terragear-cs;a=blob_plain;f=src/BuildTiles/Clipper/default_priorities.txt;h=4bb644a265ffc978a4303aad79169ace7ec1f043;hb=61ac48f3e56941b82aeb35960252c6ec4b7388d4 Git respository] See this forum thread for details: [http://www.flightgear.org/forums/viewtopic.php?f=5&p=77950]

==Using TerraGear==
First, choose the boundaries for the area of scenery you want to build, in terms of latitude and longitude. The smaller the area of scenery you generate, the smaller the amount of data you will need, and the less CPU time it will take. For example, if you are just interested in generating a new airport layout at 12.3W 34.4N, then simply generating the scenery between 12W 34N and 13W 35N would be sufficient.

Write down the bounding box (minimum and maximum longitude and latitude) for the scenery you want to generate. Remember that West and South are negative - i.e. 4W 10S would be -4, -10. Try not to get mixed up, otherwise you'll end up generating scenery or airports on the other side of the planet!

You'll be dealing with multiple different types of data in various formats. Create a new directory for your scenery work. Within that directory, create the following sub-directories:

* '''data/''' - for raw and pre-processed data (eg elevation files)
* '''output/''' - for the scenery files you will create
* '''work/''' - for data that has been processed (eg by shape-decode) and is ready to be munged into scenery

===Obtaining and processing data===
Terragear uses three different kinds of information to generate scenery:

# The elevation of the land (provided by SRTM)
# The location and layout of airports (provided by apt.dat or a custom .dat)
# Whether a given lat/lon is sea, land, city, forest, town, road, railway (provided by VMAP0, CORINE etc. or custom shapefiles)

This article describes how obtain and process each of these types of data in order, and bring it together for use by FlightGear. The order of these steps is important. For example, the airport data step needs the elevation data to determine the elevation of the airports and thus you should start with preparing elevation data.

'''<u>Please note:</u> for inclusion in the official FlightGear scenery, all data <u>must</u> come from [[GNU GPL]] compatible sources!'''

====Elevation data====
The best elevation data currently available is from the Shuttle Radar Topography Mission (SRTM). There are two types of SRTM data:
* Highly accurate 1-arcsecond resolution data, known as SRTM-1, for the USA
* Less accurate 3-arcsecond data, known as SRTM-3, for the rest of the world.
From now on, we'll assume you are using SRTM-3 data. Unless otherwise noted, the process for SRTM-1 is identical.

You can download the appropriate data from http://dds.cr.usgs.gov/srtm/version2_1/. You want all .hgt.zip files covering your region of interest. Depending on the size of your scenery, there may be quite a few. Download them to <tt>data/SRTM-1/</tt>(or SRTM-3/SRTM-30 depending on the type you downloaded) in your base directory. (Genapts looks for a few known, hardcoded elevation data directories in it's working directory. SRTM-30 is one of them and this is the least confusing in that list. Note: W.E.F. 31st July 2010, the genapts tool now alos looks for SRTM-1/SRTM-3 directories. If you are using an older version, please supply the directories using --dem-path)

Now we've got the data, we need to convert it into something of use to TerraGear. First, you need to unzip each of the .hgt files. After that, open the commandline (Windows: <tt>Start > Run > cmd.exe</tt>) and change into the base directory (<tt>cd .../.../TerraGear</tt>).
* '''NOTE:''' If you want to create a batch-file, replace <tt>%f</tt> with <tt>%%f</tt>, see [http://technet.microsoft.com/en-us/library/bb490909.aspx]
* '''NOTE:''' For SRTM-1 data, replace the <tt>3</tt> by a <tt>1</tt> in the first argument to hgtchop

For Windows:
for %f in (./data/SRTM-30/*.hgt) do ./Terragear/hgtchop.exe 3 %f ./work/SRTM-30

For Linux:
for i in $PWD/data/SRTM-3/*.hgt; do ./Terragear/hgtchop 3 $i $PWD/work/SRTM-3; done

Now you will get a lot of .arr.gz files in your work/SRTM-3/ directory. We need to convert these to the .fit.gz format. Run the commandline again with
* '''NOTE:''' the space and dot at the and are important!

For Windows:
./Terragear/terrafit.exe work/SRTM-3

For Linux:
./Terragear/terrafit work/SRTM-3

====Airport data====
Now we've got elevation data, we can generate our airports. First, create a <tt>data/airports/</tt> directory and copy in your apt.dat file. This may be direct from your FlightGear data package (though you'll need to unzip it), or it may be one that you've modified with [[TaxiDraw]].

The command to create airports is "genapts". Run it without any arguments to see the various command-line options.

If it is simply run with a specified apt.dat and work directory, it will generate airport layouts for every airport in the file, which can take a long time.

If you are just creating a single airport and you know the ICAO ID (e.g. [[KSFO]], EGPH, EG32), use is as follows from your root scenery directory (i.e. the directory above your data, work and output directories). If you use an apt.dat file with one single airport in it you should omit the "--airport" parameter.

genapts --input=data/airports/apt.dat --work=./work --airport=<AIRPORT_ID>

If you are generating a larger set of scenery, then you can specify the minimum and maximum longitude and latitude.

Genapts will create two sub-directories in your work directory:
* AirportArea/
* AirportObj/

These contain the definitions of the airport layout and any objects present (e.g. windsocks).

====Landuse data====
The final piece of data we need to generate is the landuse data. In general, this is taken from the VMAP0 dataset as shapefiles from the scenery database mapserver, but other sources can also be used.

The landuse data can be split into a number of different types:

* '''Landmass''' separates the land from the sea. It is used as a mask for all other data. The most commonly used is the VMAP0 Landmass, but GSHHS can also be used.
* '''Land use data:''' defines whether a piece of land is forest, urban, sand, lava, glacier etc. These are usually VMAP0 data, defined as polygons.
* '''Line data:''' includes railroads, streams, roads. Typically VMAP0, but also Open Street Map for roads.
* '''Point data:''' is currently only used for defining towns.

By far the easiest way to get this data is to download shapefiles from the wonderful [http://mapserver.flightgear.org MapServer]. The MapServer lets you download the shapefiles for any selected scenery area. Click on the "Download Shapefiles" link (or go direct: http://mapserver.flightgear.org/download.psp). Enter in the bounding box of the scenery you want to generate, select the type of shapefile data you want, and click download. For basic scenery, get everything listed under VMap0 (with prefix v0_).

Download each shapefile into a <tt>data/shapefiles/</tt> directory.

You can load these shapefiles into a GIS editor such as [[QGIS]] or GRASS to view and edit. This is a good idea to verify you have the correct files! Later on, you can experiment with replacing various shapefiles with other versions (GSHHS for coastline, OSM for roads etc.).

The next step is to decode the shape-files into TerraGear format using the '''ogr-decode''' command.

There are three important command-line arguments for ogr-decode:
* the destination directory for the decoded data
* the location of the shapefile's directory
* the material type

Each shape-file corresponds with one of the material types defined in the materials.xml files. The mapping is pretty obvious. For example, v0_mixedcroppasturecover maps to MixedCropPastureCover. Note that the material types are case-sensitive, so it is a good idea to refer to the <tt>[[$FG_ROOT]]/materials.xml</tt> file to hand so you can check. The exception is v0_landmass, which MUST be mapped onto the type Default.

Additionally, there are a number of optional arguments, to indicate the width of line data (for roads, streams, railways), how large to make point data (for towns) and how long the longest straight line is allowed to be.

For example, to decode the v0_landmass shapefile, you use the following command:

ogr-decode --max-segment 500 --area-type Default work/Landmass data/shapefiles/v0_landmass

To create streams of width 10 metres

ogr-decode --max-segment 500 --line-width 10 --area-type Stream work/Stream data/shapefiles/v0_stream

To generate some towns about 1km across

ogr-decode --point-width 500 --area-type Town work/Town data/shapefiles/v0_town

Run this command for each shapefile in the set.

==Generating scenery==
You will now have a work directory looking something like this:

AirportArea SRTM-30
AirportObj Stream
Bog IrrCropPastureCover Town
Lake Urban Landmass
Railroad DryCropPastureCover Road
EvergreenBroadCover Marsh Sand
MixedCropPastureCover ScrubCover
GrassCover MixedForestCover Shared

Now we can actually generate the scenery. This is done by the fgfs-construct command. Run the command with "--help" to get usage information.

We need to define:
* the work (--work-dir) and output (--output-dir) directories
* the center of the scenery we want to generate (--lat, --lon)
* the radius (--xdist, --ydist) from which to generate
* All the work directories to include in the scenery.

For example:
fgfs-construct --work-dir=./work --output-dir=./output --lon=55 --lat=60 --xdist=3 --ydist=3 \
AirportArea SRTM-30 AirportObj Stream Bog IrrCropPastureCover Town Lake Urban Landmass Railroad \
DryCropPastureCover Road EvergreenBroadCover Marsh Sand MixedCropPastureCover ScrubCover GrassCover \
MixedForestCover

When this finishes, the output directory will contain a scenery sub-tree.

Point to it by setting either [[$FG_SCENERY]] or by using the --fg-scenery command-line option to fgfs, and give your new scenery a try!

==Troubleshooting==
Below is a list of common problems and solutions. If in doubt - Google it. Many problems (particularly when compiling TerraGear) have been hit before:

* Crashes in genapts. Sometimes genapts will crash when dealing with a particular airport. In that case, try running it again with the --start-id argument to start at the airport it failed on, and the --nudge argument which tries to nudge the calculations in the right direction.
* fgfs-construct Killed. The fgfs-construct process may kill itself if it is using too many system resources. Increasing the values for setrlimit in src/BuildTiles/Main/main.cxx is the best solution.
* Airports appear in the bottom of holes, or there are spaces between the airports and the scenery. This typically happens when genapts is unable to find the correct elevation data, or the elevation data changed between running genapts and shape-decode. Try generating a single airport in your scenery area using genapts, and look at the output. In particular, make sure there is a work/SRTM-30 directory.
* Only the airports appear in the scenery. There are three typical causes for this:
** You didn't download the correct shapefiles for the area.
** You haven't run shape-decode on the v0_landmass shapefile as Default
** You didn't include the correct directories in fgfs-construct.
* Generate scenery includes data removed from the shapefiles. If you are editing shapefiles, you need to delete the appropriate work subdirectory before running shape-decode. Otherwise your changes will be in addition to those already present.
* All the scenery is flat and at sea-level. Typically this is because you didn't include any elevation data in your fgfs-construct command. Make sure there's a STRM-30 directory included in the command-line.
* All terrain copies the material of a certain shapefile. You have probably forgotten to put each of the downloaded shapefiles in a seperate directory inside the Data/shapefiles directory.

{{Terra}}

[[Category:Scenery enhancement]]

Building Flightgear - Gentoo

2010-07-15T19:00:16Z

Fahim Dalvi: /* Requirements and Preparations */

= HowTo build on Gentoo =

HowTo build FlightGear GIT on Gentoo Linux. Stable releases can be obtained directly from the official Gentoo repository.

== Requirements and Preparations ==
Download the [http://gitorious.org/papillon81/flightgear-gentoo Gentoo Overlay] from gitorious:

git-clone http://git.overlays.gentoo.org/gitweb/?p=proj/gamerlay.git;a=summary

With that done, you should now add this overlay to your Package Manager (Portage):

== Build and install ==

TODO

Building Flightgear - Gentoo

2010-07-15T10:14:44Z

Fahim Dalvi: Created page with '= HowTo build on Gentoo = HowTo build FlightGear GIT on Gentoo Linux. Stable releases can be obtained directly from the official Gentoo repository. == Requirements and Preparat…'

= HowTo build on Gentoo =

HowTo build FlightGear GIT on Gentoo Linux. Stable releases can be obtained directly from the official Gentoo repository.

== Requirements and Preparations ==
Download the [http://gitorious.org/papillon81/flightgear-gentoo Gentoo Overlay] from gitorious:

git-clone git://gitorious.org/papillon81/flightgear-gentoo.git

With that done, you should now add this overlay to your Package Manager (Portage):

== Build and install ==

TODO

Building FlightGear - Linux

2010-07-15T09:52:37Z

Fahim Dalvi: /* Ubuntu and Debian users */ Added link to Gentoo FG building article

{{Main article|Building Flightgear}}

This section describes how to build [[FlightGear]] on Linux system.

Compiling FlightGear is not a task for novice users. Thus, if you're a beginner (we all were once) on a platform which binaries are available for, we recommend postponing this task and just starting with the binary distribution to get you flying.

Or if you develop on Ubuntu or Debian, consider trying the script described in [[Scripted Compilation on Linux Debian/Ubuntu]].

== Requirements ==
Before you can compile FlightGear, you need to have the following installed on your computer:

'''C++ compiler'''

These are: c++, cpp, gcc, g++ found under the /usr/bin directory. You will also need to have the tools '''autoconf''' and '''automake1.9''' installed.

'''GIT'''

See [[FlightGear and Git]].

'''[[OpenGL]] support'''

More specifically, your system needs the support for hardware accelerated graphics. You can check for this by running the following in a [[command line]]:

glxinfo | grep direct

Note: To run the above command, you need to have the tool '''mesa-utils''' installed.

You should then see:

direct rendering: Yes

This means you are good to go as far as OpenGL support is concerned.

If you see:

direct rendering: No

Don't panic yet. This may just mean some required libraries for hardware accelerated graphic are missing. Go ahead and try installing plib 1.8.5 and its dependencies first. If you still get the above message, then you will need to do some googling and troubleshoot yourself.

== Dependencies ==
FlightGear is dependent on quite a few number of libraries. You do not need to compile all of them yourself, but you will at least need to have their development version installed. For example, the development version for package plib1.8.5 is plib1.8.5'''-dev'''.

The dependency is summarized in the following tree. Please note that each library has its own dependencies, and most of these are not shown here.

* FlightGear
** [http://kcat.strangesoft.net/openal.html OpenAL]
** SimGear
*** [http://plib.sourceforge.net/ PLIB]. Since march 2008, you will need version 1.8.5 - your distro probably supplies 1.8.4 still.
**** For versions pre march/2008: (Free)GLUT or SDL (We recommend the use of SDL over Free/GLUT, [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg16153.html however since march 2008, FreeGLUT as well as SDL are both considered depreciated, please only use --enable-osgviewer during configuration instead])
*** [[ OpenSceneGraph ]] (The latest development release or svn trunk for FlightGear/Git and the latest preceding OSG release for a FlightGear release)
*** You also need the development files for several basic libraries to build the software, among them the following (the package names are for Debian and derivatives(?)):
**** libfreetype6-dev
**** libjpeg62-dev
**** libungif4-dev
**** libtiff4-dev
**** libpng12-dev
**** libxmu-dev
**** libxi-dev
**** zlib1g-dev
**** libglut3-dev

If you attack the above dependencies in the order listed below, you should be good:

1. Glut. Most distributions include glut packages, although you may have to hunt for them. Make sure you install both the glut and glut-devel packages, otherwise FlightGear may be able to compile but won't run correctly.

2. Zlib. Most distributions install the basic zlib libraries by default, but not the development portions. If you don't have zlib.h, you probably need to install the zlib-devel package for your distribution.

3. Plib - portability libraries and scene graph.

4. [[ OpenSceneGraph ]]

5. SimGear - Simulation support libraries. If you are building FlightGear from Git, you need the Git version of SimGear. If you have strange build errors, one of the first things to check is that you have an up-to-date version of SimGear built and installed.

==== APT-GET List ====
This is a list of all the apt-get commands I had to do while compiling FG, SG, and OSG on a mostly clean Ubuntu 64 system. It is a list of all the libraries you and your computer needs to compile FG, SG, OSG, and PLib. All you have to do is copy the full command, paste it in Terminal, enter your password, and it will download all the packages for you, and install them too. The full command is at the bottom, and I hope someone finds it useful :) sub-dependencies (dependencies of the dependencies) are not included as they are installed automatically by apt-get. If anyone sees something missing, please add it.

git - to get SG and FG <br>
subversion - to get OSG <br>
build-essential - to build (includes GCC, and other build tools) <br>
cmake - OSG Uses this <br>
ccmake-curses-gui -- OSG Uses this <br>
libpng-dev - to enable FG to use PNG textures<br>
libfreetype6-dev - fonts<br>
libjpeg-dev<br>
libungif4-dev<br>
libtiff-dev<br>
libxmu-dev<br>
libxi-dev<br>
libglut3-dev<br>
libalut-dev - sound<br>
libboost-dev - makes coding for some developers easier<br>
automake - needed by ./autogen.sh files<br>
autoconf - needed by ./autogen.sh files<br>
libfltk1.1-dev - You will need this if you will be using FGRun<br>
-----------
<pre>
sudo apt-get install git subversion build-essential cmake libpng-dev libfreetype6-dev
libjpeg-dev libungif4-dev libtiff-dev libxmu-dev libxi-dev libglut3-dev libalut-dev
libboost-dev automake autoconf libfltk1.1-dev
</pre>
-----------
Total size is about 230 MB, depending on what you already have from other applications.

This list might seem a bit short, but the sub-dependencies all add up :) The dependencies will be listed by apt-get when you use the command.

== Compiling ==
Assuming you are root, do:
cd /usr/local/src

<b>Note:</b> When tracking a fast changing software like FlightGear/Git it is highly advisable to install it in a separate directory. That way one can also easily build and reinstall without being root, which greatly reduces the risk of messing up one's system.
To install in a directory of your choice add the <tt>--prefix</tt> argument to configure. E.g. <tt>./configure --prefix=$HOME/FlightGear</tt>. I would recommend installing all of OSG, plib, SimGear and FlightGear with the same prefix.

=== Getting and compiling SimGear ===

'''Step 1:'''

Clone the SimGear git repository and set it up to track the 'next' branch.
git clone git://gitorious.org/fg/simgear.git

By default after cloning you should have a local next branch that tracks the master next branch. It can be updated it with git pull.

'''Step 2:'''

The source code will be downloaded into a directory called '''simgear'''.

Next, go into the directory and make preparations for the compilation:
cd simgear
./autogen.sh
./configure

'''Note''' that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command

'''Step 3:'''

Compile and install SimGear by doing:
make; make install

''Note:'' with gcc 4.2 or later,on some platforms, you can get compiling errors about alc.h like:

'<anonymous>' has incomplete type
take a look at http://bugs.gentoo.org/166723

=== Getting and compiling FlightGear ===

'''Step 1:'''

Clone the FlightGear git repository and set it up to track the 'next' branch.
git clone git://gitorious.org/fg/flightgear.git

By default after cloning you should have a local next branch that tracks the master next branch. It can be updated it with git pull.

'''Step 2:'''

Next, go into the folder and make preparations for the compilation:
cd flightgear
./autogen.sh
./configure

Note that if you don't want to install simgear globally on the system but in a specific directory, you can do so by adding --prefix=/path/to/your/fgInstallation to the ./configure command.
If you didn't install OSG globally or in the same prefix as SimGear and FlightGear, you have to pass the OSG directory to the configure-command like this:
./configure --prefix=/path/to/fgInstallation --with-osg=/path/to/osg/installation --enable-osgviewer
In this case you have to tell your system where to find the OSG libraries before you can run flightgear:
export LD_LIBRARY_PATH=/path/to/osgInstallation/lib:$LD_LIBRARY_PATH

'''Step 3:'''

Now you can compile and install Flightgear by:
make; make install

'''Step 4:'''

Clone the data directory:
git clone git://gitorious.org/fg/fgdata.git

The data directory is large (almost 2.5GB) so it will take considerable time to download.
There mirror of fgdata that might be faster to download from:
git clone git://mapserver.flightgear.org/fgdata

The mirror is synchronized with the master so either will do.

And install it in (or as) /usr/local/share/FlightGear
mv fgdata /usr/local/share/FlightGear

== Ubuntu and Debian users ==
If you wish you can use the [[Scripted_Compilation_on_Linux_Debian/Ubuntu]] script to have Flightgear compiled in one shot under both Ubuntu and Debian systems.

Debian users who prefer to build it without script may look at [[Building_Flightgear_-_Debian]].
Gentoo users can also use overlays to build FlightGear without much hassle : [[Building_Flightgear_-_Gentoo]].

== External links ==
=== Instructions ===
* [[ MSYS ]]
* [[ MinGW/cross-compiler ]]
* [[ CodeBlocks IDE ]]
* [[ OpenSUSE 10.1 10.2 ]]
* [http://www.geoffmclane.com/fg/fgmsvc7.htm MSVC7 *.Net]
* [http://www.oflebbe.de/oflebbe/FlightGear/index.html MSVC8 aka Visual 2005]
* [http://macflightgear.sourceforge.net/home/documents/ Mac OS X]

{{Building}}

FlightGear Newsletter July 2010

2010-07-13T16:56:40Z

Fahim Dalvi: /* Detailed terrain for Dubai */ minor typos edit

{{newsletter}}
{{TOC_right}}

This month's newsletter marks a year since [[FlightGear Newsletter July 2009|the first issue]] was written!

'''<font size="4">Newsletter history</font>'''

One year ago, in June 2009, [[FlightGear]]-head Curt proposed his newsletter-idea [http://www.flightgear.org/forums/viewtopic.php?f=6&t=5201 at the forum]. With multiple (failed) efforts in the past, those involved were extremely agger to get it up and going this time. Stuart was the one that wrote most of the first issue(s). At the time of the second issue, more people were involved and wrote a paragraph or two.

Today, the newsletter is written by a bunch of people, with different interests and relations to FlightGear. It provides an easy way to keep up-to-date with the ongoing developments; both in FlightGear itself and in the community around it.

I would like to use this opportunity to thank those that contributed over the past year. Thanks to their work, the newsletter still exists! In order to reach our next mileage, we would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone (with a wiki account, [Special:UserLogin|free to register]) can edit the newsletter and every contribution is welcome.

Now, all I can say is: enjoy this brand new edition!

==Development news==

===A new forum for Google's Summer of Code ===
As some of you may already know, there is now an orchestrated effort going on to get FlightGear ready for becoming a mentoring organization in Google's Summer of Code 2011.

So far, all related information has been collected here in the wiki: [[GSoC]].
But to ease the planning and organization process, there has now been a new sub forum set up for talking about anything that is one way or another related to this effort.
The forum can be found at: http://flightgear.org/forums/viewforum.php?f=38

This should make it much easier for all community members to participate in all related discussions, without necessarily having to be subscribed to the mailing lists.

So if you have anything to contribute to this topic, please do make sure to check out this new forum.

You are for example also invited to make suggestions for new FlightGear related GSoC projects.

For the time being, one topic from the "New Features" sub forum has already been moved to this new forum, it is about a suggestion to procedurally populate the FlightGear scenery with dynamically created cities, for more details please check out [[AutoGen Scenery for FlightGear]].

===New mapping software on the block===
Michael contributes new FlightGear mapping software to the communitiy, written in the Ruby programming language: [http://rubyforge.org/projects/fgmap FGMap]. Basically it shows your current flight position on an [http://openstreetmap.org OpenStreetMap] map. It therefore has some similarity to [[Atlas]] and the online [[MPMap]]s. As with all projects, [http://rubyforge.org/tracker/?func=add&group_id=9572&atid=37032 feedback] is highly appreciated.

FGMap has many features, including:
* Show flight position on Openstreetmap map in real-time
* Download new map tiles on-the-fly in the background
* Add shaded elevation layer to map for nice visual effect
* Display current speed and altitude
* Show position and frequency of all navigation aids on the map
* Create FlightGear route manager entries with a click of the mouse from navigation aids and waypoints
* Record and restore flight path
* Colorize path according to speed and altitude
* Display information about instantaneous speed and altitude for all points of the track
* Set waypoints on map

Downloads and more information are available at [http://rubyforge.org/projects/fgmap the project's website].

==In the hangar==
===Bell P59 Airacomet and Bell 222 X===
''helijah'' created and pushed both P59 and Bell 222X onto Git. The Bell 222X FDM is still in development. More information and download at [http://helijah.free.fr/flightgear/hangar.htm ''helijah's'' Hangar].

===De Havilland Canada DHC-7-150 Dash 7===
''Quadunit404'' has announced [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8805 intentions] to produce his first aircraft, the De Havilland Canada DHC-7-150 Dash 7, adding yet another member of the De Havilland Canada family to to FlightGear fleet after active development begins. Currently he is learning how to model using [[Blender]] and will be studying the FDMs of other turboprop regional airliners already in FlightGear to get an idea of how to write the FDM.

===SpaceShipOne and White Knight===
''helijah'' has made some changes to the SpaceShipOne model including the [[FDM]], adding fuselage reflection effect and separating the SpaceShipOne and White Knight objects. The next step is to improve the SpaceShipOne model by adding wheels and moving parts. After that he will try to separate the two aircraft when in flight.

==Livery database==
In the second week of July, the [http://liveries.flightgear.org livery database] welcomed its [http://liveries.flightgear.org/liveries.php?id=251 250th livery]: a glider club's livery for the [[Robin DR400]], created by top-painter Brett Harrison (Gooneybird). More liveries are welcome as always and can be [http://liveries.flightgear.org/contribute.php uploaded]!

==Scenery corner==
===Animated jetways===
[[File:Movable_Jetway.jpg|thumb|A jetway connecting to a [[Boeing 737-300|737-300]].]]
''skyop'' and ''Gijs'' are currently working on animated jetways for FlightGear that can be activated with a click of the mouse. At the moment they are very primitive and only fit [[Boeing 737|737s]]. Planned features include automatic attachment to your airplane's door and even multiple jetways for wide-body airliners and [[Airbus A380|A380s]]. See [http://www.flightgear.org/forums/viewtopic.php?t=8728 this thread] for more information.

[[Image:Dubai_v0_vs_cs-osm.png|thumb|270px|Dubai, with the new custom scenery data with OSM roads (left) and old vmap0 data.]]
===Detailed terrain for Dubai===
As announced in an [[FlightGear Newsletter March 2010#Dubai is coming up|earlier edition]], Gijs has been (re)drawing the terrain of Dubai. The FlightGear scenery now includes:
* Palm Islands (islands in the shape of a palm)
* The World (islands together forming a worldmap)
* Detailed coastline and city boundaries
The area is represented in its form of 2008, due to the lack of more up-to-date imagery. Given Dubai's massive expansion speed, the scenery can be considered as out-of-date already. Nevertheless it is a great step forward in comparison to the previous terrain, as the image on the right proves.

This new terrain will be available with the upcoming scenery build. Those that can handle [[TerraGear]] can download shapefiles from the [http://mapserver.flightgear.org mapserver]. If you are interested in updating or detailing terrain yourself, take a look at [[Howto: Create custom scenery|this wiki article]].

[[Image:Qatar_v0_vs_cs-osm.png|thumb|270px|Qatar, with the new custom scenery data with OSM roads (left) and old vmap0 data.]]

===Detailed terrain for Qatar===
Believe it or not, but here is another Emirate that has been hand drawn! Fahim worked on the peninsula of Qatar, very close to Dubai. Seeing the image on the right, you might think detail/accuracy was lost (except for the urban areas), but I can tell you that the new terrain is far more accurate in all aspects.

This new terrain will also be included with the upcoming scenery build and is already available via the [http://mapserver.flightgear.org mapserver].

===Night flying at London Gatwick===
The new version of [[London Gatwick Airport]] (EGKK) is available and has improved textures and features. It claims to be one of the few ''(two?)'' major international airports in [[FlightGear]] suitable for night flying with full lighting textures on all buildings, hazard lights and approximately one hundred lighting masts. The tower even has lit instrumentation visible in the control room. Images are shown at [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8363 the forum topic].

The taxiways at night are complex but made easier if the official charts are downloaded from [http://www.nats-uk.ead-it.com]. Many taxiway and runway signs have been included to help you on your way. Additional [[AI]] ground network and AI traffic have made this into a very busy airport and a single gate at each pier has been thoughtfully reserved so you can find a parking space when you land here (see the readme file for details).

In daytime the airport is fully modelled with detailed textures and even the roofs of buildings having accurate features. Stock model jetways, cargoes and ground vehicles have been added in quantity to give an authentic look to the airport. Large areas of open air car parks are distributed around the perimeter with novel layering of textures to enhance the 3D effect of the parked cars. Similarly, woods and trees have been added in surrounding areas to add more to the overall feel of the airport.

London Gatwick EGKK may be downloaded from [http://www.mediafire.com/?t2ml5ezmgwv MediaFire].

==Aircraft review==
'''This month: (name of aircraft here)'''

==From the community==
===TransGear founder leaves===
Rob (MD-Terp), known by many as the founding father of the monthly [[TransGear]] events, [http://www.flightgear.org/forums/viewtopic.php?f=3&t=8809 announced] his "retirement" at the forum. With the first event being held just one month after the first edition of this newsletter, TransGear almost reached its first mileage. However, some former participants stepped up to continue organising such events and maybey even Rob will return. More on that in a future edition.

We would like to thank Rob for all he has done, wish him all the best and deeply hope to see him return to the community one day.

==And finally...==

===Did you know?===

[[Category:FlightGear Newsletter|2010 06]]

FlightGear Newsletter June 2010

2010-06-30T13:34:16Z

Fahim Dalvi: /* Scenery corner */

{{newsletter}}
{{TOC_right}}

''We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone (with a wiki account, free to register) can edit the newsletter and every contribution is welcome.''

==Development news==
===Server wanted: Continuous Integration for FlightGear ===
The FlightGear project has started using a build server for [http://en.wikipedia.org/wiki/Continuous_integration continuous integration] purposes and [http://en.wikipedia.org/wiki/Build_automation automating software builds], the [http://hudson-ci.org/ Hudson] based build server is currently running on a home box as a prototype: http://zakalawe.ath.cx:8080/

A build server like Hudson makes it very easy to automatically build FlightGear from source code, e.g. to check the integrity of the source tree or to help prepare prebuilt binaries, pre-releases or even releases.
The server will need a proper home if it moves beyond the prototype stage. If anyone wishes to volunteer or help sponsor a proper server (with a reasonably symmetric connection) to run Hudson, please get in touch using the [http://flightgear.org/mail.html mailing list] or the [http://flightgear.org/forums/ forums] - any Unix will do, for Ubuntu/Debian there's an easy apt.get source available.
All the setup can be done remotely, given SSH access. The disk, memory, CPU and bandwidth requirements are pretty moderate, due to our low commit rate. For additional details, please see [[FlightGear Build Server]].

===SquawkGear: Bringing VATSIM to FlightGear!===
{{Main article|SquawkGear}}
SquawkGear is the much-awaited client that allows FlightGear users to connect to the largest and most realistic sim server in the world: [http://vatsim.net/ VATSIM]. VATSIM is simply a network that can, in theory, take any sim, although the current ones are X-Plane and Microsoft Flight Simulator. Using addons like SquawkBox for MSFS, pilots must adhere to strict rules about realism. A valid [[flight plan]] must always be submitted before takeoff, for instance. And pilots must contact [[Air Traffic Control]] before any actions.

SquawkGear brings this wonderful server to FlightGear. While installation is not as simple as that of VATSIM clients for MSFS, pilots are now able to connect to the VATSIM network and use chat and voice to communicate with other players and ATC. Since [[scenery]] is very different between sims, aircraft do not always appear where they are supposed to be; a MSFS user might see you hovering a few feet above the ground, for instance.

With its first release, SquawkGear is an excellent addon for pilots wishing to get on VATSIM without having to buy the payware sims. It is strongly recommended that you '''read all manuals''' before connecting to VATSIM; not only because installation is tricky, but also because there are certain rules to be followed on VATSIM. You will find that your [[KSFO]] on VATSIM is a thousand times more under control than your KSFO on one of the [[Howto: Multiplayer|mpservers]]!

''Special thanks to Ivan (Reed) for all of his work!''

===Bombable air combat add-on updated===
The [http://www.flightgear.org/forums/viewtopic.php?f=2&t=5742 Bombable air combat add-on to FlightGear] received a major update in June. Bombable now has these features:

* Dogfight against other FlightGear pilots over multiplayer with [[Sopwith Camel]], SPAC VII, [[Fokker Dr.I|Fokker DR 1 Triplane]], or [[A6M2 Zero]]
* Explode/burn when you crash
* Exceeding [[Howto:Define limits|aircraft limitations]] (excess g-forces, overspeed) adds damage to your aircraft and finally leads to shutdown/crash
* Shootable/bombable moving AI tanks, jeeps, ships, and aircraft that [[Wildfire|catch fire]], burn, explode, sink, crash, etc.
* [[AI|AI scenarios]] that allow you to use FlightGear aircraft for air-to-ground, air-to-sea, and air-to-air combat missions against these targets

==In the hangar==
===Boeing 787===
''nickyivyca'' is currently working on the [[Boeing 787]]. He corrected the [[FDM]] and changed some details in the model. More information at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8203 the forum].

===C-130 Hercules===
The [[C-130]] Hercules [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8629 is receiving some updates] from ''glazmax'' and ''helijah''. These updates include FDM and instruments fixes and improvements.

===Cessna T-37===
''richter'' and ''snipey'' are working together in improving the [[Cessna T-37]]. Here is a list of items that have been improved/created:

'''Model:'''
* Completely remodeled canopy;
* Main gear wheel wells and covers.
'''Sound:'''
* Interior-exterior sound level difference.
'''Instruments:'''
* Basic flight instruments.

More information at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8354 the forum].

===CH-47 Chinook===
''MOJO'' is tuning the [[CH-47 Chinook Helicopter|CH-47 ''Chinook'']]. He spent some time adding external cosmetics which main purpose is to add more detail to the Chinook. He added antenna and aerials, domed windows, pitot tubes, winch, engine hub details and started with the internal cargo bay. He intends to be adding an animated refuel probe and will be including several liveries. His ultimate aim for the CH-47 Chinook is to attempt to get the model more defined and realistic.

===Cirrus Vision SF50===
''Zexe'' created a SF50 model. It is still at a very early stage. More information at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8352 the forum].

===CRJ-200===
''nickyivyca'' has also been working in the [[CRJ-200]]:

''"The CRJ-200 and 787 were made with very similar systems and such. Neither had a 2.0 compatible [[autopilot]]. So, I found out what was wrong with the one for the 787 first, and made those changes to the CRJ here. Both worked. I also did some FDM improvements, like moving the engines to where they really are and adding gear smoke and contrails."'' - says he in [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8329 the forum thread].

===Curtiss P-40 Warhawk===
''jackmermod'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8621 is developing a P-40 model]. It is already complete, and to be done are the animations and textures. Development of the P-40 Warhawk is coming along very quick, although a full release date is unknown.

===Il-96-400/T===
The Il-96-400/T [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7439 has been updated] to version 3, with more accurate model and a better panel, among other little fixes.

===MiG-15bis===
''vitos'' improved the [[MiG-15|MiG-15bis]] model, and released it. More information at [http://www.flightgear.org/forums/viewtopic.php?f=4&t=7486 the forum].

===MB-339 PAN===
The MB-339 PAN aircraft [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8604 was updated by ''Albert''] to work with [[FlightGear]] version 2.0.0.

===X-29A===
''Intel-Qube'' [http://www.flightgear.org/forums/viewtopic.php?f=4&t=8485 is currently revamping] the experimental X-29A aircraft. Here is a list of items that have been improved/created:

* A new, more realistic [[FDM]] is on the way;
* Landing gear has been redone and is now much more aesthetically pleasing;
* New exhaust will now dilate based on throttle as it should;
* The cockpit panel has been entirely rebuilt, is far more detailed, and will likely have interactive switches in the final release;
* The model is more ''"anatomically correct"''.

===San Antonio LPD17 and Hermann Marwede SAR-ship===
Browsing through the files, ''HHS'' [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8351 found a rotorcraft carrier model] and made a scenario to run it, which will be available in July on [[Git]] together with the [http://www.flightgear.org/forums/viewtopic.php?f=23&t=8482#p83700 "Hermann Marwede"], another scenario especially for helipilots.

==Scenery corner==
===Night-time London Gatwick===
[[File:Night-time London Gatwick.jpg|thumb|right|London Gatwick at dusk]]
London Gatwick (EGKK) is being further improved and is in the second phase of development - night textures. All the buildings and features are currently being modified by ''karla'' to give suitable lighting and make London Gatwick even more attractive to FlightGear commercial fliers. Landing or taking off from Gatwick at night should add much to your enjoyment of the game - and most likely extend the hours you enter in your pilot's log.
Further improvements and many minor changes are also being made to the existing models and daytime textures.
The link shows an image of the part completed airport at night http://www.donlavelle.net/flightgear/flightgear19.html.

The new scenery is available through [[TerraSync]] and/or the [[Objects Database]].

===Dubai airport gets busy===
With the terrain updates that were discussed in the [[FlightGear Newsletter March 2010#Dubai is coming up|March edition]] still in our minds, we now have another feature for the area; taking it yet another step closer to a bussy and realistic representation of the real emirate!

After looking jealously at the greatly enhanced airport [[Amsterdam Airport Schiphol|Schiphol]] (EHAM) and the latest highlight Gatwick (EGKK) Mike ([[User:D-SKY1|D-SKY1]]) decided to create [[interactive traffic]] for [[Dubai International Airport]] (OMDB). Based on the existing airport layout in FlightGear the traffic pattern for taxiing between gates and runways has been created in [[TaxiDraw]] next to a timetable for runway usage.

Although no model work is done (yet) a big bunch of scheduled flights is now added to this important hub in the middle east. As Dubai is home port for Emirates Airlines (UAE) only Emirates flights are included. Within the next weeks more scheduled flights for AI traffic at Dubai will be added. During the process of creating AI traffic he tried to stay as close as possible to the real life timetable for Dubai International Airport querying several sources for double checking.

As Emirates Airlines (UAE) is one of the most important customers for the [[Airbus A380]] (UAE just ordered another 30 units of A380) the Emirates Airlines livery has been added to AI aircraft A380. Additionally some minor errors in several traffic files concerning changed [[ICAO]] codes for some airports have been removed.

All changes are available via [[Git]]. Enjoy the enhancements; and always follow [[SID]]s and [[STAR]]s to prevent collisions.

===Meadows Field and FGSignMaker===
[[File:KBFL_customscenery.jpg|thumb|right|KBFL Meadows Field]]
''skyop'' released his improvements to the Meadows Field (KBFL) scenery. These include a new taxiway layout, more up-to-date runways, taxiway signs, various airport support buildings, some airport support equipment, some makeshift AI traffic, and placement of the international and domestic terminals. Read [http://www.flightgear.org/forums/viewtopic.php?f=5&t=8466 this topic] for more information.

[[File:FGSignMaker_overview.png|thumb|left|FGSignMaker 1.5.0]]
He is also writing [[FGSignMaker]], a tool to generate taxiway sign codes written in JavaScript. More information on taxiway signs can be found [[Signs|here]].

===Landcover additions===
Connecticut, Oshkosh (Wisconsin, USA) and the Toronto Harbor have been added to the [http://mapserver.flightgear.org FlightGear mapserver]. They will be released to the public with the next scenery build, or alternatively the shapefiles can be downloaded and compiled by the user.

This is in addition to the other numerous improvements to the land cover which are pending with the next scenery release, which includes (but is not limited to) France; Madrid, Spain; London, England; Bonn, Germany; Western Washington, USA; Northwest Oregon, USA; Phoenix, Arizona, USA; Washington, DC, and Baltimore, Maryland, USA; Rhode Island; Hawaii; and Long Island, New York, USA.

Landcover development is ongoing.

===LFLJ and EDDF===
After one year of having released these sceneries (LFLJ/EDDF), ''papillon81'' returned to make changes (some of them big) at them.
More information at the forum: [http://www.flightgear.org/forums/viewtopic.php?f=5&t=5238&st=0&sk=t&sd=a#p84745 EDDF], [http://www.flightgear.org/forums/viewtopic.php?f=5&t=1436&st=0&sk=t&sd=a&start=30#p84800 LFLJ].

==Aircraft Review==
'''This month: B-25 Mitchell'''

[[Image:B-25.jpg|thumb|270px|A B-25 in the air near KATL]]
The [[B-25]] served in almost every theater in World War II. From Europe to the Pacific, the Mitchell was there. One of the most famous missions accomplished by B-25s was the Doolittle Raid on Tokyo, when a group of 16 B-25s attacked the Japanese mainland, raising morale in the United States, and changing the priorities of the Imperial Japanese Navy, and possibly changing the direction of the war.

The flightgear model looks good on the outside. The author has done a lot of work on the textures, and this is improved even more by some excellent liveries made by Gooneybird that have been added to the B-25 base package by the author. The landing gear, engines and canopies are all carefully modeled, too.

The Cockpit is a little bit threadbare, with no chairs, two pilot figures, and only the standard six instruments, which, admittedly, is more than enough to fly with. The only other issue I could come up with was the lack of weapons, but that is only an aesthetic problem. The B-25 handles nicely both on the ground and in the air. I can't talk about accuracy, however, as I have never flown in a B-25, so I don't know how it 'feels' in the air.

The Mitchell sounds great, too!

''Review by Armchair Ace''

==From the community==
===LinuxTAG===
Once again, a team of FlightGear enthusiasts operated a booth during the four days of this year's [http://www.linuxtag.org/ LinuxTAG], the most important place for Linux and open source software in Europe. Besides to it's main purpose of presenting FlightGear to a public audience, LinuxTag becomes more and more '''the''' place for a meeting of core FlightGear developers and users. A technical discussion between James, Alex and Matthias has the potential to become a ''FlightGear legend'' and will probably lead to a multithreaded processing within the simulator's core. Alex also held a public presentation about the integration of [http://www.linuxtag.org/2010/en/program/free-conference/all-events/details.html?talkid=329 "Android for pilots"] with fgfs. [http://www.linuxtag.org/2010/fileadmin/www.linuxtag.org/slides/Alex%20Perry%20-%20Android%20for%20Pilots%20-%20Integration%20with%20the%20FlightGear%20Flight%20Simulator.pdf]

An exciting first contact was initiated between FlightGear team members and a hardware vendor resulting in an idea to operate a shared presentation of powerful hardware running a powerful flight simulator at the next year's LinuxTAG - to proof the claim "where .com meets .org".

===FlightGear on YouTube===
* ''edubletooth'' captured a [http://www.youtube.com/watch?v=EeQUfnHLs_Q bunch of landings] at the airports with the world's most famous approach: [[Princess Juliana International Airport|Princess Juliana]] in the Netherlands Antilles. Make sure to bend when a 777-200 or maybe even a mighty [[Boeing 747|747]] is passing just meters over your head!
* [http://www.youtube.com/watch?v=nzCcqtkTUT8 This excellent video] proves that ''Howto'' Oscar (we already mentioned him last month) does more than creating howtos. Together with Don's extremely detailed simulation of Gatwick Airport (EGKK), Oscar's video angles make this an interesting and pleasant video to watch.

[http://www.youtube.com/watch?v=XkeApfVUnVk&feature=PlayList&p=3B31CCD15245D0AA&playnext_from=PL&index=0&playnext=1 Watch the FlightGear PlayList] for a collection of all (somewhat) quality FlightGear videos ever uploaded to YouTube.

==And finally...==
===Your own Copilot===
How about having your own Copilot to help you fly your heavy metal? Imagine: You're at 3000 ft making a hand controlled descent to EGKK 26L in your [[Boeing 777-200|777-200ER]]: "flaps down"; check airspeed and altitude; you're now five miles out; "undercarriage down"; reduce speed a little more; "flaps down"; you seem to be slightly overspeed; "spoilers"; touch down "brakes" then "reverse thrust"; "flaps retract"; now take a look at the detailed scenery while taxiing to your stand; "view" and "zoom out".

Those using Windows can employ '''Shoot''' - a free user-editable voice command utility. This may be used concurrently with FlightGear to recognize spoken words or phrases and carry out keyboard actions - including sequential or Shift/Alt/Ctrl... keying. Unfortunately Linux users do not have access to such a powerful utility.

[http://clans.gameclubcentral.com/shoot Download Shoot 1.6.4] and install it on your PC. You also need the Microsoft Speech API (SAPI) which is also free; the link is given on the Shoot website. The free Microsoft .NET should also be installed using the Shoot link.

Shoot may be edited to obey verbal commands such as "start engines", "maximum thrust", "undercarriage up", "flaps retract", "trim nose down", "deploy spoilers", "reverse thrust", "view exterior" - or whatever you choose. Try it and add more immersion to your flying.

===Did you know?===
* ...that FlightGear is made of roughly 3,000,000 lines of code and would cost more than $42,000,000 if created from scratch? <ref>Metrics from [http://www.ohloh.net/p/flightgear/analyses/latest ohloh.net]</ref>
* ...that in version 2.0, fellow pilots' chat messages could be ignored on [[multiplayer]] by checking the ignore box in the pilot list? For upcoming releases, pilots' aircraft will also be able to be ignored. This is part of a strong offensive against "trolling" that disrupts MP flying.
* ...that the USS Nimitz [[Howto: Carrier|aircraft carrier]] has deck elevators that can be lowered/raised to go below deck? Toggle them up/down in your ATC Options menu under Carrier; Check-Apply raises them, unchecked-apply lowers them.

==References==
<references/>

[[Category:FlightGear Newsletter|2010 06]]

File:Night-time London Gatwick.jpg

2010-06-30T13:32:05Z

Fahim Dalvi: A Picture showing the fully Lit London Gatwick Airport at dusk.

A Picture showing the fully Lit London Gatwick Airport at dusk.

User:Fahim Dalvi

2010-06-19T18:08:54Z

Fahim Dalvi:

Modeling - Getting Started

2010-06-19T12:05:43Z

Fahim Dalvi:

== Important Notice for Volunteers ==

Developing scenery and models for use with scenery is an important and very visible contribution to Flightgear. New users of Flightgear often ask how they can contribute, and this is a good place to start. Try looking at some of the following:

* We need people to go out and take good pictures of all the buildings at their local airports, build models, and create textures (that could be different people for each task).
* We need people to go over paper lists and airport diagrams for countries that don't publish air navigation data free online (i.e. almost everyone but the U.S.) and fill in the blanks in our navaid and airport databases.
* We need people to collect geodata to give us more accurate roads, rivers, etc., especially outside the U.S.
* We need people to start modelling identifiable human-made landmarks like bridges, stadiums, and major buildings. Around the San Francisco Bay area, bridges are especially important. Once you have identified some buildings or objects you would like to have (Aircraft carriers, fuel bowsers, cars, towers, ...) you will need to check out the tools for creating and placing these objects.

It would be helpful if people would model the area they are interested in. Generally contributions are going to be from Flightgear users who find scenery lacking in some area and choose to improve it. You are encouraged to research your own area for airport, navaid and scenery information, to contribute the data or dive right in to airport and scenery design.

== Getting Started ==

Generally one can start with a blueprint using their favorite imaging software like Gimp, Photoshop, or Paint shop pro then separate various views (front, back, etc...) into greyscale jpg files. Then import them as a background for easy modelling in your favorite 3D modelling software program.

===3D Software===
To begin, you will need to create models in a 3d modeling appliction. Three popular ones are AC3D, Blender and SketchUp. FlightGear can display models in several formats, any format supported by [[PLIB]] is acceptable. AC3D is the most popular format for including scenery in Flightgear. Most or all of the default scenery bundled with a Flightgear release are in AC3D format.

If you do not have AC3D, Blender offers many import and export tools. See the Blender website for further information.

==== [[AC3D]] ====
Flightgear uses the ac3d model format for objects such as buildings. To create a model, you will need one of two modelling packages. Either go directly to [http://www.ac3d.org AC3D] itself, or use [http://www.blender.org Blender] and then convert via a Python script (see below). AC3D seems to be a much easier program to learn, while still being very powerful. The downside is that you have to buy a licence to get more than 14 days use.

* [http://wine.techlab.info/AC3D_Tutorials/ AC3D Modeling Tutorials]

==== [[Blender]] ====
[http://www.blender.org Blender] is more difficult to learn to use, since it is not quite as intuitive and is far more powerful. However it is GPL'd, and there are lots of tutorials to help with learning.

* [http://mediawiki.blender.org/index.php/Main_Page Blender Manual]
* [http://blenderartists.org/forum/ Excellent forum for discussing Blender issues]

==== SketchUp ====
{{Main article|Modeling - SketchUp}}

SketchUp (http://sketchup.google.com) is the easiest to use of these three programms. But the results are very nice and professional. I recommend SketchUp for users who are not really good at difficult computer programms.

==== [[Wings 3D]] ====
{{Main article|Modeling - Wings 3D}}

Wings 3D (http://www.wings3d.com/) is another 3D modeling program, and is free open source software.

=== Placing Objects on Scenery ===
There are several ways of doing this. The most direct way is to simply [[Adding shared models manually|add the required data by hand]].

[[Image:Placing objects with UFO html 439816e9.jpg|thumb|270px|The model adjustment dialog of the [[UFO]]]]
The easiest way is to use the [[Placing 3D Objects with the UFO|UFO's object placement feature]] (in version 9.10 or higher). When operating the UFO, left-clicking the mouse anywhere on the ground will place an object, and pressing space-up or down will cycle through the models. Coordinates of placed models can then be dumped to the terminal or written to a configuration file.

Another method is to use [[FlightGear Scenery Designer]] ([http://fgsd.sourceforge.net/ Project Site]). After setting the paths to your scenery data, simply load up the area where you want to place the object. Load your .ac format model, and right click on the desired spot to place your model there. Export the modifed scenery to save it, rerun Flightgear and your model should be there.

=== Finding, Creating, or Using Textures ===
Models in Flightgear use textures with SGI rgb format (.rgb extension).
You can open .rgb files in Windows and Mac OS using [[THE GIMP]], Corel Paintshop Pro
and XnView. PNG format is now supported in the newest versions of flightgear 1.9.1. PNG models are not backward compatible, you may wish to use rgb format so people with older versions can enjoy your model as well.

If you want to use Adobe Photoshop, you can open and save .rgb files in Adobe Photoshop using a free plugin(for Windows as well as Mac OS) : [http://www.telegraphics.com.au/sw/#sgiformat SGI File Format Plugin for Photoshop].

Once you have made your model building, you will want to apply some textures to it, so it looks as realistic as possible. This is possibly one of the hardest areas, as a good model with bad textures will still look bad. Since Flightgear and the scenery data are all released under the GPL, any textures that you use must also be able to be released under this licence. This will probably prevent you from just using anything you come across on the net, unless it is already under the GPL. It is quite common for people to state that their pictures or textures are free. Since Flightgear can be sold for profit, and is released on Linux distributions that are sold, check that there are no clauses stating that the item can not be sold or used for commercial use.

=== Generation of textured light objects in Blender ===
<table style="margin-top:0.1em; margin-bottom:0.1em; margin-left:2em; padding:2px; font-size:95%; text-align:left; background: transparent;"><tr><td>[[Image:1rightarrow.png|15px]] ''See http://members.aon.at/mfranz/flightgear/blender-textured-lights.html for the main article about this subject.''</td></tr></table>

== Problems and Solutions ==
*[[3D Model Rotates Around Nose]]
*[[Configuring Views in FlightGear]]
*[[Howto: Decrease the number of faces|Decrease the number of faces]]

== Improving Models for Best FlightGear Performance ==
[[Image:Motor.jpg|thumb|270px|Using Multiple Models with varied detailing]]
*Use a single mesh so far as is possible, for example, combine all the parts of a building into one Object.
*Use Materials on Objects instead of textures where possible.
*Use a single texture.
*Textures, transparency and .xml included sub-models : The things that kill frame rate in FlightGear. Try to avoid them.
*If a model has to be detailed to a High Degree, use multiple Objects with different levels of detailing, and switch between them based on LOD.

== Resources ==
*[[Aircraft Information Resources‎ ]]
*[[Modeling Resources]]

{{3d}}

[[Category:Modeling]]

File:Motor.jpg

2010-06-19T11:55:51Z

Fahim Dalvi: Picture Showing use of a High Poly and a Low Poly model for improving Performance in FlightGear.

Picture Showing use of a High Poly and a Low Poly model for improving Performance in FlightGear.

Modeling - Getting Started

2010-06-19T09:58:56Z

Fahim Dalvi:

== Important Notice for Volunteers ==

Developing scenery and models for use with scenery is an important and very visible contribution to Flightgear. New users of Flightgear often ask how they can contribute, and this is a good place to start. Try looking at some of the following:

* We need people to go out and take good pictures of all the buildings at their local airports, build models, and create textures (that could be different people for each task).
* We need people to go over paper lists and airport diagrams for countries that don't publish air navigation data free online (i.e. almost everyone but the U.S.) and fill in the blanks in our navaid and airport databases.
* We need people to collect geodata to give us more accurate roads, rivers, etc., especially outside the U.S.
* We need people to start modelling identifiable human-made landmarks like bridges, stadiums, and major buildings. Around the San Francisco Bay area, bridges are especially important. Once you have identified some buildings or objects you would like to have (Aircraft carriers, fuel bowsers, cars, towers, ...) you will need to check out the tools for creating and placing these objects.

It would be helpful if people would model the area they are interested in. Generally contributions are going to be from Flightgear users who find scenery lacking in some area and choose to improve it. You are encouraged to research your own area for airport, navaid and scenery information, to contribute the data or dive right in to airport and scenery design.

== Getting Started ==

Generally one can start with a blueprint using their favorite imaging software like Gimp, Photoshop, or Paint shop pro then separate various views (front, back, etc...) into greyscale jpg files. Then import them as a background for easy modelling in your favorite 3D modelling software program.

===3D Software===
To begin, you will need to create models in a 3d modeling appliction. Three popular ones are AC3D, Blender and SketchUp. FlightGear can display models in several formats, any format supported by [[PLIB]] is acceptable. AC3D is the most popular format for including scenery in Flightgear. Most or all of the default scenery bundled with a Flightgear release are in AC3D format.

If you do not have AC3D, Blender offers many import and export tools. See the Blender website for further information.

==== [[AC3D]] ====
Flightgear uses the ac3d model format for objects such as buildings. To create a model, you will need one of two modelling packages. Either go directly to [http://www.ac3d.org AC3D] itself, or use [http://www.blender.org Blender] and then convert via a Python script (see below). AC3D seems to be a much easier program to learn, while still being very powerful. The downside is that you have to buy a licence to get more than 14 days use.

* [http://wine.techlab.info/AC3D_Tutorials/ AC3D Modeling Tutorials]

==== [[Blender]] ====
[http://www.blender.org Blender] is more difficult to learn to use, since it is not quite as intuitive and is far more powerful. However it is GPL'd, and there are lots of tutorials to help with learning.

* [http://mediawiki.blender.org/index.php/Main_Page Blender Manual]
* [http://blenderartists.org/forum/ Excellent forum for discussing Blender issues]

==== SketchUp ====
{{Main article|Modeling - SketchUp}}

SketchUp (http://sketchup.google.com) is the easiest to use of these three programms. But the results are very nice and professional. I recommend SketchUp for users who are not really good at difficult computer programms.

==== [[Wings 3D]] ====
{{Main article|Modeling - Wings 3D}}

Wings 3D (http://www.wings3d.com/) is another 3D modeling program, and is free open source software.

=== Placing Objects on Scenery ===
There are several ways of doing this. The most direct way is to simply [[Adding shared models manually|add the required data by hand]].

[[Image:Placing objects with UFO html 439816e9.jpg|thumb|270px|The model adjustment dialog of the [[UFO]]]]
The easiest way is to use the [[Placing 3D Objects with the UFO|UFO's object placement feature]] (in version 9.10 or higher). When operating the UFO, left-clicking the mouse anywhere on the ground will place an object, and pressing space-up or down will cycle through the models. Coordinates of placed models can then be dumped to the terminal or written to a configuration file.

Another method is to use [[FlightGear Scenery Designer]] ([http://fgsd.sourceforge.net/ Project Site]). After setting the paths to your scenery data, simply load up the area where you want to place the object. Load your .ac format model, and right click on the desired spot to place your model there. Export the modifed scenery to save it, rerun Flightgear and your model should be there.

=== Finding, Creating, or Using Textures ===
Models in Flightgear use textures with SGI rgb format (.rgb extension).
You can open .rgb files in Windows and Mac OS using [[THE GIMP]], Corel Paintshop Pro
and XnView. PNG format is now supported in the newest versions of flightgear 1.9.1. PNG models are not backward compatible, you may wish to use rgb format so people with older versions can enjoy your model as well.

If you want to use Adobe Photoshop, you can open and save .rgb files in Adobe Photoshop using a free plugin(for Windows as well as Mac OS) : [http://www.telegraphics.com.au/sw/#sgiformat SGI File Format Plugin for Photoshop].

Once you have made your model building, you will want to apply some textures to it, so it looks as realistic as possible. This is possibly one of the hardest areas, as a good model with bad textures will still look bad. Since Flightgear and the scenery data are all released under the GPL, any textures that you use must also be able to be released under this licence. This will probably prevent you from just using anything you come across on the net, unless it is already under the GPL. It is quite common for people to state that their pictures or textures are free. Since Flightgear can be sold for profit, and is released on Linux distributions that are sold, check that there are no clauses stating that the item can not be sold or used for commercial use.

=== Generation of textured light objects in Blender ===
<table style="margin-top:0.1em; margin-bottom:0.1em; margin-left:2em; padding:2px; font-size:95%; text-align:left; background: transparent;"><tr><td>[[Image:1rightarrow.png|15px]] ''See http://members.aon.at/mfranz/flightgear/blender-textured-lights.html for the main article about this subject.''</td></tr></table>

== Problems and Solutions ==
*[[3D Model Rotates Around Nose]]
*[[Configuring Views in FlightGear]]
*[[Howto: Decrease the number of faces|Decrease the number of faces]]

== Improving Models for Best FlightGear Performance ==
*Use a single mesh so far as is possible, for example, combine all the parts of a building into one Object.
*Use a single texture.
*Use Materials on Objects instead of textures where possible.
*Textures, transparency and .xml included sub-models : The things that kill frame rate in FlightGear. Try to avoid them.

== Resources ==
*[[Aircraft Information Resources‎ ]]
*[[Modeling Resources]]

{{3d}}

[[Category:Modeling]]

Building FlightGear - Debian

2010-06-10T11:22:40Z

Fahim Dalvi: /* FlightGear data */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or CVS on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver.<BR>

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.org!)
*cvs, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (Not available for Lenny atm, see [[#Boost Library|Boost Library]] below.)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or CVS in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. <BR>
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions one have to replace these by the local paths or even <code>export</code> them during the process.

Subsequent the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively huge (CVS about 2 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear CVS as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

CVS:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and CVS:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

CVS:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and CVS:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

GIT:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

Or to Fetch A bundle that can be Downloaded in parts :
cd $prefix
wget http://peter-server.homelinux.net/fgdata/fgdata/fgdata.bundle

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Portal:Developer/Aircraft

2010-06-05T16:04:55Z

Fahim Dalvi:

{{PortalMenu}}

{|style="border-spacing:8px; margin:0px -8px; width:100%;"
|class="MainPageBG" style="width:100%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="1" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">The Aircraft Portal</h2>
|-
|style="color:#000;"|
This portal is for developers of [[FlightGear]] [[aircraft]]. And tends to be a home for aircraft related articles. See the [[Portal:Developer|developers portal]] for more articles about development
in general
|}
|}

{|style="border-spacing:8px; margin:0px -8px;"
|class="MainPageBG" style="width:25%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top; color:#000;"|
{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"

! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Livery</h2>
|-
|style="color:#000;"|
* [[ Howto: Edit a livery|Edit a livery ]]
* [[ Livery over MP]]
|}

{|width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">FDM</h2>
|-
|style="color:#000;"|
* [[Howto: Add thrust reversal|Add thrust reversal]]
* [[Flight Dynamics Model]]
* [[JSBSim Commander]]
* [[JSBSim]] • [[UIUC]] • [[YASim]]
* [[Howto: Name fuel tanks|Name fuel tanks]]
|-
|}

{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Autopilot</h2>
|-
|style="color:#000;"|
* [[Autopilot Configuration Reference]]
* [[Howto: Design an autopilot]]
* [http://www.flightgear.org/Docs/XMLAutopilot/ Customizing the XML Autopilot]
* [[Autopilot Tuning Resources]]
|}

{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Route Manager</h2>
|-
|style="color:#000;"|
* [[Route Manager]]
* [[Route manager internals]]
* [[GPS]]
* [[GPS internals]]
* [[Inertial Navigation System]]
|}

|class="MainPageBG" style="width:25%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">General</h2>
|-
|style="color:#000;"|
* [http://wiki.flightgear.org/index.php/Category:Aircraft_TODO Aircraft Todo]
* [[Aircraft Information Resources]]
* [[Aircraft Manuals]]
* [[Avionics Development Resources]]
|}

{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Nasal Scripting</h2>
|-
|style="color:#000;"|
* [[Nasal scripting language]]
* [[Writing simple scripts in "nasal"]]
|}

|class="MainPageBG" style="width:25%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Modeling</h2>
|-
|style="color:#000;"|
* [[ Howto: Shader Programming in FlightGear]]
* [[Howto: 3D Aircraft Models|3D Aircraft Models]]
* [[3D Model Rotates Around Nose]]
* [[Howto: Add aircraft lights|Add aircraft lights]]
* [[Howto: Decrease the number of faces|Decrease the number of faces]]
* [[Model Import and Export]]
* [[Modeling - Getting Started]]
* [[:Category:Modeling|Modeling Category]]
* [[Modeling Resources]]
* [[Normals and Transparency Tutorial]]
* [http://wiki.flightgear.org/index.php/Copyright_Inquiry Copyright Inquiry]

* [[AC3D]] • [[Blender]] • [[SketchUp]] • [[Wings 3D]]
|-
|}

|class="MainPageBG" style="width:25%; border:1px solid #d9e2e2; background:#efefef; vertical-align:top"|
{| width="100%" cellpadding="2" cellspacing="5" style="vertical-align:top; background:#efefef;"
! <h2 style="margin:0; background:#0f7a71; font-size:120%; font-weight:bold; border:1px solid #d9e2e2; text-align:left; color:white; padding:0.2em 0.4em;">Howtos</h2>
|-
|style="color:#000;"|

* [[Howto: Make an aircraft|Make an aircraft]]
* [[Howto: Make a helicopter|Make a helicopter]]
* [[Howto: Use The Normal Map Effect in Aircraft]]
* [[Howto: Configure views in FlightGear|Configure views in FlightGear]]
* [[Creating instruments for FG|Create instruments]]
* [[Tutorials|Create interactive tutorials]]
* [[Howto: Define speed limits|Define speed limits]]
* [[Howto: Implement wing flex|Implement wing flex]]
* [[Howto: Implement pushback|Implement pushback]]
* [[Howto: Implent Generic tyre smoke|Generic tyre smoke]]

* [[Walk View‎]]
|}
|}

__NOTOC__
__NOEDITSECTION__

[[es:Portal:Desarrolladores/Aeronaves]]
[[pt:Portal:Desenvolvedorpara/Avião]]

FlightProSim

2010-05-23T10:31:44Z

Fahim Dalvi: Corrected some typos!

As many people will be aware, there is a new flight simulator product that is being widely and actively marketed at the moment - Flight Pro Sim. As it is almost entirely based on FlightGear, there is some confusion between the two. To help provide some clarity, and answer some common questions, we (the core FlightGear development team) felt it was appropriate to make a statement, and provide a FAQ.

FlightGear is an open-source flight simulator that was started in 1996. It is released under the GNU General Public License v2, and as such, it is free to use, modify and distribute with few restrictions. It has been developed with the collaboration of a large number of individuals over the last 12 years. FlightGear can be downloaded at no cost from http://www.flightgear.org.

Flight Pro Sim is a commercial product very heavily based on FlightGear. Investigation by a number of the FlightGear developers has found no difference between this and the FlightGear v1.9.1 release other than a change of name. Flight Pro Sim is in no way endorsed or supported by the core FlightGear development team. Given the similarities between Flight Pro Sim and FlightGear, we would recommend that prospective buyers download FlightGear for free and satisfy themselves that Flight Pro Sim provides worthwhile value for money before purchasing it.

==I bought FlightProSim, what to do?==
If you have bought FlightProSim, try to get your money back as soon as possible. You can have (almost) the same software for free nevertheless! They guarentee a 60 day money back trial period, so this should be no problem if you react quickly.

The FlightGear developers are interested in the package to see whether the package complies with the GNU GPL terms or not. Therefore we would like to receive a package for inspection. If you own a package and were unable to get your money back, please contact the developers through the [[mailing list]].

==Legal or illegal?==
The [[GNU GPL]] license under which FlightGear is released allows reselling under certain terms. Many FlightGear developers have difficulties with the way FlightProSim is acting and doubt if they are acting legally. If you have any (inter)national law knowledge, please contact the developers at the [[mailing list]], they will welcome any legal support.

==What are the differences between the two?==
As far as we have been able to make out, the only difference between FlightGear v1.9.1 and FlightProSim is a change in name throughout the software, and the fact that you have to pay for it.

==Why did you refuse a money offer from FlightProSim?==
After a lot of negative criticism from the FlightGear developer, FlightProSim offered to fund a competition in which a developer of a nice new feature is rewarded with a sum of money ($250). The FlightGear developers have more or less un-officially decided to not accept the money offer. A couple of the reasons include:
* If the guy behind FPS really is interested in improving a flight sim, he would input his addons/improvements back into the FlightGear community so the software can be further developed.
* Everyone is allowed to sell FlightGear, as long as they comply with the GNU GPL v2 license. FPS did not in the past, and thus we do not trust them any more. Only after lots of requests from our side they changed their website telling the visitors (in a very small message without link) that it is actually an adaption of free software
* FlightProSim also copied all content from our wiki (and initionally also our main website). That does not give a positive developer impression, more like a "we-want-money-fast-and-without-much-effort" attitude. Apart from the fact that FPS is actually part of a money making company, rather than a software developing one...

==Why do FlightGear developers allow this?==
The freedom to modify and enhance FlightGear is a core part of the project, and of open-source in general. Restricting the modifications that are allowed and what people can do with the software goes against that ethos.

Building FlightGear - Debian

2010-05-18T11:53:58Z

Fahim Dalvi:

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or CVS on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver.<BR>

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.org!)
*cvs, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (Not available for Lenny atm, see [[#Boost Library|Boost Library]] below.)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or CVS in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. <BR>
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions one have to replace these by the local paths or even <code>export</code> them during the process.

Subsequent the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively huge (CVS about 2 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear CVS as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

CVS:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
cd simgear
./autogen.sh

2.0.0 and CVS:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

CVS:
cd $srcdir
git clone git://gitorious.org/fg/flightgear.git flightgear
cd flightgear
./autogen.sh

2.0.0 and CVS:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

CVS:
cd $prefix
git clone git://gitorious.org/fg/fgdata.git data

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Building FlightGear - Debian

2010-05-18T11:52:36Z

Fahim Dalvi: /* SimGear */

= HowTo build on Debian =

HowTo build FlightGear 2.0.0 or CVS on GNU/Linux Debian '''Stable''' 5.x (Lenny).

This HowTo may also work with '''Testing'''/'''Unstable''' except that some things are easier because of more up to date packages. So, before fetching something check the version of the available -dev package for it.

It even *should* work with '''Etch''', but I am not certain about some dependencies. [http://wiki.flightgear.org/index.php?title=Talk:Building_Flightgear_-_Debian&action=edit Reports] are welcome.

If you don't want to make your hands dirty, have a look at [[Scripted_Compilation_on_Linux_Debian/Ubuntu]].

== Requirements and Preparations ==
You need an OpenGL capable graphics including a proper installed driver.<BR>

Also a bunch of packages (and some of their dependencies) are required:
*gcc, g++, make, automake1.9, pkg-config
*mawk (or gawk)
*cmake (min. version 2.6.0-5, for Etch available on backports.org!)
*cvs, subversion, wget

*freeglut3-dev, libgl1-mesa-dev, libxrandr-dev
*libxi-dev, libxmu-dev, libxext-dev
*libopenal-dev (see [[#libopenal|libopenal]]), libalut-dev
*libjpeg62-dev, libtiff4-dev, libpng12-dev
*libboost1.37-dev (Not available for Lenny atm, see [[#Boost Library|Boost Library]] below.)

During installation packages ''simgear-dev'' and ''openscenegraph-dev'' *must not* be installed. They can safely be re-installed after compilation.

== Build and install ==
Because we are going to install versions different to the ones in the repositries it is recommended to install FG-2.0.0 and/or CVS in a place independent to the base system such as /usr/local/FG-2.0.0, /opt/FG-2.0.0 or in a subdirectory of your $HOME. I suggest to make it writeable by the user that there is no need to become root for the <code>make install</code> commands. I'll use <code>$prefix</code> as a placeholder for this directory. <BR>
Another one will be <code>$srcdir</code>, it stands for the absolute path to the directory which contains the folders of the various source codes. So in the following instructions one have to replace these by the local paths or even <code>export</code> them during the process.

Subsequent the instructions to fetch the sources and the data needed by FlightGear and the commands to build/install each source.

Have in mind that the data is relatively huge (CVS about 2 GB and 2.0.0 300 MB) so, to save some time, it is a good idea to fetch it while building the sources.

=== libopenal ===
The libopenal-dev package in Lenny/Etch is too old for [[fgcom]]. For FlightGear it does work but not all features (like Doppler) are available, so installing an up to date version is recommended anyway.
cd $srcdir
wget http://kcat.strangesoft.net/openal-releases/openal-soft-1.11.753.tar.bz2
tar xjf openal-soft-1.11.753.tar.bz2
cd openal-soft-1.11.753/build
cmake -D CMAKE_INSTALL_PREFIX:PATH="$prefix" ..
make install

=== plib ===
Latest SVN is [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg20793.html recommended], yet package plib1.8.5-dev for Testing/Unstable does work as well.
cd $srcdir
svn co https://plib.svn.sourceforge.net/svnroot/plib/trunk plib
cd plib
sed s/PLIB_TINY_VERSION\ \ 5/PLIB_TINY_VERSION\ \ 6/ -i src/util/ul.h
./autogen.sh
./configure --prefix=$prefix
make install

=== Boost Library ===
Version 1.37 is needed. At least for Lenny/Etch this means getting the sources because this is not available atm on backports.org. Testing/Unstable users may have more luck and a package is available, libboost-1.37-dev or newer.

To build SimGear, FlightGear, fgrun and fgcom some boostlib header files are required, no need to compile and install it. If you have installed a libboost1.37-dev (or higher) package on your system you don't have to bother at all with it. If not, you have to tell each ./configure where the header files are. To do so, add the option <code>CPPFLAGS=-I$prefix/include</code> to the SimGear, FlightGear and fgrun <code>./configure</code> commands. We copy the header files to $prefix/include because fgcom will need them there.

Get the newest version tar ball from http://sourceforge.net/projects/boost/files/boost/, extract it into <code>$srcdir</code> then:
cp -R $srcdir/boost-[version]/boost/ $prefix/include/

=== OpenSceneGraph ===
For FlightGear 2.0.0 one may use the latest (or at least 2.9.6) developer release from http://www.openscenegraph.org/projects/osg/wiki/Downloads/DeveloperReleases and extract it into <code>$srcdir</code>.

Mostly this is ok for FlightGear CVS as well as it is stable. However, sometimes the release is not fresh enough and one have to get the latest developments via SVN:
cd $srcdir
svn co http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk OpenSceneGraph

cmake demands a build directory separate to its source directory. So <code>mkdir</code> one and <code>cd</code> into it.
cmake -D CMAKE_BUILD_TYPE="Release" -D CMAKE_CXX_FLAGS="-O3" -D CMAKE_C_FLAGS="-O3" \
-D CMAKE_INSTALL_PREFIX:PATH="$prefix" $srcdir/OpenSceneGraph[-version]
make install

=== SimGear ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/simgear/ftp/Source/SimGear-2.0.0.tar.gz
tar xzf SimGear-2.0.0.tar.gz
cd SimGear-2.0.0

CVS:
cd $srcdir
git clone git://gitorious.org/fg/simgear.git simgear
./autogen.sh

2.0.0 and CVS:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear source ===
2.0.0:
cd $srcdir
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Source/FlightGear-2.0.0.tar.gz
tar xzf FlightGear-2.0.0.tar.gz
cd FlightGear-2.0.0

CVS:
cd $srcdir
mkdir flightgear
cd flightgear
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 login
#CVS passwd: guest
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co source
cd source
./autogen.sh

2.0.0 and CVS:
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/ LDFLAGS="-L$prefix/lib -L$prefix/lib64"]
make install

=== FlightGear data ===
2.0.0:
cd $prefix
wget http://mirrors.ibiblio.org/pub/mirrors/flightgear/ftp/Shared/FlightGear-data-2.0.0.tar.bz2
tar xjf FlightGear-data-2.0.0.tar.bz2

CVS:
cd $prefix
cvs -d :pserver:cvsguest@cvs.flightgear.org:/var/cvs/FlightGear-0.9 co data

=== Trial run ===
When all the builds are done and the data download has finished it is time for a test run:
export LD_LIBRARY_PATH=$prefix/lib/:$LD_LIBRARY_PATH
$prefix/bin/fgfs --fg-root=$prefix/data

For the future, if you want to start FlightGear from command line have a look at [[fgfsrc]], if you prefer a graphical user interface continue with [[#fgrun|compiling fgrun]]. Have in mind that fgfs need to find our self compiled libraries and therefore we have to tell the linker (ld) where to find them. That is what the first line here does.

== Optional Software ==

=== fgrun ===
To build [[fgrun]] two more package is required:
*libfltk1.1-dev fluid

cd $srcdir
svn co http://fgrun.svn.sourceforge.net/svnroot/fgrun/trunk fgrun
cd fgrun
./autogen.sh
./configure --prefix=$prefix [CPPFLAGS=-I$prefix/include/]
make install

=== fgcom ===
For [[fgcom]] unfortunately there is one more dependency which cannot be solved with packages on Lenny/Etch, see [[#libopenal|libopenal]].

cd $srcdir
svn co https://appfgcom.svn.sourceforge.net/svnroot/fgcom/trunk fgcom
cd fgcom/src
make INSTALL_BIN=$prefix/bin INSTALL_DIR=$prefix/fgcom \
PLIB_PREFIX=$prefix OPENAL_PREFIX=$prefix install



{{Building}}

[[de:FlightGear_bauen_-_Debian]]

Livery over MP

2010-05-16T14:00:30Z

Fahim Dalvi: /* Sharing your liveries */ Corrected Typo

[[Image:Livery_selection_dialog.jpg|thumb|270px|The livery selection dialog of the [[Sikorsky S76C]].]]

On this page we describe how you make use of a script to get a '''livery selection dialog''' for a [[Aircraft|plane]] in [[FlightGear]]. To get new liveries into [[FlightGear CVS]], you need to have them availabe with this script.

'''If you want to add a new livery to a plane that already makes use of the livery select system, you'll only have to follow the steps under [[#Models/Liveries|Models/Liveries]].'''

==Files==
There are a few files we need to make (or edit), namely:
* <tt>dr400-set.xml</tt>
* <tt>Models/dr400.xml</tt>
* <tt>Nasal/liveries.nas</tt>
We also have to make a new directory to store our liveries in. Let's make it <tt>Aircraft/DR400/Models/Liveries</tt>.

===Models/Liveries===
For every livery we need to make a file. Let's say we got a Rescue livery, we then need to make a file called Rescue.xml in our <tt>Models/Liveries</tt> directory. When a particular livery gets selected, its XML file is copied to the aircraft's property tree. On the pilot's side this is the main property tree <tt>/</tt>, and on all remote machines on the MP network it's one of the multiplayer branches in <tt>/ai/models/multiplayer[]</tt>. The structure of livery XML files is completely free. There just has to be a property containing a name for the selection dialog, and <tt>aircraft.livery.init()</tt> must be told which it is. By default it is <tt>sim/model/livery/name</tt>.

<?xml version="1.0"?><nowiki>
</nowiki>
<PropertyList>
<sim>
<model>
<livery>
<name type="string">Default</name>
<texture>texture.rgb</texture>
</livery>
</model>
</sim>
</PropertyList>

===Models/dr400.xml===
The first part is related to the nasal script. <tt>("Aircraft/DR400/Models/Liveries");</tt> points FlightGear to the directory where we store our liveries. This is a different directory for every plane, but there should be only one folder for one plane, containing all the liveries for that plane. Add the following code to your models .xml file:

<nasal>
<load>
var livery_update = aircraft.livery_update.new("Aircraft/DR400/Models/Liveries");
</load><nowiki>
</nowiki>
<unload>
livery_update.stop();
</unload>
</nasal>

The second part is very important and probably the hardest of all. We need to set which parts of the model should change when you select a new livery. To find the object-names, you could make use of software like [[Blender]] or [[AC3D]]. The <tt><texture>S76livery.rgb</texture></tt> part points FlightGear to the livery that should be shown on startup.

'''Warning: be sure you don't have a slash (/) in front of sim/model/livery in the <property-base> tag! Otherwise, all planes will get the same livery!'''

<animation>
<type>material</type>
<object-name>LHgeardoor</object-name>
<object-name>RHgeardoor</object-name>
<object-name>S76C</object-name>
<object-name>RF.door</object-name>
<object-name>LF.door</object-name>
<object-name>Rr.Door</object-name>
<object-name>Lr.Door</object-name>
<object-name>RHbaggage</object-name>
<object-name>LHbaggage</object-name>
<object-name>RHfrtgeardoor</object-name>
<object-name>LHfrtgeardoor</object-name>
<property-base>sim/model/livery</property-base>
<texture-prop>texture</texture-prop>
<texture>texture.rgb</texture>
</animation>

===Nasal/liveries.nas===
The only thing you might change in the nasal file is the directory of the liveries. If you don't have the livery name in <tt>sim/model/livery/name</tt>, then you have to add this as second function argument.

aircraft.livery.init("Aircraft/DR400/Models/Liveries");

===dr400-set.xml===
The follow part is really important. If this is not included, the livery changes will not be visible over MP!

<model>
<path>Aircraft/DR400/models/dr400.xml</path>
<livery>
<file type="string"/>
</livery>
</model>

If you want the default livery be something else than the first in the list, replace the file type part with the following, containing the Models/Liveries/....xml file name of the approperiate livery.

<file type="string">ANA</file>

To make a nice button in the [[menubar]] we need to add the following code, just above the <tt></sim></tt> tag.

<menubar>
<default>
<menu n="100">
<label>Robin DR 400</label>
<enabled type="bool">true</enabled>
<item>
<label>Select Livery</label>
<binding>
<command>nasal</command>
<script>aircraft.livery.dialog.open()</script>
</binding>
</item>
</menu>
</default>
</menubar>

==Multiple texture files per livery==
Some models use multiple textures file (eg. seperate files for wings and fuselage). Every texture needs it own property. You can add as many textures as you like.

The given examples are based on the [[Boeing 787]].

===Models/Liveries===
Instead of just one texture we have to deal with multiple ones now.

<?xml version="1.0"?><nowiki>
</nowiki>
<PropertyList>
<sim>
<model>
<livery>
<name type="string">All Nippon Airways</name>
<texture>ANA-Livery.rgb</texture>
</livery>
<lights>
<texture>ANA-Lights.rgb</texture>
</lights>
</model>
</sim>
</PropertyList>

Remember the names (<livery> and <lights>), as you will need them in the model file in the next step.

===Models/787.xml===
<animation>
<type>material</type>
<object-name>wipers</object-name>
<property-base>sim/model/livery</property-base>
<texture-prop>texture</texture-prop>
<texture>ANA-Livery.rgb</texture>
</animation>

<animation>
<type>material</type>
<object-name>lightedfin_0</object-name>
<property-base>sim/model/lights</property-base>
<texture-prop>texture</texture-prop>
<texture>ANA-Lights.rgb</texture>
</animation>

===Performance Improvements===
For livery changing it seems to be important to parent all objects with the same texture. In Blender select all objects and press "ctr-p" to make it parent to the last selected. E.g.: fuselage and doors with the same texture: select at first the doors and then at last the fuselage and press "ctr-p".

Also prevent transparency where possible- it will prevent lags during switching the views. See also the f14b as an very good example!

==Testing==
To ensure that your livery setup works correctly over MP, start two instances of FlightGear locally, one with

fgfs --multiplay=out,10,localhost,5702 --multiplay=in,10,localhost,5701

and one with

fgfs --multiplay=out,10,localhost,5701 --multiplay=in,10,localhost,5702

==Sharing your liveries==
Ofcourse you want other people to use and enjoy your liveries as much as you do. Therefore, other users should be able to download them.

We have some FlightGear hosts, where you can upload your liveries to:
* [http://liveries.flightgear.org FlightGear Liveries] largest FG repository with (almost) all available liveries, based on real aircraft.
* [http://unitedfreeworld.com UnitedFreeWorld] repository with lots of liveries (and scenery/aircraft), both realistic and fictional.

[[Category:Aircraft enhancement]]
[[Category:Modeling]]
[[Category:Menubar]]

Howto:Implement wing flex

2010-05-12T11:31:44Z

Fahim Dalvi: /* Animation */

[[Image:747-400_wing_flex.jpg|thumb|270px|Wing flex as seen on the [[Boeing 747-400]].]]

'''Wing flex''' is the flexing of wings on [[aircraft]], due to lift and fuselage load. [[FlightGear]] is able to show realistic wing flex. Currently the [[Boeing 787]] and [[Boeing 747-400|747-400]] are equipped with flexing wings.

==Model==
A few edits have to be made to the aircrafts model. Each wing has to be cut into multiple sections. The more sections, the smoother the wing flex. Be carefull that you do not cut through flaps or engines. Naming our wing sections, from fuselage to wing tip: wing.1, wing.2 and wing.3.

Measure the coordinates of the start of each new wing section, you will need them to animate the wings.

==Animation==
The following lines have to be added to the aircrafts model .xml file. These lines are used with three wing sections, and a [[JSBSim]] [[FDM]].

<pre>
<animation>
<type>rotate</type>
<object-name>LeftWing.1</object-name>
<object-name>LeftWing.2</object-name>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-4.00</y-m>
<z-m>-1.70</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>

<animation>
<type>rotate</type>
<object-name>LeftWing.2</object-name>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-8.00</y-m>
<z-m>-1.50</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>

<animation>
<type>rotate</type>
<object-name>LeftWing.3</object-name>
<property>fdm/jsbsim/aero/coefficient/CLalpha</property>
<factor>-0.0000045</factor>
<offset-deg>0</offset-deg>
<center>
<x-m> 0.00</x-m>
<y-m>-12.25</y-m>
<z-m> -1.25</z-m>
</center>
<axis>
<x>1.0</x>
<y>0.0</y>
<z>0.0</z>
</axis>
</animation>
</pre>

You probably need to add a lot more objects to each section (like engines, flaps, ailerons etc.) and also change the ''center'' coordinates according to your aircraft. For the right wing, just change the sign of the center <y-m> coordinate and the factor value.

===JSBSim===
[[JSBSim]] calculates the lift force of the aircraft. The lift reacts on the G-forces, the velocity and turbulences. The respective property is: <tt>fdm/jsbsim/aero/coefficient/CLalpha</tt>

===YASim===
[[YASim]] does not calculate wingflex as nice as JSBSim, but a pretty realistic effect can be reached by using the <tt>accelerations/pilot-g[0]</tt> property instead.

[[Category:Aircraft enhancement|Implent wing flex]]
[[Category:Howto|Implent wing flex]]

Advanced weather

2010-05-06T07:25:12Z

Fahim Dalvi: /* Current development status */ Updated File link.

Status: Apr. 2010

The current weather system of Flightgear can be called global when Flightgear runs offline: Any menu weather setting, be it windspeed, visibility, precipitation or cloud coverage, affects the weather everywhere. It is not possible to fly to a region where the cloud cover is different, or see precipitation from an aircraft flying in sunshine, or to observe a change in atmospheric pressure by flying somewhere else.

When online, the weather system offers a link with METAR servers, which makes the weather locally-determined global: One can change the weather by flying to a different location where a different METAR is available, but the change happens instantaneously everywhere, i.e. there is no transition of for example crossing a rain front or leaving dense clouds behind to emerge in sunshine.

A local weather system in contrast is one in which continuous changes from the weather at one location to the weather in a different location are simulated, i.e. weather phenomena are tied to a specific location. Needless to say, a local weather system is significantly more complicated to simulate than the present system. Below is a conceptual outline how a local weather system for Flightgear could be created using mainly existing technology and code.

== Scales for weather phenomena ==

Real weather phenomena are determined by processes occurring at vastly different size scales. At the large end of the scale is the system of low and high pressure regions and fronts between cold and warm air masses, which have spatial size scales of O(1000) km. At the other end of the scale are very localized phenomena, for instance a dark tarmac surface heated by sunlight acting as the source point of a thermal updraft resulting in a Cumulus cloud. Both size scales are relevant for the Flightgear experience - an airliner on a longhaul flight is able to observe large-scale weather fronts from above, whereas a glider pilot needs a reasonable simulation of local updrafts and sinks tied to terrain features in a credible way for a realistic flight experience. A local weather system therefore needs to

* simulate weather phenomena at different scales
* ideally work offline as well as online
* allow modification by the user on various scales
* be reasonably fast to run in real-time

The actual dynamics of the atmosphere is a very complex problem which even solved approximately needs hours of CPU time on supercomputing clusters. From this, it is clear that a local weather system cannot be an (even approximately) physically accurate description of processes in the atmosphere, but needs to be a credible mockup of such a description in which heuristic rules replace simulation.

To give an example for what this means, consider the development of Cumulus clouds. Cumulus development is reduced on a hot day under a hazy Cirrus sky. The reason is that the Cirrus sky reflects part of the sunlight, thus the ground is not heated that much by direct sunlight and the convective processes responsible for Cumulus cloud formation are lessened. An accurate simulation would need to start with the energy absorbed from the sunlight on various types of surfaces, then solve the equations governing the heat flux from the ground to the air above, followed by fluid-dynamical equations for the convective currents creating Cumulus clouds. A heuristic rule would simply state that the probability for the placement of a Cumulus cloud into the Flightgear environment is reduced by 50% when a Cirrus cover is present (obviously, the sophistication of the ruleset determines how realistic the weather system will appear).

In the following, the technology for such a local weather system needed at the relevant scales is outlined - first for the situation offline, followed by ideas how it could be connected with the METAR system in online use.

=== Small scale - effect volumes and average conditions ===

To simulate local weather at small scale, effect volumes (EV) are a useful concept. The effect volumes define regions in which the normal weather conditions (wind, turbulence, updraft, visibility, precipitation...) are replaced by ones characteristic for the region. As an example, one would define the inside of a cloud as an effect volume in which visibility is reduced as compared to outside, or the precipitation layer underneath a thunderstorm as an EV in which heavy rain is on, visibility is reduced, the temperature is reduced and some turbulence may be active.

The conditions characteristic for the EV are imposed once the aircraft enters the volume, they are restored to the outside values once the aircraft leaves the region again. The Flightgear AI system already has examples of structures which in essence are EVs - <b>thermal</b> and <b>thunderstorm</b>. The first structure contains an EV in which vertical air motion is active, the second one in which turbulence is present. These structures could be generalized to an AI system <b>weather</b> in which essentially all weather parameters inside the volume could be set by XML tags.

On the visual side, parts of the EV must also be tied to visible models. The inside of a cloud can be modelled by reduced visibility, but the outside of the cloud must be a model. Similarly, the inside of a rain front appears as rain generated by the Flightgear system, but the outside must be a 3-d model of a precipitation layer. This means that individual 3-d models for various visible atmospheric phenomena (clouds, precipitation, fog, ...) need to be created (see [[Howto: Modelling Clouds]] for a collection of techniques for creating cloud and precipitation models).

Outside the EV, many meteorological parameters may vary in a continuous way, for example visibility may decrease from 5000 to 4000 m when flying 20 km north - but inside the cloud (the EV), it will change in a discontinuous way very suddenly to a low value (say 30 m), to jump back to a large value outside the cloud. Thus, the EVs are used to simulate only discontinuous, local changes in conditions, the larger scale changes in the background need to be taken care of by a different system.

EV's should be implemented such that they can be user-specified, i.e. a user should be able to place any particular combination of weather effects and cloud/precipitation model to a specific location.

=== Mid scale - weather tiles ===

Weather needs to be explicitly simulated about as far as one can see from an aircraft - that naturally leads to the concept of weather tiles (analoguous to scenery tiles) which would cover a region of, say, 30x30 km or something of that size. Inside tiles, weather is simulated explicitly in terms of EVs and 3-d models.

As experiments will quickly convince anyone, placing a random set of cloud models into a tile does not create a realistic sky appearance. Instead, some cloud types usually occur together, others do not. The underlying reason is of course that there is large scale dynamics of the weather which determines what happens in a given location. For instance, Cirrus clouds are found at the leading edge of a warmfront - and they are usually followed by lower, layered cloud types like Altostratus, but typically not by a thunderstorm front.

Thus, there need to be different 'types' of tiles, each representing a typical snapshot of a development inside the larger system. Tile themes would be something like 'leading edge of warmfront', 'trailing edge of warmfront', 'cold front', 'dry high-pressure region', 'developed tropical thunderstorms' and so on. This has the added benefit that the user can specify the weather locally simply by chosing an appropriate tile from a menu (he does not need to micromanage the weather by placing individual EV and cloud models).

The type of tile then determines the rules for populating the tile with EV and models. A 'leading edge of a warmfront' tile could for example have the rules

* populate the northern part of the tile randomly with 10 Cirrus clouds between 25.000 and 30.000 ft
* make sure the models are spaced sufficiently far apart
* make sure the models show the same type of texture (do not mix feathery Cirrus textures with amorphous ones)
* populate the southern part of the tile with 20 Cirrocumulus clouds between 20.000 and 25.000 ft
(...)

The values of weather parameters outside the EVs would be set for the tile center and interpolated between neighbouring tiles.

Technically, each tile can be populated by a Nasal script specific for the tile type whenever the tile is needed (probably when it becomes visible). As an example for the development state of the system (March 2010), here is the view for a weather tile representing an approaching cold front with a Stratocumulus layer and occasional Cumulonimbus activity.

<center>
[[File:Clouds-coldfront02.jpg|400px]]
</center>

=== Large scale - tile placement rules ===

To create a realistic experience for flights beyond a tile, there need to be matching rules for tiles. Since each tile represents a particular development in a larger weather environment, only certain types of tiles match. For instance, one cannot place a 'high-pressure region' tile next to a 'low pressure region' tile without crossing a front. With a moderately large library of different tile types and a set of placement rules, out of which (in offline mode) a credible set of neighbouring tiles is chosen, a more or less realistic long-distance flight experience can result.

If each tile type contains default values for weather parameters (to be overwritten by METAR info if available), the actual value of any parameter such as atmospheric pressure of visibility can be obtained by interpolation between tile centers, and the parameters will vary even in the absence of METAR info simpy due to the tile placement rules mocking up the presence of real large-scale weather systems.

Tile placement rules can be implemented in a Nasal loop which monitors the local position and initializes a new tile as soon as it is needed.

== Connection with the METAR system ==

Connecting the above concepts with real METAR info is not straightforward. The METAR info should conceptually influence three different things:

* selection of tile type
* placement of EVs and models inside the tile
* continuously varying weather parameters

=== Selection of tile type ===

If METAR info is to determine tile type selection, one would need to find an algorithm which gets the METAR from nearby stations and tries to extract a more global weather pattern from that info. For instances, pressure differences and wind direction could be used to locate high and low pressure regions, temperature differences (corrected for elevation) could help to find cold and warm air masses, and based on the most likely weather pattern given these bits of information, the initial tile type as well as the most likely matching neighbouring tiles could be chosen.

=== Placement of EVs and models inside the tile ===

At least some aspects of EV and model placement, such as cloud base, precipitation strength or number of clouds to be placed can more or less be inferred directly from the METAR information. However, in general the tile rules may in details conflict with the METAR info, so the weather system outlined here would not always literally reproduce the METAR (for example, it could happen that the METAR reports rain at an airfield, but that the tile generation does not place a raincloud directly above the airfield).

=== METAR and continuously varying weather parameters ===

If METAR info is available, this (rather than default tile center info) should be used to set parameters like visibility, pressure or temperature. To avoid discontinuous jumps, the info should be linearly interpolated in time for each nearby position from which a METAR is available. If METAR is updated every 10 minutes, one can use the information at startup for each position for the first 10 minutes of flight, then as soon as the next METAR is available slowly change the value (at each position) within the next 10 minutes to the values just fetched, and continue to do so (in essence creating a 10 minute offset from real to simulated weather).

To interpolate in space, in principle a simple algorithm with inverse distance weighting can be used (there are more accurate but also more complicated solutions): If, say, the pressure <i>p</i> is known at <i>n</i> positions, such that the pressure at position <i>i</i> is <i>p_i</i> and the distance between aircraft and <i>i</i> is <i>d_i</i>, then a good approximation of the local pressure is

p = (sum p_i (1/d_i)) / (sum 1/d_i)

as this will make the pressure at position <i>i</i> equal to <i>p_i</i> and lead to the average of the individual pressures if the distance to all METAR stations is the same.

== Related Discussions ==
* [http://flightgear.org/forums/viewtopic.php?f=5&t=6968 New thunderstorm AI scenario alpha release] (02/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7107 Cirrus sky (download link in first post)] (02/2010)
* [http://flightgear.org/forums/viewtopic.php?f=5&t=7358 A local weather system] (03/2010)

== Connection with the Multiplayer system ==

(should be written by someone who knows what the Multiplayer system can and cannot do)

== Feature requests on the C++ side ==

To aid current development, a few features would be nice to have from the C++ side for good performance of the code:

* cloud transformations: Two view-axis based model transformation routines are available with an xml animation tag with the billboard animation. The problem is that neither of those is very useful for cloud models. It would probably help a lot in terms of performance to have more transformations available which are more suitable for cloud models: 1) one-axis position vector based rotation (yaw) 2) two-axis position vector based rotation which does not roll the model (yaw and pitch). Each of those should optionally support the specification of ranges (i.e. pitch only between -20 and +20 deg) and also a minimal distance beyond which the model is not rotated any more. 3) and 4) one and two axis position vector based rotations as above which blend at small distance into view-axis based rotations (these are computationally more expensive, but appear more realistic at small distances). Possibly even more transformations.

=> this can be done inside the shader code very conveniently, so there is probably no need to C++ it after all

* weather properties: Make visibility, wind direction, windspeed, turbulence, thermal lift, pressure, temperature and humidity in an easy way writable from Nasal. Most (except thermal lift) are currently indirectly writable by writing the config and calling environment reinit, but that's not a good solution.

* terrain elevation: For thermal convection and barrier clouds, rapid sampling of terrain elevation is needed. Can there be a way to rapidly receive terrain elevation info only in Nasal for a whole set of pre-specified coordinates which performs better than geoinfo() calls?

* terrain exposure to sun: Again, for thermal convection, a frequent problem involving lots of trigonometry would be - given a coordinate, find a 100 m x 100 m square area around that point. Find the orientation of that area in space (i.e. compute its normal). Given the time and date as input, compute the position of the sun, and based on surface normal and sun angle, compute the amount of thermal energy flux through the surface compared to the maximal one (i.e. when the sun is directly overhead flat terrain, surface normal || sun angle). So, a function f(coordinates, time, date) which returns a number between 0 (no sun exposure, e.g. during night) and 1 (maximal sun exposure). Computing this in Nasal a few 1000 times might be unreasonably expensive...

== Current development status ==

The current version 0.6 supports placement of effect volumes for visibility, rain, snow and thermal lift, as well as interpolation of visibility, pressure, temperature and dewpoint between weather stations. It has a variety of 40x40 km weather tiles with layered and non-layered clouds and weather effects, external models of precipitation and (with a CVS patch) also support for gliders, i.e. it creates thermals below convective clouds. As an example, the picture shows Nimbostratus clouds with precipitation seen from outside.

<center>
[[File:Clouds-nimbostratus.jpg|400px]]
</center>

[http://www.phy.duke.edu/~trenk/files/local_weather_fgfs2.0.0_v0.6.tgz Local Weather package v0.6(Thorsten)]

[http://www.phy.duke.edu/~trenk/files/README.local_weather.html Documentation]