FlightGear wiki - User contributions [en]

User talk:F-JJTH

2015-03-19T11:08:10Z

F-JJTH: Blanked the page

User:F-JJTH

2015-03-19T11:07:46Z

F-JJTH: Blanked the page

User:F-JJTH

2015-03-02T08:23:18Z

F-JJTH: my todo list for FG 3.6

[[Category:FlightGear Core developers]]
[[Category:Developer Plans]]

I'm french, and I participe to many developement of aircraft (Douglas DC-3 C47, R44, P92, DR400 Dauphin, Cap10B, Cap10C, DR400-jsbSim...)

My competence are :
* C++
* Nasal
* XML
* 3D : only little correction (Blender)

==Todo List==
This list contains all job I'm interested to work.

* 2013
** Add FGCom feature into FlightGear {{Progressbar|100}}
** Setup a new and updated FGCom server {{Progressbar|100}} [http://fgcom.flightgear.org]
** Add ATC mode into FGCom standalone {{Progressbar|100}}
** Provide FGCom standalone for Windows, Linux, Mac {{Progressbar|100}} [http://fgcom.flightgear.org/download]
** Write a new FGCom documentation {{Progressbar|100}} [[FGCom_3.0]]

* 2014
** <s>Fix "exit" issue for FGCom standalone</s> Re-write FGCom standalone from scratch {{Progressbar|100}} [http://mapserver.flightgear.org/git/?p=flightgear;a=commit;h=b0b272e4d240a3b02062d196b47056179464a5c1]
** Remove bin/Win[32|64] from the Windows installer {{Progressbar|100}}
** Implement an OSM client in FG {{Progressbar|10}} (Abandonned: Stuart is working on this already)
** Add support for 8.33KHz radio in FG {{Progressbar|10}} (Abandonned: X-Plane data (apt.dat) are missing information to implement this)

* 2015
** Finalize FGData split {{Progressbar|40}}
** Add Qt launcher to Windows platform {{Progressbar|10}}
** Make the Aircraft Launcher efficient {{Progressbar|10}}
** Jenkins: provide full nightly build + harmonize build scripts {{Progressbar|10}}

FGCom 3.0

2015-01-20T19:14:07Z

F-JJTH: update FGCom website link

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://fgcom.flightgear.org
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# You can also check that your PTT works fine looking at the "PTT test" checkbox when you press your PTT button (default is {{Key press|Space}})
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Echo test : check/uncheck this for testing server communication (Echo-Box)
* PTT test : when you press your PTT this checkbox will be checked
* Speaker volume : set speaker volume for FGCom built-in
* Silence threshold : set the limit, in dB, when FGCom consider no voice in your microphone
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.4.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.4.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.4.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.4.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Loading aiports informations...

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Echo Box - For testing FGCOM
Message: Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "--help" argument will show you all the available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

''' I'm using Linux and I can't get FGCom working '''

Please read this page which has a lot of information about audio configuration for Linux user, even some specific reference to FGCom: [[Linux software audio mixing with FlightGear]]

[[fr:FGCom 3.0]]
[[es:FGCom 3.0]]
[[Category:FGCom]]

FGCom 3.0

2015-01-20T19:07:55Z

F-JJTH: Update FGCom 3.4.0 download link

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# You can also check that your PTT works fine looking at the "PTT test" checkbox when you press your PTT button (default is {{Key press|Space}})
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Echo test : check/uncheck this for testing server communication (Echo-Box)
* PTT test : when you press your PTT this checkbox will be checked
* Speaker volume : set speaker volume for FGCom built-in
* Silence threshold : set the limit, in dB, when FGCom consider no voice in your microphone
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.4.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.4.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.4.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.4.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Loading aiports informations...

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Echo Box - For testing FGCOM
Message: Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "--help" argument will show you all the available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

''' I'm using Linux and I can't get FGCom working '''

Please read this page which has a lot of information about audio configuration for Linux user, even some specific reference to FGCom: [[Linux software audio mixing with FlightGear]]

[[fr:FGCom 3.0]]
[[es:FGCom 3.0]]
[[Category:FGCom]]

TerraGear Documentation

2015-01-03T19:57:19Z

F-JJTH: /* terrafit */

There has been a lot of questions relating to scenery generation tools. This page is an attempt to document each of the tools I use. I will also document the design, and what each tool is actually doing.

My hope is to attract more developers to work on the tools to make it easier to create better scenery for [[FlightGear]].

== Toolchain ==
If you just want see every options/arguments available for each tool you can use this command line in the terragear/bin directory : (only for linux user)
for file in *; do echo "" && echo "###################################" && echo $file && echo "###################################" && ./$file --help; done
or alternatively
find * -exec bash './{}' '--help' \;

=== gdalchop ===

gdalchop is a tool responsible for cropping height data files into SimGear buckets (or tiles).

Most height data is published in fairly large data files that cover 1 square degree. For SRTM-1 data, there are 3601 x 3601 data points per file. For SRTM-3 data, there are 1201 x 1201 data points per file. SRTM datafiles are named by their southwestern most point.

When TerraGear tools need to query elevation data, they do so expecting the data to be located in a standard SimGear folder structure as follows:

{| class="wikitable"
|-
! Format !! Example
|-
|''10 deg x 10 deg folder''|| ''w070n10''
|-
|— ''1 degree by 1 degree subfolder ''||— ''w065n17''
|-
|—— ''bucket file ''||—— ''1891048.arr.gz ''
|}

gdalchop will create this directory structure in the work folder, and create sgbucket.arr.gz files within.

==== command options ====
gdalchop <height data dir> <work dir>

'''height data dir''' 
This is the directory your height data resides in. (i.e. .hgt files for SRTM)

'''work_dir''' 
This is where gdalchop will generate the elevation directory structure described above.

==== notes ====
# remember to use gdalchop on directories, rather than individual files. It handles height data stitching for you. Using individual files will produce data with missing elevation data where stitching could not be performed.

For example, this command will process all the .hgt file from the folder "SRTM-source" and the result will go in the folder "work/SRTM3"
gdalchop work/SRTM3 SRTM-source/*.hgt

 

=== hgtchop (deprecated) ===
hgtchop is also a too responsible for cropping height data files into SimGear buckets (or tiles). This tool only work with data in the .hgt format (SRTM, viewfinder).

Reasons for using gdalchop:
* handles heightdata in many more formats
* is based on gdal, an actively maintained open source GIS library

==== command options ====
hgtchop <resolution> <hgt_file> <work_dir>

'''resolution''' 
Each file created contains ALL of the data points for the simgear tile. For SRTM-1 data, the resultant grid (for tiles near the equator) is 450 x 450 points. For SRTM-3 data, the grid is 150 x 150 points. The resolution parameter tells hgtcop the distance between sampled points. Note that tile width varies with latitude. So 'square' tiles really only exist between 22 degrees N - 22 degrees S. The tile widths are explained here: [[Tile_Index_Scheme|Tile Index Scheme]]

'''hgt_file''' 
The source file. Usually, the source files are 1 degree by 1 degree, and have enough data to create 64 simgear buckets (near the equator).

'''work_dir''' 
This is where hgt-chop will generate the elevation directory structure described above.

==== notes ====
#zip files : In TGHgt::open, if the file extension is '.zip', then unzip executable is executed through system(). If the host system doesn't have unzip, then hgtchop will fail. The unzip should be performed via SimGear - Investigation needed 
 

=== terrafit ===

terrafit is responsible for taking the raw heightfield data for one bucket, and picking the most important points to generate a triangle mesh. It uses [http://mgarland.org/archive/cmu/scape/terra.html Terra] to perform the work. The output is not a triangulation, but rather a list of nodes that can be fed to a triangulation routine. The quality of FlightGear's terrain is directly related to what parameters are fed into terrafit.

==== command options ====
terrafit [options] <file | path>

{| class="wikitable"
|-
! Option !! Default !! Description
|-
| -m ''or'' --minnodes||50||smallest number of nodes to produce. For a mostly flat tile, more nodes are wasteful.
|-
| -x ''or'' --maxnodes||1000||largest number of nodes to produce. 
For a very complex tile, limiting this will reduce the detail of the resulting mesh.
|-
| -e ''or'' --maxerror||40||While picking points, and we have at least minnodes, but not yet maxnodes, the mesh will be completed 
if any of the remaining points maximum elevation error drops below this value.
|-
| -f ''or'' --force|| ||If you have an already fitted work directory, and want to regenerate with different parameters, be sure to use force. 
Otherwise, the work directory is checked for updated height data and merged with current data
|}

As you can see, the default parameters are pretty conservative. At most, we will output 1,000 nodes. The input data for SRTM-1 contains 202,500 nodes, so we are only keeping 0.5% of the source data (or for SRTM-3, with 22,500 nodes, we keep ~5% of the source data)

For my experiments, I've increased maxnodes to 20,000, and decreased max error to 10 meters, and didn't see a major frame rate hit).

If you consider the number of nodes added when using detailed landclass, it's unfortunate that the height lookup for these points will be based on such an inaccurate mesh. 

For example, this command will process all the *.arr.gz file (previously generated with gdalchop) from the folder "work/SRTM3", the result will go among .arr.gz files
terrafit -f -m 50 -x 20000 -e 10 work/SRTM3
 

=== ogr-decode ===

ogrdecode is responsible for decoding landclass and line vector data into terragears internal textured polygon format. It also performs the 'chop' operation, so the output is structured in the same directory format as described in gdalchop. ogr-decode is capable of decoding shapefiles stored on disk, or retrieving the data from a PosGIS database.

==== command options ====
ogr-decode [options...] <work dir> <datasource> [<layername>...]

{| class="wikitable"
|-
! Option !! Default !! Description
|-
| --line-width||50||for line data, this is the width in meters the generated polygons will be.
|-
| --line-width-column||''none''||for line data, this optional field can be used to retrieve the width from the database row, under the given column. 
If data is present in the row, it overrides the line-width parameter.
|-
| --point-width||500||for point data, this is the 'width' of the square generated. Both width and height will be this large.
|-
| --point-width-column||''none''||for point data, this optional field can be used to retrieve the width from the database row, under the given column. 
If data is present in the row, it overrides the point-width parameter.
|-
| --area-type||Default||This string is used to define the type of landclass the generated polygons will be saved under. 
In tgconstruct, the landclass priorities file is used to determine the priority of each landclass. higher priorities are 'on top' of lower. 
The name given here must match a landclass type in your priorities configuration file.
|-
|}

=== genapts / genapts850 ===

==== design ====
:Step 1 : Parse

:Step 2 : Clip

:Step 3 : Clean

:Step 4 : Elevation

:Step 5 : Output

=== fgfs-construct ===

== Related content ==
* [[Using Terragear]]
* [[TerraGear CORINE]]

{{Terra}}
{{Building}}

[[Category:Scenery enhancement]]

TerraGear Documentation

2015-01-03T19:51:30Z

F-JJTH: /* gdalchop */

There has been a lot of questions relating to scenery generation tools. This page is an attempt to document each of the tools I use. I will also document the design, and what each tool is actually doing.

My hope is to attract more developers to work on the tools to make it easier to create better scenery for [[FlightGear]].

== Toolchain ==
If you just want see every options/arguments available for each tool you can use this command line in the terragear/bin directory : (only for linux user)
for file in *; do echo "" && echo "###################################" && echo $file && echo "###################################" && ./$file --help; done
or alternatively
find * -exec bash './{}' '--help' \;

=== gdalchop ===

gdalchop is a tool responsible for cropping height data files into SimGear buckets (or tiles).

Most height data is published in fairly large data files that cover 1 square degree. For SRTM-1 data, there are 3601 x 3601 data points per file. For SRTM-3 data, there are 1201 x 1201 data points per file. SRTM datafiles are named by their southwestern most point.

When TerraGear tools need to query elevation data, they do so expecting the data to be located in a standard SimGear folder structure as follows:

{| class="wikitable"
|-
! Format !! Example
|-
|''10 deg x 10 deg folder''|| ''w070n10''
|-
|— ''1 degree by 1 degree subfolder ''||— ''w065n17''
|-
|—— ''bucket file ''||—— ''1891048.arr.gz ''
|}

gdalchop will create this directory structure in the work folder, and create sgbucket.arr.gz files within.

==== command options ====
gdalchop <height data dir> <work dir>

'''height data dir''' 
This is the directory your height data resides in. (i.e. .hgt files for SRTM)

'''work_dir''' 
This is where gdalchop will generate the elevation directory structure described above.

==== notes ====
# remember to use gdalchop on directories, rather than individual files. It handles height data stitching for you. Using individual files will produce data with missing elevation data where stitching could not be performed.

For example, this command will process all the .hgt file from the folder "SRTM-source" and the result will go in the folder "work/SRTM3"
gdalchop work/SRTM3 SRTM-source/*.hgt

 

=== hgtchop (deprecated) ===
hgtchop is also a too responsible for cropping height data files into SimGear buckets (or tiles). This tool only work with data in the .hgt format (SRTM, viewfinder).

Reasons for using gdalchop:
* handles heightdata in many more formats
* is based on gdal, an actively maintained open source GIS library

==== command options ====
hgtchop <resolution> <hgt_file> <work_dir>

'''resolution''' 
Each file created contains ALL of the data points for the simgear tile. For SRTM-1 data, the resultant grid (for tiles near the equator) is 450 x 450 points. For SRTM-3 data, the grid is 150 x 150 points. The resolution parameter tells hgtcop the distance between sampled points. Note that tile width varies with latitude. So 'square' tiles really only exist between 22 degrees N - 22 degrees S. The tile widths are explained here: [[Tile_Index_Scheme|Tile Index Scheme]]

'''hgt_file''' 
The source file. Usually, the source files are 1 degree by 1 degree, and have enough data to create 64 simgear buckets (near the equator).

'''work_dir''' 
This is where hgt-chop will generate the elevation directory structure described above.

==== notes ====
#zip files : In TGHgt::open, if the file extension is '.zip', then unzip executable is executed through system(). If the host system doesn't have unzip, then hgtchop will fail. The unzip should be performed via SimGear - Investigation needed 
 

=== terrafit ===

terrafit is responsible for taking the raw heightfield data for one bucket, and picking the most important points to generate a triangle mesh. It uses [http://mgarland.org/archive/cmu/scape/terra.html Terra] to perform the work. The output is not a triangulation, but rather a list of nodes that can be fed to a triangulation routine. The quality of FlightGear's terrain is directly related to what parameters are fed into terrafit.

==== command options ====
terrafit [options] <file | path>

{| class="wikitable"
|-
! Option !! Default !! Description
|-
| -m ''or'' --minnodes||50||smallest number of nodes to produce. For a mostly flat tile, more nodes are wasteful.
|-
| -x ''or'' --maxnodes||1000||largest number of nodes to produce. 
For a very complex tile, limiting this will reduce the detail of the resulting mesh.
|-
| -e ''or'' --maxerror||40||While picking points, and we have at least minnodes, but not yet maxnodes, the mesh will be completed 
if any of the remaining points maximum elevation error drops below this value.
|-
| -f ''or'' --force|| ||If you have an already fitted work directory, and want to regenerate with different parameters, be sure to use force. 
Otherwise, the work directory is checked for updated height data and merged with current data
|}

As you can see, the default parameters are pretty conservative. At most, we will output 1,000 nodes. The input data for SRTM-1 contains 202,500 nodes, so we are only keeping 0.5% of the source data (or for SRTM-3, with 22,500 nodes, we keep ~5% of the source data)

For my experiments, I've increased maxnodes to 20,000, and decreased max error to 10 meters, and didn't see a major frame rate hit).

If you consider the number of nodes added when using detailed landclass, it's unfortunate that the height lookup for these points will be based on such an inaccurate mesh. 
 

=== ogr-decode ===

ogrdecode is responsible for decoding landclass and line vector data into terragears internal textured polygon format. It also performs the 'chop' operation, so the output is structured in the same directory format as described in gdalchop. ogr-decode is capable of decoding shapefiles stored on disk, or retrieving the data from a PosGIS database.

==== command options ====
ogr-decode [options...] <work dir> <datasource> [<layername>...]

{| class="wikitable"
|-
! Option !! Default !! Description
|-
| --line-width||50||for line data, this is the width in meters the generated polygons will be.
|-
| --line-width-column||''none''||for line data, this optional field can be used to retrieve the width from the database row, under the given column. 
If data is present in the row, it overrides the line-width parameter.
|-
| --point-width||500||for point data, this is the 'width' of the square generated. Both width and height will be this large.
|-
| --point-width-column||''none''||for point data, this optional field can be used to retrieve the width from the database row, under the given column. 
If data is present in the row, it overrides the point-width parameter.
|-
| --area-type||Default||This string is used to define the type of landclass the generated polygons will be saved under. 
In tgconstruct, the landclass priorities file is used to determine the priority of each landclass. higher priorities are 'on top' of lower. 
The name given here must match a landclass type in your priorities configuration file.
|-
|}

=== genapts / genapts850 ===

==== design ====
:Step 1 : Parse

:Step 2 : Clip

:Step 3 : Clean

:Step 4 : Elevation

:Step 5 : Output

=== fgfs-construct ===

== Related content ==
* [[Using Terragear]]
* [[TerraGear CORINE]]

{{Terra}}
{{Building}}

[[Category:Scenery enhancement]]

Understanding Rembrandt

2015-01-03T09:38:55Z

F-JJTH: /* Shadows at night time */

== Background ==
Many of us are wondering why Rembrandt is so slow for us, despite having fairly powerful computers.

== Objective ==
Try to better understand -and document- Rembrandt internals, so that we can better troubleshoot performance issues.

Ok, I just tried Rembrandt again (after spending 5 minutes reading the wiki article), and while my computer is much less powerful than yours, I am also getting roughly ~15 fps at ksfo with the ufo - and looking at those OSG stats, there's a hell lot of stuff going on obviously, i.e. we have 10 different cameras 3 of them extremely busy (0,1 and 5)

The performance is actually decent, though ALS with all goodies maxed out gets 25 fps for the same scene under Linux (there's the grass shader needing lots of noise calls for instance). I don't get a huge green bar.

The big hit comes when I try to see Las Vegas (with the Urban shader) - that drives me down to 3 fps. Or when I try to activate filtering and switch it to 3 - then my framerate likewise dives down to 4.

So I remember how this went - the base performance of Rembrandt without shadows was actually pretty decent on my box under Windows, 30 fps or so. Switching shadows on cost me some of that but was still flyable, but the shadows were flickering so much that I got a headache after 5 minutes, so I needed to switch the filtering to max. to be able to look at it - and that killed the framerate for good.

If this is something that we really want to investigate more closely, I guess it would be a good idea to read the "deferred rendering" paper that Fred linked to in the article - at least those parts describing the 3 cameras that seem really busy (geometry/shadows/lighting)

== Scene Complexity ==
Purely from a troubleshooting standpoint, I would like to know what kind of effect/impact we can expect from discarding vertices/triangles and quads from all three cameras (having 10 fps even at night time seems very odd), i.e. if discarding those translate into any proportional/tangible performance gains

Actually, the base idea of deferred rendering is that it should be pretty insensitive to the amount of vertices you feed to it because it really has a minimal geometry shader (computationally cheaper than default even, it basically only notes where stuff is on the screen and stores the non-projected position in a buffer) and all the actual work of lighting etc. is done in the fragment pipelines. So I'd be very surprised if it responds at all to changes of the vertex load.

I sort of see this on my card - if I'm fragment-limited, it switches to synchronized framrates, I get either 25 or 30 or 60 fps, but not 33 or 47. Completely different when the vertex shader jams, then I get to see arbitrary numbers. Which is a neat first-look diagnostics. Rembrandt is clearly fragment-dominated on my box.

The thing is, it only takes a few errors in the C++ code that could massively inflate the amount of primitives sent to effects/shaders. And Rembrandt is obviously not well understood now that Fred is not maintaininig it currently. So there might be some low-hanging fruits there, but I am not going to spend hours going through the code unless I see tangible results.

As far as I understand the wiki article, most stages are XML configurable, so we can probably customize things a bit there, or even disable certain cameras/stages - which would make sense to see if each camera's stage looks sane.

For starters, I would probably start up at night time above sea - i.e. "minimal startup profile" and see what Rembrandt is doing then in each stage.
The number of vertices etc. should be fairly minimal then, shouldn't it ?

ok, when going to zero-scenery places, I am getting rock-solid 60 fps/25ms here (daytime), with Rembrandt running with aircraft shadows, even with maxed out settings.
Can we work with that ? What about you ?
I remember your "orbitview" (?) project where you placed a huge sphere into the scenery. Could this help us to do some troubleshooting, i.e. using Nasal to place a few models (and possibly light sources) and see what's having an impact ?

the other thing I noticed is that CPU load doesn't seem to decrease despite AGL/ASL attitude being too high to realistically cast shadows - would these be things that we could add to the effects/shaders to reduce rembrandt workload a bit ?

== Reducing Complexity ? ==

What would be involved in editing effects/shaders to simply discard 50% of all vertices ? I just want to see for myself if that's having an effect here or not ?

In a vertex shader it's fairly difficult to do. To effectively discard a vertex, you need to evaluate some criterion based on its coordinates/attributes and then if that criterion is true move it out of the view frustrum and return, so you run a 'minimal' set of operations.

The obvious thing to do if you want to test response to vertex numbers is to set visibility lower so that terrain is simply not showing up at the vertex shader at all in a controllable way. A theoretically elegant way if you can is to set random numbers as vertex attributes and to move the vertex out of the view frustrum if the random number is smaller than a threshold. But in passing attributes, you're of course changing the pipeline in a substantial way...

If you want to test scaling of fragment shaders, that's much easier to do - evaluate another criterion in the first line which is true half of the time (say whether you're in the right half of the screen, you can test against gl_FragCoord which is the fragment position on the screen) and then insert a discard; if you want to dump the fragment without computing anything.

== Profiling ==
I am going to check what the C++ runtime profile looks like in comparison to the classical renderer.

Okay, I left rembrandt running for 10 minutes with the profiler enabled: fgcommand("profiler-start") - for some reason, the profile showed that "osgParticles" were eating up /some/ resources despite being not enabled - I tried to explicitly disable them, but that would still not change anything, so I removed the corresponding subsystem from src/Main/fg_init.cxx, which gave me +8 fps:
<syntaxhighlight lang="diff">
diff --git a/src/Main/fg_init.cxx b/src/Main/fg_init.cxx
index 86494da..04d6f42 100644
--- a/src/Main/fg_init.cxx
+++ b/src/Main/fg_init.cxx
@@ -635,9 +635,11 @@ void fgCreateSubsystems(bool duringReset) {
// Initialize the scenery management subsystem.
////////////////////////////////////////////////////////////////////

+#if 0
globals->get_scenery()->get_scene_graph()
->addChild(simgear::Particles::getCommonRoot());
simgear::GlobalParticleCallback::setSwitch(fgGetNode("/sim/rendering/particles", true));
+#endif

////////////////////////////////////////////////////////////////////
// Initialize the flight model subsystem.
@@ -1077,8 +1079,10 @@ void fgStartNewReset()

simgear::clearEffectCache();
simgear::SGModelLib::resetPropertyRoot();
-
+
+#if 0
simgear::GlobalParticleCallback::setSwitch(NULL);
+#endif

globals->resetPropertyRoot();
fgInitConfig(0, NULL, true);

</syntaxhighlight>

== Shadows at night time ==
Well, something seems a bit odd there, because rembrandt is doing shadows, right ? And when I switch to night time mode, I am still just getting 10-15 fps and seeing similar subsystem/osg activity.

as far as I know it's doing shadows at night just as well. If you drive your ufo to a Rembrandt-defined light source, I think it will cast a shadow also at night. I don't think the shadow part is off just because the sun is down.

Wrong, Rembrandt is not doing shadows at night time:
https://gitorious.org/fg/flightgear/source/5ccc83566785c9b5b75e8d03579dbd1aa45d7237:src/Viewer/renderer.cxx#L938-939

The conceptual beauty of shadows in Rembrandt is that they're not faked, there's actually a physics computation going on where light in the scene reaches and where it doesn't. The downside is that unless there's a huge amount of filtering going on, that computation is suffering from numerical accuracy so much that it flickers all over the place.

the thing about rembrandt & light sources is true, I remember seeing screen shots - but I cannot imagine that the amount of computations for a handful of airports light should be equal to have a "central" light source illuminating everything (aka the sun) ?

I invit you to start FlightGear and enable the Rembrandt shadows and look at your framerate,
then disable Rembrandt shadows and look again at your framerate.
Conclusion: how many FPS costs the Rembrandt shadows ?
(here the answer is 3~5 FPS, so Rembrandt shadows are not the "FPS killer" thing)

Basically, it seems there's no "LOD for shadows" taking place, i.e. computations are heavy/complex despite having any light souces in your vicinity that could have an effect realistically. I would have expected that the corresponding shaders/effects specifically look for light source so that the computations kick in, but otherwise don't - unless, rembrandt is even doin moonlight shadow ?

The shadow cascades are acting like "shadows LOD",
you can tweak this setting at runtime and see how Rembrandt shadows are updated.
After that you will conclude that "LOD for shadows" is implemented finally.

== Zero Scenery Tests ==
Using '''--aircraft=ufo - --enable-rembrandt --prop:/sim/rendering/shadows/map-size=8192 --prop:/sim/rendering/shadows/num-cascades=4'''
I can even get way beyond 60 fps when there's not scenery to be displayed, it would be interesting to check what Fred did there, i.e. if there are heuristics in place to recognize this ? We would probably want to add a few static models to the scenery and see what the performance impact is like.

I think through roughly a dozen different test cases like these, one could incrementally understand rembrandt and its stages - obviously, one would now need to edit some of the XML files and maybe some effects/shaders to see how things are affected

[[Category:Shaders]]
[[Category:Shader development]]

Fr/FGCom 3.0

2015-01-01T20:15:05Z

F-JJTH: add spanish version

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= Qu'est ce que FGCom ? =
FGCom est un moyen de communication vocale, vous permettant de communiquer avec les autres pilotes et contrôleurs aériens pendant votre vol.

L'idée principale est de reproduire des conditions de radio-communication réelles, en d'autres termes c'est un moyen de rendre les radio-communications les plus réalistes possibles durant vos vols.

FGCom se présente sous deux formes:
* Integrée dans FlightGear (FGCom intégré): c'est la meilleure solution car très simple d'utilisation
* Application externe autonome (FGCom autonome): vous devriez faire ce choix uniquement si vous avez besoin d'utilisez FGCom dans un cas particulier

Une interface web est disponible pour voir qui est connecté en direct, l'historique, et les statistiques: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom intégré est disponible dans FlightGear 3.0 ou supérieur, c'est certainement la solution la plus commode
* FGCom autonome est destiné à ceux qui veulent une installation complexe, ou qui n'utilisent pas FlightGear 3.0 ou supérieur.
* Si vous n'utilisez pas FlightGear 3.0 ou supérieur reportez-vous à [[Fr/FGCom_3.0#FGCom_autonome|la section FGCom autonome]] et suivez les instructions "Si FlightGear n'est pas installé" .

 
= FGCom intégré =

=== Installation ===
Bonne nouvelle: FGcom est inclus dans FlightGear, aucune installation supplémentaire n'est requise; vous avez FlightGear, vous pouvez immédiatement utiliser FGCom intégré.

=== Comment démarrer FGCom intégré ? ===
# Lancez FlightGear
# Ouvrez la fenêtre de dialogue "Multiplayer > FGCom Settings"
# Cochez la case "Enable"
# Fermez la fenêtre

Vous pouvez aussi utiliser la ligne de commande si vous préférez:
--enable-fgcom (equivalent de --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent de --prop:/sim/fgcom/enabled=false )

FGCom sera automatiquement actif pour vos sessions futures, jusqu'à ce que vous décochiez la case "Enable"

=== Comment tester votre installation ? ===
Pour vérifier que micro et haut-parleurs sont correctement connectés et opérationnels, effectuez les étapes suivantes:

# Lancez FlightGear (si ce n'est déjà fait)
# Ouvrez la boîte de dialogue dans "Multiplayer > FGCom Settings"
# Cochez la case "Enable" (si ce n'est déjà fait)
# Cochez la case "Display messages" checkbox. (Affiche les messages FGCom sur l'écran)
# Cochez la case "Echo test" À partir de ce moment vous devriez entendre votre propre voix avec un retard. Si vous n'entendez pas votre voix ça signifie que votre micro ou vos haut-parleurs sont mal configurés. Pour d'avantage de vérification de l'"Echo test", voyez [http://fgcom.flightgear.org/history.php Live FGCom] 
# Décochez la case "Echo test", ainsi que les autres cases si désiré.
# Vous pouvez aussi vérifier que votre PTT (Push-To-Talk = Appuyez-pour-parler) fonctionne correctement en regardant la case "PTT test" lorsque vous appuyez sur votre button "PTT" (par défaut: {{Key press|Space}})
# Fermez la fenêtre

=== Comment utiliser FGCom intégré ? ===
Une fois FGCom démarré avec la procédure [[Fr/FGCom_3.0#Comment_d.C3.A9marrer_FGCom_int.C3.A9gr.C3.A9_.3F|Comment démarrer FGCom intégré]], vous pouvez utiliser votre radio comme dans la réalité.

Quand vous voulez parler, vous appuyez sur la touche {{Key press|Space}}. Quand {{Key press|Shift}} est appuyé, vous n'entendez pas les autres pilotes.

Vous pouvez basculer entre COM1 et COM2 en appuyant {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: Il peut être utile de garder coché la case "Display messages" afin de vérifier le bon fonctionnement de FGCom.

=== Détails de dialog ===
La fenêtre située dans "Multiplayer > FGCom Settings" montre:

* Enable : vous pouvez cocher/décocher pour activer/désactiver FGCom intégré
* Display messages : affiche les messages FGCom seulement pour debug
* Echo test : cocher/décocher ici pour tester le serveur (Echo-Box)
* PTT test : lorsque vous appuyez sur votre PTT cette case sera cochée
* Speaker volume : règle le volume des HP pour FGCom intégré
* Silence threshold : défini la limite, en dB, lorsque FGCom considère qu'il n'y pas de voix dans votre micro
* Server > List : Sélectionne le serveur auquel se connecter (effet immédiat)

 

= FGCom autonome=
=== Installation ===
'''Si FlightGear est installé:'''

La bonne nouvelle ici est que si vous avez FlightGear installé sur votre ordinateur, vous avez déjà FGCom autonome !

'''Si FlightGear n'est pas installé:'''

Si FlightGear n'est pas installé sur l'ordinateur sur lequel vous voulez utiliser FGCom autonome, vous pouvez simplement le télécharger en suivant les étapes suivantes:

# Téléchargez FGCom autonome: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (attention à sélectionner la version correspondant à votre ordinateur !)
# Dézippez le fichier
# C'est tout! Bien sûr, vous pouvez placer le dossier "FGCom" où vous voulez dans votre ordinateur

Sur Linux, vous devez [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 modifier la permission en "éxecutable"] pour les fichiers "run_fgcom.sh" et "test_fgcom.sh"

=== Comment démarrer FGCom autonome ? ===
'''Si FlightGear est installé:'''

Sur Windows, vous devez exécuter FGCom situé dans votre menu Démarrer > FlightGear > Tools > FGCom-testing

Sur Linux, vous devez exécuter FGCom situé dans votre menu Application > Games > FGCom-testing

Sur Mac, vous devez activer "Enable FGCOM in Multi Player mode" situé dans l'onglet "Network" du lanceur Mac

'''Si FlightGear n'est pas installé:'''

Sur Windows, dans votre dossier dézippé "FGCom" vous devez exécuter (double clic) le fichier "run_fgcom.bat".

Sur Linux, dans votre dossier dézippé "FGCom" vous devez exécuter (double clic) le fichier "run_fgcom.sh".

Sur Mac, dans votre dossier dézippé "FGCom" vous devez exécuter (clic-droit > ouvrir avec > Terminal.app) le fichier "run_fgcom.command". Après la première fois vous pouvez simplement double-cliquer sur "run_fgcom.command".

'''Dans les deux cas'''

Dans un terminal ouvert maintenant, vous pouvez voir les lignes suivantes:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Loading aiports informations...

Pour arrêter FGCom autonome, pressez {{Key press|Control}} + {{Key press|c}}

=== Comment tester votre installation ? ===
'''Si FlightGear est installé:'''

Sur Windows, vous devez exécuter FGCom, situé dans votre menu Démarrer > FlightGear > Tools > FGCom-testing

Sur Linux, vous devez exécuter FGCom situé dans votre menu Application > Games > FGCom-testing

Sur Mac, FIXME: non implémenté

'''Si FlightGear n'est pas installé:'''

Sur Windows, dans votre dossier dézippé "FGCom" vous devez exécuter (double clic) le fichier "test_fgcom.bat".

Sur Linux, dans votre dossier dézippé "FGCom" vous devez exécuter (double clic) le fichier "test_fgcom.sh".

Sur Mac, dans votre dossier dézippé "FGCom" vous devez exécuter (clic-droit > ouvrir avec > Terminal.app) le fichier "test_fgcom.command". Après la première fois vous pouvez simplement double-cliquer sur "test_fgcom.command".

'''Dans les deux cas'''

Vous pouvez maintenant entendre votre voix en écho, et voir les lignes suivantes:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Echo Box - For testing FGCOM
Message: Call 0 answered

Pour arrêter FGCom autonome, pressez {{Key press|Control}} + {{Key press|c}}

=== Comment utiliser FGCom autonome ? ===
Après avoir lancé FGCom selon la procédure [[Fr/FGCom_3.0#Comment_d.C3.A9marrer_FGCom_autonome_.3F|Comment démarrer FGCom autonome]], vous devez lancer [[Fr/FGCom_3.0#FAQ| FlightGear avec l'option suivante]]:
--generic=socket,out,1,127.0.0.1,16661,udp,fgcom

Maintenant, vous laissez FGCom autonome allumé et vous pouvez lancer FlightGear

Lorsque vous voulez parler, vous appuyez sur {{Key press|Space}}. Quand {{Key press|Space}} est appuyé, vous ne pouvez pas entendre les autres pilotes.

Vous pouvez basculer entre COM1 et COM2 en faisant {{Key press|Shift}} + {{Key press|Space}}

Vous pouvez contrôler le volume avec le slider "ATC" du menu Fichier > Configuration du son (même si le bouton "ATC" est décoché)

Pendant votre session Flightgear vous pourrez voir quelques lignes dans FGCom autonome, c'est normal, elles vous informent sur l'état de FGCom autonome (quand vous écoutez, parlez, changez de fréquence, changez COM1/2...)

Pour arrêter FGCom autonome pressez {{Key press|Control}} + {{Key press|c}}

=== Détails des options ===

Le lancement de FGCom autonome avec "--help" vous montrera toutes les options possible.

'''IMPORTANT:''' Rappelez-vous que FGCom autonome marche bien sans aucune option ! Ne les utilisez que si vous savez exactement ce que vous faites.

= FAQ =
''' Comment ajouter l'option générique --generic option for FGCom autonome ? '''

Depuis FlightGear 3.0 vous pouvez sélectionner "FGCom autonome" dans la section [[FlightGear_Launch_Control#Network|FlightGear Launcher > Avancé > Réseau]] sinon:

Dans la [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|dernière page du Lanceur FlightGear]], cliquez "Advanced" puis [[FlightGear_Launch_Control#Input.2FOutput|sélectionnez "Input/Output" item]]. Pressez "New" et remplissez les champs:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' Je veux utiliser FGCom intégré mais je ne vois aucune rubrique "Multiplayer > FGCom Settings" dans FlightGear '''

Parce que vous n'avez pas FlightGear 3.0 ou plus. FGCom intégré est seulement depuis FlightGear 3.0 ou plus. Servez-vous de FGCom autonome en attendant votre mise à jour.

''' Je veux utiliser FGCom intégré mais je ne vois aucune rubrique dans "Start menu > FlightGear > Tools" '''

Parce que vous n'avez pas FlightGear 3.0 ou plus. FGCom autonome n'est automatiquement installé que pour FlightGear 3.0 ou plus.

Suivez les instructions "Si FlightGear n'est pas installé" jusqu'à votre mise à jour.

''' J'utilise FGCom autonome, les autres pilotes m'entendent mais je ne peux pas les entendre '''

Vérifiez que le slider "ATC" du menu Fichier > Configuration du son est complètement à droite.

''' J'utilise Linux et n'arrive pas à faire fonctionner FGCom '''

Veuillez lire cette page qui contient beaucoup d'informations à propos de la configuration audio pour les utilisateurs Linux, et fait aussi référence à FGCom: [[Linux software audio mixing with FlightGear]]

[[en:FGCom 3.0]]
[[es:FGCom 3.0]]
[[Category:FGCom]]

FGCom 3.0

2015-01-01T20:14:35Z

F-JJTH: add spanish version

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# You can also check that your PTT works fine looking at the "PTT test" checkbox when you press your PTT button (default is {{Key press|Space}})
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Echo test : check/uncheck this for testing server communication (Echo-Box)
* PTT test : when you press your PTT this checkbox will be checked
* Speaker volume : set speaker volume for FGCom built-in
* Silence threshold : set the limit, in dB, when FGCom consider no voice in your microphone
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Loading aiports informations...

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Echo Box - For testing FGCOM
Message: Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "--help" argument will show you all the available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

''' I'm using Linux and I can't get FGCom working '''

Please read this page which has a lot of information about audio configuration for Linux user, even some specific reference to FGCom: [[Linux software audio mixing with FlightGear]]

[[fr:FGCom 3.0]]
[[es:FGCom 3.0]]
[[Category:FGCom]]

Es/FGCom 3.0

2015-01-01T20:14:02Z

F-JJTH: Created page with "{{Infobox Software |title = FGCom 3.0 |logo = FGCom_logo.png|128px |developedby = Holger Wirtz Martin Spott Csaba Halasz Clém..."

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= ¿Qué es FGCom? =
FGCom es una característica de la comunicación de voz. De esa manera puede comunicarse con los pilotos y controladores del espacio aéreo a otros durante su vuelo.

La idea principal es reproducir la comunicación de la aviación reales, en otras palabras, esta característica está diseñada para hacer que la comunicación de radio tan real como sea posible durante sus vuelos.

FGCom está disponible por dos maneras:
* Integrado en FlightGear (FGCom integrado): esta es sin duda la mejor solución, porque más fácil de usar
* El software externo (FGCom independiente): usted debe utilizar éste sólo si tiene previsto utilizar FGCom en un caso especial

Una interfaz web está disponible donde se puede ver quién está conectado en vivo, la historia y las estadísticas: http://fgcom.flightgear.org

'''IMPORTANTE:'''
* FGCom integrado está disponible para FlightGear 3.0 o superior y es sin duda la solución que está buscando, porque realmente fácil de usar.
* FGCom independiente es sólo para aquellos que quieren un complejo, pero más flexible, la instalación o no utilice FlightGear 3.0 o superior.
* Si usted no está utilizando FlightGear 3.0 o superior tienes que leer el [[Es/FGCom_3.0#FGCom_independiente|FGCom sección independiente]] y siga las instrucciones "Si FlightGear no está instalado".

 
= FGCom integrado =

=== Instalación ===
La buena noticia es que FlightGear tiene ahora un cliente FGCom construido en el software. Eso significa que no hay paso de la instalación adicional. Si ha instalado FlightGear puede utilizar inmediatamente FGCom.

=== ¿Cómo empezar FGCom integrado? ===
# Inicio FlightGear
# Abra el diálogo se encuentra en "Multiplayer> FGCom Configuración"
# Marque la casilla "Habilitar"
# Cierre el diálogo

También puede utilizar la línea de comandos, si lo prefiere:
--enable-fgcom (equivalente a --prop:/sim/fgcom/enabled = true)
--disable-fgcom (equivalente a --prop:/sim/fgcom/enabled = false)

FGCom se habilitará automáticamente para sus futuros períodos de sesiones hasta que se desactiva la casilla "Activar".

=== Cómo probar la instalación? ===
Con el fin de comprobar que el micrófono y los altavoces están conectados correctamente y funcional puede probarlo con los siguientes pasos:

# Inicio FlightGear (si todavía no lo ha hecho, por supuesto)
# Abra el diálogo se encuentra en "Multiplayer > FGCom Settings"
# Marque la casilla "Enabled" (Si aún no lo ha hecho.)
# Marque la casilla "Display messages". (Muestra mensajes de FGCom en la pantalla)
# Marque la casilla "Echo test" En este momento usted debe oír su propia voz con un retraso. Si no puede escuchar su propia voz que significa el micrófono o los altavoces se ajustan mal. Para comprobar aún más su "prueba de eco", véase [http://fgcom.flightgear.org/history.php Vive FGCom ] 
# Unckeck la casilla de verificación "Echo test", y / o en otros cuadros como se desee.
# También se puede comprobar que su PTT funciona bien mirando a la casilla de verificación "PTT test" cuando presiona el botón PTT (por defecto es {{Key press|Space}})
# Cierre el diálogo

=== Cómo utilizar FGCom integrado? ===
Una vez que empezaste FGCom de la [[Es/FGCom_3.0#Cómo_probar_la_instalación.3F | Cómo iniciar FGCom integrado]] procedimiento, usted simplemente puede utilizar su panel de radio como se hace en la vida real.

Cuando usted quiere hablar tiene que pulsar {{Key press|Space}}. Cuando el {{Key press|Space}} es presionado no puede escuchar a otros pilotos.

Se puede cambiar entre COM1 y COM2 pulsando {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTA: Es tal vez deseable mantener la configuración del FGCom "Display messages" activados, para verificar estas teclas FGCom relacionados funcionan correctamente.

=== Detalles Dialog ===
El diálogo se encuentra en "Multiplayer> FGCom settings" proporcionan algunas de las características que se describen aquí:

* Enable: se puede activar / desactivar esto para activar la función de FGCom / desactivar
* Display messages: pantalla de mensajes transacción FGCom de depuración sólo
* Echo test: marcar / desmarcar este para probar la comunicación servidor (Echo-Box)
* PTT test: cuando presiona el PTT esta casilla se comprobará
* Speaker volume: ajustar el volumen del altavoz para FGCom incorporado
* Silence threshold: establecer el límite, en dB, cuando FGCom consideran ninguna voz en el micrófono
* Server > List: Seleccione el servidor que se conectará (efecto immediat)

 

= FGCom independiente =
=== Instalación ===
'''Si se instala FlightGear:'''

La buena noticia es que si usted tiene FlightGear instalado en su equipo ya tiene FGCom independiente!

'''Si FlightGear no está instalado:'''

Si no ha instalado FlightGear en el equipo en el que desea utilizar FGCom independiente puede simplemente descargar FGCom independiente con los siguientes pasos:

# Descargar FGCom independiente: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 pedacitos] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (tener cuidado de seleccionar la versión correcta para su computadora!)
# Descomprimir el archivo descargado
# Eso es todo! Por supuesto, usted puede colocar la carpeta "FGCom" en la que desea en su equipo

En Linux, usted tiene que [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 configurar el permiso como "ejecutable"] para el archivos "run_fgcom.sh" y "test_fgcom.sh"

=== ¿Cómo empezar FGCom independiente? ===
'''Si se instala FlightGear:'''

En Windows tiene que ejecutar FGCom ubicado en el menú Inicio> FlightGear > Tools > FGCom

En Linux hay que ejecutar FGCom encuentra en el menú de aplicaciones> Juegos> FGCom

En Mac hay que activar la opción "Enable FGCOM in Multi Player mode", ubicado en la "Network" pestaña del lanzador Mac

'''Si FlightGear no está instalado:'''

En Windows, en la carpeta descomprimida "FGCom", usted tiene que ejecutar (doble clic en él) el archivo "run_fgcom.bat".

En Linux, en su carpeta descomprimida "FGCom", usted tiene que ejecutar (doble clic en él) el archivo "run_fgcom.sh".

En Mac, en su carpeta descomprimida "FGCom", usted tiene que ejecutar (derecha-clic> Abrir con> Terminal.app) el archivo "run_fgcom.command". Después de la primera vez que simplemente hacer doble clic en "run_fgcom.command".

'''En ambos casos'''

Ahora un terminal se ha abierto y usted debería ser capaz de ver las siguientes líneas:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Loading aiports informations...

Con el fin de detener FGCom standalone tienes que pulsar {{Key press|Control}} + {{Key press|c}}

=== Cómo probar la instalación? ===
'''Si se instala FlightGear:'''

En Windows tiene que ejecutar FGCom ubicado en el menú Inicio> FlightGear> Herramientas> FGCom pruebas

En Linux hay que ejecutar FGCom encuentra en el menú de aplicaciones> Juegos> FGCom pruebas

En Mac FIXME: requerir a implementarse en Mac lanzador

'''Si FlightGear no está instalado:'''

En Windows, en la carpeta descomprimida "FGCom", usted tiene que ejecutar (doble clic en él) el archivo "test_fgcom.bat".

En Linux, en su carpeta descomprimida "FGCom", usted tiene que ejecutar (doble clic en él) el archivo "test_fgcom.sh".

En Mac, en su carpeta descomprimida "FGCom", usted tiene que ejecutar (derecha-clic> Abrir con> Terminal.app) el archivo "test_fgcom.command". Después de la primera vez que simplemente hacer doble clic en "test_fgcom.command".

'''En ambos casos'''

Ahora usted debería ser capaz de oír su propia voz con un retraso y ver las siguientes líneas:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Echo Box - For testing FGCOM
Message: Call 0 answered

Con el fin de detener FGCom standalone tienes que pulsar {{Key press|Control}} + {{Key press|c}}

=== Cómo utilizar FGCom independiente? ===
Una vez que empezaste FGCom de la [[Es/FGCom_3.0#Cómo_empezar_FGCom_independiente.3F | Cómo iniciar FGCom standalone]] procedimiento, usted tiene que [[Es/FGCom_3.0#FAQ | iniciar FlightGear con la siguiente opción]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Ahora usted tiene que dejar FGCom funcionamiento autónomo y simplemente utiliza FlightGear sin cuidar FGCom independiente.

Cuando usted quiere hablar tiene que pulsar {{Key press|Space}}. Cuando el {{Key press|Space}} es presionado no puede escuchar a otros pilotos.

Se puede cambiar entre COM1 y COM2 pulsando {{Key press|Shift}} + {{Key press|Space}}

Usted puede controlar el volumen del sonido con el control deslizante "ATC" del diálogo Archivo> Configuración del sonido (incluso si el ATC no está marcada)

Durante la sesión de FlightGear usted debería ser capaz de ver algunas líneas en la versión autónoma FGCom, es totalmente normal, que están aquí para que le informan sobre el estado de FGCom independiente (cuando estás escuchando, hablando, el cambio de frecuencia, cambiando COM1 / 2 ...)

Con el fin de detener FGCom standalone tienes que pulsar {{Key press|Control}} + {{Key press|c}} o simplemente cerrar la ventana.

=== Detalles Opciones ===

A partir FGCom independiente con argumento "--help" le mostrará todas las opciones disponibles.

'''IMPORTANTE:''' Tenga en cuenta que FGCom autónomo funciona bien para un sistema operativo estándar sin opciones a todos! Úsalos sólo si usted sabe exactamente lo que hacen.

= FAQ =
'''¿Cómo añadir la opción --generic para FGCom independiente? '''

Desde FlightGear 3.0 puede seleccionar "FGCom independiente" en el [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] sección más:

En el [[FlightGear_Launch_Control#Page_four_-_Options_and_Run| última página del Launcher FlightGear]], pulse en "Opciones avanzadas" y luego [[FlightGear_Launch_Control#Input.2FOutput| elemento Seleccione "Input / Output"]]. Pulse el botón "Nuevo" y definir los campos como:
* Protocolo: generic
* Medio: socket
* Dirección: out
* Hz: 5
* Nombre de host: 127.0.0.1
* Puerto: 16661
* Seleccione UDP
* Genérico: fgcom

'''Quiero usar FGCom integrado pero no tengo ningún elemento "Multijugador> FGCom Ajustes" en FlightGear'''

Debido a que usted no está utilizando FlightGear 3.0 o superior. FGCom integrado sólo está disponible para FlightGear 3.0 o superior. Usted tiene que usar FGCom independiente hasta que actualice su instalación de FlightGear.

'''Quiero usar FGCom independiente pero no tengo ningún elemento FGCom en "menú Inicio> FlightGear> Herramientas"'''

Debido a que usted no está utilizando FlightGear 3.0 o superior. FGCom independiente se instala automáticamente sólo para FlightGear 3.0 o superior.

Usted tiene que seguir "Si FlightGear no está instalado" instrucciones hasta que actualice su instalación de FlightGear.

'''Estoy usando FGCom independiente, otros pilotos pueden oírme pero no puedo oír a otros pilotos'''

Asegúrese de que el control deslizante "ATC" de> el diálogo de configuración de sonido de archivos está en pleno derecho.

'''Estoy usando Linux y no puedo conseguir FGCom trabajando'''

Por favor, lea esta página que tiene una gran cantidad de información acerca de la configuración de audio para usuarios de Linux, incluso alguna referencia específica a FGCom: [[software Linux de mezcla de audio con FlightGear]]

[[fr:FGCom 3.0]]
[[en:FGCom 3.0]]
[[Category:FGCom]]

Fr/FGCom 3.0

2015-01-01T19:32:44Z

F-JJTH: update doc for FG 3.4 (fr)

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= Qu'est ce que FGCom ? =
FGCom est un moyen de communication vocale, vous permettant de communiquer avec les autres pilotes et contrôleurs aériens pendant votre vol.

L'idée principale est de reproduire des conditions de radio-communication réelles, en d'autres termes c'est un moyen de rendre les radio-communications les plus réalistes possibles durant vos vols.

FGCom se présente sous deux formes:
* Integrée dans FlightGear (FGCom intégré): c'est la meilleure solution car très simple d'utilisation
* Application externe autonome (FGCom autonome): vous devriez faire ce choix uniquement si vous avez besoin d'utilisez FGCom dans un cas particulier

Une interface web est disponible pour voir qui est connecté en direct, l'historique, et les statistiques: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom intégré est disponible dans FlightGear 3.0 ou supérieur, c'est certainement la solution la plus commode
* FGCom autonome est destiné à ceux qui veulent une installation complexe, ou qui n'utilisent pas FlightGear 3.0 ou supérieur.
* Si vous n'utilisez pas FlightGear 3.0 ou supérieur reportez-vous à [[Fr/FGCom_3.0#FGCom_autonome|la section FGCom autonome]] et suivez les instructions "Si FlightGear n'est pas installé" .

 
= FGCom intégré =

=== Installation ===
Bonne nouvelle: FGcom est inclus dans FlightGear, aucune installation supplémentaire n'est requise; vous avez FlightGear, vous pouvez immédiatement utiliser FGCom intégré.

=== Comment démarrer FGCom intégré ? ===
# Lancez FlightGear
# Ouvrez la fenêtre de dialogue "Multiplayer > FGCom Settings"
# Cochez la case "Enable"
# Fermez la fenêtre

Vous pouvez aussi utiliser la ligne de commande si vous préférez:
--enable-fgcom (equivalent de --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent de --prop:/sim/fgcom/enabled=false )

FGCom sera automatiquement actif pour vos sessions futures, jusqu'à ce que vous décochiez la case "Enable"

=== Comment tester votre installation ? ===
Pour vérifier que micro et haut-parleurs sont correctement connectés et opérationnels, effectuez les étapes suivantes:

# Lancez FlightGear (si ce n'est déjà fait)
# Ouvrez la boîte de dialogue dans "Multiplayer > FGCom Settings"
# Cochez la case "Enable" (si ce n'est déjà fait)
# Cochez la case "Display messages" checkbox. (Affiche les messages FGCom sur l'écran)
# Cochez la case "Echo test" À partir de ce moment vous devriez entendre votre propre voix avec un retard. Si vous n'entendez pas votre voix ça signifie que votre micro ou vos haut-parleurs sont mal configurés. Pour d'avantage de vérification de l'"Echo test", voyez [http://fgcom.flightgear.org/history.php Live FGCom] 
# Décochez la case "Echo test", ainsi que les autres cases si désiré.
# Vous pouvez aussi vérifier que votre PTT (Push-To-Talk = Appuyez-pour-parler) fonctionne correctement en regardant la case "PTT test" lorsque vous appuyez sur votre button "PTT" (par défaut: {{Key press|Space}})
# Fermez la fenêtre

=== Comment utiliser FGCom intégré ? ===
Une fois FGCom démarré avec la procédure [[Fr/FGCom_3.0#Comment_d.C3.A9marrer_FGCom_int.C3.A9gr.C3.A9_.3F|Comment démarrer FGCom intégré]], vous pouvez utiliser votre radio comme dans la réalité.

Quand vous voulez parler, vous appuyez sur la touche {{Key press|Space}}. Quand {{Key press|Shift}} est appuyé, vous n'entendez pas les autres pilotes.

Vous pouvez basculer entre COM1 et COM2 en appuyant {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: Il peut être utile de garder coché la case "Display messages" afin de vérifier le bon fonctionnement de FGCom.

=== Détails de dialog ===
La fenêtre située dans "Multiplayer > FGCom Settings" montre:

* Enable : vous pouvez cocher/décocher pour activer/désactiver FGCom intégré
* Display messages : affiche les messages FGCom seulement pour debug
* Echo test : cocher/décocher ici pour tester le serveur (Echo-Box)
* PTT test : lorsque vous appuyez sur votre PTT cette case sera cochée
* Speaker volume : règle le volume des HP pour FGCom intégré
* Silence threshold : défini la limite, en dB, lorsque FGCom considère qu'il n'y pas de voix dans votre micro
* Server > List : Sélectionne le serveur auquel se connecter (effet immédiat)

 

= FGCom autonome=
=== Installation ===
'''Si FlightGear est installé:'''

La bonne nouvelle ici est que si vous avez FlightGear installé sur votre ordinateur, vous avez déjà FGCom autonome !

'''Si FlightGear n'est pas installé:'''

Si FlightGear n'est pas installé sur l'ordinateur sur lequel vous voulez utiliser FGCom autonome, vous pouvez simplement le télécharger en suivant les étapes suivantes:

# Téléchargez FGCom autonome: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (attention à sélectionner la version correspondant à votre ordinateur !)
# Dézippez le fichier
# C'est tout! Bien sûr, vous pouvez placer le dossier "FGCom" où vous voulez dans votre ordinateur

Sur Linux, vous devez [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 modifier la permission en "éxecutable"] pour les fichiers "run_fgcom.sh" et "test_fgcom.sh"

=== Comment démarrer FGCom autonome ? ===
'''Si FlightGear est installé:'''

Sur Windows, vous devez exécuter FGCom situé dans votre menu Démarrer > FlightGear > Tools > FGCom-testing

Sur Linux, vous devez exécuter FGCom situé dans votre menu Application > Games > FGCom-testing

Sur Mac, vous devez activer "Enable FGCOM in Multi Player mode" situé dans l'onglet "Network" du lanceur Mac

'''Si FlightGear n'est pas installé:'''

Sur Windows, dans votre dossier dézippé "FGCom" vous devez exécuter (double clic) le fichier "run_fgcom.bat".

Sur Linux, dans votre dossier dézippé "FGCom" vous devez exécuter (double clic) le fichier "run_fgcom.sh".

Sur Mac, dans votre dossier dézippé "FGCom" vous devez exécuter (clic-droit > ouvrir avec > Terminal.app) le fichier "run_fgcom.command". Après la première fois vous pouvez simplement double-cliquer sur "run_fgcom.command".

'''Dans les deux cas'''

Dans un terminal ouvert maintenant, vous pouvez voir les lignes suivantes:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Loading aiports informations...

Pour arrêter FGCom autonome, pressez {{Key press|Control}} + {{Key press|c}}

=== Comment tester votre installation ? ===
'''Si FlightGear est installé:'''

Sur Windows, vous devez exécuter FGCom, situé dans votre menu Démarrer > FlightGear > Tools > FGCom-testing

Sur Linux, vous devez exécuter FGCom situé dans votre menu Application > Games > FGCom-testing

Sur Mac, FIXME: non implémenté

'''Si FlightGear n'est pas installé:'''

Sur Windows, dans votre dossier dézippé "FGCom" vous devez exécuter (double clic) le fichier "test_fgcom.bat".

Sur Linux, dans votre dossier dézippé "FGCom" vous devez exécuter (double clic) le fichier "test_fgcom.sh".

Sur Mac, dans votre dossier dézippé "FGCom" vous devez exécuter (clic-droit > ouvrir avec > Terminal.app) le fichier "test_fgcom.command". Après la première fois vous pouvez simplement double-cliquer sur "test_fgcom.command".

'''Dans les deux cas'''

Vous pouvez maintenant entendre votre voix en écho, et voir les lignes suivantes:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Echo Box - For testing FGCOM
Message: Call 0 answered

Pour arrêter FGCom autonome, pressez {{Key press|Control}} + {{Key press|c}}

=== Comment utiliser FGCom autonome ? ===
Après avoir lancé FGCom selon la procédure [[Fr/FGCom_3.0#Comment_d.C3.A9marrer_FGCom_autonome_.3F|Comment démarrer FGCom autonome]], vous devez lancer [[Fr/FGCom_3.0#FAQ| FlightGear avec l'option suivante]]:
--generic=socket,out,1,127.0.0.1,16661,udp,fgcom

Maintenant, vous laissez FGCom autonome allumé et vous pouvez lancer FlightGear

Lorsque vous voulez parler, vous appuyez sur {{Key press|Space}}. Quand {{Key press|Space}} est appuyé, vous ne pouvez pas entendre les autres pilotes.

Vous pouvez basculer entre COM1 et COM2 en faisant {{Key press|Shift}} + {{Key press|Space}}

Vous pouvez contrôler le volume avec le slider "ATC" du menu Fichier > Configuration du son (même si le bouton "ATC" est décoché)

Pendant votre session Flightgear vous pourrez voir quelques lignes dans FGCom autonome, c'est normal, elles vous informent sur l'état de FGCom autonome (quand vous écoutez, parlez, changez de fréquence, changez COM1/2...)

Pour arrêter FGCom autonome pressez {{Key press|Control}} + {{Key press|c}}

=== Détails des options ===

Le lancement de FGCom autonome avec "--help" vous montrera toutes les options possible.

'''IMPORTANT:''' Rappelez-vous que FGCom autonome marche bien sans aucune option ! Ne les utilisez que si vous savez exactement ce que vous faites.

= FAQ =
''' Comment ajouter l'option générique --generic option for FGCom autonome ? '''

Depuis FlightGear 3.0 vous pouvez sélectionner "FGCom autonome" dans la section [[FlightGear_Launch_Control#Network|FlightGear Launcher > Avancé > Réseau]] sinon:

Dans la [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|dernière page du Lanceur FlightGear]], cliquez "Advanced" puis [[FlightGear_Launch_Control#Input.2FOutput|sélectionnez "Input/Output" item]]. Pressez "New" et remplissez les champs:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' Je veux utiliser FGCom intégré mais je ne vois aucune rubrique "Multiplayer > FGCom Settings" dans FlightGear '''

Parce que vous n'avez pas FlightGear 3.0 ou plus. FGCom intégré est seulement depuis FlightGear 3.0 ou plus. Servez-vous de FGCom autonome en attendant votre mise à jour.

''' Je veux utiliser FGCom intégré mais je ne vois aucune rubrique dans "Start menu > FlightGear > Tools" '''

Parce que vous n'avez pas FlightGear 3.0 ou plus. FGCom autonome n'est automatiquement installé que pour FlightGear 3.0 ou plus.

Suivez les instructions "Si FlightGear n'est pas installé" jusqu'à votre mise à jour.

''' J'utilise FGCom autonome, les autres pilotes m'entendent mais je ne peux pas les entendre '''

Vérifiez que le slider "ATC" du menu Fichier > Configuration du son est complètement à droite.

''' J'utilise Linux et n'arrive pas à faire fonctionner FGCom '''

Veuillez lire cette page qui contient beaucoup d'informations à propos de la configuration audio pour les utilisateurs Linux, et fait aussi référence à FGCom: [[Linux software audio mixing with FlightGear]]

[[en:FGCom 3.0]]
[[Category:FGCom]]

FGCom 3.0

2015-01-01T19:32:37Z

F-JJTH: update console content

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# You can also check that your PTT works fine looking at the "PTT test" checkbox when you press your PTT button (default is {{Key press|Space}})
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Echo test : check/uncheck this for testing server communication (Echo-Box)
* PTT test : when you press your PTT this checkbox will be checked
* Speaker volume : set speaker volume for FGCom built-in
* Silence threshold : set the limit, in dB, when FGCom consider no voice in your microphone
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Loading aiports informations...

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
FGCom 3.3.0 compiled Dec 30 2014, at 17:19:39
For help usage, use --help
Starting FGCom session as guest:xxxxxxxxx@fgcom.flightgear.org
Message: Call 0 accepted
Message: Echo Box - For testing FGCOM
Message: Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "--help" argument will show you all the available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

''' I'm using Linux and I can't get FGCom working '''

Please read this page which has a lot of information about audio configuration for Linux user, even some specific reference to FGCom: [[Linux software audio mixing with FlightGear]]

[[fr:FGCom 3.0]]
[[Category:FGCom]]

Talk:FGCom (before 3.0)

2015-01-01T18:51:57Z

F-JJTH:

'''FGCOM - feature request'''

Well thanks to some very hard work by some talented people and a clueless tester FGCOM has moved ahead a great deal in the past few days. Now it is cross distro and possibly even POSIX compliant, we have a possible Openal based system which should simplify things a lot and tie in well with existing work. Work goes ahead on implementing a PTT switch and appropriate muting.

However we still have a little way to go to realistically emulate VHF aviation comms. Because we are mapping frequencies onto ''conference'' call numbers (lets leave the range aspect alone for now), two or more stations can talk at once. This isn't how it works in Real Life, only one aircraft or ATC facility can talk at a time and if someone insists on talking or the PTT switch becomes jammed on, then there is not a lot that can be done about it. Nobody else can use that frequency until the pilot stops talking or his radio is switched off. There are good reasons for this, not least the dreadful sound quality of the original radios, the sometimes life-or-death nature of the information being transferred meant that having only one pilot or controller talking while everybody else listened was A Good Thing.

This is a feature request because, much as I'd like to, I can't deliver the necessary code.

I'd like to see this highly able asterisk system crippled so that only one caller can speak at a time - To get round possible abuse of this, any caller is only allowed a max of say 30 secs (more than enough for any realistic aviation comms) before their call is terminated and they have to rejoin the conversation (come back up on channel)

Is any of this feasible?

--[[User:Willie|Willie]] 06:51, 25 November 2007 (EST)

'''Voice Quality --its too good and its not good enough ;-)'''

At present we are having lots of echo testing. This may be down to extremely cheap, oversensitive mics at my end but in general it just doesn't sound like the real thing. We have distortion but its the wrong sort. Not sure how to sort this but a first attempt would be a tight narrow pass filter and possibly mixed with a white noise source to give that "radio" sound. Could get fancy and add a definite "click" as the PTT is pressed at the beginning of a call and also when it is released.

--[[User:Willie|Willie]] 06:51, 25 November 2007 (EST)

== New FGCom require a lot of changes in documentation ==

FGCom was a separate project for many years, but now FGCom is integrated into FlightGear (even if the standalone is still available)

We need to differentiate the built-in FGCom and the standalone FGCom, that I usually call "FGCom-sa" (sa = stand alone)

It is also important to '''strongly suggest''' to use the built-in FGCom as many as possible.

FGCom-sa must be used '''only''' for those who want to run FGCom on a separate computer than the one who run the FlightGear session (this case is certainly extremly rare ! even enough rare to be ignored I think)

The question is: how to re-organize all the documentation about FGCom ?

My opinion is: FGCom standalone is destinated to be used only by OpenRadar and no longer destinated to be used with FlightGear. OpenRadar will be soon able to provide FGCom standalone into his package, that way FGCom standalone will be no longer a "required dependence" for OpenRadar. So all documentation about FGCom standalone will be no longer interesting for 99% of our users (FlightGear and OpenRadar). Only people who want run FGCom standalone (those who want run it on a separate computer certainly) will be interested by some documentation, I think the fgcom --help would be sufficient for these people who certainly have some computer skills if they want to use FGCom standalone "by-hand" (without FlightGear or OpenRadar).

As of today, the FGCom documentation looks like a big mess, not because the documentation is wrong (most of the documentation is correct) but because there is too many informations (often redundant), too many pages about FGCom, too many unrelated information with FGCom. All of this could discourage our users to read the documentation

[[User:F-JJTH|F-JJTH]] ([[User talk:F-JJTH|talk]]) 22:22, 20 October 2013 (UTC) Clément de l'Hamaide

=== Reply to: New FGCom require a lot of changes in documentation ===
This documentation was quite all-right, and did build up the FGCom usage in the past years.

The problem is, that you obviously believe you have to destroy the whole functional operation by inserting wrong and misleading informations - in order to replace a functional environment with a design that is not yet functional - and even needs a lot of more basic thinking about what really is needed! Wrong is e.g.:
* You add notes telling people that the current design is not valid any more. Actually it is right now the only functional design that exists!
* You state: "FGCom-sa must be used only for those who want to run FGCom on a separate computer!" That is very definitely WRONG!! Why should it not be used together with e.g. OpenRadar on one computer?? I do not understand how you can make such funny statements - did you not investigate what your design is needed for?
* You deleted the section describing how to setup FGFS prior to the functional test of FGCom after a new installation - that indicates to me that you never tried to help users to get FGCom to work! Otherwise you would know that most of the occurring problems are due to the interaction between FGFS and FGCom. Please do not tell me that there is just the port connection! Most of the FGCom operation depends very much on the FGFS settings (e.g. frequency, location/range, airplane, multilayer, concurrencies, finding freq. values available, possible Network-problems in a LAN-environment, etc.)
* You try to convince everybody to only use your new environment for real - not just for testing - although you know it is not yet fully functional.
* You have no consideration at all for multiplayer-events where any number of pilots come together from all parts of the world! You cannot contact them all in advance and tell them "you have to install FS 3.0 (or GIT 2.99) - otherwise you cannot participate"! I hope in the meantime you did understand that all participants of an event need to use the same server! You are killing all our achievements we worked hard for the last years, if you just neglect those user-problems/dependencies!!!
* etc.
'''That means: We do not need a whole lot of changed and/or restructured documentation -- we just need to update the current one by a few lines that tell what is different between now and may be in future! <big>Without upsetting/misleading the now user-community!</big>'''

I hope you reconsider your now actions - which may be OK for a complete new design - but definitely NOT for '''phasing in''' a new one! That FGCom "new" just cannot be "broken" in by any command from anyone!

'''Please consider: The very best engineering design is worse nothing - if it does not find users/customers.'''

'''I definitely will continue to undo all your wrong/misleading informations in the FGCOM <big>''user''</big>-documentation, that was created by me - even if that means doing it every day many times.''' I love that FGCom - and will not let it be destroyed! If you want to develop a new user-documentation in addition, you are welcome to do so - but make sure it is called "FGCom 3.0" or similar. We very definitely '''do need the old one for the time being!!''' I really would hate to find another solution!''(e.g. Mumble or similar - and pls do not try to tell me what is better about FGCom - I am the one fighting against other solutions over the last 3 years!)'' But I do need some Radio-Communication - and if you are unable to support a concurrent operation of old/new - what shall we do?

I hope you are able to consider working together with the user-community and the Maintainers/Operators of the current environment.
I personally am very interested in getting those changes operational that you right now work on - but I will not be quiet if you destroy the whole, existing '''FGCom''' project!

[[User:jomo|jomo]] Oct 31 2013

== Upper+Space should read Shift+Space! ==
Title is pretty much self explanatory, "Upper+Space" should read "Shift+Space", as the upper key could easily imply or be misunderstood for the "Cursor Up" key! (Shifted-space characters has had a more common pressence amongst computer programmers since the 1980's? Or earlier? I do however easily understand the previously mentioned "upper case" numbers, but probably should also read "shifted numbers"?) On a side note, pressing Shift+Space here doesn't appear to do much (with FGCom/Radio), and curious if some other action should occur or something printed to screen. I should also mention I'm using =games-simulation/flightgear-3.0.0, and I don't know if anything is printed to stdout since FGCom's official implimentation into FlightGear. --[[User:Rogerx|Rogerx]] ([[User talk:Rogerx|talk]]) 22:47, 19 April 2014 (UTC)

: "Shift key" Wikipedia --[[User:Rogerx|Rogerx]] ([[User talk:Rogerx|talk]]) 19:34, 22 April 2014 (UTC)

== Too many FGCom Wiki pages ==
I think there's too many FGCom Wiki pages. Should have likely stuck to one page, and split later or as FGCom evolved.

For example, here's a listing of most of the pages, and some deal with pre intigration of FGCom into FlightGear and some dealing with post integration of FGCom into FlightGear:
* FGCom
* FGCom_testing
* FGCom-3.0
* FGCom_for_Windows
(There could be more FGCom FlightGear Wiki pages.)

It is really easy with Wiki, to confine everything to one page! (The only time separate pages are likely needed, is for people on dial-up or slow ISP connections.) I was considering making a new FGCom_for_LinuxALSA, but I think it's only going to make things much worse versus any better. Probably best to push all information from the other Wiki pages back into the main FGCom page, in order to prevent information from being loss from future organization. There are some very lengthy Wiki pages on the Internet, and they're all extremely easily navigated or edited. Too many separate pages causes problems with Search Engines, or users overall trying to find information, or just overall organizational issues due to duplicated information or possibly lost information. --[[User:Rogerx|Rogerx]] ([[User talk:Rogerx|talk]]) 19:36, 22 April 2014 (UTC)

== Move away this article ==
A request for our wiki manager:

please, is it technically possible to move (delete?) this article into a new article named "FGCom_old" then redirect "FGCom" (this article) to [[FGCom_3.0]] ?

that way our users can find the last up-to-date article without spending their time to read this old and out-of-date article directly at [[FGCom]]

I just marked all the out-of-date article related to FGCom as "obsolete" in any language, those article should be ideally deleted because they are more confusing than helpful for our users, however I don't know the procedure to delete an article.

[[User:F-JJTH|F-JJTH]] ([[User talk:F-JJTH|talk]]) 19:50, 1 January 2015 (UTC) Clément de l'Hamaide

De/FGCOM Testing

2015-01-01T18:39:23Z

F-JJTH:

{{obsolete|FGCom_3.0}}

{{historical
| type = article
| tense = is
| text = obsolete
| reason = The new version of FGCom is much more simple to use, a clean documentation is available at [[FGCom_3.0]]
| talk =
| date = 1 January 2015
| nocat =
}}

Dieser "FGCOM_Testing" Artikel soll FGCOM-Benutzern helfen ihr FGCOM-System nach der Installation zu testen und evtl. zu korrigieren, aber auch um von Zeit zu Zeit die Basis-Funktionen zu überprüfen und/oder das Audiosystem neu zu justieren. Der Artikel behandelt insbesondere diese 4 Gebiete:
# Austesten der FGCOM-Installation für sich - also ohne gestartetem FGFS (Flight-Gear-Flug-Simulator)
# Testen der Verbindungen zwischen FGFS und FGCOM
# Einstellen der Lautstärke für Kopfhörer, Lautsprecher, Mikrophone,etc.
# Im [[#Appendix|Anhang]] wurden bekannte Hilfen/Fehler zusammengestellt

Natürlich müssen Sie vor dem Testen das eigentliche FGCOM installiert haben (siehe den [[FGCOM|FGCOM-Haupt-Artikel]] (sorry: Noch nicht in Deutsch))!
 

== '''Der Basis-Test der FGCOM-Installation ohne dem FGFS --> der so genannte "-f910 Test"''' ==
Öffnen Sie ein [[Command line|"Befehls-Fenster"]] und wechseln Sie in das Verzeichnis, in das das FGCOM installiert wurde. Der Weg zu diesem Verzeichnis wird dann im Fenster angezeigt, gefolgt von einem "$"-Zeichen. Geben Sie dann den folgenden Befehl ein, inklusive der angegebenen Optionen:

'''fgcom -Sfgcom01.flightgear.org -f910'''
<pre>
Für MAC können Sie benutzen:
/Applications/FlightGear.app/Contents/MacOS/fgcom -Sfgcom01.flightgear.org -f910
</pre>

{|border="1"
|+
|-
|align="center"|fgcom||Der Programmaufruf ''(im Falle daß Sie mit dem [[Scripted Compilation on Linux Debian/Ubuntu|download_and_compile.sh script]] für Linux installiert haben, müssen Sie das einfache "fgcom" durch "sh ./run_fgcom.sh" ersetzen.)''
|-
|align="center"|-S'''fgcom01.flightgear.org'''||der zentrale Server der FGCOM-Anwendung. ''Derzeit gibt es noch einen zweiten Server: -S'''fgcom.flightgear.org''', der aber weniger benutzt wird''.
|-
|align="center"|-f910||die einzig verfügbare Frequenz für den "-f910 Test"
|-
|align="center"|optional||Im Falle daß Ihr Audio-System relative "schwach" ist, können Sie die folgenden Optionen versuchen:

-i und/oder -o: i=input(Mikrophon) o=output(Lautsprecher), beide Werte zwischen 0.0 und 1.0 (e.g.: -i0.9)
|-
|| ||Sie benötigen keinerlei Login-Passworte und/oder Benutzer-Namen !!!
|}
Eine komplette Liste aller verfügbaren Optionen finden sie unter [[FGCOM#Commandline Parameters|Befehls- Parameters]] - im Folgenden gehen wir nur auf auf die gebräuchlichsten ein:
 Der obige Befehl sollte antworten mit:
fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 163M
Using iaxclient library Version SVN 163M

Successfully parsed commandline options.
Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Call 0 accepted
Call 0 answered

Wenn die Antwort so aussieht sprechen Sie in Ihr Mikrophone - was immer sie sagen wird mit einer Verzögerung (Echo) vom Server zurück-gespielt. Sie sollten eine deutliche Verzögerung feststellen!
 '''Falls das in Ordnung war'''
* tippen Sie <nowiki>ctrl-C (Strg+C)</nowiki> um das Befehls-Fenster zu schließen
* und fahren Sie mit dem nächsten Kapitel fort: [[#Testen des FGCOM zusammen mit dem FlightGear Simulator|Testen des FGCOM zusammen mit dem FlightGear Simulator]]
 '''Im Falle von Problemen''' überprüfen Sie Ihr System entsprechend der folgenden wahrscheinlichsten Fehler:

 
=== Fehler: Angabe eines falschen Installations-Verzeichnisses für FGCOM: ===
{|border="1"
|+
|-
||Eine typische Anzeige für '''Windows'''-Systeme wäre z.B.:
|-
||
C:\Users\emmerich>cd \Programme\Fxx
The System cannot find the given path.

C:\Users\emmerich>fgcom.exe -Sfgcom.flightgear.org -f910
The command "fgcom.exe" is either mistyped or could not be found.
|}
{|border="1"
|+
|-
||typisch für '''Linux'''-Systeme wäre z.B.:
|-
||
/home/emmerich/Desktop/Link to fgcom: line 1: cd: /home/emmerich/fgf: No such file or directory
sh: Can't open run_fgcom.sh
|}
* Hier hatte das System eindeutig recht, denn ich habe ihm vorsätzlich ein falsches Verzeichnis angegeben!
* Falls diese Anzeige bei Ihnen aufgetaucht ist, versuchen Sie es wieder mit dem richtigen Verzeichnis

 
=== Fehler: Tippfehler ("Typo") oder ein Netzwerkproblem: ===
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

Successfully parsed command-line options.
Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
nach einiger Zeit kann danach folgen:
''' Call 0 timed out.'''
'''Timeout for a non-existent session. Dropping'''
Dies bedeutet sehr wahrscheinlich:
* Sie haben eine falsche Frequenz angegeben oder sogar völlig vergessen. Sie müssen unbedingt die '''Option -f910''' mit eingeben
* Sie haben vor einer Option das '''"-"-Zeichen vergessen'''
* Sie haben '''"-sfgcom..." klein geschrieben''', anstatt richtig groß "-Sfgcom..."
* Sie haben den '''FGCOM-Servernamen''' falsch geschrieben oder überhaupt (aus welchen Grund auch immer) einen anderen Server angegeben
* oder Sie haben einen '''"neuen Typo"''' erfunden
* oder Sie haben ein '''generelles "Netzwerk-Problem":'''
** Überprüfen Sie Ihr Netzwerk mit anderen Anwendungen (z.B. beim Aufrufen einer "sonst nicht benutzten" Web-Seite - falls Sie eine gebräuchliche benutzen wird diese evtl. aus Ihrem lokalen Speicher genommen - anstatt über das Netzwerk geholt!
** Falls Sie eine Firewall benutzen (was Sie grundsätzlich sollten!!) stellen Sie sicher daß die folgenden Ports frei gegeben sind:
2005 UDP Vcp-Stream
4569 UDP FGCom VoIP, (Inter-Asterisk eXchange)
5000 UDP in/out Multiplayer (VPN Sftw.)
16661 UDP FGCom Verbindung zu FGFS, normalerweise wird nur “local host” (intern) benötigt

=== Fehler: "Phone-book" und/oder "positions" können nicht gefunden werden oder sind kaputt: ===
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

Successfully parsed commandline options.
'''Reading list of airports...Cannot open /home/emmerich/fgfs/install/fgcom/fgcom/positions.txt'''
'''fopen: No such file or directory'''
'''Stopping service.'''
(etc)
* überprüfen Sie das Verzeichnis in dem FGCOM installiert wurde auf die Dateien "phonebook.txt" und "positions.txt". Das sind ganz normale Text-Dateien in die Sie evtl. zusätzliche Daten eintragen können. Wenn Sie die Daten ändern, sollten Sie bei Windows unbedingt das "WordPad" benutzen (nicht den "Editor"!). Falls Sie komplette Dateien zwischen "Windows" und "Linux" austauschen, können Probleme auftreten - bei einzelnen Zeilen wurden noch keine Probleme gemeldet (für "MAC" habe ich keine Test-Ergebnisse).

 
=== Fehler: Die Sound-Karte verträgt sich nicht mit Ihrem Betriebssystem: ===
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

'''AL lib: alsa.c:564: set access failed: Invalid argument'''
Successfully parsed commandline options.
Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Call 0 accepted
Call 0 answered
* '''Falls dieser Fehler auftrat:'''
** Aber alles Andere OK war, fahren Sie fort (aber versuchen Sie eine "neuere" Sound-Karten zu bekommen!)
** ansonsten suchen Sie im Internet nach neuen Treibern für Ihre Sound-Karte oder sonstige Fixes.

 

== '''Testen des FGCOM zusammen mit dem FlightGear Simulator''' ==

Im vorhergehenden Kapitel haben wir den FGCOM als ein eigenständiges System getestet. Nun werden wir testen, ob FGCOM und FGFS zusammenarbeiten können, d.h. inklusive der PTT-Teste ("Push To Talk" = "Drücken zum Sprechen", normalerweise die Leer-Taste), und ob die interne Kommunikation über die internen Ports funktioniert, etc.
 
Für diesen Test
<ol><li>starten Sie zuerst den FGFS mit irgendeinem Flugzeug auf einem Flugplatz Ihrer Wahl

 
<li>dann starten Sie den FGCOM (normalerweise ist es egal welches Programm Sie als erstes starten - aber im Fall von Problemen ist es besser in dieser Reihenfolge zu starten!) ''(Ich hoffe Sie haben nicht vergessen die Option "-f910" aus Ihrem Startbefehl zu entfernen!!)''</li>

 
<li>Klicken Sie (mit der linken Maustaste) in der FGFS-Menü-leiste auf "Equipment" (Ausstattung) --> dann "Radio-Settings" (Radio Einstellungen)
* geben Sie in das Feld "COM1" die Frequenz "910.00" und klicken dann auf "Apply" (Anwenden) (und evtl. "OK" wenn Sie das Fenster schließen wollen)
* '''überprüfen Sie immer wieder, daß das FGFS das aktive Fenster ist - wann immer etwas nicht "antwortet" wie erwartet, versuchen Sie zuallererst in das FGFS-Fenster zu klicken, um sicher zu stellen daß dieses das aktive Fenster ist - und versuchen Sie dann die letzte Aktion noch einmal!'''

 
<li>Falls sich das FGCOM Befehls-Fenster öffnet, aber nicht auf die Eingaben der COMM-Frequenzen reagiert:
 Dies deutet auf ein reines Verbindungsproblem zwischen FGFS und FGCOM hin:
* Versuchen Sie den (normalerweise bereits voreingestellten) Standard-Verbindungs-Port zu erzwingen. Das heißt fügen Sie die Option "-p16661" der Befehlszeile zum Starten des FGCOM hinzu.
* Überprüfen Sie die erweiterten ("advanced") Optionen des FGrun (bzw. Wizard): Unter Ein-/Ausgang (Input/Output) gibt es "generic=socket..": Übertippen Sie den dort angegebenen Port mit der gleichen Port-Nr. wie in der Startzeile des FGCOM. Also "16661" (falls von Ihnen nicht bewußt geändert).
* Sie können auch versuchen den Verbindungs-Port bewusst zu ändern, z.B. auf "UDP 5004". Falls sie das tun, müssen Sie an drei Stellen ändern:
** fügen Sie dem FGCOM-Startbefehl die Option "-p5004" hinzu
** ändern Sie auch den Wert in den FGrun (Wizzard) --> Advanced Options --> Input/Output --> Generic=soccket (zu 5004)
*** bzw. fügen Sie Ihrem FGFS-Startbefehl die Option "--generic=socket,out,10,localhost,5004,udp,fgcom" hinzu
** und Sie müssen diesen Port in einer evtl. vorhandenen "Firewall" freigeben (UDP 5004)
* Überprüfen Sie auf jeden Fall, daß an allen 3 vorgenannten Stellen die gleiche Port-Nummer angegeben ist!

 
<li>Drücken Sie die PTT-Taste und sprechen Sie in Ihr Mikrofon. ''("PTT" = "Push To Talk" == Drücken zum Sprechen. Dies ist normalerweise die Leer-Taste - falls Sie diese Anordnung geändert haben, benutzen Sie die von Ihnen definierte Taste.)''
* Sie sollten das gerade von Ihnen gesprochene wie in einem Echo hören -- wenn Sie "eins" sagen sollten sie das Echo erst hören, wenn sie das Wort komplett gesagt haben!
* '''Falls Sie das Echo gehört haben:'''
** Halten Sie die PTT-Taste für etwa 3 sec gedrückt - und achten Sie darauf ob sich "ungewöhnliche Geräusche" aufbauen
*** falls es solche Geräusche gibt machen Sie weiter mit dem Kapitel [[#Einstellen des Mikrophons und der Lautsprecher|Einstellen des Mikrophons und der Lautsprecher]]
*** ansonsten stellen Sie wieder die gewünschte Frequenz ein - und fahren dann mit dem nächsten nummerierten Punkt fort
<ul><li>'''Falls Sie das Echo Nicht gehört haben
<ul><li>Testen Sie Ihren PTT (Mikrofon-Taste) und achten Sie auf die Rückmeldungen im FGCOM-Befehlsfenster:
<ul><li>Wenn Sie den PTT einschalten müssen die Meldung umschalten, z.B.:
</ul></ul></ul>
[SPEAK] unmute mic
[LISTEN] mute mic
*** Falls die Meldungen sich nicht wie vorstehend ändern, fliegen Sie derzeit wahrscheinlich ein Flugzeug bei dem die Leertaste für etwas anderes verwendet wird:
*** Überprüen Sie die "''IhrFlugzeug"-set.xml" Datei in Ihrem Verzeichnis FGFS/data/Aircraft/YourPlane: Falls Sie dort eine Zeile “<key n="32">” finden, dann verwendet diese Modell ganz bewusst den "key 32" (Leertaste) für etwas anderes. Im Feb.2009 war bekannt, dass die Modelle an2, bluebird-base, ogel, OV10.., seatfireIIc, spitfireIIa, ufo etc. dies tun.

 
== '''Einstellen des Mikrophons und der Lautsprecher''' ==
Schließlich müssen wir noch die Mikrophone und Lautsprecher Lautstärken optimiere, um insbesondere von anderen besser verstanden zu werden:
 ''(Sie könnten dies auch mit dem "f910-test" im Kapitel 1 machen, aber hier macht es mehr Sinn da das gesamte Umfeld mit eingebunden wird
<ol>
<li>Starten Sie Ihr FGFS und FGCOM wie vorhergehende beschrieben, COM1 muß auf 910.00 eingestellt werden und das aktive Radio sein!
<li>Sprechen Sie in das Mikrophone und verifizieren Sie daß Sie das Echo zurückbekommen. Falls dies nicht funktioniert wiederholen Sie die vorgehenden Kapitel.
<li>Während Sie nun in das Mikrophone sprechen justieren Sie Ihren Lautsprecher so, daß Ihre Echo-Rückgabe gut verständlich ist, aber nicht lauter als tatsächlich nötig
<li>'''Justieren Sie nun das Mikrophone''' von "stumm" zu "maximal". Irgendwo auf dem Weg dazwischen werden Sie eine Stelle entdecken an der Ihre zurückkehrenden Worte nicht mehr lauter werden - obwohl Sie die Lautstärke erhöht haben. Belassen Sie die Lautstärke gerade etwas unterhalb dieser Schwelle.
<li>Nachdem nun das Mikrophon eingestellt ist '''justieren Sie die Lautsprecher''' entsprechend Ihrer eigenen Zufriedenheit
<li> Zum Schluß verifizieren Sie beide Einstellungen dadurch, daß Sie den PTT für etwa 10 Sec. gedrückt halten '''ohne''' in das Mikrophon zu sprechen oder sonstige Geräusche zu verursachen! Achten Sie darauf, ob sich dabei komische Geräusche wie z.B. "Pfeifen", "klicken", "Luft in einer Wasserleitung" oder ähnlich aufbauen - jegliche Geräusche die sich über die Zeit aufbauen sind absolut unerwünscht!
* Diese "sich über die Zeit aufbauenden" Geräusche entstehen sehr häufig durch "Mikrophon Booster" (automatische Verstärker). Falls Ihr Computer und/oder Betriebssystem solche Booster verfügbar hat, benutzen Sie diese möglichst nicht - und wenn doch halten Sie deren Einsatz/Verstärkung auf ein absolutes Minimum. Drehen Sie lieber die normale Verstärkung weiter auf! Letzteres verstärkt sich nicht selbsttätig wenn die Stimme leiser wird oder völlig verstummt!
<li>Achten Sie darauf, daß Sie nicht direkt in das Mikrofon sprechen, halten Sie es etwas schräg am Mundwinkel (kein rein-spucken + keine übersteuerungen!). Die Entfernung zu Ihrem Mund darf sich aber auch nicht ständig ädern - die meisten Mikrofone reagieren darauf sehr stark (USB-Mikrofone vergeben solch kleine Sünden besser!).
<li>Aber auch eine zu laute Einstellung der Lautsprecher kann solche "merkwürdigen Geräusche" verursachen - versuchen Sie also auch die Lautstärke-Einstellung zu reduzieren, falls sich die Nebengeräusche ansonsten nicht beseitigen lassen!
<li>Jetzt können Sie mit Anderen kommunizieren. Das heißt: Setzen Sie Ihr COM1 auf die gewünschte Frequenzen und lassen sich von Ihren Mitspielern bestätigen daß Sie eine "absolut phantastische Stimme haben".
* Nebenbei bemerkt: Sie müssen mit dieser "Feuertaufe" nicht bis auf den nächsten Multiplayer-Ausflug warten: Sehen Sie einfach in der "Pilot-List" nach (FGFS --> Menü --> Network --> Pilot List) wer aktive ist und versuchen Sie diese/n via MPchat (FGFS --> Menü --> Network --> Chat) "anzutippen" und zu fragen welche FGCOM-Frequenz er benutzt. Fast alle FGCOM-Benutzer werden Ihnen gerne behilflich sein (leider aber haben noch nicht alle FGCOM!). Evtl. müssen Sie erst im [[MPMap|MPmap]] nachschauen, wo sich Piloten aufhalten - denken Sie daran: MPchat reicht etwa 100nm, FGCOM nur 50 km (etwa 28 nm)! (Evtl. sollten Sie versuchen diesen letzten Test in Englisch zu machen - vielleicht kann ein Freund als Gegen-Sprechstelle einspringen!)
</ol>
Aber BITTE-BITTE: '''Drücken Sie die PTT-Taste nur, während Sie tatsächlich sprechen!. Denn wann immer jemand die Taste drückt (um zu sprechen oder z.B. nur weil zufällig ein Buch darauf liegt, etc.) können alle anderen diese Frequenz nicht benutzen -- damit könnten Sie sich ganz schnell sehr unbeliebt machen!! Und versuchen Sie immer nur kurze Sätze zu sprechen (absolut niemals länger als 20 Sec!) - und dann wieder eine Pause einzulegen, um zu hören ob jemand anders was zu sagen hat. Nach einiger Zeit unterbricht Sie der Server automatisch - aber darauf müssen Sie ja nicht unbedingt warten - bis dahin sind Sie längst der "meist gehasste Mensch" auf der Frequenz!!!'''
 

== '''Appendix''' ==

=== Tips und Tricks ===
==== Typische Probleme ====
<ol><li>Mikrophone nicht verbunden: Es klingt idiotisch - aber die meisten technischen Probleme basieren auf solchen "das kann gar nicht sein"s - bitte - bitte spenden Sie die 2 sec. um dies als Erstes zu überprüfen, dazu gehört auch die Überprüfung ob Ihr Mikrophone einen eigenen Ausschalter hat und ob dieser auf "on" steht!
</li> <li>Stecker/Buchsen Verbindungen sind immer recht kritisch (z.B. wegen Oxidation): Versuchen Sie ihre Stecker mehrfach raus zuziehen und wieder einzustecken. Im Zweifelsfall versuchen Sie einen anderen Eingang der Sound-Karte zu benutzen.
</li> <li>Mehrere Mikrophone und/oder Lautsprecher am PC angeschlossen: An vielen PC's befinden sich mechanische Vorrichtungen, die evtl. vorhandene weitere Steckerbuchsen abschalten. Versuchen Sie evtl. nur die Haupt-Steckerbuchsen zu benutzen - dies befinden sich zumeist auf der Rückseite des PC'S.
</li> <li>Falls Sie Ihre Audio-Einstellungen geändert haben oder ein Audiogerät ausgewechselt oder umgesteckt haben, machen Sie unbedingt erst einen PC-Restart, damit das Betriebssystem die Geräte neu zuordnen kann! (Bei Windows ist das oft nicht nötig - aber oft heißt nicht immer - und schaden kann es auf keinen Fall!)
* Falls Sie einen USB-Headset verwenden, sollten Sie evtl. erst versuchen FGCOM mit den Standardgeräten einzurichten - und erst nachdem diese funktioniert haben die USB-Geräte anschließen -- diese sind heutzutage noch nicht ganz so gebräuchlich und verursachen dadurch manch unerwartete Problem.
</li> <li>Stellen Sie sicher daß keines Ihrer Geräte auf "Mute" steht (ausgeschaltet ist):
* Feuer Standard PC's können sie zumeist mit der rechten Maustaste auf das Lautpsrechersymbol in der Task-Leiste klicken.
** Für Windows-Systeme: Falls das Lautsprechersymbol nicht da ist:
*** '''für Vista + Windows 7''': Linker Mausklick auf "Start" --> tippen Sie "SndVol.exe" in die leere Zeile direkt oberhalb des "Start"
*** '''für XP:''' Linker Mausklick auf Start, dann auf "Run", tippen Sie “SndVol32.exe” in die "PopUP-Eingabezeile"
* Für besonders "komplexe (und teure)" Sound-Karten müssen Sie evtl. deren Beschreibungen benutzen!
* FGCOM ist nur zur Übertragung von Sprache gedacht (Telefone/TCP-IP) und benötigt deshalb keine besonders "gute" Sound-Karte - (ich kenne allerdings Leute die auch gerne mal Ihre Freunde mit Country-Musik unterhalten - das funktioniert zwar - ist aber nicht wirklich HiFi!
</li> <li>Stellen Sie auf jeden Fall sicher, daß Sie mit Ihrem Betriebssystem und den dort standardmäßig vorhandenen Programmen (ohne FGCOM und/oder FGFS und/oder "OpenAL") etwas Aufnehmen und Zurueckspielen können. (Sehen Sie hierzu Ihre Systemunterlagen und/oder das Kapitel [[#Wo Sie die Lautstärken einstellen können:|Wo Sie die Lautstärken einstellen können:]])
</li> <li>Falls bei den Verbindungen Störgeräusche auftreten oder diese qualitativ ungenügend sind:
* Testen Sie zuerst noch einmal die Audio-Einstellungen wie bereits beschrieben (siehe [[#Einstellen des Mikrophons und der Lautsprecher|siehe vorstehend]])
* versuchen Sie Ihre Audio-Kabel möglichst weit von Störquellen weg zu verlegen (z.B.: Gebläse, AC/DC Umwandler, Motoren/Gebläse, Lampen, etc.)
* es kann sogar helfen Ihre Sound-Karte umzustecken
* ein (digitales) USB-Headset kann helfen Störungen zu vermeiden - reagiert aber auch kritischer auf Geräusche in der Umgebung
* falls auf Ihrer Audio-Karte "Stero-Mix" aktiviert ist, versuchen Sie dies (zumindest während der Tests) auszuschalten
</li> <li>Bei fast allen Systemen müssen Sie die "Leertaste" als den PTT (PushToTalk - Mikrophone-Schalter) gedrückt halten während Sie sprechen. Aber es gibt auch Audio-System bei denen Sie den PTT drücken und wieder loslassen müssen um das Mikrophon einzuschalten, erst ein zweites Drücken und Loslassen schaltet das Mikrophon wieder aus. Überprüfen Sie wie Ihr System funktioniert -- gerade hier kann die Aufzeichnung eines von Ihnen gesprochenen Satzes und dem anschließenden Zurückspielen helfen.
</li> <li>Falls die FGFS-Sprachausgaben die FGCOM-Ausgaben übertönen:
* Nach dem Start des FGFS klicken Sie auf "File" im FGFS-menü, dann auf "Sound Configuration": verschieben Sie den oberen Regler wie benötigt. Beachten Sie, daß diese Einstellung wieder zurückgesetzt wird wenn Sie den FGFS mittels "X" in der Fenster-Leiste verlassen - gewöhnen Sie sich daran den FGFS mittele "File" und "Exit/Quit" zu beenden.
* Anders herum können Sie die Lautstärke des FGCOM mittels der "-o" und/oder der "-i" Optionen mit Werten zwischen "0.0" bis "1.0" verändern ([[#Der Basis-Test der FGCOM-Installation ohne dem FGFS --> der so genannte "-f910 Test"|siehe das FGCOM Start-Kommando am Anfang dieser wiki-Seite]]).
</li> <li>Es ist bekannt, daß die AirToAir (weltweite) Frequenz 123.45 noch nicht funktioniert - die Ursache und ein Lösungstermin sind noch unbekannt. (Dies gilt für alle Betriebssysteme).
</li> <li>Wussten Sie schon? Falls gerade keine Tower-Frequenz in Reichweite ist - können Sie auch VOR-Frequenzen benutzen. Setzen Sie diese einfach in Ihr COM1 oder COM2 (an statt NAV1 oder NAV2).
</li></ol> Seien Sie versichert: Inzwischen wurde FGCOM auf allen bekannten Betriebssystem eingesetzt und getestet. Falls also Probleme auftreten ziehen Sie auch in Betracht daß andere Geräte und oder Programme Ihres PC's diese Probleme verursacht haben können!
 
==== Hochwertige Sound-Karten ====
Insbesondere "hochwertige Sound-Karten" (z.B. für Audio-Studios) können Probleme verursachen, da manche
* das Mikrophon nach einer bestimmten Zeitspanne selbsttätig abschalten -- ohne daß Sie das bemerken (müssen)!
* während des Reboots immer die gleichen Standardwerte laden - anstatt die zuletzt benutzten!
* sogar alle Einstellungen auf "0" setzen
* das Mikrophone erst nach Drücken '''und''' wieder Loslassen des PTT das Mikrophon einschalten - während wir das Mikrophone nur aktiv haben wollen, wenn der PTT aktive gedrückt ist. (Diese Funktion verhällt sich unter Umständen unterschiedlich, je nachdem ob der PTT an einem Joystick oder auf der Tastatur gedrückt wird!) 
Sie sollten also wissen (bzw. testen) wie sich Ihr Mikrophon verhält!
 
==== Speziell für Linux (.alsoftrc) ====
(ref.: [[Linux software audio mixing with FlightGear]]) 
Suchen Sie in ihrem Home-Verzeichnis ("~/") die Datei "'''.alsoftrc'''" (beachten Sie, daß dazu "show hidden Files" ("Zeige versteckte Dateien") aktiviert sein muß!).
* Falls die Datei ".alsoftrc" nicht existiert
** Überprüfen Sie ob es die ältere Version ".openalrc" gibt
*** falls ja: Überprüfen Sie ob Sie tatsächlich die alte Version "OpenAL Library" benutzen oder die neuere "OpenAL-soft Library". Falls Sie noch die ältere benutzen fügen Sie Folgendes in die Datei ".openalrc" ein:
(define devices '(alsa))
(define alsa-out-device "plug:dmix")
*** falls nein: Erstellen Sie eine neue Datei ".alsoftrc" und fügen in diese ein:
format = AL_FORMAT_STEREO16
cf_level = 1
drivers = alsa
[alsa] # ALSA backend stuff
device = plug:dmix
capture = plug:dsnoop
Die OpenAL-soft Konfigurations-Datei sollte "/etc/openal/alsoft.conf" sein (oder ähnlich). Üblicher Weise beinhaltet diese Kommentare, die alle möglichen Einstellungen beschreibt.
 
==== USB-Headset-Probleme unter Linux (Ubuntu) ====
Das folgende wurde unter Ubuntu gefunden/verifiziert, sollte aber auf alle Linux-Versionen zutreffen:
* Falls Sie problemlos ein Aufnahme machen können '''und''' auch der [[#Der Basis-Test der FGCOM-Installation ohne dem FGFS --> der so genannte "-f910 Test"|f910-Test]] im Befehls-Fenster das richtige Ergebnis zeigt - aber die "Echo" Rückgabe nicht erfolgt:
** tippen Sie "cat /proc/asound/modules" in ein leeres Befehls-Fenster ein, dann sollte etwa Folgendes im Fenster erscheinen:
$ cat /proc/asound/modules
0 snd_usb_audio
1 snd_hda_intel
** falls dabei mehrere Audio-Geräte angezeigt werden (wie vorstehend "usb" und "hda"), dann sollte der USB-Headset in der oberen "0-Position" stehen. Falls dies nicht der Fall ist, notieren Sie sich den kompletten Namen Ihres USB-Gerätes (hier z.B. "snd_usb_audio") und ändern Sie Ihre Konfiguration. z.B. geben Sie in ein Befehls-Fenster ein:
"sudo gedit /etc/modprobe.d/alsa-base.conf"
fügen Sie in die Datei als letzte Zeile ein, z.B.
options snd_usb_audio index=0
achten Sie auf den richtigen Namen Ihres USB-Gerätes!
 
==== Festival ====
* Falls Sie den "Text zu Sprache" Zusatz '''Festival''' verwenden
** und
*** dieses ohne FGCOM einwandfrei funktioniert
*** aber Probleme wie "can't open /dev/dsp" meldet wenn es mit FGCOM und/oder FGFS (und/oder anderen Anwendungen) zusammen läuft
** dann erstellen Sie in Ihrem Home-Verzeichnis ("~/") eine Datei ".festivalrc" mit den Zeilen:
(Parameter.set 'Audio_Command "aplay -q -c 1 -t raw -f s16 -r $SR $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)
</ol> 
=== Wo Sie die Lautstärken einstellen können: ===
Bitte denken Sie daran, daß FGCOM auf sehr unterschiedlichen PC's, Notebooks, etc. unter sehr verschiedenen Betriebssysteme verwendet wird, und zusätzlich auch noch sehr unterschiedliche Sound-Karten mit den unterschiedlichsten Möglichkeiten verwendet wird. Somit könne wir im Folgenden nur die grundsätzlichen Konzepte aufzeigen. Falls diese nicht ausreichen um Ihr System zu erkennen, müssen Sie in Ihren speziellen System und/der Sound-Card Beschreibungen nachschauen!
<ol>

'''<li>Definiere die zu benutzenden Geräte:'''
{| border="1"
|+
|width=300 align="center"|'''für Linux:'''
|width=300 align="center"|'''für Windows:'''
|width=300 align="center"|'''für MAC:'''
|-
|width=300|Geben Sie folgenden [[Command line|Befehl]] ein: ''gnome-sound-properties''
[[File:FGCOM-U-Prefs.jpg|thumb|center|250px|test devices]]
Für jeden Vorgang können Sie ein Auswahl-Menü öffnen (siehe den nach unten gerichteten Pfeil) und dort das gewünschte Gerät aussuchen. Ich empfehle es als erstes mit "Autodetect" (Automatische Auswahl) zu versuchen. Dann klicken Sie auf den grünen "Test"-Knopf. Falls Sie Änderungen vornehmen, starten Sie Ihren PC nach jeder Änderung neu, um sicher zu stellen daß das Betriebssystem die Änderung erkannt hat!
|width=300| Klicken Sie mit der rechten Maustaste auf das audio-icon in der Menü-Leiste → Preferences → Audio-tab:
[[File:FGCOM-W-Audio.jpg|thumb|center|250px|set devices]]
Beachten Sie die beiden Tabs: '''Audio''' und '''Stimme''', sie müssen die Einstellungen in beiden ändern!
|width=300|Öffnen Sie Menu --> System-preferences:
[[File:FGCOM-OVol.jpg|thumb|center|250px|set devices]]
Schalten Sie um zwischen "Output" (Ausgabe) und "input" (Eingabe) und wählen Sie dort die gewünschten Geräte im Feld "Chose a device...".
|}
Falls Sie hier die Auswahl geändert habe, rebooten Sie Ihr System bevor Sie fortfahren!
 

'''<li>Einstellen der Lautstärke und des "Boosters"''' (bei der ersten Einstellung der Lautsprecher sollten Sie vorsichtshalber vorher das Mikrofon ausschalten!)
{| border="1"
|-
|width=300|Rechts-Klick auf das Audio-Icon → Open Vol. Ctrl:
[[File:FGCOM-UVolCtrl.jpg|thumb|center|250px|Volume Control]]
Die Anzahl der Schieberegler ändert sich automatisch entsprechend der Möglichkeiten Ihrer Sound-Karte oder dem USB-Headset.

Den “Booster” finden Sie unter "Switches" (eventuell müssen Sie ihn erst unter "Preferences" (Einstellungen") aktivieren!)
|width=300|Rechts-Klick auf Audio-Icon → Volume-Ctrl. (oder geben Sie den Befehl ein: sndvol32)
[[File:FGCOM-W-VolCtrl.jpg|thumb|center|250px|set devices]]
In dem gezeigten Beispiel wird das vom Betriebssystem vorgegebenen "Mic." wegen der speziellen Möglichkeiten der Sound-Karte mit "Rear Pink In" überschrieben, da dieser Eingang sich automatisch dem eingesteckten Gerät anpasst! Achten Sie auf ähnliche Änderungen bei höherwertigen Karten!
Den "Booster" finden Sie unter "Optionen".
|width=300|Benutzen Sie das oben gezeigte Fenster für die Einstellungen.
|}
 

'''<li>Verifizieren Sie die Funktionalität des Mikrophon/Lautsprecher-Systems:'''
 Benutzen Sie die "volume-control-panels" (s.o.) um das Mikrophon für diesen Test zu aktivieren. Dann:
{| border="1"
|-
|width=300|Öffnen Sie das Aufnahmegerät durch Eingabe des [[Command line|Befehls]]: ''gnome-sound-recorder''
[[File:FGCOM-U-sndctrl.jpg|thumb|center|250px|Recording-test]]
* Record (Aufnehmen)
* Stop (stop)
* Play (Abspielen)
|width=300|Öffnen Sie das Aufnahmegerät durch Eingabe des [[Command line|Befehls]]: ''sndrec32''
[[File:FGCOM-W-sndrec.jpg|thumb|center|250px|Recording-test]]
* Starten Sie die Aufnahme (durch Mausklick auf den roten Punkt)
* sprechen Sie einige Worte in das Mikrofon
* stop (Mausklick auf das Rechteck)
* zurückspoolen ( < < )
* abhören (>)
|width=300|Unseres Wissens gibt es im Standard OSX kein vergleichbares Aufnahmegerät!
|}
[[en:FGCOM Testing]]

[[Category:FGCom]]

Fr/FGCOM Testing

2015-01-01T18:39:04Z

F-JJTH:

{{obsolete|FGCom_3.0}}

{{historical
| type = article
| tense = is
| text = obsolete
| reason = The new version of FGCom is much more simple to use, a clean documentation is available at [[FGCom_3.0]]
| talk =
| date = 1 January 2015
| nocat =
}}

Ce test de FGCOM "FGCOM_Testing" est destiné aux utilisateurs pour les aider à faire fonctionner FGCOM après l'avoir installé, mais aussi à ceux qui voudront en vérifier son fonctionnement de base, ou régler leur configuration audio. Les détails dans les 4 paragraphes qui suivent
# Test de l'installation de FGCOM indépendant
# Test de FGCOM avec FlightGear
# Réglage du volume du micro et des haut-parleurs</ol>
# Dans l'[[#Appendix|Appendice]], des informations d'aide

Bien sûr, la première condition pour la suite, c'est d'avoir déja installé FGCOM (voir[[FGCOM|FGCOM-page principale]]) !
 

== '''Le test initial d'installation autonome est appellé "-f910 Test"''' ==

Avant d'executer la[[Command line|commande]] suivante, ouvrez la fenêtre de commande et allez dans le répertoire dans lequel FGCOM a été installé. Ce chemin sera ensuite montré dans la fenêtre de commande, suivi d'un signe "$". Ensuite, entrez la commande "fgcom avec les options demandées/désirées:

<pre>fgcom -Sfgcom.flightgear.org -f910</pre>

: ''fgcom''
:: la commande ''(dans le cas d'installation avec [[Scripted Compilation on Linux Debian/Ubuntu|download_and_compile.sh script]] LINUX vous devez remplacer la commande "fgcom" par "sh ./run_fgcom.sh". La commande complète sera alors: "'''sh ./run_fgcom.sh -f910'''")''
: ''-Sfgcom.flightgear.org''
:: le serveur central pour FGCOM
: ''-f910''
:: la seule fréquence valable pour les écho-tests
: optionnel
:: En cas de faiblesse de votre audiosystème vous pouvez essayer les options:
:: ''-i and/or -o'': i=input(microphone) o=output(Speaker), les deux valeurs entre 0.0 and 1.0 (ex.: -i0.9)

Vous n'avez pas besoin de mot de passe ou de nom d'utilisateur !!!

Pour connaître toutes les options valables, voir [[FGCOM#Commandline Parameters|Paramètres de la ligne de commande]] - ce qui suit ne montrera que les options minimales requises:
<pre>Vous obtiendrez en retour:
fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 163M
Using iaxclient library Version SVN 163M

Successfully parsed commandline options.
Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Call 0 accepted
Call 0 answered
</pre>

Parlez dans votre micro et vos mots seront répétés en écho après un court délai. ex: dites "one" et vous remarquerez que le "one" est répété '''après''' que vous ayez fini de parler.
 '''Si c'est correct'''
* tapez <nowiki>ctrl-C</nowiki> pour quitter cette fenêtre Quick-Test command
* et continuez avec le chapitre suivant: [[#Test the FGCOM together with the FlightGear Simulator|Test de FGCOM avec FlightGear Simulator]].
 '''En cas d'échec''' notez les principales causes d'erreur:

 
=== Erreur: FGCOM ne marche pas à cause de la version OpenAL: ===
Si vous avez un message de l'OS semblable au message Windows suivant:
"The procedure entry point alcCaptureSamples could not be located in the dynamic link libary Open AL32.dll."
Téléchargez et installez le dernier software OpenAL avec: http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx
: pour windows: '''alinst.zip'''
: pour Linux: '''openal-soft-1.10.622'''
: pour OSX: '''OpenALInstaller'''
''Attention, les versions et aussi les modules peuvent changer -- aussi, toujours vérifier la description du module du côté droit de la page http''

 
=== Erreur: Répertoire incorrect indiqué pour FGCOM: ===

typique de '''Windows'''-Systems:
<pre>
C:\Users\localuser>cd \Programme\Fxx
The System cannot find the given path.

C:\Users\emmerich>fgcom.exe -Sfgcom.flightgear.org -f910
The command "fgcom.exe" is either mistyped or could not be found.
</pre>

typique de '''Linux'''-Systems:
<pre>
/home/emmerich/Desktop/Link to fgcom: line 1: cd: /home/emmerich/fgf: No such file or directory
sh: Can't open run_fgcom.sh
</pre>

* Le système est correct: J'ai donné (pour le test) un faux répertoire!
Corrigez avant de réessayer!

=== Erreur: "TYPO" (commande ou option mal tapée) ou problème réseau: ===
<pre>
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

Successfully parsed command-line options.Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
</pre>
quelquefois, on peut avoir:

<pre>
''' Call 0 timed out.'''
'''Timeout for a non-existent session. Dropping'''

</pre>
ou
<pre>
'''Call 0 accepted'''
'''Call 0 answered'''
'''The service is unavailable. Please wait until fgcom Version 3 is online. Thank you.'''
</pre>
plus vraisemblablement vous pouvez avoir aussi:

* défini une fréquence erronée, ou omis d'en avoir défini une. Vous '''devez définir l'option -f910'''
* oublié un signe "-" en face d'une option
* tapé une minuscule à "-sfgcom..." au lieu d'une majuscule "-Sfgcom..."
* mal tapé le nom du Serveur ou désigné un FGCOM-Server erroné
* ou vous pouvez vous-même avoir créé votre erreur "typo" (lol).
* ou cela peut indiquer un '''Problème-Réseau''':
** Vérifier votre réseau en utilisant une autre application (ex: votre navigateur pour trouver une adresse http inhabituellement utilisée - si c'est une adresse récemment utilisée la réponse pourrait être hors de vos copies de sauvegarde - même si le réseau n'est pas connecté (ex: utilisez "http://mainz.de/" pour tester)
Si vous utilisez un pare-feu (ce qui est probable, pour raisons de sécurité) soyez sûr que les ports en dessous sont désactivés dans votre PC.

<pre>
2005 UDP Vcp-Stream
4569 UDP FGCom VoIP, (Inter-Asterisk eXchange)
5000 UDP in/out Multiplayer (VPN Sftw.)
16661 UDP FGCom listening to FGFS, usually on localhost only
</pre>

=== Erreur: "Phone-book" et/ou "positions" ne peuvent être trouvées et/ou sont corrompus: ===
<pre>
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

Successfully parsed commandline options.
'''Reading list of airports...Cannot open /home/emmerich/fgfs/install/fgcom/fgcom/positions.txt'''
'''fopen: No such file or directory'''
'''Stopping service.'''
(etc)
</pre>
* vérifier le répertoire dans lequel FGCOM est installé pour les fichiers "phonebook.txt" et "positions.txt". Ce sont des fichiers-texte ordinaires dans lesquels vous pouvez ajouter des informations manquantes avec un éditeur standard, pour Windows "WordPad" (pas l' "Editor"). Remplacer un position.text "Windows" avec un "Linux" peut entraîner des erreurs, bien que les lignes des deux fichiers puissent être échangées/ajoutées.

=== Erreur: La Carte-Son n'est pas pleinement compatible: ===
<pre>
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

'''AL lib: alsa.c:564: set access failed: Invalid argument'''
Successfully parsed commandline options.
Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Call 0 accepted
Call 0 answered
</pre>
* Continuer vérification/ajustement:
** Si tout le reste est OK, oubliez le problème (mais attention, l'Audio pourrait ne pas fonctionner correctement!)
** autrement, consultez Internet pour les nouveaux drivers de votre Carte-Son.

 

== Test de FGCOM avec FlightGear Simulator ==

Dans le chapitre précédent vous avez testé FGCOM en tant qu'application indépendante. Maintenant, nous allons voir si le '''FGFS''' (FlightGear Flight-Simulator) et FGCOM fonctionnent bien ensemble, y compris la touche PTT (PushToTalk, en général la barre d'espace) et les connections internes via les ports indiqués.
 
Pour ce test
<ol><li>démarrez FGFS avec l'avion et l'aéroport de votre choix
<li>démarrez FGCOM (habituellement, peu importe l'ordre - mais en cas d'ennui, démarrez dans cet ordre!)</li>

<li>dans la barre de menu de FGFS, click sur "Equipment" --> "Radio Settings"
* dans le champ "COM1" entrez la fréquence "910.00" ensuite click "Apply" (et "OK" si vous voulez fermer le Pop-up.)
'''Assurez-vous que FGFS est la fenêtre active''': Si parfois quelque chose ne fonctionne pas comme prévu, click avec la souris quelque part dans la fenêtre principale de FGFS (ce qui activera la fenêtre) et ensuite,, réessayer les dernières action(s)!!!

<li>si la fenêtre de commande de FGCom apparaît, mais ne répond pas à une fréquence COM installée:
: Cela signifie un problème Port/Interface entre FGCOM et FGFS.
:: Essayez d'imposer le port (habituellement prédéfini) en option. c.a.d ajoutez l'option “-p16661” à la commande de démarrage de FGCom
:: Vérifiez les options étendues de FGrun → Input/output “generic=socket..”: Le port doit être le même que pour FGCOM c.a.d. 16661 (si vous ne l'avez pas changé intentionnellement)
:Vous pouvez essayer de changer le port de l'interface en p.ex UPD 5004. Dans ce cas, vous devez vous devez examiner 3 endroits:
::ajoutez l'option “-p5004” à la commande de départ de FGCom
::changez aussi le chiffre dans FGrun (“Wizard”) → Advanced Options → Input/output en 5004 '''ou''' ajoutez l'option "--generic=socket,out,10,localhost,5004,udp,fgcom" à votre commande de démarrage de FGFS.
::et vous devez dire à votre pare-feu d'autoriser le port UDP 5004
:enfin, assurez-vous que ces 3 endroits contiennent les mêmes numéros de Port !!!

 
<li>Appuyez le PTT ''(normalement la barre d'espace (si vous avez assigné une autre touche pour PTT-utilisez la!))'' et parlez dans vote micro:
"vos paroles doivent être répétées en écho après un court délai ex: dites "one" - et vous remarquez que le "one" est répété après que vous ayez fini de le prononcer.
::'''si vous avez entendu''' cet écho:
::gardez le PTT appuyé pendant 3 secondes environ et surveillez une possible survenue de "drôles de bruits".
:::si cela se produit, voyez le chapitre [[#Adjust the Microphone and Speaker volumes|Régler le volume du micro et des haut-parleurs]]
::autrement, gardez sur votre COM1 la fréquence voulue--> continuez avec le prochain chapitre numéroté.
::'''si vous n'avez pas entendu''' l'écho en retour
:::testez votre PTT: Regardez les messages FGCOM dans la fenêtre FGCOM:
:::Quand vous appuyez sur PTT ils devraient passer entre ''[SPEAK] unmute mic'' suivi par ''[LISTEN] mute mic''
:::S'ils ne passaient pas, vous avez probablement affaire à un modèle d'avion pour lequel la barre d'espace a été assignée à une autre fonction:
:: Autrement, vérifiez le fichier “''YourPlane''-set.xml” dans votre FGFS/data/Aircraft/YourPlane directory: SI vous trouvez une ligne ''<key n="32">'' c'est que cet avion utilise intentionnellement la "touche 32" (Espace) pour quelquechose d'autre que PTT. Les appareils connus pour ça en Fev 2009 sont: an2, bluebird-base, ogel, OV10.., seafireIIc, spitfireIIa, ufo. Il peut en exister d'autres.

 

== Réglage du volume du Micro et des Haut-Parleurs ==

Enfin, nous allons régler le volume du micro et des haut-parleurs au niveau optimum, tant pour vous que pour vos partenaires joueurs.
 ''(Vous pouvez aussi faire cet essai avec le"f910-test" du chapitre 1, mais avec celui du du chapitre 2, il est plus réaliste!)''

# Démarrez FGFS et FGCOM comme décrit dans le chapitre précédent, COM1 doit être calée sur 910.00 et être activée.
# Parlez dans votre micro et vérifiez l'écho retardé. Si cela ne fonctionne pas comme prévu, reprenez les chapitres précédents.
# Pendant que vous parlez dans le micro, réglez votre haut-parleur de telle sorte que votre voix en écho soit compréhensible, mais pas plus basse.
# Maintenant, '''faites varier votre volume de micro''' de 0 à maxi. Quelque part, vous allez trouver un point où le volume d'écho de retour n'augmentera pas avec le changement du volume de micro. Laissez le volume juste un peu au dessous de ce point.
# Après le réglage du micro,, '''réglez le volume du haut-parleur''' au niveau qui vous convient.
# Vérifiez enfin l'ensemble des réglages en gardant PTT pressé pendant 10 secondes environ sans parler et/ou faire d'autres bruits dans le micro.
#* écouter des "drôles de bruits" survenant parfois (difficile à décrire: "unverified whoosh" et "air dans une conduite d'eau": Quoique vous entendiez, --> ce n'est pas bon!!!.
#* La plupart de ces artefacts sonores viennent d'un booster de micro. Essayez de garder ce booster au minimum,( ou mieux supprimez le complètement, il n'est pas vraiment nécssaire)
#* Le réglage un peu trop haut des haut-parleurs peut aussi produire des "drôles de bruits" - essayez de réduire le volume du haut-parleur i vous ne pouvez pas résoudre le problème en ajustant micro et/ou booster.
#* alors, vous avez fini de régler comme il est dit dans les rubriques précédentes.
# Maintenant, vous êtes prêts à communiquer avec les autres, calez votre COM1 sur la fréquence désirée et vos co-players vous féliciterons pour votre belle voix!
 

Au fait: Il ne faut pas attendre le prochain évenement MP pour mettre tout ça au point: la prochaine fois que vous volerez, consultez votre pilots-list (FGFS-menu-bar --> Network --> Pilot List) et essayez de contacter l'un de ces pilotes (ou pilotesses) en liste via MPchat (FGFS-menu-bar --> network --> Chat) - via ce chat vous pourrez alors convenir d'une fréquence commune. En général, tous ceux qui ont FGCOM opérationnel se feront un plaisir de vous aider au test! Vous pouvez jeter un œil dans [[MPMap|MPmap]] principalement pour localiser les gens - car il faut une distance inférieure à 100nm pour avoir une liaison via MPchat.

N.B. "on Air" dans MP garde le PTT appuyé seulement pendant l'instant de la conversation - et jamais plus de 20 sec environ. Passé ce temps, vous serez coupé de toute façon - mais avant cette coupure drastique, vous aurez pû donner à vos co-players une chance de répondre/dire quelquechose!
 

== Appendice ==

[[Category:FGCom]]

FGCOM for Windows

2015-01-01T18:38:59Z

F-JJTH:

{{obsolete|FGCom_3.0}}

{{historical
| type = article
| tense = is
| text = obsolete
| reason = The new version of FGCom is much more simple to use, a clean documentation is available at [[FGCom_3.0]]
| talk =
| date = 1 January 2015
| nocat =
}}

In this wiki you will find a more detailed description of how to install and test the '''FGcom''' feature of the FlightGear Flight-Simulator ('''FGFS''') on a Windows-Operating-System. This was tested on “Windows XP Professional SP2” and “Vista Home Premium SP2”.

Please consider this only as a supplementary to the FGCOM wiki-pages. Branch to those [[FGCom]] pages for all basic directions, setups, descriptions, etc.

''In the following the phrase “'''left''' mouse-click” (short: “click”) means moving the mouse-pointer over the target and push the” left mouse-button”. That usually is used to mark or activate or select something. Whenever you need the so called “context-menu” in order to select an option you are asked to click with the “'''right''' mouse-button”.'' 

== '''Download and Install FGCOM''' ==
<ol><li>Open the Internet-Download-Page with a left mouse-click onto: http://code.google.com/p/fgcomgui/downloads/list )
 ''(For details see the "Project Home" on http://code.google.com/p/fgcomgui/, see also the "wiki"-tab on top of it)''
 <li>Verify what target-directory is set for your "Downloads":
* For '''Mozilla-Firefox''' open "Preferences" '''now'''. You find the "Preferences" in the Menu-bar under "Edit" or "Tools" (Depending on version)
* For the '''Internet-Explorer''' the system will ask you where to download '''later''' during the downloading-process
 In both cases the default is (or has been at installation time) your "'''Desktop'''". We suggest to keep it there or select it via the "Browse" button.
* Whatever you decide to choose: '''Memorize that target-directory for later'''!!
 <li>Start the download with a left mouse-click onto the newest entry under "Filename"
<li>In the appearing PopUp select the “Save”-option (a ZIP-file cannot be executed directly)
<li>Depending of your system-settings there may appear a download confirmation like
 ''(Please consider the following pictures as examples - they may not represent the actual data you will see!!)''</li> 
::'''typical for the Mozilla Firefox'''
::[[File:FGcomW1.jpg|Download completeted]]
 
::'''typical for the Internet Explorer'''
::* first there appears a PopUp-window asking you where to store the file → remember: We suggested above to use "Desktop" (and memorize it!)
::* then there may or may not appear something like
::[[File:FGcomW2.jpg|Download completeted]]
::→ Just click onto the center button to open a directory with the ZIP-File in it
 <li>Extract the ZIP-File
* If you now have a Directory with the ZIP-Folder in it: Use that one in the following
* If not: Look for the ZIP-Folder on your desktop ''(or the directory you defined for downloading, see above)'' and use that one in the following
For both versions: Double clicking onto the '''ZIP-file''' will open an explorer with the '''unzipped folder''' in it
 <li>Move that folder onto your desktop: ''(remember: We are now placing the Directory onto the Desktop - not the ZIP-file with the ".zip"-extension!)''
* Locate your mouse-pointer over the folder-icon
* push the right-mouse-button and keep it pushed while moving the pointer to an empty spot on your desktop
* release the mouse-butten and select "copy"
 <li>close the windows used for the download
 <li>You should now have 2 additional icons on your desktop
* both with the same name
* but one having the ".zip" at the end of it.
 <li>You may delete that one with the "'''.zip'''" at the end (Mouse over it --> right mouse click --> select "delete")
</ol> 

== '''Useing the FGComGUI.exe''' ==
=== How to start ===
You may start the FGComGUI, either
* '''out of the Folder''' (the one '''without''' the ".zip" at the end, described above)
** by a mouse-double-click onto that folder and then a mouse-double-click onto the "FGComGUI.exe"
 
* '''or by creating a "Start-Icon"''' and using that for all future:
** mouse-double-click onto the folder ('''without''' that ".zip", see above) opens it
** move the mouse-pointer over "FGComGUI.exe"
** push the '''right'''-mouse-button and keep it pushed while moving the pointer onto an empty place on your desktop
** release the mouse-button and select "'''link'''"
** --> from now on you can start the FGComGUI always just by a mouse-double-click onto that newly created icon
 
[[File:FGComGUI-910-Test.jpg]]
* You can move the GUI somewhere else on your desktop (mouse over it, push and hold the left mouse-button, move to your desire, release button)
 
=== Testing ===
* With the down-arrow at the right side of the upper field you can select "Normal Mode" or "Test Mode" (the latter is usually called the "-f910 Test")
** '''the last 2 output-lines ("Call 0..") will only appear after you switched to the "FGComEcho Test Mode"''' (as long as FGFS is not started!)
 
* '''1. Without FGFS:''' Speak into your microphone and your words should be echoed back with a short delay. e.g. say "one" - and you should notice that the "one" is returned after you finished speaking it.
** '''in case of trouble''' continue with Standard Debugging at chapter: [[FGCOM Testing#Error: "TYPO" (mistyped command or option) or Network-problem:|Error: "TYPO" (mistyped command or option) or Network-problem:]]
 
* '''2. With FGFS:''' After you started the FGFS
** Stop the FGComGUI (Click onto the "Stop"-button)
** switch to the "Normal Mode" ''(remember: The down-arrow at the right side of the top input-field''
** click the "Start"-button.
** From then on the FGComGui follows the FGFS Radio-settings.
** Set the COM1-Radio to the test-frequency 910.00 MHz
** repeat testing as described under 1. -- '''but this time''' you have to use the PTT-button when speaking! (PTT = "PushToTalk", usually the space-bar on your Keyboard (key 32).
** If that does not work try first to use one of the very Standard airplanes (e.g. the c172), where you can be sure that the Space-bar is not reassigned e.g. for bombing or other unusual functions).
** If it still does not work see the troubleshooting under [[FGCOM Testing#Test the FGCOM together with the FlightGear Simulator|Test the FGCOM together with the FlightGear Simulator]]
 
* If after a lengthy period of "on-line-duties" the co-players tell you that the connection sound weak or disturbed try to stop and restart the FGComGUI.

 
=== Setting Options ===
* For a detailed description of all options click onto "Help" in the FGComGUI-Menu-bar
* Open the Options-Menu by clicking onto "Settings" --> "Configure..":
[[File:FGComGUI-910-Config.jpg]]
* also here you can select the "Normal" or the "Test" Mode (Click onto downward arrow at the right of the first input-field)
* set your "input" (Microphone) and "Output" (Loudspeaker) volumes as desired -- '''but be aware that these are only affecting the FGCOM behavior internally, for a basic setting of your system-audio-controls see the general setup "[[FGCOM Testing#Adjust the Microphone and Speaker volumes|Adjust the Microphone and Speaker volumes]]" in the wiki "FGCOM_Testing".
* select a different "Binary" if e.g. you are testing different versions of the FGCom
* same with the "Server": Define a different one only if you know there is another one available for you!
* change the "Port"=16661 only when advised so by the troubleshooting procedures 
 
Please continue with the chapters:
* [[FGCOM Testing#Test the FGCOM together with the FlightGear Simulator|Test the FGCOM together with the FlightGear Simulator]]
* [[FGCOM Testing#Adjust the Microphone and Speaker volumes|Adjust the Microphone and Speaker volumes]]

 
=== Creating an extra batch-file for unique environments ===
With the now available version of the FGComGUI the need for using an extra batch-file for special options and or environments has been drastically reduced. So it will not be described here any more in detail. If you still need to use it, you can do it by using the "fgcom.exe" within the above downloaded folder. You may also see the design-pages http://code.google.com/p/fgcomgui/.
 
== '''If after all you still have problems:''' ==
When reporting that problem, please directly state:
<ol><li>Your Operating-System (and if you know: your Sound-card)
</li> <li>Did you read and follow this FGCOM-WINDOWS-wiki?
</li> <li>Could you record and playback on your PC, without using FGFS and/or FGCOM?
</li> <li>Did both (with/without FGFS) -f910 tests work? If possible send a copy of the cmd-window when FGCOM has failed
</li> <li>Tell us: '''What''' happened '''When''' and '''How''' did it show up
</li></ol>
thanks in advance.

[[Category:FGCom]]

FGCOM Testing

2015-01-01T18:38:24Z

F-JJTH:

{{obsolete|FGCom_3.0}}

{{historical
| type = article
| tense = is
| text = obsolete
| reason = The new version of FGCom is much more simple to use, a clean documentation is available at [[FGCom_3.0]]
| talk =
| date = 1 January 2015
| nocat =
}}

This "FGCOM_Testing" is intended to support FGCOM-users in debugging their FGCOM-System directly after installation, but also for those who want to verify the basic functionality or want to readjust the audio-system. It covers the following 4 areas in more detail:
# Testing of the standalone FGCOM Installation
# Testing the FGCOM together with the FlightGear Simulator
# Adjusting the Microphone and Speaker volumes</ol>
# In the [[#Appendix|Appendix]] you will find supporting information

Of course the prerequisite for the following is that you have already installed the FGCOM (see the [[FGCOM|FGCOM-main-page]]) !
 

== '''The Initial test of the standalone FGCOM Installation --> the so called "-f910 Test"''' ==

Prior to executing the following [[Command line|command]] open a command-window and change into the directory, into which the FGCom was installed. This path will then be shown shown in the command window, followed by a "$"-sign. Enter the following "fgcom"-command with the required/wanted options:

<pre>fgcom -Sfgcom.flightgear.org -f910</pre>

<pre>
For MAC you may use:
/Applications/FlightGear.app/Contents/MacOS/fgcom -Sfgcom01.flightgear.org -f910
</pre>

: '''fgcom'''
:: the command ''(in case you installed by using the [[Scripted Compilation on Linux Debian/Ubuntu|download_and_compile.sh script]] for LINUX-Systems you have to replace the command "fgcom" with: "sh ./run_fgcom.sh". Then the complete command would be: "'''sh ./run_fgcom.sh -f910'''")''
: '''-Sfgcom.flightgear.org'''
:: one of two FGCOM-servers! Since Oct.2012 there are 2 FGCOM-servers available:
::# The original: '''fgcom.flightgear.org'''
::# A new one: '''fgcom01.flightgear.org'''
::Due to technicalities it is not possible to speak from 1 server to the other - so try one and change if you notice that your friends are using the other.

::So insert the server-address after a "-S" (watch: The "S" must be a capital!):
: '''-f910'''
:: the only available frequency for echo-tests
: '''optional'''
:: In case your audiosystem is rather weak, you may try the options:
:: ''-i and/or -o'': i=input(microphone) o=output(Speaker), both values between 0.0 and 1.0 (e.g.: -i0.9)

You do not need any Login-Passwords and/or User-Names !!!

For a detailed description of all available options see [[FGCOM#Commandline Parameters|Commandline Parameters]] - in the following we will only show the minimal required options:
<pre>That should give you the following return:
fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 163M
Using iaxclient library Version SVN 163M

Successfully parsed commandline options.
Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Call 0 accepted
Call 0 answered
</pre>

Speak into your microphone and your words should be echoed back with a short delay. e.g. say "one" - and you should notice that the "one" is returned '''after''' you finished speaking it.
 '''If that was OK'''
* type <nowiki>ctrl-C</nowiki> to exit this Quick-Test command-window
* and continue with the next chapter: [[#Test the FGCOM together with the FlightGear Simulator|Test the FGCOM together with the FlightGear Simulator]].
 '''In case of trouble''' check the following most probable errors:

 
=== Error: FGCOM does not start because of OpenAL-version: ===
If you see a message from the Operating-System similar to the following Windows message:
"The procedure entry point alcCaptureSamples could not be located in the dynamic link libary Open AL32.dll."
Then download and install the latest OpenAL software from: http://connect.creativelabs.com/openal/Downloads/Forms/AllItems.aspx
: for windows: '''alinst.zip'''
: for Linux: '''openal-soft-1.10.622'''
: for OSX: '''OpenALInstaller'''
''Be aware that the versions and also the names of the modules may change -- so please always check also the description of the module at the right side on that http-page!''

 
=== Error: Incorrect Home-Directory specified for FGCOM: ===

typical for '''Windows'''-Systems:
<pre>
C:\Users\localuser>cd \Programme\Fxx
The System cannot find the given path.

C:\Users\emmerich>fgcom.exe -Sfgcom.flightgear.org -f910
The command "fgcom.exe" is either mistyped or could not be found.
</pre>

typical for '''Linux'''-Systems:
<pre>
/home/emmerich/Desktop/Link to fgcom: line 1: cd: /home/emmerich/fgf: No such file or directory
sh: Can't open run_fgcom.sh
</pre>

* The system is right: I gave it (for testing) a wrong directory!
* You better correct yours prior to retrying!

=== Error: "TYPO" (mistyped command or option) or Network-problem: ===
<pre>
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

Successfully parsed command-line options.
Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
</pre>
after some time there may appear:

<pre>
''' Call 0 timed out.'''
'''Timeout for a non-existent session. Dropping'''

</pre>
or
<pre>
'''Call 0 accepted'''
'''Call 0 answered'''
'''The service is unavailable. Please wait until fgcom Version 3 is online. Thank you.'''
</pre>
most likely you may have

* defined a wrong Frequency to use or you may have forgotten to define one. You '''must define the option -f910'''
* forgotten a "-"sign in front of an option
* typed a small "-sfgcom..." instead the capital "-Sfgcom..."
* mistyped the Server-Name or defined a wrong FGCOM-Server
* or you may have created your own unique "typo" (lol).
* or it may indicate a '''Network-Problem''':
** Check your network by using some other application (e.g. your file browser to look up an usually not used http-address - if you use a recently used address the answer might be out of your locally saved copies - even so the network is not connected! (e.g. use "http://mainz.de/" to test)
* If you use a firewall (what you should - out of general safety reasons!) make sure the ports below are enabled for your PC.

<pre>
2005 UDP Vcp-Stream
4569 UDP FGCom VoIP, (Inter-Asterisk eXchange)
5000 UDP in/out Multiplayer (VPN Sftw.)
16661 UDP FGCom listening to FGFS, usually on localhost only
</pre>

=== Error: "Phone-book" and/or "positions" cannot be found and/or are corrupted: ===
<pre>
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

Successfully parsed commandline options.
'''Reading list of airports...Cannot open /home/emmerich/fgfs/install/fgcom/fgcom/positions.txt'''
'''fopen: No such file or directory'''
'''Stopping service.'''
(etc)
</pre>
* check the directory in which the FGCOM is installed for the files "phonebook.txt" and "positions.txt". These are normal text-files in which you can add missing information with a standard editor, for Windows you should use the "WordPad" (not the "Editor"). Replacing a complete "Windows" position.txt with a "Linux" one can lead to errors, although lines of both files may be exchanged/added.

=== Error: The Sound-Card is not fully compatible: ===
<pre>
./fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 223M
Using iaxclient library Version SVN 223M

'''AL lib: alsa.c:564: set access failed: Invalid argument'''
Successfully parsed commandline options.
Reading list of airports...done.
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Call 0 accepted
Call 0 answered
</pre>
* Continue checking/adjusting:
** If everything else works out OK forget this problem (but be aware: The Audio might not function perfectly!)
** otherwise check the Internet for new drivers for your sound-card or other fixes.

 

== Test the FGCOM together with the FlightGear Simulator ==

In the forgoing chapter you checked the FGCOM as a standalone application. Now we will test whether the '''FGFS''' (FlightGear Flight-Simulator) itself and the FGCOM work together, inclusive the PTT-button (PushToTalk, usually the space-bar) and the internal connections via the assigned ports.
 
For this test
<ol><li>start the FGFS with any plane at any airport you like
<li>start the FGCOM (usually it does not matter which one starts first - but in case of trouble you should try to start in this sequence!)</li>

<li>click in the FGFS menu-bar onto "Equipment" --> "Radio Settings"
* into the field "COM1" enter the frequency "910.00" then click "Apply" (and "OK" if you want to close the Pop-up.)
* '''Ensure the FGFS is the active window''': if something does not work out as expected click with the mouse somewhere into the Main-FGFS-window (that will activate the window) and then retry the last action(s)!!!

<li>if the FGCom Command-window initiates, but does not respond to any COMM-Frequency setting:
: This indicates a pure Port/Interface problem between the FGCOM and the FGFS.
:: Try to enforce (the usually predefined) port as option. i.e. add the option “-p16661” to the FGCom Start-Command
:: check the FGrun extended Options → Input/output “generic=socket..”: The port there must be the same as for the FGCom, i.e. 16661 (if it was not intentionally changed by you)
:You may try to change the interface-port to e.g. UPD 5004. In this case you have to watch 3 places:
::add the option “-p5004” to the FGCom start-command
::also change the value in the FGrun (“Wizard”) → Advanced Options → Input/output to 5004 '''or''' add the option "--generic=socket,out,10,localhost,5004,udp,fgcom" to your FGFS start-command.
::and you may have to tell your Firewall to allow port UDP 5004
:anyhow make sure all these 3 places contain the same Port-number !!!

 
<li>Push the PTT ''(normally the Space-Bar (if you reassigned the PTT to another key - use that one!))'' and speak into your microphone:
"your words should be echoed back with a short delay. e.g. say "one" - and you should notice that the "one" is returned after you finished speaking it.
::'''if you heard''' that echo:
::keeping the PTT pressed for about 3 sec and watch for a possible start of "funny noises".
:::if those occur continue with chapter [[#Adjust the Microphone and Speaker volumes|Adjust the Microphone and Speaker volumes]]
:::otherwise switch your COM1 back to the frequency wanted --> continue with the next numbered item.
::'''if you did not hear''' the echoed return
:::Test your PTT: Watch the FGCOM messages in the FGCOM-Window:
:::When pushing the PTT they should switch between ''[SPEAK] unmute mic'' followed by ''[LISTEN] mute mic''
:::If they did not switch you probably use an airplane model that has reassigned the Space-bar to another function:
:: Otherwise check the “''YourPlane''-set.xml” file in your FGFS/data/Aircraft/YourPlane directory: If you find a line ''<key n="32">'' then this plane is intentionally using "key 32" (Space) for something other than the PTT. Known planes that do that as of Feb. 2009 are: an2, bluebird-base, ogel, OV10.., seafireIIc, spitfireIIa, ufo. There could be others.

 

== Adjust the Microphone and Speaker volumes ==

Finally we will adjust the Microphone and Loudspeaker volumes to an optimum, as well for yourself as also for your fellow players.
 ''(You could perform this test also with the "f910-test" in chapter 1, but with the test-setup in chapter 2 it becomes more realistic!)''

# Start your FGFS and FGCOM as described in the forgoing chapter(s), the COM1 must be switched to 910.00 and be the active one.
# Talk into your Microphone and verify the delayed feedback. If this does not function as described before, repeat the forgoing chapters.
# While talking into the microphone adjust your loudspeaker so that your echoed voice is understandable, but not any louder than required.
# Now '''adjust your microphone''' volume from 0 to full. Somewhere in between you will find a spot at which the returned echo-volume will not increase according to the microphone-volume changes. Leave the volume just a little below that point.
# After the microphone is set, '''adjust the loudspeaker''' volume to a level you prefer.
# Finally verify both settings by keeping the PTT pressed for about 10 seconds without talking and/or feeding any other sounds into the microphone.
#* listen for "funny noises" building up over time (hard to describe: some "unverified whoosh" and maybe additional even some sound like "air in a water-pipe" - actually: Whenever you hear anything --> it is no good!!!.
#* Mostly these "build up sounds with time" are due to an active microphone booster. Try to keep that booster to an absolute minimum (even better try to switch it off completely if not really needed!) while instead increasing the microphone volume
#* but also a rather high adjusted speaker-volume may cause such "funny noises" - try reducing the loudspeaker volume if you cannot solve the problem by adjusting the microphone and/or booster.
#* then you might readjust as described in the forgoing items.
# Now you are ready to talk to others, e.g. set your COM1 to the desired frequency and let your co-players praise you for that "absolute brilliant voice you have"!
 

By the way: You do not have to wait for the next MP-event to check this real life: When flying next time, look into your pilots-list (FGFS-menu-bar --> Network --> Pilot List) and try to contact one of those pilots (or pilotesses) listed there via MPchat (FGFS-menu-bar --> network --> Chat) - via this chat you then can define what frequency to use - to be sure you tune to the same. In general all of those having FGCOM operational will gladly help you testing! You may have to look in [[MPMap|MPmap]] first to find where there are some people - because you need a distance less than 100 nm to get into contact via MPchat.

PLEASE: While "on Air" in MP keep the PTT pressed only while actually talking - and never longer than about 20 sec. After some time you will be timed out anyhow - but even before that drastic cutoff you might give your co-players a chance to reply/say something!
 

== Appendix ==

=== Tips and Tricks ===
==== Typical Problems ====
<ol><li>Microphone not plugged or Mute-Key activated: It sounds stupid – but most technical problems are due to such “cannot bee”s – please: Always spend the 2 sec. to check this first! Also some Microphones do have an own "Mute-Key", which sometimes is not obviously to see - check your handbook if your Mic has such a switch.
</li> <li>Plug/Jack connections are often the cause for trouble: Try to re-seat your plugs and (if possible) try to use another jack (after cleaning the plug!).
</li> <li>Multiple Microphones and/or Loudspeakers plugged to your PC: Be aware that most PC's do have Jack-mechanisms that prevent more than one input and/or output per PC. Try using only one (at best the major one - mostly at the back of the PC)
</li> <li>If you changed your Mic/Loudspeaker setup or did plug them into anther jack, it is advisable to restart your PC – just to make sure the system knows what you did! (For Windows-Systems this is usually not necessary - but: It cannot hurt to reassure!)
* If you use USB-headsets you might first try to get FGCOM running with standard Input/output devices – and go back to USB after that. If nothing else it helps to narrow down into the trouble-area!
</li> <li>Check that none of your Sound-system Inputs/Outputs are set to “Mute”:
* For basic systems you might use a '''right''' mouse-click onto the loudspeaker-symbol in the upper or lower position of you screen.
** For WIndows-Systems: If that symbol is not there:
*** '''for Vista''': Left mouse-click onto “Start”, type “SndVol.exe” into the line just above the Start-button
*** '''for XP:''' Left mouse-click onto “Start” then on “Run”, type “SndVol32.exe” into the appearing input-field.
* For some “highly sophisticated (and expensive)” sound-cards you might need to use their unique descriptions.
* FGCOM does not require a “better” sound-card like e.g. for Music or so – it is all Telephone/TCP-IP talking only – (except some people I know like to play country-music while pushing the PTT – that sounds nice - but still is not really high fidelity!)
</li> <li>Always make sure that you can record and playback something you talk into the microphone with your basic system tools, completely independent of the FlightGear and/or the “OpenAL”. (See your handbooks for testing your unique system and/or the chapter [[#Where to find the volume controls|Where to find the volume controls]])
</li> <li>If the connection is noisy or poor quality:
* First retest your sound-setup as described [[#Adjust the Microphone and Speaker volumes|above]]
* try routing your Mic/Speaker cables away from electro-smog (Fans, AC/DC modules, motors, lamps, etc.)
* even placing your sound-card into another plug-position may help
* a (digital) USB-headset may help avoiding noise and feedback problems
* if stereomix is enabled on your sound-card - try to disable it
</li> <li>Most PC's are set up that you need to keep your PTT (PushToTalk) button pushed as long as you talk. But there are also sound-cards which open for talk with the first push/release and close it with the second push/release. Test your system how it works (may be while trying to record something or while testing according to the [[Adjust the Microphone and Speaker volumes|above]]).
</li> <li>If the FGFS sound-volume does not match your FGCOM-volume:
* After starting the FGFS click onto “File” in the FGFS menu-bar, then onto “Sound Configuration”: Adjust the upper slide-control to a proper volume. Be aware that this setting will get lost when you exit via “X” - always exit via “File” → “Exit/Quit”.
* To the opposite you may adjust the volume of your FGCOM by changing the “-o” and/or “-i” options to values between 0 and 1 (see the [[#The Initial test of the standalone FGCOM Installation --> the so called "-f910 Test"|FGOM command at the beginning of this wiki-page]]).
</li> <li>If you believe you did everything right - but still you cannot establish a connection: Use MPchat to ask which FGCOM-server the other('s) are using! Since Oct.2012 there are 2 FGCOM-servers available:
# The original: '''fgcom.flightgear.org'''
# A new one: '''fgcom01.flightgear.org'''
Due to technicalities it is not possible to speak from 1 server to the other - so try one and change if you notice that your friends are using the other.
</li></ol>
Try to keep in mind: FGCOM is proven to work! So if there are problems look also for surrounding PC-features like unique hardware, software, etc.
 

==== High Quality Sound-Cards ====
Especially “high quality” sound-cards may get you into trouble, because e.g.:
* they may monitor how long the microphone was not used and switch it off after some timespan (without you noticing it)
* during reboot or restart they may initiate with values out of a special profile instead of reusing the “last used” values
* or they may set some slide controls to “0” (especially microphone sliders)
* some do switch the microphone only after pushing '''and''' releasing the space-bar – while we want to change the microphone-status only while the space-bar is pushed down! (This may not affect a PTT asigned to a joystick) 
So know your standard settings and check if they have changed (without your written permission!)
 
==== Linux ALSA Sound ====
(Reference [[Linux software audio mixing with FlightGear]]) 

Check your Home-directory (“~/” or $HOME) for a file "'''.alsoftrc'''"
(Remember that the “show hidden files” must be enabled!)

===== If using Creative Labs' OpenAL library (or older OpenAL version) =====
Check if you are using the old Creative Labs OpenAL library (or old version) which uses the ".openalrc" configuration file. If so, you can put something like this within ".openalrc":

$HOME/.openalrc
<pre>
(define devices '(alsa))
(define alsa-out-device "plug:dmix")
(device alsa-in-device "plug:dsnoop")
</pre>

===== If using OpenAL Soft (or newer OpenAL version) =====
It is more likely users of more recent Linux distributions are using this newer OpenAL Soft package, instead of the previously mentioned older Create Labs' OpenAL. (Hence, the likely rational for renaming the default configuration file to something other than the more common previous naming format.)

Copy either the be /etc/openal/alsoft.conf, /usr/share/doc/openal-1.15.1-r2/alsoftrc.sample.bz2, or create a new $HOME/.alsoftrc file and insert the following:

<pre><nowiki>
format = AL_FORMAT_STEREO16
cf_level = 1
drivers = alsa
[alsa]
device = plug:dmix
capture = plug:dsnoop
</nowiki></pre>

[NOTE: format is now "sample-type = uint16", and cf_level would appear not needed for typical users, or only desired for headphone users.]

The system wide OpenAL-soft configuration file may be /etc/openal/alsoft.conf or similar. It usually contains comments describing all possible configuration options.
 

===== Linux ALSA Audiophiles avoiding Dmix =====
For audiophiles using Linux ALSA and with their custom $HOME/.asoundrc file preventing DMix usage, make sure you have both specified "device = plug:dmix" as well as "capture = plug:dsnoop". Per ALSA's page, "dsnoop is the equivalent of the dmix plugin, but for recording sound." Without specifying using dsnoop for the capture device alongside your $HOME/.asoundrc file preventing DMix usage, you will likely only get silence played back when usage FGCom. FGCom is not working at this point, as the sound device is likely still locked by your $HOME/.asoundrc file and only recording silence or playing back silence during the echo test!

===== Using ALSA Custom "plug:" Filters =====
The OpenAL Soft (or the newer version of OpenAL) $HOME/.alsoftrc file also accepts using other $HOME/.asoundrc "plug:" incanatations, such as sections containing Dmix - alsa.opensrc.org's "pcm.dmixs51" customization for using DMix with 5.1 Surround Sound, and called as:

<pre>$ aplay -D "plug:dmixs51" Some_PCM_WAV_File.wav </pre>

$HOME/.alsoftrc
<pre>
"device = plug:dmixs51"
</pre>

Just remember to also uncomment layout_surround51, and note the likely fact FlightGear is still only using Stereo sound (or two channel audio) and is only set here for an example!

==== USB-Headsets-Problems with Linux (Ubuntu) ====
The following is based/verified on Ubuntu, but should be similar on other distributions:
* If Recording is ok '''and''' the f910-Test looks alright in the window, '''but''' there is no delayed response:
** type "cat /proc/asound/modules" into the command window, e.g.:
$ cat /proc/asound/modules
0 snd_usb_audio
1 snd_hda_intel
** If that displays multiple devices (as shown in the above list, which is the result '''after''' doing the following!), then the USB-Headset should be in the "0" position. If this is not the case, notice the name of your USB-device and edit it. e.g.:
"sudo gedit /etc/modprobe.d/alsa-base.conf"
** add as last line into that file, e.g.:
options snd_usb_audio index=0
 
==== Festival ====
* If you use '''Festival''' (the Text/Speech AddOn)
** and
*** it works OK when running alone
*** but runs int error "can't open /dev/dsp" when running with FGFS (and/or other applications)
** then add a TextFile ".festivalrc" into your home-directory, containing:
(Parameter.set 'Audio_Command "aplay -q -c 1 -t raw -f s16 -r $SR $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)
</ol> 
=== Where to find the volume controls ===
Please be aware that FGCOM is used on many very different PC's, Notebooks, etc. under very different Operating-Systems and with very different Sound-Cards. So the following basic concepts may not fit your actual system 100%. In addition you may have to check your actual System and/or unique Sound-Card manuals!
<ol>

'''<li>Define the audio-devices to use:'''
{| border="1"
|+
|width=300 align="center"|'''for Linux:'''
|width=300 align="center"|'''for Windows:'''
|width=300 align="center"|'''for MAC:'''
|-
|width=300|Enter [[Command line|command]]: ''gnome-sound-properties''
[[File:FGCOM-U-Prefs.jpg|thumb|center|250px|test devices]]
For each task you can open a selection-menu (on the right the downward arrow) in order to select the wanted device. I suggest to first try setting all to "Autodetect". Then click onto the green "Test"-button. If you need to make changes, reboot the PC after each change!
|width=300| Click right onto the audio-icon → Preferences → Audio-tab:
[[File:FGCOM-W-Audio.jpg|thumb|center|250px|set devices]]
See the two Tabs (in the picture) '''Audio''' and '''Stimme''' (voice), you need to change in both!
|width=300|Open with Menu --> System-preferences:
[[File:FGCOM-OVol.jpg|thumb|center|250px|set devices]]
Switch between "Output" and "Input" and select the wanted device('s) in the field "Chose a device...".
|}
If you did change these device-settings, it is a good idea to reboot the PC and retest the settings prior to continue.
 

'''<li>Adjust volumes and switch boosters''' (for the first loudspeaker-adjustments you should switch off the Mic.!)
{| border="1"
|-
|width=300|Click right on Audio-Icon → Open Vol. Ctrl:
[[File:FGCOM-UVolCtrl.jpg|thumb|center|250px|Volume Control]]
The amount of the slider-controls vary depending on the capabilities of the sound-card or the usage of USB-headsets.

The “booster” is available under “Switches” (you may have to activate it first under "Preferences").
|width=300|Click right on the Audio-Icon → Volume-Ctrl. (or type command: sndvol32)
[[File:FGCOM-W-VolCtrl.jpg|thumb|center|250px|set devices]]
In this example the card overrides the std. Microsoft “Mic.” with “Rear Pink In”. Be aware of such changes caused by usually “high expense” devices!
The “booster” is available under options.
|width=300|Use the above shown window to adjust.
|}
 

'''<li>Verify the basic Mic/Loudspeaker functionality:'''
 Use the volume-control-panels to enable the microphone for this test. Then:
{| border="1"
|-
|width=300|Open the recorder with the [[Command line|command]]: ''gnome-sound-recorder''
[[File:FGCOM-U-sndctrl.jpg|thumb|center|250px|Recording-test]]
* Record
* Stop
* Play
|width|Open the Recorder with [[Command line|command]]: ''sndrec32''
[[File:FGCOM-W-sndrec.jpg|thumb|center|250px|Recording-test]]
* Start recording (click red point)
* talk some words into the mic
* stop (rectangel)
* spool back ( < < )
* listen (>)
|width=300|There is no basic recording program available with OSX.
|}

[[Category:FGCom]]

[[de:FGCOM Testing]]
[[fr:FGCOM Testing]]

Fr/FGCom

2015-01-01T18:37:27Z

F-JJTH:

{{obsolete|FGCom_3.0}}

{{historical
| type = article
| tense = is
| text = obsolete
| reason = The new version of FGCom is much more simple to use, a clean documentation is available at [[FGCom_3.0]]
| talk =
| date = 1 January 2015
| nocat =
}}

{{Infobox Software
| title = FGCom
| logo =
| image =
| alt =
| developedby = Holger Wirtz, Martin Spott, Csaba Halasz
| initialrelease =
| latestrelease =
| writtenin =
| os =
| platform =
| developmentstatus = Actif (2007-)
| type =
| license = [[GNU General Public License]]
| website = http://sourceforge.net/projects/fgcom/
}}
'''FGCom''' est un logiciel complémentaire à [[FlightGear]]. Avec FGCom (et son infrastructure), FlightGear dispose à présent d'un système de communication vocal en temps réel qui enrichit ses possibilités, et tout particulièrement pour les fonctions multijoueurs ([[Howto: Multiplayer|multiplayer]]), comme :

* voler en groupe, voir [http://forum.flightgear.org/viewforum.php?f=10 le forum des évènements multijoueurs] ;
** inviter des amis à faire une visite guidée de votre zone préférée ou réaliser des “Fly In's” ;
** faire des entraînements militaires comme les [[Howto: Air-Air Refueling|“ravitaillements en vol”]], des “Dog fights”, des “vols d'escorte ”, etc ;
* offrir des services supplémentaires à un aéroport, comme [[Air traffic control|le contrôle aérien]], [[Vehicules|les chasse-neige et pushbacks]], des [[FlightGear Race|courses de vol]], etc ;
* avoir un [[Dual control|entraînement au vol en temps réel]] (par exemple avec un pilote à Hongkong, un moniteur à Sydney), faire du [[Soaring|planeur]], demander de l'aide en ligne pendant le vol ou bien parler avec quelqu'un des caractéristiques d'un avion ;
* ou simplement s'asseoir dans un cockpit en Allemagne pendant que l'on visite San Francisco dans un [[Cessna C172|C172]], discuter de vive voix avec un Texan dans un avion ([[Lockheed Constellation|le Super Constellation]]) dont je rêvais quand j'étais gosse et en même temps, obtenir des informations d'un gars de Nouvelle-Zélande (ça doit être une île magnifique mais est-elle réellement habitée ? Il a dit "Oui" !!) ;
* et plus encore !

Vous pouvez même l'utiliser dans les modèles d'avions sans radio. Utilisez simplement le [[menu]] standard FlightGear (<tt>Equipement > Paramètres radio</tt>).

Dans le futur, FGCom s'améliorera encore et on aura sûrement la possibilité d'avoir une fonction de “parole vers texte” afin d'intégrer les routines des textes automatiques du contrôle aérien dans FlightGear.

== Installation du Logiciel ==
=== Conditions ===
==== Matériels requis ====
Si vous êtes satisfaits des temps de réponse et d'utilisation de votre installation actuelle de FlightGear, l'installation de FGCom n'y changera rien. Si votre installation est un peu juste, vous pourriez observer des délais lorsque de nombreux avions sont chargés dans les aéroports très fréquentés. Vous pouvez surveiller/vérifier ainsi de tels "short-time overload" dans la fenêtre de commande de FlightGear.

Pour plus de détails, voir [http://www.flightgear.org/hardwarereq.html les conditions requises pour le matériel et les pilotes].

Bien sûr, il vous faut aussi disposer d'une connexion Internet pour cette communication vocale temps-réel et mondiale.

==== Conditions requises pour le logiciel ====
{| border="1"
|align="center" width="90px" |'''FlightGear''' ||L'installation de base du simulateur de vol [[FlightGear]] . Il doit être installé avant FGCom ''(sauf avec la version Linux "complète Git" qui peut installer en même temps FGCom et FlightGear)''.
|-
|align="center" |'''Multijoueurs'''||[[Howto: Multiplayer|“Le mode multijoueurs”]] n'est pas un programme installable mais une fonction intégrée à FGFS. Comme son nom l'indique, elle permet la communication entre plusieurs joueurs via une fonction de clavardage (par clavier pour l'instant - dorénavant également avec cette interface vocale : FGCom).
|}

==== Bon à avoir ====
{| border="1" cellpadding="10"
|align="center" width="90px" | '''FGrun'''|| Ce système de contrôle du lancement de FlightGear ([[FlightGear Launch Control]], aussi connu sous le nom de FG Wizard), est un "frontal graphique" de démarrage de FGFS. Il facilite le démarrage de FGFS avec toutes les options possibles. Dans quelques distributions récentes, il fait déjà partie du paquetage de base de FGFS.

|-
|align="center" |'''MPMap'''||[[MPMap]] est une application 100% web basée sur Google Maps, ne nécessitant aucune installation, sauf un navigateur Web. Avec MPMap, vous pouvez voir tous les avions des utilisateurs du monde entier, sur une carte routière, sur des images satellites ou les deux à la fois. On y trouve la plupart des aéroports, les aides à la navigation et les informations météo. On peut donc s'en servir pour planifier un vol sans avoir FGFS démarré ni même installé. Mais il nécessite une connexion permanente à Internet - ainsi, vous pouvez faire votre préparation de vol partout où il y a un PC connecté à Internet.
|-
|align="center" |'''SkyVector'''||[http://skyvector.com/ SkyVector] est une application autonome utilisant un navigateur Internet. C'est un fantastique outil de préparation de vol, comparable sous certains aspects à "MPMap" - mais utilisant une vraie carte aéronautique ("Par sections"). Vous pouvez y planifier vos routes graphiquement, voir l'icône "Help Video" dans la barre de menus supérieure.
Mais il n'est pas relié directement à FGFS, MPMap ou au mode multijoueurs - et ne couvre que le territoire américain.
|-
|align="center" |'''Atlas'''||[[Atlas]] affiche la position actuelle de votre aéronef dans une carte du paysage en même temps que les informations de navigation. Il tire ses données directement des bases de données de FGFS installées. Vous n'avez donc pas besoin de connexion à Internet.
|-
|align="center" |'''Festival'''||[http://www.flightgear.org/Docs/getstart/getstartch5.html#x10-1080005.7 Festival] est un système TTS (Text To Speech) qui peut convertir tout texte écrit et affiché dans FGFS (ATC, clavardage, etc.) en son pour le diffuser dans vos haut-parleurs.
|}

=== Installation de FGCom ===
==== Installer sur Linux ====
Pour les systèmes Linux, trois moyens pour installer :

# '''Télécharger depuis le “Distributor” (Debian, Ubuntu, Red Hat, Suse, etc.).'''
#* '''Avantage:''' C'est le moyen le plus facile qui assure maintenance et services pour ce paquet, ainsi que toutes les aides automatiques dans un laps de temps raisonnable.
#* '''Inconvénient:''' La disponibilité de ces paquets étant récente, la plupart des Distributors ne couvre pas toutes les versions FGFS. A notre connaissance, aucun Distributor n'avait de paquet FGCom disponible en Mars 2009.
#* '''Installation:''' Suivez la procédure habituelle de votre distributeur sur la façon d'installer des paquets supplémentaires.
# '''Installer un “Git complet”'''
#* '''Avantage:''' C'est le moyen le plus facile, et en une seule étape, tous les modules pré-requis sont installés (FGFS, FGrun, FGcom, PLIB, OSG, Simgear, AT). Tout peut être ajouté ou enlevé sans déranger quoique ce soit (Libraries, Menus, Structures, etc.). Il a été testé sur plusieurs systèmes Ubuntu et Debian.
#* '''Inconvénient:''' Pas de maintenance automatique disponible. La manipulation est un peu différente de celle, guidée, du menu standard.
#* '''Installation:''' [[Scripted Compilation on Linux Debian/Ubuntu]]
# '''Compilation locale:'''
#* '''Avantage:''' Après une installation réussie, c'est intégré dans le système comme un paquet du distributeur.
#* '''Inconvénient:''' Pas de maintenance automatique disponible. Donc l'utilisateur doit avoir quelques connaissances de base de son système et de ses possibilités.
#* '''Installation:''' [http://code.google.com/p/fgcomgui/wiki/Linux_Installation instructions]

La suite avec [[FGCOM Testing]].

==== Installer sur Mac ====

'''MacFlightGear 1.9.1/2.6.0''' 
Vous pouvez télécharger l'application "MacFlightGear"- sur [http://www.flightgear.org/Downloads/binary.shtml#mac FlightGear download-center]. La version actuelle 2.6.0 contient FGCom et marche pour OSX >= 10.5. (avec les OSX versions < 10.5 vous terminerez avec un message générique "bus error").

==== Installer sur Windows ====
Veuillez utiliser la decription d'installation disponible sur [[FGCOM for Windows]].

=== Essai ===
Pendant l'essai, vous testerez/ajusterez:
# les fonctions de base FGCom sans FlightGear
# FGCom en même temps que FlightGear
# le système micro-haut-parleurs

Pour ces tests veuillez vous référer à [[FGCOM Testing]].

=== Test de fonctionnement & briefing de l'utilisateur ===
La pratique montre que la coordination entre FGCom et FlightGear se fait mieux si FlightGear est démarré en premier. Ainsi, nous commencerons le test avec un environnement de vol installé.

==== Démarrer FlightGear ====
Nous suggérons [[FGRun]] pour définir les installations demandées et/ou proposées, afin d'éviter des erreurs typo. Si vous gardez la “Show command line” active (comparez l'item 3 suivant), vous aurez aussi l'inscription correcte pour toute les options de commande(au cas ou vous voudriez plus tard partir de la ligne de commande et/ou du script). A l'avenir, vous n'aurez qu'à désigner ces commandes qui actionnent FGCom:

Si vous n'avez pas d'icone disponible pour démarrer FGrun, alors, démarrez FlightGear manuallement:

# Ouvrez une [[Command line|fenêtre de commande]]
# Allez dans le répertoire dans lequel FGFS a été installé
# Exécutez les commandes suivantes, ou quelque chose de similaire
{|
! style="background:#efefef" | Linux
|fgrun
|-
! style="background:#efefef" | Linux Git:
|cd ~/fgfs sh ./run_fgrun.sh
|-
! style="background:#efefef" | Windows
|C: cd 'C:\Program Files\Flightgear\win32' fgrun.exe
|}

Attendez la fenêtre du programme pour commencer, et ensuite précisez:

# Commencez par '''choisir un avion'''. Pour ce premier essai, nous suggérons le [[Cessna C172]]P, ainsi, nous nous comprendrons par la suite. Considérez aussi que certains dessineurs d' avions réattribuant des touches de clavier (p.ex. la barre d'espace”), vous pouvez ne pas avoir par exemple la touche PTT (“Push To Talk”- Appuyez pour parler-) disponible. Voir[[FGCOM#Trucs et Astuces]]. → Click "Next".
# Comme '''lieu de départ,''' précisez [[airport]] KPAO (Palo Alto) piste 13, ainsi, nous verrons chacun les mêmes messages dans les rapports . Une autre raison est que KPAO a les scènes de base par défaut, et donc est valable pour tout le monde. → Click "suivant".[[File:FGrun_base.jpg|thumb|Basic & multiplayer options]]
# Précisez '''Multiplayer options:''' (voir [[Howto: Multiplayer]] pour les détails).
#* “AI models” doit être activé pour voir tout le trafic
#* “Multiplayer” doit être activé
#*tapez “'''mpserverXX.flightgear.org'''” dans le champ “Hostname:”, remplacez “XX” avec le numéro de serveur le plus proche de chez vous- selectionnez le dans http://pigeond.net/flightgear/mpstatus/. En fait, peu importe le serveur que vous choisissez, prenez celui qui vous donne les meilleurs temps de réponse.
#* Insérez votre “Callsign:” (max. 7 caractères)
#* précisez les ports “in” et “out” avec le standard “5000”
#* Avec "Load/Save as" vous pouvez vous faire une liste de données pour différents aéroports. → Click "Advanced".[[File:FGrun_IP.jpg|thumb|Advanced: Initial Position]]
# Dans “'''Advanced Options'''” enregistrez les sections suivantes (click/sélectionnez les dans la colonne de G):
#* General: Ces installations étaient définies avant. Sélectionnez “Control”, si nécessaire sélectionnez votre mode d'entrée (Joystick, Clavier, ou Souris).
#* Features: “AI Traffic” sera déja activé
#* Position initiale: Vous pouvez choisir ici une position “starting/parking” en dehors de la piste. Vous éviterez ainsi de partir avant d'autres joueurs, car la plupart d'entre eux se placent juste au bout de la piste. Vous pouvez vérifier les positions dans MPMap: ''(voir le prochain item)''
#** ''Attention que les données définies ici chevauchent celles déja pré-définies (p.ex. un aéroport et une piste). Ainsi '''n'oubliez pas''' de changer/effacer les positions si par hasard vous vouliez partir d'un autre aéroport'' Naturellement, vous pouvez save/reload les installations pour différents aéroports, voir "Load/save as" sur la fenêtre principale.[[File:MPmap.jpg|thumb|[[MPMap]]]]
# Ouvrez '''[http://mpmap01.flightgear.org MPMap]'''
#* si le panneau de contrôle n'est pas visible, cliquez dans "FGMap | mpserver01:5000 | pilots: 7”
#* click sur “nav”
#* décochez toutes les options sauf “apt code”
#* tapez “KPAO” dans “Navaids lookup”
#* cliquez ENTER ou click sur le symbole "lunettes"
#* click sur la ligne “Airport KPAO Palo Alto Arpt Of Santa Clara Co”
#* maintenant, vous pouvez/devez prendre en charge votre plan de vol en cliquant sur le biseau dans le haut du coin droit après le nom de l'aéroport et analyser toutes les données "info", "metar", "atc", et "liens"
#* ensuite zoomer sur l' airport
#* mettez la souris sur le “Parking lot” désiré, et lisez cette position en haut du coin droit de l'écran
#* tapez ces coordonnées longitude/latitude dans le champ au dessous ainsi que le cap voulu de l'avion pendant le parking[[File:FGrun_net.jpg|thumb|Advanced: Network]]
# '''Réseau:''' Vous avez déja défini ces données dans la page de base, mais au cas ou vous auriez des problèmes de réseau (à cause de l'encombrement), vous pouvez entrer ici votre adresse IP actuelle.
#* ATTENTION: Lorsque vous sauvez ces données, et que vous les rechargez encore, FGRun pourrait remplacer le N° IP donné par le nom du PC . A partir de mars 2009 vous devez remplacer ça par le N° IP. N'agissez ainsi que si vous êtes obligés- D'abord essayez en n'ajoutant rien entre les ",,". Gardez "in,10,,5000".
#* Si vous avez besoin de '''donner la seule IP-Address''', ouvrez une [[Command line|fenêtre de commande]] et tapez

{|
! style="background:#efefef" | OS
! style="background:#efefef" |taper
! style="background:#efefef" | cap.
! style="background:#efefef" | valeurs renvoyées
|-
! style="background:#efefef" | Linux
|ifconfig
|eth0
|Link encap:Ethernet HWaddr 00:1d:92:80:a6:ab inet addr:'''192.168.178.23''' Bcast:192.168.178.255 Mask:255.255.255.0
|-
! style="background:#efefef" | Windows
|ipconfig /all
|et
Adresse physique. . . . . . : 00-16-E6-40-AB-BF
 DHCP activé. . . . . . . . . . : oui
 Autoconfiguration activé . . . : oui
 IP-Adresse. . . . . . . . . . . . : '''192.168.178.20'''
 Subnetzmaske. . . . . . . . . . . : 255.255.255.0
 IP-Adresse. . . . . . . . . . . . : fe80::216:e6ff:fe40:abbf%4
|}
#* '''192.168.178.23''' (or '''20''') est le nombre que vous aurez à entrer entre deux virgules. Attention vérifiez deux fois que vous avez tapé correctement “.” et “,”!![[File:FGrun_IO.jpg|thumb|Avancé: Entrée/Sortie]]
# '''Input/Output:'''
#* Vous avez besoin d'une ligne "générique", comme montré, parce qu'elle définit l'interface entre FlightGear et FGCom'''.
#** Pour entrer une nouvelle ligne: Commencez par sélectionner “generic” dans le champ “Protocol”. Ensuite, appuyez sur “New” et précisez le reste comme montré.
#** Éditer une ligne existante: cliquez celle qui existe, puis changez comme demandé.
#** Éffacer une ligne existante: Cliquez la ligne à effacer, puis tapez effacer "Delete"
# '''Avionique:''' précisons:
{|
! style="background:#efefef" | Nav1:
| 114.10
| San Jose VOR
|-
! style="background:#efefef" | Nav2:
| 115.80
| SF VOR
|-
! style="background:#efefef" | ADF:
| 379
| Brijj, balise à SF
|}
#* Et activez DME dans Nav1
#* Il ny a pas de champ pour entrer COM-radios, donc rappelez-vous en pour les entrer manuellement plus tard:
{|
! style="background:#efefef" | Com1
| 118.60
| Paolo Alto
|-
! style="background:#efefef" | Com2
| 120.50
| San Francisco
|}

# '''Propriétés:'''
#* Ici, vous pouvez mettre n'importe quelle spécifications pour FGFS. Voir p.ex e.g.: <tt>File > Browse Internal Properties</tt> dans le [[menu]]FlightGear.[[File:FGrun_prop.jpg|thumb|Avancé: Propriétés]]
#* Personnellement, je n'aime pas que mon avion commence à rouler sans me prévenir. Donc, je mets le frein de parking par défaut dès le début.
#** Entrer une nouvelle ligne: Touchez “New” et tapez votre lien.
#** Éditer une ligne: Soyez sûr de cliquer d'abord sur l'item existant et éditez cette “Propriété”
#** Effacer une ligne: Clicquez sur la ligne, puis sur Effacer "Delete"
# Touchez “OK” → “Run” et vous voyez FlightGear se lancer. Si la dimension de votre écran le permet, vous pouvez pousser sur le côté la "Fenêtre de Rapport FGFS" et surveiller le chargement des autres modèles multi-player.

==== Démarrer FGcom====
Ouvrez une [[Command line|fenêtre de commande]] et basculez dans le répertoire ou est FGCom (probablement le même que FlightGear) et démarrez FGcom. N'utilisez pas d'autre option que celle de l'adresse du serveur “-Sfgcom.flightgear.org”:
{|
! style="background:#efefef" |Linux
|fgcom -Sfgcom.flightgear.org
|"-Sfgcom..." avec majuscule "S"
|-
! style="background:#efefef" |Linux Git
| cd ~/fgfs sh ./run_fgcom.sh
| pour “Git complete” inutile de préciser l'adresse du serveur, elle est incluse dans le fichier.
|-
! style="background:#efefef" |Windows
|cd 'C:\Program Files\Flightgear\win32' fgcom.exe -Sfgcom.flightgear.org
|"-Sfgcom..." avec majuscule "S"
|}
|-
! style="background:#efefef" |Linux Git
| cd ~/fgfs sh ./run_fgcom.sh
| pour “Git complete” inutile de préciser l'adresse du serveur, elle est incluse dans le fichier.
|-
! style="background:#efefef" |Windows
|cd 'C:\Program Files\Flightgear\win32' fgcom.exe -Sfgcom.flightgear.org
|"-Sfgcom..." avec majuscule "S"
|}
Pour le test suivant, mettez cette fenêtre de commande quelque part, où vous pourrez y accéder

La première réponse doit être::
/fgcom - une communication radio basée sur VoIP avec IAX/Asterisque
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 206M
Using iaxclient library Version SVN 206M

options de ligne de commande analysées avec succès .
lecture des listes d'aéroports ...effectuée.
initialisation IAX client comme invité:xxxxxxxxxxx@fgcom.flightgear.org
Si l'impression jusqu'à cette ligne est différente, revenir en arrière au chapitre [[FGCOM#Test the basic function|Test de la fonction de base]]

{|
|+
|-
|width="300"| ||
|-
|1) Si, à cause d'unu vol antérieur, COM1 éttait sur une autre fréquence que 118.600 (p.ex. sur 119.650) vous verrez les 2 lignes suivantes ajoutées à l'initialisation de la fenêtre FGcom: ||
|-
|
fréquence selectionnée : 119.650
Appel rejeté by remote
|
Au lieu de “119.650” il y aura la dernière fréquence utilisée. Dans ce cas, la source de la plus proche ATC-Freq. 119.650 est à plus de 50km de la position actuelle de votre avion, et ainsi, FGCom refuse la connection. Si la dernière fréquence utilisée avait été de moins de 50 km vous obtiendrez un indication du gentre
|-
|2) Entrez 118.60 dans COM1 (celle de Palo Alto):
|-
|
Selected frequence: 118.600
Appel suspendu 0
Airport Palo Alto (KPAO Tour à 118.600 MHz) est dans le secteur ( 0.6 km)
Appel 0 accepté
Appel 0 demandé
Airport Palo Alto (KPAO Tour à 118.600 MHz) est dans le secteur ( 0.6 km)

|Cette dernière ligne sera répétée selon le temps que vous avez précisé dans la commande “Input/Output” “--generic=socket,in,'''10''',,5500,tcp”, vous pouvez changer cette valeur plus tard selon votre préférence.
|-
| 3) Appuyez sur votre PTT (Appuyer Pour Parler sur la barre d'espace; ou avec le joystick si disponible):
|-
|
[SPEAK] micro activé, haut-parleur muet
[LISTEN] micro muet, haut-parleur actif
[SPEAK] unmute mic, mute speaker
[LISTEN] mute mic, unmute speaker
|Vous ne pouvez parler aux autres que dans l'intervalle “SPEAK” et “LISTEN”.
|-
| Maintenant, installons/vérifions les autres radios:
* COM2 = 120.50 San Francisco
* NAV1 = 114.10 San Jose
* NAV2 = 115.80 San Francisco
4) Appuyer Upper+Space, branchera sur la prochaîne radio: '''NAV1'''
|-
|
Radio-Selectionnée: NAV1
Fréquence selectionnée: 114.100
appel suspendu 0
Appel rejeté by remote
[LISTEN] micro coupé, speaker actif
|Comparez avec l'indication de NAV2 2 pas plus loin: quelquechose ne va pas – et ce n'est pas de votre faute: bien que ce NAV soit valide, (voir ...FGFS/data/Airports/apt.dat.gz), il manque dans le listing de FGCom J'ai rencontré ce problème plusieurs foisaussi bien pour les aéroports que pour les VOR. Si cela arrive sur votre aéroport favori, vous pouvez ajouter ces données manquantes avec un éditeur de texte. Mais avant de changer, sauvez l'original quelque part- en cas!
|-
| 5) Appuyer Upper+Space branche une fois de plus '''COM2'''
|-
|
Radio-Select: COM2
Selected frequency: 120.500
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) à portée (29.1 km)
[LISTEN] mute mic, unmute speaker
Call 0 accepted
Call 0 answered
|tout paraît OK: San Francisco is à 29 km plus loin watch the “km” instead of miles! '''10 km''' = '''6.2137 mi'''
|-
| 6) Appuyer Upper+Space une fois de plus branche '''NAV2'''
|-
|
Radio-Select: NAV2
Selected frequency: 115.800
Hanging up call 0
Airport SAN FRANCISCO VOR-DME (SFO VOR at 115.800 MHz) est à portée (28.5 km)
Call 0 accepted
Call 0 answered
[LISTEN] mute mic, unmute speaker
|Et oui,: la SF VOR est juste un peu plus près que l'aéroport(center)
|-
| 7) Appuyez Upper+Space encore, ramène à '''COM1''':
|-
|
Radio-Select: COM1
Selected frequency: 118.600
Hanging up call 0
Airport Palo Alto (KPAO Tour à 118.600 MHz) distance ( 0.6 km)
Call 0 accepted
Call 0 answered
[LISTEN] mute mic, unmute speaker
|-
| 8) Démarrons et continuons le vol au 130°:
|-
|
Airport Palo Alto (KPAO Tour at 118.600 MHz) est à portée ( 0.4 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) est à portée ( 0.2 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) est à portée ( 0.7 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) est à portée ( 1.3 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) est à portée ( 1.9 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) est à portée ( 2.4 km)
|remarquez que vous venez d'abord plus près (du centre de l'aéroport) après, on s'éloigne
|-
| 9) Branchez sur '''COM2''' (San Francisco) et observez:
|-
|
Radio-Select: COM2
Selected frequency: 120.500
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) est à portée (37.8 km)
Call 0 accepted
Call 0 answered
[LISTEN] mute mic, unmute speaker
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) est à portée (38.6 km)
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) est à portée (39.5 km)
..
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) est à portée (49.7 km)
Hanging up call 0
Radio-Select: NAV2
Selected frequency: 115.800
Call rejected by remote
[LISTEN] mute mic, unmute speaker
|Cela veut dire: aux environs de 50KM nous allons être hors de portée, et l'activité de COM2 va cesser. Remarquez aussi que NAV2 devient inactif, parce que à peu près au même moment, la portée permise est dépassée!
|}
10) Vous pouvez maintenant faire demi-tour et voir l'opposé: à la même distance environ, les deux redeviendront actives ( automatiquement si vous ne changez pas les données).

Si vous arrivez ici sans problèmes (techniques) votre FGCom est pleinement fonctionnelle. Amusez-vous bien avec!.

=== Utilisation de FGCom ===
Il y a trois types d'utilisation de FGCom:
* '''Utilisation normale aux aéroorts:''' p.ex. Vous programmez votre radio à l'aéroport, comme d'habitude. Ensuite, vous entrez les procédures habituelles soit ATC-(clavier)- (soit "'" (UpperCase#) et/ou le Chat-Menu). De plus, vous pouvez communiquer avec n'importe qui dans un rayon de 50 km (environ 30 miles) autour de l'aéroport, des amis, un opérateur en place FGCOM-ATC/Twr-Operateur, les services d'aéroport, etc.. Remarquez que depuis avril 2009 seulement très peu d'avions utilisent FGCOM comme ATC (Air Trafic Control) donc, vous pourrez toujours utiliser les procédures ATC-Chat "keyboard"- pour annoncer départs/arrivées/taxiing etc. (Nous espérons que tout cela changera dans le futur!)
* Les fréquences Air-Air '''AirToAir frequencies (122.75 et 123.45)''' sont idéales pour Multiplayer. Il n'y a pas de limitation de portée et pas encore trop d'encombrement). Ainsi, lorsque vous volez, vous pouvez entrer 122.75 pour ceux qui veulent être en communication avec vous (ou l'inverse). Quand il y a beaucout de "talk" sur 122.75 vous pouvez convenir avec votre partenaire de basculer sur 123.45 - et de revenir à 122.75 ensuite. Depuis avril 2009 122.75 et 123.45 sont déja opérationnels
* En fin de compte, vous pouvez manipuler les tables de fréquences (positions.txt dans votre FGFS/FGCOM répertoire local) and '''créer une fréquence propre à certains évenements''', p.ex École de pilotage à un aéroport avec plusieurs groupes d'élèves. Naturellement, ce sont des manipulations locales sur votre PC, que vous devez faire en accord avec vos partenaires à l'avance.

=== Informations complémentaires ===
==== Trucs et Astuces====
===== Aéroport manquant dans FGCom: =====
Au cas ou votre aéroport favori n'apparaitrait pas dans FGCOM (fenêtre de commande), bien que vous le cherchiez dans votre COMM, vous pouvez l'ajouter à votre fichier de donnée “'''positions.txt'''” idans votre répertoire fgcom. Voyez p.ex. la ligne
KSFO,120.500,37.616630,-122.385478,TWR,San Francisco Intl
Vous pouvez ajouter des lignes pour autant de localisations que vous voulez p.ex: (respectez les virgules de séparation)
apt-code = DUMY (une icone pour le code de votre aéroport manquant)
KHz = prenez dans votre “FGFS-home/data/Airports/apt.dat.gz”
ou prenez en juste un dont vous êtes sûr que vous n'en avez pas besoin dans le FGFS réel
(remarquez que plusieurs aaéroports (far apart) emploient la même fréquence!
long/lat = prenez dans Mpmap (ou Google Map)
type = xxx
name = xxx
''(Naturellement, seul votre PC personnel connaît ces modifications et ce, jusqu'à la prochaine mise à jour des données!)''

===== Edition des fichiers de données FGCOM=====
Si vou éditez des fichiers-texte (p.ex. des Radio-listings) ou xml-files, vous pouvez ne pas voir les fins de lignes quand vous utilisez votre éditeur standard.
* Pour windows vous pouvez utiliser "WordPad"
* Pour Linux le "gedit" travaille bien

===== Copier/Imprimer cette page Wiki''' =====
Si vous tenez absolument à avoir une copie locale sur votre PC, ou besoin d'une copie impriméeI:

* pour copier:
** selectionner dans le menu du navigateur: "File" --> "Save Page as.. "
* pour imprimer:
** allez à [http://wiki.flightgear.org/index.php?title=FGCOM&printable=yes version imprimable].
** Enfin, je suggère: Menu --> File --> "Page Setup": Set to "Landscape" --> "Apply"
** avant d'imprimer je recommande: Menu --> File --> "Print Preview" et vous verrez ces nombreuses pages!
** Si vous voulez vraiment gâcher du papier: Menu --> "File" --> "Print" ça imprimera sur votre propre imprimante

=====Compatibilité du joystick entre les systèmes opérationnels: =====
{{Principal article|Joystick}}

Vous pouvez utiliser pour le Joystick les mêmes définitions dans tous les systèmes opérationnels. Mais vous pouvez changer les numéros assignés-votre vendeur de Joystyck a pu déja le faire pour vous. Enregistrez p.ex. (Unix, Mac, Win ont assignés des nombres différents "numbers"):
<axis> (au lieu de l'habituel<axis n=”3”> )
<desc>Mixture</desc>
<number>
<unix>3</unix>
<mac>5</mac>
<windows>5</windows>
</number>
<binding>
<command>nasal</command>
<script>controls.mixtureAxis()</script>
</binding>
</axis>

===== Assigner PTT au joystick =====
Si vous voulez assigner la fonction PushToTalk à votre Joystick, ajoutez ceci (pour n vous mettez votre propre chiffre!)
<button n="x">
<desc>PTT - Push To Talk</desc>
<binding>
<command>nasal</command>
<script>controls.ptt(1)</script>
</binding>
<mod-up>
<binding>
<command>nasal</command>
<script>controls.ptt(0)</script>
</binding>
</mod-up>
</button>

==== adresses d'aides sur Internet====
'''World-Time:'''
* [http://www.timeanddate.com/worldclock/custom.html?sort=1 standard deviations]
* [http://www.timezoneconverter.com/cgi-bin/tzc.tzc direct conversions]

Spécialement pour les événements multi player, vous devrez spécifier tous les temps en GMT (Greenwich Meantime). Notez juste votre différence par rapport à GMT et mémorisez la. Si tout le monde le fait, on peut éviter beaucoup d' incompréhensions

* '''Decimales et Degrès''' http://www.hbnweb.de/mathematik/grad-dezimal.html 
*: Quelques programmes réclament des valeurs décimales de Lon/Lat, d'autres en Degrès/Minutes/Sec. Les convertir. 
* '''Miles, km, pieds, etc. etc. ...''': http://www.convertunits.com/
*: Si vous voulez éviter des ennuis(la NASA a perdu un satellite à cause de ça) voyez plus haut.

'''Ports necéssaires'''

En cas de problèmes avec Internet, notez que les ports suivants sont permis :
1314 TCP Si le Festival-Server est utilisé pour Text/Sound
2005 UDP Vcp-Stream
4569 UDP FGCom VoIP, (Inter-Asterisk eXchange)
5000 UDP in/out Multiplayer (VPN Sftw.)
5001 UDP Enable HTTP-server
5002 UDP Enable property server
5003 UDP Enable Screen-Shot services
5004 UDP (peut être utilisé comme réserve)
5505 UDP Terra Sync
16661 UDP FGCom écoutant FGFS, habituellement “local host” seulement
Considérez aussi que certains modems modernes fournissent un pare-feu. Si en plus vous en avez un dans votre PC, attendez vous à une compétition néfaste entre les deux. En cas de problème, il faudra en désactiver l'un des deux (d'habitude celui du PC, et en particulier si plusieurs PC sont connectés via ce modem).

==== Paramètres de la ligne de commande ====
fgcom --help
retourne les infos habituelles suivantes
fgcom - a communication radio based on VoIP with IAX/Asterisk
(c)2007 by H. Wirtz <wirtz@dfn.de>
Version 1.2.2 build 163M
Using iaxclient library Version SVN 163M

OPTION DESCRIPTION

-d, -debug, --debug= montre des informations de debuggging
-S, -voipserver, --voipserver= voip server à connecter par défaut (default: 'fgcom1.parasitstudio.de')
-s, -fgserver, --fgserver= programme network a connecter à (default: 'localhost')
-p, -port, --port= où nous écoutons FG (default: '16661')
-a, -airport, --airport= airport-id (ICAO) pour ATC-mode
-f, -frequency, --frequency= frequence pour ATC-mode
-U, -user, --user= nom d'utilisateur pour compte VoIP (default: 'invité')
-P, -password, --password= mot de passe pour compteVoIP (default: 'invité')
-i, -mic, --mic= mic niveau d'entrée(0.0 - 1.0)
-o, -speaker, --speaker= speaker niveau de sortie (0.0 - 1.0)
-b, -mic-boost, --mic-boost= enable mic boost
-l, -list-audio, --list-audio= liste des programmes audio
-r, -set-audio-in, --set-audio-in= use <devicename> comme entrée audio
-k, -set-audio-out, --set-audio-out= use <devicename> comme sortie audio
-c, -codec, --codec= use codec <codec> comme transfer codec (default: 'u')

Codecs disponibles:
u - ulaw (default and best codec because the mixing is based onto ulaw)
a - alaw
g - gsm
s - speex
7 - G.723

Mode 1: client for COM1 of flightgear:
$ fgcom
- connects fgcom to fgfs at localhost:16661
$ fgcom -sother.host.tld -p23456
- connects fgcom to fgfs at other.host.tld:23456

Mode 2: client for an ATC at <airport> on <frequency>:
$ fgcom -aKSFO -f120.500
- sets up fgcom for an ATC radio at KSFO 120.500 MHz

Notez que /home/hcs/src/fgcom/trunk/src/fgcom commence avec un compte d'hôte , à moins d'utiliser -U and -P!

Notez aussi que le serveur habituel (fgcom.flightgear.co.uk) travaille avec un compte d'hôte, aussi, ne pas utiliser -U or -P'''

==Installation du serveur==
{{Article principal|Howto: Set up a FGCom server}}

== Liens externes ==
* [http://sourceforge.net/projects/fgcom/ fgcom(SourceForge-Project)] Sous-version est [http://fgcom.svn.sourceforge.net/ disponible ici]. Si vous n'avez pas utilisé la Sous-version auparavant, vous pouvez plus facilement la trouver dans [http://fgcom.svn.sourceforge.net/viewvc/fgcom/?view=tar archive] à la place.
* ldernière source disponible ici (?): http://code.google.com/p/fgcomgui/

=== Liens cassés ou déteriorés ===
* [http://squonk.abacab.org/dokuwiki/fgcom Old Official website]
* [http://squonk.abacab.org/dokuwiki/fgcom-manual Manual]

== Status ==
* '''Mars, 2009:'''
Ajout d'informations aux utilisateurs pour installer, utiliser maintenir FGCOM sur différentes plateformes.

* '''18 Novembre, 2008:'''
la plus récente SVN (rev 163) a fixé les problèmes de compilation. Aussi, nous avons un nouveau serveur: fgcom.flightgear.org'''. Les comptes d'utilisateurs ne sont pas demandés (ie. do '''not''' use -U or -P)
* '''31 Octobre, 2008:'''

La plus récente version SVN à ce moment est la '''r149''' qui ne compile pas à cause d'une constante indeterminée (STL_STRING). elle apparait à la ligne 57 dans le fichier ''src/fgcom_init.cpp'' qui est:
''#include STL_STRING''

Je devine qu'une telle constante doit apparaître dans un fichier de STL library mais je n'en suis pas sûr.
Je reviens à la version '''r148''' SVN qui compile avec succès.

La commande pour une telle version est: ''svn co -r148 svn://svn.dfn.de:/fgcom/trunk fgcom-r148''

* '''19 Juin, 2008:''' Le serveur est down en raison de problèmes de hardware. On ignore la fin de cette panne car le probléme n'est pas encore défini.

* '''22 Novembre 2007:''' Due to heavy development at this time there may be some differences between the information on the web pages and the installation. Please follow the discussions on the FlightGear development list!

== Related content ==
* [[FlightGear related projects]]
* [[FGComGui]]

[[Category:Software]]
[[Category:FGCom]]
[[en:FGCom]]
[[fr:FGCom]]

FGCom (before 3.0)

2015-01-01T18:35:44Z

F-JJTH:

{{obsolete|FGCom_3.0}}

{{historical
| type = article
| tense = is
| text = obsolete
| reason = The new version of FGCom is much more simple to use, a clean documentation is available at [[FGCom_3.0]]
| talk =
| date = 1 January 2015
| nocat =
}}

{{Infobox Software
| title = FGCom
| logo =
| image =
| alt =
| developedby = Holger Wirtz, Martin Spott, Csaba Halasz
| hostedby = tgreer @ tsone . info
| initialrelease =
| latestrelease =
| writtenin =
| os =
| platform =
| developmentstatus = Active (2007-)
| type =
| license = [[GNU General Public License]]
| website = https://gitorious.org/fg/fgcom
}}

'''FGCom''' is an addon for [[FlightGear]]. With FGCom (and the infrastructure behind it), FlightGear has a realtime voice communication system which enriches the FlightGear capabilities, especially for [[Howto: Multiplayer|multiplayer]] events, like:

* Flying in groups, see the [http://forum.flightgear.org/viewforum.php?f=10 multiplayer events forum]
** Invite friends to a guided sightseeing tour in your most beloved area or do “Fly In's”
** Do military training like [[Howto:Aerial_refueling|“Air-Air-Refuelling”]], “Dog fights”, “Escort flights”, etc.
* Offering additional services at an airport like [[Air traffic control|ATC]], [[Vehicle|snowplows, pushbacks]], racing-events, etc.
* Have a [[Dual control|real time flighttraining]] (e.g. pilot in Hongkong, teacher in Sydney), do [[Soaring|Glider-towing]], ask for on-line support during flight or just ask somebody flying a plane of interest about specifics.
* Or just sit in a cockpit in Germany while sightseeing San Francisco in a [[Cessna C172|C172]], voice-chat with a Texan in a plane I dreamed of as a boy ([[Lockheed Constellation|Super Constellation]]) and both getting information from a New Zealand guy (it shall be a wonderful island – but do real people live there? He said: Yes!!).
* And much more!

You can even use it in models without radios - just use the standard FlightGear menu --> Equipment --> Radio Settings).

In the future FGCom surely will extend further and surely will get a “Speech to Text” capability in order to also integrate the text-based automated ATC-routines inside FlightGears.

== The Client installation ==
=== Prequisites ===
==== Hardware Requirements ====
If you are satisfied with the operation and response times of your current FlightGear installation, then you should see no significant difference after adding the FGCom. If your FlightGear installation runs already a little marginal, then you might experience some delays when many new airplane-models etc. must be loaded. This may happen when starting up at a busy airport. You can monitor/verify such a "short-time overload" in the FlightGear command-window.

For details see the [http://www.flightgear.org/hardwarereq.html common hardware and driver requirements].

Of course you will also need a connection to the internet for this real-time, worldwide voice communication.

==== Software requirements ====
{| border="1"
|align="center" width="90px" |'''FlightGear''' ||The basic [[FlightGear]] Flight Simulation installation. This must be installed prior to installing FGCom ''(except if installing the Linux "Git complete" version which can install FGCom and FlightGear concurrently)''.
|-
|align="center" |'''Multiplayer'''||[[Howto: Multiplayer|“Multiplayer”]] is not an installable program but an integrated function of FGFS. As the name says, it enables communication of several players via a chat-function (until now per keyboard - now also with this vocal interface: FGCom).
|}

==== Nice to have ====
{| border="1" cellpadding="10"
|align="center" width="90px" | '''FGrun'''||This [[FlightGear Launch Control]] (also known as FG Wizard), is a graphical front end to start the FGFS. This makes it very easy to startup the FGFS with all its possible options. In some newer distributions this is already part of the basic FGFS installation package.
|-
|align="center" |'''MPMap'''||[[MPMap]] is a pure browser application based on Google Maps, so it does not need any installation, except a Web-Browser. With MPMap you can watch all Multiuser-planes worldwide on a road-map, satellite picture or a composite of both. It includes most of the airports, navigational aids, and current weather information. So it can be used for preflight planning, without having the FGFS started or even installed. But it needs a constant connection to the Internet - on the other hand you can do your preflight planning anywhere where there is a PC, connected to the Internet (with/or without FlightGear installed!).
|-
|align="center" |'''SkyVector'''||[http://skyvector.com/ SkyVector] is a standalone Browser-Application. It does present a fantastic Fight-Planning tool, showing similar aspects like the "MPMap" - but is based on a an real Aeronatical map ("Sectional"). On it you can graphically plan your routes.
But it does not directly link into FGFS, MPMap or Multiplayer -- and it covers only the domestic USA.
|-
|align="center" |'''Atlas'''||[[Atlas | Atlas]] displays the current position of your airplane on an landscape type of map together with navigational information. It derives its data direct out of the installed FGFS databases. So you do not need any connections to the Internet.
|-
|align="center" |'''Festival'''||http://www.flightgear.org/Docs/getstart/getstart.html#QQ2-10-108 is a TTS (Text To Speech) system that can convert all in the FGFS displayed written text (ATC, Chat, etc.) into speech and put it in your loudspeakers.
|}

=== Installing FGCom ===
==== Install on Linux ====
:For Linux-Systems there are various ways to install:
# '''"Integrated Installation” to be available with FGFS 3.0 spring 2014''', may be tested with GIT 2.99'''
#* '''Advantage:''' This will be the long expected "integration", i.e. users do not have to care about installing FGCOM manually. And you will be able to switch FGCOM on/off during flight (see http://wiki.flightgear.org/Integrating_FGCom)
#* '''Disadvantage:''' This is still in a "Test-mode", so you might have problems when testing
#* '''Installation:''' Is done automatically when installing FGFS (starting FGFS 3.0 / GIT 2.99)
# '''Installation of a "Standalone FGCOM"
#* '''Advantage:''' you can use this "Standalone FGCOM" without using FGFS (e.g. when operating OpenRadar)
#* '''Disadvantage:''' There may be only a engineering test version available (as of today) - use that with care!
#* '''Installation:'''You can download the needed "Standalone FGCOM".zip from http://fgcom.flightgear.org/download/.
#*:: and unzip it into a directory of your choice
#*:: then you start fgcom in a terminal like:
<div>
::::<table>
<tr><pre>
cd '/home/YourName/fgfs/bin
./fgcom
</pre></tr></table></div>
# '''Downloading from the “Distributor” (Debian, Ubuntu, Red Hat, Suse, etc.).'''
#* '''Advantage:''' This is the easiest way and ensures that maintenance and services for this package and all concurrencies to it are provided automatically for a reasonable time-frame.
#* '''Disadvantage:''' The availability of those packages is usually very late and most Distributors do not cover all FGFS-features. To our knowledge none of the Distributors has a FGCom-package available as of Oct. 2013.
#* '''Installation:''' Follow the usual procedures of your distributor on how to install additional packages.
# '''Install today’s newst GIT or released version
#* '''Advantage:''' It is the very easiest form of installation and installs in one step any (or all) prerequisite/companion modules (FGFS, FGrun, FGcom, PLIB, OSG, Simgear, AT). Also it can be added and removed from the system without disturbing the rest of the system (Libraries, Menus, Structures, etc.). It was tested on several Ubuntu and Debian systems.
#* '''Disadvantage:''' No automated maintenance available. The handling is a little different from the standard Menu-driven practices.
#* '''Installation:''' use the [[Scripted Compilation on Linux Debian/Ubuntu]]
<div>
::<table>
<tr><pre>
mkdir fgcom
cd fgcom
wget http://www.gitorious.org/fg/fgmeta/raw/download_and_compile.sh
chmod +x ./download_and_compile.sh
./download_and_compile.sh PLIB FGCOM
</pre></tr>
... it will ask 2 x for the root password
then it looks like this:
<tr><pre>
[ 95%] Building CXX object CMakeFiles/fgcom.dir/src/fgcom.cpp.o
[ 97%] Building CXX object CMakeFiles/fgcom.dir/src/fgcom_init.cpp.o
[ 98%] Building CXX object CMakeFiles/fgcom.dir/src/position.cpp.o
[100%] Building CXX object CMakeFiles/fgcom.dir/src/utils.cpp.o
Linking CXX executable fgcom

[100%] Built target fgcom
-- Install configuration: "Release"
-- Installing: /big/home/mherweg/flightgear/fgcom/try/install/fgcom/bin/fgcom
-- Installing: /big/home/mherweg/flightgear/fgcom/try/install/fgcom/share/fgcom/positions.txt
-- Installing: /big/home/mherweg/flightgear/fgcom/try/install/fgcom/share/fgcom/special_frequencies.txt
To start fgcom, run the run_fgcom.sh file
To start fgcom GUI, run the run_fgcomgui.sh file
Usage: ./download_and_compile.sh -h
for help
</pre></tr>
then you can start fgcom like this:
<tr><pre>
./run_fgcom.sh -Sfgcom.flightgear.org
</pre></tr>
</table></div>
 
==== Install on Mac ====
# '''MacFlightGear 1.9.1/2.0.0''' 
#* You can download the "MacFlightGear"-Application from the [http://www.flightgear.org/Downloads/binary.shtml#mac FlightGear download-center]. Starting with version 2.0.0 the code does contain the FGCom and works for OSX >= 10.5. (with OSX versions < 10.5 you will end up with a generic "bus error" message).
# '''Installation of a "Standalone FGCOM"
#* '''Advantage:''' you can use this "Standalone FGCOM" without using FGFS (e.g. when operating OpenRadar)
#* '''Disadvantage:''' There may be only a engineering test version available (as of today) - use that with care!
#* '''Installation:'''You can download the needed "Standalone FGCOM".zip from http://fgcom.flightgear.org/download/.
 
==== Install on Windows ====
# '''Please use the Windows installation description'''
#* available through [[FGCOM for Windows]].'''
# '''Installation of a "Standalone FGCOM"
#* '''Advantage:''' you can use this "Standalone FGCOM" without using FGFS (e.g. when operating OpenRadar)
#* '''Disadvantage:''' There may be only a engineering test version available (as of today) - use that with care!
#* '''Installation:'''You can download the needed "Standalone FGCOM".zip from http://fgcom.flightgear.org/download/.

=== Functional test & user briefing ===
To insure that we can differentiate between troubles
* that may be caused by the FGFS
* and those caused by FGCom
we will also describe the FGFS-Start and it's, for this test needed, settings in detail.

Experiences pointed out, that the cooperation between FGCom and FlightGear works more reliable, if FlightGear is started first. So we will start with setting up FGFS first:

==== Start FlightGear ====
To set all required and/or proposed settings for this first functional test, we suggest to use
*for Windows and Linux [[FGRun]]
*which for MAC-OSX is the integrated "GUI Launcher"
In the following we will just point out those commands which are significant for the FGCom-operation:

If you don't have an icon available to start FGrun, then start it manually:

# Start a [[Command line|command-window]]
# Change into the directory in which FGFS was installed
# Execute the following command or something similar
::{|
! style="background:#efefef" | Linux
|fgrun
|-
! style="background:#efefef" | Windows
|C: cd 'C:\Program Files\Flightgear\win32' fgrun.exe
|}

Wait for the program window to start and then define:
<ol>
<li> Start by '''choosing an airplane'''. For this first try we suggest the [[Cessna C172]]P, so we have a common understanding in the following. Also be aware of some airplane-designers reassigning keyboard-keys (e.g. the “space-bar” which is used as PTT, may activate a "BombDrop" in a Fighter-jet!), thus you may not have the PTT-key (“Push To Talk”) available. See [[FGCOM#Tips and Tricks]]. → Click "Next".
</li><li> As '''starting place''' please define the airport KPAO (Palo Alto) runway 13, so we all see the same messages in the following reports. A second reason for KPAO is of course that KPAO comes already with the basic scenery-package, and thus is available for everybody. → Click "Next".[[File:FGrun_base.jpg|thumb|Basic & multiplayer options]]
</li><li> Define the '''Multiplayer options:''' (see [[Howto: Multiplayer]] for details).
* “AI models” must be activated in order to see all traffic
* “Multiplayer” must be activated
* type “'''mpserverXX.flightgear.org'''” into the field “Hostname:”, replace “XX” with the server number nearest you - select it in http://mpserver15.flightgear.org/mpserverstatus/. Actually it does not matter which server you take (as long as it is online and not as overcrowded as mpserver02) - you might try which server gives you the best response-times.
* insert your “Callsign:” (max. 7 characters)
* define the “in” and “out” ports both with the standard “5000”
* With "Load/Save as" you may build up yourself a library of settings for different airports. → Click "Advanced".[[File:FGrun_IP.jpg|thumb|Advanced: Initial Position]]
</li><li> In the “'''Advanced Options'''” check the following sections (click/select them in the left column):
* General: Those settings were defined before. Check “Control”, if needed select your input device (Joystick, Keyboard, or Mouse).
* Features: “AI Traffic” should be activated already
* Initial Position: You may define here an unique “starting/parking” position outside a runway. Thus you could avoid starting on top of another player, because most of them pile up at the end of a runway. You can look up a position in the MPMap: ''(see next item)''
** ''Be aware that any data defined here override already predefined data (e.g. also an airport and runway). So '''do not forget''' to change/delete the here defined positions if some time you want to start from another airport.'' Of course you may save/reload settings for different airports, see "Load/save as" on the main window.[[File:MPmap.jpg|thumb|[[MPMap]]]]
</li><li> Open the '''[http://mpmap02.flightgear.org MPMap]'''
* if the control-panel is not visible click onto "FGMap | mpserver02:5000 | pilots: 7”
* click on “nav”
* disable all options except “apt code”
* type “KPAO” into the filed “Navaids lookup”
* hit ENTER or click onto the reading-glass symbol
* click onto the appearing line “Airport -- KPAO -- Palo Alto”
* now you could/should support your preflight planning by clicking onto the wedge in the upper right corner after the airport name and then analyse all data given under “info”, “atc”, metar”, and “links”
* then zoom into the airport
* set the mouse over the wanted “Parking lot” and read that position in the upper right corner of the screen
* type those long/lat values into the field below and also the wanted heading of the plane while parking[[File:FGrun_net.jpg|thumb|Advanced: Network]]
</li><li> '''Network:''' Those data you have already predefined on the Base-Page. But in case you have network-problems (may be due to many PC's on a home-network with even more LAN-cards) you may specify here your actual IP-Adress.
* WARNING: When saving these settings and reloading them again, FGRun might replace the given IP-Nr. by the PC-name. As of March 2009 you then have to replace that again with the IP-Nr. So use it only if you have to - first try it by adding nothing between the ",,". Keep it as "in,10,,5000".
* If you need to '''define the unique IP-Address''', open a [[Command line|command-window]] and type

::{|
! style="background:#efefef" | OS
! style="background:#efefef" | to type
! style="background:#efefef" | cap.
! style="background:#efefef" | returned values
|-
! style="background:#efefef" | Linux
|ifconfig
|eth0
|Link encap:Ethernet HWaddr 00:1d:92:80:a6:ab inet addr:'''192.168.178.23''' Bcast:192.168.178.255 Mask:255.255.255.0
|-
! style="background:#efefef" | Windows
|ipconfig /all
|et
|Physikalische Adresse . . . . . . : 00-16-E6-40-AB-BF
 DHCP aktiviert. . . . . . . . . . : Ja
 Autokonfiguration aktiviert . . . : Ja
 IP-Adresse. . . . . . . . . . . . : '''192.168.178.20'''
 Subnetzmaske. . . . . . . . . . . : 255.255.255.0
 IP-Adresse. . . . . . . . . . . . : fe80::216:e6ff:fe40:abbf%4
|}
:: '''192.168.178.23''' (or '''20''') is the number you would have to input between the two commas. Be very careful and double-check that you do not mistype “.” and “,”!![[File:FGrun_IO.jpg|thumb|Advanced: Input/Output]]
</li><li> '''Input/Output:'''
* You do need a "generic" line as shown, because '''this defines the interface between FlightGear and FGCom'''.
** To input a new line: Start by selecting “generic” in the field “Protocol”. Then hit “New” and define the rest as shown.
** Editing an existing line: Start by clicking onto the existing one, then change as required.
** Deleting an existing line: Click onto the line to be deleted, then hit "Delete"
* For fgo or the command line add --generic=socket,out,10,localhost,16661,udp,fgcom to the command line options
</li><li> '''Avionics:''' let us define:
::{|
! style="background:#efefef" | Nav1:
| 114.10
| San Jose VOR
|-
! style="background:#efefef" | Nav2:
| 115.80
| SF VOR
|-
! style="background:#efefef" | ADF:
| 379
| Brijj, beacon at SF
|}
* And activate DME to Nav1
* There is no field to input COM-radios, but remember them for setting them later manually:
::{|
! style="background:#efefef" | Com1
| 118.60
| Paolo Alto
|-
! style="background:#efefef" | Com2
| 120.50
| San Francisco
|}
</li><li> '''Properties:'''
* Here you can define any presetting for any values in the FGFS. See e.g.: <tt>File > Browse Internal Properties</tt> in the FlightGear [[menu]].[[File:FGrun_prop.jpg|thumb|Advanced: Properties]]
* I personally do not want the plane to start rolling without me telling it to. So I set the parking break as default at startup.
** Input a new line: Just hit “New” and type your string.
** Edit a line: Be sure first to click onto an existing item and then edit this “Property”
** Delete a line: Click onto the line to be deleted then hit "Delete"
</li></ol>
Hit “OK” → “Run” and watch FlightGear starting. If screen-place allows you may want to pull the shown "FGFS Report-Window" to the side and watch how busy your PC is while loading the other multi-player models.

==== Start FGCom ====
Open a [[Command line|command-window]] and change into the directory in which FGCom was installed (probably the same as FlightGear) and start FGCom. The server you want to use for events is '''fgcom.flightgear.org''' (fgcom.flightgear.org.uk was the originally used server and is not available any more).

To start FGCom with the defined server you must insert the server address after a "-S" (watch: The "S" must be a capital!):
::{| border="2" cellpadding="5"
! style="background:#efefef" |Linux||fgcom -Sfgcom.flightgear.org
|"-Sfgcom..." with capital "S"
|-
! style="background:#efefef" |Linux Git 
(FS 3.00 or GIT 2.99)
| cd ~/fgfs sh ./run_fgcom.sh
| This is the new integrated version, which you will start and set options from inside the FGFS!
|-
! style="background:#efefef" |Windows
|cd 'C:\Program Files\Flightgear\win32' fgcom.exe -Sfgcom.flightgear.org
|"-Sfgcom..." with capital "S"
|}

For the following tests, position the command-window somewhere, where you can monitor it throughout the test.
 
'''''Be aware that the standard range for the FGCom is 50km, but some people have a version with a range of 100 km! So in the following description the "50 km" restriction might be replaced with 100km!!'''''
 
'''1) The first response should be:'''
fgcom - a communication radio based on VoIP with IAX/Asterisk
Original (c) 2007-2011 by H. Wirtz <wirtz@dfn.de>
OSX and Windows ports 2012-2013 by Yves Sablonier and Geoff R. McLane, resp.
Version 3.1.0 compiled Mar 2 2014, at 00:21:19
Using iaxclient library Version SVN 261

Successfully parsed commandline options
Loaded file [/usr/share/flightgear/special_frequencies.txt].
Reading airports [/usr/share/flightgear/positions.txt]
loaded 47171 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org

If, due to a prior flight, COM1 was set to anything else but 118.600 (e.g. to 119.650) you will see the following 2 lines added to the above shown initialization of the FGCom-window:
Selected frequency: 119.650
Call rejected by remote
Instead of “119.650” there will be shown the last used frequency. In the above example the source of the ATC-Freq. 119.650 is more than 50km away from your actual position, so FGCom rejects a connection to it. If the last frequency used would have been within 50 km you get an indication very similar to the next item.
 
'''2) Switch COM1 to 118.60 (as needed at Palo Alto):'''
Selected frequency: 118.600
Hanging up call 0
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 0.6 km)
Call 0 accepted
Call 0 answered
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 0.6 km)
This last line will be repeated according the to time span you defined in the “Input/Output” command “--generic=socket,in,'''10''',,5500,tcp” (10 means all 10 sec.), you may change that value later according to your preferences.
 
'''3) Press your PTT (PushToTalk on space-bar and joystick, as available):'''
[SPEAK] unmute mic, mute speaker
[LISTEN] mute mic, unmute speaker
[SPEAK] unmute mic, mute speaker
[LISTEN] mute mic, unmute speaker
Only in between “SPEAK” and “LISTEN” you are able to talk to others.
 
'''4) First let us set/verify the other Radios:'''
COM2 = 120.50 San Francisco
NAV1 = 114.10 San Jose
NAV2 = 115.80 San Francisco
 
'''Then: Pressing Upper+Space will switch to the next radio: '''NAV1'''
Radio-Select: NAV1
Selected frequency: 114.100
Hanging up call 0
Call rejected by remote
[LISTEN] mute mic, unmute speaker
Compare this to the NAV2 indication 2 steps later: something is wrong – and it wasn't your fault: Although this NAV is valid (see ...FGFS/data/Airports/apt.dat.gz), it is missing in the FGCom listing .../FGCom/positions.txt. I encountered this problem several times, as well for Airports as also for VOR's. If this happens with your most beloved airport you can add those missing data with a text-editor. But before changing be sure you know what/how you are doing and also save the original data somewhere - just in case!
 
'''5) Pressing Upper+Space once more switches to COM2'''
Radio-Select: COM2
Selected frequency: 120.500
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) is in range (29.1 km)
[LISTEN] mute mic, unmute speaker
Call 0 accepted
Call 0 answered
That looks OK: San Francisco is about 29 km away! Watch the “km” instead of miles! '''10 km''' = '''6.2137 mi'''
 
'''6) Pressing Upper+Space once more switches to NAV2'''
Radio-Select: NAV2
Selected frequency: 115.800
Hanging up call 0
Airport SAN FRANCISCO VOR-DME (SFO VOR at 115.800 MHz) is in range (28.5 km)
Call 0 accepted
Call 0 answered
[LISTEN] mute mic, unmute speaker
And Yes: The SF VOR is just a little closer than the airport-center
 
'''7) Pressing Upper+Space once more brings back '''COM1''':'''
Radio-Select: COM1
Selected frequency: 118.600
Hanging up call 0
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 0.6 km)
Call 0 accepted
Call 0 answered
[LISTEN] mute mic, unmute speaker
 
'''8) Lets us start and continue flying with a heading of about 130°:'''
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 0.4 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 0.2 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 0.7 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 1.3 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 1.9 km)
Airport Palo Alto (KPAO Tower at 118.600 MHz) is in range ( 2.4 km)
notice that you first come closer (to the center of the airport) and after that getting away
 
'''9) Let's switch to '''COM2''' (San Francisco) and watch:'''
Radio-Select: COM2
Selected frequency: 120.500
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) is in range (37.8 km)
Call 0 accepted
Call 0 answered
[LISTEN] mute mic, unmute speaker
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) is in range (38.6 km)
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) is in range (39.5 km)
..
Airport San Francisco Intl (KSFO TWR at 120.500 MHz) is in range (49.7 km)
Hanging up call 0
Radio-Select: NAV2
Selected frequency: 115.800
Call rejected by remote
[LISTEN] mute mic, unmute speaker
That means: at about 50KM we are getting out of range and thus the on COM2 active SF getts terminated. Notice that also the inactive NAV2 gets terminated, because it exceeded the allowable range at about the same time!
 
You could turn now and watch the opposite: At about the same distance those two will become active again (automatically, if you did not change the settings).

If you got here without any (technical) problems your FGCom is fully functional. Have fun when using it.

=== Using FGCom ===
There are basically three types of FGCom-usage:
* '''Normal usage at airports:''' i.e. You set your radio to the airport as usual. Thus you are set up for the usual ATC-(keyboard)-procedures (either through the "'" (UpperCase#) and/or the Chat-Menus). In addition you then can talk to anybody in a radius of about 100 km (about 54 miles) around the airport, may that be friends, a maintained FGCOM-ATC/Twr-Operator, airport utilities, etc.. Be aware that as of April 2009 only very few planes are using the FGCOM for ATC-purposes - thus you should always use the ATC-Chat "keyboard"-procedures to announce arrivals/departures/taxiing etc. in addition. (We hope that may change in some future!)
* The '''AirToAir frequencies (122.75 and 123.45)''' are ideal for all Multiplayer events. They are without any range-limitations - and not yet "overcrowded!). Also when traveling you might want to listen on the 122.75 for others who want to contact you (or reverse). When there is much "talk" on the 122.75 you might just arrange with your partner to switch to 123.45 - and return to 122.75 afterward. As of April 2009 the 122.75 is already operational for this application, the 123.45 will follow soon. You may try from time to time if this limitations still exist.
* The Echo-Test frequency 910.00 to test your sound settings
* Finally you can manipulate the frequency-tables (positions.txt in your FGFS/FGCOM local directory) and '''define an own frequency for special events'''. e.g. a Flight-School at one airport with maybe multiple student-groups. Of course those are local manipulations on your own PC, which you have to agree on with your (planned to be) partners in advance.

=== Supplemantery Information ===
==== Tips and Tricks ====
===== Airport missing in FGCom: =====
In case your favorite airport does not show up in the FGCOM (command-window), although you can tune your COMM to it, you can add it to your data-file “'''positions.txt'''” in your fgcom directory. See e.g. the line
KSFO,120.500,37.616630,-122.385478,TWR,San Francisco Intl
You can add extra lines for any locations you want. e.g.: (watch the separation comas)
apt-code = DUMY (a "dummy" or your favorite, but missing, airport code)
KHz = take it out of your “FGFS-home/data/Airports/apt.dat.gz”
or just take one of which you are sure that you do not need it in the FGFS-reality
(notice that several Airports (far apart) use same frequencies!
long/lat = take out of the Mpmap (or Google Map)
type = whatever
name = whatever
''(of course those definition are only known to your own PC and last only until the next data update!)''

===== Editing FGCOM-Data-Files =====
If you edit Textfiles (e.g. Radio-listings) or xml-files you might not see line-endings when using your standard editor.
* For windows you can use "WordPad"
* For Linux the "gedit" works fine

===== Copying-Printing this WIKI-Page =====
If you absolutely want to have a local copy of this on your PC or need a hard-copy, then:

* to copy:
** select in the Browser-Menu: "File" --> "Save Page as.. "
* to print:
** go to the [http://wiki.flightgear.org/index.php?title=FGCOM&printable=yes printable version].
** Then I suggest: Menu --> File --> "Page Setup": Set to "Landscape" --> "Apply"
** before printing I recommend: Menu --> File --> "Print Preview" and you see those many many pages!
** If you really want to wast that paper: Menu --> "File" --> "Print" and it will print on your favorite printer

===== Joystick compatibility between Operating Systems: =====
{{Main article|Joystick}}

You may use the same joystick-definitions across all Operating-Systems: But you may need to change the assigned numbers - your joystick-vendor might have done that for you already. Check e.g. (Unix, Mac, Win having assigned different "numbers"):
<axis> (instead of the usual <axis n=”3”> )
<desc>Mixture</desc>
<number>
<unix>3</unix>
<mac>5</mac>
<windows>5</windows>
</number>
<binding>
<command>nasal</command>
<script>controls.mixtureAxis()</script>
</binding>
</axis>

===== Assign PTT to joystick =====
If you want to assign the PushToTalk function to your joystick, add the following (for n you have to find your own number!)
<button n="x">
<desc>PTT - Push To Talk</desc>
<binding>
<command>nasal</command>
<script>controls.ptt(1)</script>
</binding>
<mod-up>
<binding>
<command>nasal</command>
<script>controls.ptt(0)</script>
</binding>
</mod-up>
</button>

==== Helpful internet adresses ====
'''World-Time:'''
* [http://www.timeanddate.com/worldclock/custom.html?sort=1 standard deviations]
* [http://www.timezoneconverter.com/cgi-bin/tzc.tzc direct conversions]

Especially for multiplayer events you should define all times in the internationally used GMT (Greenwich Meantime). Just pick up your deviation from GMT and memorize it. If everybody does it, we could avoid a lot of misunderstandings.

* '''Decimal to Degree''' http://www.hbnweb.de/mathematik/grad-dezimal.html 
*: Some programs need Decimal Lon/Lat values, others the Degrees/Minutes/Sec. Just convert it. 
* '''Miles, km, feet, etc. etc. ...''': http://www.convertunits.com/
*: If like to avoid troubles (like NASA lost a satellite because of it) just look it up.

'''Ports needed'''

In case of problems over the internet you might check that the the following ports are allowed:
1314 TCP if the Festival-Server is used for Text/Sound
2005 UDP Vcp-Stream
4569 UDP FGCom VoIP, (Inter-Asterisk eXchange)
5000 UDP in/out Multiplayer (VPN Sftw.)
5001 UDP Enable HTTP-server
5002 UDP Enable property server
5003 UDP Enable Screen-Shot services
5004 UDP (may be used as a spare)
5505 UDP Terra Sync
16661 UDP FGCom listening to FGFS, usually “local host” only
Also consider that some modern modems do already provide a firewall. If in addition to that you use a local firewall in your PC, than you might expect an unhealthy competition between those two concurrent firewalls. In case of problems you should deactivate one of those (usually the one inside the PC, especially if several PCs are connected via that modem).

==== Commandline Parameters ====
fgcom --help
returns the following useful info

fgcom - a communication radio based on VoIP with IAX/Asterisk
Original (c) 2007-2011 by H. Wirtz <wirtz@dfn.de>
OSX and Windows ports 2012-2013 by Yves Sablonier and Geoff R. McLane, resp.
Version 3.1.0 compiled Mar 2 2014, at 00:21:19
Using iaxclient library Version SVN 261

OPTION DESCRIPTION

-d, -debug, --debug= show debugging information
-S, -voipserver, --voipserver= voip server to connect to (default: 'fgcom.flightgear.org')
-s, -fgserver, --fgserver= fg to connect to (default: 'localhost')
-p, -port, --port= where we should listen to FG (default: '16661')
-a, -airport, --airport= airport-id (ICAO) for ATC-mode
-f, -frequency, --frequency= frequency for ATC-mode
-C, -callsign, --callsign= callsign to use (default: 'guest')
-U, -user, --user= username for VoIP account (default: 'guest')
-P, -password, --password= password for VoIP account (default: 'guest')
-i, -mic, --mic= mic input level (0.0 - 1.0)
-o, -speaker, --speaker= speaker output level (0.0 - 1.0)
-b, -mic-boost, --mic-boost= enable mic boost
-t, -silence-threshold, --silence-threshold= set silence threshold (-60.0 - 0.0)
-l, -list-audio, --list-audio= list audio devices
-r, -set-audio-in, --set-audio-in= use <devicename> as audio input
-k, -set-audio-out, --set-audio-out= use <devicename> as audio output
-c, -codec, --codec= use codec <codec> as transfer codec (default: 'u')
-T, -positions, --positions= location positions file (default: '/usr/share/flightgear/positions.txt')
-Q, -special, --special= location spl. frequency file (opt) (default: '/usr/share/flightgear/special_frequencies.txt')

Available codecs:
u - ulaw (default and best codec because the mixing is based onto ulaw)
a - alaw
g - gsm
s - speex
7 - G.723

Mode 1: client for COM1 of flightgear:
$ fgcom
- connects fgcom to fgfs at localhost:16661
$ fgcom -sother.host.tld -p23456
- connects fgcom to fgfs at other.host.tld:23456

Mode 2: client for an ATC at <airport> on <frequency>:
$ fgcom -aKSFO -f120.500
- sets up fgcom for an ATC radio at KSFO 120.500 MHz

Note that fgcom starts with a guest account unless you use -U and -P!

Also note that the current server (fgcom.flightgear.org) works with guest account, so '''do not use -U or -P'''

== Server installation ==
{{Main article|Howto: Set up a FGCom server}}
Main FGCom server fgcom.flightgear.org hosted by F-JJTH (contact on forum, IRC, mailing list)

== External links ==
* [http://sourceforge.net/projects/fgcom/ fgcom(SourceForge-Project)] Subversion is [http://fgcom.svn.sourceforge.net/ available here]. If you haven't used Subversion before, you might find it easier to fetch a [http://fgcom.svn.sourceforge.net/viewvc/fgcom/?view=tar archive] instead.
* latest source available here (?): http://code.google.com/p/fgcomgui/

=== Deprecated or broken links ===
* [http://squonk.abacab.org/dokuwiki/fgcom Old Official website]
* [http://squonk.abacab.org/dokuwiki/fgcom-manual Manual]

== Status ==
* '''October, 2013:'''
FGCom standalone is now part of FlightGear release ( two release per year, same version number policy)

FGCom standalone is available at http://fgcom.flightgear.org/download

* '''August, 2013:'''
FGCom has been integrated into FlightGear

'''New FGCom server : fgcom.flightgear.org''' ( ATIS message record, backward compatibility with old/wrong frequencies, ready for 8.33KHz spacing frequency, new dialplan using last data from X-Plane)

* '''March, 2009:'''
Adding User-Information for installing, using, maintaining FGCOM on different platforms.

* '''18 November, 2008:'''
Latest SVN (rev 163) has the compile problems fixed. Also we have a new server: fgcom.flightgear.org.uk. User accounts not required (ie. do '''not''' use -U or -P)

* '''31 October, 2008:'''

The latest SVN release at this time is the '''r149''' which does not compile due to a constant that is not defined (STL_STRING). Such constant appears at line 57 in the file ''src/fgcom_init.cpp'' which is:
''#include STL_STRING''

I guess that such constant must point to the STL library include file but I am not sure.
I revert to the '''r148''' SVN version which successfully compiles.

Command to get such version is: ''svn co -r148 svn://svn.dfn.de:/fgcom/trunk fgcom-r148''

* '''19 June, 2008:''' Currently the server is down due to hardware problems. It is unknown when the service comes back because he currently has no time to fix the problems.

* '''22 November 2007:''' Due to heavy development at this time there may be some differences between the information on the web pages and the installation. Please follow the discussions on the FlightGear development list!

== Related content ==
* [[FlightGear related projects]]
* [[FGComGui]]

== External link ==
* [http://sourceforge.net/projects/fgcom/ Old repository] at sourceforge

[[Category:FGCom| ]]
[[Category:Multiplayer]]

[[fr:FGCom]]

FGCom 3.0

2015-01-01T18:20:28Z

F-JJTH: /* Options details */ update doc for FGCOM 3.4

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# You can also check that your PTT works fine looking at the "PTT test" checkbox when you press your PTT button (default is spacebar)
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Echo test : check/uncheck this for testing server communication (Echo-Box)
* PTT test : when you press your PTT this checkbox will be checked
* Speaker volume : set speaker volume for FGCom built-in
* Silence threshold : set the limit, in dB, when FGCom consider no voice in your microphone
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Originating an audio only call
Call 0 accepted
Echo Box - For testing FGCOM
Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "--help" argument will show you all the available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

''' I'm using Linux and I can't get FGCom working '''

Please read this page which has a lot of information about audio configuration for Linux user, even some specific reference to FGCom: [[Linux software audio mixing with FlightGear]]

[[fr:FGCom 3.0]]
[[Category:FGCom]]

FGCom 3.0

2015-01-01T18:17:37Z

F-JJTH: /* Dialog details */ update doc for FG 3.4

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# You can also check that your PTT works fine looking at the "PTT test" checkbox when you press your PTT button (default is spacebar)
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Echo test : check/uncheck this for testing server communication (Echo-Box)
* PTT test : when you press your PTT this checkbox will be checked
* Speaker volume : set speaker volume for FGCom built-in
* Silence threshold : set the limit, in dB, when FGCom consider no voice in your microphone
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Originating an audio only call
Call 0 accepted
Echo Box - For testing FGCOM
Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "-h" argument will show you all available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

''' I'm using Linux and I can't get FGCom working '''

Please read this page which has a lot of information about audio configuration for Linux user, even some specific reference to FGCom: [[Linux software audio mixing with FlightGear]]

[[fr:FGCom 3.0]]
[[Category:FGCom]]

File:FGCom dialog.png

2015-01-01T18:12:23Z

F-JJTH: F-JJTH uploaded a new version of "File:FGCom dialog.png"

=={{int:filedesc}}==
{{Information
|description={{en|1=FGCom dialog available in FG >= 2.99.0}}
|date=2013-08-19 16:57:43
|source={{own}}
|author=[[User:F-JJTH|Clément de l'Hamaide]]
|permission=
|other_versions=
|other_fields=
}}
{{Location dec|0|0}}

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

[[Category:FGCom]]

Howto:Install aircraft

2014-12-28T09:09:24Z

F-JJTH: /* Linux */

{{installing}}

The latest official [[aircraft]] can be downloaded at [http://www.flightgear.org/download/aircraft-v3-2/ FlightGear.org Aircraft], which then usually require unzipping software to extract from a compressed file format. Then these must be manually installed in a FlightGear software installation to use. The details depend on the method of download, operating system, and user setup.

An open source file archiver is [http://www.7-zip.org/ 7-Zip], although be aware of user setup.

== Installation process ==
=== Linux ===
(Ubuntu 12.04)
# Download the aircraft
# Create a directory to store your aircraft if you have not already done so. Make sure this directory is outside <tt>/usr/share/games/flightgear/</tt>. For example, use <tt>/home/{YourUserName}/FlightGear/Aircraft</tt>.
# Extract your aircraft file into the folder (the one you created above)
#: unzip XXXXX.zip
# Start up FlightGear. Append the root aircraft folder (<tt>/home/{YourUserName}/FlightGear/Aircraft</tt> in our example) to the $FG_AIRCRAFT list on the first page (previous to aircraft selection) of the launcher. Your aircraft should now show up in the list.

=== Macintosh OS X ===
# Open GUI Launcher for FlightGear Mac
# Click on "Others" tab at middle right of launcher
# Click "Install Add-On Data" link at bottom of launcher
# Select aircraft folder from menu, and click "Open"
# Click OK on pop-up box.

Please note: For Mac users, the above will not work if you have not installed FG to the applications folder. If you do not want to put your version of FG in your applications folder, you can place it in a separate folder of your own creation. That will allow the above aircraft (& scenery) installation method to work correctly/

=== Windows ===
# Download an aircraft and save it on your desktop.
# Unzip the file using a file archiver, like for example 7-Zip.
# Create a directory to store your aircraft if you have not already done so. Make sure this directory is outside your <tt>[[$FG_ROOT]]</tt> directory. For example, use <tt>C:/Users/{YourUserName}/Documents/FlightGear/Aircraft</tt>.
# Move the unzipped folder (usually the aircraft's name) to your that aircraft directory.
# Start up FlightGear. Append the root aircraft folder (<tt>C:/Users/{YourUserName}/Documents/FlightGear/Aircraft</tt> in our example) to the [[$FG_AIRCRAFT]] list on the first page (previous to aircraft selection) of the launcher. Your aircraft should now show up in the list.

== When installing an aircraft fails ==
=== XML files with wrong encoding ===
If you start FlightGear with the new plane you installed and there is no cockpit or exterior, this may be because the XML files are in the wrong encoding.

To fix this on Linux try this:

$ cd path/to/aircraft/directory/
$ find . -name "*.xml" -print | xargs sed -i 's/<?xml version="1.0" encoding="UTF-8"?>/<?xml version="1.0" encoding="ISO-8859-1"?>/g'

=== The aircraft folder have to be renamed ===
If you start FlightGear with the aircraft you installed it is invisible or if FlightGear will not start with your newly installed aircraft, but will start with other aircraft you might need to rename the aircraft folder.

If there is a readme file have a look there for instructions, otherwise try change to more obvious names like renaming for example "A320-master" to "A320" or "boeing-707" to "707". If that does not work ask around on the [[Howto:Multiplayer#Multiplayer chat|multiplayer chat]], [[FlightGear IRC channel|IRC]] or on the [http://forum.flightgear.org/viewforum.php?f=11 forum].

== Choosing aircraft ==
If you are looking for information to decide what aircraft to download, try:
* [[Aircraft]]
* [[Helicopter]]
* [[Vehicle]]
* [[Table of models]]
External links to third party aircraft can be found at [[FlightGear hangars]]. Remember that the latest aircraft may not load with previous versions. If you happen to use an older version of FlightGear, look for older aircraft in the links section.

== For developers ==
Help develop the [[FlightGear Package Manager]] which is intended to support automatic aircraft and scenery installation, currently in alpha development and in need of testing.

== Related content ==
* [[Installing Scenery]]

[[Category:Howto|Install aircraft]]

[[fr:Howto Installer un avion]]

Project Rembrandt

2014-10-19T19:32:53Z

F-JJTH: /* Implementation */

== Why this name ? ==
[http://en.wikipedia.org/wiki/Rembrandt Rembrandt] was a dutch painter living in the 17th century, famous as one of the master of [http://en.wikipedia.org/wiki/Chiaroscuro chiaroscuro].

This project is about changing the way [[FlightGear]] renders lights, [[shadows]] and shades, and aims at making Rembrandt painting style possible in FG.

{{forum|47|Effects & Shaders}}

== Status (07/2014) ==
For the time being, Rembrandt's main developer (FredB) is not actively involved in FlightGear, and Rembrandt must be considered "unmaintained" currently. However, there are 2-3 overlapping efforts, some of which were discussed on the developers mailing list. First of all, there's Zan's newcamera branch, which has never been merged with FlightGear, but which exposes FlightGear's rendering pipelines to XML/fgdata space via the effects framework - which basically means that large portions of Rembrandt could be moved out of the C++ code back into GLSL/effects space, which is something that was originally discussed by a few core developers. This has never materalized, because Zan's work took place pretty much at the same time when Rembrandt was being developed. Likewise, some technical challenges could be easily addressed by exposing each rendering stage to a [[Canvas]] texture, which would mainly require two new features: 1) [[Canvas_Development#Supporting_Cameras|supporting camera views as a new Canvas::Element]], and 2) [[Canvas_Development#Effects_.2F_Shaders|supporting effects/shaders]] per Canvas/Element.
From then on, most [[Howto:Use_a_Camera_View_in_an_Instrument|Rembrandt-like functionality, including mirror views, tail cameras or FLIR-like processing]], could be fully implemented and maintained by fgdata contributors familiar with the effects framework and shaders, without necessarily being specific to just deferred rendering:

{{FGCquote
|Personally, I see the potential of deferred rendering, but if it ends up with 15 fps on a gaming rig, then that's what it's going to remain - potential waiting for the next or next-to-next hardware generation. For me personally, real secondary light sources and shadows aren't a big deal. They're important on the ground, at an airport, but I'm usually flying. 
 
Self-shadowing of the terrain can be done in 90% of the cases accurately without Rembrandt because the terrain is rarely that steeply sloped, and the interesting other shadows in nature - clouds and trees - can't be done by Rembrandt in any case.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=204372#p204372
|title=<nowiki>Re: A long shot</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Thu Mar 27</nowiki>
}}
}}

{{FGCquote
|Rembrandt is just one particular (and experimental) implementation of deferred rendering implemented via FlightGear - when running other simulators/games -with comparable scenes (not necessarily 400km of visibility!)- you'll see that performance isn't typically that much affected. So I guess there's nothing wrong about Rembrandt per se, but it just isn't very optimized at the moment, and it not being maintained doesn't really help. A few weeks ago when we exchanged screen shots and Rembrandt stats, there were apparently a few low-hanging fruits, and Rembrandt was obviously doing stuff that wasn't really necessary (e.g. computing shadows at night time without any light sources within 50km...)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=204374#p204374
|title=<nowiki>Re: A long shot</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Mar 27</nowiki>
}}
}}

{{FGCquote
|The situations I'm aware of were deferred rendering is used are frequently first person shooters. From the ground, where you have plenty of objects obscuring each other, deferred rendering would give you a pronounced boost in framerate as you spend minimal time with vertices you're not going to see. That advantage never really materializes for a flightsim. 
 
Imo, what makes our performance in comparison worse than other software where a large scene is rendered is the lack of a terrain LOD system. Our vertex count just explodes at high visibility. 
 
I mean, FredB obviously spent quite some time with Rembrandt. If someone can make it run much faster, than that'd change the game, but so far we have mostly talk.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=204375#p204375
|title=<nowiki>Re: A long shot</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Thu Mar 27</nowiki>
}}
}}

{{FGCquote
|Given how FlightGear has evolved over time, not just regarding effects/shaders, but also complementary efforts like deferred rendering (via rembrandt), we'll probably see cameras (and maybe individual rendering stages) exposed as Canvases, so that there's a well-defined interface for hooking up custom effects/shaders to each stage in the pipeline - Zan's newcamera work demonstrates just how much flexibility can be accomplished this way, basically schemes like Rembrandt could then be entirely maintained in XML/effects and shader (fgdata) space. 
And even the fgviewer code base could be significantly unified by just working in terms of canvases that deal with camera views, which also simplifies serialization for HLA.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216741#p216741
|title=<nowiki>Re: create window</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Aug 16</nowiki>
}}
}}
{{FGCquote
|So we would need to extend CanvasElement then to support effects - according to some of your postings, you played with that already a while ago using code from SGMaterialAnimation apparently, as in 2 years ago ? Is that something that we should reuse ? 
 
Specifically, I've been in touch with some of our effects/shader guys, and we're wondering if we could directly register a Canvas/Effects texture as a texture available to effects, which is something that Thorsten and Tim talked about a while ago, being a limitation in effects that they would like to get rid of
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=201852#p201852
|title=<nowiki>Re: </nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Feb 25</nowiki>
}}
}}

{{FGCquote
|this all predates Canvas - but if we could not just support glsl/effects in Canvas, but also expose those canvas textures to the effects system, that would bring a lot of possibilities
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=201852#p201852
|title=<nowiki>Re: </nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Feb 25</nowiki>
}}
}}

{{FGCquote
|regarding Rembrandt in particular, we are only missing 2-3 [[Canvas]] enhancements to allow effects/shader guys to pick up where FredB left off - which are primarily,
# camera support
# effects/shader support

And people have this working in various stages already, sometimes unrelated to [[Canvas]] (Zan's newcameras branch), and sometimes not yet fully integrated (e.g. the shader stuff). But generally it is foreseeable that additional rendering schemes (deferred rendering) could then be implemented by people without having to touch any C++ code.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=204338#p204338
|title=<nowiki>Re: A long shot</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Mar 26</nowiki>
}}
}}

{{FGCquote
|So, it's not really Rembrandt that's the issue here, the bottleneck is the number of active expert C++ developers (you cannot really touch the 3D parts of the simulator with "just" C++ knowledge, you also need strong maths skills and OpenGL/OSG 3D rendering experience), especially once they're no longer around to help integrate their code and if there's little documentation to help newcomers maintain their code, because that's when base package development is often taking over eventually.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

{{FGCquote
|For example, I think it's pretty safe to say that the Canvas system was never intended to "compete" with Rembrandt, and most people here will be wondering how it could possibly be competing at all ? But ultimately it really is an integration and accessiblity issue, too. Admitedly, you need to be familiar with the way the project works to foresee what could be happening here, but it's not really far-fetched at all: 
 
I had a quick look, and according to the initial Rembrandt commits by FredB, they were all about decoupling rendering into multiple stages and doing offscreen rendering to textures. This is also supported by the wiki and the initial Rembrandt discussions on the devel list. So far, straightforward to understand - even without knowing any GLSL. 
 
So basically it's about decoupling each rendering step and rendering each stage to a separate offscreen texture, and then it's mostly about exposing each rendering step/stage to the effects/GLSL framework for further processing there. 
 
Rembrandt obviously predates the Canvas system, but these days that's exactly what the Canvas is good at: offscreen rendering to an osg::Image, without having to touch any C++ code, and without having to build FlightGear from source. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

{{FGCquote
|Tim Moore (developer of the effects framework) did mention several times how it would be great to extend the effects framework to allow arbitrary textures to be used as inputs/outputs for the effects frame. For example, see: [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37873.html http://www.mail-archive.com/flightgear- ... 37873.html] 
 
So consider a Canvas texture as the potential input/output for an effect, and there you have it: Canvas + effects/shader {{=}}> one important ingredient for a Canvas-based Rembrandt port.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

{{FGCquote
|we also have dozens of feature requests from aircraft developers to allow scenery views to be rendered as cockpit textures, e.g. to render mirrors or tail camera images. A feature also commonly seen on FSX and XPlane. 
Several years ago, Zan made lots of progress doing this sort of thing, long before the Canvas again - so it's also an integration issue. 
 
These days, this would require the view_mgr code to be adapted and turned into a Canvas::Element. For example, see: 
[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36673.html http://www.mail-archive.com/flightgear- ... 36673.html] 
[[Howto:Use_a_Camera_View_in_an_Instrument]] 
 
Other aircraft developers have asked for effects/GLSL being available to cockpit textures for other reasons, e.g. to implement night vision views/FLIR imagings. And supporting effects/shaders in Canvas has been discussed various times on the forum too. 
 
So, these are just two new features: 1) making effects/GLSL usable to Canvas textures and 2) rendering scenery views - and suddenly you have two major ingredients for a deferred shading scheme in place, without requiring extensive C++ changes, and without necessarily having to even look at Rembrandt ...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

{{FGCquote
|I don't think that anybody is working on replacing Rembrandt, but I also don't think that we have any active core developers who could easily help maintain Rembrandt (except for FredB obviosuly) - still it is foreseeable that the Canvas system will -eventually- provide all essential building blocks to allow deferred rendering to be built on top, it's really just a matter of time. 
 
At that point revisiting the Rembrandt code and moving its rendering stages into cascaded Canvas textures that make use of scenery views and effects/shaders with an osgViewer-based placement, would be straightforward for any GLSL developer, much more so than getting to grips with the underlying Rembrandt C++ code itself. 
 
So, nobody is working on revamping/replacing Rembrandt, but even if it were to continue to be stalled, the idea could still evolve - C++ templates were also never intended to be turing-complete, it just happened by accident :lol: 
 
As we know, even for good ideas, it usually takes ~3-5 years for them to be implemented (remember: OSG port, Rembrandt, Canvas etc). 
 
So I still wouldn't hold my breath. But re-considering the way Rembrandt is done and integrating it with the Canvas system would help make it less obscure and more accessible to effects/GLSL developers, especially for times when there are no C++/3D experts around.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

== What is it ? ==
The idea driving the project is to implement [http://en.wikipedia.org/wiki/Deferred_shading deferred rendering] inside FlightGear.
From the beginning FlightGear had a forward renderer that tries to render all properties of an object in one pass (shading, lighting, fog, ...), making it difficult to render more sophisticated shading
(see the [[FlightGear Newsletter December 2011#Shaders|'Uber-shader']]) because one has to take into account all aspects of the [http://www.wired.com/magazine/2010/07/st_equation_3danimation/ rendering equation].

[[Image:project_rembrandt_1.png|thumb|300px|Main view with the content of buffers displayed at corners]]
On the contrary, deferred rendering is about separating operations in simplified stages and collecting the intermediary results in hidden buffers that can be used by the next stage.

;First stage is the Geometry Stage :
: we render all the scene into 4 textures, using multi render targets, to do it in one pass: one for the depth buffer, one for the normals (lower left of the image), one for the diffuse colors (lower right) and one for the specular colors (upper right).

;Next stage is the Shadow Stage :
: we render the scene again into a depth texture from the point of view of the lights. There will be one texture for every light casting shadows.

;Then comes the Lighting Stage, with several substages :
:*Sky pass: the sky is first drawn using classical method.
:*Ambient pass: the diffuse buffer is modulated with the ambient color of the scene and is drawn as a screen-aligned textured quad
:*Sunlight pass: a second screen aligned quad is drawn and a shader computes the view position of every pixel to compute its diffuse and specular color, using the normal stored in the first stage. The resulting color is blended with the previous pass. Shadows are computed here by comparing the position of the pixel with the position of the light occluder stored in the shadow map.
:*Fog pass: a new screen aligned quad is draw and the position of the pixel is computed to evaluate the amount of fog the pixel has. The fog color is blended with the result of the previous stage.
:*Additional light pass: the scene graph will be traversed another time to display light volumes (cone or frusta for spot lights, sphere for omni-directional lights) and their shader will add the light contributed by the source only on pixels receiving light.
:*Transparent objects pass: transparent objects (and clouds) are finally rendered using classical method.

:All lighting computations are accumulated in a single buffer that will be used for the last stage, in addition of the one computed by the Geometry stage.

;In the end, the Display Stage, with optional Post-Processing effect :
:The results of the previous buffers are pushed to the main framebuffer to be displayed, optionally modified to show Glow, Motion blur, HDR, redout or blackout, screen-space ambient occlusion, anti-aliasing, etc...

In FG, we end the rendering pipeline by displaying the [[Menubar|GUI]] and the [[HUD]].

All these stages are more precisely described in this [http://bat710.univ-lyon1.fr/~jciehl/Public/educ/GAMA/2007/Deferred_Shading_Tutorial_SBGAMES2005.pdf tutorial] that is the basis of the current code, with some addition and modifications.

C++ developers interested in learning more about how Rembrandt works, will want to look at these initial $FG_SRC commits (note that the viewer related sources are now to be found in $FG_SRC/Viewer):
* 94e3ae4c675463c358071e1d9da8de583cf56e15
* 6b008126b5fd99c38778c6293c15f9721a4fa509
* 64e3e98069fb2310311687b9f099b338b8b375a5
* bb16463d631a8d87310a54a573966eb1cca813e6

== Caveats ==
Deferred rendering is not able to display transparency. For the moment, clouds are renderer separately and should be lit and shaded by their own. Transparent surfaces are alpha-tested and not blended. They would have to be drawn in their own bin over the composited image.

It also don't fit with depth partitioning because the depth buffer should be kept to retain the view space position, so for the moment, z-fighting is quite visible. Depth partitioning with non overlapping depth range might be the solution and should be experimented at one point.

The glow pass can make certain MFD (that use emissive color) unreadable because blurred. Should be treated as transparent.

== Implementation ==
=== Repositories ===
The code is in the main branch of the [[FlightGear and Git|official repository]]. Any other location is not maintained anymore.

=== Rendering of transparent surfaces ===
[[Image:project_rembrandt_5.png|thumb|300px|Transparent surfaces drawn after opaque objects]]
Transparent surfaces are detected by OSG loader plugins and their state set receive the TRANSPARENT_BIN rendering hint. In the culling pass, the cull visitor orders transparent surfaces in transparent bin. In a cull callback attached to the Geometry camera, after the scenegraph traversal, the transparent bins are removed from the render stage and saved in a temporary collection. In a cull callback attached to the Lighting camera, after the scenegraph traversal, the transparent bins saved at the previous stage, are added to the render stage of the Lighting camera with a high order num. That way, the transparent surface are drawn on top of the scene lighted from the Gbuffer.

=== Memory consumption ===
For each camera defined in the camera group, there is a separate shadow map, so the video memory usage is :
* G-buffer and Lighting buffer: 20 bytes per pixel. For an HD screen (1920x1080) memory requirement is 40 Mb
* Shadow map: 3 x shadow_map_size x shadow_map_size bytes (if size is 8192, whole map size is 192 Mb
Not counting textures, display list or vertex buffers for models and terrain

3 HD screens require 120 Mb of memory for the buffers (shadow excluded), you're asking 3x8192x8192x3 = 576 Mb (megabytes) of memory for the shadows alone.

If you are seeing error messages during startup or FlightGear doesn't start up properly, it's probably because you don't have enough free video memory. Reduce the size of the shadow map in preferences.xml by locating

<syntaxhighlight lang="xml">
<map-size type="int">8192</map-size>
</syntaxhighlight>

And put 4096 or 2048 instead.
You can also use a startup parameter: --prop:/sim/rendering/shadows/map-size=2048

=== Configurable pipeline ===

The Rembrandt renderer uses an XML file to setup its pipeline for each viewport described in the camera group. This file describes the way the intermediary buffers are setup and how the different rendering stages are sequenced. The general outline of a pipeline file is as follow :

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>

<buffer>

</buffer>
<buffer>

</buffer>


<stage>

</stage>
<stage>

</stage>
</PropertyList>
</syntaxhighlight>

==== Buffers ====
A buffer is a texture used as a storage area in the GPU. It's size is usually a multiple of the screen size, but fixed size is supported (typical for shadow map). The description of a buffer is described below :

<syntaxhighlight lang="xml">
<buffer>
<name>buffer-name</name>
<internal-format>rgba8</internal-format> 
<source-format>rgba</source-format> 
<source-type>unsigned-byte</source-type> 
<width>screen</width> 
<height>screen</height> 
<scale-factor>1.0</scale-factor>
<wrap-mode>clamp-to-border</wrap-mode> 

<shadow-comparison>true</shadow-comparison>

<condition>

</condition>
</buffer>
</syntaxhighlight>

==== Stages ====
A stage is an unit of rendering to a group of buffer. Most stages are predefined and their type is not free. When a type is not specified, the name is used. Stage types are :
{| class="wikitable"
!align="left"| Stage type
!align="left"| Purpose
|-
|geometry
|The geometry stage initialize most of the buffers and works on the real objects and geometry. Transparent objects are set aside and will be used untouched in the lighting stage. Other opaque geometry is rendered with the standard effects that do the hard work to put sensible data in the buffers.
|-
|shadow
|In this stage, the geometry is rendered in the normal map from the perspective of the sun.
|-
|lighting
|This stage uses the buffers filled by the previous stages to light every pixel of the scene. The result is rendered in another buffer to allow post effects.
|-
|fullscreen
|Stages of this type are used to alter the whole scene or transform data from a particular buffer.
|-
|display
|Final rendering of the scene to the screen or the texture defined in the camera group.
|}

A stage description is outlined below :
<syntaxhighlight lang="xml">
<stage>
<name>stage-name</name>
<type>stage-type</type> 
<order-num>-1</order-num>
<effect>Effects/fullscreen-effect</effect> 
<needs-du-dv>true</needs-du-dv> 
<scale-factor>0.25</scale-factor> 


<condition>

</condition>

<attachment>

</attachment>
<attachment>

</attachment>


<pass>

</pass>
<pass>

</pass>
</stage>
</syntaxhighlight>
Stages render in buffers (except for the display stage). Attachments describe which buffers are affected by each stage.

===== Attachments =====
Attachment describe bindings between buffer and attachment point :
<syntaxhighlight lang="xml">
<attachment>
<component>color0</component> 
<buffer>buffer-name</buffer>

<condition>

</condition>
</attachment>
</syntaxhighlight>

===== Passes =====
Passes are only available in the <tt>lighting</tt> stage. Three kind of stage are allowed :

{| class="wikitable"
!align="left"| Pass type
!align="left"| Purpose
|-
|sky-clouds
|Renders the skydome, sun, moon, planet, stars and clouds
|-
|lights
|Renders additional spot and point lights
|-
|fullscreen
|Fullscreen pass analog to a fullscreen stage except that it renders in the buffers attached to the lighting stage
|}
A pass is defined like below :
<syntaxhighlight lang="xml">
<pass>
<name>pass-name</name>
<type>pass-type</type> 
<order-num>-1</order-num>
<effect>Effects/fullscreen-effect</effect> 


<condition>

</condition>
</pass>
</syntaxhighlight>

A typical lighting stage is a succession of 5 passes :
# <tt>sky-clouds</tt> pass
# <tt>fullscreen</tt> pass for ambient light
# <tt>fullscreen</tt> pass for sun light (and shadows)
# <tt>lights</tt> pass
# <tt>fullscreen</tt> pass for fog

Each effect attached to the fullscreen passes define the way blending is done between the pass and the previous accumulation of render.

=== C++ implementation ===

On the C++ side, Rembrandt is set up in those steps:

* ''buildRenderingPipeline()'' is the last common function between forward rendering and deferred rendering. That's the point of start for specific deferred stuff. In this function we call ''buildDeferredPipeline()''
** ''buildDeferredPipeline()'' is just a wrapper for ''buildCameraFromRenderingPipeline()''
*** ''buildCameraFromRenderingPipeline()'' is where we initialize all buffers and create all the stages found in ''Effects/default-pipeline.xml'' with the call to ''buildBuffers()'' and ''buildStage()''
**** ''buildBuffers()'' is where we ask to build each buffer with the call to ''buildDeferredBuffer()''
***** ''buildDeferredBuffer()'' create a 2D texture
**** ''buildStage()'' is where we ask to build each camera depending on the type of the stage (geometry, lighting, shadow, fullscreen, display) with the call to ''buildDeferred*Camera()'' (where * is the stage type)
***** ''buildDeferred*Camera()''is where we build the camera, for each camera we attach the required buffers with the call to ''buildAttachments()''.
****** ''buildDeferredGeometryCamera()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]
****** ''buildDeferredShadowCamera()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]
****** ''buildDeferredLightingCamera()'' Only for the lighting camera (''buildDeferredLightingCamera()'') we have to build passes who is called with ''buildPass()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]
****** ''buildDeferredFullscreenCamera()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]
****** ''buildDeferredDisplayCamera()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]

== Running Flightgear with Rembrandt ==
[[File:Rembrandt dialog.png|thumb|270px|Rembrandt dialog]]
The Rembrandt renderer is now integrated in the main repository but needs to be enabled to run. There are two ways to enable it (only one is needed!):
* <code>--enable-rembrandt</code> (when using [[FGRun]], you may add this behind the <tt>FG_EXECUTABLE</tt> on the first page).
* <code>--prop:/sim/rendering/rembrandt/enabled=true</code> (with FGRun this can be added via <tt>Advanced > Properties</tt> on the last page, but only the <code>/sim/rendering/rembrandt/enabled=true</code> part).

The <tt>View > Rendering Options > Rembrandt Options</tt> dialog allows you to toggle and adjust the various features that Rembrandt offers.

Rembrandt is quite demanding in GPU resources and may fail to run with the default options. The more frequent symptom is an OSG message in the console :

RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6
Warning: RenderStage::runCameraSetUp(State&) Pbuffer does not support multiple color outputs.

The ssao effect provided in v2.8.0 may generate these messages, more often on Mac :

<pre>
FRAGMENT glCompileShader "/Users/xxxx/Desktop/FlightGear.app/Contents/Resources/../Resources/data/Shaders/ssao.frag" FAILED
FRAGMENT Shader "/Users/xxxx/Desktop/FlightGear.app/Contents/Resources/../Resources/data/Shaders/ssao.frag" infolog:
ERROR: 0:20: 'array of 2-component vector of float' : constructor not supported for type
ERROR: 0:20: 'array of 2-component vector of float' : no matching overloaded function found
ERROR: 0:20: 'const 2-component vector of float' : cannot declare arrays of this type
ERROR: 0:20: 'v' : redefinition
ERROR: 0:55: 'reflect' : no matching overloaded function found
ERROR: 0:55: '=' : cannot convert from 'float' to '2-component vector of float'

glLinkProgram "" FAILED
Program "" infolog:
ERROR: One or more attached shaders not successfully compiled
</pre>
In that case, disable ambient occlusion with the command :
<tt>--prop:/sim/rendering/rembrandt/ambient-occlusion-buffers=false</tt>

There is a number of additional options that can help to avoid these problems :

{| class="wikitable"
|<tt>--prop:/sim/rendering/rembrandt/use-color-for-depth=true</tt>
|Some old NVidia cards, such as 7600GT, don't give enough resolution for depth and that result in "fog curtains" at few meters from the viewer. One trick is to encode depth in another texture and get the proper value afterward. This option enables that.
|-
|<tt>--prop:/sim/rendering/shadows/enabled=false</tt>
|Disable shadows altogether.
|-
|<tt>--prop:/sim/rendering/shadows/num-cascades=1</tt>
|Set <tt>/sim/rendering/shadows/cascade-far-m[0]</tt> to change the shadow map range. The more the range, the less the resolution (default value is 5 meters)
|-
|<tt>--prop:/sim/rendering/shadows/map-size=<power-of-two></tt>
|Set the shadow map size. Useful values are 1024, 2048, 4096 or 8192. Few cards have the resources to support 16384.
|-
|<tt>--prop:/sim/rendering/shadows/num-cascades</tt>
|Set the shadow map cascade number. Less cascades means less time spent in shadow map generation, but also means lower shadow quality. Integer between 1 and 4.
|-
|<tt>--prop:/sim/rendering/shadows/cascade-far-m[i]</tt>
(1 <= i <= <tt>/sim/rendering/shadows/num-cascades</tt> <= 4)
|Set the shadow map cascade range for each cascade. Default values are 5m, 50m, 500m and 5000m for 4 cascades.
|-
|<tt>--prop:/sim/rendering/rembrandt/no-16bit-buffer=false</tt>
|By default, Rembrandt uses 8 bit buffers for normals (so the property is set to true by default). This may create banding artifacts on specular highlights. If it's unacceptable and the GPU supports it, set to false to have better precision for normals and effects relying on normal direction.
|}

== Guidelines for shader writers ==
=== Predefined uniforms ===
These glsl uniforms don't need to be declared in the effect file.
{| class="wikitable"
!Name
!Type
!Purpose
|-
|<tt>fg_ViewMatrix</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix used to transform the screen position to view direction
|-
|<tt>fg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix inverse used to transform the screen position to view direction
|-
|<tt>fg_ProjectionMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, projection matrix inverse used to transform the screen position to view direction
|-
|<tt>fg_CameraPositionCart</tt>
|<tt>vec3</tt>
|Position of the camera in world space, expressed in cartesian coordinates
|-
|<tt>fg_CameraPositionGeod</tt>
|<tt>vec3</tt>
|Position of the camera in world space, expressed in geodesic coordinates (longitude in radians, latitude in radians, elevation in meters)
|-
|<tt>fg_SunAmbientColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_SunDiffuseColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_SunSpecularColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_SunDirection</tt>
|<tt>vec3</tt>
|
|-
|<tt>fg_FogColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_FogDensity</tt>
|<tt>float</tt>
|
|-
|<tt>fg_ShadowNumber</tt>
|<tt>int</tt>
|
|-
|<tt>fg_ShadowDistances</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_DepthInColor</tt>
|<tt>bool</tt>
|Tells if the depth is stored in a depth texture or a color texture
|-
|<tt>fg_Planes</tt>
|<tt>vec3</tt>
|Used to convert the value of the depth buffer to a depth that can be used to compute the eye space position of the fragment
|-
|<tt>fg_BufferSize</tt>
|<tt>vec2</tt>
|Dimensions of the buffer, used to convert gl_FragCoord into the range [0..1][0..1]
|-
|<tt>osg_ViewMatrix</tt>
|<tt>mat4</tt>
|Defined by OSG, used only when working on actual geometry
|-
|<tt>osg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|Defined by OSG, used only when working on actual geometry
|}
They still have to be declared in the fragment or the vertex shader to be used.

=== Utility functions ===

To ease the maintenance of shaders, several utility functions are available for the fragment shader. These functions are put together in two files : <tt>gbuffer-functions.frag</tt> and <tt>gbuffer-encode.frag</tt>.

==== gbuffer-encode.frag ====

;<tt>void encode_gbuffer(vec3 normal, vec3 color, int mId, float specular, float shininess, float emission, float depth)</tt>
:Used to encode all the values of the G-Buffer in material shaders

==== gbuffer-functions.frag ====

;<tt>vec2 normal_encode(vec3 n)</tt>
:Used to compress normals into the G-Buffer in material shaders. Normally called from <tt>encode_gbuffer()</tt>

;<tt>vec3 normal_decode(vec2 enc)</tt>
:Reconstruct normals from the G-Buffer. Used in fullscreen shaders and light shaders

;<tt>vec3 float_to_color(in float f)</tt>
:Encode float values in the range [0..1] in the 24 bits of a color. This function is used by <tt>encode_gbuffer()</tt> if the <tt>/sim/rendering/use-color-for_depth</tt> is true, for old cards that don't provide depth information with enough resolution inside fullscreen or light shaders.

;<tt>float color_to_float(vec3 color)</tt>
:Decode float values in the range [0..1] from the 24 bits of a color. This function is used by <tt>position()</tt> if the <tt>/sim/rendering/use-color-for_depth</tt> is true, for old cards that don't provide depth information with enough resolution inside fullscreen or light shaders.

;<tt>vec3 position( vec3 viewDir, float depth )</tt>
:Reconstruct eye space position from the view direction and the depth read from the depth buffer

;<tt>vec3 position( vec3 viewDir, vec3 depthColor )</tt>
:Reconstruct eye space position from the view direction and the depth encoded in a color read from the depth buffer

;<tt>vec3 position( vec3 viewDir, vec2 coords, sampler2D depth_tex )</tt>
:Reconstruct eye space position from the view direction and the depth buffer (real depth or color, according to the value of <tt>/sim/rendering/use-color-for_depth</tt>) at a given fragment on screen, given by <tt>coords</tt>

==== Usage ====

For material shaders, it is necessary to provide both <tt>gbuffer-functions.frag</tt> and <tt>gbuffer-encode.frag</tt> in the effect file, like this :

<syntaxhighlight lang="xml">
<program>
<vertex-shader>Shaders/ubershader.vert</vertex-shader>
<fragment-shader>Shaders/ubershader-gbuffer.frag</fragment-shader>
<fragment-shader>Shaders/gbuffer-functions.frag</fragment-shader>
<fragment-shader>Shaders/gbuffer-encode.frag</fragment-shader>
</program>
</syntaxhighlight>

For fullscreen passes shaders, only <tt>gbuffer-functions.frag</tt> should be provided, like this :

<syntaxhighlight lang="xml">
<program>
<vertex-shader>Shaders/sunlight.vert</vertex-shader>
<fragment-shader>Shaders/sunlight.frag</fragment-shader>
<fragment-shader>Shaders/gbuffer-functions.frag</fragment-shader>
</program>
</syntaxhighlight>

In the main function of the shader, the functions referenced need to be declared first. With no #include files, the whole function prototype needs to be typed :
<syntaxhighlight lang="glsl">
void encode_gbuffer(vec3 normal, vec3 color, int mId, float specular, float shininess, float emission, float depth);

main() {
vec3 normal;
vec3 color;
int mId;
float specular;
float shininess;
float emission;
float depth;

// Do shader computations

encode_gbuffer(normal, color, mId, specular, shininess, emission, depth);
}
</syntaxhighlight>

=== Geometry Stage ===
The Geometry Stage is there to fill the G-buffer. '''Shading doesn't occur at this stage, so light or fog computation should not be part of the shader'''. The required operation in the Fragment Shader is to fill every individual buffer with sensible value :

{| class="wikitable" style="text-align: center;"
|depth (gl_FragDepth)||GL_DEPTH_COMPONENT32||colspan="4"|Fragment depth
|-
|gl_FragData[0]||GL_RG16||colspan="2"|normal.x * 0.5 + 0.5||colspan="2"|normal.y * 0.5 + 0.5
|-
|gl_FragData[1]||GL_RGBA8||diffuse.r||diffuse.g||diffuse.b||material id * 1/255.0
|-
|gl_FragData[2]||GL_RGBA8||specular.l||specular.s||emission.l||pixel valid if != 0
|}

This is the default layout expected by the sunlight shader. material Id can be used to detect a different layout



=== Additional light pass ===
There would be a single shader for each light type used. The plan is to create lights like animations in the model XML file. The light shader will retrieve scene geometry by combining screen space position converted in view space ray by the inverse of the projection matrix (an helper function should be provided), and the fragment depth at that screen position read from the depth buffer. With the help of the fragment normal, the diffuse and specular color and the properties of the light the shader implements, it will be possible to add to the lighting buffer the contribution of the light rendered.

=== Fog Pass ===
Using the fragment depth, it will be possible to compute any fog distribution. For the moment, the simple fog equation is implemented.

=== Bloom Pass ===
This is a two-pass effect that blurs the lighting buffer in a small texture. This texture is then added to the lighting buffer at the display stage.

=== Required Effects ===
Several pass are implemented using the effect system. For this purpose, some effects are referenced in the core code using reserved names. these effects are:
{| class="wikitable" cellpadding="3"
!Name
!Kind
!Purpose
|-
|<tt>Effects/ssao</tt>
|Works on a full screen quad
|Compute ambient occlusion from the normal buffer and the depth buffer
|-
|<tt>Effects/ambient</tt>
|Works on a full screen quad
|Copies the diffuse color buffer multiplied by the ambient light to the lighting buffer. Ambient Occlusion can also affect ambient light.
|-
|<tt>Effects/light-spot</tt>
|Works on real geometry of the light volume
|Computes the light contribution of a spot light defined in a <tt>light</tt> animation having a <tt>light-type</tt> of '''<tt>spot</tt>'''
|-
|<tt>Effects/fog</tt>
|Works on a full screen quad
|Computes the fog from the G-buffer and the lighting parameters
|-
|<tt>Effects/display</tt>
|Works on a full screen quad
|Renders the composite final image from the G-buffer and the lighting buffer
|}

== Guidelines for modelers ==

=== Porting aircraft ===
* Rembrandt computes shadows => no more fake shadows in the model
* Rembrandt computes ambient occlusion => no ambient occlusion baked into textures
* Rembrandt has light => static lightmap are not needed, emissive color to see models at night is not needed and would interfere
* Rembrandt has glow => incorrectly used emissive colors may blur displays and make some text unreadable. Light size may have to be adjusted
* Rembrandt has strict needs with shaders => shaders need to be adjusted to comply with the new framework otherwise the view will be plain wrong
* Rembrandt can't do transparent surfaces => transparent surface need to be properly registered to render them with the classical path

Once your aircraft has been ported, please modify its wiki page and add this symbol to it:
[[File:Rembrandtready.png]].

For a list of converted aircraft, please see [http://forum.flightgear.org/viewtopic.php?f=4&t=17536#p166346].

=== Registering all translucent surfaces ===

Every model is, by default, rendered using the <tt>Effects/model-default</tt> effect. This effect initialize the G-buffer, ignoring transparent surfaces, by doing alpha testing and rendering all the geometry in the default bin. It is not possible to redirect rendering to transparent bins when the associated texture has alpha channel because most models use a single texture atlas and even opaque parts are rendered with texture with alpha channel.

If a model needs to have transparent or translucent surfaces, these surface objects need to be assigned a different effect that sets explicitly the render bin to "DepthSortedBin", or sets the rendering hint to "transparent". This tells the renderer to render this object using forward rendering, so lighting and fog need to be enabled, and if a shader program is used, they should be computed in the classical way. The <tt>Effects/model-transparent</tt> can be used to register simple transparent/translucent surfaces. You assign this effect to an object (or multiple objects) like:
<effect>
<inherits-from>Effects/model-transparent</inherits-from>
<object-name>TheObject</object-name>
</effect>

'''Beware: <Effect> only works on real objects, not on groups of objects or animations.'''

If opaque surface need to have special effect, for example to apply bump mapping, this effect should use the "RenderBin" bin, or the rendering hint set to "opaque", and the G-buffer needs to be initialized correctly in the Geometry stage.

=== Making sure that all geometry will cast shadow ===

To limit the amount of geometry rendered in the shadow map, and also to reduce artifacts (shadow acne), only faces not facing the sun are casting shadows. The test is made using the normal orientation. That means that double-sided polygons, or mesh that are not closed, will be transparent to light at certain sun angles. To avoid that, modelers can either :
* ensure that the object is always in the shadow of another objects,
* close their mesh, or,
* double polygons with the normal set to the opposite.

=== Adding lights to a model ===

There are two things to consider: the appearance of the light source and the illuminated area. For the appearance of the light source (what you see when you look at the bulb), you need a model with an emissive material that will produce the glow effect and that is visible at night.

For the effect of the source on its environment (the lit area), we must have in the 3D model (the .ac file) a volume that includes the effect (Light Volume). It can be a large cone for spotlights or a sphere for point light. It's important that the light volume is closed, convex and it's normals are oriented outward.

The light volume must be part of the geometry of the model and be referenced in the animation file. No need to add a color or an effect to this volume. Light calculation is only done on the fragments covered by the light volume, but has no influence on the color or the attenuation of the light.

All available animations are possible on the light volume, except '''material''' and '''texture'''. It is not possible to change color of lights for the moment, except switching to another animation. Axis and position are in object space and are transformed by the subsequent animations.

==== Spotlights ====
{|cellpadding=10|
|valign=top|
<syntaxhighlight lang="xml">
<animation>
<type>light</type>
<light-type>spot</light-type>
<name>LightSrcRight</name>
<object-name>LightRight</object-name>
<nopreview/>
<position>
<x>0.169</x>
<y>0.570</y>
<z>0.713</z>
</position>
<direction>
<x>-0.9988</x>
<y>0.0349</y>
<z>-0.0349</z>
</direction>
<ambient>
<r>0.03</r>
<g>0.03</g>
0.03
<a>1.0</a>
</ambient>
<diffuse>
<r>0.7</r>
<g>0.7</g>
0.6
<a>1.0</a>
</diffuse>
<specular>
<r>0.7</r>
<g>0.7</g>
0.7
<a>1.0</a>
</specular>
<dim-factor>
<property>dimming/property</property>

<expression />
<interpolation />
<factor>1</factor>
<offset>0</offset>
<min>0</min>
<max>1</max>

</dim-factor>
<attenuation>
<c>1.0</c>
<l>0.002</l>
<q>0.00005</q>
</attenuation>
<exponent>30.0</exponent>
<cutoff>39</cutoff>
<near-m>3.5</near-m>
<far-m>39</far-m>
</animation>
</syntaxhighlight>
|valign=top|
{| class="wikitable" cellpadding="3"
!Name
!Purpose
|-
|<tt>type</tt>
|Install the <tt>'''light'''</tt> animation
|-
|<tt>light-type</tt>
|This is a <tt>'''spot'''</tt> light
|-
|<tt>name</tt>
|Name given to this animation
|-
|<tt>object-name</tt>
|Name of the light volume in the 3d model (typically a cone with an apex at <tt>position</tt>, along <tt>direction</tt> axis if <tt>cutoff</tt> is lesser than 90 degrees, or a sphere centered at <tt>position</tt> if <tt>cutoff</tt> is greater than 90 degrees )
|-
|<tt>nopreview</tt>
|Hide light volume in fgrun 3d preview
|-
|<tt>position</tt>
|In object space, position of the light
|-
|<tt>direction</tt>
|In object space, direction to the center of the spot
|-
|<tt>ambient</tt>
|Ambient color of the light
|-
|<tt>diffuse</tt>
|Diffuse color of the light
|-
|<tt>specular</tt>
|Specular color of the light
|-
|<tt>dim-factor</tt>
|Group of parameters to control a factor that is applied to ambient, diffuse and specular at the same time
|-
|<tt>attenuation</tt>
|Three element vector. <c> element is the constant factor, <l> element is the linear factor and <q> element is the quadratic factor. 
Attenuation of color at distance d is [[File:Spotlight_attenuation.png]]
|-
|<tt>exponent</tt>
|Attenuation is multiplied by <tt>pow( dot( lightDir, <direction> ), <exponent> )</tt>, lightDir being vector from light position to point, in camera space.
|-
|<tt>cutoff</tt>
|Point is lit by this source if <tt>dot( lightDir, <direction> ) > <cutoff></tt> , lightDir being vector from light position to point, in camera space.
|-
|<tt>near-m</tt>
|Minimum distance of influence, from position, in meters
|-
|<tt>far-m</tt>
|Maximum distance of influence, from position, in meters
|}
|}

==== Point lights ====
{|cellpadding=10|
|valign=top|
<syntaxhighlight lang="xml">
<animation>
<type>light</type>
<light-type>point</light-type>
<name>LightSrcRight</name>
<object-name>LightRight</object-name>
<nopreview/>
<position>
<x>0.169</x>
<y>0.570</y>
<z>0.713</z>
</position>
<ambient>
<r>0.03</r>
<g>0.03</g>
0.03
<a>1.0</a>
</ambient>
<diffuse>
<r>0.7</r>
<g>0.7</g>
0.6
<a>1.0</a>
</diffuse>
<specular>
<r>0.7</r>
<g>0.7</g>
0.7
<a>1.0</a>
</specular>
<dim-factor>
<property>dimming/property</property>

<expression />
<interpolation />
<factor>1</factor>
<offset>0</offset>
<min>0</min>
<max>1</max>

</dim-factor>
<attenuation>
<c>1.0</c>
<l>0.002</l>
<q>0.00005</q>
</attenuation>
<near-m>3.5</near-m>
<far-m>39</far-m>
</animation>
</syntaxhighlight>
|valign=top|
{| class="wikitable" cellpadding="3"
!Name
!Purpose
|-
|<tt>type</tt>
|Install the <tt>'''light'''</tt> animation
|-
|<tt>light-type</tt>
|This is a <tt>'''point'''</tt> light
|-
|<tt>name</tt>
|Name given to this animation
|-
|<tt>object-name</tt>
|Name of the light volume in the 3d model (typically a sphere centered on <tt>position</tt>, with a radius of <tt>far-m</tt>)
|-
|<tt>nopreview</tt>
|Hide light volume in fgrun 3d preview
|-
|<tt>position</tt>
|In object space, position of the light
|-
|<tt>ambient</tt>
|Ambient color of the light
|-
|<tt>diffuse</tt>
|Diffuse color of the light
|-
|<tt>specular</tt>
|Specular color of the light
|-
|<tt>dim-factor</tt>
|Group of parameters to control a factor that is applied to ambient, diffuse and specular at the same time
|-
|<tt>attenuation</tt>
|Three element vector. <c> element is the constant factor, <l> element is the linear factor and <q> element is the quadratic factor. 
Attenuation of color at distance d is [[File:Spotlight_attenuation.png]]
|-
|<tt>near-m</tt>
|Minimum distance of influence, from position, in meters
|-
|<tt>far-m</tt>
|Maximum distance of influence, from position, in meters
|}
|}

==== Performance and compatibility considerations ====
Every light on screen is equivalent for the GPU of redrawing the light volume with a shader, without z buffer culling. So each light comes with a cost, that is small taken individually but noticeable when a lot of them are visible. That cost also increase with the size of the light volume.

Beside that, it is wise to allow a model to work with the classical renderer that know nothing about lights and would render light volumes like other geometry. So a good practice is to complement each light animation with a select animation checking :
*if Rembrandt is enabled
*if the user selected quality match with the purpose of the light
*if the light should be on or off according to the other parameters of the simulation (position of the sun, position of switch, presence of power, ...)

A quality property is created to reflect the user preferences about quality vs performance concerning lights, and a proper slider is added to the shader dialog.
[[File:Fgfs-shaders-with-light.jpg|thumb|Light quality slider]]
The propery to use is :
/sim/rendering/shaders/lights
The quality slider sets its range from 0 (no lights) to 4 (all lights on). Simple airport lamp post appears at 1. Few bridge lamps at 2, all simple bridge lamp at 3 and more involved one at 4.

Example:
<syntaxhighlight lang="xml">
<animation>
<type>light</type>
<light-type>spot</light-type>
<name>LightSource</name>
<object-name>LightVolume</object-name>
...
</animation>

<animation>
<type>select</type>

<object-name>LightSource</object-name>
<condition>
<and>

<property>/sim/rendering/rembrandt/enabled</property>

<greater-than>
<property>/sim/rendering/shaders/lights</property>
<value>3.0</value>
</greater-than>

<greater-than>
<property>/sim/time/sun-angle-rad</property>
<value>1.57</value>
</greater-than>
</and>
</condition>
</animation>

</syntaxhighlight>

=== Tutorials ===
[[User:F-JJTH|F-JJTH]] compiled his experience and the one acquired by the PAF team converting aircraft in {{fr}} [http://equipe-flightgear.forumactif.com/t1034-howto-adapter-un-appareil-pour-rembrandt this tutorial],

== TODO List ==

=== Mac Issues ===
More and more Apple/Mac users are reporting issues related to running Rembrandt [http://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=rembrandt+mac].

Looking at the Mac GPU specs, it isn't clear if the Mac/ATI hardware/driver is generally insufficient, it should seem possible to run a customized Rembrandt setup with acceptable frame rates at 15-35 fps (assuming everything else being disabled for starters).

GLSL compilers have varying quality and especially the Mac (ATI/AMD) GLSL compilers are known to have issues with more sophisticated/nested constructs, so that it may help to reduce complexity of GLSL statements by splitting them up, instead of using nested anonymous vectors or functions (fatal error C9999: Nested functions, aborting!) for example.

So, the specific issue on Mac is some shaders being miscompiled, so the frame-rates are particularly bad, since the driver is hitting (slow) error paths. Certainly some Rembrandt-related shades fail to compile, though whether or not these are optional or required ones, isn't clear (Fred?). Some users reported that the errors and problems after upgrading their OS from OsX, 10.6.8 to OSX 10.8.2 (Mountain Lion) [http://forum.flightgear.org/viewtopic.php?f=47&t=19070&p=177106&hilit=rembrandt+mac#p177106] or OS Snow Leopard (10.6. to Mountain Lion (10.8.2), downloaded XQuartz 2.7.4 [http://forum.flightgear.org/viewtopic.php?f=21&t=19000&p=177570&hilit=rembrandt+mac#p176972].

The shader errors would suggest that certain GLSL constructs are not supported by the ATI/AMD glsl compiler - this seems to be a known issue: [https://groups.google.com/forum/?fromgroups=#!topic/comp.graphics.api.opengl/H_FLQCQE1i4] To address this, one would need to port the corresponding shaders - like just was done to get rid of the constructs that caused errors on old GeForce 7x generation hardware. It seems the hardware is not the problem, but the driver being way out of date. I find the fact that it's the Cg compiler and not a native glsl compiler that returns the errors very strange.

Another FG 2.10 user on MacPro 3.2 GHz Quad-Core Xeon, 8GB RAM, MacOS X 10.6.8. ATI Radeon HD 5870 (gl-vendor:ATI Technologies Inc., gl-version:2.1 ATI-1.6.36 gl-renderer:ATI Radeon HD 5870 OpenGL Engine, gl-shading-language-version:1.20) report said "Rembrandt is still unusable on my Mac. One frame every 4-5 seconds and it looks weird."[http://forum.flightgear.org/viewtopic.php?f=68&t=18839&p=175737&hilit=rembrandt+mac#p175684]

It's also worth noting that a number of FG 2.8 users reported that Rembrandt would still work for them using the 2.8 binary, unlike the 2.10 binary on Mac OSX version 10.7.5 on an iMac (AMD Radeon HD Graphics with 512MB) [http://forum.flightgear.org/viewtopic.php?f=21&t=19000&hilit=rembrandt+mac#p176460]. So the issue seems to occur largely in combination with older Mac OS versions and newer FG versions (>=2.8+) [http://forum.flightgear.org/viewtopic.php?f=4&t=19396&hilit=rembrandt+mac#p179456].

It appears it is the Rembrandt lighting causing issues while in non rembrandt mode with older Mac OS + FG 2.8 and better. On other OS setups, the rembrandt lighting gets ignored when rembrandt is turned off, but not in this case. Both lighting modes are present and creating the weird light cone effects [http://forum.flightgear.org/viewtopic.php?f=4&t=19396&hilit=rembrandt+mac&start=15#p179655].

If there are any console messages (like warnings or errors) shown, that would be helpful to know. A number of rembrandt related changes got fixed by Fred like this. Obviously, it is difficult for shader developers to troubleshoot shader related issues that they cannot reproduce with their own hardware.

Rembrandt is being largely developed by a single Windows/Nvidia-based developer, so it gets very little testing and debugging on different platforms, especially Mac/ATI (AMD) - so as a Mac user, your safest bet is probably providing lots of feedback via the forums (or preferably the issue tracker), FredB (the Rembrandt developer) is generally pretty responsive and appreciates all helpful feedback. Obviously, it helps being able to build from source, and being able to provide detailed troubleshooting reports.

These things are hard to debug/troubleshoot without having access to a corresponding system that exhibits the problem, which is why I suggested earlier to provide lots of Mac/Rembrandt-related feedback via the issue tracker, i.e. GLSL errors/warnings and anything else that could be useful.

If you have you ever tried to debug an issue that doesn't cause errors on your computer, you'll understand that it's damn difficult in the first place. Most developers don't own a Mac, and are not going to spend 1000$ or so just to have one more computer to test things on, and we don't know of anyone who buys computers for the whole purpose of testing FG on more platforms.

So as a rule we can try to pin down and solve such issues if, and only if, we get a decent bug report with tons of relevant background info and the possibility to ask follow-up questions. Remember, fixing such issues involves essentially working blind - it is trying to figure out why code that runs pefectly fine on your own computer might have issues on other computers and any traditional bug-hunting technique essentially fails.

Posting a screenshot of the issue is nice, but tells little more than that it exists. It's completely impossible to turn that into any action developer-side. The underlying shader code has probably a combined 1000 lines, any of which could be problematic.

Overall, the Rembrandt situation is most likely to improve the more feedback is provided by end users with different hardware/software configurations, Fred has fixed quite a number of shader related issues in the past, so it's largely a matter of time, and obviously the quality of feedback, provided by end-users like yourself.

And just in case: Note that GLSL shaders are not really compiled/built by developers (unlike the actual fgfs binary), but on an invididual basis by your GPU/graphics drivers, which happens transparently in the background, each time fgfs is started. Basically, a GLSL shader is a snippet of "source code" that is passed on to your GPU driver, which in turn compiles it down into hardware-specific instructions for your particular hardware.

From a troubleshooting perspective, it would be REALLY helpful if Mac users with the corresponding hardware and knowledge could come up with extremely downstripped test cases, that either show the problem, or which no longer show the problem as significantly. Disabling other shader-based features will definitely go a long way here, because many other GLSL features have not yet been explicitly ported to support Rembrandt.
In other words, you should preferably disable random building, advanced light scattern, advanced weather etc - and only really use the most basic settings to have an easily reproducable test case.

To get this started, you can customize the "zero eye candy" profile and enable Rembrandt using shader level 1: [[Howto:Debugging_FlightGear_Crashes#Minimal_Rembrandt_Startup_Profile]]

Some Mac folks have recently reported some success, it may be a good idea to search the forum for details, see for example:

* http://forum.flightgear.org/viewtopic.php?f=21&t=19000&p=177570&hilit=rembrandt+mac#p176972

{{cquote|I'm seeing regular crashes here from ALS and Rembrandt, but that's nothing new.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40024.html|title=<nowiki>Re: [Flightgear-devel] 2.10.1</nowiki>|author=Vivian Meazza|date=Fri, 03 May 2013 10:16:13 -0700}}</ref>|Vivian Meazza}}

{{cquote|With an AMD Radeon HD 5670 using free radeon driver I've never seen performance of more than 15fps with Rembrandt and if I turn shadow details up so they don't look crappy I get about 3-4fps.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40293.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stefan Seifert|date=Thu, 20 Jun 2013 10:10:56 -0700}}</ref>|Stefan Seifert}}

{{cquote|with a i3770K and a GTX670, I get some hit from ALS (10-30%) but Rembrandt instantly drops me to 20fps, and < 10fps I use an aircraft I actually want to fly (777 or Citation) and go to any major airport (EGKK, EHAM, EDDM, EDDF, EGLC, VHHH)

This is at 2560x1600, but on the 670 I would be highly surprised if I'm fill-rate limited, given that AA is off, and the general suboptimal size of our
primitive batches.

Emilian has explained on IRC this might be due to the out-of-the-box / default config for Rembrandt being highly suboptimal, which I didn't yet evaluate, I would be delighted to have it more usable.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40298.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=James Turner|date=Thu, 20 Jun 2013 13:29:47 -0700}}</ref>|James Turner}}

{{cquote|The Apple OpenGL renderer is a rather interesting beast - it's a clean-room front-end to the drivers, one of aspect of which means it is the only true 'Core Profile' 3.x renderer in wide use. (As opposed to the Ati and Nvidia Core profile drivers, which are simple the compat ones with some checks removed, I have been told). Of course FG is hence limited to 2.1 on Mac since we're a long way from Core profile support in the main code.

This does however mean it produces different GLSL compile issues, and different bugs in general, from the same hardware on other platforms.

(The renderer backend does of course come from the vendors, but OpenGL.framework always comes from Apple - it's not like Linux where your
libGL.so comes, at least potentially, from your hardware vendor)<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40083.html|title=<nowiki>Re: [Flightgear-devel] Shader compile failure</nowiki>|author=James Turner|date=Sat, 11 May 2013 06:53:32 -0700}}</ref>|James Turner}}

{{cquote|concerning the larger issue of different rendering pipelines / approaches, my opinion is, and remains, that the long-term solution is separate viewer codebases - while a plethora would be bad, we would already benefit from a 'fixed-function, no shaders' renderer codebase distinct from a Rembrandt renderer and modern, forward-rendering OpenGL 3.x pipeline. This needs the viewer to be cleanly split out from the simulation backend, via HLA, which is exactly what Mathias (and soon, myself) are working towards, but slowly.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39922.html|title=<nowiki>Re: [Flightgear-devel] Atmospheric Light Scattering</nowiki>|author=James Turner|date=Thu, 25 Apr 2013 08:09:08 -0700}}</ref>|James Turner}}

{{cquote|Like you and Thorsten, I see a very significant drop (50%) in frame-rate with Rembrandt, even without most the nice features such as shadows which has put me off using it. I had thought it was just because my box is now underpowered (the march of technology....) but it sounds like other are
seeing similar issues and it would be worth some further investigation.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40304.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Fri, 21 Jun 2013 01:40:15 -0700}}</ref>|Stuart Buchanan}}

=== Completed tasks ===
*Fix shadow rendering when using multi threading in OSG
*Implement Cascaded Shadow Map (need to be optimized - frustum calculation and night)
*Honor 'noshadow' animation (done)
*See what happens with glow in fog : unknown landclass creates white patches in the emission buffer - scenery generation problem
*Test multi-screen (mostly done)
*Restore splashscreen
*Draw transparent objects with forward rendering (may need to capture the transparent bin from the geometry stage and move it in the display stage) (OK - needs model contribution)
*Add spotlights as animations (nearly finished)
*find a solution for ambient and emissive color of material (may need an additional buffer)
*Provide a shader for transparent objects that could render to the emissive buffer too (using MRT) not doable. Light pass can't use MRT
*Use stencil buffer to limit light range(no - done in light shader)
**needed for cockpit light to implement fake shadows and avoid lighting the runway from the cabin through the airframe
*Use effect system instead of hard-coded shaders
*Add new animation to link a light source to a model (need to provide point light animation duplicating spot light) (done)
*Tidy up the architecture (done)
*Global strength of glow or ambient occlusion via slider in rendering dialog
*Fix dim-factor in multiplayer mode (done)
*Design and implement a configurable pipeline (done)
*Document rendering pipeline configuration file format (done)
*Fix fog on clouds

=== Near term tasks ===
*Convert existing shaders to deferred rendering
*Avoid to redraw opaque objects in the light pass. Involve OSG node mask not properly initialized.
*take care of particles and precipitation
*Fix shadow matrices in multi-screen
*Fix Lights in multi screen (seems same problem than shadows. Forgot a 1/w factor ?)
*Implement lightfield shader
*Add some kind of fog to lights
*Restore depth partitioning using depth ranges
*Move effect of cloud coverage from water shader to sunlight shader
*Allow light masks using textures
*Use stencil double-sided operations to limit the depth of light volumes. Use depth clamp to ensure front faces are always rendered even if the camera is enclosed in the light volume.

=== Long term ideas (unsorted) ===
*Use a separate list of light volumes to avoid traversing the scenegraph again (with transparency problems). Find out how we can detect unloading of models.
*implement volumetric effects by extending lights to arbitrary shaders. Should enable to implement heat haze effect and real wake waves.
*implement strength of glow (in the emissive buffer alpha channel) - use a Poisson-disk distribution to implement variable size blur
**provide levels 0 to 5 - we are currently at level 5
**level 0 should be ok for MFDs that are currenly unreadable because blurred
*Modify shadows to allow multiple casters (limited list)
**Implement a priority list of light sources, based on priority and distance from the viewer
*Restore stereo and other options currently available in CameraGroup
*Implement quality vs performance user control

== Gallery ==
{{#ev:youtube|PXHhtQb5yzc}} {{#ev:youtube|peEzEapavkg}} {{#ev:youtube|RIetPh8iJXk}} {{#ev:youtube|oaNFrxgQY1c}} {{#ev:youtube|8xGzy12hlis}} {{#ev:youtube|ZyuHBlm3xXU}} {{#ev:youtube|RgH9GZRukOI}} {{#ev:youtube|UQvbHnBkpaM}} {{#ev:youtube|v02phoOqWHE}}{{#ev:youtube|dlSo4sBa7Nk}}

== Appendix ==
{{Appendix|all|
* {{cite web |url=http://http.download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_Deferred_Shading.pdf |title=Deferred Shading |author=Shawn Hargreaves and Mark Harris }}
* {{cite web |url=http://bat710.univ-lyon1.fr/~jciehl/Public/educ/GAMA/2007/Deferred_Shading_Tutorial_SBGAMES2005.pdf |title=Deferred Shading Tutorial |author=Fabio Policarpo and Francisco Fonseca }}
* {{cite web |url=http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf |title=Deferred Rendering in Killzone 2 |author=Michal Valient |month=July |year=2007 }}
* {{cite web |url=http://www.anandtech.com/show/5011/nvidiaea-posts-battlefield-3-graphics-tech-talk |title=Battlefield 3 Graphics Tech Talk |author=Johan Andersson |month=October |year=2011 }}
* {{cite web |url=http://www.disney.co.uk/cms_res/blackrockstudio/pdf/Rendering_Techniques_in_SplitSecond.pdf |title=Rendering Techniques in Split/Second |author=Jeremy Moore and David Jefferies |year=2009 }}
* {{cite web |url=http://www.crytek.com/sites/default/files/A_bit_more_deferred_-_CryEngine3.ppt |title="A bit more Deferred" - CryEngine 3 (PPT) |author=Martin Mittring }}
* {{cite web |url=http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html |title=Deferred Shading in S.T.A.L.K.E.R. |author=Oles Shishkovtsov }}
* {{cite web |url=http://http.developer.nvidia.com/GPUGems3/gpugems3_ch19.html |title=Deferred Shading in Tabula Rasa |author=Rusty Koonce }}
* {{cite web |url=http://aras-p.info/texts/CompactNormalStorage.html |title=Compact Normal Storage for small g-buffers |author=Aras Pranckevičius |date=4 August 2009 |accessdate=12 April 2012 }}
* {{cite web |url=http://the-witness.net/news/2010/03/graphics-tech-shadow-maps-part-1/ |title=Graphics Tech: Shadow Maps (part 1) |author=Jonathan Blow |date=3 March 2010 |accessdate=13 April 2012 }}
* {{cite web |url=http://directtovideo.wordpress.com/2009/11/13/deferred-rendering-in-frameranger/ |title=deferred rendering in frameranger. |author=Matt Swoboda |date=13 November 2009 |accessdate=8 July 2012 }}
* {{cite web |url=http://publications.dice.se/publications.asp?show_category=yes&which_category=Rendering |author=DICE |title=Publications on rendering |accessdate=15 August 2012 }}
* {{cite web |url=http://advances.realtimerendering.com/s2012/Epic/The%20Technology%20Behind%20the%20Elemental%20Demo%2016x9.pptx |author=Martin Mittring |title=The Technology behind the Unreal Engine 4 Elemental Demo |accessdate=15 September 2012 }}
}}

<references/>

[[Category:Shader development]]
[[Category:Core development projects]]
[[fr:Projet Rembrandt]]

Project Rembrandt

2014-10-19T19:28:55Z

F-JJTH: /* Configurable pipeline */

== Why this name ? ==
[http://en.wikipedia.org/wiki/Rembrandt Rembrandt] was a dutch painter living in the 17th century, famous as one of the master of [http://en.wikipedia.org/wiki/Chiaroscuro chiaroscuro].

This project is about changing the way [[FlightGear]] renders lights, [[shadows]] and shades, and aims at making Rembrandt painting style possible in FG.

{{forum|47|Effects & Shaders}}

== Status (07/2014) ==
For the time being, Rembrandt's main developer (FredB) is not actively involved in FlightGear, and Rembrandt must be considered "unmaintained" currently. However, there are 2-3 overlapping efforts, some of which were discussed on the developers mailing list. First of all, there's Zan's newcamera branch, which has never been merged with FlightGear, but which exposes FlightGear's rendering pipelines to XML/fgdata space via the effects framework - which basically means that large portions of Rembrandt could be moved out of the C++ code back into GLSL/effects space, which is something that was originally discussed by a few core developers. This has never materalized, because Zan's work took place pretty much at the same time when Rembrandt was being developed. Likewise, some technical challenges could be easily addressed by exposing each rendering stage to a [[Canvas]] texture, which would mainly require two new features: 1) [[Canvas_Development#Supporting_Cameras|supporting camera views as a new Canvas::Element]], and 2) [[Canvas_Development#Effects_.2F_Shaders|supporting effects/shaders]] per Canvas/Element.
From then on, most [[Howto:Use_a_Camera_View_in_an_Instrument|Rembrandt-like functionality, including mirror views, tail cameras or FLIR-like processing]], could be fully implemented and maintained by fgdata contributors familiar with the effects framework and shaders, without necessarily being specific to just deferred rendering:

{{FGCquote
|Personally, I see the potential of deferred rendering, but if it ends up with 15 fps on a gaming rig, then that's what it's going to remain - potential waiting for the next or next-to-next hardware generation. For me personally, real secondary light sources and shadows aren't a big deal. They're important on the ground, at an airport, but I'm usually flying. 
 
Self-shadowing of the terrain can be done in 90% of the cases accurately without Rembrandt because the terrain is rarely that steeply sloped, and the interesting other shadows in nature - clouds and trees - can't be done by Rembrandt in any case.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=204372#p204372
|title=<nowiki>Re: A long shot</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Thu Mar 27</nowiki>
}}
}}

{{FGCquote
|Rembrandt is just one particular (and experimental) implementation of deferred rendering implemented via FlightGear - when running other simulators/games -with comparable scenes (not necessarily 400km of visibility!)- you'll see that performance isn't typically that much affected. So I guess there's nothing wrong about Rembrandt per se, but it just isn't very optimized at the moment, and it not being maintained doesn't really help. A few weeks ago when we exchanged screen shots and Rembrandt stats, there were apparently a few low-hanging fruits, and Rembrandt was obviously doing stuff that wasn't really necessary (e.g. computing shadows at night time without any light sources within 50km...)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=204374#p204374
|title=<nowiki>Re: A long shot</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Mar 27</nowiki>
}}
}}

{{FGCquote
|The situations I'm aware of were deferred rendering is used are frequently first person shooters. From the ground, where you have plenty of objects obscuring each other, deferred rendering would give you a pronounced boost in framerate as you spend minimal time with vertices you're not going to see. That advantage never really materializes for a flightsim. 
 
Imo, what makes our performance in comparison worse than other software where a large scene is rendered is the lack of a terrain LOD system. Our vertex count just explodes at high visibility. 
 
I mean, FredB obviously spent quite some time with Rembrandt. If someone can make it run much faster, than that'd change the game, but so far we have mostly talk.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=204375#p204375
|title=<nowiki>Re: A long shot</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Thu Mar 27</nowiki>
}}
}}

{{FGCquote
|Given how FlightGear has evolved over time, not just regarding effects/shaders, but also complementary efforts like deferred rendering (via rembrandt), we'll probably see cameras (and maybe individual rendering stages) exposed as Canvases, so that there's a well-defined interface for hooking up custom effects/shaders to each stage in the pipeline - Zan's newcamera work demonstrates just how much flexibility can be accomplished this way, basically schemes like Rembrandt could then be entirely maintained in XML/effects and shader (fgdata) space. 
And even the fgviewer code base could be significantly unified by just working in terms of canvases that deal with camera views, which also simplifies serialization for HLA.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=216741#p216741
|title=<nowiki>Re: create window</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Aug 16</nowiki>
}}
}}
{{FGCquote
|So we would need to extend CanvasElement then to support effects - according to some of your postings, you played with that already a while ago using code from SGMaterialAnimation apparently, as in 2 years ago ? Is that something that we should reuse ? 
 
Specifically, I've been in touch with some of our effects/shader guys, and we're wondering if we could directly register a Canvas/Effects texture as a texture available to effects, which is something that Thorsten and Tim talked about a while ago, being a limitation in effects that they would like to get rid of
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=201852#p201852
|title=<nowiki>Re: </nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Feb 25</nowiki>
}}
}}

{{FGCquote
|this all predates Canvas - but if we could not just support glsl/effects in Canvas, but also expose those canvas textures to the effects system, that would bring a lot of possibilities
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=201852#p201852
|title=<nowiki>Re: </nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Tue Feb 25</nowiki>
}}
}}

{{FGCquote
|regarding Rembrandt in particular, we are only missing 2-3 [[Canvas]] enhancements to allow effects/shader guys to pick up where FredB left off - which are primarily,
# camera support
# effects/shader support

And people have this working in various stages already, sometimes unrelated to [[Canvas]] (Zan's newcameras branch), and sometimes not yet fully integrated (e.g. the shader stuff). But generally it is foreseeable that additional rendering schemes (deferred rendering) could then be implemented by people without having to touch any C++ code.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=204338#p204338
|title=<nowiki>Re: A long shot</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Wed Mar 26</nowiki>
}}
}}

{{FGCquote
|So, it's not really Rembrandt that's the issue here, the bottleneck is the number of active expert C++ developers (you cannot really touch the 3D parts of the simulator with "just" C++ knowledge, you also need strong maths skills and OpenGL/OSG 3D rendering experience), especially once they're no longer around to help integrate their code and if there's little documentation to help newcomers maintain their code, because that's when base package development is often taking over eventually.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

{{FGCquote
|For example, I think it's pretty safe to say that the Canvas system was never intended to "compete" with Rembrandt, and most people here will be wondering how it could possibly be competing at all ? But ultimately it really is an integration and accessiblity issue, too. Admitedly, you need to be familiar with the way the project works to foresee what could be happening here, but it's not really far-fetched at all: 
 
I had a quick look, and according to the initial Rembrandt commits by FredB, they were all about decoupling rendering into multiple stages and doing offscreen rendering to textures. This is also supported by the wiki and the initial Rembrandt discussions on the devel list. So far, straightforward to understand - even without knowing any GLSL. 
 
So basically it's about decoupling each rendering step and rendering each stage to a separate offscreen texture, and then it's mostly about exposing each rendering step/stage to the effects/GLSL framework for further processing there. 
 
Rembrandt obviously predates the Canvas system, but these days that's exactly what the Canvas is good at: offscreen rendering to an osg::Image, without having to touch any C++ code, and without having to build FlightGear from source. 

|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

{{FGCquote
|Tim Moore (developer of the effects framework) did mention several times how it would be great to extend the effects framework to allow arbitrary textures to be used as inputs/outputs for the effects frame. For example, see: [http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg37873.html http://www.mail-archive.com/flightgear- ... 37873.html] 
 
So consider a Canvas texture as the potential input/output for an effect, and there you have it: Canvas + effects/shader {{=}}> one important ingredient for a Canvas-based Rembrandt port.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

{{FGCquote
|we also have dozens of feature requests from aircraft developers to allow scenery views to be rendered as cockpit textures, e.g. to render mirrors or tail camera images. A feature also commonly seen on FSX and XPlane. 
Several years ago, Zan made lots of progress doing this sort of thing, long before the Canvas again - so it's also an integration issue. 
 
These days, this would require the view_mgr code to be adapted and turned into a Canvas::Element. For example, see: 
[http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg36673.html http://www.mail-archive.com/flightgear- ... 36673.html] 
[[Howto:Use_a_Camera_View_in_an_Instrument]] 
 
Other aircraft developers have asked for effects/GLSL being available to cockpit textures for other reasons, e.g. to implement night vision views/FLIR imagings. And supporting effects/shaders in Canvas has been discussed various times on the forum too. 
 
So, these are just two new features: 1) making effects/GLSL usable to Canvas textures and 2) rendering scenery views - and suddenly you have two major ingredients for a deferred shading scheme in place, without requiring extensive C++ changes, and without necessarily having to even look at Rembrandt ...
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

{{FGCquote
|I don't think that anybody is working on replacing Rembrandt, but I also don't think that we have any active core developers who could easily help maintain Rembrandt (except for FredB obviosuly) - still it is foreseeable that the Canvas system will -eventually- provide all essential building blocks to allow deferred rendering to be built on top, it's really just a matter of time. 
 
At that point revisiting the Rembrandt code and moving its rendering stages into cascaded Canvas textures that make use of scenery views and effects/shaders with an osgViewer-based placement, would be straightforward for any GLSL developer, much more so than getting to grips with the underlying Rembrandt C++ code itself. 
 
So, nobody is working on revamping/replacing Rembrandt, but even if it were to continue to be stalled, the idea could still evolve - C++ templates were also never intended to be turing-complete, it just happened by accident :lol: 
 
As we know, even for good ideas, it usually takes ~3-5 years for them to be implemented (remember: OSG port, Rembrandt, Canvas etc). 
 
So I still wouldn't hold my breath. But re-considering the way Rembrandt is done and integrating it with the Canvas system would help make it less obscure and more accessible to effects/GLSL developers, especially for times when there are no C++/3D experts around.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=194296#p194296
|title=<nowiki>Re: What frame rate (fps) do you have?</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Mon Nov 18</nowiki>
}}
}}

== What is it ? ==
The idea driving the project is to implement [http://en.wikipedia.org/wiki/Deferred_shading deferred rendering] inside FlightGear.
From the beginning FlightGear had a forward renderer that tries to render all properties of an object in one pass (shading, lighting, fog, ...), making it difficult to render more sophisticated shading
(see the [[FlightGear Newsletter December 2011#Shaders|'Uber-shader']]) because one has to take into account all aspects of the [http://www.wired.com/magazine/2010/07/st_equation_3danimation/ rendering equation].

[[Image:project_rembrandt_1.png|thumb|300px|Main view with the content of buffers displayed at corners]]
On the contrary, deferred rendering is about separating operations in simplified stages and collecting the intermediary results in hidden buffers that can be used by the next stage.

;First stage is the Geometry Stage :
: we render all the scene into 4 textures, using multi render targets, to do it in one pass: one for the depth buffer, one for the normals (lower left of the image), one for the diffuse colors (lower right) and one for the specular colors (upper right).

;Next stage is the Shadow Stage :
: we render the scene again into a depth texture from the point of view of the lights. There will be one texture for every light casting shadows.

;Then comes the Lighting Stage, with several substages :
:*Sky pass: the sky is first drawn using classical method.
:*Ambient pass: the diffuse buffer is modulated with the ambient color of the scene and is drawn as a screen-aligned textured quad
:*Sunlight pass: a second screen aligned quad is drawn and a shader computes the view position of every pixel to compute its diffuse and specular color, using the normal stored in the first stage. The resulting color is blended with the previous pass. Shadows are computed here by comparing the position of the pixel with the position of the light occluder stored in the shadow map.
:*Fog pass: a new screen aligned quad is draw and the position of the pixel is computed to evaluate the amount of fog the pixel has. The fog color is blended with the result of the previous stage.
:*Additional light pass: the scene graph will be traversed another time to display light volumes (cone or frusta for spot lights, sphere for omni-directional lights) and their shader will add the light contributed by the source only on pixels receiving light.
:*Transparent objects pass: transparent objects (and clouds) are finally rendered using classical method.

:All lighting computations are accumulated in a single buffer that will be used for the last stage, in addition of the one computed by the Geometry stage.

;In the end, the Display Stage, with optional Post-Processing effect :
:The results of the previous buffers are pushed to the main framebuffer to be displayed, optionally modified to show Glow, Motion blur, HDR, redout or blackout, screen-space ambient occlusion, anti-aliasing, etc...

In FG, we end the rendering pipeline by displaying the [[Menubar|GUI]] and the [[HUD]].

All these stages are more precisely described in this [http://bat710.univ-lyon1.fr/~jciehl/Public/educ/GAMA/2007/Deferred_Shading_Tutorial_SBGAMES2005.pdf tutorial] that is the basis of the current code, with some addition and modifications.

C++ developers interested in learning more about how Rembrandt works, will want to look at these initial $FG_SRC commits (note that the viewer related sources are now to be found in $FG_SRC/Viewer):
* 94e3ae4c675463c358071e1d9da8de583cf56e15
* 6b008126b5fd99c38778c6293c15f9721a4fa509
* 64e3e98069fb2310311687b9f099b338b8b375a5
* bb16463d631a8d87310a54a573966eb1cca813e6

== Caveats ==
Deferred rendering is not able to display transparency. For the moment, clouds are renderer separately and should be lit and shaded by their own. Transparent surfaces are alpha-tested and not blended. They would have to be drawn in their own bin over the composited image.

It also don't fit with depth partitioning because the depth buffer should be kept to retain the view space position, so for the moment, z-fighting is quite visible. Depth partitioning with non overlapping depth range might be the solution and should be experimented at one point.

The glow pass can make certain MFD (that use emissive color) unreadable because blurred. Should be treated as transparent.

== Implementation ==
=== Repositories ===
The code is in the main branch of the [[FlightGear and Git|official repository]]. Any other location is not maintained anymore.

=== Rendering of transparent surfaces ===
[[Image:project_rembrandt_5.png|thumb|300px|Transparent surfaces drawn after opaque objects]]
Transparent surfaces are detected by OSG loader plugins and their state set receive the TRANSPARENT_BIN rendering hint. In the culling pass, the cull visitor orders transparent surfaces in transparent bin. In a cull callback attached to the Geometry camera, after the scenegraph traversal, the transparent bins are removed from the render stage and saved in a temporary collection. In a cull callback attached to the Lighting camera, after the scenegraph traversal, the transparent bins saved at the previous stage, are added to the render stage of the Lighting camera with a high order num. That way, the transparent surface are drawn on top of the scene lighted from the Gbuffer.

=== Memory consumption ===
For each camera defined in the camera group, there is a separate shadow map, so the video memory usage is :
* G-buffer and Lighting buffer: 20 bytes per pixel. For an HD screen (1920x1080) memory requirement is 40 Mb
* Shadow map: 3 x shadow_map_size x shadow_map_size bytes (if size is 8192, whole map size is 192 Mb
Not counting textures, display list or vertex buffers for models and terrain

3 HD screens require 120 Mb of memory for the buffers (shadow excluded), you're asking 3x8192x8192x3 = 576 Mb (megabytes) of memory for the shadows alone.

If you are seeing error messages during startup or FlightGear doesn't start up properly, it's probably because you don't have enough free video memory. Reduce the size of the shadow map in preferences.xml by locating

<syntaxhighlight lang="xml">
<map-size type="int">8192</map-size>
</syntaxhighlight>

And put 4096 or 2048 instead.
You can also use a startup parameter: --prop:/sim/rendering/shadows/map-size=2048

=== Configurable pipeline ===

The Rembrandt renderer uses an XML file to setup its pipeline for each viewport described in the camera group. This file describes the way the intermediary buffers are setup and how the different rendering stages are sequenced. The general outline of a pipeline file is as follow :

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>

<buffer>

</buffer>
<buffer>

</buffer>


<stage>

</stage>
<stage>

</stage>
</PropertyList>
</syntaxhighlight>

==== Buffers ====
A buffer is a texture used as a storage area in the GPU. It's size is usually a multiple of the screen size, but fixed size is supported (typical for shadow map). The description of a buffer is described below :

<syntaxhighlight lang="xml">
<buffer>
<name>buffer-name</name>
<internal-format>rgba8</internal-format> 
<source-format>rgba</source-format> 
<source-type>unsigned-byte</source-type> 
<width>screen</width> 
<height>screen</height> 
<scale-factor>1.0</scale-factor>
<wrap-mode>clamp-to-border</wrap-mode> 

<shadow-comparison>true</shadow-comparison>

<condition>

</condition>
</buffer>
</syntaxhighlight>

==== Stages ====
A stage is an unit of rendering to a group of buffer. Most stages are predefined and their type is not free. When a type is not specified, the name is used. Stage types are :
{| class="wikitable"
!align="left"| Stage type
!align="left"| Purpose
|-
|geometry
|The geometry stage initialize most of the buffers and works on the real objects and geometry. Transparent objects are set aside and will be used untouched in the lighting stage. Other opaque geometry is rendered with the standard effects that do the hard work to put sensible data in the buffers.
|-
|shadow
|In this stage, the geometry is rendered in the normal map from the perspective of the sun.
|-
|lighting
|This stage uses the buffers filled by the previous stages to light every pixel of the scene. The result is rendered in another buffer to allow post effects.
|-
|fullscreen
|Stages of this type are used to alter the whole scene or transform data from a particular buffer.
|-
|display
|Final rendering of the scene to the screen or the texture defined in the camera group.
|}

A stage description is outlined below :
<syntaxhighlight lang="xml">
<stage>
<name>stage-name</name>
<type>stage-type</type> 
<order-num>-1</order-num>
<effect>Effects/fullscreen-effect</effect> 
<needs-du-dv>true</needs-du-dv> 
<scale-factor>0.25</scale-factor> 


<condition>

</condition>

<attachment>

</attachment>
<attachment>

</attachment>


<pass>

</pass>
<pass>

</pass>
</stage>
</syntaxhighlight>
Stages render in buffers (except for the display stage). Attachments describe which buffers are affected by each stage.

===== Attachments =====
Attachment describe bindings between buffer and attachment point :
<syntaxhighlight lang="xml">
<attachment>
<component>color0</component> 
<buffer>buffer-name</buffer>

<condition>

</condition>
</attachment>
</syntaxhighlight>

===== Passes =====
Passes are only available in the <tt>lighting</tt> stage. Three kind of stage are allowed :

{| class="wikitable"
!align="left"| Pass type
!align="left"| Purpose
|-
|sky-clouds
|Renders the skydome, sun, moon, planet, stars and clouds
|-
|lights
|Renders additional spot and point lights
|-
|fullscreen
|Fullscreen pass analog to a fullscreen stage except that it renders in the buffers attached to the lighting stage
|}
A pass is defined like below :
<syntaxhighlight lang="xml">
<pass>
<name>pass-name</name>
<type>pass-type</type> 
<order-num>-1</order-num>
<effect>Effects/fullscreen-effect</effect> 


<condition>

</condition>
</pass>
</syntaxhighlight>

A typical lighting stage is a succession of 5 passes :
# <tt>sky-clouds</tt> pass
# <tt>fullscreen</tt> pass for ambient light
# <tt>fullscreen</tt> pass for sun light (and shadows)
# <tt>lights</tt> pass
# <tt>fullscreen</tt> pass for fog

Each effect attached to the fullscreen passes define the way blending is done between the pass and the previous accumulation of render.

===== C++ implementation =====

On the C++ side, Rembrandt is set up in those steps:

* ''buildRenderingPipeline()'' is the last common function between forward rendering and deferred rendering. That's the point of start for specific deferred stuff. In this function we call ''buildDeferredPipeline()''
** ''buildDeferredPipeline()'' is just a wrapper for ''buildCameraFromRenderingPipeline()''
*** ''buildCameraFromRenderingPipeline()'' is where we initialize all buffers and create all the stages found in ''Effects/default-pipeline.xml'' with the call to ''buildBuffers()'' and ''buildStage()''
**** ''buildBuffers()'' is where we ask to build each buffer with the call to ''buildDeferredBuffer()''
***** ''buildDeferredBuffer()'' create a 2D texture
**** ''buildStage()'' is where we ask to build each camera depending on the type of the stage (geometry, lighting, shadow, fullscreen, display) with the call to ''buildDeferred*Camera()'' (where * is the stage type)
***** ''buildDeferred*Camera()''is where we build the camera, for each camera we attach the required buffers with the call to ''buildAttachments()''.
****** ''buildDeferredGeometryCamera()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]
****** ''buildDeferredShadowCamera()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]
****** ''buildDeferredLightingCamera()'' Only for the lighting camera (''buildDeferredLightingCamera()'') we have to build passes who is called with ''buildPass()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]
****** ''buildDeferredFullscreenCamera()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]
****** ''buildDeferredDisplayCamera()'' c.f [http://wiki.flightgear.org/Project_Rembrandt#What_is_it_.3F What is it ?]

== Running Flightgear with Rembrandt ==
[[File:Rembrandt dialog.png|thumb|270px|Rembrandt dialog]]
The Rembrandt renderer is now integrated in the main repository but needs to be enabled to run. There are two ways to enable it (only one is needed!):
* <code>--enable-rembrandt</code> (when using [[FGRun]], you may add this behind the <tt>FG_EXECUTABLE</tt> on the first page).
* <code>--prop:/sim/rendering/rembrandt/enabled=true</code> (with FGRun this can be added via <tt>Advanced > Properties</tt> on the last page, but only the <code>/sim/rendering/rembrandt/enabled=true</code> part).

The <tt>View > Rendering Options > Rembrandt Options</tt> dialog allows you to toggle and adjust the various features that Rembrandt offers.

Rembrandt is quite demanding in GPU resources and may fail to run with the default options. The more frequent symptom is an OSG message in the console :

RenderStage::runCameraSetUp(), FBO setup failed, FBO status= 0x8cd6
Warning: RenderStage::runCameraSetUp(State&) Pbuffer does not support multiple color outputs.

The ssao effect provided in v2.8.0 may generate these messages, more often on Mac :

<pre>
FRAGMENT glCompileShader "/Users/xxxx/Desktop/FlightGear.app/Contents/Resources/../Resources/data/Shaders/ssao.frag" FAILED
FRAGMENT Shader "/Users/xxxx/Desktop/FlightGear.app/Contents/Resources/../Resources/data/Shaders/ssao.frag" infolog:
ERROR: 0:20: 'array of 2-component vector of float' : constructor not supported for type
ERROR: 0:20: 'array of 2-component vector of float' : no matching overloaded function found
ERROR: 0:20: 'const 2-component vector of float' : cannot declare arrays of this type
ERROR: 0:20: 'v' : redefinition
ERROR: 0:55: 'reflect' : no matching overloaded function found
ERROR: 0:55: '=' : cannot convert from 'float' to '2-component vector of float'

glLinkProgram "" FAILED
Program "" infolog:
ERROR: One or more attached shaders not successfully compiled
</pre>
In that case, disable ambient occlusion with the command :
<tt>--prop:/sim/rendering/rembrandt/ambient-occlusion-buffers=false</tt>

There is a number of additional options that can help to avoid these problems :

{| class="wikitable"
|<tt>--prop:/sim/rendering/rembrandt/use-color-for-depth=true</tt>
|Some old NVidia cards, such as 7600GT, don't give enough resolution for depth and that result in "fog curtains" at few meters from the viewer. One trick is to encode depth in another texture and get the proper value afterward. This option enables that.
|-
|<tt>--prop:/sim/rendering/shadows/enabled=false</tt>
|Disable shadows altogether.
|-
|<tt>--prop:/sim/rendering/shadows/num-cascades=1</tt>
|Set <tt>/sim/rendering/shadows/cascade-far-m[0]</tt> to change the shadow map range. The more the range, the less the resolution (default value is 5 meters)
|-
|<tt>--prop:/sim/rendering/shadows/map-size=<power-of-two></tt>
|Set the shadow map size. Useful values are 1024, 2048, 4096 or 8192. Few cards have the resources to support 16384.
|-
|<tt>--prop:/sim/rendering/shadows/num-cascades</tt>
|Set the shadow map cascade number. Less cascades means less time spent in shadow map generation, but also means lower shadow quality. Integer between 1 and 4.
|-
|<tt>--prop:/sim/rendering/shadows/cascade-far-m[i]</tt>
(1 <= i <= <tt>/sim/rendering/shadows/num-cascades</tt> <= 4)
|Set the shadow map cascade range for each cascade. Default values are 5m, 50m, 500m and 5000m for 4 cascades.
|-
|<tt>--prop:/sim/rendering/rembrandt/no-16bit-buffer=false</tt>
|By default, Rembrandt uses 8 bit buffers for normals (so the property is set to true by default). This may create banding artifacts on specular highlights. If it's unacceptable and the GPU supports it, set to false to have better precision for normals and effects relying on normal direction.
|}

== Guidelines for shader writers ==
=== Predefined uniforms ===
These glsl uniforms don't need to be declared in the effect file.
{| class="wikitable"
!Name
!Type
!Purpose
|-
|<tt>fg_ViewMatrix</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix used to transform the screen position to view direction
|-
|<tt>fg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix inverse used to transform the screen position to view direction
|-
|<tt>fg_ProjectionMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, projection matrix inverse used to transform the screen position to view direction
|-
|<tt>fg_CameraPositionCart</tt>
|<tt>vec3</tt>
|Position of the camera in world space, expressed in cartesian coordinates
|-
|<tt>fg_CameraPositionGeod</tt>
|<tt>vec3</tt>
|Position of the camera in world space, expressed in geodesic coordinates (longitude in radians, latitude in radians, elevation in meters)
|-
|<tt>fg_SunAmbientColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_SunDiffuseColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_SunSpecularColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_SunDirection</tt>
|<tt>vec3</tt>
|
|-
|<tt>fg_FogColor</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_FogDensity</tt>
|<tt>float</tt>
|
|-
|<tt>fg_ShadowNumber</tt>
|<tt>int</tt>
|
|-
|<tt>fg_ShadowDistances</tt>
|<tt>vec4</tt>
|
|-
|<tt>fg_DepthInColor</tt>
|<tt>bool</tt>
|Tells if the depth is stored in a depth texture or a color texture
|-
|<tt>fg_Planes</tt>
|<tt>vec3</tt>
|Used to convert the value of the depth buffer to a depth that can be used to compute the eye space position of the fragment
|-
|<tt>fg_BufferSize</tt>
|<tt>vec2</tt>
|Dimensions of the buffer, used to convert gl_FragCoord into the range [0..1][0..1]
|-
|<tt>osg_ViewMatrix</tt>
|<tt>mat4</tt>
|Defined by OSG, used only when working on actual geometry
|-
|<tt>osg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|Defined by OSG, used only when working on actual geometry
|}
They still have to be declared in the fragment or the vertex shader to be used.

=== Utility functions ===

To ease the maintenance of shaders, several utility functions are available for the fragment shader. These functions are put together in two files : <tt>gbuffer-functions.frag</tt> and <tt>gbuffer-encode.frag</tt>.

==== gbuffer-encode.frag ====

;<tt>void encode_gbuffer(vec3 normal, vec3 color, int mId, float specular, float shininess, float emission, float depth)</tt>
:Used to encode all the values of the G-Buffer in material shaders

==== gbuffer-functions.frag ====

;<tt>vec2 normal_encode(vec3 n)</tt>
:Used to compress normals into the G-Buffer in material shaders. Normally called from <tt>encode_gbuffer()</tt>

;<tt>vec3 normal_decode(vec2 enc)</tt>
:Reconstruct normals from the G-Buffer. Used in fullscreen shaders and light shaders

;<tt>vec3 float_to_color(in float f)</tt>
:Encode float values in the range [0..1] in the 24 bits of a color. This function is used by <tt>encode_gbuffer()</tt> if the <tt>/sim/rendering/use-color-for_depth</tt> is true, for old cards that don't provide depth information with enough resolution inside fullscreen or light shaders.

;<tt>float color_to_float(vec3 color)</tt>
:Decode float values in the range [0..1] from the 24 bits of a color. This function is used by <tt>position()</tt> if the <tt>/sim/rendering/use-color-for_depth</tt> is true, for old cards that don't provide depth information with enough resolution inside fullscreen or light shaders.

;<tt>vec3 position( vec3 viewDir, float depth )</tt>
:Reconstruct eye space position from the view direction and the depth read from the depth buffer

;<tt>vec3 position( vec3 viewDir, vec3 depthColor )</tt>
:Reconstruct eye space position from the view direction and the depth encoded in a color read from the depth buffer

;<tt>vec3 position( vec3 viewDir, vec2 coords, sampler2D depth_tex )</tt>
:Reconstruct eye space position from the view direction and the depth buffer (real depth or color, according to the value of <tt>/sim/rendering/use-color-for_depth</tt>) at a given fragment on screen, given by <tt>coords</tt>

==== Usage ====

For material shaders, it is necessary to provide both <tt>gbuffer-functions.frag</tt> and <tt>gbuffer-encode.frag</tt> in the effect file, like this :

<syntaxhighlight lang="xml">
<program>
<vertex-shader>Shaders/ubershader.vert</vertex-shader>
<fragment-shader>Shaders/ubershader-gbuffer.frag</fragment-shader>
<fragment-shader>Shaders/gbuffer-functions.frag</fragment-shader>
<fragment-shader>Shaders/gbuffer-encode.frag</fragment-shader>
</program>
</syntaxhighlight>

For fullscreen passes shaders, only <tt>gbuffer-functions.frag</tt> should be provided, like this :

<syntaxhighlight lang="xml">
<program>
<vertex-shader>Shaders/sunlight.vert</vertex-shader>
<fragment-shader>Shaders/sunlight.frag</fragment-shader>
<fragment-shader>Shaders/gbuffer-functions.frag</fragment-shader>
</program>
</syntaxhighlight>

In the main function of the shader, the functions referenced need to be declared first. With no #include files, the whole function prototype needs to be typed :
<syntaxhighlight lang="glsl">
void encode_gbuffer(vec3 normal, vec3 color, int mId, float specular, float shininess, float emission, float depth);

main() {
vec3 normal;
vec3 color;
int mId;
float specular;
float shininess;
float emission;
float depth;

// Do shader computations

encode_gbuffer(normal, color, mId, specular, shininess, emission, depth);
}
</syntaxhighlight>

=== Geometry Stage ===
The Geometry Stage is there to fill the G-buffer. '''Shading doesn't occur at this stage, so light or fog computation should not be part of the shader'''. The required operation in the Fragment Shader is to fill every individual buffer with sensible value :

{| class="wikitable" style="text-align: center;"
|depth (gl_FragDepth)||GL_DEPTH_COMPONENT32||colspan="4"|Fragment depth
|-
|gl_FragData[0]||GL_RG16||colspan="2"|normal.x * 0.5 + 0.5||colspan="2"|normal.y * 0.5 + 0.5
|-
|gl_FragData[1]||GL_RGBA8||diffuse.r||diffuse.g||diffuse.b||material id * 1/255.0
|-
|gl_FragData[2]||GL_RGBA8||specular.l||specular.s||emission.l||pixel valid if != 0
|}

This is the default layout expected by the sunlight shader. material Id can be used to detect a different layout



=== Additional light pass ===
There would be a single shader for each light type used. The plan is to create lights like animations in the model XML file. The light shader will retrieve scene geometry by combining screen space position converted in view space ray by the inverse of the projection matrix (an helper function should be provided), and the fragment depth at that screen position read from the depth buffer. With the help of the fragment normal, the diffuse and specular color and the properties of the light the shader implements, it will be possible to add to the lighting buffer the contribution of the light rendered.

=== Fog Pass ===
Using the fragment depth, it will be possible to compute any fog distribution. For the moment, the simple fog equation is implemented.

=== Bloom Pass ===
This is a two-pass effect that blurs the lighting buffer in a small texture. This texture is then added to the lighting buffer at the display stage.

=== Required Effects ===
Several pass are implemented using the effect system. For this purpose, some effects are referenced in the core code using reserved names. these effects are:
{| class="wikitable" cellpadding="3"
!Name
!Kind
!Purpose
|-
|<tt>Effects/ssao</tt>
|Works on a full screen quad
|Compute ambient occlusion from the normal buffer and the depth buffer
|-
|<tt>Effects/ambient</tt>
|Works on a full screen quad
|Copies the diffuse color buffer multiplied by the ambient light to the lighting buffer. Ambient Occlusion can also affect ambient light.
|-
|<tt>Effects/light-spot</tt>
|Works on real geometry of the light volume
|Computes the light contribution of a spot light defined in a <tt>light</tt> animation having a <tt>light-type</tt> of '''<tt>spot</tt>'''
|-
|<tt>Effects/fog</tt>
|Works on a full screen quad
|Computes the fog from the G-buffer and the lighting parameters
|-
|<tt>Effects/display</tt>
|Works on a full screen quad
|Renders the composite final image from the G-buffer and the lighting buffer
|}

== Guidelines for modelers ==

=== Porting aircraft ===
* Rembrandt computes shadows => no more fake shadows in the model
* Rembrandt computes ambient occlusion => no ambient occlusion baked into textures
* Rembrandt has light => static lightmap are not needed, emissive color to see models at night is not needed and would interfere
* Rembrandt has glow => incorrectly used emissive colors may blur displays and make some text unreadable. Light size may have to be adjusted
* Rembrandt has strict needs with shaders => shaders need to be adjusted to comply with the new framework otherwise the view will be plain wrong
* Rembrandt can't do transparent surfaces => transparent surface need to be properly registered to render them with the classical path

Once your aircraft has been ported, please modify its wiki page and add this symbol to it:
[[File:Rembrandtready.png]].

For a list of converted aircraft, please see [http://forum.flightgear.org/viewtopic.php?f=4&t=17536#p166346].

=== Registering all translucent surfaces ===

Every model is, by default, rendered using the <tt>Effects/model-default</tt> effect. This effect initialize the G-buffer, ignoring transparent surfaces, by doing alpha testing and rendering all the geometry in the default bin. It is not possible to redirect rendering to transparent bins when the associated texture has alpha channel because most models use a single texture atlas and even opaque parts are rendered with texture with alpha channel.

If a model needs to have transparent or translucent surfaces, these surface objects need to be assigned a different effect that sets explicitly the render bin to "DepthSortedBin", or sets the rendering hint to "transparent". This tells the renderer to render this object using forward rendering, so lighting and fog need to be enabled, and if a shader program is used, they should be computed in the classical way. The <tt>Effects/model-transparent</tt> can be used to register simple transparent/translucent surfaces. You assign this effect to an object (or multiple objects) like:
<effect>
<inherits-from>Effects/model-transparent</inherits-from>
<object-name>TheObject</object-name>
</effect>

'''Beware: <Effect> only works on real objects, not on groups of objects or animations.'''

If opaque surface need to have special effect, for example to apply bump mapping, this effect should use the "RenderBin" bin, or the rendering hint set to "opaque", and the G-buffer needs to be initialized correctly in the Geometry stage.

=== Making sure that all geometry will cast shadow ===

To limit the amount of geometry rendered in the shadow map, and also to reduce artifacts (shadow acne), only faces not facing the sun are casting shadows. The test is made using the normal orientation. That means that double-sided polygons, or mesh that are not closed, will be transparent to light at certain sun angles. To avoid that, modelers can either :
* ensure that the object is always in the shadow of another objects,
* close their mesh, or,
* double polygons with the normal set to the opposite.

=== Adding lights to a model ===

There are two things to consider: the appearance of the light source and the illuminated area. For the appearance of the light source (what you see when you look at the bulb), you need a model with an emissive material that will produce the glow effect and that is visible at night.

For the effect of the source on its environment (the lit area), we must have in the 3D model (the .ac file) a volume that includes the effect (Light Volume). It can be a large cone for spotlights or a sphere for point light. It's important that the light volume is closed, convex and it's normals are oriented outward.

The light volume must be part of the geometry of the model and be referenced in the animation file. No need to add a color or an effect to this volume. Light calculation is only done on the fragments covered by the light volume, but has no influence on the color or the attenuation of the light.

All available animations are possible on the light volume, except '''material''' and '''texture'''. It is not possible to change color of lights for the moment, except switching to another animation. Axis and position are in object space and are transformed by the subsequent animations.

==== Spotlights ====
{|cellpadding=10|
|valign=top|
<syntaxhighlight lang="xml">
<animation>
<type>light</type>
<light-type>spot</light-type>
<name>LightSrcRight</name>
<object-name>LightRight</object-name>
<nopreview/>
<position>
<x>0.169</x>
<y>0.570</y>
<z>0.713</z>
</position>
<direction>
<x>-0.9988</x>
<y>0.0349</y>
<z>-0.0349</z>
</direction>
<ambient>
<r>0.03</r>
<g>0.03</g>
0.03
<a>1.0</a>
</ambient>
<diffuse>
<r>0.7</r>
<g>0.7</g>
0.6
<a>1.0</a>
</diffuse>
<specular>
<r>0.7</r>
<g>0.7</g>
0.7
<a>1.0</a>
</specular>
<dim-factor>
<property>dimming/property</property>

<expression />
<interpolation />
<factor>1</factor>
<offset>0</offset>
<min>0</min>
<max>1</max>

</dim-factor>
<attenuation>
<c>1.0</c>
<l>0.002</l>
<q>0.00005</q>
</attenuation>
<exponent>30.0</exponent>
<cutoff>39</cutoff>
<near-m>3.5</near-m>
<far-m>39</far-m>
</animation>
</syntaxhighlight>
|valign=top|
{| class="wikitable" cellpadding="3"
!Name
!Purpose
|-
|<tt>type</tt>
|Install the <tt>'''light'''</tt> animation
|-
|<tt>light-type</tt>
|This is a <tt>'''spot'''</tt> light
|-
|<tt>name</tt>
|Name given to this animation
|-
|<tt>object-name</tt>
|Name of the light volume in the 3d model (typically a cone with an apex at <tt>position</tt>, along <tt>direction</tt> axis if <tt>cutoff</tt> is lesser than 90 degrees, or a sphere centered at <tt>position</tt> if <tt>cutoff</tt> is greater than 90 degrees )
|-
|<tt>nopreview</tt>
|Hide light volume in fgrun 3d preview
|-
|<tt>position</tt>
|In object space, position of the light
|-
|<tt>direction</tt>
|In object space, direction to the center of the spot
|-
|<tt>ambient</tt>
|Ambient color of the light
|-
|<tt>diffuse</tt>
|Diffuse color of the light
|-
|<tt>specular</tt>
|Specular color of the light
|-
|<tt>dim-factor</tt>
|Group of parameters to control a factor that is applied to ambient, diffuse and specular at the same time
|-
|<tt>attenuation</tt>
|Three element vector. <c> element is the constant factor, <l> element is the linear factor and <q> element is the quadratic factor. 
Attenuation of color at distance d is [[File:Spotlight_attenuation.png]]
|-
|<tt>exponent</tt>
|Attenuation is multiplied by <tt>pow( dot( lightDir, <direction> ), <exponent> )</tt>, lightDir being vector from light position to point, in camera space.
|-
|<tt>cutoff</tt>
|Point is lit by this source if <tt>dot( lightDir, <direction> ) > <cutoff></tt> , lightDir being vector from light position to point, in camera space.
|-
|<tt>near-m</tt>
|Minimum distance of influence, from position, in meters
|-
|<tt>far-m</tt>
|Maximum distance of influence, from position, in meters
|}
|}

==== Point lights ====
{|cellpadding=10|
|valign=top|
<syntaxhighlight lang="xml">
<animation>
<type>light</type>
<light-type>point</light-type>
<name>LightSrcRight</name>
<object-name>LightRight</object-name>
<nopreview/>
<position>
<x>0.169</x>
<y>0.570</y>
<z>0.713</z>
</position>
<ambient>
<r>0.03</r>
<g>0.03</g>
0.03
<a>1.0</a>
</ambient>
<diffuse>
<r>0.7</r>
<g>0.7</g>
0.6
<a>1.0</a>
</diffuse>
<specular>
<r>0.7</r>
<g>0.7</g>
0.7
<a>1.0</a>
</specular>
<dim-factor>
<property>dimming/property</property>

<expression />
<interpolation />
<factor>1</factor>
<offset>0</offset>
<min>0</min>
<max>1</max>

</dim-factor>
<attenuation>
<c>1.0</c>
<l>0.002</l>
<q>0.00005</q>
</attenuation>
<near-m>3.5</near-m>
<far-m>39</far-m>
</animation>
</syntaxhighlight>
|valign=top|
{| class="wikitable" cellpadding="3"
!Name
!Purpose
|-
|<tt>type</tt>
|Install the <tt>'''light'''</tt> animation
|-
|<tt>light-type</tt>
|This is a <tt>'''point'''</tt> light
|-
|<tt>name</tt>
|Name given to this animation
|-
|<tt>object-name</tt>
|Name of the light volume in the 3d model (typically a sphere centered on <tt>position</tt>, with a radius of <tt>far-m</tt>)
|-
|<tt>nopreview</tt>
|Hide light volume in fgrun 3d preview
|-
|<tt>position</tt>
|In object space, position of the light
|-
|<tt>ambient</tt>
|Ambient color of the light
|-
|<tt>diffuse</tt>
|Diffuse color of the light
|-
|<tt>specular</tt>
|Specular color of the light
|-
|<tt>dim-factor</tt>
|Group of parameters to control a factor that is applied to ambient, diffuse and specular at the same time
|-
|<tt>attenuation</tt>
|Three element vector. <c> element is the constant factor, <l> element is the linear factor and <q> element is the quadratic factor. 
Attenuation of color at distance d is [[File:Spotlight_attenuation.png]]
|-
|<tt>near-m</tt>
|Minimum distance of influence, from position, in meters
|-
|<tt>far-m</tt>
|Maximum distance of influence, from position, in meters
|}
|}

==== Performance and compatibility considerations ====
Every light on screen is equivalent for the GPU of redrawing the light volume with a shader, without z buffer culling. So each light comes with a cost, that is small taken individually but noticeable when a lot of them are visible. That cost also increase with the size of the light volume.

Beside that, it is wise to allow a model to work with the classical renderer that know nothing about lights and would render light volumes like other geometry. So a good practice is to complement each light animation with a select animation checking :
*if Rembrandt is enabled
*if the user selected quality match with the purpose of the light
*if the light should be on or off according to the other parameters of the simulation (position of the sun, position of switch, presence of power, ...)

A quality property is created to reflect the user preferences about quality vs performance concerning lights, and a proper slider is added to the shader dialog.
[[File:Fgfs-shaders-with-light.jpg|thumb|Light quality slider]]
The propery to use is :
/sim/rendering/shaders/lights
The quality slider sets its range from 0 (no lights) to 4 (all lights on). Simple airport lamp post appears at 1. Few bridge lamps at 2, all simple bridge lamp at 3 and more involved one at 4.

Example:
<syntaxhighlight lang="xml">
<animation>
<type>light</type>
<light-type>spot</light-type>
<name>LightSource</name>
<object-name>LightVolume</object-name>
...
</animation>

<animation>
<type>select</type>

<object-name>LightSource</object-name>
<condition>
<and>

<property>/sim/rendering/rembrandt/enabled</property>

<greater-than>
<property>/sim/rendering/shaders/lights</property>
<value>3.0</value>
</greater-than>

<greater-than>
<property>/sim/time/sun-angle-rad</property>
<value>1.57</value>
</greater-than>
</and>
</condition>
</animation>

</syntaxhighlight>

=== Tutorials ===
[[User:F-JJTH|F-JJTH]] compiled his experience and the one acquired by the PAF team converting aircraft in {{fr}} [http://equipe-flightgear.forumactif.com/t1034-howto-adapter-un-appareil-pour-rembrandt this tutorial],

== TODO List ==

=== Mac Issues ===
More and more Apple/Mac users are reporting issues related to running Rembrandt [http://forum.flightgear.org/search.php?st=0&sk=t&sd=d&sr=posts&keywords=rembrandt+mac].

Looking at the Mac GPU specs, it isn't clear if the Mac/ATI hardware/driver is generally insufficient, it should seem possible to run a customized Rembrandt setup with acceptable frame rates at 15-35 fps (assuming everything else being disabled for starters).

GLSL compilers have varying quality and especially the Mac (ATI/AMD) GLSL compilers are known to have issues with more sophisticated/nested constructs, so that it may help to reduce complexity of GLSL statements by splitting them up, instead of using nested anonymous vectors or functions (fatal error C9999: Nested functions, aborting!) for example.

So, the specific issue on Mac is some shaders being miscompiled, so the frame-rates are particularly bad, since the driver is hitting (slow) error paths. Certainly some Rembrandt-related shades fail to compile, though whether or not these are optional or required ones, isn't clear (Fred?). Some users reported that the errors and problems after upgrading their OS from OsX, 10.6.8 to OSX 10.8.2 (Mountain Lion) [http://forum.flightgear.org/viewtopic.php?f=47&t=19070&p=177106&hilit=rembrandt+mac#p177106] or OS Snow Leopard (10.6. to Mountain Lion (10.8.2), downloaded XQuartz 2.7.4 [http://forum.flightgear.org/viewtopic.php?f=21&t=19000&p=177570&hilit=rembrandt+mac#p176972].

The shader errors would suggest that certain GLSL constructs are not supported by the ATI/AMD glsl compiler - this seems to be a known issue: [https://groups.google.com/forum/?fromgroups=#!topic/comp.graphics.api.opengl/H_FLQCQE1i4] To address this, one would need to port the corresponding shaders - like just was done to get rid of the constructs that caused errors on old GeForce 7x generation hardware. It seems the hardware is not the problem, but the driver being way out of date. I find the fact that it's the Cg compiler and not a native glsl compiler that returns the errors very strange.

Another FG 2.10 user on MacPro 3.2 GHz Quad-Core Xeon, 8GB RAM, MacOS X 10.6.8. ATI Radeon HD 5870 (gl-vendor:ATI Technologies Inc., gl-version:2.1 ATI-1.6.36 gl-renderer:ATI Radeon HD 5870 OpenGL Engine, gl-shading-language-version:1.20) report said "Rembrandt is still unusable on my Mac. One frame every 4-5 seconds and it looks weird."[http://forum.flightgear.org/viewtopic.php?f=68&t=18839&p=175737&hilit=rembrandt+mac#p175684]

It's also worth noting that a number of FG 2.8 users reported that Rembrandt would still work for them using the 2.8 binary, unlike the 2.10 binary on Mac OSX version 10.7.5 on an iMac (AMD Radeon HD Graphics with 512MB) [http://forum.flightgear.org/viewtopic.php?f=21&t=19000&hilit=rembrandt+mac#p176460]. So the issue seems to occur largely in combination with older Mac OS versions and newer FG versions (>=2.8+) [http://forum.flightgear.org/viewtopic.php?f=4&t=19396&hilit=rembrandt+mac#p179456].

It appears it is the Rembrandt lighting causing issues while in non rembrandt mode with older Mac OS + FG 2.8 and better. On other OS setups, the rembrandt lighting gets ignored when rembrandt is turned off, but not in this case. Both lighting modes are present and creating the weird light cone effects [http://forum.flightgear.org/viewtopic.php?f=4&t=19396&hilit=rembrandt+mac&start=15#p179655].

If there are any console messages (like warnings or errors) shown, that would be helpful to know. A number of rembrandt related changes got fixed by Fred like this. Obviously, it is difficult for shader developers to troubleshoot shader related issues that they cannot reproduce with their own hardware.

Rembrandt is being largely developed by a single Windows/Nvidia-based developer, so it gets very little testing and debugging on different platforms, especially Mac/ATI (AMD) - so as a Mac user, your safest bet is probably providing lots of feedback via the forums (or preferably the issue tracker), FredB (the Rembrandt developer) is generally pretty responsive and appreciates all helpful feedback. Obviously, it helps being able to build from source, and being able to provide detailed troubleshooting reports.

These things are hard to debug/troubleshoot without having access to a corresponding system that exhibits the problem, which is why I suggested earlier to provide lots of Mac/Rembrandt-related feedback via the issue tracker, i.e. GLSL errors/warnings and anything else that could be useful.

If you have you ever tried to debug an issue that doesn't cause errors on your computer, you'll understand that it's damn difficult in the first place. Most developers don't own a Mac, and are not going to spend 1000$ or so just to have one more computer to test things on, and we don't know of anyone who buys computers for the whole purpose of testing FG on more platforms.

So as a rule we can try to pin down and solve such issues if, and only if, we get a decent bug report with tons of relevant background info and the possibility to ask follow-up questions. Remember, fixing such issues involves essentially working blind - it is trying to figure out why code that runs pefectly fine on your own computer might have issues on other computers and any traditional bug-hunting technique essentially fails.

Posting a screenshot of the issue is nice, but tells little more than that it exists. It's completely impossible to turn that into any action developer-side. The underlying shader code has probably a combined 1000 lines, any of which could be problematic.

Overall, the Rembrandt situation is most likely to improve the more feedback is provided by end users with different hardware/software configurations, Fred has fixed quite a number of shader related issues in the past, so it's largely a matter of time, and obviously the quality of feedback, provided by end-users like yourself.

And just in case: Note that GLSL shaders are not really compiled/built by developers (unlike the actual fgfs binary), but on an invididual basis by your GPU/graphics drivers, which happens transparently in the background, each time fgfs is started. Basically, a GLSL shader is a snippet of "source code" that is passed on to your GPU driver, which in turn compiles it down into hardware-specific instructions for your particular hardware.

From a troubleshooting perspective, it would be REALLY helpful if Mac users with the corresponding hardware and knowledge could come up with extremely downstripped test cases, that either show the problem, or which no longer show the problem as significantly. Disabling other shader-based features will definitely go a long way here, because many other GLSL features have not yet been explicitly ported to support Rembrandt.
In other words, you should preferably disable random building, advanced light scattern, advanced weather etc - and only really use the most basic settings to have an easily reproducable test case.

To get this started, you can customize the "zero eye candy" profile and enable Rembrandt using shader level 1: [[Howto:Debugging_FlightGear_Crashes#Minimal_Rembrandt_Startup_Profile]]

Some Mac folks have recently reported some success, it may be a good idea to search the forum for details, see for example:

* http://forum.flightgear.org/viewtopic.php?f=21&t=19000&p=177570&hilit=rembrandt+mac#p176972

{{cquote|I'm seeing regular crashes here from ALS and Rembrandt, but that's nothing new.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40024.html|title=<nowiki>Re: [Flightgear-devel] 2.10.1</nowiki>|author=Vivian Meazza|date=Fri, 03 May 2013 10:16:13 -0700}}</ref>|Vivian Meazza}}

{{cquote|With an AMD Radeon HD 5670 using free radeon driver I've never seen performance of more than 15fps with Rembrandt and if I turn shadow details up so they don't look crappy I get about 3-4fps.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40293.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stefan Seifert|date=Thu, 20 Jun 2013 10:10:56 -0700}}</ref>|Stefan Seifert}}

{{cquote|with a i3770K and a GTX670, I get some hit from ALS (10-30%) but Rembrandt instantly drops me to 20fps, and < 10fps I use an aircraft I actually want to fly (777 or Citation) and go to any major airport (EGKK, EHAM, EDDM, EDDF, EGLC, VHHH)

This is at 2560x1600, but on the 670 I would be highly surprised if I'm fill-rate limited, given that AA is off, and the general suboptimal size of our
primitive batches.

Emilian has explained on IRC this might be due to the out-of-the-box / default config for Rembrandt being highly suboptimal, which I didn't yet evaluate, I would be delighted to have it more usable.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40298.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=James Turner|date=Thu, 20 Jun 2013 13:29:47 -0700}}</ref>|James Turner}}

{{cquote|The Apple OpenGL renderer is a rather interesting beast - it's a clean-room front-end to the drivers, one of aspect of which means it is the only true 'Core Profile' 3.x renderer in wide use. (As opposed to the Ati and Nvidia Core profile drivers, which are simple the compat ones with some checks removed, I have been told). Of course FG is hence limited to 2.1 on Mac since we're a long way from Core profile support in the main code.

This does however mean it produces different GLSL compile issues, and different bugs in general, from the same hardware on other platforms.

(The renderer backend does of course come from the vendors, but OpenGL.framework always comes from Apple - it's not like Linux where your
libGL.so comes, at least potentially, from your hardware vendor)<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40083.html|title=<nowiki>Re: [Flightgear-devel] Shader compile failure</nowiki>|author=James Turner|date=Sat, 11 May 2013 06:53:32 -0700}}</ref>|James Turner}}

{{cquote|concerning the larger issue of different rendering pipelines / approaches, my opinion is, and remains, that the long-term solution is separate viewer codebases - while a plethora would be bad, we would already benefit from a 'fixed-function, no shaders' renderer codebase distinct from a Rembrandt renderer and modern, forward-rendering OpenGL 3.x pipeline. This needs the viewer to be cleanly split out from the simulation backend, via HLA, which is exactly what Mathias (and soon, myself) are working towards, but slowly.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39922.html|title=<nowiki>Re: [Flightgear-devel] Atmospheric Light Scattering</nowiki>|author=James Turner|date=Thu, 25 Apr 2013 08:09:08 -0700}}</ref>|James Turner}}

{{cquote|Like you and Thorsten, I see a very significant drop (50%) in frame-rate with Rembrandt, even without most the nice features such as shadows which has put me off using it. I had thought it was just because my box is now underpowered (the march of technology....) but it sounds like other are
seeing similar issues and it would be worth some further investigation.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40304.html|title=<nowiki>Re: [Flightgear-devel] reminder: entering feature freeze now</nowiki>|author=Stuart Buchanan|date=Fri, 21 Jun 2013 01:40:15 -0700}}</ref>|Stuart Buchanan}}

=== Completed tasks ===
*Fix shadow rendering when using multi threading in OSG
*Implement Cascaded Shadow Map (need to be optimized - frustum calculation and night)
*Honor 'noshadow' animation (done)
*See what happens with glow in fog : unknown landclass creates white patches in the emission buffer - scenery generation problem
*Test multi-screen (mostly done)
*Restore splashscreen
*Draw transparent objects with forward rendering (may need to capture the transparent bin from the geometry stage and move it in the display stage) (OK - needs model contribution)
*Add spotlights as animations (nearly finished)
*find a solution for ambient and emissive color of material (may need an additional buffer)
*Provide a shader for transparent objects that could render to the emissive buffer too (using MRT) not doable. Light pass can't use MRT
*Use stencil buffer to limit light range(no - done in light shader)
**needed for cockpit light to implement fake shadows and avoid lighting the runway from the cabin through the airframe
*Use effect system instead of hard-coded shaders
*Add new animation to link a light source to a model (need to provide point light animation duplicating spot light) (done)
*Tidy up the architecture (done)
*Global strength of glow or ambient occlusion via slider in rendering dialog
*Fix dim-factor in multiplayer mode (done)
*Design and implement a configurable pipeline (done)
*Document rendering pipeline configuration file format (done)
*Fix fog on clouds

=== Near term tasks ===
*Convert existing shaders to deferred rendering
*Avoid to redraw opaque objects in the light pass. Involve OSG node mask not properly initialized.
*take care of particles and precipitation
*Fix shadow matrices in multi-screen
*Fix Lights in multi screen (seems same problem than shadows. Forgot a 1/w factor ?)
*Implement lightfield shader
*Add some kind of fog to lights
*Restore depth partitioning using depth ranges
*Move effect of cloud coverage from water shader to sunlight shader
*Allow light masks using textures
*Use stencil double-sided operations to limit the depth of light volumes. Use depth clamp to ensure front faces are always rendered even if the camera is enclosed in the light volume.

=== Long term ideas (unsorted) ===
*Use a separate list of light volumes to avoid traversing the scenegraph again (with transparency problems). Find out how we can detect unloading of models.
*implement volumetric effects by extending lights to arbitrary shaders. Should enable to implement heat haze effect and real wake waves.
*implement strength of glow (in the emissive buffer alpha channel) - use a Poisson-disk distribution to implement variable size blur
**provide levels 0 to 5 - we are currently at level 5
**level 0 should be ok for MFDs that are currenly unreadable because blurred
*Modify shadows to allow multiple casters (limited list)
**Implement a priority list of light sources, based on priority and distance from the viewer
*Restore stereo and other options currently available in CameraGroup
*Implement quality vs performance user control

== Gallery ==
{{#ev:youtube|PXHhtQb5yzc}} {{#ev:youtube|peEzEapavkg}} {{#ev:youtube|RIetPh8iJXk}} {{#ev:youtube|oaNFrxgQY1c}} {{#ev:youtube|8xGzy12hlis}} {{#ev:youtube|ZyuHBlm3xXU}} {{#ev:youtube|RgH9GZRukOI}} {{#ev:youtube|UQvbHnBkpaM}} {{#ev:youtube|v02phoOqWHE}}{{#ev:youtube|dlSo4sBa7Nk}}

== Appendix ==
{{Appendix|all|
* {{cite web |url=http://http.download.nvidia.com/developer/presentations/2004/6800_Leagues/6800_Leagues_Deferred_Shading.pdf |title=Deferred Shading |author=Shawn Hargreaves and Mark Harris }}
* {{cite web |url=http://bat710.univ-lyon1.fr/~jciehl/Public/educ/GAMA/2007/Deferred_Shading_Tutorial_SBGAMES2005.pdf |title=Deferred Shading Tutorial |author=Fabio Policarpo and Francisco Fonseca }}
* {{cite web |url=http://www.guerrilla-games.com/publications/dr_kz2_rsx_dev07.pdf |title=Deferred Rendering in Killzone 2 |author=Michal Valient |month=July |year=2007 }}
* {{cite web |url=http://www.anandtech.com/show/5011/nvidiaea-posts-battlefield-3-graphics-tech-talk |title=Battlefield 3 Graphics Tech Talk |author=Johan Andersson |month=October |year=2011 }}
* {{cite web |url=http://www.disney.co.uk/cms_res/blackrockstudio/pdf/Rendering_Techniques_in_SplitSecond.pdf |title=Rendering Techniques in Split/Second |author=Jeremy Moore and David Jefferies |year=2009 }}
* {{cite web |url=http://www.crytek.com/sites/default/files/A_bit_more_deferred_-_CryEngine3.ppt |title="A bit more Deferred" - CryEngine 3 (PPT) |author=Martin Mittring }}
* {{cite web |url=http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter09.html |title=Deferred Shading in S.T.A.L.K.E.R. |author=Oles Shishkovtsov }}
* {{cite web |url=http://http.developer.nvidia.com/GPUGems3/gpugems3_ch19.html |title=Deferred Shading in Tabula Rasa |author=Rusty Koonce }}
* {{cite web |url=http://aras-p.info/texts/CompactNormalStorage.html |title=Compact Normal Storage for small g-buffers |author=Aras Pranckevičius |date=4 August 2009 |accessdate=12 April 2012 }}
* {{cite web |url=http://the-witness.net/news/2010/03/graphics-tech-shadow-maps-part-1/ |title=Graphics Tech: Shadow Maps (part 1) |author=Jonathan Blow |date=3 March 2010 |accessdate=13 April 2012 }}
* {{cite web |url=http://directtovideo.wordpress.com/2009/11/13/deferred-rendering-in-frameranger/ |title=deferred rendering in frameranger. |author=Matt Swoboda |date=13 November 2009 |accessdate=8 July 2012 }}
* {{cite web |url=http://publications.dice.se/publications.asp?show_category=yes&which_category=Rendering |author=DICE |title=Publications on rendering |accessdate=15 August 2012 }}
* {{cite web |url=http://advances.realtimerendering.com/s2012/Epic/The%20Technology%20Behind%20the%20Elemental%20Demo%2016x9.pptx |author=Martin Mittring |title=The Technology behind the Unreal Engine 4 Elemental Demo |accessdate=15 September 2012 }}
}}

<references/>

[[Category:Shader development]]
[[Category:Core development projects]]
[[fr:Projet Rembrandt]]

Changelog 3.2

2014-10-12T17:06:21Z

F-JJTH: remove terrain simplifier stuff

{{draft|changelog|This changelog is currently being written for the FlightGear 3.2 release. To see what is being worked on, check out [[Changelog 3.2]].
Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog. It's a good idea to check [[:Category:Changes_after_3.00|the newsletters since the last release]], and the git commit history.
To view the changelog for the most recent release, please see [[Changelog 3.0]].
We also encourage people to help by translating the changelog and appreciate all contributions, however please keep in mind that this changelog is not yet final!

}}

==Upcoming FlightGear Changelog==
The FlightGear development team is delighted to announce the v3.2 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include ...

Founded in 1997, FlightGear is developed 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.

FlightGear features more than 400 aircraft, a worldwide scenery database, a multi-player 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.

Download FlightGear v3.2 for free from [http://www.flightgear.org FlightGear.org].

FlightGear - Fly Free!

=== Breaking Changes ===

=== Major enhancements in this release ===

'''Surface Light Effects & OpenSceneGraph 3.2'''

Stuart committed a change that brings surface lights, including VASI/PAPI/taxi/runway etc. into the xml-defined Effects framework. Kudos to Tim Moore for his original Effects work - it made it very straightforward to enhance with support for point sprites and a custom texture generator required.

The relevant effect is data/Effects/surface-lights.eff. It should allow development of ALS and Rembrandt variants.

Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow. So, if your
build fails, please check you've got a recent OSG build installed.

'''Core'''
* [[Reset & re-init]] is merged and now enabled
* A segfault related to scripted Nasal fgcommands (like used in joystick and other bindings) has been fixed {{Issue|1397}}
* YASim versioning support for maintenance fixes (TorstenD)
* FLITE TTS support
* Windows dependencies have been updated
* The integrated [[Map]] dialog now uses an azimuthal equidistant projection, for better representation in polar regions and across the International Date Line.

'''Aircraft Modeling'''
* [[A Failure Management Framework for FlightGear]] has been added
* Additional aircraft have started adopting the [[NavDisplay|Canvas navigation display]] that was introduced with FlightGear 3.0.

'''JSBSim'''
* The JSBSim flight dynamics model now has support for ground effects like bumpiness, solid-ground detection and adjusting of friction factors. Additionally, bogey type contact points sink in non-solid surfaces, making it no longer possible to ride on water.

'''Atmospheric Light Scattering'''

Atmospheric Light Scattering (ALS) is one of FlightGear's three rendering frameworks, with the aim of providing an integrated simulation of the interaction between weather, light and the environment.

Additions to ALS in version 3.2 include:

* an experimental framework to render cloud shadows on the ground (requires Advanced Weather)
* a substantial extension of cloud layer visibility using impostor techniques to 150 km
* a new agriculture effect allowing to render fields without tiling artifacts
* a new forest effect to simulate managed forest, varying tree size by patch
* sparkle and fog effect on runway lights
* much improved visual appearance of rock faces

'''Environment Rendering'''

* EarthView, a simple orbital rendering engine based on projecting a textured sphere into the scene. By default, EarthView uses low resolution textures, however using hires textures e.g. from the NASA [http://visibleearth.nasa.gov/ Visible Earth] project very realistic results from altitudes above 100 km can be achieved.
* New deciduous and needle tree textures with much improved visuals
* New regional texture definitions for Ireland, Alaska/Northwest territories and US Southwest

'''Performance'''

'''Misc/Uncategorized'''
* AIModels use PagedLOD
* Optimise NavCache airport query
* osg::Switch for masking scenery rendering
* Torsten's metar work, newradio, mongoose httpd
* HTTP: improve handling of connection errors
* Windows installer has been reworked
* Windows installer creates 3 news directories pre-configured in FGRun:
** {user}\Documents\FlightGear\Aircraft
** {user}\Documents\FlightGear\TerraSync
** {user}\Documents\FlightGear\Custom Scenery

''' Usability '''
* Windows users are now able to use the scroll wheel in dialog lists

''' Scenery '''

'''Canvas System'''

FlightGear's fully scriptable 2D rendering system now includes improved APIs for creating maps and navigation displays amongst many other improvements. People no longer need to have programming experience to add a working ND to their aircraft, it can now be all done by copying and pasting 30 lines of text and customizing a few properties. The so called MapStructure back-end handles efficient updating of all ND layers transparently. Also, maps can now be mostly customized, including custom styling (colors, fonts, symbols etc).

* Tom has pushed an update to git (simgear) which removes a lot of unneeded OpenGL state changes for Canvas paths. Depending on the GPU/driver this can lead to quite a noticeable performance improvement. For example, he was able to get from ~120ms down to ~45ms [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].

* The [[MapStructure]] back-end used by the [[NavDisplay]] now supports symbol instancing, so that performance is improved
* MapStructure-based layers can now be customized and styled
* Tom added support for button/modifiers (mouse handling) [http://wiki.flightgear.org/index.php?title=Canvas_Event_Handling&curid=10777&diff=68569&oldid=68422]
* CanvasImage now supports the ''http://'' protocol for dynamically retrieving raster images. See the renamed [[Canvas_Image#src|src attribute]] (''file'' is now deprecated).
* As part of the ongoing effort on [[Unifying the 2D rendering backend via canvas]], we have started re-implementing the integrated [[Map]] dialog using Nasal & Canvas instead of C++ {{Progressbar|80}}
* Custom event handlers can now be registered.
* Canvas Layout Engine
* Canvas-based dialog for downloading aircraft [[Aircraft Center]]

'''Nasal Scripting'''

* getprop()/setprop() arguments (those that form a path) can now be numeric to specify a index, so:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index", "texture", 1, "name");
</syntaxhighlight>
: is now the same as:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index/texture[1]/name");
</syntaxhighlight>
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request 54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])
* A new fully-interactive Nasal GUI console based on [[Canvas]] has been added: [[Interactive Nasal Console]]
* the hard-coded '''flight path history''' subsystem which samples aircraft position, which was previously only accessible to C++ code, has now been exposed to scripting space by Tom so that people can easily access the system and reuse the data for their own purpoes (e.g. for creating an instructor console). The first use-case will involve the new [[Canvas]] based [[Map]] dialog which will be 100% scripted by then.
: Usage:
<syntaxhighlight lang="nasal">
var hist = aircraft.history(); debug.dump(hist.pathForHistory(50));
</syntaxhighlight>
* cppbind: Nasal ghosts can now support arbitrary setters/getters for when members are not mapped to a C++ member/method.
* Language enhancements
** Bitwise operators (|, &, ^, ~, |=, &=, ^=)
** Support for octal, decimal and hexadecimal numbers in literals as well as in strings

'''Documentation'''

'''Highlighted new and improved aircraft'''
* [[Boeing 757-200]]: Improved autopilot and additional systems, like hydraulics and pneumatic. The aircraft comes with two engine options.
* [[Cessna 337G Skymaster]]: Tuned autopilot and improved instrument stack.
* [[Mainair Flash 2 Alpha]]: Simulated weightshift-control and new wing model.
* [[North American P-51 Mustang|North American P-51D]]: All new highly accurate external model based on factory blueprints.
* [[Tupolev Tu-154B|Tupolev Tu-154B2]]: version 3.1

'''Other'''

'''Bug fixes'''
* See [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=Milestone%3D3.2 our bugtracker] for an extensive, yet incomplete, list of the bugs fixed in this release.

[[Category:FlightGear changelogs]]

Release plan

2014-10-05T18:36:17Z

F-JJTH: /* Detailed time schedule and checklist */

{{GitStatus}}

This page contains details about how to release a new version of [[FlightGear]] into the wild. It is a continous work in progress to be improved with every new release.

[[File:ReleasePlan.jpg|thumb|250px|The original plan]]
This '''release plan''' was originally developed by Mathias Fröhlich, Martin Spott, Thorsten Brehm and Torsten Dreyer during LinuxTag 2011.

If you think you have something to contribute to the release process, feel free to [{{SERVER}}{{localurl:{{NAMESPACE}}:{{PAGENAME}}|action=edit}} edit this page]. In particular, improvements should be based on [[Release plan/Lessons learned]] from past releases. Please discuss this concept at the mailing-list.

== General release concept ==
New FlightGear releases are scheduled twice a year. The magic number to remember is 17 (we tried 42, but that didn't turn out so well. 17 is perfect: 1 is not a prime, 7 is a prime and so is 17). On the 17th of January (1) and July (7) a new release branch is created for [[SimGear]], FlightGear and FGDATA.

{{cquote|As a clarification: We do not enter a code freeze but a feature freeze. Code changes are welcome after December 17th as long as it is guaranteed (not just "unlikely") that they do not introduce any side effects and become a release blocker. It is the sole responsibility of the commiter to decide if that is the case or not. Every new feature that didn't make it into the respository by the deadline may probably easily wait for another four weeks to get commited. Remember: most aircraft are not affected by the feature freeze and aircraft developers quickly adopt and use new features as they become available<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38749.html|title=<nowiki>[Flightgear-devel] Next FlightGear release (Feb. 17 2013)</nowiki>|author=Torsten Dreyer|date=16 November 2012}}</ref>|Torsten Dreyer}}

After branching, there is one month for bug fixing in the release branch, so building and packing of the binaries and FGDATA takes place around February, 18th and August, 18th. Allowing a few days for distribution of the files, new versions should be publically available around the 20th of February and August.

The development stream of SimGear, FlightGear, FGRun and FGDATA is set into a frozen state one month before the branch-day (17th), to let the dust of development settle and to allow fixing the most annoying bugs in the code. During this period, developers should not add any new features, subsystems, and the like. Immediately after the stream has branched for the release, development in the main stream (next/master) is open for major changes until one month before the next branch-day. This results in a duty cycle of 5 month developing and 1 month thinking.

== Version numbers ==
FlightGear version numbers consist of three digits, seperated by dots:
* '''Major''' (2.4.1): is only increased after significant changes to the functionality of the software, i.e. 1.X.X => 2.0.0 (due to switch to OSG).
* '''Minor''' (2.4.1): has two applications:
** '''Stable releases''' always have ''even numbers'', i.e. 2.6.0, 2.8.0, 3.0.0.
** The '''development stream''' (''latest Git version'') uses an ''odd number'', increasing the minor number of the latest stable release's version by one. I.e., when the latest release was 2.8.0, the current development stream is 2.9.0.
* '''Revision''' (2.4.1): is increased by bugfix releases, i.e. 2.8.1, 2.8.2, 2.8.3.

When referring to a major release in general, only the first two digits should be used, i.e. 2.6 refers to 2.6.0, 2.6.1 etc.

== Detailed time schedule and checklist ==
# '''Dec/Jun 17th:''' Development stream is declared "frozen" or "yellow"
##Send a mail to the flightgear-devel mailing-list to announce the state, add a call for screenshots
##Create a "release preperations" topic at the forum and make it a "Global Announcement", add a call for screenshots
##Change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:frozen}}</nowiki></code>
##Bump up the version-number of simgear/next, flightgear/next, fgrun/next and fgdata/master to an even number (2.9.0 -> 3.0.0)
##Compile and test drive FlightGear with the new version-number
##Commit the new version number to next (flightgear+simgear+fgrun) and master(fgdata)
##Tag (annotated) flightgear, simgear, fgrun and fgdata with <tt>version/3.0.0</tt>
##:<code>git tag -a version/3.0.0</code> (Enter a wise comment)
##Push the branches next/master '''and''' the tags upstream
##:for flightgear, fgrun and simgear: <code>git push origin next</code>
##:for fgdata: <code>git push origin master</code>
##:for the tags (all repos): <code>git push origin version/3.0.0</code>
# '''Jan/Jul 17th:''' Create new release branch, assign new version number to dev-stream, re-open streams

##Pull current Git, create the release branches (for sg/fg/fgrun/fgdata):
##:<code>git pull</code>
##:<code>git branch release/3.0.0</code>
##On the next/master branches, bump up the version-number of simgear, flightgear, fgrun and fgdata to an odd number (3.0.0 -> 3.1.0)
##Compile and test drive FlightGear with the new development version number
##Commit the changes of version-number to next/master
##Tag (annotated) flightgear, simgear, fgrun and fgdata with "version/2.9.0"
##:<code>git tag -a version/2.9.0</code> (Enter a wise comment)
##Push the branches next/master '''and''' release/3.0.0 '''and''' the tags upstream
##:for flightgear, simgear, fgrun and fgdata: <code>git push origin release/3.0.0</code>
##:for flightgear, fgrun and simgear: <code>git push origin next</code>
##:for fgdata: <code>git push origin master</code>
##:for the tags (all repos): <code>git push origin version/3.1.0</code>
##Declare dev-streams "open" or "green"
##: Ask a [http://wiki.flightgear.org/index.php?title=Special:ListUsers&group=sysop wiki admin] to change the content of wiki template at [[Template:GitStatus]] to <code><nowiki>{{GitStatus:open}}</nowiki></code>
##:Send a mail to the flightgear-devel mailing-list to announce the state.
## Trigger James or Clément for the Jenkins-builds and Curt for a snapshot release and ThorstenB for the OpenSuse build
##:in fgmeta:
##:<code>git checkout release/3.0.0</code>
##:<code>git submodule foreach git checkout release/3.0.0</code>
##:<code>git submodule foreach git pull -r</code>
##:<code>git add .</code>
##:<code>git commit -m "Bump revision"</code>
##:<code>git push origin release/3.0.0</code>
# '''Feb/Aug 1st:''' Start preparing the release notes and a press announcement
# '''Feb/Aug 17th:''' Create binaries/installers, pack fgdata, publish files, announce new version, close the release-branch.
## Generate latest '''getstart.pdf''', push the PDF to fgdata/master - and cherry-pick to the '''release branch'''. Generate latest '''getstart''' HTML, push PDF and HTML to the MapServer site.
##Tag the release/3.0.0 branches of simgear, flightgear, fgrun and fgdata and push the tags.
##:for flighgear, simgear, fgrun and fgdata: <code>git tag version/3.0.0-final</code>
##:for flighgear, simgear, fgrun and fgdata: <code>git push origin version/3.0.0-final</code>
##Merge the branch release/3.0.0 into '''master''' ('''NOT''' next) for flightgear and simgear and push the branch
##:We don't have a next branch for fgdata, no merging of the release branch here.
##:for flighgear, fgrun and simgear:
##:<code>git checkout -b master origin/master</code> or <code>git checkout master</code> if you already have the local branch
##:<code>git merge version/3.0.0-final</code>
##:<code>git push origin master</code>
##[[:Category:FlightGear Core developers|Core developers]] and other contributors should be invited to add their release related experiences (i.e. suggestions for improvements) to the wiki to help update and improve the release plan (i.e. this page) accordingly.

== To bump up the version number ==
* [https://gitorious.org/fg/fgdata FGData]
** edit the ''version'' file
* [https://gitorious.org/fg/simgear SimGear]
** edit the ''version'' file
* [https://gitorious.org/fg/flightgear FlightGear]
** edit the ''version'' file
* [https://gitorious.org/fg/fgrun FGRun]
** edit the ''version'' file

== Definition of repository states ==
{| class="wikitable"
!
! State
! Description
|-
! [[File:Traffic light green.png|20px]]
! Open/Green
| Normal development of the code base and fgdata. Unrestricted (well, sort of) access to the streams. This state lasts for five months after the release branches were created.
|-
! [[File:Traffic light yellow.png|20px]]
! Frozen/Yellow
| No new features or major changes shall be pushed onto the development streams (neither source nor data). This period is for preparing the code for the release and make sure there are no major issues. It lasts for four weeks until creation of the release branches.

It's a good idea for aircraft developers to adhere to this rule. However, aircraft in fgdata may be handled as an exception from the frozen state. Any change to aircraft may be pushed to the repository if it is guaranteed that this change does not affect any other aircraft or system and if no file outside the root directory of that specific aircraft is changed. Also, aircraft defined as part of the base package (e.g. the c172p) enter the frozen state and shall not undergo major changes in that period.
|-
! [[File:Traffic light red.png|20px]]
! Closed/Red
| Nothing shall be pushed to the development streams (simgear, flightgear, fgrun and fgdata). This state is for creating the release branches. It lasts for just a few hours on Jan 17th and Jul 17th around 12:00 UTC.
|}

== Bug fix committing policy ==
Fixes for bugs during the shakedown test of the release branch may be applied to the branches next or release/2.8.0.
A fix goes into release/2.8.0 if the development of next has moved forward and this fix does not apply there. It also goes into the release branch if there will be a better fix for next.
A fix goes into next if it is also solves an issue for the next version. Cherry-pick this commit into the release/2.8.0 branch.

'''DO NOT''' merge next into release/2.8.0 or vice versa. Most likely, there will be commits that are not welcome in or even break the other branch.

== Bug tracking ==
The [http://flightgear-bugs.googlecode.com bugtracker] will be our primary source for the bug fixing period. Bugs reported on the mailing list or forum will not be tracked! Reporters shall be requested to file a bug report at the bugtracker. Bugs shall be assigned a priority and a keyword to make the assignment to a developer easier. Bug reports that can't be confirmed or need more input from the reporter to get fixed will be assigned a new state "stalled" and only processed after more information has been provided. Bugs assigned a high priority will be downgraded, if no progress has been made over a certain amount of time. This is to prevent the release from being blocked by a bug that no developer is able (or willing) to fix. The only exception is "does not compile for one of the major platforms", which certainly is a release-blocker.

Bugs that were present in the latest stable release, and now considered "fixed", should be assigned a milestone label, corresponding with the upcoming stable release number. By doing so, they'll end up in [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=label%3AMilestone-2.12.0 the list of fixed bugs].

=== Tasks and owners ===

The following table should be updated and augmented after each release, according to the [[Release plan#Lessons learned|Lessons learned]] section below.

{|class="wikitable"
!
! width="500px" | Task
! Owner(s)
! Status for [[Changelog 2.12|2.12]]
|-
! rowspan="7" |
| Announce the state-change of the dev-streams, '''cross-post to JSBSim list''' (see lessons learned!)
| TorstenD
|
|-
| Create/maintain the git branches
| TorstenD
|
|-
| Track the bugs on the tracker, trigger developers, adjust bug-priorities
| ThorstenB, Gijs, James, ...
|-
| Sync the language files so they can be translated
| ThorstenB, James
|
|-
| Beta testing
| '''EVERYBODY'''
|-
| Update documentation: [[FAQ]], [https://www.gitorious.org/fg/getstart/ The Manual], wiki
| Stuart, Gijs and anyone else
|
|-
| Pack RC and final version of FGDATA
|
|-
! rowspan="5" | Create the RC and final version
| Source-tarball
| Curt
|-
| Linux
| ThorstenB (for openSUSE)
|-
| Windows
| Curt
|
|-
| MacOS
| Tat/James
|
|-
| Distribute files to download servers
| Curt
|
|-
! rowspan="3" | Make adjustments on the web-site
| Collect/make screenshots for the gallery
| Curt
|-
| Generate aircraft page
| Curt, Gijs
|-
|-
| Tag the [http://wiki.flightgear.org/index.php?title=Talk:Next_newsletter&action=edit&section=45 newsletter template] according to the released version
<nowiki>[[Category:Changes after 2.12]]</nowiki>
| Hooray, Gijs, Stuart (other wiki admins)
|-
! rowspan="2" | Announce the new version to the public
| Write a changelog: [[Next Changelog]]
| All developers/contributors
|-
| Contact flightsim websites and send them/link them to the "press announcement". See [[release promotion]] for a list of already-contacted and yet-to-contact websites/magazins.
| '''EVERYBODY'''
|}

== Open items, questions ==
* Automate and/or document the creation of RC's: "We need to get this automated some day. Or at least documented...(another one from "famous last words": if you have to do it more than once, automate it. If you can't automate it, document it."<ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39205.html |title=<nowiki>Re: [Flightgear-devel] Release candidates</nowiki> |author=Torsten Dreyer |date=29 January 2013}}</ref>
* <del>Automate the creation of Windows and Mac installers</del> {{Done}} <ref>http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40650.html</ref> (see [[FlightGear Build Server]])
* Automate the creation of FGDATA distribution
* Possibly try to find a way to automate testing of updated jsbsim code, so that the chance for breakage is reduced by running scripted tests <ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg39109.html |title=<nowiki>Re: [Flightgear-devel] [Jsbsim-devel] JSBSim Synch with FlightGear</nowiki> |author=Torsten Dreyer |date=13 January 2013}}</ref><ref>{{Cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg40201.html |title=<nowiki>Re: [Flightgear-devel] JSBSim Synch with FlightGear</nowiki> |author=Anders Gidenstam |date=11 June 2013}}</ref><ref>
{{Cite web |url=http://sourceforge.net/p/flightgear/mailman/message/31762085/
|title=<nowiki>Release preparations - feature freeze starts today</nowiki> |author=Anders Gidenstam |date=2013-12-17 19:46:48}}
</ref>

== Lessons learned ==
See [[Release plan/Lessons learned]] for a list of things that turned out well and should be kept for the next release as well as thing that didn't turn out so well and should be changed for future releases. Ideally, the release plan should be updated and augmented so that the lessons learned are incorporated accordingly.

{{Appendix}}

[[Category:Core developer documentation]]
[[Category:FlightGear]]

Modelling guidelines

2014-09-23T21:24:17Z

F-JJTH:

{{Merge|Modeling - Getting Started#Improving models for best FlightGear performance}}

When modelling an aircraft, building or any other 3D model, you are encouraged to follow the '''modelling guidelines''' outlined in this article.

Feel free to add/modify. (''please leave a comment in the [[Talk:Modelling guidelines|talk page]] for radical modifications'').

== Definitions ==
*Model = the file.
*Object/Mesh = part of the Model file. The Model can contain several Objects.
*Texture = image file (.rgb, .png).

== Modelling guidelines ==
*Vertices are free up to a point - use as many as you need.
*Many small (in vertex numbers) Objects/Meshes have a far worse negative impact on performance than a single Object/Mesh with very high vertex numbers.
*Combine all different parts of the Model into one single Object/Mesh, with the exception of parts that need to be animated, or of transparent parts.
** '''Blender''': Select some objects and press {{Key press|Ctrl|J}} to join them into one Object. The new object origin/transform/orientation/name will be based on the ones of the last object selected.
*Use different unique names for each of the Objects in a Model file. Even more so when the different parts need to be animated.
*Make all faces of the objects single sided.
*If you need a part of the model to be visible from both sides, duplicate it in place and flip the normals. The extra geometry overhead is negligible compared to the extra work generated by double-sided faces.
*Split transparent parts into their own objects.
** '''Blender''': Go into Edit Mode, select the part of the object that you would like to split and press {{Key press|P}}.
*Assign to all transparent Objects at least the ''model-transparent'' effect:
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/model-transparent</inherits-from>
<object-name>Transparent-object1</object-name>
<object-name>Transparent-object2</object-name>
<object-name>Transparent-object3</object-name>
<object-name>other-Transparent-object</object-name>
</effect>
</syntaxhighlight>
*The interior should be a separate Model. Having it separate enables delayed loading of such models in multiplayer/AI contexts.
Only one instance of the tag is allowed for the whole aircraft. Such a model is specified as follows in the .xml file:
<syntaxhighlight lang="xml">
<model>
<usage>interior</usage> 
<path>Models/your-interior-model.xml</path>
</model>
</syntaxhighlight>

If your <model> require an <offsets> you must move the <offsets> section in the children XML like:

your/aircraft/Models/aircraft.xml:
<syntaxhighlight lang="xml">
<PropertyList>
<path>path/to/model.ac</path>
<model>
<path>your/aircraft/Models/Interior/model.xml</path>
<usage>interior</usage>
</model>
...
</PropertyList>
</syntaxhighlight>

your/aircraft/Models/Interior/model.xml:
<syntaxhighlight lang="xml">
<PropertyList>
<path>path/to/another/model.ac</path>
<offsets>
<x-m> -1.91552 </x-m>
<y-m> 0.00000 </y-m>
<z-m> 0.23706 </z-m>
<roll-deg> 40.0 </roll-deg>
<pitch-deg> 35.0 </pitch-deg>
<heading-deg> 60.0 </heading-deg>
</offsets>

<model>
<path>path/to/another/model.xml</path>
</model>
...
</syntaxhighlight>

== Texturing guidelines ==
*Combine as many parts of a single Model to a single texture as you can - the maximum texture size is 4096 x 4096 pixels.
*Do not assign multiple textures to the same Object/Mesh. The Object will be split so as to have a single texture/Mesh.
*Do not use different parts of a single texture for different models. Split the texture into smaller parts then.
*If using the same texture on multiple models, use a single file, do not make different copies.
*Prefer texture replacing animations to textranslate for models that spend large amounts of their time in one state (day/night animations).
*Avoid transparency like the plague, it kills frame rate like nothing else: remove the alpha channel from textures if they are non-transparent.
** '''GIMP''': Go to <tt>Layers > Transparency > Remove alpha layer</tt>.
** '''Inkscape''': Go to <tt>File > Document Properties</tt> and set the "Background" to a non transparent colour (preferably black).
*Hive off transparent parts of textures into their own textures.
*Use power of two dimensions for textures (2n, e.g. 256x256, 512x1024). Do not worry if your image would get stretched in the texture, you can fix that with the mapping on the model.
*Do not have textures with the image in one corner and the rest unused.
*Recommended texture format is: '''.png'''. In general any texture format supported by OSG could be used, but be aware of varying cross-platform support for such formats, or of lossy compression.
 

[[Category:Modeling]]

Modelling guidelines

2014-09-23T11:16:13Z

F-JJTH: /* Modelling guidelines */

{{Merge|Modeling - Getting Started#Improving models for best FlightGear performance}}

When modelling an aircraft, building or any other 3D model, you are encouraged to follow the '''modelling guidelines''' outlined in this article.

Feel free to add/modify. (''please leave a comment in the [[Talk:Modelling guidelines|talk page]] for radical modifications'').

== Definitions ==
*Model = the file.
*Object/Mesh = part of the Model file. The Model can contain several Objects.
*Texture = image file (.rgb, .png).

== Modelling guidelines ==
*Vertices are free up to a point - use as many as you need.
*Many small (in vertex numbers) Objects/Meshes have a far worse negative impact on performance than a single Object/Mesh with very high vertex numbers.
*Combine all different parts of the Model into one single Object/Mesh, with the exception of parts that need to be animated, or of transparent parts.
** '''Blender''': Select some objects and press {{Key press|Ctrl|J}} to join them into one Object. The new object origin/transform/orientation/name will be based on the ones of the last object selected.
*Use different unique names for each of the Objects in a Model file. Even more so when the different parts need to be animated.
*Make all faces of the objects single sided.
*If you need a part of the model to be visible from both sides, duplicate it in place and flip the normals. The extra geometry overhead is negligible compared to the extra work generated by double-sided faces.
*Split transparent parts into their own objects.
** '''Blender''': Go into Edit Mode, select the part of the object that you would like to split and press {{Key press|P}}.
*Assign to all transparent Objects at least the ''model-transparent'' effect:
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/model-transparent</inherits-from>
<object-name>Transparent-object1</object-name>
<object-name>Transparent-object2</object-name>
<object-name>Transparent-object3</object-name>
<object-name>other-Transparent-object</object-name>
</effect>
</syntaxhighlight>
*The interior should be a separate Model. Having it separate enables delayed loading of such models in multiplayer/AI contexts.
Only one instance of the tag is allowed for the whole aircraft. Such a model is specified as follows in the .xml file:
<syntaxhighlight lang="xml">
<model>
<usage>interior</usage> 
<path>Models/your-interior-model.xml</path>
</model>
</syntaxhighlight>

If your <model> require an <offsets> you must create a proxy XML like:

your/aircraft/Models/aircraft.xml:
<syntaxhighlight lang="xml">
<model>
<path>your/aircraft/Models/Interior/model-proxy.xml</path>
<usage>interior</usage>
</model>
</syntaxhighlight>

your/aircraft/Models/Interior/model-proxy.xml:
<syntaxhighlight lang="xml">
<model>
<path>your/aircraft/Models/Interior/model.xml</path>
<offsets>
<x-m> -1.91552 </x-m>
<y-m> 0.00000 </y-m>
<z-m> 0.23706 </z-m>
<roll-deg> 40.0 </roll-deg>
<pitch-deg> 35.0 </pitch-deg>
<heading-deg> 60.0 </heading-deg>
</offsets>
</model>
</syntaxhighlight>

== Texturing guidelines ==
*Combine as many parts of a single Model to a single texture as you can - the maximum texture size is 4096 x 4096 pixels.
*Do not assign multiple textures to the same Object/Mesh. The Object will be split so as to have a single texture/Mesh.
*Do not use different parts of a single texture for different models. Split the texture into smaller parts then.
*If using the same texture on multiple models, use a single file, do not make different copies.
*Prefer texture replacing animations to textranslate for models that spend large amounts of their time in one state (day/night animations).
*Avoid transparency like the plague, it kills frame rate like nothing else: remove the alpha channel from textures if they are non-transparent.
** '''GIMP''': Go to <tt>Layers > Transparency > Remove alpha layer</tt>.
** '''Inkscape''': Go to <tt>File > Document Properties</tt> and set the "Background" to a non transparent colour (preferably black).
*Hive off transparent parts of textures into their own textures.
*Use power of two dimensions for textures (2n, e.g. 256x256, 512x1024). Do not worry if your image would get stretched in the texture, you can fix that with the mapping on the model.
*Do not have textures with the image in one corner and the rest unused.
*Recommended texture format is: '''.png'''. In general any texture format supported by OSG could be used, but be aware of varying cross-platform support for such formats, or of lossy compression.
 

[[Category:Modeling]]

FlightGear Newsletter September 2014

2014-09-21T21:16:14Z

F-JJTH:

{{Newsletter-header|September 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}} 
{{Newsletter-cover-item|DDS feedback needed}} 
{{Newsletter-cover-item|Aircraft moved to SVN}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Using Ada in FlightGear}} 
{{Newsletter-cover-item|Performance issues}} 
{{Newsletter-cover-item|The hidden Map}} 

| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}} 
{{Newsletter-cover-item|Improve the multiplayer experience}} 
|}
</div>

== DDS feedback needed ==

We are looking for feedback about possibly adopting DDS textures in FlightGear. There are several advantages in doing so:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by most Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.

Continue reading at [[Switching default texture format to DDS]]...

== Aircraft moved to SVN ==
Some months ago we decided to host our aircraft on an SVN repository in order to relieve <code>fgdata</code>.
The <code>fgdata</code> repo would be a mirror of the base package.

We finally moved all our aircraft to '''the new SVN repo''': http://sourceforge.net/p/flightgear/fgaddon/

This repository is named "FGAddon" because its content is not required to run FlightGear but provides a new feature (aircraft in this case); this is usually called an "addon".

=== Advantages ===
On the user side, the most important feature is to be able to checkout only desired aircraft, as you no longer need to download the 400+ aircraft at once.

On the developer side, the most important interest is to have a base package (<code>fgdata</code>) which is lighter to sync for new contributors and easier to keep up to date.

=== A mini HowTo ===
* For Windows: Install TortoiseSVN (http://tortoisesvn.net/)
* For Linux/Mac: Install SVN

Then to fetch an aircraft (in this example we pick up the [[Robin DR400 Dauphin|DR400 Dauphin]]):
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DR400-dauphin

Then you can regularly fetch the latest updates with
svn up

If you are used to use Git, <code>svn co</code> and <code>svn up</code> are similar to <code>git clone</code> or <code>git pull</code>.

The aircraft will remain in the <code>fgdata</code> Git repository for a few months, until everyone has transitioned to the SVN repositories.

=== Background ===
For our aircraft developers who don't regularly read the mailing list (even though any aircraft developers should already be subscribed), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971

== Using Ada in FlightGear ==
[[File:FlightGear built using gnatmake.png|thumb|FlightGear built with optional support for Ada]]

Recently, we've had an interesting discussion on the forum where some of FlightGear's threading issues were discussed, and a few contributors mentioned that Ada would have better tasking support than C++ because C++ support for tasking/multi-threading is generally considered fairly "low-level". Other programming languages, like Ada, provide native support for multi-threading using built-in primitives like '''tasks''' and '''protected types'''.

Meanwhile, a few contributors have teamed up to explore using Ada in FlightGear to make some experiments.

We're hoping to document the steps required to extend our [[Developing using CMake|CMake build system]] to support optional modules implemented in Ada as discussed by onox, Flying toaster and Hooray on the forum, including support for mapping existing C++ classes to Ada (e.g. from OSG and/or OpenRTI).

The main goal being here to leverage Ada's native tasking support for prototyping optional features that do not have to be running in the FlightGear main loop.

We've already found some existing CMake modules that we can reuse: The [http://plplot.sourceforge.net/ PLPlot project] is implemented using C, C++ and Ada and provides a set of CMake modules that are scheduled to be merged into CMake soon.

Hooray has copied those files into a branch of $FG_SRC and ended up with a working build environment that successfully links in Ada modules. For starters, we'll be playing with optionally allowing [[Howto:Add new fgcommands to FlightGear|fgcommands]] to be implemented in Ada, as well as new [[Howto:Create new subsystems|SGsubsystems]].

Next, we'll be exploring how to add thin bindings using '''-fdump-ada-spec''' for existing SimGear/OpenRTI (HLA) headers and document the whole process on the wiki.

Using -fdump-ada-specc to create bindings for SG/HLA classes to create standalone HLA federates in Ada would make FG pretty compelling for anybody doing this kind of thing professionally, because Ada simply happens to be widely used in the aviation industry, and it seems there are even bindings of complex stuff like OSG available.

To learn more, please see [[Howto:Using Ada in FlightGear]]

== Improve the multiplayer experience ==
The <usage>interior</usage> tag has been extended to support MP/AI models.

A new LOD key is added to the LOD dialog which affect the distance of loading the interior model of AI/MP models. Default value is 50.0

In other words, the interior model of AI/MP is loaded '''only''' when you are at less than 50.0 meters of the AI/MP models.

http://wiki.flightgear.org/Modelling_guidelines#Modelling_guidelines

== Performance Issues ==
Several FlightGear users have pointed out inexplicable "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily.

So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker.

As some of you may know from working with Nasal code: listeners are not in and of themselves expensive, but running identical listeners over and over again each frame is getting unnecessarily expensive quickly. This doesn't just apply to scripting space, but also to C++ space - here, it's the sheer performance offered by native C++ code that makes it much harder to identify such problems, because code that would bring the simulator down to its knees in Nasal may very well still be "fast enough" for most people with fast computers, despite being still very much "broken", and plain wrong.

As can be seen on the devel list, Torsten has been spending the last weeks troubleshooting the effects system, which isn't exactly straightforward because its original developer is not currently involved in FlightGear, and the code is pretty sophisticated and even multi-threaded (which means that parts of the code may be running concurrently on different CPUs) - however, Torsten did report pretty significant performance improvements recently - he's just pushed his work to a new branch so that other developers (and people building from source!) can have a look and test his changes and report feedback/issues - this will probably mean that it may take a few weeks until all the feedback has come in and implemented - but performance should be improved significantly by then - which also addresses the whole "when will 3.2 be released" question. Meanwhile, Stuart has joined Torsten to help with fixing the bug:

{{FGCquote
|Acutally, Stuart is working on this and has improved the UniformCache I started with. He has a much better insight in the Effect system than I do.
His work is much better than mine but still has some breakage for existing shaders, most prominent one is ALS.
We are still investigating whats going on there and I have to ask for just some more patience. 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32846172/
|title=<nowiki>Re: [Flightgear-devel] crash in SGPropertyNode::fireValueChanged</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-18</nowiki>
}}
}}

Also, Hooray recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - it seems that a few contributors are still trying to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work.

But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:

* [[FlightGear Headless|Running FlightGear headless]] (i.e. without a window, used for subsystem performance testing)

* [[Testing|Testing Performance]]

Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.

People wanting to change that, need to roll up their sleeves and get involved, and PLEAE provide feedback.

'''All''' testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: [[Howto:Optimizing FlightGear for mobile devices]].

And here some initial observations based on running FlightGear on an underpowered Netbook with integrated Intel GMA graphics:

* our existing GUI truly sucks: whenever a PUI dialog is opened, the frame rate is becoming single-digit
* once the dialog is closed, it will spike up to ~30 fps, with the Canvas/REPL window still shown (!)
* hiding the PUI menubar further helps increase frame rate and improve frame spacing
* hiding the menubar AND closing the REPL dialog, I am getting ~45-50 fps using the minimal startup profile, frame spacing is then roughly in the 60s
* the navcache is a huge resource hog for people on such systems - initializinig/rebuilding the cache is taking ages (10-20+ minutes here !)
* it would make sense to refactor the navcache and turn it into a library, so that we can prebuild the navcache - and either do so while packaging a release, or alternatively, during installation (plenty of time there!)
* in addition, threading would make sense probably, when the navcache was being rebuilt, the 2nd core was idling all the time while 1 core was at 100%
* Canvas/RTT (FBOs) actually work here (which is a good thing for FGPanel/FGCanvas usage)
* there are a bunch of default options that will "break" FG for users on such systems, including a number of options that will trigger OpenGL/OSG errors early on

Hooray is hoping to do further testing, using the system monitor and the built-in profiler - keep in mind that this still is the code that contains some pretty severe performance bugs.

If we had more people doing this kind of testing, we could definitely identify, and hopefully eliminate, quite a few performance issues that would not be noticeable on a typical developer's machine.
So this could be a worthwhile thing to do, and it would help FG in the long term - i.e. even benefit power users who have 2048 MB of VRAM and 8 cores/12 gb of RAM.

The really interesting "benchmark" here is running osgviewer and fgviewer as comparison, because what FG is doing here isn't much different functionality-wise, and it's using the same technology stack (i.e. OSG), so should provide similar performance.

Unofortunately, we generally don't have many people who do a lot of testing, troubleshooting - or even just provide feedback via the issue tracker - it is definitely true that the Canvas GUI is much faster here, despite containing a ton MORE Nasal code, and despite being MUCH more dynamic/flexible than our existing PUI dialogs.

It would really be awesome to find a handful of people with access to old/slow hardware interested in testing and maybe troubleshooting things - while it would be great if those people knew how to build from source, and how to use git/gitorious, I don't think that's even necessary - we can definitely provide a lot of infrastructure and advice, but most of us don't typically have access to these kinds of computers. And while some of us admittedly aren't bothered by it, it is very true that FlightGear as a whole will benefit from teasing out certain bugs/issues, no matter if those are slowing things down due to CPU/GPU or RAM/VRAM utilization.

But we really need more people willing to do this kind of testing and who can provide feedback regularly - and start yelling once something that previously worked, stops working or is becoming unnecessarily slow - there are a bunch of issues that should have never made it into the code, but which went unnoticed for months (or even years), because it's really only power users/contributors and developers who do this kind of testing, and as I am seeing right now, certain issues are pretty well "masked" on an 8-core, 10 gb, 2gb VRAM machine obviously ...

We've been hoping to create some kind of "benchmark" for years - and this is one of those things that would truly help FlightGear in the long term, because we'd get quantifiable data over time, so that we can easily tell how a certain startup/run-time feature behaves in correlation with how it behaved previously, i.e. compared to updated dependencies (OpenAL, PLIB, OSG) - but also changes to the C++ code in SG/FG itself.

People are generally quick to point at Nasal and its known GC issues, but are usually not experienced enough to look behind the scenes, and the amount of existing C++ code that is doing things in a slow fashion, code that's been lurking in the source tree for years more often than not. Creating some kind of simple benchmark would help all of us, no matter the kind of hardware we have: [[FlightGear_Benchmark]].

If you're interested in getting involved with testing FlightGear and improving compatibility for older/slow systems, please get in touch with Hooray on the forum.

<gallery mode=packed widths=230px heights=230px>
Fgfs 3.2 on a dual-core netbook.png|FlightGear 3.2/Canvas working on a dual-core Netbook with Intel GMA graphics showing the [[Interactive Nasal Console]] dialog
Comparing Native Canvas GUI Performance over PUI.png|A native [[Canvas]] window showing the new [[Aircraft Center]] dialog (good performance)
System-monitor-on-netbook.png|Screen shot showing a number of performance issues in a handful of FG subsystems, especially the PUI GUI
Pui slowness.png|The old PLIB/PUI GUI is shown here rendering a Canvas Widget with a [[MapStructure]] layer, a few users have reported that PUI is significantly slowing down the simulator
MapStructure self test over embedded PUI widget.png|And for comparison a native Canvas window also using the [[MapStructure]] framework,without going through PUI (better performance)
</gallery>

== The hidden Map ==
[[File:FlightGear-Map-on-Android.png|right|400px]]
Did you know that FlightGear has an internal web server? And did you ever ask yourself the question, what does a flight simulator needs a web server for? A nice and impressive use case is a map application that has just been brought to the main menu. Click on "Equipment" and select "Map (opens in browser)". Your web browser will pop up and show a map based on current web standards. It can display OpenStreetMap maps as a base layer as well as satelite image or roads from MapQuest. Overlays for current (real) weather like precipitation and isobares exist. The map can display FlightGear internal navigation data like airports, navaids etc. And it can display AI traffic and multiplayer aircraft, too.
Of course, it runs on any decent browser, but not only the one on your FlightGear computer. It is web-app-capable so you can install it to your mobile device (IOS and Android) to have a full screen map App on your tablet or phone displaying your current FlightGear status. All this at almost zero cost for the FlightGear main loop. All the rendering computations are done within your browser. The FlightGear webserver only provides the HTML and JavaScript files and transmits the internal properties over a websocket.
To enable the internal browser-based map, you need to enable the internal web server by adding <code>--httpd=8080</code> to your command line.
Consult your mobile devices operation manual about how to add a web page as a full screen App.

== Learning Canvas using Copy & Paste ==
Given that we still have aircraft developers who consider [[Canvas]] programming too 'inaccessible', we've started a dedicate wiki article for gathering useful Canvas snippets - early Canvas adopters are obviously invited to help grow this library of snippets over time to turn this into a useful repository for all people wanting to do Canvas development in some shape or form. For starters, here's a simple snippet creating a GUI dialog:

{| class="wikitable"
|-
! Screenshot !! Code !!
|-
| [[File:Snippets-canvas-dialog.png|left|thumb|This is what the [[Nasal]]/[[Canvas]] snippet will look like once you pasted it into the [[Nasal Console]] and click "Execute".]] || {{Note|This example uses so called method chaining, if you're not familiar with the concept, please see: [[Object_Oriented_Programming_with_Nasal#More_on_methods:_Chaining|Method Chaining]].}}

<syntaxhighlight lang="nasal" enclose="div">
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas().set("background", canvas.style.getColor("bg_color"));

# Using specific css colors would also be possible:
# myCanvas.set("background", "#ffaac0");

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();
</syntaxhighlight>
|-
|}

See: [[Canvas Snippets]]
== Dynamic Liveries via Canvas / Proof of Concept: Exhaust dirt==
''by [[User:Algernon|Algernon]] ([[User talk:Algernon|talk]]) 17:09, 17 September 2014 (UTC) ''

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015.
The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt streaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.

<gallery mode="packed">
Two-layers.jpg|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks
Dynamic-Textures-First-Try.jpg|A first (failed) attempt to put a canvas onto a model object in place of its texture.
Ef2000dyn1.jpg|The EF2000 showing a dynamically-changed texture on the fuselage - at the moment, the resolution appears to be wrong and the UV coordinates seem to be being ignored.
File:Ef2000dyn2.jpg|Changing the dialog window size to be the same size as the texture fixed the issue - note that the fuselage sections are free of dirt (except the APU exhaust smudge, which is a special case) where as the wings and tail have integral dirt in the texture.
File:Ef2000dyn3.jpg|A full-screen illustration using the updated Canvas code to make the canvas independent of the window, but with the window still displaying the canvas. Here, only the base "clean" paintwork texture is added to the fuselage element.
File:Ef2000dyn4.jpg|After creating a canvas with the base "clean" paintwork texture, another child is added containing the dirt layer transparency. The effect is seen both in the dialog window and on the airframe.
</gallery>

To learn more, see [[Howto:Dynamic Liveries via Canvas]]

== Interview with a contributor ==

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.

'''What is your forum nickname, ZLSA?''' ZLSA.

'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?

'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.

'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.

'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.

'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.

'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

'''Have you previously used other flight simulators or simulation software in general?''' No.

'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?

'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

'''Have you ever used FlightGear professionally or for educational purposes?''' No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.

'''What about FlightGear as a "game", do you think it can be used as such?''' Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.

'''On average, how much time do you spend working with/contributing to FlightGear?''' Probably in the hundreds of hours at this point.

'''Which of the more recent FlightGear developments do you consider most interesting/appealing?''' Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.

'''Is there some feature that you'd truly like to see in FlightGear one day?''' Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)

'''What do you think could be done to attract even more new users and contributors to FlightGear?''' Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.

'''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' Back up your FlightGear data directory and play around with things.

'''Have you ever recommended FlightGear to other users, friends/family?''' No, whenever I mention it they suddenly disappear...

'''Is there anything else you'd like to share with us?''' No.

'''Good day then, and thanks for agreeing to this interview.''' No problem.

==In the Hangar==

'''[[Airbus A300-600]]'''

This Airbus A300-600 has been developed by Airbus330 and Toryx (Developer of the A310), using many parts of the A310. The Flightdeck was taken from the A300-600ST, but has the addition of a Cockpit Controllable Autopilot. It has a reasonably detailed exterior model, with accurate flap, speed brake, and spoiler position animations, tail surface animations and tyre smoke. The interior now consists only of the cockpit, but that is fairly detailed except for the overhead panel. The version currently available for download from the forum or wiki has only the A300-603, but a version with the A300-600F will soon be released, (as soon as i make enough liveries).
Currently, the engines are always on, but i am now working on an autostart system, which will also be in the next release.

<gallery mode=packed widths=230px heights=230px>
File:A300F.png|A300F-coming soon!
File:A300-600 Flightdeck.png|The "Office"
</gallery>

Modelling guidelines

2014-09-21T21:02:05Z

F-JJTH: /* Modelling guidelines */

{{Merge|Modeling - Getting Started#Improving models for best FlightGear performance}}

When modelling an aircraft, building or any other 3D model, you are encouraged to follow the '''modelling guidelines''' outlined in this article.

Feel free to add/modify. (''please leave a comment in the [[Talk:Modelling guidelines|talk page]] for radical modifications'').

== Definitions ==
*Model = the file.
*Object/Mesh = part of the Model file. The Model can contain several Objects.
*Texture = image file (.rgb, .png).

== Modelling guidelines ==
*Vertices are free up to a point - use as many as you need.
*Many small (in vertex numbers) Objects/Meshes have a far worse negative impact on performance than a single Object/Mesh with very high vertex numbers.
*Combine all different parts of the Model into one single Object/Mesh, with the exception of parts that need to be animated, or of transparent parts.
** '''Blender''': Select some objects and press {{Key press|Ctrl|J}} to join them into one Object. The new object origin/transform/orientation/name will be based on the ones of the last object selected.
*Use different unique names for each of the Objects in a Model file. Even more so when the different parts need to be animated.
*Make all faces of the objects single sided.
*If you need a part of the model to be visible from both sides, duplicate it in place and flip the normals. The extra geometry overhead is negligible compared to the extra work generated by double-sided faces.
*Split transparent parts into their own objects.
** '''Blender''': Go into Edit Mode, select the part of the object that you would like to split and press {{Key press|P}}.
*Assign to all transparent Objects at least the ''model-transparent'' effect:
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/model-transparent</inherits-from>
<object-name>Transparent-object1</object-name>
<object-name>Transparent-object2</object-name>
<object-name>Transparent-object3</object-name>
<object-name>other-Transparent-object</object-name>
</effect>
</syntaxhighlight>
*The interior should be a separate Model. Having it separate enables delayed loading of such models in multiplayer/AI contexts. Such a model is specified as follows in the .xml file:
<syntaxhighlight lang="xml">
<model>
<usage>interior</usage> 
<path>Models/your-interior-model.xml</path>
</model>
</syntaxhighlight>

If your <model> require an <offsets> you must create a proxy XML like:

your/aircraft/Models/aircraft.xml:
<syntaxhighlight lang="xml">
<model>
<path>your/aircraft/Models/Interior/model-proxy.xml</path>
<usage>interior</usage>
</model>
</syntaxhighlight>

your/aircraft/Models/Interior/model-proxy.xml:
<syntaxhighlight lang="xml">
<model>
<path>your/aircraft/Models/Interior/model.xml</path>
<offsets>
<x-m> -1.91552 </x-m>
<y-m> 0.00000 </y-m>
<z-m> 0.23706 </z-m>
<roll-deg> 40.0 </roll-deg>
<pitch-deg> 35.0 </pitch-deg>
<heading-deg> 60.0 </heading-deg>
</offsets>
</model>
</syntaxhighlight>

== Texturing guidelines ==
*Combine as many parts of a single Model to a single texture as you can - the maximum texture size is 4096 x 4096 pixels.
*Do not assign multiple textures to the same Object/Mesh. The Object will be split so as to have a single texture/Mesh.
*Do not use different parts of a single texture for different models. Split the texture into smaller parts then.
*If using the same texture on multiple models, use a single file, do not make different copies.
*Prefer texture replacing animations to textranslate for models that spend large amounts of their time in one state (day/night animations).
*Avoid transparency like the plague, it kills frame rate like nothing else: remove the alpha channel from textures if they are non-transparent.
** '''GIMP''': Go to <tt>Layers > Transparency > Remove alpha layer</tt>.
** '''Inkscape''': Go to <tt>File > Document Properties</tt> and set the "Background" to a non transparent colour (preferably black).
*Hive off transparent parts of textures into their own textures.
*Use power of two dimensions for textures (2n, e.g. 256x256, 512x1024). Do not worry if your image would get stretched in the texture, you can fix that with the mapping on the model.
*Do not have textures with the image in one corner and the rest unused.
*Recommended texture format is: '''.png'''. In general any texture format supported by OSG could be used, but be aware of varying cross-platform support for such formats, or of lossy compression.
 

[[Category:Modeling]]

Switching default texture format to DDS

2014-09-17T22:39:52Z

F-JJTH: /* NVIDIA proprietary driver */

The FG development team is considering to '''switch the default format for textures from png to DDS'''. This would offer a number of significant advantages:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, in essence no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

== Feedback needed - should FlightGear switch the defaults to DDS format for terrain texturing? ==
However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

{{FGCquote
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.
In other words, a lack of feedback from end users might very well mean that future FlightGear versions may require DDS support and may not necessarily work for people with outdated hardware - so if you care about backward compatibility, please do get involved, test DDS support and provide feedback!

=== What we need you to do? ===
FlightGear already provides the simple option to test a DDS texture set. If you are running on Linux and use an open source graphics driver, please take 5 minutes to help during your next FG session:

# Open the dialog under View -> Rendering
# Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'
# Press 'Okay' - FG will reload the terrain
# Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic, or even bright/pink, colors or other rendering artifacts, your system may have problems with DDS.
# Change back to the texture scheme you like best
# Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphics drivers ==
=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT 640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|-
|GeForce GT 620 OEM
|331.38
|{{yes}}
|C-GGKV
|-
|GeForce GTX 650
|331.20
|{{yes}}
|dany93
|-
|GeForce 210
|304.117
|{{yes}}
|Jean-Philippe
|-
|GeForce GT 520
|332.21
|{{yes}}
|cossack90
|-
|GeForce GTX 260
|304.117
|{{yes}}
|Lann
|-
|GeForce GTS 250
|331.38
|{{yes}}
|Madbyte
|-
|GeForce GTS 450
|340.32
|{{yes}}
|chris_blues
|-
|GeForce 8600 GT
|340.32
|{{yes}}
|szpajder
|-
|GeForce GTX 460 SE
|331.38
|{{yes}}
|f-jjth
|-
|GeForce GTX 560 Ti
|319.32
|{{yes}}
|PATTEN
|-
|GeForce 8600 GT
|304.117
|{{yes}}
|attila
|-
|GeForce GTX 750 ti
|340.32
|{{yes}}
|f-toro
|-
|GeForce GT 650M
|Apple OS 10.9.4
|{{No}}
|dersh
|-
|GeForce 9800GTX
|304.117
|{{yes}}
|ctec356
|-
|GeForce GT 220
|331.38
|{{yes}}
|D-ABEK
|-
|GeForce GTX 760M
|331.38
|{{yes}}
|f-ojac
|-
|GeForce GTX 560
|319.32
|{{yes}}
|[http://fr.flightgear.org/forums/viewtopic.php?pid=28721#p28721 Clm76]
|}

=== NVIDIA open source driver (Nouveau)===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GT 630
|
|{{no}}
|[https://plus.google.com/111978238381658236898/posts/VYSusMLRiH2 Jakub Klawiter]
|-
|GeForce GT 220
|
|{{no}}
|D-ABEK
|-
|}

=== Intel proprietary driver ===

=== Intel open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|{{n/a}}
|{{yes}}
|cdesai
|-
|HD Graphics 3000 (i3-2330M)
|10.2.2
|{{n/a}}
|{{yes}}
|Flyhigh/saiarcot895
|-
|HD Graphics Sandy Bridge (Pentium B980)
|10.1.0
|{{no}}
|{{yes}}
|f-jjth
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|-
|AMD Radeon R9 200 Series
|14.4
|{{yes}}
|Richi
|-
|Radeon HD 4850/4870
|legacy 8.97.100.7-4
|{{yes}}
|Jano
|}

=== ATI/AMD open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|AMD Radeon HD 6570
|10.1.3
|{{yes}}
|{{yes}}
|fgjosh
|-
|-
|AMD Radeon HD 6770
|10.2.5
|{{no}}
|{{no}}
|Mongrol
|-
|AMD Radeon HD 7950
|10.2.1
|{{yes}}
|{{yes}}
|Saga
|-
|AMD Radeon R9 270X
|10.3~git20140805
|{{no}}
|{{no}}
|nine
|-
|AMD Radeon R9 270X
|10.3~git20140805
|{{yes}}
|{{yes}}
|nine
|}

== Sample test ==
=== DDS Test at the airport of Orio (Bergamo - Italy) ===
[[File:Terrain texture scheme DDS 01-2000.jpg|800px|thumb|Comparison of texture in relation to the three possible choices in "Rendering Options" -> "Terrain texture scheme"]]The final result, with all the "Shader Options" active, is not very satisfactory, I would say very poor. Apparently not check on any improvement in the speed of image loading. I think on modern machines with quad-core processors 16 GB, with latest graphics cards (NVIDIA 870) 6 GB, the loading of these images is not really a "bottleneck". I propose to insert the DDS functionality, but in a transparent way, ie convert "on the fly" the images before inserting them into the temporary memory, for example using the convert function of ImageMagick. However, I do not know if it really is a useful feature, I think there are many other things to do before this. These are the parameters used by the startup script "run_fgrun.sh":
{{Note|To reproduce this test, you can use the following [[Fgfsrc]] file - you should set up [[$FG_ROOT]] and [[$FG_SCENERY]] specifically for your own system though.}}
<code>
--airport=LIME
--aircraft=757-200-PW2040
--disable-random-objects
--enable-horizon-effect
--enable-enhanced-lighting
--enable-distance-attenuation
--enable-ai-models
--disable-ai-traffic
--disable-real-weather-fetch
--enable-clouds3d
--bpp=32
--texture-filtering=16
--prop:/sim/rendering/multi-sample-buffers=1
--prop:/sim/rendering/multi-samples=4
--timeofday=noon
--enable-terrasync
--httpd=5500
--props=5501
--jpg-httpd=5502
--multiplay=out,10,,0
--multiplay=in,10,,0
--disable-fgcom
</code>

== Excerpts from the ongoing discussion ==
{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== DDS Debate in 2012 ==
=== Legalities ===
{{See also|Talk:Switching default texture format to DDS#Using patented algorithms}}

{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|t is technically incorrect to provide these s3 patent 
precompressed textures to a driver that does not announce the apropriate 
extension and since we are not allowed to code something that deompresses 
this, I think we should avoid using this compression for all the provided 
models/textures. 
 
I think of a warning that is issued from the image loader in flightgear that 
detects when these precompressed textures are seen. So even people using 
drivers that just offer this extension have a chance to see that the provided 
textures will not work for others.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612879/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

=== Portability Concerns ===
{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|And this is what I try to do now: 
Object against using these patented compression algorithms. 
I do not care for the on disk format of any image file we have. But the problem 
is that some kind of precompression that can be stored in these dds files 
cannot be used with other drivers than the closed ati and nvidia ones. 
As long as these patented compression techiques are not used, every OpenGL 
driver can use this and displays this fine. 
 
Think: Intel has the hugest marketshare in graphics today. If I remember 
right, they sell more than ati and nvidia together (*). This kind of change in 
effect rules out the majority of users as intel cannot work with these files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably 
have the same effect. So I think simply ommitting DDS is ok? 
 
Also, much more important, the comment is not about 'your video driver'. It is 
in your (Vivian) case even wrong. Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I would like to have a flightgear that is by default just running on every 
average system. Having this run faster on a special configured system with some 
better configuration options and hand tuned hardware and drivers is very fine. 
But without tuning it must at least work in an acceptable way. 
 
I have checked in a change to flightgear to make the use of the compressed 
internal formats a starttime configuration option. 
I am still interrested if we have that hangs also with texture compression 
disabled and without providing precompressed dds textures?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28602775/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|this is the reason for the message. If your machine would refuse to display this you, 
developing that, would probably just say 'nice try, but it does not work' 
before you check in something. In the case it displays fine, you probably say 
'it works here, so I assume it works also for others, lets do'. 
And the message tells you, 'despite of just seeing this working on this 
current machine, it does not work for others'.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff. 
 
I am not going to discuss the patent stuff. Please search the mesa-dev archives 
for the discussion and see there why they think that the nvidia tools and 
other stuff out there cannot be used. Really - it is not that the code for that 
is too dificult or unavailable. I am not a lawyer and I cannot change this 
world - even if I would like to in this regard. 
 
I agree that techically for drivers/gpus supporting these compression formats 
it would be best to use these precompressed files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

=== Approaches ===
{{FGCquote
|Well, the default f16 does not work anymore for example. 
I have also never tried the new textures, but I assume that these also contain 
precompressed data? Also you claimed that the old texture files start to bitrot 
comared to the new ones which makes me think that the new standard should be 
the dds files. This together makes me think that the dds files should replace 
the traditional image files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|Hmm, regarding dds. 
I have to say, that not all OpenGL drivers support texture compression, and 
the models with dds files, are those that I cannot display, because of that. 
And in fact this will not happen to the open source drivers before something 
about 2020 because of patent issues. 
 
Sorry to step in this so late - probably way too late - but is there a reason 
that the on disk format must be compressed? 
The previous strategy to have on disk an format that everybody can read and to 
make the driver compress them as needed/possible is better I think? 
 
So, for me the f16 lost its livery lately - where I can live with this for the 
f16, I hope that this does not happen to flightgear as a whole ...
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28594472/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-27</nowiki>
}}
}}

{{FGCquote
|Well, I hope that we can get rid of the compression. 
Can somebody with the apropriate tools convert the compressed textures to non 
compressed ones? That could still be dds, but dds without these compressions 
that produce the warning. So no problem with cubemaps in dds as long as the 
compression is not there. 
Then *everybody* is again able to use this stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678109/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I can see several approaches: 
 
* Just do not use the patented compression stuff. The precomputed mipmaps could 
probably do the job of avoiding the hangs (hopefully? to be checked?). May be 
we could lower disk space usage by providing a dds.gz or similar wrapper? 
 
* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu 
in the database loader thread. This would help all textures not only the ones 
that could be converted. May be this is the most generic solution. 
 
* Implement some kind of image lookup order that knows if the compressed files 
could be handled or not. On loading an image in case of available compression 
first try to find a dds file with the same name of the original one. That 
involves some 'magic' which often leads to problems but that could at least 
work.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

{{FGCquote
|Next step is to make sure that compression is not required to avoid the hangs. 
My favorite bet would be that then the new configure option regarding texture 
compression needs to be set to none.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

=== Precomputed mipmaps ===
{{FGCquote
|Could we do dds files without compression but with precomputed mipmaps? 
 
So at next, can you try out which combination of compression/provided 
mipmaps/forced simgear compression still work fine?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28603114/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|The 4. Method that I can imagine is to precompute the mipmaps in the loader. 
IIRC tests with some of the guys suffering from this problem, providing 
premipmapped but uncompressed dds files had helped to get a fluent viewer. 
The argument against providing these dds files in general was that these files 
are really huge because of not including any compression and having all the 
mipmaps. 
But that means we could at the point where the warning happens compute the 
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be 
used to do this I think (or something similar not requireing a context). This 
one is an imported version of the original glu function that is included in 
osg for running on an EGL stack which no longer provides GLU. 
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and 
scale this to the 2. mipmap and so forth. 
 
This would have the advantage that the png's do not deviate from the dds files 
over time.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571679/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I think then, computing mipmaps for any texture file on the CPU in the loader 
thread should globally improove the situation. 
Also avoiding the compression already in the files should help every use case. 
Except that the on disk memory consumption is higher. 
Well and except that the database loader has more work to do on the CPU.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612897/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

{{FGCquote
|Doing that differently will provide some overhead that could be kept at a 
minimum I think: 
For the disk usage, I think gzip compressing these will work sufficiently fine. 
Ram usage of the images should not hurt too much. Sure the images are bigger 
in memory. But fgfs is not just about images - far from that. 
On the GPU, you can still use compression for the textures as the internal 
format. This is what flightgear tries to do if the extension is supported 
(checked by osg). 
 
The major point is that there are several ways that use slightly more 
resources to get around this problem. 
But once the patented compression is on disk, there is *no* way back for 
people not having this feature. 
 
If you have better ideas that do not rule out intel and the oss drivers, you 
are welcome!
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this 
also the case for the default win32 case? Is there a osgdb_gz.dll or something 
along the lines in the directory containing the plugins? 
 
If yes, we can already tackle the size problem of the uncompressed dds files on 
disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and 
just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here. 
And I assume that this works fine for all unix like operating systems including 
mac?! 
James?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|What about solution 6 with (uncompressed premipmapped dds).gz? 
On linux this should work as long as you have zlib installed which could be 
regarded as a system library there. 
Can we rely on zlib being compield into our osg distributions on win32? We do 
need zlib in any case, it's mostly about teaching osg that it finds our zlib on 
configure and build the gz plugin.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571819/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I implemented a mipmap control and generation tool in effects when I last updated 
the urban shader. For the moment, it relies on hardware when the average operator 
is used for all texture channels but it could easily be modified to compute 
all mipmap on the CPU. look the <mipmap-control> effect option and 
mipmap.[ch]xx in SG material lib
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606692/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees
& buildings)</nowiki>
|author=<nowiki>Frederic Bouvier</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

== Implementation ==
{{FGCquote
|As has been previously pointed out, the current DDS texture set is not 
simply the global png texture set converted. 
 
For our own sanity and those of the users, we need to ensure that there's 
an apples-to-apples comparison being made when we change the default. I 
therefore think we need to create a DDS version of the current default 
texture set.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|2) If we go down this path, we probably want to separate the underlying 
texture format from the materials.xml definition entirely. For example, we 
could simply remove the extention from the materials definition, and have 
the C++ code append the appropriate extension based on a separate property. 
This has a couple of advantages: 
a) Makes testing easier and materials definitions less error-prone. 
Assuming we have some batch job in place to generate dds textures, those 
working on materials definitions could continue to work with png textures, 
and only convert to dds as a final step (or indeed as part of the "make 
release" jobs). 
a) Avoids duplication of materials definitions. Having just spent quite a 
bit of time making the materials definitions more efficient, I'd like to 
avoid making it worse again! 
 
I'm quite happy to do the C++ coding required for this in the materials 
loader - it's probably pretty straightforward.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|That does leave the issue of what happens to the existing dds texture 
definitions where there are special mipmap layers. I'd suggest that we 
have some Clever Script (tm) that is able to work out whether the DDS or 
PNG version of a texture is the master, and then generate the other version 
from it. I admit that the PNG conversion of the DDS will lose some 
information in this process, but it would allow those without DDS support 
to at least use the textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|3) We need a sensible process for dealing with aircraft, which has been 
identified as a significant issue. Again, I think more aircraft developers 
find .png easier to deal with, and there are a lot of aircraft out there 
that would need conversion. It feels like we need some build scripts to 
"compile" aircraft to use DDS textures. 
 
A more far-fetched idea might be to have a cache of dds textures that are 
generated on-the-fly, or when aircraft are loaded by the aircraft center. 
Clearly that impacts initial load time the first time a new aircraft is 
loaded, and would increase the size of .fgfs/ directories massively, but it 
would remove the need for any work by aircraft/scenery developers and could 
be made optional. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

== Challenges ==
{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==
Also see [[DDS texture conversion]].

{{FGCquote
|the script take the .dds and not convert the png again if both exist(I remember having manually used "compare" to check if both the dds and the png looks the same, and if not i changed some names) 
 
notice that the normal maps are a particular case as you need to tell the effect the texture is dds with a line like: 
 
1 
 
 
just be sure to include this in the normal map effects with png and it will be easier: 
 
0 
 
 
about FG doing the dds conversion , nvcompress is told to be gpl compatible, but i'm not an expert here: 
 
http://nvidia-texture-tools.googlecode.com/svn/trunk/NVIDIA_Texture_Tools_README.txt 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799214/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean pellotier</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

{{FGCquote
|I think this is an inheritance from some other game engine using a different convention, and therefore from the authoring tools that were developed for such an engine (photoshop exporter plugins and the like). If indeed the FGFS DDS textures are only meant to be used in FGFS then this should be fixed at the conversion time. Otherwise, if we want other applications to easily reuse the FGFS textures then it would be better to stick to the most common convention. But I think we all agree that the source for any DDS texture should be kept, which pretty much precludes importing ready made DDS textures from 3rd party sources. Incidentally I think importing DDS artwork from other sources should be discouraged, since it will most likely run afoul of the licensing terms of the original copyright owner.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799324/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>TDO Brandano</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

Nothing as exotic. Just a different "origin" between OpenGL and Direct3D image conventions. OpenGL image origin is located in the lower-left corner, while Direct3D (hence DDS too) considers the top-left as the origin, resulting in a DDS image to appear vertically flipped when read in an OpenGL context. This has repercussions in the way normal-map decoded normals appear (hence the flag in the effects, which signals to the shader to flip the decoded normals). The rest is simply a matter of workflow: either use flipped coordinates and skewed/reversed conventions throughout your whole workflow, or just flip the image and (eventually) set a flag for the shader at "publish" time (said flag could be automatically set by the code on DDS texture load). ''(the latter seems more pragmatic/appealing)''

{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Cons ==
{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

[[Category:Core development projects]]

FlightGear Newsletter September 2014

2014-09-15T19:24:09Z

F-JJTH: /* A mini HowTo */

{{Newsletter-header|September 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}} 
{{Newsletter-cover-item|DDS feedback needed}} 
{{Newsletter-cover-item|Aircraft moved to SVN}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Performance issues}} 
{{Newsletter-cover-item|The hidden Map}} 

| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
|}
</div>

== DDS feedback needed ==

We are looking for feedback about possibly adopting DDS textures in FlightGear. There are several advantages in doing so:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by most Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.

Continue reading at [[Switching default texture format to DDS]]...

== Aircraft moved to SVN ==
Some months ago we decided to host our aircraft on an SVN repository in order to relieve <code>fgdata</code>.
The <code>fgdata</code> repo would be a mirror of the base package.

We finally moved all our aircraft to '''the new SVN repo''': http://sourceforge.net/p/flightgear/fgaddon/

This repository is named "FGAddon" because its content is not required to run FlightGear but provides a new feature (aircraft in this case); this is usually called an "addon".

=== Advantages ===
On the user side, the most important feature is to be able to checkout only desired aircraft, as you no longer need to download the 400+ aircraft at once.

On the developer side, the most important interest is to have a base package (<code>fgdata</code>) which is lighter to sync for new contributors and easier to keep up to date.

=== A mini HowTo ===
* For Windows: Install TortoiseSVN (http://tortoisesvn.net/)
* For Linux/Mac: Install SVN

Then to fetch an aircraft (in this example we pick up the [[Robin DR400 Dauphin|DR400 Dauphin]]):
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DR400-dauphin

Then you can regularly fetch the latest updates with
svn up

If you are used to use Git, <code>svn co</code> and <code>svn up</code> are similar to <code>git clone</code> or <code>git pull</code>.

The aircraft will remain in the <code>fgdata</code> Git repository for a few months, until everyone has transitioned to the SVN repositories.

=== Background ===
For our aircraft developers who don't regularly read the mailing list (even though any aircraft developers should already be subscribed), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971

== Performance Issues ==
Several FlightGear users have pointed out inexplicable "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily.

So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker.

As some of you may know from working with Nasal code: listeners are not in and of themselves expensive, but running identical listeners over and over again each frame is getting unnecessarily expensive quickly. This doesn't just apply to scripting space, but also to C++ space - here, it's the sheer performance offered by native C++ code that makes it much harder to identify such problems, because code that would bring the simulator down to its knees in Nasal may very well still be "fast enough" for most people with fast computers, despite being still very much "broken", and plain wrong.

As can be seen on the devel list, Torsten has been spending the last weeks troubleshooting the effects system, which isn't exactly straightforward because its original developer is not currently involved in FlightGear, and the code is pretty sophisticated and even multi-threaded (which means that parts of the code may be running concurrently on different CPUs) - however, Torsten did report pretty significant performance improvements recently - he's just pushed his work to a new branch so that other developers (and people building from source!) can have a look and test his changes and report feedback/issues - this will probably mean that it may take a few weeks until all the feedback has come in and implemented - but performance should be improved significantly by then - which also addresses the whole "when will 3.2 be released" question.

Also, Hooray recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - it seems that a few contributors are still trying to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work.

But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:

* [[FlightGear Headless|Running FlightGear headless]] (i.e. without a window, used for subsystem performance testing)

* [[Testing|Testing Performance]]

Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.

People wanting to change that, need to roll up their sleeves and get involved, and PLEAE provide feedback.

'''All''' testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: [[Howto:Optimizing FlightGear for mobile devices]].

And here some initial observations based on running FlightGear on an underpowered Netbook with integrated Intel GMA graphics:

* our existing GUI truly sucks: whenever a PUI dialog is opened, the frame rate is becoming single-digit
* once the dialog is closed, it will spike up to ~30 fps, with the Canvas/REPL window still shown (!)
* hiding the PUI menubar further helps increase frame rate and improve frame spacing
* hiding the menubar AND closing the REPL dialog, I am getting ~45-50 fps using the minimal startup profile, frame spacing is then roughly in the 60s
* the navcache is a huge resource hog for people on such systems - initializinig/rebuilding the cache is taking ages (10-20+ minutes here !)
* it would make sense to refactor the navcache and turn it into a library, so that we can prebuild the navcache - and either do so while packaging a release, or alternatively, during installation (plenty of time there!)
* in addition, threading would make sense probably, when the navcache was being rebuilt, the 2nd core was idling all the time while 1 core was at 100%
* Canvas/RTT (FBOs) actually work here (which is a good thing for FGPanel/FGCanvas usage)
* there are a bunch of default options that will "break" FG for users on such systems, including a number of options that will trigger OpenGL/OSG errors early on

Hooray is hoping to do further testing, using the system monitor and the built-in profiler - keep in mind that this still is the code that contains some pretty severe performance bugs.

If we had more people doing this kind of testing, we could definitely identify, and hopefully eliminate, quite a few performance issues that would not be noticeable on a typical developer's machine.
So this could be a worthwhile thing to do, and it would help FG in the long term - i.e. even benefit power users who have 2048 MB of VRAM and 8 cores/12 gb of RAM.

The really interesting "benchmark" here is running osgviewer and fgviewer as comparison, because what FG is doing here isn't much different functionality-wise, and it's using the same technology stack (i.e. OSG), so should provide similar performance.

Unofortunately, we generally don't have many people who do a lot of testing, troubleshooting - or even just provide feedback via the issue tracker - it is definitely true that the Canvas GUI is much faster here, despite containing a ton MORE Nasal code, and despite being MUCH more dynamic/flexible than our existing PUI dialogs.

It would really be awesome to find a handful of people with access to old/slow hardware interested in testing and maybe troubleshooting things - while it would be great if those people knew how to build from source, and how to use git/gitorious, I don't think that's even necessary - we can definitely provide a lot of infrastructure and advice, but most of us don't typically have access to these kinds of computers. And while some of us admittedly aren't bothered by it, it is very true that FlightGear as a whole will benefit from teasing out certain bugs/issues, no matter if those are slowing things down due to CPU/GPU or RAM/VRAM utilization.

But we really need more people willing to do this kind of testing and who can provide feedback regularly - and start yelling once something that previously worked, stops working or is becoming unnecessarily slow - there are a bunch of issues that should have never made it into the code, but which went unnoticed for months (or even years), because it's really only power users/contributors and developers who do this kind of testing, and as I am seeing right now, certain issues are pretty well "masked" on an 8-core, 10 gb, 2gb VRAM machine obviously ...

We've been hoping to create some kind of "benchmark" for years - and this is one of those things that would truly help FlightGear in the long term, because we'd get quantifiable data over time, so that we can easily tell how a certain startup/run-time feature behaves in correlation with how it behaved previously, i.e. compared to updated dependencies (OpenAL, PLIB, OSG) - but also changes to the C++ code in SG/FG itself.

People are generally quick to point at Nasal and its known GC issues, but are usually not experienced enough to look behind the scenes, and the amount of existing C++ code that is doing things in a slow fashion, code that's been lurking in the source tree for years more often than not. Creating some kind of simple benchmark would help all of us, no matter the kind of hardware we have: [[FlightGear_Benchmark]].

If you're interested in getting involved with testing FlightGear and improving compatibility for older/slow systems, please get in touch with Hooray on the forum.

<gallery mode=packed widths=230px heights=230px>
Fgfs 3.2 on a dual-core netbook.png|FlightGear 3.2/Canvas working on a dual-core Netbook with Intel GMA graphics showing the [[Interactive Nasal Console]] dialog
Comparing Native Canvas GUI Performance over PUI.png|A native [[Canvas]] window showing the new [[Aircraft Center]] dialog (good performance)
System-monitor-on-netbook.png|Screen shot showing a number of performance issues in a handful of FG subsystems, especially the PUI GUI
Pui slowness.png|The old PLIB/PUI GUI is shown here rendering a Canvas Widget with a [[MapStructure]] layer, a few users have reported that PUI is significantly slowing down the simulator
MapStructure self test over embedded PUI widget.png|And for comparison a native Canvas window also using the [[MapStructure]] framework,without going through PUI (better performance)
</gallery>

== The hidden Map ==
[[File:FlightGear-Map-on-Android.png|right|400px]]
Did you know that FlightGear has an internal web server? And did you ever ask yourself the question, what does a flight simulator needs a web server for? A nice and impressive use case is a map application that has just been brought to the main menu. Click on "Equipment" and select "Map (opens in browser)". Your web browser will pop up and show a map based on current web standards. It can display OpenStreetMap maps as a base layer as well as satelite image or roads from MapQuest. Overlays for current (real) weather like precipitation and isobares exist. The map can display FlightGear internal navigation data like airports, navaids etc. And it can display AI traffic and multiplayer aircraft, too.
Of course, it runs on any decent browser, but not only the one on your FlightGear computer. It is web-app-capable so you can install it to your mobile device (IOS and Android) to have a full screen map App on your tablet or phone displaying your current FlightGear status. All this at almost zero cost for the FlightGear main loop. All the rendering computations are done within your browser. The FlightGear webserver only provides the HTML and JavaScript files and transmits the internal properties over a websocket.
To enable the internal browser-based map, you need to enable the internal web server by adding <code>--httpd=8080</code> to your command line.
Consult your mobile devices operation manual about how to add a web page as a full screen App.

== Interview with a contributor ==

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.

'''What is your forum nickname, ZLSA?''' ZLSA.

'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?

'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.

'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.

'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.

'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.

'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

'''Have you previously used other flight simulators or simulation software in general?''' No.

'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?

'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

'''Have you ever used FlightGear professionally or for educational purposes?''' No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.

'''What about FlightGear as a "game", do you think it can be used as such?''' Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.

'''On average, how much time do you spend working with/contributing to FlightGear?''' Probably in the hundreds of hours at this point.

'''Which of the more recent FlightGear developments do you consider most interesting/appealing?''' Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.

'''Is there some feature that you'd truly like to see in FlightGear one day?''' Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)

'''What do you think could be done to attract even more new users and contributors to FlightGear?''' Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.

'''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' Back up your FlightGear data directory and play around with things.

'''Have you ever recommended FlightGear to other users, friends/family?''' No, whenever I mention it they suddenly disappear...

'''Is there anything else you'd like to share with us?''' No.

'''Good day then, and thanks for agreeing to this interview.''' No problem.

FlightGear Newsletter September 2014

2014-09-13T17:51:39Z

F-JJTH:

FlightGear Newsletter September 2014

2014-09-13T17:50:37Z

F-JJTH:

User:F-JJTH

2014-09-09T18:07:29Z

F-JJTH:

[[Category:FlightGear Core developers]]
[[Category:Developer Plans]]

I'm french, and I participe to many developement of aircraft (Douglas DC-3 C47, R44, P92, DR400 Dauphin, Cap10B, Cap10C, DR400-jsbSim...)

My competence are :
* C++
* Nasal
* XML
* 3D : only little correction (Blender)

==Todo List==
This list contains all job I'm interested to work.

* 2013
** Add FGCom feature into FlightGear {{Progressbar|100}}
** Setup a new and updated FGCom server {{Progressbar|100}} [http://fgcom.flightgear.org]
** Add ATC mode into FGCom standalone {{Progressbar|100}}
** Provide FGCom standalone for Windows, Linux, Mac {{Progressbar|100}} [http://fgcom.flightgear.org/download]
** Write a new FGCom documentation {{Progressbar|100}} [[FGCom_3.0]]

* 2014
** <s>Fix "exit" issue for FGCom standalone</s> Re-write FGCom standalone from scratch {{Progressbar|100}} [http://mapserver.flightgear.org/git/?p=flightgear;a=commit;h=b0b272e4d240a3b02062d196b47056179464a5c1]
** Remove bin/Win[32|64] from the Windows installer {{Progressbar|100}}
** Implement an OSM client in FG {{Progressbar|10}}
** Add support for 8.33KHz radio in FG {{Progressbar|10}}

Switching default texture format to DDS

2014-09-07T09:25:09Z

F-JJTH: /* Intel open source driver */

The FG development team is considering to '''switch the default format for textures from png to DDS'''. This would offer a number of significant advantages:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, in essence no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

== Feedback needed - should FlightGear switch the defaults to DDS format for terrain texturing? ==

However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

{{FGCquote
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.
In other words, a lack of feedback from end users might very well mean that future FlightGear versions may require DDS support and may not necessarily work for people with outdated hardware - so if you care about backward compatibility, please do get involved, test DDS support and provide feedback!

=== What we need you to do? ===

FlightGear already provides the simple option to test a DDS texture set. If you are running on Linux and use an open source graphics driver, please take 5 minutes to help during your next FG session:

# Open the dialog under View -> Rendering
# Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'
# Press 'Okay' - FG will reload the terrain
# Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic, or even bright/pink, colors or other rendering artifacts, your system may have problems with DDS.
# Change back to the texture scheme you like best
# Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphics drivers ==

=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|-
|GeForce GT 620 OEM
|331.38
|{{yes}}
|C-GGKV
|-
|GeForce GTX 650
|331.20
|{{yes}}
|dany93
|-
|GeForce 210
|304.117
|{{yes}}
|Jean-Philippe
|-
|GeForce GT 520
|332.21
|{{yes}}
|cossack90
|-
|GeForce GTS 250
|331.38
|{{yes}}
|Madbyte
|-
|GeForce 8600 GT
|340.32
|{{yes}}
|szpajder
|-
|GeForce GTX 460 SE
|331.38
|{{yes}}
|f-jjth
|}

=== NVIDIA open source driver (Nouveau)===

{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GT 630
|
|{{no}}
|[https://plus.google.com/111978238381658236898/posts/VYSusMLRiH2 Jakub Klawiter]
|-
|}

=== Intel proprietary driver ===

=== Intel open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|???
|{{yes}}
|cdesai
|-
|HD Graphics 3000 (i3-2330M)
|10.2.2
|???
|{{yes}}
|Flyhigh/saiarcot895
|-
|HD Graphics Sandy Bridge (Pentium B980)
|10.1.0
|no
|{{yes}}
|f-jjth
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|-
|AMD Radeon R9 200 Series
|14.4
|{{yes}}
|Richi
|}

=== ATI/AMD open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|AMD Radeon HD 7950
|10.2.1
|???
|{{yes}}
|Saga
|
|-
|AMD Radeon R9 270X
|10.3~git20140805
|no
|{{no}}
|nine
|
|-
|AMD Radeon R9 270X
|10.3~git20140805
|yes
|{{yes}}
|nine
|}

== Sample test ==

=== DDS Test at the airport of Orio (Bergamo - Italy) ===

[[File:Terrain texture scheme DDS 01-2000.jpg|800px|thumb|Comparison of texture in relation to the three possible choices in "Rendering Options" -> "Terrain texture scheme"]]The final result, with all the "Shader Options" active, is not very satisfactory, I would say very poor. Apparently not check on any improvement in the speed of image loading. I think on modern machines with quad-core processors 16 GB, with latest graphics cards (NVIDIA 870) 6 GB, the loading of these images is not really a "bottleneck". I propose to insert the DDS functionality, but in a transparent way, ie convert "on the fly" the images before inserting them into the temporary memory, for example using the convert function of ImageMagick. However, I do not know if it really is a useful feature, I think there are many other things to do before this. These are the parameters used by the startup script "run_fgrun.sh":
{{Note|To reproduce this test, you can use the following [[Fgfsrc]] file - you should set up [[$FG_ROOT]] and [[$FG_SCENERY]] specifically for your own system though.}}
<code>
--airport=LIME
--aircraft=757-200-PW2040
--disable-random-objects
--enable-horizon-effect
--enable-enhanced-lighting
--enable-distance-attenuation
--enable-ai-models
--disable-ai-traffic
--disable-real-weather-fetch
--enable-clouds3d
--bpp=32
--texture-filtering=16
--prop:/sim/rendering/multi-sample-buffers=1
--prop:/sim/rendering/multi-samples=4
--timeofday=noon
--enable-terrasync
--httpd=5500
--props=5501
--jpg-httpd=5502
--multiplay=out,10,,0
--multiplay=in,10,,0
--disable-fgcom
</code>

== Excerpts from the ongoing discussion ==

{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== DDS Debate in 2012 ==

=== Legalities ===
{{See also|Talk:Switching default texture format to DDS#Using patented algorithms}}

{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|t is technically incorrect to provide these s3 patent 
precompressed textures to a driver that does not announce the apropriate 
extension and since we are not allowed to code something that deompresses 
this, I think we should avoid using this compression for all the provided 
models/textures. 
 
I think of a warning that is issued from the image loader in flightgear that 
detects when these precompressed textures are seen. So even people using 
drivers that just offer this extension have a chance to see that the provided 
textures will not work for others.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612879/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

=== Portability Concerns ===
{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|And this is what I try to do now: 
Object against using these patented compression algorithms. 
I do not care for the on disk format of any image file we have. But the problem 
is that some kind of precompression that can be stored in these dds files 
cannot be used with other drivers than the closed ati and nvidia ones. 
As long as these patented compression techiques are not used, every OpenGL 
driver can use this and displays this fine. 
 
Think: Intel has the hugest marketshare in graphics today. If I remember 
right, they sell more than ati and nvidia together (*). This kind of change in 
effect rules out the majority of users as intel cannot work with these files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably 
have the same effect. So I think simply ommitting DDS is ok? 
 
Also, much more important, the comment is not about 'your video driver'. It is 
in your (Vivian) case even wrong. Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I would like to have a flightgear that is by default just running on every 
average system. Having this run faster on a special configured system with some 
better configuration options and hand tuned hardware and drivers is very fine. 
But without tuning it must at least work in an acceptable way. 
 
I have checked in a change to flightgear to make the use of the compressed 
internal formats a starttime configuration option. 
I am still interrested if we have that hangs also with texture compression 
disabled and without providing precompressed dds textures?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28602775/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|this is the reason for the message. If your machine would refuse to display this you, 
developing that, would probably just say 'nice try, but it does not work' 
before you check in something. In the case it displays fine, you probably say 
'it works here, so I assume it works also for others, lets do'. 
And the message tells you, 'despite of just seeing this working on this 
current machine, it does not work for others'.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff. 
 
I am not going to discuss the patent stuff. Please search the mesa-dev archives 
for the discussion and see there why they think that the nvidia tools and 
other stuff out there cannot be used. Really - it is not that the code for that 
is too dificult or unavailable. I am not a lawyer and I cannot change this 
world - even if I would like to in this regard. 
 
I agree that techically for drivers/gpus supporting these compression formats 
it would be best to use these precompressed files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

=== Approaches ===

{{FGCquote
|Well, the default f16 does not work anymore for example. 
I have also never tried the new textures, but I assume that these also contain 
precompressed data? Also you claimed that the old texture files start to bitrot 
comared to the new ones which makes me think that the new standard should be 
the dds files. This together makes me think that the dds files should replace 
the traditional image files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|Hmm, regarding dds. 
I have to say, that not all OpenGL drivers support texture compression, and 
the models with dds files, are those that I cannot display, because of that. 
And in fact this will not happen to the open source drivers before something 
about 2020 because of patent issues. 
 
Sorry to step in this so late - probably way too late - but is there a reason 
that the on disk format must be compressed? 
The previous strategy to have on disk an format that everybody can read and to 
make the driver compress them as needed/possible is better I think? 
 
So, for me the f16 lost its livery lately - where I can live with this for the 
f16, I hope that this does not happen to flightgear as a whole ...
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28594472/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-27</nowiki>
}}
}}

{{FGCquote
|Well, I hope that we can get rid of the compression. 
Can somebody with the apropriate tools convert the compressed textures to non 
compressed ones? That could still be dds, but dds without these compressions 
that produce the warning. So no problem with cubemaps in dds as long as the 
compression is not there. 
Then *everybody* is again able to use this stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678109/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I can see several approaches: 
 
* Just do not use the patented compression stuff. The precomputed mipmaps could 
probably do the job of avoiding the hangs (hopefully? to be checked?). May be 
we could lower disk space usage by providing a dds.gz or similar wrapper? 
 
* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu 
in the database loader thread. This would help all textures not only the ones 
that could be converted. May be this is the most generic solution. 
 
* Implement some kind of image lookup order that knows if the compressed files 
could be handled or not. On loading an image in case of available compression 
first try to find a dds file with the same name of the original one. That 
involves some 'magic' which often leads to problems but that could at least 
work.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

{{FGCquote
|Next step is to make sure that compression is not required to avoid the hangs. 
My favorite bet would be that then the new configure option regarding texture 
compression needs to be set to none.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}
=== Precomputed mipmaps ===

{{FGCquote
|Could we do dds files without compression but with precomputed mipmaps? 
 
So at next, can you try out which combination of compression/provided 
mipmaps/forced simgear compression still work fine?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28603114/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|The 4. Method that I can imagine is to precompute the mipmaps in the loader. 
IIRC tests with some of the guys suffering from this problem, providing 
premipmapped but uncompressed dds files had helped to get a fluent viewer. 
The argument against providing these dds files in general was that these files 
are really huge because of not including any compression and having all the 
mipmaps. 
But that means we could at the point where the warning happens compute the 
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be 
used to do this I think (or something similar not requireing a context). This 
one is an imported version of the original glu function that is included in 
osg for running on an EGL stack which no longer provides GLU. 
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and 
scale this to the 2. mipmap and so forth. 
 
This would have the advantage that the png's do not deviate from the dds files 
over time.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571679/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I think then, computing mipmaps for any texture file on the CPU in the loader 
thread should globally improove the situation. 
Also avoiding the compression already in the files should help every use case. 
Except that the on disk memory consumption is higher. 
Well and except that the database loader has more work to do on the CPU.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612897/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

{{FGCquote
|Doing that differently will provide some overhead that could be kept at a 
minimum I think: 
For the disk usage, I think gzip compressing these will work sufficiently fine. 
Ram usage of the images should not hurt too much. Sure the images are bigger 
in memory. But fgfs is not just about images - far from that. 
On the GPU, you can still use compression for the textures as the internal 
format. This is what flightgear tries to do if the extension is supported 
(checked by osg). 
 
The major point is that there are several ways that use slightly more 
resources to get around this problem. 
But once the patented compression is on disk, there is *no* way back for 
people not having this feature. 
 
If you have better ideas that do not rule out intel and the oss drivers, you 
are welcome!
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this 
also the case for the default win32 case? Is there a osgdb_gz.dll or something 
along the lines in the directory containing the plugins? 
 
If yes, we can already tackle the size problem of the uncompressed dds files on 
disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and 
just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here. 
And I assume that this works fine for all unix like operating systems including 
mac?! 
James?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|What about solution 6 with (uncompressed premipmapped dds).gz? 
On linux this should work as long as you have zlib installed which could be 
regarded as a system library there. 
Can we rely on zlib being compield into our osg distributions on win32? We do 
need zlib in any case, it's mostly about teaching osg that it finds our zlib on 
configure and build the gz plugin.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571819/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I implemented a mipmap control and generation tool in effects when I last updated 
the urban shader. For the moment, it relies on hardware when the average operator 
is used for all texture channels but it could easily be modified to compute 
all mipmap on the CPU. look the <mipmap-control> effect option and 
mipmap.[ch]xx in SG material lib
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606692/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees
& buildings)</nowiki>
|author=<nowiki>Frederic Bouvier</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

== Implementation ==

{{FGCquote
|As has been previously pointed out, the current DDS texture set is not 
simply the global png texture set converted. 
 
For our own sanity and those of the users, we need to ensure that there's 
an apples-to-apples comparison being made when we change the default. I 
therefore think we need to create a DDS version of the current default 
texture set.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|2) If we go down this path, we probably want to separate the underlying 
texture format from the materials.xml definition entirely. For example, we 
could simply remove the extention from the materials definition, and have 
the C++ code append the appropriate extension based on a separate property. 
This has a couple of advantages: 
a) Makes testing easier and materials definitions less error-prone. 
Assuming we have some batch job in place to generate dds textures, those 
working on materials definitions could continue to work with png textures, 
and only convert to dds as a final step (or indeed as part of the "make 
release" jobs). 
a) Avoids duplication of materials definitions. Having just spent quite a 
bit of time making the materials definitions more efficient, I'd like to 
avoid making it worse again! 
 
I'm quite happy to do the C++ coding required for this in the materials 
loader - it's probably pretty straightforward.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|That does leave the issue of what happens to the existing dds texture 
definitions where there are special mipmap layers. I'd suggest that we 
have some Clever Script (tm) that is able to work out whether the DDS or 
PNG version of a texture is the master, and then generate the other version 
from it. I admit that the PNG conversion of the DDS will lose some 
information in this process, but it would allow those without DDS support 
to at least use the textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|3) We need a sensible process for dealing with aircraft, which has been 
identified as a significant issue. Again, I think more aircraft developers 
find .png easier to deal with, and there are a lot of aircraft out there 
that would need conversion. It feels like we need some build scripts to 
"compile" aircraft to use DDS textures. 
 
A more far-fetched idea might be to have a cache of dds textures that are 
generated on-the-fly, or when aircraft are loaded by the aircraft center. 
Clearly that impacts initial load time the first time a new aircraft is 
loaded, and would increase the size of .fgfs/ directories massively, but it 
would remove the need for any work by aircraft/scenery developers and could 
be made optional. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

== Challenges ==

{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==

Also see [[DDS texture conversion]].

{{FGCquote
|the script take the .dds and not convert the png again if both exist(I remember having manually used "compare" to check if both the dds and the png looks the same, and if not i changed some names) 
 
notice that the normal maps are a particular case as you need to tell the effect the texture is dds with a line like: 
 
1 
 
 
just be sure to include this in the normal map effects with png and it will be easier: 
 
0 
 
 
about FG doing the dds conversion , nvcompress is told to be gpl compatible, but i'm not an expert here: 
 
http://nvidia-texture-tools.googlecode.com/svn/trunk/NVIDIA_Texture_Tools_README.txt 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799214/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean pellotier</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

{{FGCquote
|I think this is an inheritance from some other game engine using a different convention, and therefore from the authoring tools that were developed for such an engine (photoshop exporter plugins and the like). If indeed the FGFS DDS textures are only meant to be used in FGFS then this should be fixed at the conversion time. Otherwise, if we want other applications to easily reuse the FGFS textures then it would be better to stick to the most common convention. But I think we all agree that the source for any DDS texture should be kept, which pretty much precludes importing ready made DDS textures from 3rd party sources. Incidentally I think importing DDS artwork from other sources should be discouraged, since it will most likely run afoul of the licensing terms of the original copyright owner.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799324/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>TDO Brandano</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

Nothing as exotic. Just a different "origin" between OpenGL and Direct3D image conventions. OpenGL image origin is located in the lower-left corner, while Direct3D (hence DDS too) considers the top-left as the origin, resulting in a DDS image to appear vertically flipped when read in an OpenGL context. This has repercussions in the way normal-map decoded normals appear (hence the flag in the effects, which signals to the shader to flip the decoded normals). The rest is simply a matter of workflow: either use flipped coordinates and skewed/reversed conventions throughout your whole workflow, or just flip the image and (eventually) set a flag for the shader at "publish" time (said flag could be automatically set by the code on DDS texture load). ''(the latter seems more pragmatic/appealing)''

{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Cons ==

{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

[[Category:Core development projects]]

Switching default texture format to DDS

2014-09-07T09:11:31Z

F-JJTH: /* NVIDIA proprietary driver */

The FG development team is considering to '''switch the default format for textures from png to DDS'''. This would offer a number of significant advantages:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, in essence no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

== Feedback needed - should FlightGear switch the defaults to DDS format for terrain texturing? ==

However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

{{FGCquote
|let's collect some some feedback [on DDS usage in FlightGear] until late November and restart this topic. We probably know by then what we do for the next release. "Somebody" needs to collect the feedback, however.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.
In other words, a lack of feedback from end users might very well mean that future FlightGear versions may require DDS support and may not necessarily work for people with outdated hardware - so if you care about backward compatibility, please do get involved, test DDS support and provide feedback!

=== What we need you to do? ===

FlightGear already provides the simple option to test a DDS texture set. If you are running on Linux and use an open source graphics driver, please take 5 minutes to help during your next FG session:

# Open the dialog under View -> Rendering
# Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'
# Press 'Okay' - FG will reload the terrain
# Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic, or even bright/pink, colors or other rendering artifacts, your system may have problems with DDS.
# Change back to the texture scheme you like best
# Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphics drivers ==

=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|-
|GeForce GT 620 OEM
|331.38
|{{yes}}
|C-GGKV
|-
|GeForce GTX 650
|331.20
|{{yes}}
|dany93
|-
|GeForce 210
|304.117
|{{yes}}
|Jean-Philippe
|-
|GeForce GT 520
|332.21
|{{yes}}
|cossack90
|-
|GeForce GTS 250
|331.38
|{{yes}}
|Madbyte
|-
|GeForce 8600 GT
|340.32
|{{yes}}
|szpajder
|-
|GeForce GTX 460 SE
|331.38
|{{yes}}
|f-jjth
|}

=== NVIDIA open source driver (Nouveau)===

{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GT 630
|
|{{no}}
|[https://plus.google.com/111978238381658236898/posts/VYSusMLRiH2 Jakub Klawiter]
|-
|}

=== Intel proprietary driver ===

=== Intel open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|???
|{{yes}}
|cdesai
|-
|HD Graphics 3000 (i3-2330M)
|10.2.2
|???
|{{yes}}
|Flyhigh/saiarcot895
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|-
|AMD Radeon R9 200 Series
|14.4
|{{yes}}
|Richi
|}

=== ATI/AMD open source driver ===
{| class="wikitable sortable"
!Card
!Driver
!libtxc_dxtn installed?
!DDS ok
!Reported by
|-
|AMD Radeon HD 7950
|10.2.1
|???
|{{yes}}
|Saga
|
|-
|AMD Radeon R9 270X
|10.3~git20140805
|no
|{{no}}
|nine
|
|-
|AMD Radeon R9 270X
|10.3~git20140805
|yes
|{{yes}}
|nine
|}

== Sample test ==

=== DDS Test at the airport of Orio (Bergamo - Italy) ===

[[File:Terrain texture scheme DDS 01-2000.jpg|800px|thumb|Comparison of texture in relation to the three possible choices in "Rendering Options" -> "Terrain texture scheme"]]The final result, with all the "Shader Options" active, is not very satisfactory, I would say very poor. Apparently not check on any improvement in the speed of image loading. I think on modern machines with quad-core processors 16 GB, with latest graphics cards (NVIDIA 870) 6 GB, the loading of these images is not really a "bottleneck". I propose to insert the DDS functionality, but in a transparent way, ie convert "on the fly" the images before inserting them into the temporary memory, for example using the convert function of ImageMagick. However, I do not know if it really is a useful feature, I think there are many other things to do before this. These are the parameters used by the startup script "run_fgrun.sh":
{{Note|To reproduce this test, you can use the following [[Fgfsrc]] file - you should set up [[$FG_ROOT]] and [[$FG_SCENERY]] specifically for your own system though.}}
<code>
--airport=LIME
--aircraft=757-200-PW2040
--disable-random-objects
--enable-horizon-effect
--enable-enhanced-lighting
--enable-distance-attenuation
--enable-ai-models
--disable-ai-traffic
--disable-real-weather-fetch
--enable-clouds3d
--bpp=32
--texture-filtering=16
--prop:/sim/rendering/multi-sample-buffers=1
--prop:/sim/rendering/multi-samples=4
--timeofday=noon
--enable-terrasync
--httpd=5500
--props=5501
--jpg-httpd=5502
--multiplay=out,10,,0
--multiplay=in,10,,0
--disable-fgcom
</code>

== Excerpts from the ongoing discussion ==

{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== DDS Debate in 2012 ==

=== Legalities ===
{{See also|Talk:Switching default texture format to DDS#Using patented algorithms}}

{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|t is technically incorrect to provide these s3 patent 
precompressed textures to a driver that does not announce the apropriate 
extension and since we are not allowed to code something that deompresses 
this, I think we should avoid using this compression for all the provided 
models/textures. 
 
I think of a warning that is issued from the image loader in flightgear that 
detects when these precompressed textures are seen. So even people using 
drivers that just offer this extension have a chance to see that the provided 
textures will not work for others.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612879/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

=== Portability Concerns ===
{{FGCquote
|These kind of precompressed images limits their usage to a specific set of 
drivers. And no, due to the patent issues no open source code including ours 
is allowed to implement compression/decompression code for these image 
formats. Even if this is easy implementation wise.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|And this is what I try to do now: 
Object against using these patented compression algorithms. 
I do not care for the on disk format of any image file we have. But the problem 
is that some kind of precompression that can be stored in these dds files 
cannot be used with other drivers than the closed ati and nvidia ones. 
As long as these patented compression techiques are not used, every OpenGL 
driver can use this and displays this fine. 
 
Think: Intel has the hugest marketshare in graphics today. If I remember 
right, they sell more than ati and nvidia together (*). This kind of change in 
effect rules out the majority of users as intel cannot work with these files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|It's not limited to dds. If you use osgconv xxx.dds xxx.ivs you will probably 
have the same effect. So I think simply ommitting DDS is ok? 
 
Also, much more important, the comment is not about 'your video driver'. It is 
in your (Vivian) case even wrong. Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I would like to have a flightgear that is by default just running on every 
average system. Having this run faster on a special configured system with some 
better configuration options and hand tuned hardware and drivers is very fine. 
But without tuning it must at least work in an acceptable way. 
 
I have checked in a change to flightgear to make the use of the compressed 
internal formats a starttime configuration option. 
I am still interrested if we have that hangs also with texture compression 
disabled and without providing precompressed dds textures?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28602775/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|this is the reason for the message. If your machine would refuse to display this you, 
developing that, would probably just say 'nice try, but it does not work' 
before you check in something. In the case it displays fine, you probably say 
'it works here, so I assume it works also for others, lets do'. 
And the message tells you, 'despite of just seeing this working on this 
current machine, it does not work for others'.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff. 
 
I am not going to discuss the patent stuff. Please search the mesa-dev archives 
for the discussion and see there why they think that the nvidia tools and 
other stuff out there cannot be used. Really - it is not that the code for that 
is too dificult or unavailable. I am not a lawyer and I cannot change this 
world - even if I would like to in this regard. 
 
I agree that techically for drivers/gpus supporting these compression formats 
it would be best to use these precompressed files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Seriously, I think plenty people not being on this list today and probably 
never will be in touch with anybody here, will run into this issue. 
People here are those few guys from the power users that want to develop this 
stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|Your driver will display this fine. 
So, in the end I do not care if it is 'your particular video driver' that does 
not like this. You will just see this in the best case as the models look 
wrong, and in the worst case fgfs just crashes the driver if these textures 
are used. 
What I really care about is that these files are expected not to work on a huge 
amount of graphics boards out there. The point is to tell people doing 
textures that they should omit compression so that this message disapears.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

=== Approaches ===

{{FGCquote
|Well, the default f16 does not work anymore for example. 
I have also never tried the new textures, but I assume that these also contain 
precompressed data? Also you claimed that the old texture files start to bitrot 
comared to the new ones which makes me think that the new standard should be 
the dds files. This together makes me think that the dds files should replace 
the traditional image files.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28604650/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|Hmm, regarding dds. 
I have to say, that not all OpenGL drivers support texture compression, and 
the models with dds files, are those that I cannot display, because of that. 
And in fact this will not happen to the open source drivers before something 
about 2020 because of patent issues. 
 
Sorry to step in this so late - probably way too late - but is there a reason 
that the on disk format must be compressed? 
The previous strategy to have on disk an format that everybody can read and to 
make the driver compress them as needed/possible is better I think? 
 
So, for me the f16 lost its livery lately - where I can live with this for the 
f16, I hope that this does not happen to flightgear as a whole ...
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28594472/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-27</nowiki>
}}
}}

{{FGCquote
|Well, I hope that we can get rid of the compression. 
Can somebody with the apropriate tools convert the compressed textures to non 
compressed ones? That could still be dds, but dds without these compressions 
that produce the warning. So no problem with cubemaps in dds as long as the 
compression is not there. 
Then *everybody* is again able to use this stuff.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678109/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|I can see several approaches: 
 
* Just do not use the patented compression stuff. The precomputed mipmaps could 
probably do the job of avoiding the hangs (hopefully? to be checked?). May be 
we could lower disk space usage by providing a dds.gz or similar wrapper? 
 
* If it's just the mipmaps. May be we can precompute the mipmaps using the cpu 
in the database loader thread. This would help all textures not only the ones 
that could be converted. May be this is the most generic solution. 
 
* Implement some kind of image lookup order that knows if the compressed files 
could be handled or not. On loading an image in case of available compression 
first try to find a dds file with the same name of the original one. That 
involves some 'magic' which often leads to problems but that could at least 
work.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

{{FGCquote
|Next step is to make sure that compression is not required to avoid the hangs. 
My favorite bet would be that then the new configure option regarding texture 
compression needs to be set to none.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606576/
|title=<nowiki>[Flightgear-devel] DDS texures (Was: Improving random trees &
buildings)</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}
=== Precomputed mipmaps ===

{{FGCquote
|Could we do dds files without compression but with precomputed mipmaps? 
 
So at next, can you try out which combination of compression/provided 
mipmaps/forced simgear compression still work fine?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28603114/
|title=<nowiki>Re: [Flightgear-devel] Improving random trees & buildings</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2011-12-29</nowiki>
}}
}}

{{FGCquote
|The 4. Method that I can imagine is to precompute the mipmaps in the loader. 
IIRC tests with some of the guys suffering from this problem, providing 
premipmapped but uncompressed dds files had helped to get a fluent viewer. 
The argument against providing these dds files in general was that these files 
are really huge because of not including any compression and having all the 
mipmaps. 
But that means we could at the point where the warning happens compute the 
mipmap levels on the cpu in the loader thread. osg::gluScaleImage could be 
used to do this I think (or something similar not requireing a context). This 
one is an imported version of the original glu function that is included in 
osg for running on an EGL stack which no longer provides GLU. 
That is take the image scale this to the 1st mipmap, take the 1.st mipmap and 
scale this to the 2. mipmap and so forth. 
 
This would have the advantage that the png's do not deviate from the dds files 
over time.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571679/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I think then, computing mipmaps for any texture file on the CPU in the loader 
thread should globally improove the situation. 
Also avoiding the compression already in the files should help every use case. 
Except that the on disk memory consumption is higher. 
Well and except that the database loader has more work to do on the CPU.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28612897/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-01</nowiki>
}}
}}

{{FGCquote
|Doing that differently will provide some overhead that could be kept at a 
minimum I think: 
For the disk usage, I think gzip compressing these will work sufficiently fine. 
Ram usage of the images should not hurt too much. Sure the images are bigger 
in memory. But fgfs is not just about images - far from that. 
On the GPU, you can still use compression for the textures as the internal 
format. This is what flightgear tries to do if the extension is supported 
(checked by osg). 
 
The major point is that there are several ways that use slightly more 
resources to get around this problem. 
But once the patented compression is on disk, there is *no* way back for 
people not having this feature. 
 
If you have better ideas that do not rule out intel and the oss drivers, you 
are welcome!
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678784/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|On unix I usually get the gzip plugin installed by osg (osgdb_gz.so). Is this 
also the case for the default win32 case? Is there a osgdb_gz.dll or something 
along the lines in the directory containing the plugins? 
 
If yes, we can already tackle the size problem of the uncompressed dds files on 
disk by just gzip compressing these makging a xxx.dds.gz from a xxx.dds and 
just refering to xxx.dds.gz instead of xxx.dds. At least this works fine here. 
And I assume that this works fine for all unix like operating systems including 
mac?! 
James?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28678235/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees &</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-01-15</nowiki>
}}
}}

{{FGCquote
|What about solution 6 with (uncompressed premipmapped dds).gz? 
On linux this should work as long as you have zlib installed which could be 
regarded as a system library there. 
Can we rely on zlib being compield into our osg distributions on win32? We do 
need zlib in any case, it's mostly about teaching osg that it finds our zlib on 
configure and build the gz plugin.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/29571819/
|title=<nowiki>Re: [Flightgear-devel] DDS usage in effects files</nowiki>
|author=<nowiki>Mathias Fröhlich</nowiki>
|date=<nowiki>2012-07-21</nowiki>
}}
}}

{{FGCquote
|I implemented a mipmap control and generation tool in effects when I last updated 
the urban shader. For the moment, it relies on hardware when the average operator 
is used for all texture channels but it could easily be modified to compute 
all mipmap on the CPU. look the <mipmap-control> effect option and 
mipmap.[ch]xx in SG material lib
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/28606692/
|title=<nowiki>Re: [Flightgear-devel] DDS texures (Was: Improving random trees
& buildings)</nowiki>
|author=<nowiki>Frederic Bouvier</nowiki>
|date=<nowiki>2011-12-30</nowiki>
}}
}}

== Implementation ==

{{FGCquote
|As has been previously pointed out, the current DDS texture set is not 
simply the global png texture set converted. 
 
For our own sanity and those of the users, we need to ensure that there's 
an apples-to-apples comparison being made when we change the default. I 
therefore think we need to create a DDS version of the current default 
texture set.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|2) If we go down this path, we probably want to separate the underlying 
texture format from the materials.xml definition entirely. For example, we 
could simply remove the extention from the materials definition, and have 
the C++ code append the appropriate extension based on a separate property. 
This has a couple of advantages: 
a) Makes testing easier and materials definitions less error-prone. 
Assuming we have some batch job in place to generate dds textures, those 
working on materials definitions could continue to work with png textures, 
and only convert to dds as a final step (or indeed as part of the "make 
release" jobs). 
a) Avoids duplication of materials definitions. Having just spent quite a 
bit of time making the materials definitions more efficient, I'd like to 
avoid making it worse again! 
 
I'm quite happy to do the C++ coding required for this in the materials 
loader - it's probably pretty straightforward.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|That does leave the issue of what happens to the existing dds texture 
definitions where there are special mipmap layers. I'd suggest that we 
have some Clever Script (tm) that is able to work out whether the DDS or 
PNG version of a texture is the master, and then generate the other version 
from it. I admit that the PNG conversion of the DDS will lose some 
information in this process, but it would allow those without DDS support 
to at least use the textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

{{FGCquote
|3) We need a sensible process for dealing with aircraft, which has been 
identified as a significant issue. Again, I think more aircraft developers 
find .png easier to deal with, and there are a lot of aircraft out there 
that would need conversion. It feels like we need some build scripts to 
"compile" aircraft to use DDS textures. 
 
A more far-fetched idea might be to have a cache of dds textures that are 
generated on-the-fly, or when aircraft are loaded by the aircraft center. 
Clearly that impacts initial load time the first time a new aircraft is 
loaded, and would increase the size of .fgfs/ directories massively, but it 
would remove the need for any work by aircraft/scenery developers and could 
be made optional. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32797669/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Stuart Buchanan</nowiki>
|date=<nowiki>2014-09-04</nowiki>
}}
}}

== Challenges ==

{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==

Also see [[DDS texture conversion]].

{{FGCquote
|the script take the .dds and not convert the png again if both exist(I remember having manually used "compare" to check if both the dds and the png looks the same, and if not i changed some names) 
 
notice that the normal maps are a particular case as you need to tell the effect the texture is dds with a line like: 
 
1 
 
 
just be sure to include this in the normal map effects with png and it will be easier: 
 
0 
 
 
about FG doing the dds conversion , nvcompress is told to be gpl compatible, but i'm not an expert here: 
 
http://nvidia-texture-tools.googlecode.com/svn/trunk/NVIDIA_Texture_Tools_README.txt 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799214/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean pellotier</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

{{FGCquote
|I think this is an inheritance from some other game engine using a different convention, and therefore from the authoring tools that were developed for such an engine (photoshop exporter plugins and the like). If indeed the FGFS DDS textures are only meant to be used in FGFS then this should be fixed at the conversion time. Otherwise, if we want other applications to easily reuse the FGFS textures then it would be better to stick to the most common convention. But I think we all agree that the source for any DDS texture should be kept, which pretty much precludes importing ready made DDS textures from 3rd party sources. Incidentally I think importing DDS artwork from other sources should be discouraged, since it will most likely run afoul of the licensing terms of the original copyright owner.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32799324/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>TDO Brandano</nowiki>
|date=<nowiki>2014-09-05</nowiki>
}}
}}

Nothing as exotic. Just a different "origin" between OpenGL and Direct3D image conventions. OpenGL image origin is located in the lower-left corner, while Direct3D (hence DDS too) considers the top-left as the origin, resulting in a DDS image to appear vertically flipped when read in an OpenGL context. This has repercussions in the way normal-map decoded normals appear (hence the flag in the effects, which signals to the shader to flip the decoded normals). The rest is simply a matter of workflow: either use flipped coordinates and skewed/reversed conventions throughout your whole workflow, or just flip the image and (eventually) set a flag for the shader at "publish" time (said flag could be automatically set by the code on DDS texture load). ''(the latter seems more pragmatic/appealing)''

{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Cons ==

{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

[[Category:Core development projects]]

Building using CMake - Windows

2014-08-26T19:07:51Z

F-JJTH:

{{Main article|Building Flightgear}}

== Required software ==
* [http://www.cmake.org CMake GUI]
* [http://www.microsoft.com/visualstudio/en-us/products/2010-editions/visual-cpp-express Microsoft Visual Studio 2010 Express] (MSVC)
* [http://www.microsoft.com/en-us/download/details.aspx?id=8279 Microsoft Windows SDK] (only required for 64-bit builds)
: If you get an error during the installation of the SDK, try uninstalling MSVC redist packages first, then installing the SDK without compilers and then finally re-installing MSVC.
* [http://www.microsoft.com/en-au/download/details.aspx?id=23691 Visual Studio 2010 SP1] (If you get a linking error during the configure process)

== Obtaining source ==
{{Main article|FlightGear and Git}}
Throughout this article it is assumed that you've already set up git clones of the various source repositories (FlightGear, SimGear, data...).

== Directory tree ==
On Windows, assumptions on the directory structure are made to automate the discovery of dependencies. This recommended directory structure is described below. Clicking the links allows you to download pre-built parts. If you do not use the recommended structure you will need to enter paths by hand. Source and build directories can be located anywhere.

=== 32-bits ===
<tt>
: ${MSVC_3RDPARTY_ROOT} /
:: [http://flightgear.simpits.org:8080/job/3rdParty-Win/lastSuccessfulBuild/artifact/3rdParty/*zip*/3rdParty.zip 3rdParty] / </tt> ( includes plib, fltk, zlib, libpng, libjpeg, libtiff, freetype, libsvn, gdal, ... ) <tt>
::: bin /
::: include /
::: lib /
:: [http://flightgear.simpits.org:8080/job/Boost-Win/lastSuccessfulBuild/artifact/*zip*/archive.zip Boost] / </tt> (latest version can be downloaded from http://www.boost.org/) <tt>
::: boost /
::: lib /
:: install /
::: msvc100 / </tt> ( for VS2010 32 bits, or msvc90 for VS2008 32-bits ) <tt>
:::: [http://flightgear.simpits.org:8080/view/Win/job/OSG-Win/lastSuccessfulBuild/artifact/install/msvc100/OpenSceneGraph/*zip*/OpenSceneGraph.zip OpenSceneGraph] / </tt> ( OSG CMake install ) <tt>
::::: bin /
::::: include /
::::: lib /
:::: SimGear / </tt> (create this empty for now, subfolders will be created by build process) <tt>
::::: include /
::::: lib /
:::: FlightGear / </tt> (create this empty for now) <tt>
::::: include /
::::: lib /</tt>

=== 64-bits ===
<tt>
: ${MSVC_3RDPARTY_ROOT} /
:: [http://flightgear.simpits.org:8080/job/3rdParty-Win/lastSuccessfulBuild/artifact/3rdParty.x64/*zip*/3rdParty.x64.zip 3rdParty.x64] /
::: bin /
::: include /
::: lib /
:: [http://flightgear.simpits.org:8080/job/Boost-Win64/lastSuccessfulBuild/artifact/*zip*/archive.zip Boost] /
::: boost /
::: lib64 /
:: install /
::: msvc100-64 / </tt> ( for VS2010 64-bits, or msvc90-64 for VS2008 64-bits ) <tt>
:::: [http://flightgear.simpits.org:8080/view/Win/job/OSG-Win/lastSuccessfulBuild/artifact/install/msvc100-64/OpenSceneGraph/*zip*/OpenSceneGraph.zip OpenSceneGraph] / </tt> ( OSG CMake install ) <tt>
::::: bin /
::::: include /
::::: lib /
:::: SimGear / </tt> (create this empty for now, subfolders will be created by build process) <tt>
::::: include /
::::: lib /
:::: FlightGear / </tt> (create this empty for now) <tt>
::::: include /
::::: lib /</tt>

NdT: glut is missing for the 64bits build, you can use [http://www.transmissionzero.co.uk/software/freeglut-devel/ freeglut].

== Building ==
# Set up a work directory as described above.
# '''Building SimGear'''
## Open the CMake gui.
## Set <tt>"Where is the source code"</tt> to wherever you put the SimGear sources (from the released tarball or the git repository).
## Set <tt>"Where to build the binaries"</tt> to a new empty directory (could be anywhere and any name, for example naming it simgear-build, at the same folder location as your unzipped SimGear source folder was put).
## Press [[File:CMake GUI Configure.png]]. The first time that the project is configured, CMake will bring up a window asking you to "Specify the generator for this project" i.e. which compiler you wish to use. Select Visual Studio 10 (or Visual Studio 10 Win64 for 64-bit), and press Finish. CMake will now do a check on your system and will produce a preliminary build configuration.
## CMake adds new configuration variables in red. Some have a value ending with <tt>-NOTFOUND</tt>. These variables should receive your attention. Some errors will prevent SimGear from building and others will simply invalidate some options without causing build errors.
### First check the <tt>MSVC_3RDPARTY_ROOT</tt> variable. If it is not set, chances are that there will be a lot of <tt>-NOTFOUND</tt> errors. Instead of trying to fix every error individually, set that variable to the location of the directory structure that is presented above. Then press [[File:CMake GUI Configure.png]] again.
### Set the <tt>CMAKE_INSTALL_PREFIX</tt> variable to <tt>${MSVC_3RDPARTY_ROOT}/install/msvc100/SimGear</tt>.
### Also check the lines with a checkbox. These are build options and may impact the feature set of the built program.
## Repeat the process from step 5, until [[File:CMake GUI Generate.png]] is enabled.
## Press [[File:CMake GUI Generate.png]].
## Start Visual Studio 2010 and load the SimGear solution (SimGear.sln) located in <tt>"Where to build the binaries"</tt>.
## Choose the <tt>"Release"</tt> build in the VS2010 "Generation" toolbar. The right menu should read Win32 for 32-bits or x64 for 64-bits. [[File:MVSC 2010 solution.png|right]]
## Generate the solution with F7 key or right-click the top level "Solution SimGear" in the Solution Explorer and choose Build.
## If there are build errors, return to CMake, clear remaining errors, [[File:CMake GUI Configure.png]] and [[File:CMake GUI Generate.png]].
## When Visual Studio is able to build everything without errors, right-click on the <tt>INSTALL</tt> project (further down within the "Solution Simgear" solution) and choose Build, which will put the include and lib files in <tt>${CMAKE_INSTALL_PREFIX}</tt>
# '''Building FlightGear'''
#: Repeat the steps under Building Simgear, but change the <tt>SimGear</tt> paths to <tt>FlightGear</tt>.
# Enjoy!

==== Build options ====
To include [[LaRCsim]]/[[UIUC]] in your build, set:
ENABLE_LARCSIM:BOOL=ON
ENABLE_UIUC_MODEL:BOOL=ON

=== Updating ===
When updating the source from [[git]], it is usually unnecessary to restart CMake as the solution is able to reconfigure itself when CMake files are changed. Simply rebuild the solution from Visual Studio and accept the reload of updated projects. When the Simgear/FlightGear version numbers change, you do have to re-run CMake.

It is also possible to edit CMakeList.txt files directly in Visual Studio as they also appear in the solution, and projects will be reconfigured on the next generation. To change build options or directory path, it is mandatory to use the CMake Gui. In case of problems, locate the <tt>CMakeCache.txt</tt> file in <tt>"Where to build the binaries”</tt> directory and delete it to reconfigure from scratch or use the menu item <tt>File > Delete Cache</tt>.

=== TerraGear ===
TerraGear can be built the same way as FlightGear, just change the paths to your TerraGear source and directories.

== Jenkins Windows configurations ==
When using CMake GUI, you can add those entries by clicking the Add entry button. Note that you should omit the -D prefix.

=== OSG-stable-Win ===
cmake ..\svn -G "Visual Studio 10"
-DACTUAL_3RDPARTY_DIR:PATH=%WORKSPACE%/3rdParty
-DBUILD_OSG_APPLICATIONS:BOOL=ON
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/OpenSceneGraph
-DOSG_PLUGIN_SEARCH_INSTALL_DIR_FOR_PLUGINS:BOOL=OFF
-DFREETYPE_LIBRARY:FILEPATH=%WORKSPACE%/3rdParty/lib/freetype243.lib
-DGDAL_INCLUDE_DIR:PATH=
-DGDAL_LIBRARY:FILEPATH=
=== SimGear-Win-CMake ===
cmake ..\SimGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/SimGear
=== FlightGear-Win-CMake ===
cmake ..\FlightGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/FlightGear
-DFLTK_FLUID_EXECUTABLE=%WORKSPACE%/3rdParty/bin/fluid.exe
=== FGRun-Win-CMake ===
cmake ..\svn -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT:PATH=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/FGRun
-DFLTK_FLUID_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/fluid.exe
-DGETTEXT_MSGFMT_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/msgfmt.exe
-DGETTEXT_MSGMERGE_EXECUTABLE:FILEPATH=%WORKSPACE%/3rdParty/bin/msgmerge.exe
=== TerraGear-Win-CMake ===
cmake ..\TerraGear -G "Visual Studio 10"
-DMSVC_3RDPARTY_ROOT=%WORKSPACE%
-DCMAKE_INSTALL_PREFIX:PATH=%WORKSPACE%/install/msvc100/TerraGear
-DGPC_LIBRARY=%WORKSPACE%/3rdParty/lib/gpc232.lib
-DNEWMAT_LIBRARY=%WORKSPACE%/3rdParty/lib/newmat11.lib

== External link ==
* [https://gitorious.org/fg/flightgear/blobs/next/docs-mini/README.MSVC README.MSVC] (at Gitorious)

{{building}}
[[fr:compiler flightear avec CMake - Windows]]

FGCom 3.0

2014-08-09T20:12:21Z

F-JJTH: /* How to test your setup ? */

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# You can also check that your PTT works fine looking at the "PTT test" checkbox when you press your PTT button (default is spacebar)
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Test : check/uncheck this for testing server communication (Echo-Box)
* Speaker volume : set speaker volume for FGCom built-in
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Originating an audio only call
Call 0 accepted
Echo Box - For testing FGCOM
Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "-h" argument will show you all available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

''' I'm using Linux and I can't get FGCom working '''

Please read this page which has a lot of information about audio configuration for Linux user, even some specific reference to FGCom: [[Linux software audio mixing with FlightGear]]

[[fr:FGCom 3.0]]
[[Category:FGCom]]

FGCom 3.0

2014-05-29T22:57:53Z

F-JJTH: Move the "Linux audio" part in FAQ with link for detailed instructions

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Test : check/uncheck this for testing server communication (Echo-Box)
* Speaker volume : set speaker volume for FGCom built-in
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Originating an audio only call
Call 0 accepted
Echo Box - For testing FGCOM
Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "-h" argument will show you all available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

''' I'm using Linux and I can't get FGCom working '''

Please read this page which has a lot of information about audio configuration for Linux user, even some specific reference to FGCom: [[Linux software audio mixing with FlightGear]]

[[fr:FGCom 3.0]]
[[Category:FGCom]]

Linux software audio mixing with FlightGear

2014-05-29T22:54:09Z

F-JJTH: Move info from FGCom_3.0 to this page

This article describes, with a soundcard that does not do hardware mixing, how you can run FlightGear with other audio applications, such as Festival for text-to-speech and running TeamSpeak at the same time, with ALSA software mixing (<code>dmix</code> and <code>dsnoop</code> plugin).

== Quick start ==

* [[#FlightGear|Getting FlightGear to use ALSA, esd (Gnome), or arts (KDE)]].
* [[#Festival|Getting Festival to use ALSA]].
* [[#TeamSpeak|Getting TeamSpeak to use ALSA]].

== Audio mixing what? ==

One of the most common issues with soundcard and Linux is when you can only have one application playing sound at a time on some systems. This happens when the soundcard itself does not do audio mixing (i.e. hardware mixing).

Audio mixing allows multiple audio (PCM) streams to be "mixed" together and to be played at the same time. It is generally better and more efficient for a soundcard, if available, to do audio mixing in the hardware.

Software audio mixing is useful when you have a soundcard not capable of doing hardware mixing. Under Linux, software mixing can be done by ALSA's <code>dmix</code> / <code>dsnoop</code> plugin, or by userspace applications, like ESD and ARTS. Software uses your CPU to do the work and mixes multiple audio streams into one, before passing the audio data onto your soundcard for playback.

On Windows, software mixing is enabled by default transparently. Because of this, most people would have no idea about the capability of their sound cards in the Windows world. This is debatable whether this is good or bad, and is out of scope of this article.

With ALSA, an easy to test whether your soundcard supports hardware mixing or not would be running this following twice, say in two different terminals:

<pre>
$ aplay -D hw:0,0 test.wav
</pre>

This tells <code>aplay</code>, the ALSA audio player, to play the file <code>test.wav</code> using the first sound hardware directly, without using any plugin or any software mixing. For a soundcard without hardware mixing support, the second <code>aplay</code> would fail, and might look like this:

<pre>
$ aplay -D hw:0,0 test.wav
aplay: main:547: audio open error: Device or resource busy
</pre>

You could also find out from ALSA's driver info, by doing:

<pre>
$ cat /proc/asound/pcm
00-00: Intel ICH : Intel 82801DB-ICH4 : playback 1 : capture 1
00-01: Intel ICH - MIC ADC : Intel 82801DB-ICH4 - MIC ADC : capture 1
00-02: Intel ICH - MIC2 ADC : Intel 82801DB-ICH4 - MIC2 ADC : capture 1
00-03: Intel ICH - ADC2 : Intel 82801DB-ICH4 - ADC2 : capture 1
00-04: Intel ICH - IEC958 : Intel 82801DB-ICH4 - IEC958 : playback 1
01-00: Intel ICH - Modem : Intel 82801DB-ICH4 Modem - Modem : playback 1 : capture 1
</pre>

Notice the first line, "<code>playback 1</code>", indicating the device only supports one PCM audio playback at any time.

With a soundcard that supports hardware audio mixing, the same check looks like this:

<pre>
$ cat /proc/asound/pcm
00-00: emu10k1 : EMU10K1 : playback 32 : capture 1
00-01: emu10k1 mic : EMU10K1 MIC : capture 1
00-02: emu10k1 efx : EMU10K1 EFX : playback 8 : capture 1
</pre>

As you can see, the first line suggests this device supports 32 simultaneous PCM audio playback.

== Prerequisites ==

This article assumes you have a basic understanding and knowledge of Linux. For instance:

* <code>~/</code> refers to your HOME directory. If your user name is <code>blah</code>, then <code>~/</code> normally would be <code>/home/blah/</code>. And so <code>~/.asoundrc</code> would mean <code>/home/blah/.asoundrc</code>

* Files with names starting with a dot (".") are normally considered as hidden files. If you're using some sort of file manager application, remember to turn on or enable showing these hidden files.

* If a "dot rc" file (e.g. <code>.asoundrc</code>, <code>.openalrc</code>) does not exist, simply creates it.

This article assumes you have ALSA setup and working with your soundcard(s).

== The concept ==

It is simple. You want to get all the applications to use the ALSA <code>dmix</code> plugin for PCM audio playback, and sometimes also the <code>dsnoop</code> plugin for audio recording.

According to ALSA, <code>dmix</code> plugin is enabled and used by default since ALSA 1.0.9rc2. Though it seems it does not work straight away for everyone.

There are a lot of pages on the net with different customized ALSA configuration (e.g. <code>.asoundrc</code>) to use "dmix" by default. This article's approach is NOT to touch any ALSA configuration file, but simply per-application setup.

In general, for applications written with ALSA support, usually what you need is to get is to use the device <code>"plug:dmix"</code>. For example, with the ALSA command line player <code>aplay</code>, you run:

<pre>
$ aplay -D "plug:dmix" test.wav
</pre>

It's a good idea to run this to test if your <code>dmix</code> works.

For applications which does not have ALSA support (i.e. using OSS), you have a few choices:

; <code>aoss</code> : A wrapper script to run any application to use ALSA OSS. This works using simply via <code>LD_PRELOAD</code> to preload <code>libaoss.so</code>. It *seems* to use <code>dmix</code> if available automatically.

; <code>esd</code> : A software audio mixing daemon, typically shipped with GNOME. You can use its wrapper <code>esddsp</code> with other applications. You could run:
<pre>
$ esd -d plug:dmix
</pre>

; <code>artsd</code> : Another software audio mixing daemon, typically shipped with KDE. You can use its wrapper <code>artsdsp</code> with other applications. You could run:
<pre>
$ artsd -D plug:dmix
</pre>

However, not all apps work with all these wrappers. For example, festival does not seem to work properly with <code>aoss</code> and <code>artsd</code>. If possible it's a good idea to try all three approaches to get an OSS application to do ALSA.

<code>esd</code> does not seem to handle recording properly. So if you have an OSS application which does audio recording (say TeamSpeak), <code>esd</code> / <code>esddsp</code> will probably not work.

== OSS? ALSA? ==

So how do you tell whether an application uses OSS or ALSA? There are a few simple ways.

Usually if an application uses the audio device via <code>/dev/dsp</code> (or <code>/dev/dsp0</code>, <code>/dev/dsp1</code>, etc), then it is probably using OSS. With ALSA, you normally specify an audio device using a string, which might look something like "<code>hw:0,0</code>" or "<code>plug:dmix</code>", or sometimes "<code>ALSA:default</code>", depending on the application itself.

=== <code>'''ldd'''</code> ===

<code>ldd</code> prints what shared libraries an application depends on.

Take <code>aplay</code> again as an example, you do:

<pre>
$ ldd /usr/bin/aplay
linux-gate.so.1 => (0xffffe000)
libasound.so.2 => /usr/lib/libasound.so.2 (0x40037000)
libm.so.6 => /lib/tls/libm.so.6 (0x400f9000)
libdl.so.2 => /lib/tls/libdl.so.2 (0x4011f000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0x40123000)
libc.so.6 => /lib/tls/libc.so.6 (0x40135000)
/lib/ld-linux.so.2 (0x40000000)
</pre>

Note the <code>libasound.so.2</code>, which is the ALSA library, which *possibly* means <code>aplay</code> *CAN* use ALSA. It does not have to, however. It's up to an application to use whatever audio support it wants to use. An example would be applications like <code>mplayer</code> and <code>xine</code>, which can do audio playback using many different audio libraries/approaches (OSS, ALSA, ESD, ARTS, and more).

=== <code>'''strace'''</code> ===

<code>strace</code> is a rather powerful tool, which traces and prints system calls of a running application.

Take <code>mpg123</code> as an example, you do:

<pre>
$ strace -f -e open /usr/bin/mpg123 -q test.mp3
open("/etc/ld.so.cache", O_RDONLY) = 3
open("/lib/tls/libm.so.6", O_RDONLY) = 3
open("/lib/tls/libc.so.6", O_RDONLY) = 3
open("/dev/dsp", O_WRONLY) = 3
open("test.mp3", O_RDONLY) = 3
open("/dev/dsp", O_WRONLY) = 4
open("/dev/dsp", O_WRONLY) = 4
</pre>

This shows all calls to the system call <code>open()</code> of this running instance of <code>mpg123</code>. As you can see it is opening <code>/dev/dsp</code>, which hints it is using OSS.

For an ALSA application, you will see a lot of <code>open()</code> calls to devices like <code>/dev/snd/controlC0</code>, <code>/dev/aloadC2</code>, <code>/dev/snd/pcmC0D0p</code>, etc. (Try <code>strace</code> with <code>aplay</code>!)

== FlightGear ==

FlightGear uses OpenAL (via SimGear) for audio playback, and OpenAL supports ALSA, ESD and ARTS. However you have to make sure your OpenAL is built with the audio support you need. Run <code>configure --help</code> if you are building your own OpenAL.

=== OpenAL-soft ===

[http://kcat.strangesoft.net/openal.html OpenAL-soft] is a LGPL-licensed implementation of the OpenAL 3D audio API. It is the default OpenAL library in some Linux distribution, among them Debian.

To get OpenAL-soft to use a particular ALSA device, put this in your <code>~/.alsoftrc</code>

<pre>
format = AL_FORMAT_STEREO16
cf_level = 2
drivers = alsa
[alsa] # ALSA backend options
device = plug:dmix
capture = plug:dsnoop
</pre>

[NOTE: format is now "sample-type = uint16", and cf_level would appear not needed for typical users, or only desired for headphone users.]

See your system wide OpenAL-soft configuration file, typically <code>/etc/openal/alsoft.conf</code>, for an overview of the available options.

=== OpenAL ===

To get OpenAL to use a particular ALSA device, put these in your <code>~/.openalrc</code>

<pre>
(define devices '(alsa))
(define alsa-out-device "plug:dmix")
(device alsa-in-device "plug:dsnoop")
</pre>

To get OpenAL to use ESD:

<pre>
(define devices '(esd))
</pre>

And to get OpenAL to use ARTS:

<pre>
(define devices '(arts))
</pre>

== Festival ==

There are two ways to get Festival to use ALSA.

=== ESD ===

Festival supports a couple of audio method for playback, and one of them is ESD support. To have it use ESD by default, put this in your <code>~/.festivalrc</code>:

<pre>
(Parameter.set 'Audio_Method 'esdaudio)
</pre>

And then run <code>festival</code> as usual. So:

<pre>
$ festival --server
</pre>

Of course, you'll have to make sure your ESD is running, for example:

<pre>
$ esd -d plug:dmix
</pre>

If for some reasons this does not work, you could always try using <code>esddsp</code>, which means you would be running:

<pre>
$ esddsp festival --server
</pre>

Test your festival server by:

<pre>
$ echo '(SayText "Hello")' | festival_client
</pre>

=== Using the <code>Audio_Command</code> parameter ===

You can configure festival to run another application for playing audio. In this case, we could use <code>aplay</code> to help us. In your <code>~/.festivalrc</code> put:

<pre>
(Parameter.set 'Audio_Command "aplay -D plug:dmix -q -c 1 -t raw -f s16 -r $SR $FILE")
(Parameter.set 'Audio_Method 'Audio_Command)
</pre>

<code>$SR</code> is the sampling rate, and <code>$FILE</code> is the audio data file generated by festival for playback.

== TeamSpeak ==

TeamSpeak works with <code>aoss</code> and <code>artsd</code> / <code>artsdsp</code>. It does not work with <code>esd</code> / <code>esddsp</code>, because <code>esd</code> does not seem to handle recording properly.

=== <code>'''aoss'''</code> ===

To run TeamSpeak, do:

<pre>
$ aoss TeamSpeak
</pre>

=== <code>'''arts'''</code> ===

You have to run <code>artsd</code> with <code>-d</code>, enabling full-duplex. So:

<pre>
$ artsd -d -D plug:duplex
</pre>

You'll need this [[ #~/.asoundrc ]] as well.

Then you have you run TeamSpeak.bin, instead of TeamSpeak, because <code>artsdsp</code> can only handle binary. You will also need to have LD_LIBRARY_PATH set to where TeamSpeak is installed. For example, if you have TeamSpeak installed at /opt/TeamSpeak/, then you should run:

<pre>
$ LD_LIBRARY_PATH=/opt/TeamSpeak artsdsp /opt/TeamSpeak.bin
</pre>

== ~/.asoundrc ==

Usually you shouldn't need a custom ALSA configuration. But just in case, here is a simple <code>~/.asoundrc</code> to get you started:

<pre>
pcm.duplex {
type asym
playback.pcm "dmix"
capture.pcm "dsnoop"
}

pcm.!default {
type plug
slave.pcm "duplex"
}
</pre>

This is the same as specifying "<code>plug:duplex</code>" as the audio device for all applications, for instance:

<pre>
$ aplay -D plug:duplex test.wav

$ arecord -D plug:duplex test.wav

$ esd -d plug:duplex

$ artsd -d -D plug:duplex
</pre>

So with this configuration, you do not have to specify which ALSA device applications should use. As long as the application uses ALSA, it will be using the <code>dmix</code> and <code>dsnoop</code> plugins.

With FlightGear/OpenAL, however, I'm not sure what the issue is, but you may still need to specify <code>alsa-out-device</code> in the <code>~/.openalrc</code>, which is:

<pre>
(define devices '(alsa))
(define alsa-out-device "plug:duplex")
</pre>

=== Linux ALSA Audiophiles avoiding Dmix ===
For audiophiles using Linux ALSA and with their custom $HOME/.asoundrc file preventing DMix usage, make sure you have both specified "device = plug:dmix" as well as "capture = plug:dsnoop". Per ALSA's page, "dsnoop is the equivalent of the dmix plugin, but for recording sound." Without specifying using dsnoop for the capture device alongside your $HOME/.asoundrc file preventing DMix usage, you will likely only get silence played back when usage FGCom. FGCom is not working at this point, as the sound device is likely still locked by your $HOME/.asoundrc file and only recording silence or playing back silence during the echo test!

== GNOME and KDE ==

If you're using GNOME or KDE, you will probably have <code>esd</code> or <code>artsd</code> running already. In this case, you may also want to try this [[ #~/.asoundrc ]], which set <code>dmix</code> and <code>dsnoop</code> as the default to use for ALSA. You need to restart <code>esd</code> or <code>artsd</code> after making changes to <code>~/.asoundrc</code>. Make sure your <code>esd</code> or <code>artsd</code> is using ALSA, too.

(TODO: Anyone who uses GNOME or KDE could add more descriptions here, thanks)

== When things don't work ==

* Try the [[ ~/.asoundrc ]] published within this article.

* The <code>AOSS</code> (script for ALSA OSS emulation) honours your ALSA configurations, and hence your <code>~/.asoundrc</code> file. Make sure this <code>~/.asoundrc</code> file is correct, and typically ALSA aware applications will show problems via stdout. Use <code>aplay</code> and <code>arecord</code> to test your setup, as these simple applications readily display any problems with your configuration files via stdout.

* Temporarily rename or move your current <code>~/.asoundrc</code>, resorting to the default Linux ALSA configuration (using default DMix), and then test everything again. (NOTE: Some Linux distributions may further make additional adjustments to the default system ALSA configuration files.)

* See http://gentoo-wiki.com/HOWTO_ALSA_sound_mixer_aka_dmix (even if you're not using Gentoo). It's a pretty detailed HOWTO with ALSA audio including <code>dmix</code> and <code>dsnoop</code> configurations. (NOTE: This http://gentoo-wiki.com domain no longer is working, and most non-copyrighted material may have been migrated to http://wiki.gentoo.org. Unfortunately this dmix related material only now exsist within Google Cache. There are many other well documented Linux Distribution ALSA related Wiki articles.)

[[Category:FlightGear]]

Howto:Build 3rdParty library for Windows

2014-05-25T22:53:36Z

F-JJTH: Created page with "FlightGear require some 3rd party libraries, sometimes these library require to be updated, here are 2 scripts (one for x86 + one for x64) who build most of these library. You..."

FlightGear require some 3rd party libraries, sometimes these library require to be updated, here are 2 scripts (one for x86 + one for x64) who build most of these library. You just need to update the source of the library in order to update the package (and apply any required change if needed, e.g: xcopy *.h file, compilation options...)

build_3rdparty.x64.bat:
<syntaxhighlight lang="winbatch">
set "WORKSPACE=%CD%"
set "CGAL_PATH=C:\Program Files\CGAL-4.3"

md %WORKSPACE%\3rdParty.x64\bin
md %WORKSPACE%\3rdParty.x64\lib
md %WORKSPACE%\3rdParty.x64\include

call "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" amd64
GOTO SkipMe

REM ############################# Download & compile ZLIB

curl http://zlib.net/zlib128.zip -o %WORKSPACE%/zlib.zip
unzip %WORKSPACE%/zlib.zip
mv -f %WORKSPACE%/zlib-1.2.8 %WORKSPACE%/zlib-source

cd %WORKSPACE%
md zlib-build
cd zlib-build
cmake ..\zlib-source -G "Visual Studio 10 Win64" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\zlib-build\build"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\zlib-build\build\include\* %WORKSPACE%\3rdParty.x64\include /y /s /q
xcopy %WORKSPACE%\zlib-build\build\lib\zlib.lib %WORKSPACE%\3rdParty.x64\lib /y /q
xcopy %WORKSPACE%\zlib-build\build\bin\zlib.dll %WORKSPACE%\3rdParty.x64\bin /y /q
cd %WORKSPACE%

REM ############################# Download & compile LIBTIFF

curl http://download.osgeo.org/libtiff/tiff-4.0.3.zip -o %WORKSPACE%/libtiff.zip
unzip %WORKSPACE%/libtiff.zip
mv -f %WORKSPACE%/tiff-4.0.3 %WORKSPACE%/libtiff-source

cd %WORKSPACE%/libtiff-source
nmake -f makefile.vc
cd %WORKSPACE%

xcopy %WORKSPACE%\libtiff-source\libtiff\libtiff.lib %WORKSPACE%\3rdParty.x64\lib\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\libtiff_i.lib %WORKSPACE%\3rdParty.x64\lib\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\libtiff.dll %WORKSPACE%\3rdParty.x64\bin\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\tiff.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\tiffconf.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\tiffio.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\tiffvers.h %WORKSPACE%\3rdParty.x64\include\ /y /f
cd %WORKSPACE%

REM ############################# Download & compile LIBPNG

curl -L http://download.sourceforge.net/libpng/lpng1610.zip -o %WORKSPACE%/libpng.zip
unzip %WORKSPACE%/libpng.zip
mv -f %WORKSPACE%/lpng1610 %WORKSPACE%/libpng-source

cd %WORKSPACE%
md libpng-build
cd libpng-build
cmake ..\libpng-source -G "Visual Studio 10 Win64" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libpng-build\build" -DCMAKE_PREFIX_PATH:PATH="%WORKSPACE%\3rdParty.x64"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libpng-build\build\include\*.h %WORKSPACE%\3rdParty.x64\include /y
xcopy %WORKSPACE%\libpng-build\build\lib\libpng16.lib %WORKSPACE%\3rdParty.x64\lib /y
xcopy %WORKSPACE%\libpng-build\build\bin\libpng16.dll %WORKSPACE%\3rdParty.x64\bin /y
cd %WORKSPACE%

REM ############################# Download & compile LIBJPEG

curl http://www.ijg.org/files/jpegsr9a.zip -o %WORKSPACE%/libjpeg.zip
unzip %WORKSPACE%/libjpeg.zip
mv -f %WORKSPACE%/jpeg-9a %WORKSPACE%/libjpeg-source

cd %WORKSPACE%/libjpeg-source

nmake -f makefile.vc setup-v10
sed -i "s/Win32/x64/g" jpeg.sln
sed -i "s/Win32/x64/g" jpeg.vcxproj
msbuild jpeg.sln /t:Build /p:Configuration=Release;Platform=x64

xcopy %WORKSPACE%\libjpeg-source\x64\Release\jpeg.lib %WORKSPACE%\3rdParty.x64\lib /y /s /q
xcopy %WORKSPACE%\libjpeg-source\jconfig.h %WORKSPACE%\3rdParty.x64\include /y /s /q
xcopy %WORKSPACE%\libjpeg-source\jerror.h %WORKSPACE%\3rdParty.x64\include /y /s /q
xcopy %WORKSPACE%\libjpeg-source\jmorecfg.h %WORKSPACE%\3rdParty.x64\include /y /s /q
xcopy %WORKSPACE%\libjpeg-source\jpeglib.h %WORKSPACE%\3rdParty.x64\include /y /s /q
cd %WORKSPACE%

REM ############################# Download & compile LIBCURL

curl http://curl.haxx.se/download/curl-7.35.0.zip -o %WORKSPACE%/libcurl.zip
unzip %WORKSPACE%/libcurl.zip
mv -f %WORKSPACE%/curl-7.35.0 %WORKSPACE%/libcurl-source

cd %WORKSPACE%
md libcurl-build
cd libcurl-build
cmake ..\libcurl-source -G "Visual Studio 10 Win64" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libcurl-build\build" -DCMAKE_PREFIX_PATH:PATH="%WORKSPACE%\3rdParty.x64"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libcurl-build\build\include\* %WORKSPACE%\3rdParty.x64\include /y /s /q
xcopy %WORKSPACE%\libcurl-build\build\lib\libcurl_imp.lib %WORKSPACE%\3rdParty.x64\lib /y /q
xcopy %WORKSPACE%\libcurl-build\build\lib\libcurl.dll %WORKSPACE%\3rdParty.x64\bin /y /q
cd %WORKSPACE%

REM ############################# Download & compile GDAL

svn co https://svn.osgeo.org/gdal/trunk/gdal %WORKSPACE%/libgdal-source

cd %WORKSPACE%/libgdal-source
nmake -f makefile.vc MSVC_VER=1600 GDAL_HOME=%WORKSPACE%/libgdal-source BINDIR=%WORKSPACE%\3rdParty.x64\bin LIBDIR=%WORKSPACE%\3rdParty.x64\lib INCDIR=%WORKSPACE%\3rdParty.x64\include WIN64=YES
cd %WORKSPACE%

xcopy %WORKSPACE%\libgdal-source\gcore\gdal.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gcore\gdal_frmts.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gcore\gdal_proxy.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gcore\gdal_priv.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gcore\gdal_version.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\alg\gdal_alg.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\alg\gdalwarper.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\frmts\vrt\gdal_vrt.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\ogr\ogr*.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\port\cpl*.h %WORKSPACE%\3rdParty.x64\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gdal_i.lib %WORKSPACE%\3rdParty.x64\lib\ /y /f
xcopy %WORKSPACE%\libgdal-source\gdal.lib %WORKSPACE%\3rdParty.x64\lib\ /y /f
xcopy %WORKSPACE%\libgdal-source\gdal*.dll %WORKSPACE%\3rdParty.x64\bin\ /y /f
cd %WORKSPACE%

REM ############################# Download & compile LIBFLTK

curl http://fltk.org/pub/fltk/1.3.2/fltk-1.3.2-source.tar.gz -o %WORKSPACE%/libfltk.tar.gz
tar xzvf libfltk.tar.gz
mv -f %WORKSPACE%/fltk-1.3.2 %WORKSPACE%/libfltk-source

cd %WORKSPACE%
md libfltk-build
cd libfltk-build
cmake ..\libfltk-source -G "Visual Studio 10 Win64" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libfltk-build\build" -DCMAKE_PREFIX_PATH:PATH="%WORKSPACE%\3rdParty.x64"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libfltk-build\build\include\* %WORKSPACE%\3rdParty.x64\include /y /s /q
xcopy %WORKSPACE%\libfltk-build\build\bin\* %WORKSPACE%\3rdParty.x64\bin /y /s /q
xcopy %WORKSPACE%\libfltk-build\build\lib\fltk*.lib %WORKSPACE%\3rdParty.x64\lib /y /s /q
cd %WORKSPACE%

REM ############################# Download & compile LIBBOOST

curl http://flightgear.simpits.org:8080/job/Boost-Win64/lastSuccessfulBuild/artifact/*zip*/archive.zip -o %WORKSPACE%/libboost.zip
unzip libboost.zip
mv %WORKSPACE%\archive\Boost %WORKSPACE%\Boost
rmdir %WORKSPACE%\archive
cd %WORKSPACE%

REM ############################# Download & compile CGAL

curl https://gforge.inria.fr/frs/download.php/32996/CGAL-4.3.zip -o %WORKSPACE%/libcgal.zip
unzip %WORKSPACE%/libcgal.zip
mv -f %WORKSPACE%/CGAL-4.3 %WORKSPACE%/libcgal-source
:SkipMe
cd %WORKSPACE%\Boost\
mv lib64 lib
md include\boost-1_55
mv boost include\boost-1_55\boost
xcopy "%CGAL_PATH%"\auxiliary\gmp\include\* %WORKSPACE%\libcgal-source\auxiliary\gmp\include /s /y /i
xcopy "%CGAL_PATH%"\auxiliary\gmp\lib64\* %WORKSPACE%\libcgal-source\auxiliary\gmp\lib /s /y /i

cd %WORKSPACE%
md libcgal-build
cd libcgal-build
cmake ..\libcgal-source -G "Visual Studio 10 Win64" -DCMAKE_PREFIX_PATH="%WORKSPACE%\cgal-source\auxiliary\gmp;%WORKSPACE%\Boost" -DCGAL_Boost_USE_STATIC_LIBS:BOOL=ON -DZLIB_LIBRARY="%WORKSPACE%\3rdParty.x64\lib\zlib.lib" -DZLIB_INCLUDE_DIR="%WORKSPACE%\3rdParty.x64\include" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libcgal-build\build"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libcgal-build\build\include\* %WORKSPACE%\3rdParty.x64\include /y /s /q
xcopy %WORKSPACE%\libcgal-build\build\bin\*.dll %WORKSPACE%\3rdParty.x64\bin /y /s /q
xcopy %WORKSPACE%\libcgal-build\build\lib\*.lib %WORKSPACE%\3rdParty.x64\lib /y /s /q
xcopy %WORKSPACE%\libcgal-source\auxiliary\gmp\lib\*.dll %WORKSPACE%\3rdParty.x64\bin /s /y /q
xcopy %WORKSPACE%\libcgal-source\auxiliary\gmp\lib\*.lib %WORKSPACE%\3rdParty.x64\lib /s /y /q
cd %WORKSPACE%

REM ############################# Download & compile FREETYPE

curl -L http://sourceforge.net/projects/freetype/files/freetype2/2.5.3/ft253.zip/download -o %WORKSPACE%/freetype.zip
unzip freetype.zip
mv -f %WORKSPACE%/freetype-2.5.3 %WORKSPACE%/freetype-source

cd %WORKSPACE%
md freetype-build
cd freetype-build

cmake ..\freetype-source -G "Visual Studio 10 Win64" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%/freetype-build/build" -DCMAKE_PREFIX_PATH:PATH="%WORKSPACE%/3rdParty.x64"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\freetype-build\build\* %WORKSPACE%\3rdParty.x64 /y /s /q
cd %WORKSPACE%

REM ############################# Download & compile LIBPROJ

curl http://download.osgeo.org/proj/proj-4.8.0.zip -o libproj.zip
unzip libproj.zip
mv -f proj-4.8.0 libproj-source

cd %WORKSPACE%/libproj-source

nmake -f makefile.vc

xcopy %WORKSPACE%\libproj-source\src\*.lib %WORKSPACE%\3rdParty.x64\lib /s /y /q
xcopy %WORKSPACE%\libproj-source\src\*.dll %WORKSPACE%\3rdParty.x64\bin /s /y /q
xcopy %WORKSPACE%\libproj-source\src\proj_api.h %WORKSPACE%\3rdParty.x64\include /s /y /q
cd %WORKSPACE%

REM ############################# Download & compile LIBGEOS

curl http://download.osgeo.org/geos/geos-3.4.2.tar.bz2 -o %WORKSPACE%/libgeos.tar.bz2
tar xvjf libgeos.tar.bz2
mv -f geos-3.4.2 libgeos-source

cd %WORKSPACE%
md libgeos-build
cd libgeos-build
cmake ..\libgeos-source -G "Visual Studio 10 Win64" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libgeos-build\build"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libgeos-build\build\bin\geos_c.dll %WORKSPACE%\3rdParty.x64\bin /s /y /q
xcopy %WORKSPACE%\libgeos-build\build\lib\geos_c.lib %WORKSPACE%\3rdParty.x64\lib /s /y /q
xcopy %WORKSPACE%\libgeos-build\build\include\geos_c.h %WORKSPACE%\3rdParty.x64\include /s /y /q
cd %WORKSPACE%

REM ############################# Download & compile LIBEXPAT

curl -L http://sourceforge.net/projects/expat/files/expat/2.1.0/expat-2.1.0.tar.gz/download -o %WORKSPACE%/libexpat.tar.gz
tar xzvf libexpat.tar.gz
mv -f expat-2.1.0 libexpat-source

cd %WORKSPACE%
md libexpat-build
cd libexpat-build
cmake ..\libexpat-source -G "Visual Studio 10 Win64" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libexpat-build\build"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libexpat-build\build\bin\expat.dll %WORKSPACE%\3rdParty.x64\bin /s /y /q
xcopy %WORKSPACE%\libexpat-build\build\lib\expat.lib %WORKSPACE%\3rdParty.x64\lib /s /y /q
xcopy %WORKSPACE%\libexpat-build\build\include\* %WORKSPACE%\3rdParty.x64\include /s /y /q

:SkipMe
</syntaxhighlight>

build_3rdparty.bat:
<syntaxhighlight lang="winbatch">
set "WORKSPACE=%CD%"
set "CGAL_PATH=C:\Program Files\CGAL-4.3"

md %WORKSPACE%\3rdParty\bin
md %WORKSPACE%\3rdParty\lib
md %WORKSPACE%\3rdParty\include

call "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat" x86

REM GOTO SkipMe

REM ############################# Download & compile ZLIB

curl http://zlib.net/zlib128.zip -o %WORKSPACE%/zlib.zip
unzip %WORKSPACE%/zlib.zip
mv -f %WORKSPACE%/zlib-1.2.8 %WORKSPACE%/zlib-source

cd %WORKSPACE%
md zlib-build
cd zlib-build
cmake ..\zlib-source -G "Visual Studio 10" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\zlib-build\build"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\zlib-build\build\include\* %WORKSPACE%\3rdParty\include /y /s /q
xcopy %WORKSPACE%\zlib-build\build\lib\zlib.lib %WORKSPACE%\3rdParty\lib /y /q
xcopy %WORKSPACE%\zlib-build\build\bin\zlib.dll %WORKSPACE%\3rdParty\bin /y /q
cd %WORKSPACE%

REM ############################# Download & compile LIBTIFF

curl http://download.osgeo.org/libtiff/tiff-4.0.3.zip -o %WORKSPACE%/libtiff.zip
unzip %WORKSPACE%/libtiff.zip
mv -f %WORKSPACE%/tiff-4.0.3 %WORKSPACE%/libtiff-source

cd %WORKSPACE%/libtiff-source
nmake -f makefile.vc
cd %WORKSPACE%

xcopy %WORKSPACE%\libtiff-source\libtiff\libtiff.lib %WORKSPACE%\3rdParty\lib\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\libtiff_i.lib %WORKSPACE%\3rdParty\lib\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\libtiff.dll %WORKSPACE%\3rdParty\bin\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\tiff.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\tiffconf.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\tiffio.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libtiff-source\libtiff\tiffvers.h %WORKSPACE%\3rdParty\include\ /y /f
cd %WORKSPACE%

REM ############################# Download & compile LIBPNG

curl -L http://download.sourceforge.net/libpng/lpng1610.zip -o %WORKSPACE%/libpng.zip
unzip %WORKSPACE%/libpng.zip
mv -f %WORKSPACE%/lpng1610 %WORKSPACE%/libpng-source

cd %WORKSPACE%
md libpng-build
cd libpng-build
cmake ..\libpng-source -G "Visual Studio 10" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libpng-build\build" -DCMAKE_PREFIX_PATH:PATH="%WORKSPACE%\3rdParty"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libpng-build\build\include\*.h %WORKSPACE%\3rdParty\include /y
xcopy %WORKSPACE%\libpng-build\build\lib\libpng16.lib %WORKSPACE%\3rdParty\lib /y
xcopy %WORKSPACE%\libpng-build\build\bin\libpng16.dll %WORKSPACE%\3rdParty\bin /y
cd %WORKSPACE%

REM ############################# Download & compile LIBJPEG

REM curl http://www.ijg.org/files/jpegsr9a.zip -o %WORKSPACE%/libjpeg.zip
unzip %WORKSPACE%/libjpeg.zip
mv -f %WORKSPACE%/jpeg-9a %WORKSPACE%/libjpeg-source

cd %WORKSPACE%/libjpeg-source

nmake -f makefile.vc setup-v10
msbuild jpeg.sln /t:Build /p:Configuration=Release;Platform=Win32

xcopy %WORKSPACE%\libjpeg-source\Release\jpeg.lib %WORKSPACE%\3rdParty\lib /y /s /q
xcopy %WORKSPACE%\libjpeg-source\jconfig.h %WORKSPACE%\3rdParty\include /y /s /q
xcopy %WORKSPACE%\libjpeg-source\jerror.h %WORKSPACE%\3rdParty\include /y /s /q
xcopy %WORKSPACE%\libjpeg-source\jmorecfg.h %WORKSPACE%\3rdParty\include /y /s /q
xcopy %WORKSPACE%\libjpeg-source\jpeglib.h %WORKSPACE%\3rdParty\include /y /s /q
cd %WORKSPACE%

REM ############################# Download & compile LIBCURL

curl http://curl.haxx.se/download/curl-7.35.0.zip -o %WORKSPACE%/libcurl.zip
unzip %WORKSPACE%/libcurl.zip
mv -f %WORKSPACE%/curl-7.35.0 %WORKSPACE%/libcurl-source

cd %WORKSPACE%
md libcurl-build
cd libcurl-build
cmake ..\libcurl-source -G "Visual Studio 10" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libcurl-build\build" -DCMAKE_PREFIX_PATH:PATH="%WORKSPACE%\3rdParty"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libcurl-build\build\include\* %WORKSPACE%\3rdParty\include /y /s /q
xcopy %WORKSPACE%\libcurl-build\build\lib\libcurl_imp.lib %WORKSPACE%\3rdParty\lib /y /q
xcopy %WORKSPACE%\libcurl-build\build\lib\libcurl.dll %WORKSPACE%\3rdParty\bin /y /q
cd %WORKSPACE%

REM ############################# Download & compile GDAL

svn co https://svn.osgeo.org/gdal/trunk/gdal %WORKSPACE%/libgdal-source

cd %WORKSPACE%/libgdal-source
nmake -f makefile.vc MSVC_VER=1600 GDAL_HOME=%WORKSPACE%/libgdal-source BINDIR=%WORKSPACE%\3rdParty\bin LIBDIR=%WORKSPACE%\3rdParty\lib INCDIR=%WORKSPACE%\3rdParty\include
cd %WORKSPACE%

xcopy %WORKSPACE%\libgdal-source\gcore\gdal.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gcore\gdal_frmts.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gcore\gdal_proxy.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gcore\gdal_priv.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gcore\gdal_version.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\alg\gdal_alg.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\alg\gdalwarper.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\frmts\vrt\gdal_vrt.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\ogr\ogr*.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\port\cpl*.h %WORKSPACE%\3rdParty\include\ /y /f
xcopy %WORKSPACE%\libgdal-source\gdal_i.lib %WORKSPACE%\3rdParty\lib\ /y /f
xcopy %WORKSPACE%\libgdal-source\gdal.lib %WORKSPACE%\3rdParty\lib\ /y /f
xcopy %WORKSPACE%\libgdal-source\gdal*.dll %WORKSPACE%\3rdParty\bin\ /y /f
cd %WORKSPACE%

REM ############################# Download & compile LIBFLTK

curl http://fltk.org/pub/fltk/1.3.2/fltk-1.3.2-source.tar.gz -o %WORKSPACE%/libfltk.tar.gz
tar xzvf libfltk.tar.gz
mv -f %WORKSPACE%/fltk-1.3.2 %WORKSPACE%/libfltk-source

cd %WORKSPACE%
md libfltk-build
cd libfltk-build
cmake ..\libfltk-source -G "Visual Studio 10" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libfltk-build\build" -DCMAKE_PREFIX_PATH:PATH="%WORKSPACE%\3rdParty"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libfltk-build\build\include\* %WORKSPACE%\3rdParty\include /y /s /q
xcopy %WORKSPACE%\libfltk-build\build\bin\* %WORKSPACE%\3rdParty\bin /y /s /q
xcopy %WORKSPACE%\libfltk-build\build\lib\fltk*.lib %WORKSPACE%\3rdParty\lib /y /s /q
cd %WORKSPACE%

REM ############################# Download & compile LIBBOOST

curl http://flightgear.simpits.org:8080/job/Boost-Win/lastSuccessfulBuild/artifact/*zip*/archive.zip -o %WORKSPACE%/libboost.zip
unzip libboost.zip
mv %WORKSPACE%\archive\Boost %WORKSPACE%\Boost
rmdir %WORKSPACE%\archive
cd %WORKSPACE%

REM ############################# Download & compile CGAL

curl https://gforge.inria.fr/frs/download.php/32996/CGAL-4.3.zip -o %WORKSPACE%/libcgal.zip
unzip %WORKSPACE%/libcgal.zip
mv -f %WORKSPACE%/CGAL-4.3 %WORKSPACE%/libcgal-source

cd %WORKSPACE%\Boost\
md include\boost-1_55
mv boost include\boost-1_55\boost
xcopy "%CGAL_PATH%"\auxiliary\gmp\include\* %WORKSPACE%\libcgal-source\auxiliary\gmp\include /s /y /i
xcopy "%CGAL_PATH%"\auxiliary\gmp\lib32\* %WORKSPACE%\libcgal-source\auxiliary\gmp\lib /s /y /i

cd %WORKSPACE%
md libcgal-build
cd libcgal-build
cmake ..\libcgal-source -G "Visual Studio 10" -DCMAKE_PREFIX_PATH="%WORKSPACE%\cgal-source\auxiliary\gmp;%WORKSPACE%\Boost" -DCGAL_Boost_USE_STATIC_LIBS:BOOL=ON -DZLIB_LIBRARY="%WORKSPACE%\3rdParty\lib\zlib.lib" -DZLIB_INCLUDE_DIR="%WORKSPACE%\3rdParty\include" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libcgal-build\build"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libcgal-build\build\include\* %WORKSPACE%\3rdParty\include /y /s /q
xcopy %WORKSPACE%\libcgal-build\build\bin\*.dll %WORKSPACE%\3rdParty\bin /y /s /q
xcopy %WORKSPACE%\libcgal-build\build\lib\*.lib %WORKSPACE%\3rdParty\lib /y /s /q
xcopy %WORKSPACE%\libcgal-source\auxiliary\gmp\lib\*.dll %WORKSPACE%\3rdParty\bin /s /y /q
xcopy %WORKSPACE%\libcgal-source\auxiliary\gmp\lib\*.lib %WORKSPACE%\3rdParty\lib /s /y /q
cd %WORKSPACE%

REM ############################# Download & compile FREETYPE

curl -L http://sourceforge.net/projects/freetype/files/freetype2/2.5.3/ft253.zip/download -o %WORKSPACE%/freetype.zip
unzip freetype.zip
mv -f %WORKSPACE%/freetype-2.5.3 %WORKSPACE%/freetype-source

cd %WORKSPACE%
md freetype-build
cd freetype-build

cmake ..\freetype-source -G "Visual Studio 10" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%/freetype-build/build" -DCMAKE_PREFIX_PATH:PATH="%WORKSPACE%/3rdParty"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\freetype-build\build\* %WORKSPACE%\3rdParty /y /s /q
cd %WORKSPACE%

REM ############################# Download & compile LIBPROJ

curl http://download.osgeo.org/proj/proj-4.8.0.zip -o libproj.zip
unzip libproj.zip
mv -f proj-4.8.0 libproj-source

cd %WORKSPACE%/libproj-source

nmake -f makefile.vc

xcopy %WORKSPACE%\libproj-source\src\*.lib %WORKSPACE%\3rdParty\lib /s /y /q
xcopy %WORKSPACE%\libproj-source\src\*.dll %WORKSPACE%\3rdParty\bin /s /y /q
xcopy %WORKSPACE%\libproj-source\src\proj_api.h %WORKSPACE%\3rdParty\include /s /y /q
cd %WORKSPACE%

REM ############################# Download & compile LIBGEOS

curl http://download.osgeo.org/geos/geos-3.4.2.tar.bz2 -o %WORKSPACE%/libgeos.tar.bz2
tar xvjf libgeos.tar.bz2
mv -f geos-3.4.2 libgeos-source

cd %WORKSPACE%
md libgeos-build
cd libgeos-build
cmake ..\libgeos-source -G "Visual Studio 10" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libgeos-build\build"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libgeos-build\build\bin\geos_c.dll %WORKSPACE%\3rdParty\bin /s /y /q
xcopy %WORKSPACE%\libgeos-build\build\lib\geos_c.lib %WORKSPACE%\3rdParty\lib /s /y /q
xcopy %WORKSPACE%\libgeos-build\build\include\geos_c.h %WORKSPACE%\3rdParty\include /s /y /q
cd %WORKSPACE%

REM ############################# Download & compile LIBEXPAT

curl -L http://sourceforge.net/projects/expat/files/expat/2.1.0/expat-2.1.0.tar.gz/download -o %WORKSPACE%/libexpat.tar.gz
tar xzvf libexpat.tar.gz
mv -f expat-2.1.0 libexpat-source

cd %WORKSPACE%
md libexpat-build
cd libexpat-build
cmake ..\libexpat-source -G "Visual Studio 10" -DCMAKE_INSTALL_PREFIX:PATH="%WORKSPACE%\libexpat-build\build"
cmake --build . --config Release --target INSTALL

xcopy %WORKSPACE%\libexpat-build\build\bin\expat.dll %WORKSPACE%\3rdParty\bin /s /y /q
xcopy %WORKSPACE%\libexpat-build\build\lib\expat.lib %WORKSPACE%\3rdParty\lib /s /y /q
xcopy %WORKSPACE%\libexpat-build\build\include\* %WORKSPACE%\3rdParty\include /s /y /q

:SkipMe
</syntaxhighlight>

This page is mostly here for the futur guy who will replace me when I will be tired to maintain Windows stuff ;)

Scripted Compilation on Linux Debian/Ubuntu

2014-05-21T09:06:59Z

F-JJTH: /* List of compiled programs */

The following script takes care of downloading and compiling FlightGear from the git repositories with just one command execution for both 32-bit and 64-bit Debian based systems (Debian, Ubuntu). Pre-existing installed version (if any) of FlightGear are not touched at all since the script builds and installs everything under the directory in which it is launched. You can choose between building all or only specific tools and applications. For redhat-based systems (Fedora, CentOS) you may want to check out [[CentOS]].

Necessary packages are installed via the apt-get system while libraries not included in the repositories are downloaded and compiled on the fly (i.e. [[Plib]], [[Simgear]] and [[OSG]]).

For Hints on Using a RPM based distribution like CentOS, please see [[CentOS]]

Please also see [[Superbuild]].

=== Update Available - Conversion step is built in ===

[[user:F-JJTH|F-JJTH]] has published version 2.23 of the script.
The new script will not try to do as much housekeeping. It will be easier to maintain.

However, the script does use a slightly different directory structure. For example simgear/simgear has been replaced with just simgear. OpenSceneGraph becomes openscenegraph and install/fgfs becomes install/flightgear.

If you have used the script before, the script will do a quick conversion step and stop. You will need to restart the script after the conversion step. During conversion, your download of fgdata is preserved, but other sources may not be. Read the script for details. You may want to backup your flightgear build directories before running this version.

download the newest script with this command:

wget -O download_and_compile.sh https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh

The conversion will:

* move or remove source directories for compatibility
* remove the build directory
* remove the install directory except for fgdata

=== Cut to the Chase: for the impatient ===

cd <your working directory for building flightgear>
wget download_and_compile.sh https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh
chmod +x download_and_compile.sh
mkdir -p stable
mkdir -p next
cd stable
../download_and_compile.sh -s
cd ../next
../download_and_compile.sh -p n

=== Disk Space Requirements ===
As of 02/2013, this script will by at least require 24-30 gb of disk space, note that this includes the downloaded source trees and the build files, but also the fgdata checkout (which accounts approx. for 50% of the whole thing).

=== List of compiled programs ===
The script is able to download and compile:
* FlightGear (And all the data needed to use it)
* [[Fgrun]]
* [[FGo!]]
* [[FGX]]
* [[Terragear]]
* [[TerraGear_GUI]]
* [[OpenRadar]]
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]]

Note that openRTI is just another optional dependency for HLA support: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

For the time being, you should be just fine building without HLA support. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it's probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.

==== When building Next you may see build errors ====
Keeping in mind that this script compiles bleeding edge software versions, using latest debian derivered distros, it can happen that the program that was successfully compiling last week, today does not. Building the stable version should always work unless there is a problem with the script 

== Download ==
You can download the script here:
* Primary site: [https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh download_and_compile.sh]
* Mirror: [http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh download_and_compile.sh] (not recently updated)

*The script is maintained in the FlightGear main repository. Remember to update this script whenever a new FlightGear version is released, so that you'll be able to download the latest stable revision.

There is also another option for building FlightGear and all its dependencies in an automated fashion, please refer to: http://geoffmclane.com/fg/fgfs-052.htm

== Known Pitfalls ==
FlightGear versions <= 3.0 are known to have a cmake build system issue related to NOT automatically reconfiguring the SG/FG sources after updating the version files in in $SG_SRC and $FG_SRC, which basically means that using "git pull" to update your source trees (via the d&c script) will create the latest binaries, but they may not be looking for the right base package data, because the source trees are still using the old version files found in the cmake cache. This has been encountered by various contributors, including at least one core developer.

To work around this issue, simply switch to your SG/FG build directories and reconfigure each tree by running "cmake ." - for further info, see [http://forum.flightgear.org/viewtopic.php?f=22&t=20304#p186647][http://forum.flightgear.org/viewtopic.php?f=22&p=187413#p186942].

This should probably be removed. Stable is 3.0.

== Instructions ==
To run download_and_compile.sh, just save it in a directory called for example: ~/fgfs
then execute it (no need to execute it as root).

Here is for example a sequence of commands to get the script from the master branch. You can replace master with next to get a later version of the script if one is available:
<pre>
mkdir ~/fgfs
cd ~/fgfs
wget http://www.gitorious.org/fg/fgmeta/raw/download_and_compile.sh
chmod 755 download_and_compile.sh
</pre>

You have two options now: build the latest ''stable'' FlightGear release or build the ''current development'' version (bleeding edge).
After building stable or the latest, if you need to build a different version, try the instructions for [[Avoiding Multiple Downloads of fgdata]].
=== Build the latest stable FlightGear release ===
When executing the script, use the "-s" option to build the latest stable release:
<pre>
./download_and_compile.sh -s
</pre>

=== Build the current FlightGear development version ===
When executing the script without any options,
the latest development version is built.

'''Warning''': The development version of Flightgear changes on an almost daily basis. It provides the latest features, but is not always guaranteed to work reliably. If you're unfamiliar with software testing, you may prefer to use the latest stable release.

<pre>
./download_and_compile.sh
</pre>

Once the script is finished, you will successfully get Flightgear and Fgrun installed in the ~/fgfs directory.

=== Launching FlightGear ===
When using brisa's script, the two FG dependencies/libs are usually not installed system-wide, but in a custom location (that makes it possible, to easily use different OSG/SG/FG versions on a single system, i.e. for testing purposes - but also to have separate build trees (optimized/debug) ) - which is why you either need to set LD_LIBRARY_PATH or simply use Brisa's script to run everything (something like run_fgfs.sh, which automatically sets up all environment variables according to your build settings).

To run your new git installation of FlightGear you have to launch the ''run_fgfs.sh'' command under the same folder, for example:
<pre>
cd ~/fgfs
sh run_fgfs.sh
</pre>

=== Launching Fgrun ===
[[File:fgrun-page2.jpg|thumb|right]]
For many users it's more comfortable having FlightGear launched by the graphical utility Fgrun which is installed as well in the same folder. You have to launch the ''run_fgrun.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgrun.sh
</pre>

fgrun will save its settings in ~/.fltk/flightgear.org/fgrun.prefs you may want to save copies of the preferences customized for stable and next.

=== Launching Fgo! ===
[[File:Fgo01.jpg|thumb|left]]
This is a graphical utility written in [[python]], You have to launch the ''run_fgo.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgo.sh
</pre>
Remember that the first time you run it, you have to go to preferences and set the binary and fgdata path (Do no set the working directory, you don't need it).

== Additional programs ==
If you wish to get all the other programs, you need to launch the script adding the "ALL" option to the command line:
<pre>
./download_and_compile.sh ALL
</pre>
This, will also install FGCOM, FGComGui and Atlas

=== Launching FGCOM ===
FGCOM is the system used by FlightGear to simulate radio communications between users. Launch it using the ''run_fgcom.sh'' command:
<pre>
cd ~/fgfs
sh run_fgcom.sh
</pre>

=== Launching Terrasync ===
Your FlightGear compilation comes with the Terrasync program too, so if you want to use it:
<pre>
cd ~/fgfs
sh run_terrasync.sh -S -p 5500 -d /folder/with/sceneries
</pre>
Where: ''/folder/with/sceneries'' is the folder containing the sceneries data.

Then launch fgfs with the '''--fg-scenery=/folder/with/sceneries --atlas=socket,out,5,localhost,5500,udp''' option

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only fgrun, fgcom or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

== Options ==
The script by default (without any option) will only compile FlightGear and Fgrun. To make it compile all, you need to launch the script with the ''ALL'' parameter. i.e.:
<pre>
./download_and_compile.sh ALL
</pre>

=== Compiling only one program ===
If you wish to recompile only one of the programs you can launch the script with one of the following parameters:
* PLIB (to compile and install only plib)
* OSG (to compile and install only OpenSceneGraph)
* SIMGEAR (to compile and install only Simgear)
* FGFS (to compile and install only FlightGear)
* DATA (to download / update only data files for FlightGear)
* FGRUN (to compile and install only Fgrun)
* TERRAGEAR (to compile and install only terragear!)
* TERRAGEARGUI (to compile and install only terrageargui!)
* OPENRADAR (to compile and install only OpenRadar!)
* FGO (to compile and install only Fgo!)

=== Fast updating ===
There is a second parameter ''UPDATE'' that allows you to just update your installation. i.e.:
This will only update FGFS
<pre>
./download_and_compile.sh FGFS UPDATE
</pre>

=== Compiling last stable versions (Experimental) ===
Even if the script fetches data and sources from bleeding edge developers repositories (which sometimes do not compile), you can still force the script to download latest known versions of the software that were compiling successfully by adding the -s option.
<pre>
./download_and_compile.sh -s
</pre>

How does it work? Inside the script there is a small list with latest known versions of successfully compiling revisions, it will download from svn/git those specific revisions, which have been found able to compile together. 
Warning: If you run this option inside a folder where you previously compiled fgfs, it will probably fail to compile, you better run the script with this option inside an empty folder or a folder whith the same fgfs version compiled previously.

=== Advanced options ===
* Skip download of packages using '''-p n''' option
* Skip compilation of programs using '''-c n''' option
* Skip retrieving software updates using '''-d n''' option
* Skip reconfigure (make clean) using '''-r n''' option

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear do this:
<pre>
./download_and_compile.sh -p n -d n -r n FGFS
</pre>

this will only recompile modifications and reinstall them.

=== Multicore Acceleration ===
Using the option '''-j x''' (where x is the number of your CPU-Cores you wish to assign to the job) will speed up the whole compilation process considerably.

== Disk usage ==
Having both compiled program, source code, and data from git requires some hard disk space: It will take something like 13 GB of space.
If you don't have a fast machine, it will require several hours of compilation time.

== Optimus technology ==
If your computer has a GPU with optimus technology, you need a dedicated script in order to make FG running with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FG installation directory (where you executed ./download_and_compile.sh) :
<pre>
sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
</pre>
Now you can run FG with ./run_fgfs_optirun.sh

== Remove warning message for DDS files ==
You can remove the warning message displayed when DDS files are parsed by SimGear by adding the following line just after '''cd "simgear"''' line :
<pre>
sed -i s/SG_ALERT,\ \"Image/SG_WARN,\ \"Image/g simgear/scene/model/ModelRegistry.cxx
</pre>

[[Category:Building from source]]

[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Scripted Compilation on Linux Debian/Ubuntu

2014-05-21T09:05:07Z

F-JJTH: /* Update Available - Conversion step is built in */

The following script takes care of downloading and compiling FlightGear from the git repositories with just one command execution for both 32-bit and 64-bit Debian based systems (Debian, Ubuntu). Pre-existing installed version (if any) of FlightGear are not touched at all since the script builds and installs everything under the directory in which it is launched. You can choose between building all or only specific tools and applications. For redhat-based systems (Fedora, CentOS) you may want to check out [[CentOS]].

Necessary packages are installed via the apt-get system while libraries not included in the repositories are downloaded and compiled on the fly (i.e. [[Plib]], [[Simgear]] and [[OSG]]).

For Hints on Using a RPM based distribution like CentOS, please see [[CentOS]]

Please also see [[Superbuild]].

=== Update Available - Conversion step is built in ===

[[user:F-JJTH|F-JJTH]] has published version 2.23 of the script.
The new script will not try to do as much housekeeping. It will be easier to maintain.

However, the script does use a slightly different directory structure. For example simgear/simgear has been replaced with just simgear. OpenSceneGraph becomes openscenegraph and install/fgfs becomes install/flightgear.

If you have used the script before, the script will do a quick conversion step and stop. You will need to restart the script after the conversion step. During conversion, your download of fgdata is preserved, but other sources may not be. Read the script for details. You may want to backup your flightgear build directories before running this version.

download the newest script with this command:

wget -O download_and_compile.sh https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh

The conversion will:

* move or remove source directories for compatibility
* remove the build directory
* remove the install directory except for fgdata

=== Cut to the Chase: for the impatient ===

cd <your working directory for building flightgear>
wget download_and_compile.sh https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh
chmod +x download_and_compile.sh
mkdir -p stable
mkdir -p next
cd stable
../download_and_compile.sh -s
cd ../next
../download_and_compile.sh -p n

=== Disk Space Requirements ===
As of 02/2013, this script will by at least require 24-30 gb of disk space, note that this includes the downloaded source trees and the build files, but also the fgdata checkout (which accounts approx. for 50% of the whole thing).

=== List of compiled programs ===
The script is able to download and compile:
* FlightGear (And all the data needed to use it)
* [[Fgrun]]
* [[FGo!]]
* [[FGX]]
* [[Terragear]]
* [[TerragearGUI]]
* [[OpenRadar]]
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]]

Note that openRTI is just another optional dependency for HLA support: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

For the time being, you should be just fine building without HLA support. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it's probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.

==== When building Next you may see build errors ====
Keeping in mind that this script compiles bleeding edge software versions, using latest debian derivered distros, it can happen that the program that was successfully compiling last week, today does not. Building the stable version should always work unless there is a problem with the script 

== Download ==
You can download the script here:
* Primary site: [https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh download_and_compile.sh]
* Mirror: [http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh download_and_compile.sh] (not recently updated)

*The script is maintained in the FlightGear main repository. Remember to update this script whenever a new FlightGear version is released, so that you'll be able to download the latest stable revision.

There is also another option for building FlightGear and all its dependencies in an automated fashion, please refer to: http://geoffmclane.com/fg/fgfs-052.htm

== Known Pitfalls ==
FlightGear versions <= 3.0 are known to have a cmake build system issue related to NOT automatically reconfiguring the SG/FG sources after updating the version files in in $SG_SRC and $FG_SRC, which basically means that using "git pull" to update your source trees (via the d&c script) will create the latest binaries, but they may not be looking for the right base package data, because the source trees are still using the old version files found in the cmake cache. This has been encountered by various contributors, including at least one core developer.

To work around this issue, simply switch to your SG/FG build directories and reconfigure each tree by running "cmake ." - for further info, see [http://forum.flightgear.org/viewtopic.php?f=22&t=20304#p186647][http://forum.flightgear.org/viewtopic.php?f=22&p=187413#p186942].

This should probably be removed. Stable is 3.0.

== Instructions ==
To run download_and_compile.sh, just save it in a directory called for example: ~/fgfs
then execute it (no need to execute it as root).

Here is for example a sequence of commands to get the script from the master branch. You can replace master with next to get a later version of the script if one is available:
<pre>
mkdir ~/fgfs
cd ~/fgfs
wget http://www.gitorious.org/fg/fgmeta/raw/download_and_compile.sh
chmod 755 download_and_compile.sh
</pre>

You have two options now: build the latest ''stable'' FlightGear release or build the ''current development'' version (bleeding edge).
After building stable or the latest, if you need to build a different version, try the instructions for [[Avoiding Multiple Downloads of fgdata]].
=== Build the latest stable FlightGear release ===
When executing the script, use the "-s" option to build the latest stable release:
<pre>
./download_and_compile.sh -s
</pre>

=== Build the current FlightGear development version ===
When executing the script without any options,
the latest development version is built.

'''Warning''': The development version of Flightgear changes on an almost daily basis. It provides the latest features, but is not always guaranteed to work reliably. If you're unfamiliar with software testing, you may prefer to use the latest stable release.

<pre>
./download_and_compile.sh
</pre>

Once the script is finished, you will successfully get Flightgear and Fgrun installed in the ~/fgfs directory.

=== Launching FlightGear ===
When using brisa's script, the two FG dependencies/libs are usually not installed system-wide, but in a custom location (that makes it possible, to easily use different OSG/SG/FG versions on a single system, i.e. for testing purposes - but also to have separate build trees (optimized/debug) ) - which is why you either need to set LD_LIBRARY_PATH or simply use Brisa's script to run everything (something like run_fgfs.sh, which automatically sets up all environment variables according to your build settings).

To run your new git installation of FlightGear you have to launch the ''run_fgfs.sh'' command under the same folder, for example:
<pre>
cd ~/fgfs
sh run_fgfs.sh
</pre>

=== Launching Fgrun ===
[[File:fgrun-page2.jpg|thumb|right]]
For many users it's more comfortable having FlightGear launched by the graphical utility Fgrun which is installed as well in the same folder. You have to launch the ''run_fgrun.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgrun.sh
</pre>

fgrun will save its settings in ~/.fltk/flightgear.org/fgrun.prefs you may want to save copies of the preferences customized for stable and next.

=== Launching Fgo! ===
[[File:Fgo01.jpg|thumb|left]]
This is a graphical utility written in [[python]], You have to launch the ''run_fgo.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgo.sh
</pre>
Remember that the first time you run it, you have to go to preferences and set the binary and fgdata path (Do no set the working directory, you don't need it).

== Additional programs ==
If you wish to get all the other programs, you need to launch the script adding the "ALL" option to the command line:
<pre>
./download_and_compile.sh ALL
</pre>
This, will also install FGCOM, FGComGui and Atlas

=== Launching FGCOM ===
FGCOM is the system used by FlightGear to simulate radio communications between users. Launch it using the ''run_fgcom.sh'' command:
<pre>
cd ~/fgfs
sh run_fgcom.sh
</pre>

=== Launching Terrasync ===
Your FlightGear compilation comes with the Terrasync program too, so if you want to use it:
<pre>
cd ~/fgfs
sh run_terrasync.sh -S -p 5500 -d /folder/with/sceneries
</pre>
Where: ''/folder/with/sceneries'' is the folder containing the sceneries data.

Then launch fgfs with the '''--fg-scenery=/folder/with/sceneries --atlas=socket,out,5,localhost,5500,udp''' option

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only fgrun, fgcom or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

== Options ==
The script by default (without any option) will only compile FlightGear and Fgrun. To make it compile all, you need to launch the script with the ''ALL'' parameter. i.e.:
<pre>
./download_and_compile.sh ALL
</pre>

=== Compiling only one program ===
If you wish to recompile only one of the programs you can launch the script with one of the following parameters:
* PLIB (to compile and install only plib)
* OSG (to compile and install only OpenSceneGraph)
* SIMGEAR (to compile and install only Simgear)
* FGFS (to compile and install only FlightGear)
* DATA (to download / update only data files for FlightGear)
* FGRUN (to compile and install only Fgrun)
* TERRAGEAR (to compile and install only terragear!)
* TERRAGEARGUI (to compile and install only terrageargui!)
* OPENRADAR (to compile and install only OpenRadar!)
* FGO (to compile and install only Fgo!)

=== Fast updating ===
There is a second parameter ''UPDATE'' that allows you to just update your installation. i.e.:
This will only update FGFS
<pre>
./download_and_compile.sh FGFS UPDATE
</pre>

=== Compiling last stable versions (Experimental) ===
Even if the script fetches data and sources from bleeding edge developers repositories (which sometimes do not compile), you can still force the script to download latest known versions of the software that were compiling successfully by adding the -s option.
<pre>
./download_and_compile.sh -s
</pre>

How does it work? Inside the script there is a small list with latest known versions of successfully compiling revisions, it will download from svn/git those specific revisions, which have been found able to compile together. 
Warning: If you run this option inside a folder where you previously compiled fgfs, it will probably fail to compile, you better run the script with this option inside an empty folder or a folder whith the same fgfs version compiled previously.

=== Advanced options ===
* Skip download of packages using '''-p n''' option
* Skip compilation of programs using '''-c n''' option
* Skip retrieving software updates using '''-d n''' option
* Skip reconfigure (make clean) using '''-r n''' option

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear do this:
<pre>
./download_and_compile.sh -p n -d n -r n FGFS
</pre>

this will only recompile modifications and reinstall them.

=== Multicore Acceleration ===
Using the option '''-j x''' (where x is the number of your CPU-Cores you wish to assign to the job) will speed up the whole compilation process considerably.

== Disk usage ==
Having both compiled program, source code, and data from git requires some hard disk space: It will take something like 13 GB of space.
If you don't have a fast machine, it will require several hours of compilation time.

== Optimus technology ==
If your computer has a GPU with optimus technology, you need a dedicated script in order to make FG running with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FG installation directory (where you executed ./download_and_compile.sh) :
<pre>
sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
</pre>
Now you can run FG with ./run_fgfs_optirun.sh

== Remove warning message for DDS files ==
You can remove the warning message displayed when DDS files are parsed by SimGear by adding the following line just after '''cd "simgear"''' line :
<pre>
sed -i s/SG_ALERT,\ \"Image/SG_WARN,\ \"Image/g simgear/scene/model/ModelRegistry.cxx
</pre>

[[Category:Building from source]]

[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Scripted Compilation on Linux Debian/Ubuntu

2014-05-21T08:59:34Z

F-JJTH: /* Update Available - Conversion step is built in */

The following script takes care of downloading and compiling FlightGear from the git repositories with just one command execution for both 32-bit and 64-bit Debian based systems (Debian, Ubuntu). Pre-existing installed version (if any) of FlightGear are not touched at all since the script builds and installs everything under the directory in which it is launched. You can choose between building all or only specific tools and applications. For redhat-based systems (Fedora, CentOS) you may want to check out [[CentOS]].

Necessary packages are installed via the apt-get system while libraries not included in the repositories are downloaded and compiled on the fly (i.e. [[Plib]], [[Simgear]] and [[OSG]]).

For Hints on Using a RPM based distribution like CentOS, please see [[CentOS]]

Please also see [[Superbuild]].

=== Update Available - Conversion step is built in ===

[[user:F-JJTH|F-JJTH]] has published version 2.23 of the script.
The new script will not try to do as much housekeeping. It will be easier to maintain.

However, the script does use a slightly different directory structure. For example simgear/simgear has been replaced with just simgear. OpenSceneGraph becomes openscenegraph and install/fgfs becomes install/flightgear.

If you have used the script before, the script will do a quick conversion step and stop. You will need to restart the script after the conversion step. During conversion, your download of fgdata is preserved, but other sources may not be. Read the script for details. You may want to backup your flightgear build directories before running this version.

download the newest script with this command:

wget -O download_and_compile.sh https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh

The conversion will:

* move or remove source directories for compatibility
* remove the build directory
* remove the install directory except for fgdata

You will have to restart the script after the conversion.

=== Cut to the Chase: for the impatient ===

cd <your working directory for building flightgear>
wget download_and_compile.sh https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh
chmod +x download_and_compile.sh
mkdir -p stable
mkdir -p next
cd stable
../download_and_compile.sh -s
cd ../next
../download_and_compile.sh -p n

=== Disk Space Requirements ===
As of 02/2013, this script will by at least require 24-30 gb of disk space, note that this includes the downloaded source trees and the build files, but also the fgdata checkout (which accounts approx. for 50% of the whole thing).

=== List of compiled programs ===
The script is able to download and compile:
* FlightGear (And all the data needed to use it)
* [[Fgrun]]
* [[FGo!]]
* [[FGX]]
* [[Terragear]]
* [[TerragearGUI]]
* [[OpenRadar]]
* [[FlightGear HLA support (High Level Architecture) | OpenRTI]]

Note that openRTI is just another optional dependency for HLA support: http://wiki.flightgear.org/FlightGear_HLA_support_(High_Level_Architecture)

For the time being, you should be just fine building without HLA support. Eventually, the idea is for HLA to replace the existing MP system and even increasingly distribute the FlightGear architecture such that more and more components can be more easily run in separate threads or even separate processes, possibly even on different machines. So this is going to be an important feature for professional users, using several computers and screens to create a comprehensive and immersive simulation environment.

At the moment, it's probably safe to say that HLA is only of interest to developers and people willing to play with experimental features.

==== When building Next you may see build errors ====
Keeping in mind that this script compiles bleeding edge software versions, using latest debian derivered distros, it can happen that the program that was successfully compiling last week, today does not. Building the stable version should always work unless there is a problem with the script 

== Download ==
You can download the script here:
* Primary site: [https://www.gitorious.org/fg/fgmeta/raw/next:download_and_compile.sh download_and_compile.sh]
* Mirror: [http://assistenza.larasrl.net/brisa/fgfs/download_and_compile.sh download_and_compile.sh] (not recently updated)

*The script is maintained in the FlightGear main repository. Remember to update this script whenever a new FlightGear version is released, so that you'll be able to download the latest stable revision.

There is also another option for building FlightGear and all its dependencies in an automated fashion, please refer to: http://geoffmclane.com/fg/fgfs-052.htm

== Known Pitfalls ==
FlightGear versions <= 3.0 are known to have a cmake build system issue related to NOT automatically reconfiguring the SG/FG sources after updating the version files in in $SG_SRC and $FG_SRC, which basically means that using "git pull" to update your source trees (via the d&c script) will create the latest binaries, but they may not be looking for the right base package data, because the source trees are still using the old version files found in the cmake cache. This has been encountered by various contributors, including at least one core developer.

To work around this issue, simply switch to your SG/FG build directories and reconfigure each tree by running "cmake ." - for further info, see [http://forum.flightgear.org/viewtopic.php?f=22&t=20304#p186647][http://forum.flightgear.org/viewtopic.php?f=22&p=187413#p186942].

This should probably be removed. Stable is 3.0.

== Instructions ==
To run download_and_compile.sh, just save it in a directory called for example: ~/fgfs
then execute it (no need to execute it as root).

Here is for example a sequence of commands to get the script from the master branch. You can replace master with next to get a later version of the script if one is available:
<pre>
mkdir ~/fgfs
cd ~/fgfs
wget http://www.gitorious.org/fg/fgmeta/raw/download_and_compile.sh
chmod 755 download_and_compile.sh
</pre>

You have two options now: build the latest ''stable'' FlightGear release or build the ''current development'' version (bleeding edge).
After building stable or the latest, if you need to build a different version, try the instructions for [[Avoiding Multiple Downloads of fgdata]].
=== Build the latest stable FlightGear release ===
When executing the script, use the "-s" option to build the latest stable release:
<pre>
./download_and_compile.sh -s
</pre>

=== Build the current FlightGear development version ===
When executing the script without any options,
the latest development version is built.

'''Warning''': The development version of Flightgear changes on an almost daily basis. It provides the latest features, but is not always guaranteed to work reliably. If you're unfamiliar with software testing, you may prefer to use the latest stable release.

<pre>
./download_and_compile.sh
</pre>

Once the script is finished, you will successfully get Flightgear and Fgrun installed in the ~/fgfs directory.

=== Launching FlightGear ===
When using brisa's script, the two FG dependencies/libs are usually not installed system-wide, but in a custom location (that makes it possible, to easily use different OSG/SG/FG versions on a single system, i.e. for testing purposes - but also to have separate build trees (optimized/debug) ) - which is why you either need to set LD_LIBRARY_PATH or simply use Brisa's script to run everything (something like run_fgfs.sh, which automatically sets up all environment variables according to your build settings).

To run your new git installation of FlightGear you have to launch the ''run_fgfs.sh'' command under the same folder, for example:
<pre>
cd ~/fgfs
sh run_fgfs.sh
</pre>

=== Launching Fgrun ===
[[File:fgrun-page2.jpg|thumb|right]]
For many users it's more comfortable having FlightGear launched by the graphical utility Fgrun which is installed as well in the same folder. You have to launch the ''run_fgrun.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgrun.sh
</pre>

fgrun will save its settings in ~/.fltk/flightgear.org/fgrun.prefs you may want to save copies of the preferences customized for stable and next.

=== Launching Fgo! ===
[[File:Fgo01.jpg|thumb|left]]
This is a graphical utility written in [[python]], You have to launch the ''run_fgo.sh'' command, for example:
<pre>
cd ~/fgfs
sh run_fgo.sh
</pre>
Remember that the first time you run it, you have to go to preferences and set the binary and fgdata path (Do no set the working directory, you don't need it).

== Additional programs ==
If you wish to get all the other programs, you need to launch the script adding the "ALL" option to the command line:
<pre>
./download_and_compile.sh ALL
</pre>
This, will also install FGCOM, FGComGui and Atlas

=== Launching FGCOM ===
FGCOM is the system used by FlightGear to simulate radio communications between users. Launch it using the ''run_fgcom.sh'' command:
<pre>
cd ~/fgfs
sh run_fgcom.sh
</pre>

=== Launching Terrasync ===
Your FlightGear compilation comes with the Terrasync program too, so if you want to use it:
<pre>
cd ~/fgfs
sh run_terrasync.sh -S -p 5500 -d /folder/with/sceneries
</pre>
Where: ''/folder/with/sceneries'' is the folder containing the sceneries data.

Then launch fgfs with the '''--fg-scenery=/folder/with/sceneries --atlas=socket,out,5,localhost,5500,udp''' option

== Troubleshooting ==

=== Compilation errors ===
Here we are, no fear, if you wish to use programs from the cvs/svn/git repositories, you might face compilation errors that will prevent you to have a working copy of one or more of the programs provided by this script. What can be the causes that prevent us from successfully compiling? As far as I know those:
# Software developers introduce a new functionality with a new piece of code that prevents the compilation under your architecture, this can happen working with cvs/svn/git sources.
# The program refuses to compile because of a divergence in the libraries on which it depends. For example FlightGear might not compile because OSG has been modified, while OSG itself compiles fine, FG won't.
# One or more repositories are down and you can't get the library you need. (Both from cvs/svn/git or apt-get)

There is a simple solution to the above errors: wait and relaunch the script after some time (hours or days), if software developers repair or synchronize their code with the newly updated libraries (which generally happens eventually), your FlightGear will compile fine as if the previous error never took place.

Sometimes it happens that the script fails to compile only fgrun, fgcom or atlas, if you then see the run_fgfs.sh file it means that FlightGear installation was successful and you can safely run it.

== Options ==
The script by default (without any option) will only compile FlightGear and Fgrun. To make it compile all, you need to launch the script with the ''ALL'' parameter. i.e.:
<pre>
./download_and_compile.sh ALL
</pre>

=== Compiling only one program ===
If you wish to recompile only one of the programs you can launch the script with one of the following parameters:
* PLIB (to compile and install only plib)
* OSG (to compile and install only OpenSceneGraph)
* SIMGEAR (to compile and install only Simgear)
* FGFS (to compile and install only FlightGear)
* DATA (to download / update only data files for FlightGear)
* FGRUN (to compile and install only Fgrun)
* TERRAGEAR (to compile and install only terragear!)
* TERRAGEARGUI (to compile and install only terrageargui!)
* OPENRADAR (to compile and install only OpenRadar!)
* FGO (to compile and install only Fgo!)

=== Fast updating ===
There is a second parameter ''UPDATE'' that allows you to just update your installation. i.e.:
This will only update FGFS
<pre>
./download_and_compile.sh FGFS UPDATE
</pre>

=== Compiling last stable versions (Experimental) ===
Even if the script fetches data and sources from bleeding edge developers repositories (which sometimes do not compile), you can still force the script to download latest known versions of the software that were compiling successfully by adding the -s option.
<pre>
./download_and_compile.sh -s
</pre>

How does it work? Inside the script there is a small list with latest known versions of successfully compiling revisions, it will download from svn/git those specific revisions, which have been found able to compile together. 
Warning: If you run this option inside a folder where you previously compiled fgfs, it will probably fail to compile, you better run the script with this option inside an empty folder or a folder whith the same fgfs version compiled previously.

=== Advanced options ===
* Skip download of packages using '''-p n''' option
* Skip compilation of programs using '''-c n''' option
* Skip retrieving software updates using '''-d n''' option
* Skip reconfigure (make clean) using '''-r n''' option

For example, if you are a developer and wish to quickly recompile and reinstall only your own modifications for FlightGear do this:
<pre>
./download_and_compile.sh -p n -d n -r n FGFS
</pre>

this will only recompile modifications and reinstall them.

=== Multicore Acceleration ===
Using the option '''-j x''' (where x is the number of your CPU-Cores you wish to assign to the job) will speed up the whole compilation process considerably.

== Disk usage ==
Having both compiled program, source code, and data from git requires some hard disk space: It will take something like 13 GB of space.
If you don't have a fast machine, it will require several hours of compilation time.

== Optimus technology ==
If your computer has a GPU with optimus technology, you need a dedicated script in order to make FG running with the powerful GPU.

After having installed required tools (Bumblebee) you just need to run this command line in your FG installation directory (where you executed ./download_and_compile.sh) :
<pre>
sed 's|\./fgfs|optirun ./fgfs|' run_fgfs.sh > run_fgfs_optirun.sh && chmod +x run_fgfs_optirun.sh
</pre>
Now you can run FG with ./run_fgfs_optirun.sh

== Remove warning message for DDS files ==
You can remove the warning message displayed when DDS files are parsed by SimGear by adding the following line just after '''cd "simgear"''' line :
<pre>
sed -i s/SG_ALERT,\ \"Image/SG_WARN,\ \"Image/g simgear/scene/model/ModelRegistry.cxx
</pre>

[[Category:Building from source]]

[[nl:Compileren met een Script op Linux Debian/Ubuntu]]

Changelog 3.2

2014-05-08T13:13:30Z

F-JJTH: /* Major enhancements in this release */

{{draft|changelog|This changelog is currently being written for the FlightGear 3.2 release. To see what is being worked on, check out [[Changelog 3.2]].
Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog. It's a good idea to check [[:Category:Changes_after_3.00|the newsletters since the last release]], and the git commit history.
To view the changelog for the most recent release, please see [[Changelog 3.0]].
We also encourage people to help by translating the changelog and appreciate all contributions, however please keep in mind that this changelog is not yet final!

}}

==Upcoming FlightGear Changelog==



=== Major enhancements in this release ===

'''Surface Light Effects & OpenSceneGraph 3.2'''

Stuart committed a change that brings surface lights, including VASI/PAPI/taxi/runway etc. into the xml-defined Effects framework. Kudos to Tim Moore for his original Effects work - it made it very straightforward to enhance with support for point sprites and a custom texture generator required.

The relevant effect is data/Effects/surface-lights.eff. It should allow development of ALS and Rembrandt variants.

Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow. So, if your
build fails, please check you've got a recent OSG build installed.

'''Core'''
* [[Reset & re-init]] is merged and now enabled
* A segfault related to scripted Nasal fgcommands (like used in joystick and other bindings) has been fixed {{Issue|1397}}
* yasim versioning support for maintenance fixes (TorstenD)
* FLITE TTS support
* Windows dependencies have been updated

'''Aircraft Modeling'''
* galvedro's work: [[A Failure Management Framework for FlightGear]]
* extra 500
* Tu-154B2 version 3.1
* additional aircraft have started adopting Gijs' [[NavDisplay]]

'''JSBSim'''
* ground effects (see newsletter 02/2014)

'''Environment Rendering'''
* EarthView: Orbital Rendering (Thorsten) [http://sourceforge.net/p/flightgear/mailman/message/32262904/]

'''Performance'''
* F-JJTH and Stuart have started working on using osg::Simplifier [https://gitorious.org/fg/simgear/commit/3429e0072103a8c90d8e456f1f6b711099851225]: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAP3ntysifK34TxANKUj1s4Of_dJRg7dvJ74Gbko4zXVFHdV-YQ%40mail.gmail.com/#msg32016452

'''Misc/Uncategorized'''
* AIModels use PagedLOD
* Optimise NavCache airport query
* osg::Switch for masking scenery rendering
* Torsten's metar work, newradio, mongoose httpd
* HTTP: improve handling of connection errors
* [[FGCamera]] (external addon, not yet reviewed/committed as of 03/2014)
* Windows installer has been reworked
* Windows installer creates 3 news directories pre-configured in FGRun:
** {user}\Documents\FlightGear\Aircraft
** {user}\Documents\FlightGear\TerraSync
** {user}\Documents\FlightGear\Custom Scenery

''' Usability '''
* Windows users are now able to use scrollwheel in dialog

''' Internationalization '''

''' Scenery '''

'''Canvas System'''

FlightGear's fully scriptable 2D rendering system now includes improved APIs for creating maps and navigation displays amongst many other improvements. People no longer need to have programming experience to add a working ND to their aircraft, it can now be all done by copying and pasting 30 lines of text and customizing a few properties. The so called MapStructure back-end handles efficient updating of all ND layers transparently.

* Tom has pushed an update to git (simgear) which removes a lot of unneeded OpenGL state changes for Canvas paths. Depending on the GPU/driver this can lead to quite a noticeable performance improvement. For example, he was able to get from ~120ms down to ~45ms [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].
* Hooray is working on adding shader support to Canvas {{Progressbar|30}}
* Gijs is currently working on additional projections as part of {{Issue|550}}
* The [[MapStructure]] back-end used by the [[NavDisplay]] now supports symbol instancing, so that performance is improved
* MapStructure-based layers can now be customized and styled
* Tom added support for button/modifiers (mouse handling) [http://wiki.flightgear.org/index.php?title=Canvas_Event_Handling&curid=10777&diff=68569&oldid=68422]
* CanvasImage now supports the ''http://'' protocol for dynamically retrieving raster images. See the renamed [[Canvas_Image#src|src attribute]] (''file'' is now deprecated).
* As part of the ongoing effort on [[Unifying the 2D rendering backend via canvas]], we have started re-implementing the integrated [[Map]] dialog using Nasal & Canvas instead of C++ {{Progressbar|30}}

'''Nasal Scripting'''

* getprop()/setprop() arguments (those that form a path) can now be numeric to specify a index, so:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index", "texture", 1, "name");
</syntaxhighlight>
: is now the same as:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index/texture[1]/name");
</syntaxhighlight>
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request 54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])
* A new fully-interactive Nasal GUI console based on [[Canvas]] has been added: [[Interactive Nasal Console]]

'''Documentation'''

'''Highlighted new and improved aircraft'''

'''Other'''

'''Bug fixes'''

* See [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=Milestone%3D3.2 our bugtracker] for an extensive, yet incomplete, list of the bugs fixed in this release.

[[Category:FlightGear changelogs]]

Changelog 3.2

2014-05-01T09:17:02Z

F-JJTH: /* Major enhancements in this release */

{{draft|changelog|This changelog is currently being written for the FlightGear 3.2 release. To see what is being worked on, check out [[Changelog 3.2]].
Feel free to help! If you are aware of any FlightGear related changes, please add them to the changelog. It's a good idea to check [[:Category:Changes_after_3.00|the newsletters since the last release]], and the git commit history.
To view the changelog for the most recent release, please see [[Changelog 3.0]].
We also encourage people to help by translating the changelog and appreciate all contributions, however please keep in mind that this changelog is not yet final!

}}

==Upcoming FlightGear Changelog==



=== Major enhancements in this release ===

'''Surface Light Effects & OpenSceneGraph 3.2'''

Stuart committed a change that brings surface lights, including VASI/PAPI/taxi/runway etc. into the xml-defined Effects framework. Kudos to Tim Moore for his original Effects work - it made it very straightforward to enhance with support for point sprites and a custom texture generator required.

The relevant effect is data/Effects/surface-lights.eff. It should allow development of ALS and Rembrandt variants.

Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow. So, if your
build fails, please check you've got a recent OSG build installed.

'''Core'''
* [[Reset & re-init]] is merged and now enabled
* A segfault related to scripted Nasal fgcommands (like used in joystick and other bindings) has been fixed {{Issue|1397}}
* yasim versioning support for maintenance fixes (TorstenD)
* FLITE TTS support
* Windows dependencies have been updated

'''Aircraft Modeling'''
* galvedro's work: [[A Failure Management Framework for FlightGear]]
* extra 500
* Tu-154B2 version 3.1
* additional aircraft have started adopting Gijs' [[NavDisplay]]

'''JSBSim'''
* ground effects (see newsletter 02/2014)

'''Environment Rendering'''
* EarthView: Orbital Rendering (Thorsten) [http://sourceforge.net/p/flightgear/mailman/message/32262904/]

'''Performance'''
* F-JJTH and Stuart have started working on using osg::Simplifier [https://gitorious.org/fg/simgear/commit/3429e0072103a8c90d8e456f1f6b711099851225]: http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/CAP3ntysifK34TxANKUj1s4Of_dJRg7dvJ74Gbko4zXVFHdV-YQ%40mail.gmail.com/#msg32016452

'''Misc/Uncategorized'''
* AIModels use PagedLOD
* Optimise NavCache airport query
* osg::Switch for masking scenery rendering
* Torsten's metar work, newradio, mongoose httpd
* HTTP: improve handling of connection errors
* [[FGCamera]] (external addon, not yet reviewed/committed as of 03/2014)
* Windows installer has been reworked
* Windows installer creates 3 news directories pre-configured in FGRun:
** {user}\Documents\FlightGear\Aircraft
** {user}\Documents\FlightGear\TerraSync
** {user}\Documents\FlightGear\Custom Scenery

''' Usability '''

''' Internationalization '''

''' Scenery '''

'''Canvas System'''

FlightGear's fully scriptable 2D rendering system now includes improved APIs for creating maps and navigation displays amongst many other improvements. People no longer need to have programming experience to add a working ND to their aircraft, it can now be all done by copying and pasting 30 lines of text and customizing a few properties. The so called MapStructure back-end handles efficient updating of all ND layers transparently.

* Tom has pushed an update to git (simgear) which removes a lot of unneeded OpenGL state changes for Canvas paths. Depending on the GPU/driver this can lead to quite a noticeable performance improvement. For example, he was able to get from ~120ms down to ~45ms [http://forum.flightgear.org/viewtopic.php?f=71&t=16984&p=204730#p204730].
* Hooray is working on adding shader support to Canvas {{Progressbar|30}}
* Gijs is currently working on additional projections as part of {{Issue|550}}
* The [[MapStructure]] back-end used by the [[NavDisplay]] now supports symbol instancing, so that performance is improved
* MapStructure-based layers can now be customized and styled
* Tom added support for button/modifiers (mouse handling) [http://wiki.flightgear.org/index.php?title=Canvas_Event_Handling&curid=10777&diff=68569&oldid=68422]
* CanvasImage now supports the ''http://'' protocol for dynamically retrieving raster images. See the renamed [[Canvas_Image#src|src attribute]] (''file'' is now deprecated).
* As part of the ongoing effort on [[Unifying the 2D rendering backend via canvas]], we have started re-implementing the integrated [[Map]] dialog using Nasal & Canvas instead of C++ {{Progressbar|30}}

'''Nasal Scripting'''

* getprop()/setprop() arguments (those that form a path) can now be numeric to specify a index, so:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index", "texture", 1, "name");
</syntaxhighlight>
: is now the same as:
<syntaxhighlight lang="nasal">
getprop("canvas/by-index/texture[1]/name");
</syntaxhighlight>
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request 54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])
* A new fully-interactive Nasal GUI console based on [[Canvas]] has been added: [[Interactive Nasal Console]]

'''Documentation'''

'''Highlighted new and improved aircraft'''

'''Other'''

'''Bug fixes'''

* See [http://code.google.com/p/flightgear-bugs/issues/list?can=1&q=Milestone%3D3.2 our bugtracker] for an extensive, yet incomplete, list of the bugs fixed in this release.

[[Category:FlightGear changelogs]]

FGCom 3.0

2014-04-22T20:37:50Z

F-JJTH: /* FGCom Builtin */

{{Infobox Software
|title = FGCom 3.0
|logo = FGCom_logo.png|128px
|developedby = Holger Wirtz Martin Spott Csaba Halasz Clément de l'Hamaide
|developmentstatus = Active
|license = GNU GPL v2
|website = http://gitorious.org/fg/flightgear
}}

= What is FGCom ? =
FGCom is a voice communication feature. That way you can communicate with other pilots and airspace controllers during your flight.

The main idea is to reproduce the real aviation communication, in other words this feature is designed to make radio communication as real as possible during your flights.

FGCom is available by two ways:
* Integrated into FlightGear (FGCom builtin): this is certainly the better solution because easier to use
* External software (FGCom standalone): you should use this one only if you plan to use FGCom in a special case

A web interface is available where you can see who is connected in live, the history, and statistics: http://fgcom.flightgear.org

'''IMPORTANT:'''
* FGCom builtin is available for FlightGear 3.0 or higher and is certainly the solution you are looking for because really easy to use.
* FGCom standalone is only for those who want a complex, yet more flexible, setup or don't use FlightGear 3.0 or higher.
* If you are not using FlightGear 3.0 or higher you have to read the [[FGCom_3.0#FGCom_standalone|FGCom standalone section]] and follow "If FlightGear is not installed" instructions.

 
= FGCom Builtin =

=== Installation ===
The good news here is that FlightGear has now an FGCom client built in the software. That means there is no additional installation step. If you have installed FlightGear you can immediately use FGCom.

=== How to start FGCom builtin ? ===
# Start FlightGear
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enable" checkbox
# Close the dialog

You can also use the command line if you prefer:
--enable-fgcom (equivalent to --prop:/sim/fgcom/enabled=true )
--disable-fgcom (equivalent to --prop:/sim/fgcom/enabled=false )

FGCom will be automatically enabled for your future sessions until you uncheck the "Enable" checkbox.

=== How to test your setup ? ===
In order to check that your microphone and speakers are correctly connected and functional you can test it with the following steps:

# Start FlightGear (if not yet done of course)
# Open the dialog located in "Multiplayer > FGCom Settings"
# Check the "Enabled" checkbox (If not yet already done.)
# Check the "Display messages" checkbox. (Displays FGCom's messages on screen)
# Check the "Echo test" checkbox At this moment you should hear your own voice with a delay. If you can't hear your own voice it means your microphone or your speakers are wrongly set. To further check your "Echo test", see [http://fgcom.flightgear.org/history.php Live FGCom] 
# Unckeck the "Echo test" checkbox, and/or other boxes as desired.
# Close the dialog

=== How to use FGCom builtin ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_builtin_.3F|How to start FGCom builtin]] procedure, you can simply use your radio stack like it done in real life.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

[[File:FGCom dialog.png|thumb|FGCom dialog]]

NOTE: It maybe desirable to keep FGCom's Settings "Display messages" activated, to verify these FGCom related keys are working properly.

=== Dialog details ===
The dialog located in "Multiplayer > FGCom Settings" provide some features described here:

* Enable : you can check/uncheck this for enable/disable FGCom feature
* Display messages : display FGCom transaction message for debug only
* Test : check/uncheck this for testing server communication (Echo-Box)
* Speaker volume : set speaker volume for FGCom built-in
* Server > List : Select the server to be connected (immediat effect)

 

= FGCom standalone =
=== Installation ===
'''If FlightGear is installed:'''

The good news here is that if you have FlightGear installed on your computer you already have FGCom standalone !

'''If FlightGear is not installed:'''

If you haven't installed FlightGear on the computer where you want to use FGCom standalone you can simply download FGCom standalone with the following steps:

# Download FGCom standalone: [http://fgcom.flightgear.org/download/fgcom-3.0.0_win32.zip Windows] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux32.zip Linux 32 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_linux64.zip Linux 64 bits] | [http://fgcom.flightgear.org/download/fgcom-3.0.0_mac.zip Mac] (take care to select the correct version for your computer !)
# Unzip the downloaded file
# That's all ! Of course you can place the "FGCom" folder where you want on your computer

On Linux, you have to [http://www.pilotlogic.com/sitejoom/index.php/95-wiki/codetyphon-studio/installation/linux-install/206-linux-give-executable-permission#h1-method-1 setup the permission as "executable"] for the files "run_fgcom.sh" and "test_fgcom.sh"

=== How to start FGCom standalone ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom

On Linux you have to execute FGCom located in your Application menu > Games > FGCom

On Mac you have to enable "Enable FGCOM in Multi Player mode" located in the tab "Network" of the Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "run_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "run_fgcom.command". After the first time you can simply double click on "run_fgcom.command".

'''In both case'''

Now a terminal has been opened and you should be able to see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org

=== How to test your setup ? ===
'''If FlightGear is installed:'''

On Windows you have to execute FGCom located in your Start menu > FlightGear > Tools > FGCom-testing

On Linux you have to execute FGCom located in your Application menu > Games > FGCom-testing

On Mac FIXME: require to be implemented in Mac launcher

'''If FlightGear is not installed:'''

On Windows, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.bat".

On Linux, in your unzipped "FGCom" folder, you have to execute (double clic on it) the file "test_fgcom.sh".

On Mac, in your unzipped "FGCom" folder, you have to execute (right-clic > open with > Terminal.app) the file "test_fgcom.command". After the first time you can simply double click on "test_fgcom.command".

'''In both case'''

Now you should be able to hear your own voice with a delay and see the following lines:
Successfully parsed commandline options
Loaded file [../share/flightgear/special_frequencies.txt].
Reading airports [../share/flightgear/positions.txt]
loaded 46927 entries
Initializing IAX client as guest:xxxxxxxxxxx@fgcom.flightgear.org
Originating an audio only call
Call 0 accepted
Echo Box - For testing FGCOM
Call 0 answered

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}}

=== How to use FGCom standalone ? ===
Once you started FGCom from the [[FGCom_3.0#How_to_start_FGCom_standalone_.3F|How to start FGCom standalone]] procedure, you have to [[FGCom_3.0#FAQ|start FlightGear with the following option]]:
--generic=socket,out,2,127.0.0.1,16661,udp,fgcom

Now you have to leave FGCom standalone running and simply use FlightGear without taking care of FGCom standalone.

When you want to talk you have to press {{Key press|Space}}. When the {{Key press|Space}} is pressed you can't hear other pilots.

You can switch between COM1 and COM2 by pressing {{Key press|Shift}} + {{Key press|Space}}

You can control the sound volume with the slider "ATC" from the File > Sound configuration dialog (even if ATC is unchecked)

During your FlightGear session you should be able to see some lines in the FGCom standalone, it's totally normal, they are here to inform you about the state of FGCom standalone (when you are listening, talking, changing frequency, changing COM1/2...)

In order to stop FGCom standalone you have to press {{Key press|Control}} + {{Key press|c}} or simply close the window.

=== Options details ===

Starting FGCom standalone with "-h" argument will show you all available options.

'''IMPORTANT:''' Keep in mind that FGCom standalone works fine for a standard operating system without options at all ! Use them only if you know exactly what they do.

= FAQ =
''' How to add the --generic option for FGCom standalone ? '''

Since FlightGear 3.0 you can select "FGCom standalone" in the [[FlightGear_Launch_Control#Network|FlightGear Launcher > Advanced > Network]] section else:

On the [[FlightGear_Launch_Control#Page_four_-_Options_and_Run|last page of the FlightGear Launcher]], press "Advanced" then [[FlightGear_Launch_Control#Input.2FOutput|select "Input/Output" item]]. Press "New" and set the fields as:
* Protocol : generic
* Medium : socket
* Direction : out
* Hz : 5
* Hostname : 127.0.0.1
* Port : 16661
* Select UDP
* Generic : fgcom

''' I want to use FGCom builtin but I haven't any item "Multiplayer > FGCom Settings" in FlightGear '''

Because you are not using FlightGear 3.0 or higher. FGCom builtin is only available for FlightGear 3.0 or higher. You have to use FGCom standalone until you upgrade your FlightGear installation.

''' I want to use FGCom standalone but I haven't any FGCom item in "Start menu > FlightGear > Tools" '''

Because you are not using FlightGear 3.0 or higher. FGCom standalone is automatically installed only for FlightGear 3.0 or higher.

You have to follow "If FlightGear is not installed" instructions until you upgrade your FlightGear installation.

''' I'm using FGCom standalone, other pilots can hear me but I can't hear other pilots '''

Be sure the slider "ATC" from the File > Sound configuration dialog is at full right.

= Linux ALSA Sound =
By defaults, most Linux ALSA systems should just work. This is because by default Linux ALSA utilizes the DMix plugin when there is no $HOME/.asoundrc file. Linux ALSA also, by default when using DMix unless further customized, resamples all audio to 48000hz. If this is not the case, or if you speculate customizations have been performed by your Linux distribution, you may need to read further below on how to ensure ALSA's DMix and DSnoop plugins are used with FlightGear & FGCom. The common side effect of possible customizations, FGCom does not playback (or record) sound.

(Reference [[Linux software audio mixing with FlightGear]]) 

Check your Home-directory (“~/” or $HOME) for a file "'''.alsoftrc'''"
(Remember that the “show hidden files” must be enabled!)

Copied over from [[FGCOM Testing]] or FGCOM Testing Wiki page.

=== If using Creative Labs' OpenAL library (or older OpenAL version) ===
Check if you are using the old Creative Labs OpenAL library (or old version) which uses the ".openalrc" configuration file. If so, you can put something like this within ".openalrc":

$HOME/.openalrc
<pre>
(define devices '(alsa))
(define alsa-out-device "plug:dmix")
(device alsa-in-device "plug:dsnoop")
</pre>

=== If using OpenAL Soft (or newer OpenAL version) ===
It is more likely users of more recent Linux distributions are using this newer OpenAL Soft package, instead of the previously mentioned older Create Labs' OpenAL. (Hence, the likely rational for renaming the default configuration file to something other than the more common previous naming format.)

Copy either the be /etc/openal/alsoft.conf, /usr/share/doc/openal-1.15.1-r2/alsoftrc.sample.bz2, or create a new $HOME/.alsoftrc file and insert the following:

<pre><nowiki>
format = AL_FORMAT_STEREO16
cf_level = 1
drivers = alsa
[alsa]
device = plug:dmix
capture = plug:dsnoop
</nowiki></pre>

[NOTE: format is now "sample-type = uint16", and cf_level would appear not needed for typical users, or only desired for headphone users.]

The system wide OpenAL-soft configuration file may be /etc/openal/alsoft.conf or similar. It usually contains comments describing all possible configuration options.
 

=== Linux ALSA Audiophiles avoiding Dmix ===
For audiophiles using Linux ALSA and with their custom $HOME/.asoundrc file preventing DMix usage, make sure you have both specified "device = plug:dmix" as well as "capture = plug:dsnoop". Per ALSA's page, "dsnoop is the equivalent of the dmix plugin, but for recording sound." Without specifying using dsnoop for the capture device alongside your $HOME/.asoundrc file preventing DMix usage, you will likely only get silence played back when usage FGCom. FGCom is not working at this point, as the sound device is likely still locked by your $HOME/.asoundrc file and only recording silence or playing back silence during the echo test!

=== Using ALSA Custom "plug:" Filters ===
The OpenAL Soft (or the newer version of OpenAL) $HOME/.alsoftrc file also accepts using other $HOME/.asoundrc "plug:" incanatations, such as sections containing Dmix - alsa.opensrc.org's "pcm.dmixs51" customization for using DMix with 5.1 Surround Sound, and called as:

<pre>$ aplay -D "plug:dmixs51" Some_PCM_WAV_File.wav </pre>

$HOME/.alsoftrc
<pre>
"device = plug:dmixs51"
</pre>

Just remember to also uncomment layout_surround51, and note the likely fact FlightGear is still only using Stereo sound (or two channel audio) and is only set here for an example!

[[fr:FGCom 3.0]]
[[Category:FGCom]]