FlightGear wiki - User contributions [en]

Howto:Add blackout and redout settings

2024-05-18T11:37:26Z

Necolatis: /* Source code */ added heading

This is '''how to add blackout and redout settings''' to an aircraft. These settings will determine when the view will start to turn black or red and when it will be fully black or red due to {{wikipedia|G-force#Human tolerance of g-force|g-force}}.

{{note|While the pilot will be temporarily blind due to g-force he will not be incapacitated (G-LOC) and will still be able to control the aircraft.}}

The G effect system is time based, so for example the longer time you spend at a high G the darker the screen gets.

The algorithm was used by a US military simulator and has been adapted to Flightgear.

It features gradual vision loss according to G and time in a logarithmic manner. Furthermore, once the pilot has experienced vision loss, the pilot must return G force to below a certain threshold before it starts to clear.

It also features G priming (PPE), so that if you for example pull some high Gs for a while and then go negative, the redout will take longer to come into effect, and vice versa, as the blood flows to or from the pilots brain.

== Tunnel vision, redout and greyout in ALS ==
If running in [[ALS]] with ALS filters enabled, there will be greyout with tunnel-vision. Only the filters checkbox is needed, no need for infrared or night-vision to be enabled.

Greyout is a transient loss of vision from positive G's, it has these effects:

* Loss of peripheral vision (aka. tunnel vision)
* Dimming of bright light
* Desaturation
* Brown hue (not implemented yet)
* When the effect is heavy, there is some noise blurring too

Redout has these effects (and no tunnel vision):

* Red hue
* Loss of vision

Both redout and greyout will end with 100% vision loss.

[[File:Blackout shaders.png|640px|Blackout shaders in effect]]

== G effects in Rembrandt ==
G effects is not implemented in [[Rembrandt]].

== G effects in HDR ==
A G effect has been added to [[HDR]].

= Install in aircraft =
You can customize some parameters according to the quality of the G-suit the pilot is wearing and training in anti-G breathing.

Blackout and redout are controlled through these properties in <code>/sim/rendering/redout/</code>:

* <code>enabled</code> (bool)
If the system is on or off.

* <code>parameters/blackout-onset-g</code> (double) [Default = 2.5 G]
* <code>parameters/onset-blackout-sec</code> (double) [Default = 300 seconds]
Onset-g must be positive and above 1. This is the G-force when the blackout effect will start to come into effect. This is also the G-force that the pilot will have to get below to clear the blackout of the screen. The time property is to set how many seconds it takes to get complete blackout at this G value.

* <code>parameters/blackout-complete-g</code> (double) [Default = 4.5 G]
* <code>parameters/fast-blackout-sec</code> (double) [Default = 10 seconds]
Complete-g must be higher than blackout-onset-g. This should be at or near to the maximum the pilot should be expected to tolerate depending on his G-suit and anti-G breathing techniques or lack of those. The fast-blackout-sec, is how long it will take to blackout completely at this G value. This should normally be considerably shorter than onset-blackout-sec.

* <code>parameters/redout-onset-g</code> (double) [Default = -2 G]
* <code>parameters/redout-complete-g</code> (double) [Default = -4 G]
* <code>parameters/onset-redout-sec</code> (double) [Default = 45 seconds]
* <code>parameters/fast-redout-sec</code> (double) [Default = 7.5 seconds]
These four works like the first four, just for negative Gs. Onset-g must be below 1 and complete-g must be below onset.

* <code>parameters/recover-fast-sec</code> (double) [Default = 7 seconds]
* <code>parameters/recover-slow-sec</code> (double) [Default = 15 seconds]
The recover-slow is how long it takes to recover from complete redout/blackout just below the onset, and recover-fast is how long it takes to clear at 1 G.

The default values, is estimated to be for a pilot without G-suit and untrained in anti-G breathing techniques. So defaults is well suited for GA aircraft.

The properties can be controlled at runtime or be added to any [[PropertyList XML files|PropertyList XML file]], for example an [[aircraft-set.xml]] or your own [[FlightGear configuration via XML|configuration file]].

In addition to these properties there is another property, <code>/sim/rendering/headshake/enabled</code> (bool), that will make the pilots viewpoint move up and down due to the g-force, for example due to maneuvers or turbulence.

== Minimal install ==
Notice that the new system from FG 2017.1.1 is somewhat backwards compatible with the older system. The old system used only these 5 properties, if you do not want to adjust it too detailed you can just set these 5, they are also the 5 that the pilot can control in the GUI:
* <code>enabled</code> (bool)
* <code>parameters/blackout-onset-g</code> (double)
* <code>parameters/blackout-complete-g</code> (double)
* <code>parameters/redout-onset-g</code> (double)
* <code>parameters/redout-complete-g</code> (double)

== Hearing loss ==
To add hearing loss, add this extra volume section to each sound effect section in the sound xml, and put this Nasal code in a 10 to 20hz loop:

<syntaxhighlight lang="Nasal">
var bf = getprop("sim/rendering/als-filters/black-factor");
setprop("mySounds/g-force-effect-volume", 1-bf);
</syntaxhighlight>

<syntaxhighlight lang="xml">
<volume>
<property>mySounds/g-force-effect-volume</property>
<factor>1</factor>
<offset>0</offset>
<min>0</min>
<max>1</max>
</volume>
</syntaxhighlight>

== Example (Fighter-jet 1979) ==
This example show how these setting can be added to a propertylist xml file:
These blackout settings is the values used in a 1979 Langley simulator for F-16.
Notice that the redout is also same as the default values, they are low because G-suits mainly protects against high G, not much against negative Gs.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>

<sim>

<rendering>
<redout>
<enabled type="bool" userarchive="y">true</enabled>
<parameters>
<blackout-onset-g type="double">5</blackout-onset-g>
<blackout-complete-g type="double">9</blackout-complete-g>
<onset-blackout-sec type="double">300</onset-blackout-sec>
<fast-blackout-sec type="double">10</fast-blackout-sec>
<redout-onset-g type="double">-2</redout-onset-g>
<redout-complete-g type="double">-4</redout-complete-g>
<onset-redout-sec type="double">45</onset-redout-sec>
<fast-redout-sec type="double">7.5</fast-redout-sec>
<recover-fast-sec type="double">7</recover-fast-sec>
<recover-slow-sec type="double">15</recover-slow-sec>
</parameters>
</redout>
<headshake>
<enabled type="bool" userarchive="y">true</enabled>
</headshake>
</rendering>

</sim>

</PropertyList>
</syntaxhighlight>

== Example (Fighter-jet 1995) ==

For more modern fighters 1995+ you could set the positive G effect settings to something like this (Don't be misled by 8 vs. 9 G, its time curve is much more gentle):

<syntaxhighlight>
blackout-onset-g = 5;
blackout-complete-g = 8;
onset-blackout-sec = 300;
fast-blackout-sec = 30;
</syntaxhighlight>

= Forum topics =
* [http://forum.flightgear.org/viewtopic.php?f=47&t=26380&p=244613 Adding redout and blackout]
* [https://forum.flightgear.org/viewtopic.php?f=4&t=30985 More realistic Blackout/Redout]

= Mailing list threads =
* [http://sourceforge.net/p/flightgear/mailman/message/18602699/ <nowiki>[Flightgear-devel] Generic Blackout/Redout</nowiki>]

= Source code =
Main system:
* {{fgdata file|Aircraft/Generic/g-forces.xml}}
Helper loops:
* {{fgdata file|Nasal/redout.nas}}
The basic effect is just to turn screen black/red:
* {{flightgear file|src/Scenery/redout.hxx}}
* {{flightgear file|src/Scenery/redout.cxx}}
The ALS filter redout system works by combining a shader effect with the effect of turning screen back/red:
* {{fgdata file|Shaders/filters-ALS.frag}}
The HDR effect is also shader based:
* {{fgdata file|Shaders/HDR/redout.glsl}}

= Citations =
* {{cite web
| url = http://www.dtic.mil/dtic/tr/fulltext/u2/a109127.pdf
| title = AFHRL-TP-80-41 - Study and Design of High G Augmentation Devices for Flight Simulators
| author = Kron, Gerald J.; Cardullo, Frank M.; Young, Laurence R.
| date = December 1981
| publisher = US Air Force Human Resources Laboratory
| format = pdf
}}

[[Category:Aircraft enhancement]]
[[Category:Howto]]

Howto:Add blackout and redout settings

2024-05-18T11:36:46Z

Necolatis: /* Source code */ added citation from deleted page

This is '''how to add blackout and redout settings''' to an aircraft. These settings will determine when the view will start to turn black or red and when it will be fully black or red due to {{wikipedia|G-force#Human tolerance of g-force|g-force}}.

{{note|While the pilot will be temporarily blind due to g-force he will not be incapacitated (G-LOC) and will still be able to control the aircraft.}}

The G effect system is time based, so for example the longer time you spend at a high G the darker the screen gets.

The algorithm was used by a US military simulator and has been adapted to Flightgear.

It features gradual vision loss according to G and time in a logarithmic manner. Furthermore, once the pilot has experienced vision loss, the pilot must return G force to below a certain threshold before it starts to clear.

It also features G priming (PPE), so that if you for example pull some high Gs for a while and then go negative, the redout will take longer to come into effect, and vice versa, as the blood flows to or from the pilots brain.

== Tunnel vision, redout and greyout in ALS ==
If running in [[ALS]] with ALS filters enabled, there will be greyout with tunnel-vision. Only the filters checkbox is needed, no need for infrared or night-vision to be enabled.

Greyout is a transient loss of vision from positive G's, it has these effects:

* Loss of peripheral vision (aka. tunnel vision)
* Dimming of bright light
* Desaturation
* Brown hue (not implemented yet)
* When the effect is heavy, there is some noise blurring too

Redout has these effects (and no tunnel vision):

* Red hue
* Loss of vision

Both redout and greyout will end with 100% vision loss.

[[File:Blackout shaders.png|640px|Blackout shaders in effect]]

== G effects in Rembrandt ==
G effects is not implemented in [[Rembrandt]].

== G effects in HDR ==
A G effect has been added to [[HDR]].

= Install in aircraft =
You can customize some parameters according to the quality of the G-suit the pilot is wearing and training in anti-G breathing.

Blackout and redout are controlled through these properties in <code>/sim/rendering/redout/</code>:

* <code>enabled</code> (bool)
If the system is on or off.

* <code>parameters/blackout-onset-g</code> (double) [Default = 2.5 G]
* <code>parameters/onset-blackout-sec</code> (double) [Default = 300 seconds]
Onset-g must be positive and above 1. This is the G-force when the blackout effect will start to come into effect. This is also the G-force that the pilot will have to get below to clear the blackout of the screen. The time property is to set how many seconds it takes to get complete blackout at this G value.

* <code>parameters/blackout-complete-g</code> (double) [Default = 4.5 G]
* <code>parameters/fast-blackout-sec</code> (double) [Default = 10 seconds]
Complete-g must be higher than blackout-onset-g. This should be at or near to the maximum the pilot should be expected to tolerate depending on his G-suit and anti-G breathing techniques or lack of those. The fast-blackout-sec, is how long it will take to blackout completely at this G value. This should normally be considerably shorter than onset-blackout-sec.

* <code>parameters/redout-onset-g</code> (double) [Default = -2 G]
* <code>parameters/redout-complete-g</code> (double) [Default = -4 G]
* <code>parameters/onset-redout-sec</code> (double) [Default = 45 seconds]
* <code>parameters/fast-redout-sec</code> (double) [Default = 7.5 seconds]
These four works like the first four, just for negative Gs. Onset-g must be below 1 and complete-g must be below onset.

* <code>parameters/recover-fast-sec</code> (double) [Default = 7 seconds]
* <code>parameters/recover-slow-sec</code> (double) [Default = 15 seconds]
The recover-slow is how long it takes to recover from complete redout/blackout just below the onset, and recover-fast is how long it takes to clear at 1 G.

The default values, is estimated to be for a pilot without G-suit and untrained in anti-G breathing techniques. So defaults is well suited for GA aircraft.

The properties can be controlled at runtime or be added to any [[PropertyList XML files|PropertyList XML file]], for example an [[aircraft-set.xml]] or your own [[FlightGear configuration via XML|configuration file]].

In addition to these properties there is another property, <code>/sim/rendering/headshake/enabled</code> (bool), that will make the pilots viewpoint move up and down due to the g-force, for example due to maneuvers or turbulence.

== Minimal install ==
Notice that the new system from FG 2017.1.1 is somewhat backwards compatible with the older system. The old system used only these 5 properties, if you do not want to adjust it too detailed you can just set these 5, they are also the 5 that the pilot can control in the GUI:
* <code>enabled</code> (bool)
* <code>parameters/blackout-onset-g</code> (double)
* <code>parameters/blackout-complete-g</code> (double)
* <code>parameters/redout-onset-g</code> (double)
* <code>parameters/redout-complete-g</code> (double)

== Hearing loss ==
To add hearing loss, add this extra volume section to each sound effect section in the sound xml, and put this Nasal code in a 10 to 20hz loop:

<syntaxhighlight lang="Nasal">
var bf = getprop("sim/rendering/als-filters/black-factor");
setprop("mySounds/g-force-effect-volume", 1-bf);
</syntaxhighlight>

<syntaxhighlight lang="xml">
<volume>
<property>mySounds/g-force-effect-volume</property>
<factor>1</factor>
<offset>0</offset>
<min>0</min>
<max>1</max>
</volume>
</syntaxhighlight>

== Example (Fighter-jet 1979) ==
This example show how these setting can be added to a propertylist xml file:
These blackout settings is the values used in a 1979 Langley simulator for F-16.
Notice that the redout is also same as the default values, they are low because G-suits mainly protects against high G, not much against negative Gs.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>

<sim>

<rendering>
<redout>
<enabled type="bool" userarchive="y">true</enabled>
<parameters>
<blackout-onset-g type="double">5</blackout-onset-g>
<blackout-complete-g type="double">9</blackout-complete-g>
<onset-blackout-sec type="double">300</onset-blackout-sec>
<fast-blackout-sec type="double">10</fast-blackout-sec>
<redout-onset-g type="double">-2</redout-onset-g>
<redout-complete-g type="double">-4</redout-complete-g>
<onset-redout-sec type="double">45</onset-redout-sec>
<fast-redout-sec type="double">7.5</fast-redout-sec>
<recover-fast-sec type="double">7</recover-fast-sec>
<recover-slow-sec type="double">15</recover-slow-sec>
</parameters>
</redout>
<headshake>
<enabled type="bool" userarchive="y">true</enabled>
</headshake>
</rendering>

</sim>

</PropertyList>
</syntaxhighlight>

== Example (Fighter-jet 1995) ==

For more modern fighters 1995+ you could set the positive G effect settings to something like this (Don't be misled by 8 vs. 9 G, its time curve is much more gentle):

<syntaxhighlight>
blackout-onset-g = 5;
blackout-complete-g = 8;
onset-blackout-sec = 300;
fast-blackout-sec = 30;
</syntaxhighlight>

= Forum topics =
* [http://forum.flightgear.org/viewtopic.php?f=47&t=26380&p=244613 Adding redout and blackout]
* [https://forum.flightgear.org/viewtopic.php?f=4&t=30985 More realistic Blackout/Redout]

= Mailing list threads =
* [http://sourceforge.net/p/flightgear/mailman/message/18602699/ <nowiki>[Flightgear-devel] Generic Blackout/Redout</nowiki>]

= Source code =
Main system:
* {{fgdata file|Aircraft/Generic/g-forces.xml}}
Helper loops:
* {{fgdata file|Nasal/redout.nas}}
The basic effect is just to turn screen black/red:
* {{flightgear file|src/Scenery/redout.hxx}}
* {{flightgear file|src/Scenery/redout.cxx}}
The ALS filter redout system works by combining a shader effect with the effect of turning screen back/red:
* {{fgdata file|Shaders/filters-ALS.frag}}
The HDR effect is also shader based:
* {{fgdata file|Shaders/HDR/redout.glsl}}

* {{cite web
| url = http://www.dtic.mil/dtic/tr/fulltext/u2/a109127.pdf
| title = AFHRL-TP-80-41 - Study and Design of High G Augmentation Devices for Flight Simulators
| author = Kron, Gerald J.; Cardullo, Frank M.; Young, Laurence R.
| date = December 1981
| publisher = US Air Force Human Resources Laboratory
| format = pdf
}}

[[Category:Aircraft enhancement]]
[[Category:Howto]]

Howto:Add blackout and redout settings

2024-05-18T11:32:41Z

Necolatis: Removed old outdated info for FG 2017 and restructured article

This is '''how to add blackout and redout settings''' to an aircraft. These settings will determine when the view will start to turn black or red and when it will be fully black or red due to {{wikipedia|G-force#Human tolerance of g-force|g-force}}.

{{note|While the pilot will be temporarily blind due to g-force he will not be incapacitated (G-LOC) and will still be able to control the aircraft.}}

The G effect system is time based, so for example the longer time you spend at a high G the darker the screen gets.

The algorithm was used by a US military simulator and has been adapted to Flightgear.

It features gradual vision loss according to G and time in a logarithmic manner. Furthermore, once the pilot has experienced vision loss, the pilot must return G force to below a certain threshold before it starts to clear.

It also features G priming (PPE), so that if you for example pull some high Gs for a while and then go negative, the redout will take longer to come into effect, and vice versa, as the blood flows to or from the pilots brain.

== Tunnel vision, redout and greyout in ALS ==
If running in [[ALS]] with ALS filters enabled, there will be greyout with tunnel-vision. Only the filters checkbox is needed, no need for infrared or night-vision to be enabled.

Greyout is a transient loss of vision from positive G's, it has these effects:

* Loss of peripheral vision (aka. tunnel vision)
* Dimming of bright light
* Desaturation
* Brown hue (not implemented yet)
* When the effect is heavy, there is some noise blurring too

Redout has these effects (and no tunnel vision):

* Red hue
* Loss of vision

Both redout and greyout will end with 100% vision loss.

[[File:Blackout shaders.png|640px|Blackout shaders in effect]]

== G effects in Rembrandt ==
G effects is not implemented in [[Rembrandt]].

== G effects in HDR ==
A G effect has been added to [[HDR]].

= Install in aircraft =
You can customize some parameters according to the quality of the G-suit the pilot is wearing and training in anti-G breathing.

Blackout and redout are controlled through these properties in <code>/sim/rendering/redout/</code>:

* <code>enabled</code> (bool)
If the system is on or off.

* <code>parameters/blackout-onset-g</code> (double) [Default = 2.5 G]
* <code>parameters/onset-blackout-sec</code> (double) [Default = 300 seconds]
Onset-g must be positive and above 1. This is the G-force when the blackout effect will start to come into effect. This is also the G-force that the pilot will have to get below to clear the blackout of the screen. The time property is to set how many seconds it takes to get complete blackout at this G value.

* <code>parameters/blackout-complete-g</code> (double) [Default = 4.5 G]
* <code>parameters/fast-blackout-sec</code> (double) [Default = 10 seconds]
Complete-g must be higher than blackout-onset-g. This should be at or near to the maximum the pilot should be expected to tolerate depending on his G-suit and anti-G breathing techniques or lack of those. The fast-blackout-sec, is how long it will take to blackout completely at this G value. This should normally be considerably shorter than onset-blackout-sec.

* <code>parameters/redout-onset-g</code> (double) [Default = -2 G]
* <code>parameters/redout-complete-g</code> (double) [Default = -4 G]
* <code>parameters/onset-redout-sec</code> (double) [Default = 45 seconds]
* <code>parameters/fast-redout-sec</code> (double) [Default = 7.5 seconds]
These four works like the first four, just for negative Gs. Onset-g must be below 1 and complete-g must be below onset.

* <code>parameters/recover-fast-sec</code> (double) [Default = 7 seconds]
* <code>parameters/recover-slow-sec</code> (double) [Default = 15 seconds]
The recover-slow is how long it takes to recover from complete redout/blackout just below the onset, and recover-fast is how long it takes to clear at 1 G.

The default values, is estimated to be for a pilot without G-suit and untrained in anti-G breathing techniques. So defaults is well suited for GA aircraft.

The properties can be controlled at runtime or be added to any [[PropertyList XML files|PropertyList XML file]], for example an [[aircraft-set.xml]] or your own [[FlightGear configuration via XML|configuration file]].

In addition to these properties there is another property, <code>/sim/rendering/headshake/enabled</code> (bool), that will make the pilots viewpoint move up and down due to the g-force, for example due to maneuvers or turbulence.

== Minimal install ==
Notice that the new system from FG 2017.1.1 is somewhat backwards compatible with the older system. The old system used only these 5 properties, if you do not want to adjust it too detailed you can just set these 5, they are also the 5 that the pilot can control in the GUI:
* <code>enabled</code> (bool)
* <code>parameters/blackout-onset-g</code> (double)
* <code>parameters/blackout-complete-g</code> (double)
* <code>parameters/redout-onset-g</code> (double)
* <code>parameters/redout-complete-g</code> (double)

== Hearing loss ==
To add hearing loss, add this extra volume section to each sound effect section in the sound xml, and put this Nasal code in a 10 to 20hz loop:

<syntaxhighlight lang="Nasal">
var bf = getprop("sim/rendering/als-filters/black-factor");
setprop("mySounds/g-force-effect-volume", 1-bf);
</syntaxhighlight>

<syntaxhighlight lang="xml">
<volume>
<property>mySounds/g-force-effect-volume</property>
<factor>1</factor>
<offset>0</offset>
<min>0</min>
<max>1</max>
</volume>
</syntaxhighlight>

== Example (Fighter-jet 1979) ==
This example show how these setting can be added to a propertylist xml file:
These blackout settings is the values used in a 1979 Langley simulator for F-16.
Notice that the redout is also same as the default values, they are low because G-suits mainly protects against high G, not much against negative Gs.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>

<sim>

<rendering>
<redout>
<enabled type="bool" userarchive="y">true</enabled>
<parameters>
<blackout-onset-g type="double">5</blackout-onset-g>
<blackout-complete-g type="double">9</blackout-complete-g>
<onset-blackout-sec type="double">300</onset-blackout-sec>
<fast-blackout-sec type="double">10</fast-blackout-sec>
<redout-onset-g type="double">-2</redout-onset-g>
<redout-complete-g type="double">-4</redout-complete-g>
<onset-redout-sec type="double">45</onset-redout-sec>
<fast-redout-sec type="double">7.5</fast-redout-sec>
<recover-fast-sec type="double">7</recover-fast-sec>
<recover-slow-sec type="double">15</recover-slow-sec>
</parameters>
</redout>
<headshake>
<enabled type="bool" userarchive="y">true</enabled>
</headshake>
</rendering>

</sim>

</PropertyList>
</syntaxhighlight>

== Example (Fighter-jet 1995) ==

For more modern fighters 1995+ you could set the positive G effect settings to something like this (Don't be misled by 8 vs. 9 G, its time curve is much more gentle):

<syntaxhighlight>
blackout-onset-g = 5;
blackout-complete-g = 8;
onset-blackout-sec = 300;
fast-blackout-sec = 30;
</syntaxhighlight>

= Forum topics =
* [http://forum.flightgear.org/viewtopic.php?f=47&t=26380&p=244613 Adding redout and blackout]
* [https://forum.flightgear.org/viewtopic.php?f=4&t=30985 More realistic Blackout/Redout]

= Mailing list threads =
* [http://sourceforge.net/p/flightgear/mailman/message/18602699/ <nowiki>[Flightgear-devel] Generic Blackout/Redout</nowiki>]

= Source code =
Main system:
* {{fgdata file|Aircraft/Generic/g-forces.xml}}
Helper loops:
* {{fgdata file|Nasal/redout.nas}}
The basic effect is just to turn screen black/red:
* {{flightgear file|src/Scenery/redout.hxx}}
* {{flightgear file|src/Scenery/redout.cxx}}
The ALS filter redout system works by combining a shader effect with the effect of turning screen back/red:
* {{fgdata file|Shaders/filters-ALS.frag}}
The HDR effect is also shader based:
* {{fgdata file|Shaders/HDR/redout.glsl}}

[[Category:Aircraft enhancement]]
[[Category:Howto]]

AI Scenarios

2023-11-10T09:35:30Z

Necolatis: Add info on how to load scenarios

There are multiple way to to load a scenario in FG:

* Put the scenarios in $FG_HOME/Scenarios
* Put the scenarios in {aircraft-dir}/Scenarios
* Put them in {add-on}/Scenarios
* Put them in $FGDATA/Scenarios
* Passing the path to a scenario file to —ai-scenario, eg —ai-scenario=/home/jmt/FGFS/my-test-scenario.xml

When it has been loaded, it also need to be enabled. That can be done from command-line or from the menu.

= Demo scenarios =
This is a list of the demo scenarios, distributed with Flightgear 2019.1

To find additional scenarios, take a look at [[Hangars#Unofficial_sites|unofficial hangars]].

===aircraft_demo===
737 takeoff from runway 28L at KSFO and fly the Porte Departure to the south

===ballon_demo===
Spawns some hotair ballons close to where you start.

===clemenceau_demo===
Puts french carrier Clemenceau at:
<latitude>42.800</latitude>
<longitude>6.325</longitude>

===droptank_demo===
Ties droptanks to the aircraft. This is a ballistic AI object, once released it will follow a ballistic curve.

===droptank_hunter_demo===
Ties droptanks to the aircraft. This is a ballistic AI object, once released it will follow a ballistic curve.

===eisenhower_demo===
Sets up USS Eisenhower in operating an operating box off Norfolk VA.

===foch_demo===
Puts french carrier Foch at:
<latitude>42.830</latitude>
<longitude>6.325</longitude>

Hint: If the Foch model is missing in your Flightgear installation, just copy Clemenceau.xml to Foch.xml and exchange all strings "Clemenceau" to "Foch" in the xml file. These two carriers are the same type of ship in the real world.

===ICE3_demo===
A german train from Frankfurt to Essen.
Select Frankfurt (EDDF) airport, hang about a bit, The ICE3 runs close to the main terminal, and is relatively easy to spot.

===KRHV_towing_demo===
J3 takeoff from runway 31L at KRHV for aerotowing.

===KSFO_AirTrain===
Trains drive around on elevated rails in KSFO.

===lead_aircraft===
A 737 tanker at 3000 circling above KSFO.

===load_demo===
This was a first try to create an external cargo, which could be carried/ towed by a helicopter or any other aircraft.
The goal was to simulate realistic slung loads and winching operation.
The file places an AI ballistic object at 28R KSFO. The object can be easily controlled by applying forces, which are defined in terms of
Magnitude (lbf), Azimuth (deg, North = O) and Elevation (deg, up = 90). When released it behaves like any other ballistic AI-Object.
Like any AI-object it can be hooked. To make it workable, the forces on the hook must be applied and transformed to the AI Object.
Weight, slug mass and aerodynamic drag of the object can be defined in the file.
This project has been stopped due problems which couldn't be solved at this time.

Nethertheless with little effort, the problems could be solved today and would have many advantages over the current approach described in
http://forum.flightgear.org/viewtopic.php?f=23&t=23996.
As an example you could also create more easily AI missiles or rockets, or carrying a Space Shuttle which could be released and controlled to get landed on an airport, everything without much lines of nasal scripts.
For more infos and the developing background: http://sourceforge.net/p/flightgear/mailman/message/15801723/
The file load_demo.xml itself gives information in how to use.

===nimitz_demo===
Places 2 Nimitz-class Carriers in the environment:

USS Nimitz - in the Pacific Ocean off San Fransisco

USS Eisenhower in the Mediterranean off Toulon

===PAVictoria===
Ferry will depart from port near KNOW.

===railway_demo===
This scenario runs a variety of trains and buses along tracks or roads near Wakefield, Yorkshire, UK

Select Leeds-Bradford (EGNM) airport, fly 165 deg until you get to Wakefield. Look around: there is a railway line to the south of the city, and one to the east. The bus runs out to the west. Look carefully - the trains and bus are very hard to pick out.

===sanantonio_demo===
Puts carrier USS San Antonio at:
<latitude>32.75</latitude>
<longitude>-117.34</longitude>

===seahawk_wingman_demo===
A Seahawk wingman.

PS. The plane must be installed in data/aircraft folder.

===ship_demo===
Puts a sailboat in the bay just east of KSFO

===steam_train_demo===
A steamtrain operating in North Yorkshire Moors, UK.

To find it start at EGXZ - TOPCLIFFE and fly 084 degrees magnetic

===tankers===
Several tanker aircraft

===truman_demo===
Puts carrier USS Harry S.Truman at:
<latitude>21.3</latitude>
<longitude>-157.3</longitude>

35nm east of Honolulu near PHNL

===vinson_demo===
Puts carrier USS Vinson at:
<latitude>37.8</latitude>
<longitude>-123.6</longitude>

60nm west of San Fransisco

===wingman_b29_2_demo===
B29 Section 2 adds 4 B29 aircraft as wingmen.

===wingman_b29_3_demo===
B29 Section 3 adds 4 B29 aircraft as wingmen.

PS. It assumes the b29 is put in default FG aircraft folder.

===wingman_b29_demo===
B29 Section with 3 B29 aircraft as wingmen.

===wingman_demo===
One british twin engine Bucaneer acts as wingman. This only works if its installed into data/Aircraft folder.

===wingman2_demo===
Two british twin engine Bucaneer act as wingmen. This only works if they are installed into data/Aircraft folder.

= Deprecated scenarios =
The following scenarios are no longer available in FG 2019.1

===bigstorm_demo===
Big thunderstrom over San Fransisco.
Remark: no longer available in FG 2019.1

===refueling_demo===
Puts an 737 aerial tanker in orbit over KSFO at 3000 ft AGL.
Remark: no longer available in FG 2019.1

===refueling_demo_1===
Puts an KC-135 aerial tanker in a N/S towline starting over KSFO at 8000 ft AGL.
Remark: no longer available in FG 2019.1

===refueling_demo_2===
Puts an KC-135 aerial tanker in a N/S towline starting over KSFO at 8000 ft AGL.
Remark: no longer available in FG 2019.1

===Thermal_demo===
Thermal winds over KSFO.
Remark: no longer available in FG 2019.1

= Flightplan scenario=
AI flightplan scenarios are very simple. Simply tie a flightplan to a model, and you have a scenario. Below, I'm going to go explain exactly how this is done.

== Flightplans and Their Waypoints ==
Flightplans have a basic structure that you must adhere to in order to create one successfully. They are in XML, and consist of several waypoints. So, you have the XML header at the top followed by a PropertyList tag and a flightplan tag, followed by a series of waypoints, a final waypoint with no coordinates, called EOF (end of flight), and the end tags for PropertyList and flightplan.

Each waypoint has eight parameters. They tend to be written in the following order: name, lat, lon, alt, ktas, on-ground, gear-down, flaps-down. All waypoints, except EOF, must have these, or the scenario may behave unpredictably. Furthermore, all waypoints are tagged with a wpt tag. Now, to go through the different parameters.

* name: can consist of anything. If you want to use a word or a number, it doesn't matter so long as the characters in it are allowed in XML.
* lat: the model's latitude at the waypoint.
* lon: the model's longitude at the waypoint.
* alt: the model's altitude.
* ktas: Knots True AirSpeed of the model.
* on-ground: a boolean value expressed as an integer value of either 1 or 0.
* gear-down: a boolean value expressed as an integer value of either 1 or 0.
* flaps-down: a float value expressed a value between 0 and 1.
* on-ground need not necessarily be placed correctly. In the example, you will see that, for all waypoints, this value is set to zero. You may want to play around with this one. If you set it to 1 too early (for a landing), the aircraft will be thrust onto the ground sharply. If you set it late, then things should be okay. Or, it may appear to hover if you’ve set the altitude a bit high.

[[File:SFOBridges1.png]][[File:SFOBridges2.png]]

Once completed, be sure to save as an XML file in the AI/flightplans directory.

== Tying Things Together ==
Next, you need to create the scenario XML file. For the example, I will simply borrow an existing one, and make modifications to it. I’ll choose aircraft_demo.xml. As you will see, you need PropertyList and scenario tags. A description is optional, but recommended. Then, there’s an entry for a model. It starts with an entry tag. Then, it’s given a callsign. The type is aircraft. There are different types you can specify for different kinds of scenarios; however, we’re just going to focus on the aircraft type. There are various classes as well. This one is set to jet transport. I think there’s a light class as well, but they all seem to behave the same to me. If someone else, more knowledgeable in this area could clarify things that would be helpful. Next is the model. Just set the path to the aircraft of your choice. It’s recommended that you use a low-poly aircraft from the AI directory, but a regular aircraft works fine as well. After that is the flightplan parameter. Simply set the path to your flightplan. Finally, there is an option to set your scenario to either simply terminate or repeat once completed. Enter a 1 for repeat, a 0 for no repeat. Remember to add all your end-tags when you have finished, and save it with a name other than the one you modified (if you chose to modify an existing scenario).
==Special Tools ==
There are two great tools for making flight plans. You can use Oscar’s Flightplan Generator or redneck’s Flightplan Generator. They work very differently, but can be used together to further enhance your AI scenarios. Oscar’s Flightplan Generator uses a Google Maps interface in which you simply click on the location you want to place a waypoint at, and enter the rest of the data (speed, altitude, on-ground, etc.). redneck’s Flightplan Generator is a custom FlightGear logger. Simply start FG with the logger, using the --generic=file,out,0.1,path/to/flightplan/file,dgrecord2 command. If you have named the logger something other than dgrecord2, then subsitute the actual name for dgrecord2. This won’t work in FGRun’s interface, so just tack it on to the executable line, being sure to add a space between the executable and the command. Then, just fly the flight you want the AI aircraft to fly. Once finished, close FG, and check the flightplan file. You will find your once blank file is suddenly filled with all the necessary data, plus some useless data points. You will need to trim off the waypoints with KTAS < 10 so that your AI model can get off the ground in some reasonable amount of time. Both tools can be found at the Official FlightGear Forum.

http://forum.flightgear.org/viewtopic.php?f=23&t=9151&hilit=Oscar%E2%80%99s+Flightplan+Generator

http://oscar.bouwmans.name/FlightGear/aiscenario/

==Common Issues ==
I believe I have created the flightplan correctly, yet, when I run the scenario, the plane doesn’t follow the route as expected.
There are a few possible reasons for this.

1. AI scenarios are flown with turn anticipation. Therefore, the aircraft will rarely fly all the way to the waypoint, especially if it’s at a turning point. You may want to adjust for this by setting the entry point of the turn a little late. You can do this by changing the coordinates of the problem waypoint.

2. Is your plane doing flat loops? Perhaps you have set your waypoints too close together. The AI aircraft in the scenario always goes from the first waypoint to the next nearest waypoint, regardless of what order you put your waypoints in. Therefore, it’s important that you avoid making circles or any kind of flight that starts and ends at roughly the same location.

3. Another possibility is that you are expecting the aircraft to turn tighter than the AI scenario will allow it to turn. Write your flightplans to use gentle turns to correct this, or a slower speed.

== Related content ==
* [[Status of AI in FlightGear]]

[[Category:Artificial intelligence]]

Canvas Nasal API

2023-09-28T13:45:05Z

Necolatis: Add del() function to element

{{Template:Canvas Navigation}}

Canvas consist of a class with various nestable classes (elements).

See inside the current (Git) API {{fgdata source|Nasal/canvas/api.nas|text=here}} and {{simgear source|simgear/canvas/|text=here}}.

'''For the Canvas GUI API see [[Canvas GUI API]]'''

== Canvas ==
For constructor see: [[Howto:Add_a_2D_canvas_instrument_to_your_aircraft#Initialize_a_Canvas|Initialize a Canvas]]
=== addPlacement ===
{{Note|It is possible to place a canvas on models in the scene. Tom has not tested if it also works for MP/AI aircraft but it should. The placement in scenery objects needs a different placement type to select also the model it should be placed on. For scenery objects a special placement exists:
<syntaxhighlight lang="nasal">
var placement = { "module-id": _module_id, type: "scenery-object", <normal placement parameters like eg. node> }</syntaxhighlight>
'_module_id' is a special variable which is only set in scenery object <load> handlers.<ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/35093833/
|title = <nowiki> Re: [Flightgear-devel] Canvas in dynamically loaded scene models </nowiki>
|author = <nowiki> Thomas Geymayer </nowiki>
|date = May 17th, 2016
|added = May 17th, 2016
|script_version = 0.40
}}</ref>
}}

See: [[Howto:Add_a_2D_canvas_instrument_to_your_aircraft#Place_it_somewhere_on_your_aircraft|Place a Canvas]]

=== setColorBackground ===
'''Parameters:''' (r, g, b, a)

Fills the background of the entire canvas with the supplied color.
=== createGroup ===
'''Parameters:''' ()

'''Parameters:''' (name)

'''Returns:''' Group

Create a new group under this Canvas. Supplying name is optional.
=== getPath ===
'''Parameters:''' ()

?
=== del ===
'''Parameters:''' ()

Deletes this Canvas.
=== wrapCanvas ===
'''Parameters:''' ()

?
=== get ===
'''Parameters:''' (name)

'''Returns:''' Canvas

Returns the canvas with the specified name.

Possible settings

* character-size - font size
* character-aspect-ratio - font aspect ratio
* ... please contribute and expand this list!

=== set ===
'''Parameters:''' (setting, value)

Not sure all the below settings can be used after initialization.

Settings can be:

"name" string

"size" vector of size 2 with ints

"view" vector of size 2 with ints

"mipmapping" bool

"additive-blend" bool

"coverage-samples" int

"color-samples" int

"freeze" bool

"render-always" bool

"update" bool

=== parsesvg ===
'''Parameters:''' (group, file)

'''Parameters:''' (group, file, font-mapper)

See: [[Howto:Use_SVG_inside_a_Canvas|SVG inside a Canvas]]
== Element ==
Note that in each element there are 2 transformation matrices. The first will be applied first, then the second.

=== set ===
'''Parameters:''' (key, value)

''Key = "z-index":''

Default value = 0

Minimum value = 0

Integer value indicates the explicit Z sort order, highest on top. If this is not set, elements that are added later gets drawn on top.
Notice that if you have for example two paths inside their own groups, and you want to order those paths in relation to each other, its on their groups you should call this method, not on the paths themselves.

FG 2.10.0.3: Elements added after z-index has been set will overrule it. (fix is in GIT)

''Key = "blend-source":''

''Key = "blend-destination":''

''Key = "blend-source-rgb":''

''Key = "blend-destination-rgb":''

''Key = "blend-source-alpha":''

''Key = "blend-destination-alpha":''

These are blending operations, they determine how a texel is drawn based on what your current element want to draw (source) and what is already drawn at this texel (destination).

For example for the 2 first listed keys, the formula is ''output_color = (blend_source * src_color) + (blend_destination * dst_color).''

The value for the keys can be one of: (string)

''zero, one, dst-color, src-color, one-minus-dst-color, one-minus-src-color, src-alpha, dst-alpha, one-minus-dst-alpha, one-minus-src-alpha, src-alpha-saturate''

You can see the formulas [[https://web.cs.ship.edu/~djmoon/cg/cg-notes/cg-ogl-blending.pdf here]]

With a little creativity these can be used for many things, like creating custom clipping geometry and other stuff.

NOTICE: Blending does NOT work for paths. They are confirmed to work with text and images though.

=== update ===
'''Parameters:''' ()

Normally an element gets updated in the next frame. Calling this will make it update in the current frame.
Note that visibility methods do get updated in the current frame.
=== getVisible ===
'''Parameters:''' ()

'''Returns:''' visible

Returns 0 if not visible, 1 if visible.
=== setVisible ===
'''Parameters:''' ()

'''Parameters:''' (visible)

Sets if this element should be visible. 0 sets it not visible, 1 visible. No parameters sets it visible.
=== show ===
'''Parameters:''' ()

Sets the element visible.
=== hide ===
'''Parameters:''' ()

Sets the element not visible.
=== toggleVisibility ===
'''Parameters:''' ()

Toggles if element should be visible.
=== setGeoPosition ===
'''Parameters:''' (lat, lon)

Sets the geographic coordinates for a map element. Parent element must be of type "map".

'''Example:''' setGeoPosition(37.615223, -122.389978)

Places element at [[San Francisco International Airport]].

=== createTransform ===
createTransform creates a new matrix on top of the existing matrix stack. A while ago I've added an example for a HUD built using the Canvas to the wiki: [[Canvas HUD]]
It doesn't use SVG but manually creates everything instead. As loading an SVG should basically do the same than handcrafting icons there shouldn't be much of a difference.

'''Parameters:''' ()

'''Parameters:''' ([a, b, c, d, e, f])

'''Return:''' The new (second) transform

Creates a new (second) transformation matrix for this element. No parameters will create a default identity matrix transform. Otherwise supply a 6 element vector for the matrix:

{| class="wikitable"
|-
| a || b || c
|-
| d || e || f
|-
| 0 || 0 || 1
|}

You should probably change the order of creating the transforms for pitch and roll as normally one would rotate first and then move according to roll and then move according to pitch up and down. Keep in mind that rotations always happens around the origin of the local coordinate frame of the object being rotated. For a rotation around another point you would need to move the object first until the center coincides with the local origin then rotate and afterwards move back. Instead of applying three transformations there exists a shortcut to pass the center of rotation as second argument to setRotation.

To further shorten the code an especially to allow rotating objects imported from SVG there exists setRotation also for canvas Elements (not only Transformation) and additionally setCenter which instead of passing the center as an argument sets the center which is being used while calling setRotation on this element. setCenter only affects setRotation of this not object but not for any matrix added with createTransform. If you set the center of rotation in Inkscape (switch to rotate mode and drag the cross to the center of rotation) it is automatically loaded with setCenter so you just need to call setRotation and automatically get a rotation around the correct center.

You don't need to care about tf[0] being reserved as it only reserves the index 0 and doesn't affect anything if not used. createTransform creates a new matrix with the next unused index starting at 1 (0 is reserved). If you later call setRotation directly on an element a new Transform will be created but this time using tf[0] to ensure it is applied before all other matrices and therefore rotating the object around its own center before being moved around.

For the HUD I'd set the rotation center correctly inside Inkscape and later on just call ladder.setRotation to rotate for changes in the roll angle. Afterwards create a Transform and use setTranslate for changes in pitch angle.

=== setTranslation ===
'''Parameters:''' (x, y)

Translates the element. The translation is set on the second transform.
=== setRotation ===
'''Parameters:''' (x, y)

Rotates the element around the center. The rotation is set on the first transform.

setRotation really just combines a rotation with two translations -> translate(-center[0], -center[1]) * rotate * translate(center[0], center[1])

You can also have a look in the property browser and check the bounding box (/canvas/by-index/texture[i]/[group[j]+]/path[j]/bounding-box) and use its coordinates to determine the correct center of rotation.

=== setScale ===
'''Parameters:''' (x, y)

Scales the element. The scale is set on the second transform.
=== getScale ===
'''Parameters:''' ()

'''Return:''' 2 element vector [x,y]

Returns the scale of this element.
=== setColorFill ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Sets the color/alpha to be used as fill value. If you do not want the element to be filled, do not call this method.
=== getBoundingBox ===
'''Parameters:''' ()

'''Returns:''' [minX, minY, maxX, maxY]

Returns the bounds of the element.
=== updateCenter ===
'''Parameters:''' ()

Sets the center to be the center of the boundingbox in relation to the elements position in its parent.
=== setCenter ===
'''Parameters:''' (x, y)

Sets the center of the element that is used for rotation.
=== getCenter ===
'''Parameters:''' ()

Gets the center of the element.
=== del ===
'''Parameters:''' ()

Deletes this element.

== Group ==
Inherits from Element.
=== set ===
'''Parameters:''' (key, value)

''key = "clip"''
{{Note|
{{FGCquote
|1= Scaling or any other type of transformation or changing the coordinates of individual points is definitely more efficient than clipping (which requires to change the OpenGL clip planes for every rendered object with a different clipping rectangle).
|2= {{cite web
| url = http://forum.flightgear.org/viewtopic.php?p=277062#p277062
| title = <nowiki>Re: Space Shuttle</nowiki>
| author = <nowiki>TheTom</nowiki>
| date = Feb 21st, 2016
| added = Feb 21st, 2016
| script_version = 0.25
}}
}}
}}

Makes a clipping bounds for the group, only what is inside the clipping bounds will be shown.

It uses same coordinate format as [http://www.w3.org/TR/CSS21/visufx.html#clipping Clipping]

'''Example:''' my_grp.set("clip", "rect(62px, 587px, 262px, 437px)"); # top,right,bottom,left

''key = "clip-frame"''

Sets the coordinate system to be used for clip coordinates.

Can be canvas.Element.GLOBAL (the default value), canvas.Element.PARENT or canvas.Element.LOCAL

Notice that if set to local or parent and there is a rotation is play, the clipping wont rotate properly, it will move around and scale instead.

''key = "font"''

Sets the default font.

'''Example:''' my_group.set("font", "LiberationFonts/LiberationMono-Regular.ttf");

''key = "stroke"''

?

''key = "fill"''

?

=== setDouble ===
'''Parameters:''' (key, value)

''key = "character-aspect-ration"''

?

''key = "character-size"''

?

=== createChild ===
'''Parameters:''' (type)

'''Parameters:''' (type, name)

'''Returns:''' Element

Creates a child element under this Group. Name can be supplied. Type can be "text", "group", "path", "image", "map".
Return an Element of the particular type specified.
=== createChildren ===
'''Parameters:''' (type, count)

'''Returns:''' [Element]

Creates a number of child elements under this Group. Return a vector of Elements of the particular type specified.
=== getChildren ===
'''Parameters:''' ()

'''Returns:''' [Element]

Returns all the child elements of this group.
=== getElementById ===
'''Parameters:''' (name)

'''Returns:''' Element

Returns the first found child element with the specified name.
=== removeAllChildren ===
'''Parameters:''' ()

Removes all the child elements from this group.

== Text ==
Inherits from Element.

=== enableUpdate ===

Enables the updateText() method for a text element.

=== setText ===
'''Parameters:''' (text)

Sets the text to be displayed.

=== updateText ===
'''Parameters:''' (text)

The setText method internally writes the text string into a property node. If the method is run inside an update loop (as usually done for displays), setText writes the property regardless of whether the text has actually changed in the last update cycle. For complicated displays, this may cause a lot of unnecessary property I/O slowing down the simulation.

To improve this, updateText() keeps a Nasal variable record of the last text that has been written and writes the property only if the text has changed. Since this record needs to be allocated, the method requires to call enableUpdate() once before using it.

Note also that updateText() and setText() should not be both used on the same text element (updateText() will not register any changes made to the property string by any other means).

=== setAlignment ===
'''Parameters:''' (alignment)

Sets how the text should be aligned with its position.

Full list:
* left-top
* left-center
* left-bottom
* center-top
* center-center
* center-bottom
* right-top
* right-center
* right-bottom
* left-baseline
* center-baseline
* right-baseline
* left-bottom-baseline
* center-bottom-baseline
* right-bottom-baseline

=== setFontSize ===
'''Parameters:''' (size, aspectRatio)

Sets the size and aspectRatio of the font. AspectRatio is the Ratio between character height and width. Default aspectRatio is 1.
=== setFont ===
'''Parameters:''' (fontName)

Sets the font to be used. See [[$FG_ROOT]]/Fonts for list of fonts.

=== setDrawMode ===
'''Parameters:''' (mode)

Sets the drawing mode. You can use the values below and add those you need.

'''Text.TEXT:''' Draws the text

'''Text.BOUNDINGBOX:''' Draws the boundingbox

'''Text.FILLEDBOUNDINGBOX:''' Draws the filled boundingbox

'''Text.ALIGNMENT:''' Draws a cross where the element position is

'''Example:''' my_text.setDrawMode(Text.TEXT + Text.BOUNDINGBOX);
=== setPadding ===
Sets bounding box padding

=== setMaxWidth ===
?
=== setColor ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Sets the color the text should be drawn in.
=== setColorFill ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Sets the color the text background should be drawn in.

== Path ==
Inherits from Element.

A path is similar to drawing with a pen on paper. The move and moveTo methods represent lifting the pen from the paper and moving to a new position. The drawing methods like lineTo would then be seen as starting from the current position of the pen. Therefore offcouse the order the methods is called in, is important.
=== pop_front ===
'''Parameters:''' ()

Remove first segment
=== pop_back ===
'''Parameters:''' ()

Remove last segment
=== getNumSegments ===
'''Parameters:''' ()

Get the number of segments
=== reset ===
'''Parameters:''' ()

Remove all existing path data
=== moveTo ===
'''Parameters:''' (x, y)

Moves the position to an new absolute position.
=== move ===
'''Parameters:''' (x, y)

Moves the position to a new relative position from the current.
=== lineTo ===
'''Parameters:''' (x, y)

Draws a line to specified position.
=== line ===
'''Parameters:''' (x, y)

Draws a line to specified relative position.
=== horizTo ===
'''Parameters:''' (x)

Draws a horizontal line to specified position.
=== horiz ===
'''Parameters:''' (x)

Draws a horizontal line to specified relative position.
=== vertTo ===
'''Parameters:''' (y)

Draws a vertical line to specified position.
=== vert ===
'''Parameters:''' (y)

Draws a vertical line to specified relative position.
=== quadTo ===
'''Parameters:''' (x0, y0, x1, y1)

Draws quadratic Bézier curve.
=== quad ===
'''Parameters:''' (x0, y0, x1, y1)

Draws quadratic Bézier curve. Relative coordinates.
=== squadTo ===
'''Parameters:''' (x, y)

Draws smooth quadratic Bézier curve.
=== squad ===
'''Parameters:''' (x, y)

Draws smooth quadratic Bézier curve. Relative coordinates.
=== cubicTo ===
'''Parameters:''' (x0, y0, x1, y1, x2, y2)

Draws cubic Bézier curve.
=== cubic ===
'''Parameters:''' (x0, y0, x1, y1, x2, y2)

Draws cubic Bézier curve. Relative coordinates.
=== scubicTo ===
'''Parameters:''' (x, y, x2, y2)

Add a smooth cubic Bézier curve
=== scubic ===
'''Parameters:''' (x, y)

Add a smooth cubic Bézier curve. Relative coordinates.
=== rect ===
'''Parameters:''' (x, y, w, h, cfg = nil)

cfg: Optional settings (eg. {"border-top-radius": 5}, {"border-bottom-radius": 5}, {"border-radius": 5}, {"border-bottom-right-radius": 5} or {"border-left-radius": 5})

Add a (rounded) rectangle to the path

=== square ===
''' available on next, expected release 2019.1 '''

'''Parameters:''' (x, y, length, cfg = nil)

alias for rect(x, y, length, length, cfg)

Add a (rounded) square to the path

=== arcSmallCCWTo ===
=== arcSmallCCW ===
=== arcSmallCWTo ===
=== arcSmallCW ===
'''Parameters:''' (xRadius, yRadius,0,xEnd,yEnd)

Draws an arc with the specified radii, up to the specified end point. The end point is relative to the starting point.

To draw half a circle with radius 20 around the origin:
.moveTo(-20,0)
.arcSmallCW(20,20,0,40,0);

To draw a circle with radius 20 around the origin:
.moveTo(-20,0)
.arcSmallCW(20,20,0,40,0)
.arcSmallCW(20,20,0,-40,0);

=== arcLargeCCWTo ===
=== arcLargeCCW ===
=== arcLargeCWTo ===
=== arcLargeCW ===

Drawing arcs examples :
[[File:Canvas arc.png|thumb|Canvas arc draw examples]]
<syntaxhighlight lang="nasal">
var fpv = group.createChild("group", "FPV");

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,255,1)")
.moveTo(100, 100).arcSmallCCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4) .set("stroke", "rgba(255,0,255,1)")
.moveTo(300, 100).arcSmallCCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,255,1)")
.moveTo(500, 100).arcSmallCCW(50, 50, 0, 50, -50);

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(55,0,255,1)")
.moveTo(100, 300).arcSmallCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(55,0,255,1)")
.moveTo(300, 300).arcSmallCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(55,0,255,1)")
.moveTo(500, 300).arcSmallCW(50, 50, 0, 50, -50);

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(100, 500).arcLargeCCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(300, 500).arcLargeCCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(500, 500).arcLargeCCW(50, 50, 0, 50, -50);

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(100, 500).arcLargeCCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(300, 500).arcLargeCCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(500, 500).arcLargeCCW(50, 50, 0, 50, -50);

fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(100, 700).arcLargeCW(50, 50, 0, 50, 50);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,55,1)")
.moveTo(300, 700).arcLargeCW(50, 50, 0, 100, 0);
fpv.createChild("path").setStrokeLineWidth(4).set("stroke", "rgba(255,0,5
</syntaxhighlight>

=== ellipse ===
''' available on next, expected release 2019.1 '''

'''Parameters:''' (rx, ry, cx = nil, cy = nil)

rx, ry are the radii of the ellipse
cx, cy is optional for the center coordinates

Add an ellipse to the path

=== circle ===
''' available on next, expected release 2019.1 '''

'''Parameters:''' (r, cx, cy)

alias for ellipse(r, r, cx, cy), cx, cy optional for center coordinates

Add a circle to the path.

=== close ===
'''Parameters:''' ()

Close the path (implicit lineTo to first point of path)
=== setColor ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Sets the color of the drawn path
=== setColorFill ===
'''Parameters:''' (r, g, b)

'''Parameters:''' (r, g, b, a)

Calling this will make the path get filled in the specified color. For example if you draw a 'V' and fill it, the fill area will be a triangle inside the 'V'.
=== setStrokeLineWidth ===
'''Parameters:''' (width)

The width of the path.
=== setStrokeLineJoin ===
'''Parameters:''' (type)

Set stroke linejoin. Type can be "miter", "round" or "bevel".

[[File:Stroke join.png|Canvas stroke join]]

=== setStrokeLineCap ===
'''Parameters:''' (type)

Caps the path. Type can be "butt", "round" or "square".

[[File:Stroke cap.png|Canvas stroke cap]]

=== setStrokeDashArray ===
'''Parameters:''' (pattern)

Make dashed path. Pattern is a vector of alternating dash and gap lengths. Lines drawn will follow this pattern.

'''Example:''' my_path.setStrokeDashArray([10, 20, 10, 20, 10]);

=== setData ===

'''Parameters:''' (cmds, points)

Re-sets the data structure for a plot. cmds is an array containing the draw commands (integers, but they can be referenced via canvas.Path.VG_LINE_TO or canvas.Path.VG_MOVE_TO etc.) and points an array containing the associated points to which the curve is to be drawn in the form [x1, y1, x2, y2,...].

'''Example:''' my_path.setData([2, 4], [10, 20, 10, 40]);

See addSegment for list of commands.

=== setDataGeo ===
'''Parameters:''' (cmds, points)

Same as setData(), just for GPS coords. See addSegmentGeo() for details.

Parent element must be of type "map".

=== addSegment ===
'''Parameters:''' (cmd, coords)

Add a path segment.

Cmd can for example be canvas.Path.VG_MOVE_TO

Coords is a vector with the numbers/coordinates that the command needs.

See this list of all commands and how many coords they require.

VG_CLOSE_PATH: 0,
VG_MOVE_TO: 2,
VG_MOVE_TO_ABS: 2,
VG_MOVE_TO_REL: 2,
VG_LINE_TO: 2,
VG_LINE_TO_ABS: 2,
VG_LINE_TO_REL: 2,
VG_HLINE_TO: 1,
VG_HLINE_TO_ABS: 1,
VG_HLINE_TO_REL: 1,
VG_VLINE_TO: 1,
VG_VLINE_TO_ABS: 1,
VG_VLINE_TO_REL: 1,
VG_QUAD_TO: 4,
VG_QUAD_TO_ABS: 4,
VG_QUAD_TO_REL: 4,
VG_CUBIC_TO: 6,
VG_CUBIC_TO_ABS: 6,
VG_CUBIC_TO_REL: 6,
VG_SQUAD_TO: 2,
VG_SQUAD_TO_ABS: 2,
VG_SQUAD_TO_REL: 2,
VG_SCUBIC_TO: 4,
VG_SCUBIC_TO_ABS: 4,
VG_SCUBIC_TO_REL: 4,
VG_SCCWARC_TO: 5,
VG_SCCWARC_TO_ABS: 5,
VG_SCCWARC_TO_REL: 5,
VG_SCWARC_TO: 5,
VG_SCWARC_TO_ABS: 5,
VG_SCWARC_TO_REL: 5,
VG_LCCWARC_TO: 5,
VG_LCCWARC_TO_ABS: 5,
VG_LCCWARC_TO_REL: 5,
VG_LCWARC_TO: 5,
VG_LCWARC_TO_ABS: 5,
VG_LCWARC_TO_REL: 5,

=== addSegmentGeo ===
'''Parameters:''' (cmd, coords)

Add a path segment.

Cmd can for example be canvas.Path.VG_MOVE_TO

Coords is a vector with the numbers/coordinates that the command needs in GPS format.

The coords can for example be "E32.45" for latitude and "N45.34" for longitude. If an 'S' or 'W' is seen instead of E or N, the sign is flipped.

See addSegment for list of commands.

Parent element must be of type "map".

== Map ==
Inherits from Element.

Class for a group element on a canvas with possibly geographic positions which automatically get projected according to the specified projection.
Each map consists of an arbitrary number of layers (canvas groups)
=== del ===
'''Parameters:''' ()

Deletes the Map instance.
=== setController ===
'''Parameters:''' (controller)

A controller needs to inherit from Map.Controller
=== addLayer ===
'''Parameters:''' (factory, type_arg=nil, priority=nil, style=nil, opts=nil, visible=1)

Each layer is some kind of data to be rendered - there’s all the built in layers but WXR, TERRain or anything else specific to the acft would be another layer.
=== getLayer ===
'''Parameters:''' (type_arg)

Returns the layer corresponding to the argument type.
=== setRange ===
'''Parameters:''' (range)

This sets the display range of the map in NM.
=== getRange ===
'''Parameters:''' ()

Get current range setting
=== setPos ===
'''Parameters:''' (lat, lon, hdg=nil, range=nil, alt=nil)

This is the center of the map (very often the aircraft position, except in something special such as PLAN mode). Hdg sets the up direction (could be north, track, heading and true vs magnetic depending on the aircraft)

=== getPos ===
'''Parameters:''' ()

Returns vector with lat, lon, heading, range and altitude
=== getLat ===
'''Parameters:''' ()

Returns position latitude.
=== getLon ===
'''Parameters:''' ()

Returns position longitude.
=== getHdg ===
'''Parameters:''' ()

Return current 'up' heading.
=== getAlt ===
'''Parameters:''' ()

Returns current altitude setting in feet.
=== getRange ===
'''Parameters:''' ()

Returns current range setting.
=== getLatLon ===
'''Parameters:''' ()

Returns the center position of the map as a vector with lat and lon
=== getPosCoord ===
'''Parameters:''' ()

Returns the center position of the map as a geo.Coord

N.B.: This always returns the same geo.Coord object,
so its values can and will change at any time (call
update() on the coord to ensure it is up-to-date,
which basically calls this method again).
=== update ===
'''Parameters:''' (predicate=nil)

Update each layer on this Map. Predicate is a function that takes a layer as argument and returns true if that layer should be updated. If predicate is not supplied, all layers will be updated.
=== See also ===
[[Canvas_Maps|Canvas Maps]] and [[Canvas_Map_API|Canvas Map API]]

== Image ==
Inherits from Element.

See: [[Canvas_Image|Canvas Image]]

Howto:Activate multi core and multi GPU support

2023-09-21T12:15:41Z

Necolatis: /* Related content */

FlightGear supports a number of different threading modes to make use of multiple CPUs or GPUs, this applies mostly to high-end multi-core or multi-GPU, multi-screen (or multi-window) setups and may improve performance (see [[Howto: Configure camera view windows]]).

{{DeQuote}}
{{Multicore}}

== Selecting threading modes ==
{{Note|Beginning with FlightGear 3.0, you should be careful when changing the default OSG threading settings, as enabling multi-threading seems to be an increasingly reliable way to trigger race conditions/segfaults (crashes). Also see {{Issue|1393}} and [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/53374444.8040304%40t3r.de/#msg32162794]
{{FGCquote
|the aforementioned threading related directives are only relevant at the OSG/rendering level, i.e. will only tell the underlying OpenSceneGraph implementation to try to do certain tasks "concurrently", for a more detailed explanation, please refer to: [[Howto:Use_the_system_monitor]]
|{{cite web |url={{forum url|p=231703}}
|title=<nowiki>Re: Multiprocessor Support</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sun Feb 08</nowiki>
}}
}}

{{FGCquote
| OSG threading support is largely specific to offloading '''rendering-related''' computations (i.e. culling) to different threads, it will NOT directly help conventional FlightGear subsystems runing in the main loop, not without explicit coding - i.e. multi-threading or multi-processing and IPC.
|{{cite web |url={{forum url|p=153269}}
|title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Mar 15</nowiki>
}}
}}

{{FGCquote
|OSG threading is neat and dandy, but obviously it is only directly useful for rendering related parallelization and related work. On the other hand, none of this comes for free. OSG's threading support really is impressive, but all those OSG threads must be kept busy. Properly. That's exactly the work that FlightGear is responsible for in its main loop.
OSG's multithreading support doesn't just come "automagically", just because FlightGear uses OSG.
The multithreading support in OSG must be explicitly supported by following certain OSG coding patterns and coding protocols. Otherwise, you won't benefit at all.<br/>
Obviously, OSG really is extremely powerful and also pretty good at parallelizing things, but you cannot necessarily see that when running FlightGear, but there is other OSG-based software which is making really good use of this.
|{{cite web |url={{forum url|p=153295}}
|title=<nowiki>Re: [SUGGESTION] Multi-core FlightGear support</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Thu Mar 15</nowiki>
}}
}}

{{FGCquote
|Even distribution across the cores doesn't in itself indicate that a process is using multiple threads. The operating system will switch tasks between cores for even temperature distribution, even with a single-threaded program.
The indication that a program is multi-threaded is when the overall usage of the program goes above the capacity of one core. For that to happen it must have different threads running on different cores at the same time.
|{{cite web |url={{forum url|p=231646}}
|title=<nowiki>Re: Multiprocessor Support</nowiki>
|author=<nowiki>sanhozay</nowiki>
|date=<nowiki>Sun Feb 08</nowiki>
}}

}}}}

{{Caution|
{{FGCquote
|In my preferences.xml I have:<br/>
<syntaxhighlight lang="xml">
<multithreading-mode> AutomaticSelection </multithreading-mode>
</syntaxhighlight>
With OSG2 this worked and I could see fgfs using CPU cycles on both CPU cores. This did increase frame rates compared to single threading but only by perhaps 25% on average but it also seemed to improve frames rates even more under condidtions that would result in lower frames rates. With OSG3 this does not happen and it appears to only be single threaded.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/27776273/
|title=<nowiki>[Flightgear-devel] OSG3 frame rates and multithreading</nowiki>
|author=<nowiki>Hal V. Engel</nowiki>
|date=<nowiki>2011-07-10</nowiki>
}}
}}

{{FGCquote
|I [used to be] able to run FlightGear with osg multithreading mode set to AutomaticSelection on my presentation machine with five graphic cards and ten monitors attached and a dozen or so cameras configured. For some reason, that is no longer possible and I get a core dump sooner or later.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32162794/
|title=<nowiki>[Flightgear-devel] osg multithreading crashes</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-03-29</nowiki>
}}
}}

{{FGCquote
|Only of 1 out of 10 sessions crashed, here is the only dump I was able to produce.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32168368/
|title=<nowiki>Re: [Flightgear-devel] osg multithreading crashes</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-03-31</nowiki>
}}
}}

{{FGCquote
|When I run FlightGear with multiple screens and multiple cameras, the highes threading mode for OpenSceneGraph that works reliable is '''CullDrawThreadPerContext''' while the '''CullThreadPerCameraDrawThreadPerContext''' quickly leads to a crash.
You can set the osg threading model upon startup with '''--prop:/sim/rendering/multithreading-mode{{=}}CullDrawThreadPerContext'''
If it still does not work, try DrawThreadPerContext or even SingleThreaded and see if this helps.
|{{cite web |url={{forum url|p=228282}}
|title=<nowiki>Re: Error when trying to run FlightGear with three monitors</nowiki>
|author=<nowiki>Torsten</nowiki>
|date=<nowiki>Sun Dec 28</nowiki>
}}
}}
{{FGCquote
|1= My sense is that most of our crashes seem to come from newer code or threading issues.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34679412/
| title = <nowiki>Re: [Flightgear-devel] Reactivation of the UIUC, LaRCsim,
and special purpose FDMs by default.</nowiki>
| author = <nowiki>Curtis Olson</nowiki>
| date = Dec 8th, 2015
| added = Dec 8th, 2015
| script_version = 0.23
}}
}}
{{FGCquote
|1=<code>--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext</code> never worked for me with multiscreen/multicamera setups. It always crashed within a few seconds. It's a known issue, It should not bite you with a single camera, but I would not bet on it.
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34870630/
| title = <nowiki>Re: [Flightgear-devel] 2016.2.0 long-term testing (was: memory
leaks - long term testing - pre-2016.2.0)</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Feb 21st, 2016
| added = Feb 21st, 2016
| script_version = 0.25
}}
}}

{{FGCquote
|1= if you use the default screen configuration there is just one window and one camera. In that case, CullThreadPerCamera results in one thread (just one camera) and you effectively run as CullDrawThreadPerContext. You can configure more than one camera on a single screen an in that case the above will bite
|2= {{cite web
| url = http://sourceforge.net/p/flightgear/mailman/message/34870695/
| title = <nowiki>Re: [Flightgear-devel] 2016.2.0 long-term testing</nowiki>
| author = <nowiki>Torsten Dreyer</nowiki>
| date = Feb 21st, 2016
| added = Feb 21st, 2016
| script_version = 0.25
}}
}}

}}

There is a property supported named '''/sim/rendering/multithreading-mode''' this can be set either in the preferences.xml file located in the flightgear data folder (base package: [[$FG_ROOT]]) or by using the '''--prop:/sim/rendering/multithreading-mode=...''' parameter from the console (or fgrun) this affects directly the osgviewer threading mode, supported values are:

* AutomaticSelection
* CullDrawThreadPerContext
* DrawThreadPerContext
* CullThreadPerCameraDrawThreadPerContext

Further information on threading modes can be found here: http://www.mail-archive.com/osg-users@openscenegraph.net/msg09620.html and here: http://www.mail-archive.com/osg-users@openscenegraph.net/msg09611.html

To set this in a separate XML file, just include it from preferences.xml (toplevel PropertyList node):

threadingmode.xml:

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<sim>
<rendering>
<multithreading-mode>AutomaticSelection</multithreading-mode>
</rendering>
</sim>
</PropertyList>
</syntaxhighlight>

This property must be set during initialization, modifying it at runtime has no effect.

Multithreading modes allocate two instances of OpenGL resources to speed up rendering .
Default implicit buffer attachment policy adds depth buffer to FBOs if only color buffer was attached.

if you have a single graphics card, having a thread per camera (each one with a graphics context) doesn't necessarily improve the performance, what is more, it can degrade it. The reason is that each thread will be competing for the graphics card, which is an exclusive resource, and the driver is forced to perform many context switchs. If you are using multiple graphics contexts then by default the OSG/OpenGL will be creating OpenGL objects (like textures) on a per context basis. So one osg::Texture in the scene graph even if it's rendered on two contexts you'll have two separate TextureObjects/OpenGL texture objects.

== Related content ==
* [[ThreadCPUAffinities]]
* {{forum url|p=69706}}
* http://www.mail-archive.com/osg-users@openscenegraph.net/msg09620.html
* http://www.opensubscriber.com/message/flightgear-devel@lists.sourceforge.net/14221108.html
* {{forum url|t=8890}}
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg19265.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg18808.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29272.html
* http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg29519.html

[[Category:Howto|Activate multi core and multi GPU support]]

ExtraViewWindows

2023-09-05T06:43:46Z

Necolatis: /* exmaple */

[[File:Fg-cv-textures2.jpeg|thumb|Multiple top level windows in CompositeViewer]]

== Overview ==

On next, there's support for Extra View windows. These are top-level windows that show views independently from the main window's view. These use a new view system called '''Sview''' (short for "Step View") along with [[CompositeViewer Support]].

The simplest way to create an extra view window is from menu '''View/Add Clone View''' which, as the name implies, will create a new window that is a clone of the current view. Changing the main window's view will leave the new window's view unchanged.

== Viewing pairs of aircraft ==

There is a slightly crude mechanism for creating views that work on pairs of aircraft: one uses menu '''View/Push Pair View''' to push the current main-window view onto a stack of views.

Once this has been done at two or more times, menu '''View/Add Pair View''' will open a new top-level window showing a view derived from the last two remembered viewpoints. So for example it can show the view of your aircraft from a particular multiplayer aircraft, or a view of the nearest tower from your aircraft.

Menu '''View/Add Pair Foreground View''' is similar but it keeps the first viewpoint at a fixed distance in the foreground and the second viewpoint in the background. This works well when flying in formation.

== Limitations ==

As of '''2021-10-25''':

* Extra View windows can be panned like the main window by dragging with the left mouse button.
* Other UI interations is not supported:
** Mouse clicks are ignord.
** Key presses are ignored.

== Specifying views in more detail ==

One can specify views explicitly with the <code>view-new</code> command, which accepts an Sview specification in the form of an accompanying XML tree.

For details of the XML format, see the comments in: {{flightgear file|src/Viewer/sview.hxx}}

== How Sview works ==

Sview works by constructing camera's eye and target positions/directions using an arbitrary number of individual configurable steps. There are various step types defined which allow for various transformations such as moving to a particular user/multiplayer aircraft or nearest tower, move relative to the current position+direction, modify heading, pitch and roll according to particular property values, rotate view direction to point at a particular target etc.

These basic steps are enough to allow Sview to copy what conventional views do, allowing the '''View/Add clone view''' menu item to work.

It's also easy enough to add (C++) code to implement new steps to achieve more sophisticated behaviour. An example of this is the view step called '''double''' that keeps two aircraft visible at all times, with one in the foreground; this is used for '''View/Add Pair Foreground View'''.

For more details, see the C++ Sview code itself: {{flightgear file|src/Viewer/sview.cxx}}

== Example ==
This example will work with F-16. It will place a small window in lower-right corner of a 1920x1080 FG window.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>
<window-width>400</window-width>
<window-height>400</window-height>
<window-x>1520</window-x>
<window-y>0</window-y>
<type>sview</type>
<name>step-dancer</name>

<step n="0"> 
<type>aircraft</type>
<callsign></callsign>
</step>


<step n="1">
<type>move</type>
<right>0</right>
<up>-0.83</up>
<forward>4.40</forward>
</step>
</PropertyList>
</syntaxhighlight>

== Related content ==
=== Wiki articles ===
* [[Configuring View Windows]]
* [[SView]]

ExtraViewWindows

2023-09-05T06:34:19Z

Necolatis: /* How Sview works */

[[File:Fg-cv-textures2.jpeg|thumb|Multiple top level windows in CompositeViewer]]

== Overview ==

On next, there's support for Extra View windows. These are top-level windows that show views independently from the main window's view. These use a new view system called '''Sview''' (short for "Step View") along with [[CompositeViewer Support]].

The simplest way to create an extra view window is from menu '''View/Add Clone View''' which, as the name implies, will create a new window that is a clone of the current view. Changing the main window's view will leave the new window's view unchanged.

== Viewing pairs of aircraft ==

There is a slightly crude mechanism for creating views that work on pairs of aircraft: one uses menu '''View/Push Pair View''' to push the current main-window view onto a stack of views.

Once this has been done at two or more times, menu '''View/Add Pair View''' will open a new top-level window showing a view derived from the last two remembered viewpoints. So for example it can show the view of your aircraft from a particular multiplayer aircraft, or a view of the nearest tower from your aircraft.

Menu '''View/Add Pair Foreground View''' is similar but it keeps the first viewpoint at a fixed distance in the foreground and the second viewpoint in the background. This works well when flying in formation.

== Limitations ==

As of '''2021-10-25''':

* Extra View windows can be panned like the main window by dragging with the left mouse button.
* Other UI interations is not supported:
** Mouse clicks are ignord.
** Key presses are ignored.

== Specifying views in more detail ==

One can specify views explicitly with the <code>view-new</code> command, which accepts an Sview specification in the form of an accompanying XML tree.

For details of the XML format, see the comments in: {{flightgear file|src/Viewer/sview.hxx}}

== How Sview works ==

Sview works by constructing camera's eye and target positions/directions using an arbitrary number of individual configurable steps. There are various step types defined which allow for various transformations such as moving to a particular user/multiplayer aircraft or nearest tower, move relative to the current position+direction, modify heading, pitch and roll according to particular property values, rotate view direction to point at a particular target etc.

These basic steps are enough to allow Sview to copy what conventional views do, allowing the '''View/Add clone view''' menu item to work.

It's also easy enough to add (C++) code to implement new steps to achieve more sophisticated behaviour. An example of this is the view step called '''double''' that keeps two aircraft visible at all times, with one in the foreground; this is used for '''View/Add Pair Foreground View'''.

For more details, see the C++ Sview code itself: {{flightgear file|src/Viewer/sview.cxx}}

== Related content ==
=== Wiki articles ===
* [[Configuring View Windows]]
* [[SView]]

Howto:Configure camera view windows

2023-09-05T06:32:37Z

Necolatis: Added

: ''See also [[CompositeViewer Support]] and [[Canvas_Development#Supporting_Cameras]]

[[File:Fg-multiview-demo.png|thumb|$FG_ROOT/Docs/README.multiscreen [http://forum.flightgear.org/viewtopic.php?f=6&t=6455&p=260733#p260733]]]

This article discusses '''how to configure camera view windows''' for systems with more than one monitor. FlightGear's multiple view features are very powerful, and it is amazing how fast things run on medium and even lower range hardware.

== Major modes of operation ==
FlightGear's [[XML]]-configurable camera view system supports two major modes of operation:

# If you have multiple monitors connected to your computer and setup as separate independent displays (i.e. you can't drag a window back and forth between the monitors, and can't create a window that spans multiple monitors) then you can configure FlightGear to open up a separate window on each display and draw a unique view perspective in each window. (And if you want you can configure flightgear to open multiple windows on a single display.)
# If you have multiple monitors connected as one larger virtual display, you can configure FlightGear to open up one large window that spans all your displays, but then separate that large window into individual cameras and still draw a unique perspective on each display.

In addition, each view is highly configurable, no matter how your displays are configured.

* You can setup a distinct field of view for each display, so you can create a seamless outside world with different size monitors.
* If you wish, you can define each view in terms of the low level view frustum parameters, so you can carefully measure your monitor/display layout and configure each view to match your physical layout exactly ... including asymmetric view frustums if need be. Otherwise you can still define your views in terms of a simpler (but less flexible) horizontal/vertical field of view scheme.
* You can specify the horizontal and vertical offset from center for each display. This allows you to spread out your monitors to account for the physical gap between displays ... this allows you to create an even more seamless virtual world where runway lines and horizon lines start in the correct place on the next monitor when they run off the edge of the first. Imagine taking a large poster, cutting it into pieces and then separating the pieces from each other by a little bit ... none of the straight lines in the original image will pass straight through in the separated/stretched version. Now imagine taking that same picture and cutting strips out of it, but leaving the sections where they were originally. Straight lines are preserved between adjacent pieces. This is what this is about.

=== Use Cases ===
* ATI (the ATI that makes graphics chips and cards) used a simplified (pre-release) version of this feature to demo 8 screens being driven from a single computer at SigGraph this year.
* Enter the Matrox Triple Head to Go (do a Google search for it if you haven't heard of it.) This is just a little box, but to the computer, it looks like one giant 3x wide monitor. It plugs into your computer on one side, and on the other side you plug in 3 actual monitors. So you get up to 3 monitors without your computer needing to know anything about it, and even on video cards with only one external display connector (like a laptop.) Using the 2nd mode of operation described above, I divided my one big window into 3 camera views and was able to draw about 120 degree wrap around field of view on 3 displays.

== Required changes in preferences.xml ==
{{note|1=The changes to preferences.xml suggested here are better added to a personal XML file that can be invoked with the command line option <code>--config=path-to-your-config.xml</code>. For details on why and how, see [[FlightGear configuration via XML#Adding your own settings]].}}

As of version 1.9, FlightGear uses [[OpenSceneGraph]] (OSG) for rendering the scenery. OSG already has an implementation for setting up different cameras looking at the scene and they are configured in <tt>[[$FG ROOT]]/preferences.xml</tt>.

Slave cameras are created using properties in preferences.xml. One slave is always created that is aligned with the viewing parameters of the
master camera. Others can be opened in different graphics windows, possibly on other displays and screens. A slave camera is presently created in its own window. Closing any of the windows will close FlightGear as a whole.

Parameters for the slave are currently pretty limited; they include:

* The dimensions and position of the window.
* "shear" values in projection space.
* "heading-deg" (a heading offset that was added specifically for LinuxTag).

The shear-x and shear-y values are really only useful for setting up a "video wall" type display where monitors arranged around the "master view" show a view in an offset frustum with the same aspect ratio and fov as the master.

Let's first look at an example, setting up two extra windows. Add something like the following code to the <rendering> section of your preferences.xml file:

<syntaxhighlight lang="xml">
<camera>
<host-name type="string"></host-name>
<display>0</display>
<screen>0</screen>
<shear-x>2</shear-x>
<shear-y>1</shear-y>
<width>320</width>
<height>240</height>
<fullscreen type="bool">false</fullscreen>
</camera>
<camera>
<host-name type="string"></host-name>
<display>0</display>
<screen>0</screen>
<shear-x>-2</shear-x>
<shear-y>1</shear-y>
<width>320</width>
<height>240</height>
<fullscreen type="bool">false</fullscreen>
</camera>
</syntaxhighlight>

To simplify maintenance you can also save these modifications in a separate [[PropertyList XML files|PropertyList XML file]] (in essence the toplevel XML node must be named "PropertyList") and simply reference it in preferences.xml by making use of the include attribute in the <rendering> section.

Preferences.xml will look like this:

<syntaxhighlight lang="xml">
<rendering include="camera-views.xml">
...
</rendering>

</syntaxhighlight>

And a to be created camera-views.xml file will have the following content:

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<camera>
<host-name type="string"></host-name>
<display>0</display>
<screen>0</screen>
<shear-x>2</shear-x>
<shear-y>1</shear-y>
<width>320</width>
<height>240</height>
<fullscreen type="bool">false</fullscreen>
</camera>
<camera>
<host-name type="string"></host-name>
<display>0</display>
<screen>0</screen>
<shear-x>-2</shear-x>
<shear-y>1</shear-y>
<width>320</width>
<height>240</height>
<fullscreen type="bool">false</fullscreen>
</camera>
</PropertyList>
</syntaxhighlight>

Finally, you may be better off just running a separate FlightGear instance on the second monitor and slaving it. The whole idea behind having a multiple screen setup like twinview is that it mimics a continuous area with no boundaries. Putting those screen boundaries back in when the video subsystem has worked so hard to eliminate them is a metaphor collision and a design problem, see [[Property Tree/Native Protocol Slaving]].

== Related content ==
=== Wiki articles ===
* [[PropertyList XML files]]
* [[FlightGear configuration via XML]]
* [[ExtraViewWindows]]
* [[SView]]

=== Mailing list threads ===
* [http://sourceforge.net/p/flightgear/mailman/message/19411126/ <nowiki>[Flightgear-devel] building view windows</nowiki>] (May 2008)
* [http://sourceforge.net/p/flightgear/mailman/message/19718339/ <nowiki>[Flightgear-devel] RFC: changes to views and cameras</nowiki>] (June-July 2008)
* [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/4754694F.4040609%40wanadoo.fr/#msg15646938 <nowiki>[Flightgear-devel] dual head problem</nowiki>] (December 2007)
* [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/ef5fc9920803171336q6e62c038q65c96b822c9f47f1%40mail.gmail.com/#msg18867154 <nowiki>[Flightgear-devel] Matrox TripleHead2Go</nowiki>] (Marsh 2008-June 2011)
* [http://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/20081014201611.GC1483%40voyageur.mas.nom.fr/#msg20557100 <nowiki>[Flightgear-devel] Patch for multiscreen mode with multiplayer</nowiki>] (October 2008)

=== Readme file ===
* {{readme file|multiscreen}}

== External links ==
* David R. Miller, [http://www.inkdrop.net/dave/multimon.pdf ''Multiple Monitors in FlightGear: Quick and Dirty''] (PDF, 0.8 MB), last updated 4 Mar 2006. Setting up multiple monitors on multiple system with different OS:es. May be outdated.
* example files from the german c't magazine: ftp://ftp.heise.de/pub/ct/listings/1309-162.zip

[[Category:Howto|Configure camera views in Windows]]
[[Category:Discusses editing preferences.xml]]

[[es:Cómo configurar ventanas de vistas de cámara]]
[[fr:Howto:Configurer cameras, vues et fenêtres]]

Howto:Syntax highlighting for Nasal

2023-06-29T13:19:59Z

Necolatis: /* Sublime Text 4 */

There's '''[[Nasal]] syntax-highlighting''' support available for some editors, which is a big advantage, as it makes Nasal coding much easier.

Syntax highlighting can often point to syntax errors and so reduce the number of tedious time-consuming and unproductive [[FlightGear]] runs. It can also be a sort of "guide" to the language, highlighting functions or keywords that are builtin, so you can quickly check if it is "type" or "typeof" by typing each. In addition makes understanding other people's code easier, since you have all of the parts visually separated out, like loops, strings, constants, and builtin functions.

== Atom ==
Script is available from [https://github.com/www2000/atom-language-nasal Github] and can also be found in the [https://atom.io/packages/language-nasal Atom's packages repository].

Manual installation:

# Download the latest release from https://github.com/www2000/atom-language-nasal
# Unpack the tar.bz2
# Copy/move the language-nasal package to ~/.atom/packages

For installation from atom's packages repository:

# Open Atom
# Go to Preferences Edit -> Preferences or {{key press|Ctrl|+}},
# Click on packages and search for nasal
# Click install for Language Nasal

== Emacs ==
[[File:Emacs-nasal-syntax-highlighting.png|400px|thumb|Nasal syntax highlighting in GNU Emacs]]

There is an Emacs major mode for Nasal available in SimGear, that is based on Andy Ross' [https://github.com/andyross/nasal/blob/master/misc/nasal-mode.el original version]. In order to use it, you can copy the {{simgear source
| path = simgear/nasal/misc/nasal-mode.el
| text = nasal-mode.el
}} file where you have the rest of your manually installed packages and add the following line to your [https://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html Emacs initialization file]:
<nowiki>(require 'nasal-mode)</nowiki>

In case you don't already have a directory to place your manually installed packages, put the file for instance in ''~/.emacs.d/manual-installs/'' (first create this directory if necessary) and insert the following in your Emacs initialization file before the above ''require'' line:
<nowiki>;; Tell Emacs it can load ELisp files from there
(add-to-list 'load-path "~/.emacs.d/manual-installs")</nowiki>

Once this is done, restart Emacs, check that no error is reported and open a .nas file.

Optional step: in order to speed up loading of nasal-mode.el, you can open it and choose ''Byte-compile this file'' from the ''Emacs-Lisp'' menu (or equivalently, run M-x byte-compile-file).

{{Tip|In case you have a clone of the {{simgear source
| text = SimGear repository
}} on your hard drive, you may create a symbolic link from ~/.emacs.d/manual-installs/nasal-mode.el to the file inside that repository; this way, you'll get automatic updates of nasal-mode.el when your SimGear repository is updated (Emacs will ignore the .elc file resulting from byte compilation if the corresponding .el file is more recent).}}

The '''true''' and '''false''' keywords introduced in January 2023 are already supported.<ref>https://forum.flightgear.org/viewtopic.php?f=30&t=41115&p=409029#p409029</ref>

== Geany ==

A syntax highlighting solution for [https://www.geany.org/ Geany], a lean text editor/IDE is available from [https://forum.flightgear.org/viewtopic.php?f=30&t=36838#p360677 this thread] in the FlightGear forum.

== gedit ==
[[File:Philosopher's nasal highlighting in gEdit.jpeg|400px|thumb|Screen shot illustrating syntax highlighting in gedit]]

'''Philosopher''' on the FlightGear Forum has created syntax highlighting for gedit, a popular and simple text editor for Mac OS X, Linux, and Windows.


To install, copy the ''nasal.lang'' file  from the first post of the forum topic {{forum link|p=164133}} and:

* If you use Mac, move it into your ''Applications/gedit/Contents/Resources/share/gtksourceview-X.0/language specs'' folder.
* For Linux, move it into your ''/usr/share/gtksourceview-X.0/language-specs'' folder.

In the same post given above, there are instructions for how to edit ''xml.lang'' (in the same directory) to add the embedded XML content support (with this minor edit, Nasal highlighting will be used inside of certain tags, instead of plain text).

For "snippets" support, nasal.xml from the above post has to be moved into ''/usr/share/gedit/plugins/snippets/'' folder or installed using the "import" feature. See this image for more details:

[[:File:Install nasal snippets in gedit.png|how to import Nasal snippets]].
{{-}}

== jEdit ==
There's a syntax highlighting mode for jEdit, programmer's text editor

Included are some of Nasal's internal functions and those functions currently implemented in NasalSys.cxx
To use, add the content of the catalog inside your own catalog (do NOT overwrite the file) and nasal.xml in /home/USER/.jedit/modes

Restart jEdit and you can use it. Current extension is .nas, you can add your own extension and functions.
This mode is heavily based on the Javascript mode.

Get it here: https://sourceforge.net/projects/fgscheduleview/files/jedit/catalog.zip/download

== KDE Editors ==
There's a highlighting definition for nasal available at '''opendesktop.org''' (https://www.opendesktop.org/p/1187022/)

Download the file and copy it into:
:~/.kde4/share/apps/katepart/syntax/ (for KDE4)
:or
:~/.local/share/katepart5/syntax/ (for KF5 pre 5.29)
:or
:~/.local/share/org.kde.syntax-highlighting/syntax/ (for current KF5 versions)

(you can create the folders if they don't exist yet).

Note that the syntax highlighting in KDE doesn't set colors, it just identifies structural elements, colors are defined by the '''schemas''' used by each editor, thus you get consistent highlighting between different languages.

The highlighting file should work with all editors based on the katepart: KWrite, Kate, and the editor component of KDevelop.

== Notepad++ ==
[[File:Highlight parse.png|400px|thumb|Screenshot of Nasal support for Notepad++]]
Provides comprehensive syntax highlighting and a function list parser with support for hierarchical display of both inline and out-of-body class member functions.
* [http://github.com/Slaiyer/nasal-npp GitHub repository for download and instructions]

'''Alternative (syntax highlighting only):'''
* [http://dl.dropbox.com/u/1463693/nasal.xml Download here]
** [http://superuser.com/questions/62474/notepad-custom-syntax-highlighting-setting-where-to-look-for-it Instructions are here]
{{-}}

== Sublime Text 2 ==
[[File:Sublime Text 2 syntax highlighting.png|400px|thumb|Sublime Text 2 syntax highlighting]]

Scripts and installation instructions are here: https://github.com/freevryheid/nasal
{{-}}

== Sublime Text 4 ==
Scripts and installation instructions are here: https://github.com/NikolaiVChr/sublime-nasal
{{-}}

== Vim ==
[[File:Vim-nasal-syntax-highlighting.png|400px|thumb|Screen shot illustrating syntax highlighting in Vim]]

One such editor is the free vim or its GUI variant gvim.

It's not for everyone but it's free, and testing it doesn't hurt: http://www.vim.org/.

The syntax definition file comes with the FlightGear code ({{flightgear file|scripts/syntax/nasal.vim}}). Highlighting works even for Nasal embedded in XML files (type ":set ft=nasal", where ft stands for file-type)

Here's an example, which demonstrates a short code segment with three syntax errors as well as the highlighting of a matching pair of parentheses (yellow) and trailing spaces (blue x). (The leading blue dots aren't on by default. They help to spot tab crimes.)
{{-}}

== Visual Studio Code ==
[[File:Vscode-sintaxhighlight.jpg|thumb|Screen shot illustrating syntax highlighting in VSCode]]

[https://code.visualstudio.com Visual Studio Code] is a source-code editor developed by Microsoft for Windows, Linux and macOS. Its open source and free.

The nasal extension is available from [https://github.com/RenanMsV/nasal-vscode Github] and can also be found in the [https://marketplace.visualstudio.com/items?itemName=Renan-MsV.nasal-lang VSCode's marketplace].
It supports basic syntax highlighting and snippets to improve development speed.

For installation from the marketplace:

# Open VSCode
# Go to File -> Preferences -> Extensions or {{key press|Ctrl|Shift|X}},
# Search for nasal
# Click install for Nasal Language (FlightGear)

Manual installation:

# Download the latest release from the repository, it should be a .vsix file.
# Install the extension manually by doing the command 'code --install-extension path_to_extension.vsix'

{{-}}

== TextMate==
[[File:Nasal syntax highlighting in TextMate.png|thumb|Screen shot illustrating syntax highlighting in TextMate]]
[https://macromates.com/ TextMate] is a general-purpose GUI text editor for macOS created by Allan Odgaard. It is open source and free to use.

There is a TextMate Bundle for Nasal available on [https://github.com/BobDotCom/Nasal.tmbundle GitHub] which can be [https://macromates.com/manual/en/bundles#installing_a_bundle installed in TextMate] for basic syntax highlighting.

{{-}}

==IntelliJ Family Editors (JetBrains)==
[[File:Nasal syntax highlighting in PyCharm.png|thumb|Screenshot illustrating syntax highlighting in PyCharm]]
[https://www.jetbrains.com/idea/ IntelliJ IDEA] is an integrated development environment written in Java for developing computer software written in Java, Kotlin, Groovy, and other JVM-based languages. It is developed by JetBrains and is available as an Apache 2 Licensed community edition, and in a proprietary commercial edition.

Although there is not a native IntelliJ plugin for Nasal, IntelliJ supports [https://www.jetbrains.com/help/idea/textmate-bundles.html installing TextMate bundles] for syntax highlighting, so the [https://github.com/BobDotCom/Nasal.tmbundle Nasal TextMate Bundle] can be used. Installation instructions are available [https://www.jetbrains.com/help/webstorm/tutorial-using-textmate-bundles.html here].

There are many [https://www.jetbrains.com/products/ JetBrains products] that are based on IntelliJ such as [https://www.jetbrains.com/pycharm/ PyCharm] (Python) and [https://www.jetbrains.com/webstorm/ WebStorm] (Javascript). These IDEs can also be used with nasal syntax highlighting, in the same way as above.

{{-}}

==Other editors==
Nasal being syntactically very close to other programming languages like C, Php or JavaScript, you can get some usable highlighting even without real Nasal support:

* TextMate {{forum link|hilit=syntax+nasal|p=127828}}
*SciTe {{forum link|hilit=syntax+nasal|p=94521}}

==FlightGear Wiki==
{{Note|As of 02/2016, we do not currently have a dedicated Nasal module available [http://wiki.flightgear.org/FlightGear_wiki:Village_pump/Archive_2016#Nasal_Syntaxhighlighting]}}
{{main article|Help:Formatting#Syntax highlighting}}

Using the <syntaxhighight> tag with a lang="nasal" attribute, we can have highlighting right here on the wiki. Use enclose="div" to wrap the text, if it happens to be particularly wide.

<nowiki><syntaxhighlight lang="nasal">
# hello.nas
print('Hello World!');
</syntaxhighlight></nowiki>

Which renders into:
<syntaxhighlight lang="nasal">
# hello.nas
print('Hello World!');
</syntaxhighlight>

==Syntax highlighting test==
Just a collection of keywords, etc. to test whether highlighting works (you can copy this to test your own highlighting):
<syntaxhighlight lang="nasal">
# this is a comment
# operators (if applicable):
!a ? a+b - c/d*e : f~g; expr1 and expr2 or expr3;
# Builtin functions, strings
print('Hello World!');
die("We have an error, Houston!", arg[0]);
cmdarg().getNode("setting").getValue();
streq(typeof(id(keys(hash))),10);
# Loopoids
foreach (var a; ["haha", {command:"NASAL!"}, me]) {
if(0) break;
elsif(1) continue;
else return;
while(1) sprintf("%s%s\n%s=%f", "Spam", "spam", "spam", 0e-0);
for (var i=0; i < 0.00; i += 0x0) printf("%d", int(i));
forindex(var o; a) (func {
var o = o;
setlistener("/", func print(o), 1, 2);
})();
}
# String escaping stress tests:
'\a\b\c\"\\\?' # none of these
"\e\?\'\f\a" # none of these
'\'' # this one
"\"\r\n\t\\\t" # and all of these
# And optionally string formatting:
"%s%%s%.0f%8d" # the second "s" shouldn't be highlighted, otherwise everything else
# Syntax error!:
%$@&^|\`
</syntaxhighlight>

==Related content==
*{{forum url|p=164155}}
*{{forum url|t=12495}}
*{{forum url|t=15972}}
*{{forum url|t=9812}}

[[Category:Nasal howto]]

<references />

Virtual Reality

2023-06-07T13:22:45Z

Necolatis: /* Testing */ Added Windows

{{Experimental|disclaimer=VR support in flightgear still comes with a number of caveats.}}

{{infobox subsystem
|image = VR screenshot c182s.png
|name = Virtual Reality
|started = 07/2021
|description = Virtual Reality support using osgXR / OpenXR
|status = Active
|developers = James Hogan <ref>https://sourceforge.net/u/amalon/profile/</ref>
|changelog = https://sourceforge.net/u/amalon/profile/feed.rss
}}

The '''Virtual Reality''' project aims to add immersive VR support to FlightGear. This is done using the OpenXR<ref>{{cite web |url=https://www.khronos.org/OpenXR/ |title=OpenXR Overview |publisher=The Khronos Group Inc}}</ref> API, via an external library called osgXR<ref name="github-osgXR">{{github source |user=amalon |repo=osgXR |full=1}}</ref> for handling OpenXR and OpenSceneGraph specifics, which is being developed in parallel.

== Background ==

A previous attempt to support some form of VR is described in [[OculusImplementation]].

The portable OpenXR API now seems to be getting widespread adoption, which will allow FlightGear to support a variety of VR devices across multiple platforms.

== Source code ==

* osgXR source can be found on github<ref name="github-osgXR"/>, or the version included in the flightgear 3rdparty directory can be used.
** On ArchLinux, you can install the osgxr AUR package <ref>https://aur.archlinux.org/packages/osgxr/</ref> to get the version needed by FlightGear's next branches.
* Some VR code can now be found in FlightGear's next branches (see below for details).
** On ArchLinux, you can use the -git AUR packages, i.e. flightgear-git, simgear-git, flightgear-data-git.
** On Windows, you can use the [[Nightly Build#Windows|Windows nightly builds]].
* More FlightGear changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=flightgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased). A mirror is available on github for issue tracking<ref>{{github source |user=amalon |repo=flightgear-vr}}</ref>.
* More SimGear changes can be found in James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=simgear |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).
* More FGData changes can be found on James Hogan's osgxr branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr |full=1}}</ref> (non-rebased branch), or osgxr_clean branch<ref>{{sourceforge source |user=amalon |repo=fgdata |branch=osgxr_clean |full=1}}</ref> (clean history, may be rebased).

== Building & Packaging Notes ==

When CMake runs for FlightGear (next or osgxr/osgxr_clean branches), by default it will attempt to enable VR on Windows and Linux (same as <code>-DENABLE_VR=ON</code>). It will do the following:
# Look for the osgXR library, and if found it will link against that (same as <code>-DSYSTEM_OSGXR=ON</code>).
# If no osgXR library is found it will check for OpenXR and if found it will build its own static built-in copy of osgXR to use.
# If no OpenXR is found it will disable VR support.

In any case it will print a message along the lines of <code>-- VR support enabled/disabled...</code>.

To avoid implicit dependencies when packaging, packagers may need to do ONE of the following:
* preferably depend upon an osgXR package providing the osgXR dynamic library
* OR depend on OpenXR and GLX, and explicitly pass `-DSYSTEM_OSGXR=OFF` to CMake so the built-in osgXR is built statically
* OR explicitly pass `-DENABLE_VR=OFF` to CMake to disable VR support altogether

== Status ==
'''Last updated: 22nd August 2022'''

Highly experimental, partially in next, partly out of tree. Development in progress.

Working in next branch (e.g. [[Nightly Build#Windows|Windows nightly builds]]):
* Enable/disable at startup via --enable-vr / --disable-vr command line options, or from GUI (View->VR Options).
* VR friendly splash screen.
* Displaying stereo images on the HMD.
* Motion tracking updates HMD views (but doesn't move main camera).
* Configurable VR mirror (see View->VR Settings) shown in default camera view (blank, left, right, side-by-side left & right).
* Visibility mask support.

Working in osgxr/osgxr_clean branch:
* Controller support for flight (helicopter collective in left hand, helicopter cyclic in right).
* Controller pointing support with some mouse emulation.
* Rendering of controllers (as basic cuboids).

Current priorities:
* Improving platform support (Monado in particular).
* Continue to polish controller flight support, add haptics etc.
* Get started on other controller interaction and controller rendering.

=== Known issues ===

* <s>Splash screen is rendered directly onto the left eye viewport which isn't very pleasant in VR.</s>
* Performance could be better so crank down the graphics if frame rate is low.
* Shadows are broken:
** When shadows are enabled, the FlightGear window doesn't appear to refresh even though buffers are swapped, but VR output works.
** Sun position is fixed relative to head, presumably because shadow maps are rendered based on master camera, but osgXR only moves slave cams.
* Spotlights (taxi/landing lights) are relative to camera in default mode
** Affects default / scene view mode (<code>--prop:/sim/vr/mode=AUTOMATIC</code>), as stereo callbacks position cameras
** Doesn't affect slave cameras mode (<code>--prop:/sim/vr/mode=SLAVE_CAMERAS</code>), as slave cameras are positioned correctly
* ALS filters appear to operate in screen space but don't take into account side by side rendering
* Still some Monado issues:
** <s>Saturated output due to not using SRGB textures</s> (use osgXR 0.3.8)
** <s>Suboptimal depth format used</s> (osgXR 0.3.8 should end up using GL_DEPTH32F_STENCIL8)
** Warnings about suggesting bindings of attached action sets when restarting VR (looks like a monado issue at first glance)
* Multiple SteamVR issues on Linux:
** If it doesn't close cleanly on Linux it may be due to a SteamVR bug<ref name="github-SteamVR-422"/>, but a ctrl+c / SIGINT on the command line should close it.
* osgXR doesn't support Direct3D graphics bindings for WMR (it isn't a priority for me). Contributions welcome.

=== Testing ===

VR has been tested with the following hardware & software configurations:
* HTC Vive, SteamVR, Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 21:43, 27 August 2021 (UTC)
* Oculus Quest 2, SteamVR (ALVR), Linux/X11 (Fedora 34) -- [[User:vezza|vezza]] ([[User talk:vezza|talk]]) 16:30 27 August 2021 (UTC)
* Oculus Quest 2, Oculus App, Windows 10 --[[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 13:22, 7 June 2023 (UTC)
** Works fine, shadows gets rendered, but move when turning the head.
** Eye view point is about 0.2 meter above where the view is defined, so I have to duck my head to look out through the HUD and stuff.
* HTC Vive, Monado (to window), Linux/X11 (ArchLinux), nVidia proprietary -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
* Monado dummy driver, Linux/X11 (ArchLinux), Intel mesa -- [[User:Amalon|Amalon]] ([[User talk:Amalon|talk]]) 22:36, 17 December 2021 (UTC)
** only basic display to window tested
** osgXR master
** /sim/vr/depth-info=false
* Monado Dummy HMD, Linux/X11 (Debian), AMD Mesa Drivers [[User:merspieler|merspieler]] ([[User talk:merspieler|talk]]) 23:27, 17 December 2021 (UTC)
** Applying the following patch: <syntaxhighlight lang="diff">
diff --git a/src/XRState.cpp b/src/XRState.cpp
index ce09bcd..5bcbbca 100644
--- a/src/XRState.cpp
+++ b/src/XRState.cpp
@@ -1017,7 +1017,7 @@ XRState::UpResult XRState::upSession()
unsigned int thisDepthBits = 0;
switch (format)
{
- case GL_RGBA16:
+ case GL_RGB10_A2:
// FIXME This one will do for now...
if (!chosenSwapchainFormat)
chosenSwapchainFormat = format;
</syntaxhighlight>

If you've got VR working, feel free to add your configuration above.

The following testing is desired:
* SteamVR, Linux, AMD graphics:
** Test that motion smoothing works (its unsupported on NVidia)
** moving head side to side should reproject using depth buffer
** try suspending fgfs with Ctrl+Z in terminal (resume with fg) to force reprojection
* Monado, Linux:
** May be awkward to test as it crashes in latest NVidia proprietary drivers<ref>https://gitlab.freedesktop.org/monado/monado/-/issues/122</ref>.
*** There's now a workaround mentioned in that ticket that allows for basic testing
** Use at least osgXR 0.3.6 for monado workaround, or <code>--disable-vr</code> and enable VR with GUI
* SteamVR, Windows, with a headset (I've only attempted to null driver, and it at least partly worked):
** Needs building with at least osgXR 0.3.7 for Windows bindings, and my osgxr/osgxr_clean branch of flightgear/fgdata/simgear
** May need --disable-sentry
** Test headset output and controllers

Issues can be reported:
* On the flightgear-devel [[Mailing lists|mailing list]]
* To the {{tickets|FlightGear bug tracker}} if the issue is reproducible on the next branch
* To the [{{github issues url |user=amalon |repo=flightgear-vr}} flightgear-vr issue tracker]
* To the [{{github issues url |user=amalon |repo=osgXR}} osgXR issue tracker] if it is known to be a non-flightgear specific bug in osgXR

But please be aware of the known caveats mentioned above, and the roadmap below.

== Performance ==

Here are some pointers to get the best VR experience.
* Ensure your runtime supports asynchronous reprojection, which may alleviate the nausea induced by lower frame rates.
** On Linux / SteamVR / NVidia proprietary driver, ensure you have at least driver version 270.
* If your frame rate is being capped at the refresh rate of your desktop monitor, try disabling VSync in both flightgear settings and your driver settings
** On Linux / NVidia proprietary driver, its found in OpenGL settings in nvidia-settings.
* If FlightGear is getting throttled by SteamVR (to try and ensure a consistent, if slow, frame rate), consider switching to fixed throttling (in per-application video settings) and playing with the sliders. You may prefer no frame rate throttling but a higher predicted frame time.
* Enabling multithreading may get you better performance, e.g. <code>--prop:/sim/rendering/multithreading-mode=CullThreadPerCameraDrawThreadPerContext</code>
* If using an AMD GPU, use [https://gitlab.com/corectrl/corectrl CoreCtrl] and set the GPU to the "Virtual Reality" power profile with GPU and memory clocked to max. You may also benefit from changing the CPU frequency governor to Performance.

== Implementation Details ==

=== Concepts ===

==== Interaction Modes ====

Interaction modes are a way of describing (via XML) how a VR controller should look and behave in a particular context. It roughly corresponds to a virtual control you can hold (and let go of), for example:
* When you're holding a helicopter collective control, the pitch angle of the controller should control the collective pitch (and look like a collective in your hand).
* When you're pointing the controller at a GUI or cockpit controls it should pick along a line, rendered in a specific way, and emulate mouse events to those controls (and look like a small laser pointer control or a pointing hand/glove).
* When you're teleporting around, it should pick along a parabolic arc, rendered a specific way, and teleport there when the button is released.
* When you're using the flight recorder it should treat the controller trackpad as a rewind/fast forward (and look like a fancy TV remote or something).

The definition of interaction modes should be generic enough that custom ones can be provided with aircraft, or defined separately and work with any aircraft, but also powerful enough that a complex and intuitive control can be defined with a minimum of Nasal scripting.

== Roadmap ==

=== Development targets ===
* Merge stable & minimally functional code into next ({{Merge-request |project=flightgear |id=253}}, {{Merge-request |project=fgdata |id=238}}) {{done}}
** Bare functionality {{done}}
** Stability {{done}}
* Merge some form of desktop mirroring of VR view ({{Merge-request |project=flightgear |id=260}}, {{Merge-request |project=fgdata |id=241}}) {{done}}
* Merge visibility mask support ({{Merge-request |project=simgear |id=98}}, {{Merge-request |project=flightgear |id=264}}, {{Merge-request |project=fgdata |id=244}}) {{done}}
* Polish {{not done}}
** Make launcher accessible to VR user {{not done}}
** Make splash screen VR friendly {{done}}
** Make GUI accessible to VR user {{not done}}
** Make aircraft center accessible to VR user {{not done}}
* Functionality {{progressbar|40}}
** Controller flight support {{progressbar|80}}
*** Haptic feedback {{not done}}
** Controller interaction support {{progressbar|40}}
** Walker locomotion / room scale {{not done}}

=== General tasks ===

* Stability {{done}}
** Clean shutdown {{done}}
*** SteamVR for Linux hangs on OpenXR app shutdown<ref name="github-SteamVR-422">{{github issues url|ValveSoftware|SteamVR-for-Linux|number=422}}</ref>.
** Handle OpenXR stopping {{done}}
*** SteamVR for Linux kills running app even if it ends session<ref>{{github issues url|ValveSoftware|SteamVR-for-Linux|number=461}}</ref>.
* Resolve questions around VR mirror switching {{done}}
* Performance {{progressbar|10}}
** Handle shouldRender=false by somehow disabling VR cameras (maybe setting cull mask to 0) {{not done}}
** SceneView mode: Combine culling traversal {{not done}}
** Check why update isn't proceeding in parallel with multithreading {{not done}}
** Use OpenXR visibility mask extension to avoid rendering to invisible fragments {{done}}
* Sound {{progressbar|0}}
** Ensure surround sound is relative to user's head {{not done}}
** Investigate a way to use appropriate OpenAL binaural mode automatically {{not done}}
** Specify separate sound device for VR so it switches automatically? {{not done}}

=== User facing features ===

* Display {{progressbar|60}}
** Show views on HMD {{done}}
** Configurable mirror on desktop window {{done}}
*** Left, Right, Left & Right {{done}}
*** Composited mirror mode (combine & blend views and allow zooming) {{paused}}
** Geometry shader multi viewport {{not done}}
** OVR_multiview2 with OSG branch {{not done}}
* Motion tracking {{progressbar|50}}
** Follow motion of HMD {{done}}
** Move master camera instead of scene slave cameras (presumably would fix surround sound) {{not done}}
* Settings {{progressbar|20}}
** Mirror settings {{done}}
** Dynamic toggling of VR {{done}}
** Sound settings? {{not done}}
*** Sound reference frame (user's head or room)? {{not done}}
** Advanced VR settings {{not done}}
*** validation layer {{not done}}
*** submit depth information {{done}} but needs testing (SteamVR+Linux+nVidia doesn't do motion smoothing yet)
*** osgXR VR mode {{not done}}
**** Fix slave cameras mode clearing {{not done}}
*** osgXR swapchain mode {{not done}}
* Platform support {{progressbar|70}}
** Linux/X11/OpenGL graphics bindings {{done}}
** Monado support {{progressbar|60}}
** Windows/OpenGL graphics bindings {{done}}
** Windows Mixed Reality render via DirectX bindings {{not done}}
* Splash screen {{progressbar|80}}
** Show splash screen as quad layer for runtime to composite {{done}}
** Cube map/quads background provided by aircraft {{progressbar|20}}
* GUI {{progressbar|10}} {{priority|2}}
** Shown over mirror on desktop window {{done}}
** Expose a menubar & GUI, rendered to a quad or cylinder in front of VR user when they activate {{not done}}
** Interact with GUI buttons etc using controllers as lasers {{not done}}
* Launcher {{not done}}
** Show launcher in VR similar to GUI when enabled via command line or launcher option {{not done}}
** Transition to flightgear {{not done}}
** Transition to aircraft center with VR already started {{not done}}
** Transition back to flightgear from aircraft center {{not done}}
** More VR friendly environment
*** A simple background cubemap, shared with splash {{not done}}
*** A hanger (like xplane11)? {{not done}}
* Controller support {{progressbar|50}}
** Basic action support in osgXR API {{done}}
** Tie osgXR actions into FG's input system {{done}}
** Helicopter flight controls (can use for planes too) {{done}}
** Plane flight controls {{not done}}
** Render controllers {{progressbar|20}}
** Hand tracking (robot hand) {{progressbar|90}}
** Render skinned hand {{not done}}
** Basic interaction with controls {{progressbar|80}}
*** Grasp surfaces {{{progressbar|90}}
*** Force feedback for haptic gloves {{not done}}
** Advanced interaction with animated controls {{progressbar|90}}
*** Direct manipulation mouse mode for testing without VR {{progressbar|90}}
*** Inverse kinematics of translate and rotate animations {{done}}
*** Ability to specify frictions {{not done}}
*** Ability to specify ranges (where can't be deduced) {{not done}}
*** Ability to hint what aircraft processes/filters/kinematics should be reversible {{progressbar|10}}
** Haptic feedback {{not done}}
* Walker VR locomotion / Room scale {{progressbar|0}}
** Walker follows user {{not done}}
** Parabolic arc teleport {{not done}}
** Snap into seats {{not done}}
** Easy turning around {{not done}}

=== Aircraft compatibility ===

This section is largely about how usable controls are in VR with direct manipulation.

==== [[Cessna 172P]] ====
* Controls
** Flaps {{progressbar|90}}
*** kinematic needs to be reversible {{progressbar|90}}
** Visors {{progressbar|70}}
*** correct relative friction {{not done}}
** Opening of doors {{not done}}
*** reversing of gain expression {{not done}}

==== [[Eurocopter EC130 B4]] ====
* Engine start
** Engine cutoff lever reversing (Alt+C required) {{not done}}
** External power on (GUI required) {{not done}}
** External power off (GUI required) {{not done}}
** Throttle roll (middle mouse drag required) {{not done}}
* Take off & flight
** Arms & hands get a bit in the way {{not done}}
* Controls
** Engine cutoff lever {{not done}}
*** Uses nasal, needs pick animation binding of some sort
** ELT {{progressbar|50}}
*** Both /ELT/test and /ELT/armed can be set to bool
*** Both can get set though
** Doors & hatches {{not done}}
*** Add limits

==== [[McDonnell Douglas F-15 Eagle]] ====
* Model
** Floating switches are very noticeable {{not done}}
** HUD should be at infinity {{not done}}

==== [[Robinson R22]] ====
* Controls
** Tilting T-bar {{progressbar|90}}
*** limit range? {{not done}}
** Collective awkward to get at {{not done}}
** Throttle roll & governor switch? {{not done}}

==== [[Robinson R44]] ====
* Controls
** Tilting T-bar {{not done}}

== References ==
{{Appendix}}

[[Category:Core development projects]]

User:Necolatis/HDR

2023-06-05T16:30:45Z

Necolatis:

On this page I detail my experiences with playing around with PBR and [[HDR Pipeline|HDR]] in Flightgear 2020.4.0.
=Render quality=
It looks absolutely amazing when using model-pbr.eff with ORM texture.
[[File:Hdr-3.png|thumb|Looks great]]
=Bugs=
===Black areas===
This happens sometimes in HDR. Only when using model-pbr.eff, model-combined.eff don't have the issue. It goes away if I sit and wait about 1 to 2 minutes.
[[File:Hdr-1.png|thumb|Black areas]]
===Dark halo===
Some aircraft have a dark halo around the lower edge of the objects in HDR.
The used effect is just stock model-combined without any adjustments. The halo goes away moving camera lower than the object that displays a halo.
[[File:Hdr-2.png|thumb|Dark halo]]
===Weak AA===
The only I got to work was FXAA from driver, and that don't get shown in screenshots.
Also tried <nowiki>--prop:/sim/rendering/hdr/antialiasing-technique=1</nowiki> or 2 to no avail.
===Textranslate===
This type of animation seems to not work in HDR.
=Missing model features=
===Ignores canvas background alpha===
Canvas background color alpha is constant at 1.0. So canvas HUDs wont work.
===Ignores model alpha (AC3D material)===
Constant at 1.0
===Thruster effect===
It don't show.
===Backout===
It does something weird.
=Missing world features=

User:Necolatis

2023-06-05T11:45:57Z

Necolatis:

'''List of Wiki pages I intend to expand:'''

'''List of Wiki pages I intend to make:'''

'''List of Wiki pages I made and try to keep updated:'''
* [[Canvas Nasal API‎]]
* [[Aero input and outputs‎]]
* [[Saab 37 Viggen]]
* [[Aircraft Failure System]]
* [[Nasal and the Property-tree]]
* [[Aircraft sound]]
* [[Crash and stress damage system]]
* [[Blender AC3D import and export]]
* [[:Category:Aerodynamic Tools]]
* [[Aeromatic]]
* [[Save properties between sessions]]
* [[JSBSim Logging]]
* [[Custom blackout system]]
* [[Terrain Detection]]
* [[Howto:Add sound effects to aircraft]]
* [[AI wake turbulence]]
* [[Effect Framework]]
* [[JSB to PNG]]
* [[User:Necolatis/HDR|My experience with testing HDR]]

[[User:Necolatis/often_used|Shortcuts]]

User:Necolatis/HDR

2023-06-05T11:30:14Z

Necolatis: /* Missing AA */

On this page I detail my experiences with playing around with PBR and [[HDR Pipeline|HDR]] in Flightgear 2020.4.0.
=Render quality=
It looks absolutely amazing when using model-pbr.eff with ORM texture.
[[File:Hdr-3.png|thumb|Looks great]]
=Bugs=
===Black areas===
This happens sometimes in HDR. Only when using model-pbr.eff, model-combined.eff don't have the issue. It goes away if I sit and wait about 1 to 2 minutes.
[[File:Hdr-1.png|thumb|Black areas]]
===Dark halo===
Some aircraft have a dark halo around the lower edge of the objects in HDR.
The used effect is just stock model-combined without any adjustments. The halo goes away moving camera lower than the object that displays a halo.
[[File:Hdr-2.png|thumb|Dark halo]]
===Weak AA===
The only I got to work was FXAA from driver, and that don't get shown in screenshots.
Also tried <nowiki>--prop:/sim/rendering/hdr/antialiasing-technique=1</nowiki> or 2 to no avail.
=Missing model features=
===Ignores canvas background alpha===
Canvas background color alpha is constant at 1.0. So canvas HUDs wont work.
===Ignores model alpha (AC3D material)===
Constant at 1.0
===Thruster effect===
It don't show.
===Backout===
It does something weird.
=Missing world features=

User:Necolatis/HDR

2023-06-05T11:29:50Z

Necolatis: /* Ignores model alpha (AC3D) */

On this page I detail my experiences with playing around with PBR and [[HDR Pipeline|HDR]] in Flightgear 2020.4.0.
=Render quality=
It looks absolutely amazing when using model-pbr.eff with ORM texture.
[[File:Hdr-3.png|thumb|Looks great]]
=Bugs=
===Black areas===
This happens sometimes in HDR. Only when using model-pbr.eff, model-combined.eff don't have the issue. It goes away if I sit and wait about 1 to 2 minutes.
[[File:Hdr-1.png|thumb|Black areas]]
===Dark halo===
Some aircraft have a dark halo around the lower edge of the objects in HDR.
The used effect is just stock model-combined without any adjustments. The halo goes away moving camera lower than the object that displays a halo.
[[File:Hdr-2.png|thumb|Dark halo]]
===Missing AA===
The only I got to work was FXAA from driver, and that don't get shown in screenshots.
Also tried <nowiki>--prop:/sim/rendering/hdr/antialiasing-technique=1</nowiki> or 2 to no avail.
=Missing model features=
===Ignores canvas background alpha===
Canvas background color alpha is constant at 1.0. So canvas HUDs wont work.
===Ignores model alpha (AC3D material)===
Constant at 1.0
===Thruster effect===
It don't show.
===Backout===
It does something weird.
=Missing world features=

User:Necolatis/HDR

2023-06-05T11:27:55Z

Necolatis: Created page

On this page I detail my experiences with playing around with PBR and [[HDR Pipeline|HDR]] in Flightgear 2020.4.0.
=Render quality=
It looks absolutely amazing when using model-pbr.eff with ORM texture.
[[File:Hdr-3.png|thumb|Looks great]]
=Bugs=
===Black areas===
This happens sometimes in HDR. Only when using model-pbr.eff, model-combined.eff don't have the issue. It goes away if I sit and wait about 1 to 2 minutes.
[[File:Hdr-1.png|thumb|Black areas]]
===Dark halo===
Some aircraft have a dark halo around the lower edge of the objects in HDR.
The effect is just stock model-combined without any adjustments. The halo goes away moving camera lower than the object that displays a halo.
[[File:Hdr-2.png|thumb|Dark halo]]
===Missing AA===
The only I got to work was FXAA from driver, and that don't get shown in screenshots.
Also tried <nowiki>--prop:/sim/rendering/hdr/antialiasing-technique=1</nowiki> or 2 to no avail.
=Missing model features=
===Ignores canvas background alpha===
Canvas background color alpha is constant at 1.0. So canvas HUDs wont work.
===Ignores model alpha (AC3D)===
Constant at 1.0
===Thruster effect===
It don't show.
===Backout===
It does something weird.
=Missing world features=

File:Hdr-3.png

2023-06-05T10:52:04Z

Necolatis:

Using ORM texture

File:Hdr-2.png

2023-06-05T10:40:48Z

Necolatis:

Dark halo

File:Hdr-1.png

2023-06-05T10:37:03Z

Necolatis:

Bug in hdr

Canvas Image

2023-05-12T16:51:08Z

Necolatis: Added imageSize

[[Category:Canvas Elements]]
{{Template:Canvas Navigation}}

= setPixel =
* '''Version''': FlightGear >= 2020.1
* '''Format''': setPixel(x_position, y_position, color)
* '''Color Format''': Can be a vector of size 3 or 4 (rgba as 0 to 1). Or a string with hexadecimal colors, for example "#7f3f1f".
Will change a single pixel to a specified color in the image. End the changing by calling dirtyPixels.

setPixel and fillRect is typically used when having to change an image alot. So to avoid using possibly hundreds of path elements on top of the image, changing the image pixel colors is more efficient.

= dirtyPixels =
* '''Version''': FlightGear >= 2020.1
After operations on setPixel is done, the method dirtyPixels() must be run.

= imageSize =
* '''Version''': Flightgear >= 2020.4
Returns the raw image size.

= fillRect =
* '''Version''': FlightGear >= 2020.1
* '''Format''': fillRect(dimension, color)
* '''Dimension Format''': Can be a vector of size 4 [x_position,y_position,x_size,y_size]. The numbers is in absolute pixel coordinates, not 0 to 1.
* '''Color Format''': Can be a vector of size 3 or 4 (rgba as 0 to 1). Or a string with hexadecimal colors, for example "#7f3f1f".
Will fill a specified rectangle inside the image with a specified color.

= Properties =

Additionally to the properties supported by every [[Canvas Element]], Canvas Images support the following properties:

== src ==

* '''Version''': FlightGear >= 3.1
* '''Format''': [<protocol>://]<path> (Supported protocols: canvas://, <nowiki>http://</nowiki>)

<syntaxhighlight lang="nasal">
# Use file inside default search paths
img.set("src", "gui/dialogs/images/exit.png");

# Show canvas with index 3
img.set("src", "canvas://by-index/texture[3]");

# Download and show FlightGear logo
img.set("src", "http://wiki.flightgear.org/skins/common/images/icons-fg-135.png");

# Show canvas available as object
img.set("src", my_canvas.getPath());
</syntaxhighlight>

== x/y ==
== size ==

== fill ==

* '''Format''': <color> (#rrggbb | rgb(r, g, b) | rgba(r, g, b, a))
where r, g, b must be in range 0 - 255 and a must be in range 0.0 - 1.0.
*'''Default''': #ffffff (white)

Image background color. Each pixel is modulated with the background color. If the image shall be displayed unchanged use white as background color.

<syntaxhighlight lang="nasal">
# White with alpha of 0.5 (=half transparent)
img.set("fill", "rgba(255,255,255,0.5)");

# red completely opaque
img.set("fill", "#ff0000");
</syntaxhighlight>

== slice ==

* '''Format''': [<number>%?]{1,4} fill?
* '''Default''': (empty) (disabled)

Image slicing (or scale-9, 9-slice) is a technique for dividing an image into nine regions. While scaling such an image the four corner regions will be shown undistorted, whereas the other regions are scaled to fit into the remaining parts. See the CSS3 [https://www.w3.org/TR/css-backgrounds-3/#the-border-image-slice border-image-slice] property for more information.

<syntaxhighlight lang="nasal">
# Top/bottom offset 10%, left/right offset 5%, fill center
img.set("slice", "10% 5% fill");

# All offsets 8 pixels, only draw border and do not fill center
img.set("slice", "8");

# Disable slicing
img.set("slice", "");
</syntaxhighlight>

== outset ==

* '''Format''': [<number>%?]{1,4}
* '''Default''': (empty) (disabled)

Let the image extend outside its specified size. The areas extending outside the original dimensions are just drawn but not included in the bounding box, and therefore ignored for event handling and distance/margin calculations. This could be used, for example, to draw a shadow around an element which is ignored for handling events.

<syntaxhighlight lang="nasal">
# Top outset 10%, left/right outset 5%, bottom outset 10 pixels
img.set("outset", "10% 5% 10");

# All offsets 8 pixels
img.set("outset", "8");

# Disable outset
img.set("outset", "");
</syntaxhighlight>

== file (deprecated) ==

* '''Version''': FlightGear <= 3.0

Same as ''src''. Use ''src'' with FlightGear >= 3.1.

Talk:Virtual Reality

2023-01-10T07:49:45Z

Necolatis: Question

== Nightly ==
Is the Windows Nightly binary compiled with osgXR? So in theory just have to start SteamVR and enable the VR setting in Flightgear?

FlightGear Newsletter December 2022

2022-12-21T13:37:43Z

Necolatis: /* In the hangar */ Added 3 updated aircraft

{{User:Skybike/Template:Newsletter-header-translate|2022-12}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

''The new Visual Editor makes editing the wiki as simple as using a Word-processor, and even easier than using the forum as you don't even need to know the syntax for a url. Just hit the 'edit' link and start.''

== Development news ==






== In the hangar ==



=== Updated aircraft ===
The Saab Viggen was updated to version 3.5.1 (2020.3.xx and 2020.4.0).

The F-16 was updated to version 2.71 (2020.3.xx).

The S-75 was updated with new guidance system.





== Scenery corner ==
















== Help wanted ==
{{Help wanted}}

== AI ==


The AI team makes FlightGear more realistic, colorful and lively every month. You can support the development of ''Interactive Traffic'' and contribute at the FlightGear {{forum link|title=AI|f=23}}.



== Community news ==



=== Forum news ===

A new '''Logbook add-on''' has been released that automatically logs our flights to a CSV file. The add-on also includes a GUI written in Canvas, with which you can view the log, edit entries and delete them. For read more please visit the [https://forum.flightgear.org/viewtopic.php?t=41070 forum topic] or [[Logbook_Add-on|wiki]] page.

[[File:Logbook-v.1.1.0.png|thumb|Logbook add-on - main logbook window and secondary with details of single entry, with "dark" theme]]
[[File:Logbook-v.1.1.0-edit-field.png|thumb|Logbook add-on - editing one of the fields with "Light" theme]]




=== FlightGear on Facebook ===
Since early December 2010, FlightGear has an [https://www.facebook.com/FlightGear official Facebook page]. If you have a Facebook account please feel free to join the page.

=== FlightGear on Instagram ===
In January 2018 the [https://www.instagram.com/flightgear_sim/ @flightgear_sim Instagram account] was brought back to life. If you've got nice screenshots to be featured, feel free to {{forum link|text=contact the maintainer|t=33636}}.

=== FlightGear on FlightSim.com ===
FlightGear has also a [https://www.flightsim.com/vbfs/forumdisplay.php?102-FlightGear sub-forum] on flightsim.com - just like the commercial flight sims. It is an opportunity to showcase what FG can do, get people curious and answer any questions they may have with regard to the software or the project.

== Multiplayer events ==









== Contributing ==
=== Translators needed ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====

If you want to participate in the screenshot contest, you can submit your candidate to the {{forum link|title=this|f=88|t=}}. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.

''Thanks for reading {{PAGENAME}}!''

{{Appendix}}


[[Category:Changes after 2020.3]]
[[Category:FlightGear Newsletter|2022 12]]

Changelog 2020.3

2022-11-26T13:37:46Z

Necolatis: /* 2020.3.13+ */ Scoured the mailing list for info, and found some bits.

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

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

Please help us translate into other languages!

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

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

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

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

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

FlightGear - Fly Free!

----

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

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

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

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

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

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

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

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

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

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

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

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

=Updates since 2020.3.0=

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

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

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

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

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

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

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

== 2020.3.7 ==

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

== 2020.3.8 ==

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

== 2020.3.9 ==

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

== 2020.3.10 ==

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

== 2020.3.11 ==

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

== 2020.3.12 ==

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

== 2020.3.13 ==

* Fix for the disappearing MP pilot list

== 2020.3.14 ==

* Support for add-on paths
* Instant audio queue
* Support for canvas display focus change

== 2020.3.15 ==

* Fix radio audio morse issue.

== 2020.3.16 ==

* Fix audio indent issue.

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

== References ==
{{Appendix}}

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

General Dynamics F-16 Fighting Falcon/info

2022-01-21T04:45:55Z

Necolatis:

<includeonly>{{infobox aircraft
| name = General Dynamics F-16 Fighting Falcon
| hangar = fgaddon
| aircraft = f16
| image = F-16C KLSV.jpg
| image2 = F-16C Cockpit.png
| alt2 = {{LangSwitch
| en = F-16CG Cockpit view
| de = F-16CG cockpit aussicht
}}
| type = Military aircraft/Attack aircraft/Fighter aircraft
| config = Retractable gear aircraft
| propulsion = Single-engine jet
| manufacturer = General Dynamics/Lockheed
| authors = Erik Hofman/Pensacola/Martin "Pegasus" Schmitt/Nikolai V. Chr./J Maverick 16/Richard Harrison/Josh Davidson/Martien Van Der P./Gary Brown/Justin Nicholson/legoboyvdlp/Timi/Enrico Castaldi
| fdm = JSBSim
| fgname1 = f16-block-10
| fgname2 = f16-block-20
| fgname3 = f16-block-30
| fgname4 = f16-block-32
| fgname5 = f16-block-40
| fgname6 = f16-block-42
| fgname7 = f16-block-50
| fgname8 = f16-block-52
| fgname9 = f16-block-60
| fgname10 = f16-simplified
| fgname11 = YF-16
| status-fdm = 5
| status-systems = 4
| status-cockpit = 4
| status-model = 4
| ready = airrefuel/canvas/checklist
| liverydbid = 20
| license = GPLv2+
| forumtid = 2003
| manual = https://github.com/NikolaiVChr/f16/wiki
| navbar = 1
}}
</includeonly><noinclude>
This is the aircraft infobox subpage of the [[General Dynamics F-16 Fighting Falcon]].
[[Category:Aircraft infobox documentation]]
</noinclude>

General Dynamics F-16 Fighting Falcon

2022-01-21T04:43:12Z

Necolatis:

{{:{{PAGENAME}}/info}}
The '''General Dynamics F-16 Fighting Falcon''' (nicknamed Viper by pilots) is a single-engine supersonic multirole fighter aircraft by General Dynamics, exported to many countries. Designed as an air superiority day fighter for the US Air Force, it evolved into a successful all-weather multirole aircraft.
The Fighting Falcon has key features including a frameless bubble canopy for better visibility, side-mounted control stick to ease control while maneuvering, a seat reclined 30 degrees to reduce the effect of g-forces on the pilot, and the first use of a relaxed static stability/fly-by-wire flight control system which helps to make it a nimble aircraft.

== Keyboard Controls ==
====Flight Controls====
{| class="keytable"
! Key
! Function
|-
|{{Key press|Ctrl|B}}
|Toggles speed brake
|-
|{{Key press|Delete}}
|Toggles FBW (fly by wire) override (F-16 Simplified)
|-
|{{Key press|Delete}}
|Toggles MPO
|}

====Radar====
{| class="keytable"
! Key
! Function
|-
|{{Key press|Shift|E}}
|Decreases radar range
|-
|{{Key press|Shift|R}}
|Increases radar range
|-
|{{Key press|R}}
|Toggles radar standby mode
|-
|{{Key press|Y}}
|Toggles next target
|-
|}

====Tactical====
{| class="keytable"
! Key
! Function
|-
|{{Key press|E}}
|Fires the cannon
|-
| {{Key press|Q}}
| Chaff/flare
|-
| {{Key press|M}}
| Master arm
|-
| {{Key press|W}}
| Cycle weapon
|}
====Miscellaneous====
{| class="keytable"
! Key
! Function
|-
|{{Key press|Ctrl|H}}
|Toggles arrester hook
|-
|{{Key press|Shift|C}}
|Toggles canopy
|-
| {{Key press|Q}}
| Reset cockpit view
|-
| {{Key press|Ctrl|Q}}
| View right MFD
|-
| {{Key press|Shift|W}}
| View left MFD and RWR
|-
|{{Key press|F}}
|Toggles refuel door
|-
| {{Key press|Shift|S}}
| Toggle smoke
|-
| {{Key press|U}}
| Seat up
|-
| {{Key press|Shift|U}}
| Seat down
|}

== Features ==
=== Canvas HUD ===
[[File:Canvasready.png|left|caption|link=Howto:Aerial refueling]] The F-16 has a canvas {{wikipedia|Head-Up Display}}.<br clear=all> 

=== Air-to-air refueling ===
[[File:Airrefuelingready.png|left|caption|link=Howto:Aerial refueling]]
The General Dynamics F-16 Fighting Falcon supports ''in-flight refueling''. You need to start a specific scenario or do that in multiplayer to get a tanker [[aircraft]]. See [[Howto:Aerial refueling]] for more information. Also look on the box at the [[{{PAGENAME}}#External link|bottom]] of the page.<br clear=all>

=== Aircraft carrier ===
[[File:Carrier3.jpg|left|150px|caption|link=Howto:Carrier]]
Although the Viper wasn't designed for maritime operations, there is the possibility to start from and land on a [[Aircraft carrier|carrier]]. You can toggle the '''arrester hook''' with {{Key press|Ctrl|H}}. There are several [[Aircraft carrier]] available. How to set it up start your aircraft there is described in '''[[Howto:Carrier]]'''. If you fly in multiplayer mode see [[Carrier over MP]]<br clear=all>
[[File:F-16 AV029.JPG|thumb|400px|'''F-16''' taxiing to parking at [[LIPA]] after landing on rwy 05 with home livery]] [[File:F-16 RNLAF J015-demo 3.png|thumb|400px|The RNLAF J015-demo livery of the F-16]]

== Video tutorials ==

{{#ev:youtube|iSkxDhy8-zk}}

{{#ev:youtube|uN6pddgHaog}}

{{#ev:youtube|AjTw77d_lzo}}

{{#ev:youtube|Dd1Ddqr8-A0}}

== New to fighter aircraft ==
If you have never flown an aircraft like this one before (Just light planes or airliners), crashed it before landing or just are not sure, how to land a right way; there is an article ''[[A-4F Skyhawk Operations Manual]]'' by Andy Ross. Although is written for the [[Douglas A-4]] most of the information contain general stuff about fly delta wing aircraft, about stall, AoA and landing maneuver and applies to the F-16 too.

[[File:F16-cockpit-pano.jpg|480px|thumb|center|[[Howto: Make full spherical panorama|A full spherical panorama]] of the f-16 cockpit]]

== Development Status ==
{{Main article|F16/Development}}

== External link ==
* [http://brenthugh.com/flightgear/Sun_Valley_Tank_Invasion1.zip Several ground bombing scenarios suitable for the F-16, involving moving and static tank formations, explodable M1 Abrams tanks, etc.]
* [https://github.com/NikolaiVChr/f16/wiki Flightgear F-16 Manual]

[[Category:Military aircraft]]

{{Lockheed}}
{{air-to-air refueling}}

[[Category:Fighter aircraft]]
[[de:General Dynamics F-16 Fighting Falcon]]
[[fr:General Dynamics F-16]]

Talk:High-Level Architecture

2022-01-05T23:54:49Z

Necolatis: Another GPL 2.0 RTI

==== Another GPL 2.0 RTI ====
If the block for this was getting the RTI done, there is another GPL RTI out there.

https://github.com/etopzone/CERTI

--[[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 23:54, 5 January 2022 (UTC)

User talk:Jsb

2021-06-14T22:08:52Z

Necolatis: Re-loading multi

In Nasal runtime re-loadable modules, how do I set more than 1 nasal file to be loaded?
I have 3 nas files, all belong together in same namespace. And would like to load them as one. --[[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 22:08, 14 June 2021 (UTC)

FlightGear Newsletter May 2021

2021-05-17T09:08:22Z

Necolatis: /* Updated aircraft */ F-16

{{User:Skybike/Template:Newsletter-header-translate|2021-05}}
{{TOC_right|limit=2}}
''We would like to emphasize that the monthly newsletter cannot live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) is welcome to contribute to the newsletter. If you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.''

== Development news ==





{{Note|FG is currently undergoing a lot of huge changes. More importantly: moving to the OpenGL core profile, WS 3.0, osm2city buildings, photoscenery and Compositor shadows&lights.<ref>https://sourceforge.net/p/flightgear/codetickets/2560/#76c9</ref> It is likely the non-shader code path (fixed-function pipeline) will also go away in the next twelve months (~ early/mid 2022). We tried to communicate this: 2020.3 is the last release that will work on really old hardware: 'next' and future releases will need a more modern machine with an OpenGL 4 / DX12 class GPU.<ref>https://sourceforge.net/p/flightgear/codetickets/2560/#f6f6</ref> 'next' is work-in-progress: likely 12 or 18 months before it becomes a release. In that time the minimum system requirements, performance baseline and basically everything else are going to change (and keep changing). Of course we'll try to make it work on as wide a range of hardware as possible, but right now we don't know, and it would be incorrect to speculate or promise anything. (Eg, we cannot say 'an Intel 4000 will work but an Intel 3000 won't - we have no idea!)

If next works for someone, that is great, but if you want stability, stable FPS and comaptability with older hardware, there is an easy answer: use 2020.3. That's what we recommend for everyone who wants to fly and enjoy flying. <ref>https://sourceforge.net/p/flightgear/codetickets/2560/#5802</ref>}}

=== Text animations and OSG 3.6 ===
Fernando pushed two commits to simgear and fgdata that should hopefully fix the [[OSGText Issues|white osgText issue under OSG 3.6]]. Apparently assigning an Effect to the geode containing the osgText was enough to get it working. He thought it would conflict with OSG internal shaders, but it didn't. This might not be the case with the core profile, but has got a few tricks which should force our shaders to prevail over OSG's.

Anyway, Fernando tested it and it looks fine to him. If someone who is more used to using osgText can report if the fix was successful and the text looks exactly the same as before, it would be greatly appreciated.<ref>https://sourceforge.net/p/flightgear/mailman/message/37282835/</ref>

It is vital that people report back if this fix works for them or not, since the osgText issue has been preventing us from adopting OSG 3.6, and OSG 3.6 can be considered a prerequisite for some other core development efforts, namely [[WS30]], [[Compositor]] and [[CompositeViewer Support]] - furthermore, once we can safely require OSG 3.6, it is also much more likely that we'll get support for [[Hackathon Proposal: CompositeViewer and Canvas|Canvas Cameras]] (for features like tail cams, rear view mirrors, shuttle RMS arm etc).

Thus, please report back via the developers mailing list and/or the issue tracker.

== In the hangar ==



[[File:H130 update.jpg|thumb|EC 130 B4 sitting on the tarmac in dawn with lights on- showing [[Compositor|compositor lights]] with [[Atmospheric light scattering|ALS]] and [[Advanced weather]]]]
[[File:H130 RotorWashEffect.jpg|thumb|Airbus H130 T2 hovering above a lake on Hawaii near PHNL]]

The [[Eurocopter EC130 B4]] and [[Eurocopter EC 135]] helicopters are quite popular among helicopter fans in FlightGear. It´s main author and long term aircraft developer [[User:HHS|HHS]], whose work in models, fdm, systems and instruments is used by many other helicopter and aircraft projects, is currently working on updating them. With the [[Compositor|compositor pipeline]], it is now possible to have shadows, lights and [[Atmospheric light scattering|ALS]] all together- the aircraft needs some changes to make them work with. There will be also many other improvements. You can expect the finish results around early summer in [[FGAddon]]. Stay tuned!

== Updated aircraft ==
=== Pottier P130 ===
The [[Pottier P130 UltraLight]] has received a new, [[JSBSim]] FDM as well as a lot of fixes and systems updates, based on the little data that is available.
=== Diamond HK36 ===
The [[Diamond HK36]] got also various fixes and additionally its interior was substantially improved, featuring now a detailed engine control quadrant and more. It also comes with another variant now, the -TC with a Rotax 912 engine.
=== F-16 ===
The [[General Dynamics F-16 Fighting Falcon]] has been updated, this is some of the changes:
* Helmet mounted off-bore display
* Forward looking Infrared (FLIR) capability in the HUD.
* Reworked steerpoint, markpoint, bulls-eye, threat-circles system.
* Link16 by Colin, including possibility to send any points over the datalink.
* Auto release program for chaff and flares.
* CCIP aiming for hydra rockets.
* New cannon aiming mode: STRF (strafe).
* Bunch of new liveries by Bat.





== Scenery corner ==
















== Help wanted ==
{{Help wanted}}

== AI ==


The AI team makes FlightGear more realistic, colorful and lively every month. You can support the development of ''Interactive Traffic'' and contribute at the FlightGear {{forum link|title=AI|f=23}}.



== Community news ==








=== FlightGear on Facebook ===
Since early December 2010, FlightGear has an [https://www.facebook.com/FlightGear official Facebook page]. If you have a Facebook account please feel free to join the page.

=== FlightGear on Instagram ===
In January 2018 the [https://www.instagram.com/flightgear_sim/ @flightgear_sim Instagram account] was brought back to life. If you've got nice screenshots to be featured, feel free to {{forum link|text=contact the maintainer|t=33636}}.

=== FlightGear on FlightSim.com ===
FlightGear has also a [https://www.flightsim.com/vbfs/forumdisplay.php?102-FlightGear sub-forum] on flightsim.com - just like the commercial flight sims. It is an opportunity to showcase what FG can do, get people curious and answer any questions they may have with regard to the software or the project.

== Multiplayer events ==









== Contributing ==
=== Translators needed ===
{|
| [[File:en.gif]]
| The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multilingual, you can start by looking at [[Help:Translate]].
|-
| [[File:fr.gif]]
| Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire [[:fr:Help:Traduire|Help:Traduire]].
|-
| [[File:de.gif]]
| Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki mehrsprachig zu machen, dann fang mit dem [[:de:Help:Übersetzen|Help:Übersetzen]] an.
|-
| [[File:nl.gif]]
| De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij [[:nl:Help:Vertalen|Help:Vertalen]].
|-
| [[File:es.gif]]
| La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en [[:es:Help:Traducir|Help:Traducir]].
|-
| [[File:cat.gif]]
| La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a [[:ca:Help:Traduir|Help:Traduir]].
|-
| [[File:pt.gif]]
| A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em [[:pt:Help:Traduzir|Help:Traduzir]].
|-
| [[File:zh.gif]]
| FlightGear 百科仍然需要志愿者将其翻译为各种语言。如果你有兴趣让FlightGear百科支持更多语言, 你可以查看 [[Help:Translate]].
|}

=== FlightGear logos ===
If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit [[FlightGear logos]] for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

=== Screenshots ===
The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings ([[anti-aliasing]], texture sharpening, etc.). More info at [[Howto:Make nice screenshots]].

==== Screenshot of the Month ====

If you want to participate in the screenshot contest, you can submit your candidate to the {{forum link|title=this|f=88|t=}}. Be sure to see the first post for participation rules. For purposes of convenience and organization, at the end of the month or after 20 entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there.

''Thanks for reading {{PAGENAME}}!''

{{Appendix}}


[[Category:Changes after 2020.3]]
[[Category:FlightGear Newsletter|2021 05]]

Howto:Configure views in FlightGear

2020-10-18T04:25:13Z

Necolatis: /* Changes in 2020.3.1 to eye position */

{{merge|Howto:Set view points|date=March 2016}}

This mini-HOWTO explains how to configure views in FlightGear. Views define the position of the eye in the rendered scene and what if any object the eye is focused on or tracking. The eye is the imaginary or constructed eye that is simulated by the 3D rendering. It makes the picture on your screen represent what things would look like if you were standing or sitting at a given location.

Formerly there were two views hard coded into FlightGear, but as this document describes, it is possible to configure any number of views with XML configuration files. Views may be configured to switch between pilot and co-pilot, tower view, or view of an observer on the ground.

== Types of Views ==
There are two basic types of views:

* '''LookFrom''' - This type requires a single coordinate position. The direction of the view is independent of any particular object. Adjusting the heading and pitch offsets moves the direction of observation around. In the default FlightGear configuration panning with the mouse will move the view around as if the observer was turning their head.
* '''LookAt''' - This type requires two coordinate positions. The direction of the view is always oriented toward a target and tracks the target if it moves.

(see configuration examples below for usage of the <type> paramter)

== Defining Positions ==
There are two methods to define a postion and orientation for use in configuring a view. One method is tied to a model which means the view references the position and orientation of a model (e.g. Aircraft 3D Model) and the other is an independent postion which simply means that the view references location data directly (via the FlightGear property tree):

=== Tied to a Model ===
This method allows definition of the "eye", that is where you are looking from and/or the "target" or objected being looked at based on a model position and orientation. The following illustrates defining the positon of a "Cockpit View" that is positioned and oriented according to the position and orientation of a model:

<sim>
<view>
<name>Cockpit View</name>
<type>lookfrom</type>
<internal type="bool">true</internal>
<config>
<from-model type="bool">true</from-model>
<from-model-idx type="int">0</from-model-idx>
</config>
</view>
</sim>

Syntax for the '''eye position''' is:

<from-model type="bool">true or false</from-model>
<from-model-idx type="int">modelnumber</from-model-idx>

Syntax for the target or '''at position''' used in views of type "lookat" is:

<at-model type="bool">true or false</at-model>
<at-model-idx type="int">modelnumber</at-model-idx>

Note that from-model or at-model must be true in order for the position and orientation data from the model to be used.

=== Independent Position ===
This method allows definition of the eye, that is where you are looking from or the target (objected being looked at) based on arbitrary position and orientation data obtained from the property tree (i.e. any source). The following illustrates a Tower defined as a "lookat", a view that can be used to track or follow a moving model:

<sim>
<view>
<name>Tower View</name>
<type>lookat</type>
<config>
<eye-lat-deg-path>/sim/tower/latitude-deg</eye-lat-deg-path>
<eye-lon-deg-path>/sim/tower/longitude-deg</eye-lon-deg-path>
<eye-alt-ft-path>/sim/tower/altitude-ft</eye-alt-ft-path>
<eye-roll-deg-path>/sim/tower/roll-deg</eye-roll-deg-path>
<eye-pitch-deg-path>/sim/tower/pitch-deg</eye-pitch-deg-path>
<eye-heading-deg-path>/sim/tower/heading-deg</eye-heading-deg-path>

<at-model type="bool">true</at-model>
<at-model-idx type="int">0</at-model-idx>

</config>
</view>
</sim>

Note that the definition is constructed as a path to a numeric data item in the global property tree. If you are unfamiliar with these properties, take a look at the "Property Picker" dialog while FlightGear is running and you can see the kinds of values in use. You may define your own static values, say for a fixed location of an observer, by adding the following xml to your setup (prefrences.xml or another file):

<somepath>
<ground-observer-lon-deg>48.6124</ground-observer-lon-deg>
<ground-observer-lat-deg>63.1243</ground-observer-lat-deg>
<ground-observer-alt-ft>123.5</ground-observer-alt-ft>
</somepath>

These values can then then be referenced in your view by including their path in the definition. For example to reference the above longitude for the ground observer:

<sim>
<view>
<config>
<eye-lat-deg-path>/somepath/ground-observer-lat-deg></eye-lon-deg-path>
..

All three longitude, latitude, and altitude must be defined to have a valid position (otherwise the missing items default to 0). You may also define orientation such as heading (the direction to look toward) and pitch (the angle up or down to be looking). In the case of a cockpit view the orientation will be that of the aircraft itself, but in the case of a "lookfrom" view like a ground observer or tower it can be an arbitrary view direction that is either static, or changing.

Syntax for the '''eye position and orientation''' is:

<eye-lat-deg-path>path-to-property-value</eye-lat-deg-path>
<eye-lon-deg-path>path-to-property-value</eye-lon-deg-path>
<eye-alt-ft-path>path-to-property-value</eye-alt-ft-path>
<eye-roll-deg-path>path-to-property-value</eye-roll-deg-path>
<eye-pitch-deg-path>path-to-property-value</eye-pitch-deg-path>
<eye-heading-deg-path>path-to-property-value</eye-heading-deg-path>

Syntax for the target or '''at position''' used in views of type "lookat" is:

<target-lat-deg-path>path-to-property-value</target-lat-deg-path>
<target-lon-deg-path>path-to-property-value</target-lon-deg-path>
<target-alt-ft-path>path-to-property-value</target-alt-ft-path>

== View Offsets ==
There are two types of offsets, but only one is used in building viewer configurations. This is an offset from the eye position applied to the position defined for the eye as described in the section on '''Defining Positon'''.

These offsets are defined in meters. Here is an example of a '''Cockpit View''' definition that includes offsets for the pilot's eye:

<sim>
<view>
<name>Cockpit View</name>
<type>lookfrom</type>
<internal type="bool">false</internal>
<config>
<from-model type="bool">true</from-model>
<from-model-idx type="int">0</from-model-idx>

<x-offset-m type="double">-0.22</x-offset-m>
<y-offset-m type="double">0.30</y-offset-m>
<z-offset-m type="double">-0.45</z-offset-m>
</config>
</view>
</sim>

Note that these offsets are actually best applied differently to specific aircraft models. The size of the aircraft and the actual position of the pilot's seat make a big difference. So typically these offset entries are included per aircraft in the aircraft-set.xml files.

In other circumstances, such as defining a Chase View, you can possibly get away with defining the x-offsets in a more global location so that they apply to all aircraft. Here is an example of a Chase View configuration that includes offsets to define the eye as being 25 meters behind the model origin:

<sim>
<view>
<name>Chase View</name>
<type>lookat</type>
<config>
<from-model type="bool">true</from-model>
<from-model-idx type="int">0</from-model-idx>
<at-model type="bool">true</at-model>
<at-model-idx type="int">0</at-model-idx>

<x-offset-m type="double">0</x-offset-m>
<y-offset-m type="double">0</y-offset-m>
<z-offset-m type="double">-25</z-offset-m>
</config>
</view>
</sim>

At the time of this writing (and this is subject to change), offsets define the change in eye position as follows:

x-offset-m
Positive values to the right of origin (view position).
y-offset-m
Positive values move up from origin.
z-offset-m
Positive values move back (or in) from origin.

Generally, a higher Near Plane value will result in a better quality rendering of distant scenery and models. Currently when the aircraft is in flight the Near Plane is set at 10 meters.

Any object (including terrain) that is closer to the eye or camera than 10 meters will not be visible. For this reason, when the eye is close to the ground, the Near Plane must be set lower. Here is an example of a Cockpit view that is configured to have only a 0.5 meter Near Plane when sitting on the ground (or below a given flight level which currently defaults to 30ft AGL altitude).

<view>
<name>Cockpit View</name>
<type>lookfrom</type>
<internal type="bool">false</internal>
<config>
<from-model type="bool">true</from-model>
<from-model-idx type="int">0</from-model-idx>

<ground-level-nearplane-m type="double">0.5f</ground-level-nearplane-m>
</config>
</view>

The example Tower View however, is able to set the value to 10 meters since the tower position is 50ft AGL altitude to start with:

<view>
<name>Tower View</name>
<type>lookat</type>
<config>
<eye-lat-deg-path>/sim/tower/latitude-deg</eye-lat-deg-path>
<eye-lon-deg-path>/sim/tower/longitude-deg</eye-lon-deg-path>
<eye-alt-ft-path>/sim/tower/altitude-ft</eye-alt-ft-path>
<eye-roll-deg-path>/sim/tower/roll-deg</eye-roll-deg-path>
<eye-pitch-deg-path>/sim/tower/pitch-deg</eye-pitch-deg-path>
<eye-heading-deg-path>/sim/tower/heading-deg</eye-heading-deg-path>

<at-model type="bool">true</at-model>
<at-model-idx type="int">0</at-model-idx>

<ground-level-nearplane-m type="double">10.0f</ground-level-nearplane-m>

</config>
</view>

== Other examples ==

Example 1 - The configuration of a Chase View without a rotating frutstum (the view does not tilt with the aircraft's roll and pitch) is easy. Since the aircraft model's orientation is contained in it's location definition, you must set from-model property to false so you may define your own source for position and orientation. Then define eye position properties for the appropriate values. If you leave eye-roll-deg and eye-pitch-deg out then they will be fixed at 0 degrees. Note that technically this example does rotate, but only on the heading :)

<view>
<name>Chase View</name>
<type>lookat</type>
<config>
<from-model type="bool">false</from-model>
<from-model-idx type="int">0</from-model-idx>
<eye-lat-deg-path>/position/latitude-deg</eye-lat-deg-path>
<eye-lon-deg-path>/position/longitude-deg</eye-lon-deg-path>
<eye-alt-ft-path>/position/altitude-ft</eye-alt-ft-path>
<eye-heading-deg-path>/orientation/heading-deg</eye-heading-deg-path>

<at-model type="bool">true</at-model>
<at-model-idx type="int">0</at-model-idx>

<ground-level-nearplane-m type="double">0.5f</ground-level-nearplane-m>

<x-offset-m type="double">0</x-offset-m>
<y-offset-m type="double">0</y-offset-m>
<z-offset-m type="double">-25</z-offset-m>
</config>
</view>

== Changes in 2020.3.1 to eye position ==

To make eye views work like in earlier Flightgear version you can add this:

<syntaxhighlight lang="xml">
<eye-fixed type="bool">true</eye-fixed>
</syntaxhighlight>

== Related content ==
* For some basic info about defining views see [[Howto:Set view points]]
* To make parts of the aircraft only appear in a specific view, read the [[Howto: Objects visible according to views]]
[[Category:Howto|Configure views in FlightGear]]

User:Necolatis

2020-10-16T03:12:51Z

Necolatis:

Effect framework

2020-05-12T14:49:24Z

Necolatis: /* program */ added uniform-block-binding

{{forum|47|Effects & Shaders}}
{{Rendering}}
The effect framework as per version 2020.1

Effects describe the graphical appearance of 3D objects and scenery in
FlightGear. The main motivation for effects is to support OpenGL
shaders and to provide different implementations for graphics hardware
of varying capabilities. Effects are similar to DirectX effects files
and Ogre3D material scripts.

An effect is a property list. The property list syntax is extended
with new "vec3d" and "vec4d" types to support common computer graphics
values. Effects are read from files with a ".eff" extension or can be
created on-the-fly by FlightGear at runtime. An effect consists of a
"parameters" section followed by "technique" descriptions. The
"parameters" section is a tree of values that describe, abstractly,
the graphical characteristics of objects that use the effect. Techniques
refer to these parameters and use them to set OpenGL state or to set
parameters for shader programs. The names of properties in the
parameter section can be whatever the effects author chooses, although
some standard parameters are set by FlightGear itself. On the other
hand, the properties in the techniques section are all defined by the
FlightGear.

== Default Effects in Terrain Materials and Models ==
Effects for terrain work in this way: for each material type in
materials.xml an effect is created that inherits from a single default
terrain effect, Effects/terrain-default.eff. The parameters section of
the effect is filled in using the ambient, diffuse, specular,
emissive, shininess, and transparent fields of the material. The
parameters image, filter, wrap-s, and wrap-t are also initialized from
the material xml. Seperate effects are created for each texture
variant of a material.

Model effects are created by walking the OpenSceneGraph scene graph
for a model and replacing nodes (osg::Geode) that have state sets with
node that uses an effect instead. Again, a small effect is created
with parameters extracted from OSG objects; this effect inherits, by
default, from Effects/model-default.eff. A larger set of parameters is
created for model effects than for terrain because there is more
variation possible from the OSG model loaders than from the terrain
system. The parameters created are:

* material active, ambient, diffuse, specular, emissive, shininess, color mode
# blend active, source, destination
# shade-model
# cull-face
* rendering-hint
* texture type, image, filter, wrap-s, wrap-t

== Specifying Custom Effects ==
You can specify the effects that will be used by FlightGear as the
base effect when it creates terrain and model effects.

In the terrain materials.xml, an "effect" property specifies the name
of the model to use.

Material animations will be implemented by creating a new effect
that inherits from one in a model, overriding the parameters that
will be animated.

== Examples ==
The $FGDATA/Effects directory contains the effects definitions; look there for
examples. Effects/crop.eff is a good example of a complex effect.

== Application ==
To apply an effect to a model or part of a model use:

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/light-cone</inherits-from>
<object-name>Cone</object-name>
</effect>
</syntaxhighlight>

where <inherits-from> </inherits-from> contains the path to the effect you want to apply.
The effect does not need the file extension.

=== Parameters in model file ===

Parameters can be put into the model files effect application as well. But only bool, int, float, string can be used there.

=== Chrome old usage ===

Chrome, although now implemented as an effect, still retains the old method of application:

<syntaxhighlight lang="xml">
<animation>
<type>shader</type>
<shader>chrome</shader>
<texture>glass_shader.png</texture>
<object-name>windscreen</object-name>
</animation>
</syntaxhighlight>

in order to maintain backward compatibility.

== Reload effects at runtime ==
To reload an effect applied in a model xml file (e.g. some parameters and what it enherits from) just go into debug menu and select Reload Model.

To reload the entire effect framework including eff files, go into menu and debug and configure development extensions and reload shaders. This is broken in 2020.1 though, but works in earlier FG versions.

== The xml tags of an effect ==

=== name ===
The name of the effect

=== inherits-from ===
One feature not fully illustrated in the sample below is that
effects can inherit from each other. The parent effect is listed in
the "inherits-from" form. The child effect's property tree is
overlaid over that of the parent. Nodes that have the same name and
property index -- set by the "n=" attribute in the property tag --
are recursively merged. Leaf property nodes from the child have
precedence. This means that effects that inherit from the example
effect below could be very short, listing just new
parameters and adding nothing to the techniques section;
alternatively, a technique could be altered or customized in a
child, listing (for example) a different shader program. An example
showing inheritance Effects/crop.eff, which inherits some if its
values from Effects/terrain-default.eff.

FlightGear directly uses effects inheritance to assign effects to 3D
models and terrain. As described below, at runtime small effects are
created that contain material and texture values in a "parameters"
section. These effects inherit from another effect which references
those parameters in its "techniques" section. The derived effect
overrides any default values that might be in the base effect's
parameters section.

=== Parameters ===
Custom parameters that controls the effect.

Note that parameters can use the <use> tags to enable properties to specify the values.

=== Generate ===

Often shader effects need tangent vectors to work properly. These
tangent vectors, usually called tangent and binormal, are computed
on the CPU and given to the shader as vertex attributes. These
vectors are computed on demand on the geometry using the effect if
the 'generate' clause is present in the effect file. Exemple :

<syntaxhighlight lang="xml">
<generate>
<tangent type="int">6</tangent>
<binormal type="int">7</binormal>
<normal type="int">8</normal>
</generate>
</syntaxhighlight>

Valid subnodes of 'generate' are 'tangent', 'binormal' or 'normal'.
The integer value of these subnode is the index of the attribute
that will hold the value of the vec3 vector.

The generate clause is located under PropertyList in the xml file.

In order to be available for the vertex shader, these data should
be bound to an attribute in the program clause, like this :

<syntaxhighlight lang="xml">
<program>
<vertex-shader>my_vertex_shader</vertex-shader>
<attribute>
<name>my_tangent_attribute</name>
<index>6</index>
</attribute>
<attribute>
<name>my_binormal_attribute</name>
<index>7</index>
</attribute>
</program>
</syntaxhighlight>

attribute names are whatever the shader use. The index is the one
declared in the 'generate' clause. So because generate/tangent has
value 6 and my_tangent_attribute has index 6, my_tangent_attribute
holds the tangent value for the vertex.

=== technique ===
A certain way of rendering this effect. Different pipelines typically have their own techniques.

==== scheme ====
Since 2020.1, is only usable in Compositor build.

For the compositor ALS pipeline a scheme of als-lightning has to be specified for the technique to be considered for rendering.

Example:

<syntaxhighlight lang="xml">
<scheme>als-lighting</scheme>
</syntaxhighlight>

==== predicate ====
A technique can contain a predicate that describes the OpenGL
functionality required to support the technique. The first
technique with a valid predicate in the list of techniques is used
to set up the graphics state of the effect. A technique with no
predicate is always assumed to be valid. The predicate is written in a
little expression language that supports the following primitives:

and, or, equal, less, less-equal
glversion - returns the version number of OpenGL
extension-supported - returns true if an OpenGL extension is supported
property - returns the boolean value of a property
float-property - returns the float value of a property, useful inside equal, less or less-equal nodes
shader-language - returns the version of GLSL supported, or 0 if there is none.

The proper way to test whether to enable a shader-based technique is:
<syntaxhighlight lang="xml">
<predicate>
<and>
<property>/sim/rendering/shader-effects</property>
<less-equal>
<value type="float">1.0</value>
<shader-language/>
</less-equal>
</and>
</predicate>
</syntaxhighlight>

There is also a property set by the user to indicate what is the level
of quality desired. This level of quality can be checked in the predicate
like this :
<syntaxhighlight lang="xml">
<predicate>
<and>
<property>/sim/rendering/shader-effects</property>
<less-equal>
<value type="float">2.0</value>
<float-property>/sim/rendering/quality-level</float-property>
</less-equal>

</and>
</predicate>
</syntaxhighlight>

The range of /sim/rendering/quality-level is [0..5]
* 2.0 is the threshold for relief mapping effects,
* 4.0 is the threshold for geometry shader usage.

Example:

<syntaxhighlight lang="xml">
<predicate>
<and>
<property>/sim/rendering/shaders/quality-level</property>
<property>/sim/rendering/shaders/model</property>
<or>
<less-equal>
<value type="float">2.0</value>
<glversion/>
</less-equal>
<and>
<extension-supported>GL_ARB_shader_objects</extension-supported>
<extension-supported>GL_ARB_shading_language_100</extension-supported>
<extension-supported>GL_ARB_vertex_shader</extension-supported>
<extension-supported>GL_ARB_fragment_shader</extension-supported>
</and>
</or>
</and>
</predicate>
</syntaxhighlight>

==== pass ====
A technique can consist of several passes. A pass is basically an Open
Scene Graph StateSet. Ultimately all OpenGL and OSG modes and state
attributes will be accessable in techniques. State attributes -- that
is, technique properties that have children and are not just boolean
modes -- have an <active> parameter which enables or disables the
attribute. In this way a technique can declare parameters it needs,
but not enable the attribute at all if it is not needed; the decision
can be based on a parameter in the parameters section of the
effect. For example, effects that support transparent and opaque
geometry could have as part of a technique:

<syntaxhighlight lang="xml">
<blend>
<active><use>blend/active</use></active>
<source>src-alpha</source>
<destination>one-minus-src-alpha</destination>
</blend>
</syntaxhighlight>

So if the blend/active parameter is true blending will be activated
using the usual blending equation; otherwise blending is disabled.

Values are assigned to technique properties in several ways:

* They can appear directly in the techniques section as a
constant. For example:
<syntaxhighlight lang="xml">
<uniform>
<name>ColorsTex</name>
<type>sampler-1d</type>
<value type="int">2</value>
</uniform>
</syntaxhighlight>
* The name of a property in the parameters section can be
referenced using a "use" clause. For example, in the technique
section:
<syntaxhighlight lang="xml">
<material>
<ambient><use>material/ambient</use></ambient>
</material>
</syntaxhighlight>
Then, in the parameters section of the effect:
<syntaxhighlight lang="xml">
<parameters>
<material>
<ambient type="vec4d">0.2 0.2 0.2 1.0</ambient>
</material>
</parameters>
</syntaxhighlight>
It's worth pointing out that the "material" property in a
technique specifies part of OpenGL's state, whereas "material"
in the parameters section is just a name, part of a
hierarchical namespace.

* A property in the parameters section doesn't need to contain
a constant value; it can also contain a "use" property. Here
the value of the use clause is the name of a node in an
external property tree which will be used as the source of a
value. If the name begins with '/', the node is in
FlightGear's global property tree; otherwise, it is in a local
property tree, usually belonging to a model [NOT IMPLEMENTED
YET]. For example:
<syntaxhighlight lang="xml">
<parameters>
<chrome-light><use>/rendering/scene/chrome-light</use></chrome-light>
</parameters>
</syntaxhighlight>
The type is determined by what is expected by the technique
attribute that will ultimately receive the value. [There is
no way to get vector values out of the main property system
yet; this will be fixed shortly.] Values that are declared
this way are dynamically updated if the property node
changes.

===== lighting =====
true or false

===== material =====
children: active, ambient, ambient-front, ambient-back, diffuse,
diffuse-front, diffuse-back, specular, specular-front,
specular-back, emissive, emissive-front, emissive-back, shininess,
shininess-front, shininess-back, color-mode

===== blend =====
Children: active, source, destination, source-rgb, source-alpha, destination-rgb, destination-alpha

Children values: dst-alpha, dst-color, one, one-minus-dst-alpha, one-minus-dst-color, one-minus-src-alpha, one-minus-src-color, src-alpha, src-alpha-saturate, src-color, constant-color, one-minus-constant-color, constant-alpha, one-minus-constant-alpha, zero

Example:
<syntaxhighlight lang="xml">
<blend>
<active>true</active>
<source>one-minus-dst-alpha</source>
<destination>src-alpha-saturate</destination>
</blend>
</syntaxhighlight>

===== blend (simple) =====
A blend tag with 0 will do nothing.
A blend tag with 1 will do the same as source-alpha: one-minus-dst-alpha, in other words it will enable z transparency using alpha from the fragment shader.

Example:
<syntaxhighlight lang="xml">
<blend>1</blend>
</syntaxhighlight>

===== shade-model =====
flat or smooth

===== cull-face =====
front, back, front-back, off

===== texture-unit =====
Example:

<syntaxhighlight lang="xml">
<texture-unit>
<unit>3</unit>
<image>Textures/Terrain/void.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<mag-filter>linear-mipmap-linear</mag-filter>
<wrap-s>repeat</wrap-s>
<wrap-t>repeat</wrap-t>
<wrap-r>repeat</wrap-r>
<internal-format>normalized</internal-format>
<mipmap-control>
<function-r>average</function-r>
<function-g>min</function-g>
<function-b>sum</function-b>
<function-a>product</function-a>
</mipmap-control>
<environment>
<mode>decal</mode>
<color>0.0 0.1 0.6 1.0</color>
</environment>
<point-sprite>true</point-sprite>
<texenv-combine>operand0-rgb</texenv-combine>
<texgen>
<mode>S</mode>
<planes>0.075, 0.0, 0.0, 0.5</planes>
</texgen>
</texture-unit>
</syntaxhighlight>

===== vertex-program-two-side =====
true or false

===== polygon-mode =====
children: front, back

Valid values: fill, line, point

===== vertex-program-point-size =====
true, false

===== uniform =====
Data accessible by shaders.

name: the name

type: bool, int, float, float-vec3, float-vec4, sampler-1d, sampler-2d, sampler-3d, sampler-1d-shadow, sampler-2d-shadow, sampler-cube

===== alpha-test =====

active: true, false

comparison: never, less, equal, lequal, greater, notequal, gequal, always

reference: 0 to 1

===== render-bin =====
Sent to OSG.

bin-number: This is an integer defining the order stuff will be rendered in, it can be negative also.

bin-name: RenderBin, DepthSortedBin

===== rendering-hint =====
Sent to OSG.

default, opaque, transparent

This basically just sets Renderbin:

opaque = bin 10, depthsortedbin

transparent = bin 0, renderbin

default = inherit renderbin details from parent node

===== program =====
* vertex-shader
* geometry-shader
* fragment-shader
* attribute
* geometry-vertices-out: integer, max number of vertices emitted by geometry shader
* geometry-input-type: points, lines, lines-adjacency, triangles, triangles-adjacency
* geometry-output-type: points, line-strip, triangle-strip
* uniform-block-binding: has name and index (since 2020.1)

example:

<syntaxhighlight lang="xml">
<program>
<vertex-shader n="0">Shaders/lcd.vert</vertex-shader>
<fragment-shader n="0">Shaders/lcd.frag</fragment-shader>
<fragment-shader n="1">Shaders/noise.frag</fragment-shader>
<fragment-shader n="2">Shaders/filters-ALS.frag</fragment-shader>
</program>
</syntaxhighlight>

example for clustered lightning in compositor:

<syntaxhighlight lang="xml">
<program>
<vertex-shader n="0">Shaders/lcd.vert</vertex-shader>
<fragment-shader n="0">Shaders/lcd.frag</fragment-shader>
<fragment-shader n="1">Shaders/noise.frag</fragment-shader>
<fragment-shader n="2">Shaders/filters-ALS.frag</fragment-shader>
<fragment-shader n="3">Shaders/ALS/clustered-include.frag</fragment-shader>
<uniform-block-binding>
<name>PointLightBlock</name>
<index>5</index>
</uniform-block-binding>
<uniform-block-binding>
<name>SpotLightBlock</name>
<index>6</index>
</uniform-block-binding>
</program>
</syntaxhighlight>

See this page for more about shaders: [[Howto:Shader programming in FlightGear]]

== Uniforms passed to shaders outside the xml effect framework ==

{| class="wikitable"
!Name
!Type
!Purpose
|-
|<tt>fg_ViewMatrix</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix used to transform from world to view space. Same as osg_ViewMatrix, but for fullscreen pass.
|-
|<tt>fg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix inverse used to transform from view to world space. Same as osg_ViewMatrixInverse but for fullscreen pass.
|-
|<tt>fg_ProjectionMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, projection matrix inverse
|-
|<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>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunDiffuseColor</tt>
|<tt>vec4</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunSpecularColor</tt>
|<tt>vec4</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunDirection</tt>
|<tt>vec3</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<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. Transforms from world to view space.
|-
|<tt>osg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|Defined by OSG, used only when working on actual geometry. Transforms from view to world space.
|-
|<tt>osg_SimulationTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_DeltaFrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameNumber</tt>
|<tt>int</tt>
|Defined by OSG
|}

== Related content ==
=== Forum topics ===
* {{forum link|t=37364|title=Application of effects}} - Testing which kind of groups an effect can be applied to and when

[[Category:Shader development]]

Effect framework

2020-05-12T14:44:15Z

Necolatis: /* scheme */ added section

{{forum|47|Effects & Shaders}}
{{Rendering}}
The effect framework as per version 2020.1

Effects describe the graphical appearance of 3D objects and scenery in
FlightGear. The main motivation for effects is to support OpenGL
shaders and to provide different implementations for graphics hardware
of varying capabilities. Effects are similar to DirectX effects files
and Ogre3D material scripts.

An effect is a property list. The property list syntax is extended
with new "vec3d" and "vec4d" types to support common computer graphics
values. Effects are read from files with a ".eff" extension or can be
created on-the-fly by FlightGear at runtime. An effect consists of a
"parameters" section followed by "technique" descriptions. The
"parameters" section is a tree of values that describe, abstractly,
the graphical characteristics of objects that use the effect. Techniques
refer to these parameters and use them to set OpenGL state or to set
parameters for shader programs. The names of properties in the
parameter section can be whatever the effects author chooses, although
some standard parameters are set by FlightGear itself. On the other
hand, the properties in the techniques section are all defined by the
FlightGear.

== Default Effects in Terrain Materials and Models ==
Effects for terrain work in this way: for each material type in
materials.xml an effect is created that inherits from a single default
terrain effect, Effects/terrain-default.eff. The parameters section of
the effect is filled in using the ambient, diffuse, specular,
emissive, shininess, and transparent fields of the material. The
parameters image, filter, wrap-s, and wrap-t are also initialized from
the material xml. Seperate effects are created for each texture
variant of a material.

Model effects are created by walking the OpenSceneGraph scene graph
for a model and replacing nodes (osg::Geode) that have state sets with
node that uses an effect instead. Again, a small effect is created
with parameters extracted from OSG objects; this effect inherits, by
default, from Effects/model-default.eff. A larger set of parameters is
created for model effects than for terrain because there is more
variation possible from the OSG model loaders than from the terrain
system. The parameters created are:

* material active, ambient, diffuse, specular, emissive, shininess, color mode
# blend active, source, destination
# shade-model
# cull-face
* rendering-hint
* texture type, image, filter, wrap-s, wrap-t

== Specifying Custom Effects ==
You can specify the effects that will be used by FlightGear as the
base effect when it creates terrain and model effects.

In the terrain materials.xml, an "effect" property specifies the name
of the model to use.

Material animations will be implemented by creating a new effect
that inherits from one in a model, overriding the parameters that
will be animated.

== Examples ==
The $FGDATA/Effects directory contains the effects definitions; look there for
examples. Effects/crop.eff is a good example of a complex effect.

== Application ==
To apply an effect to a model or part of a model use:

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/light-cone</inherits-from>
<object-name>Cone</object-name>
</effect>
</syntaxhighlight>

where <inherits-from> </inherits-from> contains the path to the effect you want to apply.
The effect does not need the file extension.

=== Parameters in model file ===

Parameters can be put into the model files effect application as well. But only bool, int, float, string can be used there.

=== Chrome old usage ===

Chrome, although now implemented as an effect, still retains the old method of application:

<syntaxhighlight lang="xml">
<animation>
<type>shader</type>
<shader>chrome</shader>
<texture>glass_shader.png</texture>
<object-name>windscreen</object-name>
</animation>
</syntaxhighlight>

in order to maintain backward compatibility.

== Reload effects at runtime ==
To reload an effect applied in a model xml file (e.g. some parameters and what it enherits from) just go into debug menu and select Reload Model.

To reload the entire effect framework including eff files, go into menu and debug and configure development extensions and reload shaders. This is broken in 2020.1 though, but works in earlier FG versions.

== The xml tags of an effect ==

=== name ===
The name of the effect

=== inherits-from ===
One feature not fully illustrated in the sample below is that
effects can inherit from each other. The parent effect is listed in
the "inherits-from" form. The child effect's property tree is
overlaid over that of the parent. Nodes that have the same name and
property index -- set by the "n=" attribute in the property tag --
are recursively merged. Leaf property nodes from the child have
precedence. This means that effects that inherit from the example
effect below could be very short, listing just new
parameters and adding nothing to the techniques section;
alternatively, a technique could be altered or customized in a
child, listing (for example) a different shader program. An example
showing inheritance Effects/crop.eff, which inherits some if its
values from Effects/terrain-default.eff.

FlightGear directly uses effects inheritance to assign effects to 3D
models and terrain. As described below, at runtime small effects are
created that contain material and texture values in a "parameters"
section. These effects inherit from another effect which references
those parameters in its "techniques" section. The derived effect
overrides any default values that might be in the base effect's
parameters section.

=== Parameters ===
Custom parameters that controls the effect.

Note that parameters can use the <use> tags to enable properties to specify the values.

=== Generate ===

Often shader effects need tangent vectors to work properly. These
tangent vectors, usually called tangent and binormal, are computed
on the CPU and given to the shader as vertex attributes. These
vectors are computed on demand on the geometry using the effect if
the 'generate' clause is present in the effect file. Exemple :

<syntaxhighlight lang="xml">
<generate>
<tangent type="int">6</tangent>
<binormal type="int">7</binormal>
<normal type="int">8</normal>
</generate>
</syntaxhighlight>

Valid subnodes of 'generate' are 'tangent', 'binormal' or 'normal'.
The integer value of these subnode is the index of the attribute
that will hold the value of the vec3 vector.

The generate clause is located under PropertyList in the xml file.

In order to be available for the vertex shader, these data should
be bound to an attribute in the program clause, like this :

<syntaxhighlight lang="xml">
<program>
<vertex-shader>my_vertex_shader</vertex-shader>
<attribute>
<name>my_tangent_attribute</name>
<index>6</index>
</attribute>
<attribute>
<name>my_binormal_attribute</name>
<index>7</index>
</attribute>
</program>
</syntaxhighlight>

attribute names are whatever the shader use. The index is the one
declared in the 'generate' clause. So because generate/tangent has
value 6 and my_tangent_attribute has index 6, my_tangent_attribute
holds the tangent value for the vertex.

=== technique ===
A certain way of rendering this effect. Different pipelines typically have their own techniques.

==== scheme ====
Since 2020.1, is only usable in Compositor build.

For the compositor ALS pipeline a scheme of als-lightning has to be specified for the technique to be considered for rendering.

Example:

<syntaxhighlight lang="xml">
<scheme>als-lighting</scheme>
</syntaxhighlight>

==== predicate ====
A technique can contain a predicate that describes the OpenGL
functionality required to support the technique. The first
technique with a valid predicate in the list of techniques is used
to set up the graphics state of the effect. A technique with no
predicate is always assumed to be valid. The predicate is written in a
little expression language that supports the following primitives:

and, or, equal, less, less-equal
glversion - returns the version number of OpenGL
extension-supported - returns true if an OpenGL extension is supported
property - returns the boolean value of a property
float-property - returns the float value of a property, useful inside equal, less or less-equal nodes
shader-language - returns the version of GLSL supported, or 0 if there is none.

The proper way to test whether to enable a shader-based technique is:
<syntaxhighlight lang="xml">
<predicate>
<and>
<property>/sim/rendering/shader-effects</property>
<less-equal>
<value type="float">1.0</value>
<shader-language/>
</less-equal>
</and>
</predicate>
</syntaxhighlight>

There is also a property set by the user to indicate what is the level
of quality desired. This level of quality can be checked in the predicate
like this :
<syntaxhighlight lang="xml">
<predicate>
<and>
<property>/sim/rendering/shader-effects</property>
<less-equal>
<value type="float">2.0</value>
<float-property>/sim/rendering/quality-level</float-property>
</less-equal>

</and>
</predicate>
</syntaxhighlight>

The range of /sim/rendering/quality-level is [0..5]
* 2.0 is the threshold for relief mapping effects,
* 4.0 is the threshold for geometry shader usage.

Example:

<syntaxhighlight lang="xml">
<predicate>
<and>
<property>/sim/rendering/shaders/quality-level</property>
<property>/sim/rendering/shaders/model</property>
<or>
<less-equal>
<value type="float">2.0</value>
<glversion/>
</less-equal>
<and>
<extension-supported>GL_ARB_shader_objects</extension-supported>
<extension-supported>GL_ARB_shading_language_100</extension-supported>
<extension-supported>GL_ARB_vertex_shader</extension-supported>
<extension-supported>GL_ARB_fragment_shader</extension-supported>
</and>
</or>
</and>
</predicate>
</syntaxhighlight>

==== pass ====
A technique can consist of several passes. A pass is basically an Open
Scene Graph StateSet. Ultimately all OpenGL and OSG modes and state
attributes will be accessable in techniques. State attributes -- that
is, technique properties that have children and are not just boolean
modes -- have an <active> parameter which enables or disables the
attribute. In this way a technique can declare parameters it needs,
but not enable the attribute at all if it is not needed; the decision
can be based on a parameter in the parameters section of the
effect. For example, effects that support transparent and opaque
geometry could have as part of a technique:

<syntaxhighlight lang="xml">
<blend>
<active><use>blend/active</use></active>
<source>src-alpha</source>
<destination>one-minus-src-alpha</destination>
</blend>
</syntaxhighlight>

So if the blend/active parameter is true blending will be activated
using the usual blending equation; otherwise blending is disabled.

Values are assigned to technique properties in several ways:

* They can appear directly in the techniques section as a
constant. For example:
<syntaxhighlight lang="xml">
<uniform>
<name>ColorsTex</name>
<type>sampler-1d</type>
<value type="int">2</value>
</uniform>
</syntaxhighlight>
* The name of a property in the parameters section can be
referenced using a "use" clause. For example, in the technique
section:
<syntaxhighlight lang="xml">
<material>
<ambient><use>material/ambient</use></ambient>
</material>
</syntaxhighlight>
Then, in the parameters section of the effect:
<syntaxhighlight lang="xml">
<parameters>
<material>
<ambient type="vec4d">0.2 0.2 0.2 1.0</ambient>
</material>
</parameters>
</syntaxhighlight>
It's worth pointing out that the "material" property in a
technique specifies part of OpenGL's state, whereas "material"
in the parameters section is just a name, part of a
hierarchical namespace.

* A property in the parameters section doesn't need to contain
a constant value; it can also contain a "use" property. Here
the value of the use clause is the name of a node in an
external property tree which will be used as the source of a
value. If the name begins with '/', the node is in
FlightGear's global property tree; otherwise, it is in a local
property tree, usually belonging to a model [NOT IMPLEMENTED
YET]. For example:
<syntaxhighlight lang="xml">
<parameters>
<chrome-light><use>/rendering/scene/chrome-light</use></chrome-light>
</parameters>
</syntaxhighlight>
The type is determined by what is expected by the technique
attribute that will ultimately receive the value. [There is
no way to get vector values out of the main property system
yet; this will be fixed shortly.] Values that are declared
this way are dynamically updated if the property node
changes.

===== lighting =====
true or false

===== material =====
children: active, ambient, ambient-front, ambient-back, diffuse,
diffuse-front, diffuse-back, specular, specular-front,
specular-back, emissive, emissive-front, emissive-back, shininess,
shininess-front, shininess-back, color-mode

===== blend =====
Children: active, source, destination, source-rgb, source-alpha, destination-rgb, destination-alpha

Children values: dst-alpha, dst-color, one, one-minus-dst-alpha, one-minus-dst-color, one-minus-src-alpha, one-minus-src-color, src-alpha, src-alpha-saturate, src-color, constant-color, one-minus-constant-color, constant-alpha, one-minus-constant-alpha, zero

Example:
<syntaxhighlight lang="xml">
<blend>
<active>true</active>
<source>one-minus-dst-alpha</source>
<destination>src-alpha-saturate</destination>
</blend>
</syntaxhighlight>

===== blend (simple) =====
A blend tag with 0 will do nothing.
A blend tag with 1 will do the same as source-alpha: one-minus-dst-alpha, in other words it will enable z transparency using alpha from the fragment shader.

Example:
<syntaxhighlight lang="xml">
<blend>1</blend>
</syntaxhighlight>

===== shade-model =====
flat or smooth

===== cull-face =====
front, back, front-back, off

===== texture-unit =====
Example:

<syntaxhighlight lang="xml">
<texture-unit>
<unit>3</unit>
<image>Textures/Terrain/void.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<mag-filter>linear-mipmap-linear</mag-filter>
<wrap-s>repeat</wrap-s>
<wrap-t>repeat</wrap-t>
<wrap-r>repeat</wrap-r>
<internal-format>normalized</internal-format>
<mipmap-control>
<function-r>average</function-r>
<function-g>min</function-g>
<function-b>sum</function-b>
<function-a>product</function-a>
</mipmap-control>
<environment>
<mode>decal</mode>
<color>0.0 0.1 0.6 1.0</color>
</environment>
<point-sprite>true</point-sprite>
<texenv-combine>operand0-rgb</texenv-combine>
<texgen>
<mode>S</mode>
<planes>0.075, 0.0, 0.0, 0.5</planes>
</texgen>
</texture-unit>
</syntaxhighlight>

===== vertex-program-two-side =====
true or false

===== polygon-mode =====
children: front, back

Valid values: fill, line, point

===== vertex-program-point-size =====
true, false

===== uniform =====
Data accessible by shaders.

name: the name

type: bool, int, float, float-vec3, float-vec4, sampler-1d, sampler-2d, sampler-3d, sampler-1d-shadow, sampler-2d-shadow, sampler-cube

===== alpha-test =====

active: true, false

comparison: never, less, equal, lequal, greater, notequal, gequal, always

reference: 0 to 1

===== render-bin =====
Sent to OSG.

bin-number: This is an integer defining the order stuff will be rendered in, it can be negative also.

bin-name: RenderBin, DepthSortedBin

===== rendering-hint =====
Sent to OSG.

default, opaque, transparent

This basically just sets Renderbin:

opaque = bin 10, depthsortedbin

transparent = bin 0, renderbin

default = inherit renderbin details from parent node

===== program =====
* vertex-shader
* geometry-shader
* fragment-shader
* attribute
* geometry-vertices-out: integer, max number of vertices emitted by geometry shader
* geometry-input-type - points, lines, lines-adjacency, triangles, triangles-adjacency
* geometry-output-type - points, line-strip, triangle-strip

example:

<syntaxhighlight lang="xml">
<program>
<vertex-shader n="0">Shaders/lcd.vert</vertex-shader>
<fragment-shader n="0">Shaders/lcd.frag</fragment-shader>
<fragment-shader n="1">Shaders/noise.frag</fragment-shader>
<fragment-shader n="2">Shaders/filters-ALS.frag</fragment-shader>
</program>
</syntaxhighlight>

See this page for more about shaders: [[Howto:Shader programming in FlightGear]]

== Uniforms passed to shaders outside the xml effect framework ==

{| class="wikitable"
!Name
!Type
!Purpose
|-
|<tt>fg_ViewMatrix</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix used to transform from world to view space. Same as osg_ViewMatrix, but for fullscreen pass.
|-
|<tt>fg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, view matrix inverse used to transform from view to world space. Same as osg_ViewMatrixInverse but for fullscreen pass.
|-
|<tt>fg_ProjectionMatrixInverse</tt>
|<tt>mat4</tt>
|In fullscreen pass only, projection matrix inverse
|-
|<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>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunDiffuseColor</tt>
|<tt>vec4</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunSpecularColor</tt>
|<tt>vec4</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<tt>fg_SunDirection</tt>
|<tt>vec3</tt>
|For fullscreen pass only, sun information as lightsource[0] is not available in fullscreen pass.
|-
|<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. Transforms from world to view space.
|-
|<tt>osg_ViewMatrixInverse</tt>
|<tt>mat4</tt>
|Defined by OSG, used only when working on actual geometry. Transforms from view to world space.
|-
|<tt>osg_SimulationTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_DeltaFrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameTime</tt>
|<tt>float</tt>
|Defined by OSG
|-
|<tt>osg_FrameNumber</tt>
|<tt>int</tt>
|Defined by OSG
|}

== Related content ==
=== Forum topics ===
* {{forum link|t=37364|title=Application of effects}} - Testing which kind of groups an effect can be applied to and when

[[Category:Shader development]]