FlightGear wiki - User contributions [en]

GDT Hornet (autogyro)

2021-05-12T21:39:40Z

HHS:

The GDT Hornet autogyro is FlightGear´s first simulation of an autogyro. It was brought to FlightGear in 2007 by Maik Justus, developer of the rotorcraft fdm implementation in YASim. Always wanting to have an autogyro he asked Emannuel Barranger for help. Emannuel Barranger stumbled about detailed information of the hornet, and they decided to build the hornet in flightgear. They were very pleasured, that Don Shoebridge- engineer behind the hornet- gave them any detailed information about the hornet they asked for and exported his SolidWorks model for FligthGear. Emmanuel Baranger converted it and made some simplifications and added animations.[1]

It does not happen all too often, that a company behind an aircraft even delivers a CAD-Model of their own aircraft to FlightGear to use!

{{:{{PAGENAME}}/info}}
== Aircraft help ==
=== Startup ===
# Accelerate the rotor by hand {{key press|n}}
# Set magneto switch to both {{key press|} }}
# Start engine {{key press|s}}
# Release parking-brake {{key press|B}}
# Full power
# Wait for the rotor to reach sufficient rpm (~300)
#* The rotor accelerates faster if you pull the stick)

== External link ==
* [https://web.archive.org/web/20111001020003/http://www.gdt-systems.com/body.asp GDT Systems: Hornet Autogyro] (Internet Archive Wayback Machine capture of October 2011)
* https://en.wikipedia.org/wiki/Midwest_Hornet
* [https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjM3ZPOi8XwAhXdgf0HHTDhA-EQFjABegQIAxAD&url=http%3A%2F%2Fkekstas.darbastalis.lt%2Fuploads%2Fprototipai%2FHornet%2520new.pdf&usg=AOvVaw1AcYCgco_TSQLiD2qHrPFt Hornet Documentation Manual]
[1] https://sourceforge.net/p/flightgear/mailman/message/15443723/

GDT Hornet (autogyro)

2021-05-12T21:39:15Z

HHS: Important history of FlightGears first autogyro- the Hornet

The GDT Hornet autogyro is FlightGear´s first simulation of an autogyro. It was brought to FlightGear in 2007 by Maik Justus, developer of the rotorcraft fdm implementation in YASim. Always wanting to have an autogyro he asked Emannuel Barranger for help. Emannuel Barranger stumbled about detailed information of the hornet, and they decided to build the hornet in flightgear. They were very pleasured, that Don Shoebridge- engineer behind the hornet- gave them any detailed information about the hornet they asked for and exported his SolidWorks model for FligthGear. Emmanuel Baranger converted it and made some simplifications and added animations.[1]
It does not happen all too often, that a company behind an aircraft even delivers a CAD-Model of their own aircraft to FlightGear to use!

{{:{{PAGENAME}}/info}}
== Aircraft help ==
=== Startup ===
# Accelerate the rotor by hand {{key press|n}}
# Set magneto switch to both {{key press|} }}
# Start engine {{key press|s}}
# Release parking-brake {{key press|B}}
# Full power
# Wait for the rotor to reach sufficient rpm (~300)
#* The rotor accelerates faster if you pull the stick)

== External link ==
* [https://web.archive.org/web/20111001020003/http://www.gdt-systems.com/body.asp GDT Systems: Hornet Autogyro] (Internet Archive Wayback Machine capture of October 2011)
* https://en.wikipedia.org/wiki/Midwest_Hornet
* [https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=&ved=2ahUKEwjM3ZPOi8XwAhXdgf0HHTDhA-EQFjABegQIAxAD&url=http%3A%2F%2Fkekstas.darbastalis.lt%2Fuploads%2Fprototipai%2FHornet%2520new.pdf&usg=AOvVaw1AcYCgco_TSQLiD2qHrPFt Hornet Documentation Manual]
[1] https://sourceforge.net/p/flightgear/mailman/message/15443723/

FlightGear Newsletter May 2021

2021-05-09T19:31:17Z

HHS: /* In the hangar */

File:H130 RotorWashEffect.jpg

2021-05-09T19:30:19Z

HHS: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Airbus H130 hovering above a lake on Hawaii near PHNL}}
|date=2021-05-09 21:27:59
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Airbus]]
[[Category:H130]]
[[Category:Eurocopter]]
[[Category:PHNL]]
[[Category:ALS]]

FlightGear Newsletter May 2021

2021-05-09T12:44:18Z

HHS: News on updates to some helicopters -final

FlightGear Newsletter May 2021

2021-05-09T12:36:01Z

HHS: News on updates to some helicopters part2

FlightGear Newsletter May 2021

2021-05-09T12:31:36Z

HHS: News on updates to some helicopters part1

File:H130 update.jpg

2021-05-09T11:51:02Z

HHS: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Airbus H130B4 sitting on the tarmac in dawn, It shows the first conversion to us compositor lights}}
|date=2021-05-09 13:48:12
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Airbus]]
[[Category:Helicopters]]
[[Category:Eurocopter]]
[[Category:Dawn]]
[[Category:EDDS]]
[[Category:Compositor screenshots]]
[[Category:H130B4]]

Cessna 182S

2021-05-02T14:40:25Z

HHS:

{{:{{PAGENAME}}/info}}

The '''Cessna 182S Skylane''' is an American four-seat, single-engine, light [[Aircraft|airplane]], built by [[Cessna]] between 1996 and 2001. It uses a fuel-injected Textron Lycoming IO-540 AB1A5 with 230 HP at 2,400 RPM.

== Features ==
The Cessna 182S is one of the high-quality aircraft models in FlightGear.

The new Cessna 182S has a very detailed 3D model and a cockpit with highly detailed textures. Most of the switches in the cockpit are already clickable and working. It has a very realistic FDM based on real aerodynamic coefficients and the pilot operating handbook; engine power, EGT and fuel performance are tuned according the pilot operating handbook, the weight and balance behaves like written in the POH. Fly by the book - a link to real POH is given at the end of this page.

[[File:c182-panel-detail.jpg|center|800px]]

There are currently several liveries available: default Cessna livery, Blank, D-ELFP, HB-CZV, N182PJ, N321HW and a Custom Livery.

The aircraft has a simulation of the [[Bendix/King KAP140 Autopilot]]. The cockpit can be illuminated at night by using the glareshield lighting, pedestal lighting and instruments/ radio lighting, controlled by two knobs. Dome lights which illuminates the cabin in a realistic way are in work. The knobs have two modes each, which can be used by clicking and dragging horizontally or vertically.

Also, if the user has enabled ALS (Atmospheric light scattering) in the Rendering Options, some effects are activated such as cockpit shadows, visible landing lights from the cockpit and rain effect on the windshield.

The Cessna 182S comes with static objects which can be activated via the Ground Equipment dialog in the aircraft menu. These include a fuel tank trailer, ladders to access the fuel caps (and which the walker can climb(only in FG Versions before 2017.3.1 !!), ground power unit and a Dragon Engine Pre-Heater. Security cones are also available. Special Feature: The ground equipment will stay on ground where placed, independent from the movement of the aircraft! The aircraft can also go through a pre-flight check: wheel chocks, tie-downs and the pitot tube cover can now be added or removed.

[[File:c182-objects.jpg|600px|center|Cessna 182S with static elements]]

==Feature-List:==
For details and usage hints, please also read the [https://github.com/HHS81/c182s/blob/master/Documentation.md documentation].
*accurate flight model based on real test aerodynamic coefficients and POH
* accurate fuel flow numbers, engine power, airspeed and climbrate in nearly all pressure altitudes and temperatures with less than 5% difference from POH
* realistic stall behavior
* calculation of real KIAS based on KCAS, based on POH
* accurate weight and balance behavior

* New Start-up States: aircraft can be initialized in cruise, landing, takeoff and more states

* fully simulated fuel system: fuel flow by gravity, engine pump and fuel pump simulated for each of the two tanks,; engine needs correct priming procedure according POH, fuel contamination simulated
* realistic electrical system, battery charge state depending on temperature, working circuit breakers
* fully simulated oil management (temperature, ....)
* autostart for beginners
* simulation of cabin heat and defrost
* simulation of icing to wings, propellers and engines in icing conditions

* High quality 3d-model, textures and animations
* Realistic exterior reflection shaders with fresnel effect and normalmap
* selectable chromed spinner and wheel fairings
* Very detailed 3d-interior
* moveable sun-visors
* 99% of all switches are working (except alternate static air- WIP!)
* fully working audio panel
* fully simulated [[Bendix/King_KAP140_Autopilot]]
* fully simulated [[Davtron M803]] digital clock
* fully simulated Bendix King avionics stack
* Realistic interior light effects in ALS-Renderer
* Interior shadows in ALS-Renderer
* interior glass frost and fog effects in ALS-Renderer
* Exterior 3d-shadow in ALS-Renderer
* selectable and fully simulated Winterization kit
* External equipement like ladders, safety cones, tie ups, pitot cover, wheel chocks, external power source, simulated external engine pre-heater with sound - they keep their position on ground!
* aircraft can be checked outside (free movement check of flight control surfaces; oil, fuel, pitot heat, ....)
* Walker - can be used to follow the Checklist outside
* Save states: aircraft remembers last switch, systems and configuration state
* Many liveries

=== Aerotowing gliders ===
The C182S and C182T are capable of [[Howto: Do aerotow over the net|aerotowing over multiplayer]] by the glider pilot pressing {{key press|Ctrl|o}} while behind the Cessna.
The Cessna pilot can release the hook anytime by pressing {{key press|Shift|O}}

=== Dual control ===
The plane supports [[Dual control]] where a copilot can ride along in another multiplayer plane. The copilot needs to start the C182 copilot variant and then select the pilots plane from the multiplayer dialog. The pilot also need to select the copilot this way.

Currently the copilot is view-only and cannot take over controls.

== Handling The Aircraft (beginner version)==
You can activate more realistic handling at any time in the aircraft dialog, like fuel contamination, engine oil management and priming needs.

The full checklists are available ingame in the checklists dialog.

=== Pre-Flight Inspection ===
[[File:C182-ready-for-take-off.jpg|270px||thumb|Cessna 182S ready for take off]]
It's recommended to use any exterior view or activate the walker for these procedures.
* Check fuel quantity on both tanks
* Left wing: remove pitot tube cover
* Left wing: remove tie-down
* Left wing: check water contamination
* Left main wheel: remove chocks
* Tail: remove tie-down
* Right wing: remove tie-down
* Right wing: check water contamination
* Right main wheel: remove chocks
* Right nose: check water contamination of fuel selector and fuel strainer
* Nose: remove wheel chocks
* Nose: check oil level

=== Engine Start (manual and complex startup) ===
* Mixture: Rich
* Propeller: High RPM
* Throttle: Open 1/4 inch (~5%-8% setting inSim)
* Parking Brake: Applied ({{Key press|Shift|B}})
* Prop Area: Clear
* Master switch: ON (both)
* Auxiliary Fuel Pump Switch: ON
* Advance mixture to full rich, keep it 3-5sec
* Then Idle Cutoff
* Auxiliary Fuel Pump Switch: Off
* Magnetos: Both (Press {{Key press|<nowiki>}</nowiki>}} three times)
* Ignition: Start ({{Key press|S}})

If engine floods, then set mixture to idle cut off and throttle to 1/2 to full open and crank. When engine fires, set mixture to full rich and throttle to idle.

=== Takeoff ===
* no flaps or flaps 10deg
* cowl flaps open ({{Key press|Shift|F}} several times)
* full throttle
* rotate at 50-60 KIAS

=== Climbout ===
* no flaps
* cowl flaps open
* full throttle
* 80 KIAS

=== Cruise ===
[[File:c182-default.jpg|270px||thumb|Cessna 182S in the air]]
* 2000-2400 RPM
* 18-23 mp
* mixture rich of peak as recommended lean mixture setting for cruise or 125°F rich for best power
* speed between 120-140 knots depending on the power settings
* cowl flaps closed ({{Key press|f}} as appropriate -> watch CHT gauge)

=== Landing ===
* flaps 20deg or full flaps
* 60-70 KIAS

=== Airspeeds ===
: ''See also [[Aircraft speed#V speeds]]''

{| class="wikitable"
! Airspeed !! IAS
|-
| Stall speed, landing configuration, V<sub>S<sub>0</sub></sub> || 36 kt
|-
| Stall speed, clean, V<sub>S<sub>1</sub></sub> || 43 kt
|-
| Rotation speed, V<sub>R</sub> || 55 kt
|-
| Best angle of climb speed, V<sub>X</sub> || 63 kt
|-
| Best rate of climb speed, V<sub>Y</sub> || 80 kt
|-
| Maximum flap extended speed, V<sub>FE</sub> || 100 kt
|-
| Manoeuvring speed, V<sub>A</sub> || 110 kt
|-
| Maximum structural cruising speed, V<sub>NO</sub> || 140 kt
|-
| Never exceed speed, V<sub>NE</sub> || 175 kt
|-
| Max. Crosswind || 15 kt
|}

=== Performance ===

{| class="wikitable"
|Cruise, 80% power, 6,000 ft || 140 kt
|-
|Cruise, 65% power, 8,000 ft || 130 kt
|-
|Cruise, 55% power, 10,000 ft || 121 kt
|}

{| class="wikitable"
|Range, 75% power, 6,000 ft || 820 nm
|-
|Range, 65% power, 8,000 ft || 910 nm
|-
|Range, 55% power, 10,000 ft || 968 nm
|}

{| class="wikitable"
|Best Climb || 924fpm
|-
|Service Ceiling || 18,100ft
|-
|Takeoff ground roll: 795ft over 50ft obstacle || 1,514ft
|-
|Landing ground roll: 590ft over 50ft obstacle || 1,390ft
|}

[[File:c182-cockpit-at-night.jpg|600px|center|Cessna 182S panel illumination]]

== FAQ ==
'''''I wonder why would the 182s be easier to fly than the c172p?'''''

Is it? If you think the fdm is wrong: A fdm is only so good as the datas available. The c182s-fdm uses real coefficient data where available, but not all needed coeeficients could be found. Where not available, pilot reports had been used. And they are from a subjective view of the pilot.

'''''According to google, most pilots agree that the 182s is actually harder to fly than the 172p'''''

Not because of its flight characteristics. Though many pilot bends their firewalls on touchdown, due the nose heaviness of that aircraft. But a lot pilot likes the C182 more because of more power, more speed, higher possible altitudes, [[constant speed propeller]], cowl-flaps and the IFR-equipement. And that`s the reason - due to that all it is much more challenging to fly than the Cessna 172. So FAA counts the Cessna 182 to the high perfomace aircraft. Imagine beeing in a crowded area like KLAX, approaching the airport while listening to Radio calls every few seconds, watching speed, altitude, manage the engine and prop speed, chasing VOR-needles and watching the traffic around at the same time in bad weather condition - challenging!
You might wanna read this: [https://pilotbrian.blogspot.com/2009/05/stepping-up-to-c182.html Stepping Up to a C182 ]

'''''Is the C182S made easier to fly, instead of more realistic to fly?'''''

No. The authors uses real numbers, datas, coefficients and more where available, aiming to get everything realistic as it can be. As an example it matches all the numbers given in the POH, and uses real aerodynamic coeffcients for the fdm where available. If it doesn`t fly as you expect, you might be used to FSX? Just kidding...
Anyway, if encounter something you think it isn`t right, file an Issue-report [https://github.com/HHS81/c182s/issues here], and we will find out.

'''''Why has the C182S a smaller left push tendency than the c172p?'''''

You propably uses a older version of the C182S, released before 6. february 2019. There was a single wrong sign used in the fdm, which reduced the left push tendency. The version released after 6. february 2019 has been fixed in [[FGAddon]] and in the [https://github.com/HHS81/c182s Dev-repo on github.com].

'''''At 3,000 ft, I can't get over 110 knots. MP: 23 RPM: 2450 FF: 14. What am I missing?'''''

The checklist! If it doesn`t get the speed as you expect, check: Mixture, prop rpm, cowl flaps, icing, engine damaged,... Probably you simply forget to close the cowl flaps.
Another reason could be that you mistake KTAS (Knots True AirSpeed) with KIAS (Knots Indicated AirSpeed). The tables and many publications gives the speeds in KTAS. So you have to read the KTAS-values from your instruments, not the KIAS. How to?- just read below.

''''' Where I can see my True Airspeed ([[TAS|KTAS]])?'''''
The Air Speed Indicator has a dial at the upper part of the instrument face. So you simply dial in the pressure altitude (=Altimeter set to 29.92) in ft via the knob, and align it with the temperature mark just below.
Now you can read your true airspeed in the lower left window of your instrument.
[[:File:C182s-ais-tas.png|There is a screenshot]] showing an example of using the TAS disc.

'''''I flew in cold weather, but suddenly crashed because the aircraft slowed down. Where is the carb heat?'''''

The Cessna 182S uses an fuel-injected engine - like many modern cars. So there is no carburetor. But what you experienced is the icing of the prop and the aircraft body. Unfortunately there is indeed a bug: propeller icing of constant speed props can`t be simulated yet with JSBSim. The C182S-team tried to find a work-around, but might not have yet found the best solution....Not everything can be perfect! Anyway: with this type of aircraft you are not allowed to fly in known icing-conditions!

'''''Cessna 182S refuses to start'''''

First: you probably didn`t follow the checklist.
Second: you might have flooded the engine. Follow this procedure: Pull back mixture to cut off, advance throttle to about about little more than 50-60%, then operate the starter again for a while. If the engine fires, promptly advance the mixture to full rich and return throttle to Idle.

'''''Why I can`t see the wingtip and the cowl?'''''

The eye level position has been carefully set comapring informations from pictures showing the Cessna 182S or Cessna 182T and pilot reports. If you compare, you can see that the eye level of the pilot is sitting at the level of the upper edge of the side window frame. The wing root sits much higher, the wingtip even more. So it is impossible to see the wingtip.
The glareshield is quite high on the newer Cessna, and from you usual position you are not able to see the engine cowling in front of you.
And the eye level position is also set to the fact that a good landing is provided why you flare just before the touchdown. Your flare will be correct, when the upper edge of the glareshiels is virtually touching the horizon.

== Development status/Issues/TODO ==

This aircraft is undergoing a constant development, which can be followed on its [https://github.com/HHS81/c182s repository], where a [https://github.com/HHS81/c182s/issues list of issues and future enhancements] can also be found. Worth a visit!

== Gallery ==
{{screenshot cat
| category = Cessna 182S screenshots
| subject = the Cessna 182S
| image = C182-default.jpg
}}{{-}}
<gallery mode="packed">
GXLTGAltenrhein.jpg|aircraft sitting on the apron of St. Gallen-Altenrhein/ Switzerland
Cessna182S compositor2.jpg|aircraft sitting in the dark, all lights on
c182s.jpg|Cessna 182S at dusk
c182-cockpit-view.jpg|Default cockpit view
c182-external2.jpg|HB-CZV livery
c182-external3.jpg|D-ELFP livery
c182-external5.jpg|Cessna 182S over California
c182-external6.jpg|Another view of the HB-CZV livery
C182-4.jpg|Taking off
c182-rosskopf-at-dusk.jpg|Cessna 182S around Roßkopf in Freiburg/ Germany
C182STakeOff.jpg|Cessna 182S with custom registration at Siegerland Airport/ Germany
C182SDavtron803.jpg|The Davtron 803 clock in action
C182SWinterKit.jpg|Winterkit installed, and preheating the engine with an Engine Preheater
C182SFuelManagement.jpg|Fuel Management Dialog
c182-rain.jpg|Rain effect in the windshield
C182-oil-cap.png|Oil cap location
C182SOilManagement.jpg|Oil Management Dialog
C182-fuelports.png|Fuel selector and strainer quick drain valves location
c182-night-take-off.jpg|Ready to take off at night
c182-3.jpg|D-ELFP at dusk
C182SPitot.jpg|Pitot, Cover and message
C182SFreeMovementCheck.jpg|Checking the aileron
C182SCustomRegistration.jpg|The custom registration
c182-external4.jpg|N182PJ livery
c182-external-at-night.jpg|Default livery at night
c182-external1.jpg|N321HW livery
C182Scrashed.jpg|aircraft crashed
AboveSouthGermany.jpg|aircraft flying above South Germany
Cessna182S compositor.jpg|aircraft sitting in the dark, all lights on

</gallery>

== External links ==
* {{Wikipedia|Cessna 182 Skylane|lang=en}}
* [http://www.freechecklists.net/Resources/Cessna/182S+Skylane/ Links to Cessna 182S Checklists and W&B sheet]
* [http://tssflyingclub.org/documents/C182S_POH.pdf Cessna 182S POH]
* [http://www.airborne-aviation.com.au/resources/aircraft/booklet_pco.pdf Cessna 182S Aircraft Information Booklet]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]
[[Category:Red Griffin ATC compatible aircraft]]

FlightGear Newsletter April 2021

2021-05-02T14:38:18Z

HHS:

{{User:Skybike/Template:Newsletter-header-translate|2021-04}}
{{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>}}



=== 2020.3.8 LTS released - OSM2City world-build release ===
FlightGear 2020.3.8 LTS has been released with an '''experimental''' 1st rollout of [[OSM2City]] buildings, roads and other objects for the entire world. Objects that are in the Open Street Map (OSM) database will be present. Automatic generation for areas without objects is disabled for this release.

See [[OSM2City 1st Worldbuild|'''1st World-build of OSM2City''']] for information on what's included, and tips on performance/troubleshooting.

See 2020.3.8 LTS [[Changelog 2020.3#2020.3.7|change log]] - included are improvements to Europe agriculture appearance, update to random scenery objects such as farm or industrial buildings and silos, California regional definitions improvements (now active), and updated water depth data (bathymetry).<gallery mode="packed" widths="480" heights="200" caption="2020.3.8 LTS improvements. Click to enlarge.">
File:Innsbruck at night in FlighGear with OSM2City worldbuild 03.jpg|alt=Innsbruck at night in FlighGear with OSM2City worldbuild|Innsbruck OSM2City
File:Madrid at dawn in FlightGear 2020.x with the 1st world-build of OSM2City 01.jpg|alt=Madrid at dawn in FlightGear 2020.x with the 1st world-build of OSM2City 01.jpg|Madrid at dawn, OSM2City
File:Rolling agricultural lands stretching away to the horizon in southern France in FlightGear 2020.x 02.jpg|alt=Rolling agricultural lands stretching away to the horizon in southern France in FlightGear 2020.x|Southern Europe - rolling agricultural lands stretching to horizon
File:FlightGear 2020 - Overlooking San Franciso International Airport (KSFO), California with OSM2City output (FlightGear 2020) 02.jpg|alt=FlightGear 2020 - Overlooking San Franciso International Airport (KSFO), California with OSM2City output (FlightGear 2020|California - San Francisco OSM2City
File:Airport keep at San Franciso International Airport (KSFO), California with OSM2City output (FlightGear 2020) 01.jpg|California regional definitions - airport keep
</gallery>Release builds now include {{Wikipedia|Appimage|Appimages}} for Linux. See this discussion of [[Hardware recommendations#Recommendations for FlightGear in 2021 .282020.3 LTS.29|hardware recommendations]] for modern FlightGear - although it is for 2018.3 LTS and doesn't cover the new experimental OSM2City (see the OSM2City page info for perfromance tips).

=== Homepage news posts on 2020.3 LTS ===
There is a [[2020 LTS Keflavik news post draft|draft page]] here for submissions of material for posts on the homepage about changes to FlightGear, Aircraft, Addons etc. since 2018.3 was released, with screenshots. The points are the important thing, don't worry if your English is not perfect. If you need suitable screenshots for the homepage ([https://www.flightgear.org/category/tours/ examples]) for a specific craft or feature that aren't already available ([[:Category:Screenshots at high settings|1]] , [https://wiki.flightgear.org/w/index.php?title=Category:Screenshots_at_high_settings&filefrom=SOTM+2020-03+Mystic+Misty+by+GinGin+%28Space+Shuttle+on+launchpad%2C+Florida%29.jpg#mw-category-media 2] , [https://forum.flightgear.org/viewforum.php?f=88 3]) in the wiki or forum, you can try asking in the forum [https://forum.flightgear.org/viewforum.php?f=19 media] section.

=== The road ahead ===
''See [[FlightGear Newsletter February 2021#Help%20Wanted|'''Help Wanted''']].''

There are a lot of big projects that are currently under way - see the [[FlightGear Newsletter January 2021#The%20road%20ahead|January newsletter]] for details for some of these projects. A lot of work (but not all) is already on the next branch (i.e. nightly builds). There is a lot to check out if you are curious - power users can run [[$FG HOME#Parallel%20installs%20of%20FlightGear|multiple installs]] of FlightGear in parallel. To contribute to any aspect of these projects, get in touch via the "[[Mailing lists|fg-devel]]" mailing list.

Nightly builds with some of the big changes are available at [http://download.flightgear.org/builds/nightly/ download.flightgear.org] as usual.

Please report bugs and issues via the sourceforge [https://sourceforge.net/p/flightgear/codetickets/ tickets] system if you come across any on the next branch, or LTS.

==== Data Distribution Services Update: Property tree support ====
{{Main article|Data Distribution Services Support}}

As of 04/2021, Erik has implemented an initial implementation of a [[Property|property server]] using '''Data Distribution Service'''. And he has also taken the time to implement it [[Remote Properties|like he once envisioned the remote property tree]].

The idea is as follows:

You request a property path, the server responds with the property value and a property index.

Successive requests now can use the index to access the property removing the need to send the full property path every request saving both
bandwidth and lookup time. After thinking about this a bit more I think future revision will have a different scheme.

1. Request the id of the property you are interested in.

2. You get an answer with the property value and id for that property.

3. From now on the server pushes an updated value for that particular

property id whenever the property value changes.

When set up properly DDS will keep the changed properties in it's cache for clients to read when they have time for it.

So no need to do successive requests anymore. Just wait and watch out for updates.

As an example, there is the fg_dds_prop utility in {{Flightgear source|src/Network/DDS/fg_dds_prop.cpp}} which can be used to either request a property path or a know property property ID.

And there is {{Flightgear source|src/Network/DDS/fg_dds_log.cpp}} which is able to log all DDS samples passing over the DDS network layer, including the new
property sample format.

To access properties from a running version of FlightGear use the following command line parameter:

<code>--dds-props=dds,out,<hz></code>

All this is 'next' only. <ref>https://sourceforge.net/p/flightgear/mailman/message/37263034/</ref>

=== New rendering pipeline for Compositor ===
Fernando has been experimenting with adding new rendering features, using the capabilities of the [[Compositor]] - see page for the new [[HDR Pipeline|pipeline]]. The work is "''*very*'' ''experimental''", as Fernando said. It has not been released on the next branch as of writing this - although a ''very limited'' prototype is intended to be added to the FlightGear next branch. The new renderers will assume a higher version of OpenGL, which is one of the many big projects that are being worked on,

The Compositor is a framework to define rendering pipelines - so far the work has been to port the ALS renderer to the new framework, and add the distinguishing features of the old unmaintained Rembrandt renderer like shadows and environmental light definitions without being slow. The idea is to port existing features from both renderers to ensure everything works - the next preview release or LTS will transition to the Compositor. The next LTS will have the existing features as the classic rendering pipeline alongside any new pipelines that are finished, so there's no need to worry about performance hits of features from the new pipeline making very old hardware too slow to run FG. The new pipeline work builds on top. It investigates changing the physical model of aircraft surfaces (to something involving a version of PBR), adding lighting of surfaces from light bouncing off surrounding surfaces including real-time reflections, and implementing a new way of doing HDR algorithm using the new physically based surface model. Some tunable artistic glow (know as [https://en.wikipedia.org/wiki/Bloom_(shader_effect) bloom]) is also supported. The new pipeline is built on top of existing work, and will use the fast shadows and lights added to the ALS port. Fernando hasn't found a way to re-use occlusion data (finding what is visible in the view and what isn't, and culling invisible geometry) between passes in current Open Scene Graph (OSG), so he is using a deferred rendering approach in the prototype to overcome this OSG limitation - it means that anti-aliasing is restricted to post-processing that looks at the rendered image and tries to detect edges and blur them to remove jagged lines.

The current plan is to support {{Wikipedia|GlTF|GlTF}} (Graphics Language Transmission Format) as an alternative for 3d models in future - it supports the new surface model natively. This format also supports binary data (GLB file extension), and these will be smaller than AC files.

As Fernando said, this is all very WiP and experimental - it's an investigation of various approaches like a lot of development. Plans can change. There is no timeline, and progress can vary based on availability of volunteers.

[[HDR Pipeline#Gallery|WiP screenshots]] - keep in mind this is very proof of concept using existing art not especially designed to take advantage of the new surface models, and it only works on aircraft carriers / over the sea. It's not an end-user demo of how a craft designed for these pipeline features will look when done, and shows features that people familiar with rendering and what's been tested can pick up on.

== Related Software tools and projects ==


=== FGCom-mumble ===
[https://github.com/hbeni/fgcom-mumble FGCom-Mumble] aims to provide a mumble based FGCom implementation. This will simulate radio communications in a seamless frequency spectrum. The project aims to be easy to use: Pilots just install the plugin, open mumble, join a channel on a mumble server and start using their radio stack in Flightgear.

The development is discussed in the {{forum link|title=FGCom-mumble|f=32|t=37644}}. Releases can be downloaded from {{github source|user=hbeni|repo=fgcom-mumble|text=GitHub}}. The project also has a flightgear wikipage: [[FGCom-mumble]]

==== Mumble 1.4.0 development master received plugin framework ====
The new plugin framework feature finally reached mumbles master development branch. This means that from now on, self-compiling users just need to build the ordinary master branch of the upcoming 1.4.0 or just use one of the precompiled [https://dev.azure.com/Mumble-VoIP/Mumble/_build?definitionId=6 Mumble 1.4.0 nightly development snapshots].

==== Plugin development status ====
Right now, the latest FGCom-mumble [https://github.com/hbeni/fgcom-mumble/releases/tag/v.0.12.0 release v.0.12.0] fixes a bug with the new FGFS addon which prevented to load the protocol definition. If you tried the addon with 0.11.0, you need to patch your extracted addon folder manually with the provided upgrade.

Under the hood on the server side, the statuspage usage statistics got an upgrade that allows [https://github.com/hbeni/fgcom-mumble/blob/master/server/statuspage/Readme.statuspage.md#usage-statistics selection of the displayed timeframe of the graph]. Also, stale clients have a grey icon now. Both is already available [http://fgcom.hallinger.org/ at the online statuspage of the test server].

Release 0.12.0 also brings support for MacOS users!

Also, we now have support for FlightGear ADF data, so the aircrafts first ADF receiver will pick up FGCom-mumble transmissions and drive the needle in your ADF gauge! This could for example be used to fly with user created NDBs (maybe radio stations) - just record something to a suitable frequency with the RadioGUI and enjoy your custom NDB navaid!

==== New nightlies and debug build release ====
On GitHub there are now also [https://github.com/hbeni/fgcom-mumble/actions nightly builds] that also provide a debug-version of the plugin, which will help in tracking down errors. The debug version provides extensive logging to the console, and optionally to a logfile if configured to do so. Please use such a debug log if opening tickets (if applicable), because it helps to track down what happened during execution.

== In the hangar ==

=== Space Shuttle Milestone 13 released ===
Copy & Paste from this post by Thorsten: https://sourceforge.net/p/flightgear/mailman/message/37266972/ :

''We're happy to announce the arrival of the [[Space Shuttle|Shuttle]] milestone 13 while at
the same time welcoming GinGin as new collaborator in the team (who has
done most of the work for this milestone). Given the state of the spacecraft before, you might reasonably ask - is there anything substantial that can still be added? You'll be the judge of that, but I think there is.''

* ''thanks to new aero data, we now have a better description of the hypersonic flight phase from Mach 27 down to about Mach 5''

* ''GinGin has been patiently digging into NASA documents and replaced my home-written guidance for the launch and entry trajectories by something that is much more shaped like the real thing, for instance the launch trajectory is now somewhat flatter and reaches a later arctop''
* ''also, thanks to GinGin's patient work, we now have pretty much all the display pages very close to the original appearance (they've been moved to the original font, items blink where they should, and the limit sensing overlay which indicates when a value is off-nominal has been added)''
* ''a lot of time has gone into testing and fixing issues with launch aborts. They're generally a wide field in that they probe a huge kinematical region in terms of what can happen, but are interesting because they actually showcase what the Shuttle can do with a rocket engine and as a hypersonic vehicle, and they provide a high-workload and challening environment for the crew. We now have voice callouts for the abort boundaries (what maneuver should be flown when), as well as literally dozens of different cases tested and the guidance parameters adjusted to resolve small issues''
* ''also, I've added the helium system (providing a purge for the engines during launch) including full failure and leakage capability, which was one of the last remaining systems that were not simulated in gory detail''
* ''to make use of all that failure modeling, a new failure training mode throws a random scenario at selectable difficulty level at the user as a challenge - so you don't know up-front what will happen''
* ''a new view to simulate the RMS arm camera simplifies grabbing objects in space''
* ''a virtual notepad to record voice calls from mission control or display payload attachment points''

''All in all, with three people flying tests for more than a month, this is probably the best-tested milestone we ever had, and it's been verified to run all the way back to 2018.3. I'm currently in the last stages of updating the manual, which will be available within a few days.''

''Enjoy!''
[[File:Shuttle cockpit before launch.jpg|alt=FlightGear Space Shuttle cockpit with internal lighting|none|thumb|700x700px|[[Space Shuttle]] cockpit before launch with internal lighting]]



=== New aircraft ===

==== BAE/Avro 146 ====
The development of BAE146 starts 2 weeks ago. It's still unbublished. Main developer - SP-NTX.

To do:

* 3D Model.
* FDM (jsbsim).
* Cockpit.
* Screens (Canvas).
* Wiki page.

=== Updated aircraft ===

==== Cessna 182S / 182T ====
The [[Cessna 182S]] ([https://github.com/HHS81/c182s git version]) got some really exiting enhancements over the last half year, and is now also available on [[FGAddon|FGAddon]]:
[[File:Cessna182S compositor.jpg|thumb|Cessna 182S all lights on, Compositor]][[File:C182Scrashed.jpg|thumb|Cessna 182S on the rwy crashed]][[File:GXLTGAltenrhein.jpg|thumb|Cessna 182S new livery G-XLTG on the apron of the Airport St. Gallen Altenrhein/ Schweiz]]
* The EGT Indicator knob got a long due label now and features the original scale as well as a properly yellow colored needle.
* The CHT was retextured with the original scale too.
* The VOR gauges have the yellow tick marks as reference for the course wheel; and the OBS label on the knob.
* The ADF gauge features red ticks and a more detailed aircraft symbol.
* The transponder buttons are visually depressed when clicked now.
* The KAP-140 Autopilot was upgraded to Sascha Reißners new version and the control loop finetuned by Josh Davidson. This new version does not only feature a nice preflight check, but brought the realism to a whole new level. The UP/DN buttons can be used now to change altitude in ALT mode when continuously pressed, the AP disconnects in high-G situations and it features an AP disconnect knob as well as a CWS knob to temporarily disengage. The autopilot now realistically simulates the attached servo motors to drive the flight control surfaces, and they can of course fail. The REV mode now actually works and one can do a all-angle-intercept from ROL mode into NAV/APR/REV.
* The model supports damage now, so you can crash the gear when landing too hard and actually see that.
* Flying too low in forests make you hit the trees now.
* The pilot seat position can be adjusted forward/backward and this is stored.
* Starting the engine now causes visible vibrations in the plane.
* Spark plug icing is simulated, so in freezing conditions when the engine just revolves a few rounds and then quits, it possibly may not be able to start again.
* The radio stack was upgraded to the new model, supporting 8.33 channels.
* Multiplayer enhancements, many more properties are transmitted now. Also the custom registration was converted to canvas, making it visible in mutliplayer now (Note: When you use the new model, you will see the gear collapsed at old version multiplayer clients).
* Passengers and copilot are visually in the plane now (also in multiplayer!)
* Some corner cases in the FDM were fixed, most notably the plane is now more stable in high-wind conditions and also does not swing left/right so much when osciallating the yoke. Also the flap pitch reactions are even more realistic now.
* The gear damping values were revised and also the nose gear scissor animation was added as well as the oleo strut reworked.
* Some minor fixes and additions in the electrical system.
* Some minor fixes in the startup state system; also the GUI was reworked so it has a drop-down instead of a radio button menu.
* Aircraft tags were revised and switched to standard tags in some occasions.
* Splash screens where ported to the new system, and URLs were added so one can lookup documentation from the launcher.
* Aircraft menus were reordered and are more consistent to the C172p now. Also a small "about" dialog was added.
* Some small fixes in the failure manager, regarding failed flaps.
* The yoke can be shown/hidden with lowercase "y" now, previously it was just uppercase "Y", which is now in line with the C172. Also the yoke now goes transparent instead of being completely hidden (transparency level is configurable in the aircraft dialog).
* Some minor texture fixes in the cockpit.
* Dual control for a copilot to share the ride (view-only for now).
* Multiplayer Aerotowing support added.
* Adding support for the default "c" keybind to hide the 3D-cockpit.
* New f/F keybinds to adjust cowl flaps.
* Gravel- and Pavement roll sounds from the C172 project.
* Better all-angle.intercept handling for the KAP-140 autopilot (currently it sometimes briefly initiates a 45° turn when capturing the beam).
* Upgraded the [[Davtron M803]] digital clock with new FT/ET alarm timers and ET count-down mode and fixed boot-up state.
* The starter motor power drain is more realistic now.
* The C182T is upgraded to include all shared systems to the current level of the C182S, so now the electrical system is working as intended and the failure manager can fail most systems specific to the T-variant too. The C182T can now also Ice and has the advanced fuel and engine system etc; also multiplayer fixes are contained.
* Update to use compositor lights

All those changed where deployed to the FGAddon hangar already!



=== Instruments ===
* A fully simulated [[Davtron_M803]] digital clock is now available, featuring all the timers and alarm modes. The source is currently in the c182s project. Forum thread: {{forum link|t=38955|title=Davtron M803}}



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





=== Wiki updates ===
* A new article was drafted, describing the "magical blue lever" aka. [[Constant speed propeller]]


=== 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 ==
=== Upcoming events ===
A bunch of pilots currently do (mostly) GA flights on wednesdays evenings. Look at the forums for details! Everyone is welcome, the more, the merrier!
We are casually flying, so no procedures/radio phrases knowledge needed (but we are happy if you do)








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

File:Cessna182S compositor2.jpg

2021-05-02T14:36:53Z

HHS: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Cessna 182S all lights on, Compositor}}
|date=2021-05-02 16:34:39
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Cessna 182S screenshots]]
[[Category:Compositor screenshots]]

File:Cessna182S compositor.jpg

2021-05-02T14:36:53Z

HHS: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Cessna 182S all lights on, Compositor}}
|date=2021-05-02 16:33:56
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Cessna 182S screenshots]]
[[Category:Compositor screenshots]]

Cessna 182S/info

2021-05-02T14:17:16Z

HHS:

<includeonly>{{infobox aircraft
| name = Cessna 182S Skylane
| hangar = fgaddon
| image = c182s.jpg
| image2 = c182-cockpit-view.jpg
| type = Civil aircraft/Civil utility aircraft aircraft/Glider tug
| config = High wing aircraft/Fixed gear aircraft
| propulsion = Propeller aircraft/Single-engine aircraft
| manufacturer = Cessna
| authors = Heiko Schulz/Gilberto Agostinho/Benedikt Hallinger/Wayne Bragg (wlbragg)/onox/Ron Jensen (jentron)/Daniel Dubreuil (Dany93)/Stuart Buchanan/David Megginson Sascha Reiszner Joshua Davidson
| fdm = JSBSim
| fgname = c182s
| status-fdm = 5
| status-systems = 5
| status-cockpit = 5
| status-model = 5
| ready = checklist/dualcontrol/tutorials/compositor
| devel-repo = {{github url|user=HHS81|repo=c182s}}
| download = {{github zip file|user=HHS81|repo=c182s|full=1}}
| forumtid = 28475
| navbar = 1
}}</includeonly><noinclude>
This is the aircraft infobox subpage of the [[Cessna 182s]].
[[Category:Aircraft infobox documentation]]
</noinclude>

Cessna 182S

2021-05-02T14:13:28Z

HHS: /* Gallery */

{{:{{PAGENAME}}/info}}

The '''Cessna 182S Skylane''' is an American four-seat, single-engine, light [[Aircraft|airplane]], built by [[Cessna]] between 1996 and 2001. It uses a fuel-injected Textron Lycoming IO-540 AB1A5 with 230 HP at 2,400 RPM.

== Features ==
The Cessna 182S is one of the high-quality aircraft models in FlightGear.

The new Cessna 182S has a very detailed 3D model and a cockpit with highly detailed textures. Most of the switches in the cockpit are already clickable and working. It has a very realistic FDM based on real aerodynamic coefficients and the pilot operating handbook; engine power, EGT and fuel performance are tuned according the pilot operating handbook, the weight and balance behaves like written in the POH. Fly by the book - a link to real POH is given at the end of this page.

[[File:c182-panel-detail.jpg|center|800px]]

There are currently several liveries available: default Cessna livery, Blank, D-ELFP, HB-CZV, N182PJ, N321HW and a Custom Livery.

The aircraft has a simulation of the [[Bendix/King KAP140 Autopilot]]. The cockpit can be illuminated at night by using the glareshield lighting, pedestal lighting and instruments/ radio lighting, controlled by two knobs. Dome lights which illuminates the cabin in a realistic way are in work. The knobs have two modes each, which can be used by clicking and dragging horizontally or vertically.

Also, if the user has enabled ALS (Atmospheric light scattering) in the Rendering Options, some effects are activated such as cockpit shadows, visible landing lights from the cockpit and rain effect on the windshield.

The Cessna 182S comes with static objects which can be activated via the Ground Equipment dialog in the aircraft menu. These include a fuel tank trailer, ladders to access the fuel caps (and which the walker can climb(only in FG Versions before 2017.3.1 !!), ground power unit and a Dragon Engine Pre-Heater. Security cones are also available. Special Feature: The ground equipment will stay on ground where placed, independent from the movement of the aircraft! The aircraft can also go through a pre-flight check: wheel chocks, tie-downs and the pitot tube cover can now be added or removed.

[[File:c182-objects.jpg|600px|center|Cessna 182S with static elements]]

==Feature-List:==
For details and usage hints, please also read the [https://github.com/HHS81/c182s/blob/master/Documentation.md documentation].
*accurate flight model based on real test aerodynamic coefficients and POH
* accurate fuel flow numbers, engine power, airspeed and climbrate in nearly all pressure altitudes and temperatures with less than 5% difference from POH
* realistic stall behavior
* calculation of real KIAS based on KCAS, based on POH
* accurate weight and balance behavior

* New Start-up States: aircraft can be initialized in cruise, landing, takeoff and more states

* fully simulated fuel system: fuel flow by gravity, engine pump and fuel pump simulated for each of the two tanks,; engine needs correct priming procedure according POH, fuel contamination simulated
* realistic electrical system, battery charge state depending on temperature, working circuit breakers
* fully simulated oil management (temperature, ....)
* autostart for beginners
* simulation of cabin heat and defrost
* simulation of icing to wings, propellers and engines in icing conditions

* High quality 3d-model, textures and animations
* Realistic exterior reflection shaders with fresnel effect and normalmap
* selectable chromed spinner and wheel fairings
* Very detailed 3d-interior
* moveable sun-visors
* 99% of all switches are working (except alternate static air- WIP!)
* fully working audio panel
* fully simulated [[Bendix/King_KAP140_Autopilot]]
* fully simulated [[Davtron M803]] digital clock
* fully simulated Bendix King avionics stack
* Realistic interior light effects in ALS-Renderer
* Interior shadows in ALS-Renderer
* interior glass frost and fog effects in ALS-Renderer
* Exterior 3d-shadow in ALS-Renderer
* selectable and fully simulated Winterization kit
* External equipement like ladders, safety cones, tie ups, pitot cover, wheel chocks, external power source, simulated external engine pre-heater with sound - they keep their position on ground!
* aircraft can be checked outside (free movement check of flight control surfaces; oil, fuel, pitot heat, ....)
* Walker - can be used to follow the Checklist outside
* Save states: aircraft remembers last switch, systems and configuration state
* Many liveries

=== Aerotowing gliders ===
The C182S and C182T are capable of [[Howto: Do aerotow over the net|aerotowing over multiplayer]] by the glider pilot pressing {{key press|Ctrl|o}} while behind the Cessna.
The Cessna pilot can release the hook anytime by pressing {{key press|Shift|O}}

=== Dual control ===
The plane supports [[Dual control]] where a copilot can ride along in another multiplayer plane. The copilot needs to start the C182 copilot variant and then select the pilots plane from the multiplayer dialog. The pilot also need to select the copilot this way.

Currently the copilot is view-only and cannot take over controls.

== Handling The Aircraft (beginner version)==
You can activate more realistic handling at any time in the aircraft dialog, like fuel contamination, engine oil management and priming needs.

The full checklists are available ingame in the checklists dialog.

=== Pre-Flight Inspection ===
[[File:C182-ready-for-take-off.jpg|270px||thumb|Cessna 182S ready for take off]]
It's recommended to use any exterior view or activate the walker for these procedures.
* Check fuel quantity on both tanks
* Left wing: remove pitot tube cover
* Left wing: remove tie-down
* Left wing: check water contamination
* Left main wheel: remove chocks
* Tail: remove tie-down
* Right wing: remove tie-down
* Right wing: check water contamination
* Right main wheel: remove chocks
* Right nose: check water contamination of fuel selector and fuel strainer
* Nose: remove wheel chocks
* Nose: check oil level

=== Engine Start (manual and complex startup) ===
* Mixture: Rich
* Propeller: High RPM
* Throttle: Open 1/4 inch (~5%-8% setting inSim)
* Parking Brake: Applied ({{Key press|Shift|B}})
* Prop Area: Clear
* Master switch: ON (both)
* Auxiliary Fuel Pump Switch: ON
* Advance mixture to full rich, keep it 3-5sec
* Then Idle Cutoff
* Auxiliary Fuel Pump Switch: Off
* Magnetos: Both (Press {{Key press|<nowiki>}</nowiki>}} three times)
* Ignition: Start ({{Key press|S}})

If engine floods, then set mixture to idle cut off and throttle to 1/2 to full open and crank. When engine fires, set mixture to full rich and throttle to idle.

=== Takeoff ===
* no flaps or flaps 10deg
* cowl flaps open ({{Key press|Shift|F}} several times)
* full throttle
* rotate at 50-60 KIAS

=== Climbout ===
* no flaps
* cowl flaps open
* full throttle
* 80 KIAS

=== Cruise ===
[[File:c182-default.jpg|270px||thumb|Cessna 182S in the air]]
* 2000-2400 RPM
* 18-23 mp
* mixture rich of peak as recommended lean mixture setting for cruise or 125°F rich for best power
* speed between 120-140 knots depending on the power settings
* cowl flaps closed ({{Key press|f}} as appropriate -> watch CHT gauge)

=== Landing ===
* flaps 20deg or full flaps
* 60-70 KIAS

=== Airspeeds ===
: ''See also [[Aircraft speed#V speeds]]''

{| class="wikitable"
! Airspeed !! IAS
|-
| Stall speed, landing configuration, V<sub>S<sub>0</sub></sub> || 36 kt
|-
| Stall speed, clean, V<sub>S<sub>1</sub></sub> || 43 kt
|-
| Rotation speed, V<sub>R</sub> || 55 kt
|-
| Best angle of climb speed, V<sub>X</sub> || 63 kt
|-
| Best rate of climb speed, V<sub>Y</sub> || 80 kt
|-
| Maximum flap extended speed, V<sub>FE</sub> || 100 kt
|-
| Manoeuvring speed, V<sub>A</sub> || 110 kt
|-
| Maximum structural cruising speed, V<sub>NO</sub> || 140 kt
|-
| Never exceed speed, V<sub>NE</sub> || 175 kt
|-
| Max. Crosswind || 15 kt
|}

=== Performance ===

{| class="wikitable"
|Cruise, 80% power, 6,000 ft || 140 kt
|-
|Cruise, 65% power, 8,000 ft || 130 kt
|-
|Cruise, 55% power, 10,000 ft || 121 kt
|}

{| class="wikitable"
|Range, 75% power, 6,000 ft || 820 nm
|-
|Range, 65% power, 8,000 ft || 910 nm
|-
|Range, 55% power, 10,000 ft || 968 nm
|}

{| class="wikitable"
|Best Climb || 924fpm
|-
|Service Ceiling || 18,100ft
|-
|Takeoff ground roll: 795ft over 50ft obstacle || 1,514ft
|-
|Landing ground roll: 590ft over 50ft obstacle || 1,390ft
|}

[[File:c182-cockpit-at-night.jpg|600px|center|Cessna 182S panel illumination]]

== FAQ ==
'''''I wonder why would the 182s be easier to fly than the c172p?'''''

Is it? If you think the fdm is wrong: A fdm is only so good as the datas available. The c182s-fdm uses real coefficient data where available, but not all needed coeeficients could be found. Where not available, pilot reports had been used. And they are from a subjective view of the pilot.

'''''According to google, most pilots agree that the 182s is actually harder to fly than the 172p'''''

Not because of its flight characteristics. Though many pilot bends their firewalls on touchdown, due the nose heaviness of that aircraft. But a lot pilot likes the C182 more because of more power, more speed, higher possible altitudes, [[constant speed propeller]], cowl-flaps and the IFR-equipement. And that`s the reason - due to that all it is much more challenging to fly than the Cessna 172. So FAA counts the Cessna 182 to the high perfomace aircraft. Imagine beeing in a crowded area like KLAX, approaching the airport while listening to Radio calls every few seconds, watching speed, altitude, manage the engine and prop speed, chasing VOR-needles and watching the traffic around at the same time in bad weather condition - challenging!
You might wanna read this: [https://pilotbrian.blogspot.com/2009/05/stepping-up-to-c182.html Stepping Up to a C182 ]

'''''Is the C182S made easier to fly, instead of more realistic to fly?'''''

No. The authors uses real numbers, datas, coefficients and more where available, aiming to get everything realistic as it can be. As an example it matches all the numbers given in the POH, and uses real aerodynamic coeffcients for the fdm where available. If it doesn`t fly as you expect, you might be used to FSX? Just kidding...
Anyway, if encounter something you think it isn`t right, file an Issue-report [https://github.com/HHS81/c182s/issues here], and we will find out.

'''''Why has the C182S a smaller left push tendency than the c172p?'''''

You propably uses a older version of the C182S, released before 6. february 2019. There was a single wrong sign used in the fdm, which reduced the left push tendency. The version released after 6. february 2019 has been fixed in [[FGAddon]] and in the [https://github.com/HHS81/c182s Dev-repo on github.com].

'''''At 3,000 ft, I can't get over 110 knots. MP: 23 RPM: 2450 FF: 14. What am I missing?'''''

The checklist! If it doesn`t get the speed as you expect, check: Mixture, prop rpm, cowl flaps, icing, engine damaged,... Probably you simply forget to close the cowl flaps.
Another reason could be that you mistake KTAS (Knots True AirSpeed) with KIAS (Knots Indicated AirSpeed). The tables and many publications gives the speeds in KTAS. So you have to read the KTAS-values from your instruments, not the KIAS. How to?- just read below.

''''' Where I can see my True Airspeed ([[TAS|KTAS]])?'''''
The Air Speed Indicator has a dial at the upper part of the instrument face. So you simply dial in the pressure altitude (=Altimeter set to 29.92) in ft via the knob, and align it with the temperature mark just below.
Now you can read your true airspeed in the lower left window of your instrument.
[[:File:C182s-ais-tas.png|There is a screenshot]] showing an example of using the TAS disc.

'''''I flew in cold weather, but suddenly crashed because the aircraft slowed down. Where is the carb heat?'''''

The Cessna 182S uses an fuel-injected engine - like many modern cars. So there is no carburetor. But what you experienced is the icing of the prop and the aircraft body. Unfortunately there is indeed a bug: propeller icing of constant speed props can`t be simulated yet with JSBSim. The C182S-team tried to find a work-around, but might not have yet found the best solution....Not everything can be perfect! Anyway: with this type of aircraft you are not allowed to fly in known icing-conditions!

'''''Cessna 182S refuses to start'''''

First: you probably didn`t follow the checklist.
Second: you might have flooded the engine. Follow this procedure: Pull back mixture to cut off, advance throttle to about about little more than 50-60%, then operate the starter again for a while. If the engine fires, promptly advance the mixture to full rich and return throttle to Idle.

'''''Why I can`t see the wingtip and the cowl?'''''

The eye level position has been carefully set comapring informations from pictures showing the Cessna 182S or Cessna 182T and pilot reports. If you compare, you can see that the eye level of the pilot is sitting at the level of the upper edge of the side window frame. The wing root sits much higher, the wingtip even more. So it is impossible to see the wingtip.
The glareshield is quite high on the newer Cessna, and from you usual position you are not able to see the engine cowling in front of you.
And the eye level position is also set to the fact that a good landing is provided why you flare just before the touchdown. Your flare will be correct, when the upper edge of the glareshiels is virtually touching the horizon.

== Development status/Issues/TODO ==

This aircraft is undergoing a constant development, which can be followed on its [https://github.com/HHS81/c182s repository], where a [https://github.com/HHS81/c182s/issues list of issues and future enhancements] can also be found. Worth a visit!

== Gallery ==
{{screenshot cat
| category = Cessna 182S screenshots
| subject = the Cessna 182S
| image = C182-default.jpg
}}{{-}}
<gallery mode="packed">
c182s.jpg|Cessna 182S at dusk
c182-cockpit-view.jpg|Default cockpit view
c182-external2.jpg|HB-CZV livery
c182-external3.jpg|D-ELFP livery
c182-external5.jpg|Cessna 182S over California
c182-external6.jpg|Another view of the HB-CZV livery
C182-4.jpg|Taking off
c182-rosskopf-at-dusk.jpg|Cessna 182S around Roßkopf in Freiburg/ Germany
C182STakeOff.jpg|Cessna 182S with custom registration at Siegerland Airport/ Germany
C182SDavtron803.jpg|The Davtron 803 clock in action
C182SWinterKit.jpg|Winterkit installed, and preheating the engine with an Engine Preheater
C182SFuelManagement.jpg|Fuel Management Dialog
c182-rain.jpg|Rain effect in the windshield
C182-oil-cap.png|Oil cap location
C182SOilManagement.jpg|Oil Management Dialog
C182-fuelports.png|Fuel selector and strainer quick drain valves location
c182-night-take-off.jpg|Ready to take off at night
c182-3.jpg|D-ELFP at dusk
C182SPitot.jpg|Pitot, Cover and message
C182SFreeMovementCheck.jpg|Checking the aileron
C182SCustomRegistration.jpg|The custom registration
c182-external4.jpg|N182PJ livery
c182-external-at-night.jpg|Default livery at night
c182-external1.jpg|N321HW livery
C182Scrashed.jpg|aircraft crashed
AboveSouthGermany.jpg|aircraft flying above South Germany
GXLTGAltenrhein.jpg|aircraft sitting on the apron of St. Gallen-Altenrhein/ Switzerland
</gallery>

== External links ==
* {{Wikipedia|Cessna 182 Skylane|lang=en}}
* [http://www.freechecklists.net/Resources/Cessna/182S+Skylane/ Links to Cessna 182S Checklists and W&B sheet]
* [http://tssflyingclub.org/documents/C182S_POH.pdf Cessna 182S POH]
* [http://www.airborne-aviation.com.au/resources/aircraft/booklet_pco.pdf Cessna 182S Aircraft Information Booklet]

{{Appendix}}

{{Cessna}}

[[Category:Aircraft with a cockpit-only autopilot]]
[[Category:Red Griffin ATC compatible aircraft]]

FlightGear Newsletter April 2021

2021-05-02T14:09:58Z

HHS: Added screenshots of Cessna 182S

{{User:Skybike/Template:Newsletter-header-translate|2021-04}}
{{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>}}



=== 2020.3.8 LTS released - OSM2City world-build release ===
FlightGear 2020.3.8 LTS has been released with an '''experimental''' 1st rollout of [[OSM2City]] buildings, roads and other objects for the entire world. Objects that are in the Open Street Map (OSM) database will be present. Automatic generation for areas without objects is disabled for this release.

See [[OSM2City 1st Worldbuild|'''1st World-build of OSM2City''']] for information on what's included, and tips on performance/troubleshooting.

See 2020.3.8 LTS [[Changelog 2020.3#2020.3.7|change log]] - included are improvements to Europe agriculture appearance, update to random scenery objects such as farm or industrial buildings and silos, California regional definitions improvements (now active), and updated water depth data (bathymetry).<gallery mode="packed" widths="480" heights="200" caption="2020.3.8 LTS improvements. Click to enlarge.">
File:Innsbruck at night in FlighGear with OSM2City worldbuild 03.jpg|alt=Innsbruck at night in FlighGear with OSM2City worldbuild|Innsbruck OSM2City
File:Madrid at dawn in FlightGear 2020.x with the 1st world-build of OSM2City 01.jpg|alt=Madrid at dawn in FlightGear 2020.x with the 1st world-build of OSM2City 01.jpg|Madrid at dawn, OSM2City
File:Rolling agricultural lands stretching away to the horizon in southern France in FlightGear 2020.x 02.jpg|alt=Rolling agricultural lands stretching away to the horizon in southern France in FlightGear 2020.x|Southern Europe - rolling agricultural lands stretching to horizon
File:FlightGear 2020 - Overlooking San Franciso International Airport (KSFO), California with OSM2City output (FlightGear 2020) 02.jpg|alt=FlightGear 2020 - Overlooking San Franciso International Airport (KSFO), California with OSM2City output (FlightGear 2020|California - San Francisco OSM2City
File:Airport keep at San Franciso International Airport (KSFO), California with OSM2City output (FlightGear 2020) 01.jpg|California regional definitions - airport keep
</gallery>Release builds now include {{Wikipedia|Appimage|Appimages}} for Linux. See this discussion of [[Hardware recommendations#Recommendations for FlightGear in 2021 .282020.3 LTS.29|hardware recommendations]] for modern FlightGear - although it is for 2018.3 LTS and doesn't cover the new experimental OSM2City (see the OSM2City page info for perfromance tips).

=== Homepage news posts on 2020.3 LTS ===
There is a [[2020 LTS Keflavik news post draft|draft page]] here for submissions of material for posts on the homepage about changes to FlightGear, Aircraft, Addons etc. since 2018.3 was released, with screenshots. The points are the important thing, don't worry if your English is not perfect. If you need suitable screenshots for the homepage ([https://www.flightgear.org/category/tours/ examples]) for a specific craft or feature that aren't already available ([[:Category:Screenshots at high settings|1]] , [https://wiki.flightgear.org/w/index.php?title=Category:Screenshots_at_high_settings&filefrom=SOTM+2020-03+Mystic+Misty+by+GinGin+%28Space+Shuttle+on+launchpad%2C+Florida%29.jpg#mw-category-media 2] , [https://forum.flightgear.org/viewforum.php?f=88 3]) in the wiki or forum, you can try asking in the forum [https://forum.flightgear.org/viewforum.php?f=19 media] section.

=== The road ahead ===
''See [[FlightGear Newsletter February 2021#Help%20Wanted|'''Help Wanted''']].''

There are a lot of big projects that are currently under way - see the [[FlightGear Newsletter January 2021#The%20road%20ahead|January newsletter]] for details for some of these projects. A lot of work (but not all) is already on the next branch (i.e. nightly builds). There is a lot to check out if you are curious - power users can run [[$FG HOME#Parallel%20installs%20of%20FlightGear|multiple installs]] of FlightGear in parallel. To contribute to any aspect of these projects, get in touch via the "[[Mailing lists|fg-devel]]" mailing list.

Nightly builds with some of the big changes are available at [http://download.flightgear.org/builds/nightly/ download.flightgear.org] as usual.

Please report bugs and issues via the sourceforge [https://sourceforge.net/p/flightgear/codetickets/ tickets] system if you come across any on the next branch, or LTS.

==== Data Distribution Services Update: Property tree support ====
{{Main article|Data Distribution Services Support}}

As of 04/2021, Erik has implemented an initial implementation of a [[Property|property server]] using '''Data Distribution Service'''. And he has also taken the time to implement it [[Remote Properties|like he once envisioned the remote property tree]].

The idea is as follows:

You request a property path, the server responds with the property value and a property index.

Successive requests now can use the index to access the property removing the need to send the full property path every request saving both
bandwidth and lookup time. After thinking about this a bit more I think future revision will have a different scheme.

1. Request the id of the property you are interested in.

2. You get an answer with the property value and id for that property.

3. From now on the server pushes an updated value for that particular

property id whenever the property value changes.

When set up properly DDS will keep the changed properties in it's cache for clients to read when they have time for it.

So no need to do successive requests anymore. Just wait and watch out for updates.

As an example, there is the fg_dds_prop utility in {{Flightgear source|src/Network/DDS/fg_dds_prop.cpp}} which can be used to either request a property path or a know property property ID.

And there is {{Flightgear source|src/Network/DDS/fg_dds_log.cpp}} which is able to log all DDS samples passing over the DDS network layer, including the new
property sample format.

To access properties from a running version of FlightGear use the following command line parameter:

<code>--dds-props=dds,out,<hz></code>

All this is 'next' only. <ref>https://sourceforge.net/p/flightgear/mailman/message/37263034/</ref>

=== New rendering pipeline for Compositor ===
Fernando has been experimenting with adding new rendering features, using the capabilities of the [[Compositor]] - see page for the new [[HDR Pipeline|pipeline]]. The work is "''*very*'' ''experimental''", as Fernando said. It has not been released on the next branch as of writing this - although a ''very limited'' prototype is intended to be added to the FlightGear next branch. The new renderers will assume a higher version of OpenGL, which is one of the many big projects that are being worked on,

The Compositor is a framework to define rendering pipelines - so far the work has been to port the ALS renderer to the new framework, and add the distinguishing features of the old unmaintained Rembrandt renderer like shadows and environmental light definitions without being slow. The idea is to port existing features from both renderers to ensure everything works - the next preview release or LTS will transition to the Compositor. The next LTS will have the existing features as the classic rendering pipeline alongside any new pipelines that are finished, so there's no need to worry about performance hits of features from the new pipeline making very old hardware too slow to run FG. The new pipeline work builds on top. It investigates changing the physical model of aircraft surfaces (to something involving a version of PBR), adding lighting of surfaces from light bouncing off surrounding surfaces including real-time reflections, and implementing a new way of doing HDR algorithm using the new physically based surface model. Some tunable artistic glow (know as [https://en.wikipedia.org/wiki/Bloom_(shader_effect) bloom]) is also supported. The new pipeline is built on top of existing work, and will use the fast shadows and lights added to the ALS port. Fernando hasn't found a way to re-use occlusion data (finding what is visible in the view and what isn't, and culling invisible geometry) between passes in current Open Scene Graph (OSG), so he is using a deferred rendering approach in the prototype to overcome this OSG limitation - it means that anti-aliasing is restricted to post-processing that looks at the rendered image and tries to detect edges and blur them to remove jagged lines.

The current plan is to support {{Wikipedia|GlTF|GlTF}} (Graphics Language Transmission Format) as an alternative for 3d models in future - it supports the new surface model natively. This format also supports binary data (GLB file extension), and these will be smaller than AC files.

As Fernando said, this is all very WiP and experimental - it's an investigation of various approaches like a lot of development. Plans can change. There is no timeline, and progress can vary based on availability of volunteers.

[[HDR Pipeline#Gallery|WiP screenshots]] - keep in mind this is very proof of concept using existing art not especially designed to take advantage of the new surface models, and it only works on aircraft carriers / over the sea. It's not an end-user demo of how a craft designed for these pipeline features will look when done, and shows features that people familiar with rendering and what's been tested can pick up on.

== Related Software tools and projects ==


=== FGCom-mumble ===
[https://github.com/hbeni/fgcom-mumble FGCom-Mumble] aims to provide a mumble based FGCom implementation. This will simulate radio communications in a seamless frequency spectrum. The project aims to be easy to use: Pilots just install the plugin, open mumble, join a channel on a mumble server and start using their radio stack in Flightgear.

The development is discussed in the {{forum link|title=FGCom-mumble|f=32|t=37644}}. Releases can be downloaded from {{github source|user=hbeni|repo=fgcom-mumble|text=GitHub}}. The project also has a flightgear wikipage: [[FGCom-mumble]]

==== Mumble 1.4.0 development master received plugin framework ====
The new plugin framework feature finally reached mumbles master development branch. This means that from now on, self-compiling users just need to build the ordinary master branch of the upcoming 1.4.0 or just use one of the precompiled [https://dev.azure.com/Mumble-VoIP/Mumble/_build?definitionId=6 Mumble 1.4.0 nightly development snapshots].

==== Plugin development status ====
Right now, the latest FGCom-mumble [https://github.com/hbeni/fgcom-mumble/releases/tag/v.0.12.0 release v.0.12.0] fixes a bug with the new FGFS addon which prevented to load the protocol definition. If you tried the addon with 0.11.0, you need to patch your extracted addon folder manually with the provided upgrade.

Under the hood on the server side, the statuspage usage statistics got an upgrade that allows [https://github.com/hbeni/fgcom-mumble/blob/master/server/statuspage/Readme.statuspage.md#usage-statistics selection of the displayed timeframe of the graph]. Also, stale clients have a grey icon now. Both is already available [http://fgcom.hallinger.org/ at the online statuspage of the test server].

Release 0.12.0 also brings support for MacOS users!

Also, we now have support for FlightGear ADF data, so the aircrafts first ADF receiver will pick up FGCom-mumble transmissions and drive the needle in your ADF gauge! This could for example be used to fly with user created NDBs (maybe radio stations) - just record something to a suitable frequency with the RadioGUI and enjoy your custom NDB navaid!

==== New nightlies and debug build release ====
On GitHub there are now also [https://github.com/hbeni/fgcom-mumble/actions nightly builds] that also provide a debug-version of the plugin, which will help in tracking down errors. The debug version provides extensive logging to the console, and optionally to a logfile if configured to do so. Please use such a debug log if opening tickets (if applicable), because it helps to track down what happened during execution.

== In the hangar ==

=== Space Shuttle Milestone 13 released ===
Copy & Paste from this post by Thorsten: https://sourceforge.net/p/flightgear/mailman/message/37266972/ :

''We're happy to announce the arrival of the [[Space Shuttle|Shuttle]] milestone 13 while at
the same time welcoming GinGin as new collaborator in the team (who has
done most of the work for this milestone). Given the state of the spacecraft before, you might reasonably ask - is there anything substantial that can still be added? You'll be the judge of that, but I think there is.''

* ''thanks to new aero data, we now have a better description of the hypersonic flight phase from Mach 27 down to about Mach 5''

* ''GinGin has been patiently digging into NASA documents and replaced my home-written guidance for the launch and entry trajectories by something that is much more shaped like the real thing, for instance the launch trajectory is now somewhat flatter and reaches a later arctop''
* ''also, thanks to GinGin's patient work, we now have pretty much all the display pages very close to the original appearance (they've been moved to the original font, items blink where they should, and the limit sensing overlay which indicates when a value is off-nominal has been added)''
* ''a lot of time has gone into testing and fixing issues with launch aborts. They're generally a wide field in that they probe a huge kinematical region in terms of what can happen, but are interesting because they actually showcase what the Shuttle can do with a rocket engine and as a hypersonic vehicle, and they provide a high-workload and challening environment for the crew. We now have voice callouts for the abort boundaries (what maneuver should be flown when), as well as literally dozens of different cases tested and the guidance parameters adjusted to resolve small issues''
* ''also, I've added the helium system (providing a purge for the engines during launch) including full failure and leakage capability, which was one of the last remaining systems that were not simulated in gory detail''
* ''to make use of all that failure modeling, a new failure training mode throws a random scenario at selectable difficulty level at the user as a challenge - so you don't know up-front what will happen''
* ''a new view to simulate the RMS arm camera simplifies grabbing objects in space''
* ''a virtual notepad to record voice calls from mission control or display payload attachment points''

''All in all, with three people flying tests for more than a month, this is probably the best-tested milestone we ever had, and it's been verified to run all the way back to 2018.3. I'm currently in the last stages of updating the manual, which will be available within a few days.''

''Enjoy!''
[[File:Shuttle cockpit before launch.jpg|alt=FlightGear Space Shuttle cockpit with internal lighting|none|thumb|700x700px|[[Space Shuttle]] cockpit before launch with internal lighting]]



=== New aircraft ===

==== BAE/Avro 146 ====
The development of BAE146 starts 2 weeks ago. It's still unbublished. Main developer - SP-NTX.

To do:

* 3D Model.
* FDM (jsbsim).
* Cockpit.
* Screens (Canvas).
* Wiki page.

=== Updated aircraft ===

==== Cessna 182S / 182T ====
The [[Cessna 182S]] ([https://github.com/HHS81/c182s git version]) got some really exiting enhancements over the last half year, and is now also available on [[FGAddon|FGAddon]]:
[[File:C182Scrashed.jpg|thumb|Cessna 182S on the rwy crashed]][[File:GXLTGAltenrhein.jpg|thumb|Cessna 182S new livery G-XLTG on the apron of the Airport St. Gallen Altenrhein/ Schweiz]]
* The EGT Indicator knob got a long due label now and features the original scale as well as a properly yellow colored needle.
* The CHT was retextured with the original scale too.
* The VOR gauges have the yellow tick marks as reference for the course wheel; and the OBS label on the knob.
* The ADF gauge features red ticks and a more detailed aircraft symbol.
* The transponder buttons are visually depressed when clicked now.
* The KAP-140 Autopilot was upgraded to Sascha Reißners new version and the control loop finetuned by Josh Davidson. This new version does not only feature a nice preflight check, but brought the realism to a whole new level. The UP/DN buttons can be used now to change altitude in ALT mode when continuously pressed, the AP disconnects in high-G situations and it features an AP disconnect knob as well as a CWS knob to temporarily disengage. The autopilot now realistically simulates the attached servo motors to drive the flight control surfaces, and they can of course fail. The REV mode now actually works and one can do a all-angle-intercept from ROL mode into NAV/APR/REV.
* The model supports damage now, so you can crash the gear when landing too hard and actually see that.
* Flying too low in forests make you hit the trees now.
* The pilot seat position can be adjusted forward/backward and this is stored.
* Starting the engine now causes visible vibrations in the plane.
* Spark plug icing is simulated, so in freezing conditions when the engine just revolves a few rounds and then quits, it possibly may not be able to start again.
* The radio stack was upgraded to the new model, supporting 8.33 channels.
* Multiplayer enhancements, many more properties are transmitted now. Also the custom registration was converted to canvas, making it visible in mutliplayer now (Note: When you use the new model, you will see the gear collapsed at old version multiplayer clients).
* Passengers and copilot are visually in the plane now (also in multiplayer!)
* Some corner cases in the FDM were fixed, most notably the plane is now more stable in high-wind conditions and also does not swing left/right so much when osciallating the yoke. Also the flap pitch reactions are even more realistic now.
* The gear damping values were revised and also the nose gear scissor animation was added as well as the oleo strut reworked.
* Some minor fixes and additions in the electrical system.
* Some minor fixes in the startup state system; also the GUI was reworked so it has a drop-down instead of a radio button menu.
* Aircraft tags were revised and switched to standard tags in some occasions.
* Splash screens where ported to the new system, and URLs were added so one can lookup documentation from the launcher.
* Aircraft menus were reordered and are more consistent to the C172p now. Also a small "about" dialog was added.
* Some small fixes in the failure manager, regarding failed flaps.
* The yoke can be shown/hidden with lowercase "y" now, previously it was just uppercase "Y", which is now in line with the C172. Also the yoke now goes transparent instead of being completely hidden (transparency level is configurable in the aircraft dialog).
* Some minor texture fixes in the cockpit.
* Dual control for a copilot to share the ride (view-only for now).
* Multiplayer Aerotowing support added.
* Adding support for the default "c" keybind to hide the 3D-cockpit.
* New f/F keybinds to adjust cowl flaps.
* Gravel- and Pavement roll sounds from the C172 project.
* Better all-angle.intercept handling for the KAP-140 autopilot (currently it sometimes briefly initiates a 45° turn when capturing the beam).
* Upgraded the [[Davtron M803]] digital clock with new FT/ET alarm timers and ET count-down mode and fixed boot-up state.
* The starter motor power drain is more realistic now.
* The C182T is upgraded to include all shared systems to the current level of the C182S, so now the electrical system is working as intended and the failure manager can fail most systems specific to the T-variant too. The C182T can now also Ice and has the advanced fuel and engine system etc; also multiplayer fixes are contained.
* Update to use compositor lights

All those changed where deployed to the FGAddon hangar already!



=== Instruments ===
* A fully simulated [[Davtron_M803]] digital clock is now available, featuring all the timers and alarm modes. The source is currently in the c182s project. Forum thread: {{forum link|t=38955|title=Davtron M803}}



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





=== Wiki updates ===
* A new article was drafted, describing the "magical blue lever" aka. [[Constant speed propeller]]


=== 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 ==
=== Upcoming events ===
A bunch of pilots currently do (mostly) GA flights on wednesdays evenings. Look at the forums for details! Everyone is welcome, the more, the merrier!
We are casually flying, so no procedures/radio phrases knowledge needed (but we are happy if you do)








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

File:AboveSouthGermany.jpg

2021-05-02T14:03:28Z

HHS: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{de|1=Cessna 182S über Süddeutschland}}
{{en|1=Cessna 182S above South Germany}}
|date=2021-05-02 15:55:12
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Cessna 182S screenshots]]

File:C182Scrashed.jpg

2021-05-02T14:03:28Z

HHS: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{de|1=Cessna 182S auf der Runway verunfallt}}
{{en|1=Cessna 182S crashed on the runway.}}
|date=2021-05-02 15:59:21
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Cessna 182S screenshots]]

File:GXLTGAltenrhein.jpg

2021-05-02T14:03:28Z

HHS: Uploaded own work with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{de|1=Cessna 182S G-XLTG auf dem Vorfeld des Flughafens St. Gallen Altenrhein/ Schweiz}}
{{en|1=Cessna 182S G-XLTG on the apron of the aiport St. Gallen Altenrhein/ Switzerland}}
|date=2021-05-02 15:57:55
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Cessna 182S screenshots]]

Compositor

2021-01-04T17:29:35Z

HHS: /* Lights */

{{forum|47|Effects & Shaders}}

{{infobox subsystem
|image = Compositor logo.png
|name = Compositor Framework
|started = 01/2018 (Available since FlightGear 2020.4)
|description = Dynamic rendering pipeline configured via the [[Property tree]] and [[PropertyList XML File|XML]]
|status = Stable (merged and actively maintained)
|developers = Fernando García Liñán <ref>https://sourceforge.net/u/fgarlin/profile/</ref>
|changelog = https://sourceforge.net/u/fgarlin/profile/feed.rss
|folders =
* {{simgear file|simgear/scene/viewer}}
* {{flightgear file|src/Viewer}}
* {{fgdata file|Compositor}}
}}

The '''Compositor''' aims to bring multi-pass rendering to FlightGear. It encapsulates a rendering pipeline and exposes its parameters to a [[Property Tree]] interface. At startup, FlightGear reads the pipeline definition file for each physical viewport defined on the [[Howto:Configure camera view windows|CameraGroup settings]]. If no Compositor file is specified for a physical camera, the one given by the <code>--compositor=</code> startup command will be used. If such startup option is not used either, FlightGear will look for a valid Compositor file in <tt>$FG_ROOT/Compositor/default.xml</tt>.

The Compositor introduces a new dedicated fgdata directory for new/custom rendering pipelines: {{Fgdata file|Compositor}}.

== Background ==
{{See also|Supporting multiple renderers|Howto:Canvas View Camera Element}}

First discussed in 03/2012 during the early [[Rembrandt]] days, Zan (Lauri Peltonen) came up with a set of patches demonstrating how to create an XML-configurable rendering pipeline. Back then, this work was considered to look pretty promising <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28946515/
|title = <nowiki> Re: [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Mathias Fröhlich </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref> and at the time plans were discussed to unify this with the ongoing Rembrandt implementation (no longer maintained).

Adopting Zan's approach would have meant that efforts like [[Rembrandt]] (deferred rendering) could have been implemented without requiring C++ space modifications, i.e. purely in [[Base package]] space. Rembrandt's developer (FredB) suggested to extend the format to avoid duplicating the stages when you have more than one viewport, i.e. specifying a pipeline as a template, with conditions like in effects, and have the current camera layout refer the pipeline that would be duplicated, resized and positioned for each declared viewport <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28944773/
|title = <nowiki> Re: [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Frederic Bouvier </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref>

Zan's original patches can still be found in his newcameras branches which allow the user to define the rendering pipeline in preferences.xml: {{gitorious source|proj=fg|repo=zans-flightgear|branch=newcameras|text=FlightGear}}, {{gitorious source|proj=fg|repo=zans-simgear|branch=newcameras|text=SimGear}}. At that point, it didn't have everything Rembrandt's pipeline needs, but most likely could be easily enhanced to support those things. Basically, the original version added support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28944733/
|title = <nowiki> [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Lauri Peltonen </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref>

Since the early days of Zan's groundwork, providing the (hooks) infrastructure to enable base package developers to prototype, test and develop distinct rendering pipelines without requiring C++ space modifications has been a long-standing idea, especially after the [[Canvas]] system became available in early 2012, which demonstrated how RTT-rendering buffers (FBOs) could be set up, created and manipulated procedurally (i.e. at run-time) using XML, the property tree and [[Nasal]] scripting. <ref>{{forum link|type=search|title=Zan's Rembrandt and Canvas work|keywords=zan+rembrandt+canvas}}</ref>

The new '''Compositor''' is an improved re-implementation of Zan's original work using not just XML, but also [[Property Tree|properties]] and a handful of [[Canvas]] concepts.

== Features ==

* Completely independent of other parts of the simulator, i.e. it's part of [[SimGear]] and can be used in a standalone fashion if needed, ala Canvas.
* Although independent, its aim is to be fully compatible with the current rendering framework in FG. This includes the [[Effects]] system, [[Howto:Configure camera view windows|CameraGroup]], [[Rembrandt]], [[ALS]] and [[Canvas]].
* Its functionality overlaps Rembrandt: what can be done with Rembrandt can be done with the Compositor, but not vice versa.
* Fully configurable via an XML interface without compromising performance (ala Effects, using [[PropertyList XML File|PropertyList files]]).
* Flexible, expandable and compatible with modern graphics.
* It doesn't increase the hardware requirements, it expands the hardware range FG can run on. People with integrated GPUs (Intel HD etc) can run a Compositor with a single pass that renders directly to the screen like before, while people with more powerful cards can run a Compositor that implements deferred rendering, for example.
* Static branching support. Every pipeline element can be enabled/disabled at startup via a [[Conditions|<condition> block]].
* The entire rendering pipeline can be reloaded via an fgcommand (<tt>reload-compositor</tt>).

== How to enable the Compositor ==

The Compositor is now the default renderer framework in FlightGear since 2020/11/17. It will be included as part of version 2020.4 onwards.

If you compile FlightGear from source, you can already try the Compositor. Make sure you are pulling the latest version of the 'next' branch. You can also try out the latest nightly build from the [[FlightGear build server]].

== Notes for aircraft developers ==

=== Lights ===

The Compositor introduces a new way of defining lights that is renderer agnostic, so every rendering pipeline will be able to access the lights that have been implemented like this. The resulting light volumes can be visualized for debugging purposes by setting the property <tt>/sim/debug/show-light-volumes</tt> to true. It is important setting <tt>sim/rendering/clustered-shading/enabled</tt> to true, otherwise you won´t have any illuminations.

[[Project Rembrandt]] light definitions are also read by the Compositor for backwards compatibility reasons. However, it is not recommended to use the old syntax for new/updated projects.

{|cellpadding=10|
|valign=top style="width: 20%;"|
<syntaxhighlight lang="xml">
<light>
<name>my-spotlight</name>
<type>spot</type>
<position>
<x-m>-7.7476</x-m>
<y-m>0</y-m>
<z-m>-1.7990</z-m>
</position>
<direction>
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</direction>
<ambient>
<r>0.03</r>
<g>0.03</g>
<b>0.03</b>
<a>1</a>
</ambient>
<diffuse>
<r>0.95</r>
<g>0.9</g>
<b>0.9</b>
<a>1</a>
</diffuse>
<specular>
<r>0.95</r>
<g>0.9</g>
<b>0.9</b>
<a>1</a>
</specular>
<attenuation>
<c>1.0</c>
<l>0.09</l>
<q>0.032</q>
</attenuation>
<spot-exponent>5</spot-exponent>
<spot-cutoff>40</spot-cutoff>
<range-m>50</range-m>
<dim-factor>
<property>controls/lighting/instruments-norm</property>
</dim-factor>
</light>
</syntaxhighlight>
|valign=top style="width: 80%;"|
* <tt>'''name'''</tt>. An {{tag|animation}} will be able to reference the light by this name. Most animations will work as expected (rotate, translate, spin etc). Material animations are not supported.
* <tt>'''type'''</tt>. <tt>spot</tt> or <tt>point</tt>.
* <tt>'''position'''</tt>. The position of the light source in model space and in meters.
* <tt>'''direction'''</tt>. Only available in <tt>spot</tt> lights. It indicates the direction of the spotlight. This parameter can be specified in three different ways:
{| class="wikitable" style="border: 1px solid darkgray;"
! scope="col" style="width:33%;" |Direction vector
! scope="col" style="width:33%;" |Look-at point
! scope="col" style="width:33%;" |Rotation angles
|-
| style="padding: 10px" | A vector in model space that specifies the direction. Doesn't have to be normalized.
<syntaxhighlight lang="xml">
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</syntaxhighlight>
| style="padding: 10px" | The spotlight will calculate its direction by looking at this position from the light position. The point is in model space and in meters.
<syntaxhighlight lang="xml">
<lookat-x-m>-8.031</lookat-x-m>
<lookat-y-m>0</lookat-y-m>
<lookat-z-m>-2</lookat-z-m>
</syntaxhighlight>
| style="padding: 10px" | A three angle rotation in degrees that rotates the spotlight around the three axes. A 0 degree angle in all axes makes the spotlight point downwards (negative Z).
<syntaxhighlight lang="xml">
<pitch-deg>90</pitch-deg>
<roll-deg>0</roll-deg>
<heading-deg>0</heading-deg>
</syntaxhighlight>
|}
* <tt>'''ambient'''</tt>, <tt>'''diffuse'''</tt> and <tt>'''specular'''</tt>. Four-component vectors that specify the light color.
* <tt>'''attenuation'''</tt>. Three-component vector where <code><c></code> specifies the constant factor, <code><l></code> specifies the linear factor and <code><nowiki><q></nowiki></code> specifies the quadratic factor. These factors are plugged into the OpenGL light attenuation formula [[File:Spotlight_attenuation.png]] where d is the distance of the fragment to the light source. See this [http://wiki.ogre3d.org/tiki-index.php?page=-Point+Light+Attenuation table] for a list of attenuation values based on the range of the light.
* <tt>'''range-m'''</tt>. Maximum range from the light source position in meters. This value will be used by the renderers to determine if a fragment is illuminated by this source. Every fragment outside this range isn't guaranteed to be affected by the light, even if the attenuation factor isn't 0 in that particular fragment.
* <tt>'''spot-cutoff'''</tt>. Only available in <tt>spot</tt> lights. It specifies the maximum spread angle of a light source. Only values in the range 0 90 are accepted. If the angle between the direction of the light and the direction from the light to the fragment being lighted is greater than the spot cutoff angle, it won't be lit.
* <tt>'''spot-exponent'''</tt>. Only available in <tt>spot</tt> lights. Higher spot exponents result in a more focused light source, regardless of the spot cutoff angle.
* <tt>'''dim-factor'''</tt> ('''Optional'''). Controls the dimming of the light source through an [[Expressions|expression]].
* <tt>'''debug-color'''</tt> ('''Optional'''). Sets the color of the debug light volume. By default it's red.
|}

=== Shadows ===

The shadow mapping algorithm can be customized entirely by the rendering pipeline. This means that each pipeline will have its own requirements when it comes to shadows. Here are some general recommendations:

* Use the [[Howto:Animate models#Noshadow|<tt>noshadow</tt> animation]] to disable shadows on objects that don't need them. An example would be billboarded lights (light sprites) or really small cockpit elements that don't need shadows and would cause degraded performance.
* Try to mark as many cockpit objects as possible as <tt>interior</tt>.
<syntaxhighlight lang="xml">
<model>
<name>interior</name>
<usage>interior</usage>
<path>Aircraft/JA37/Models/ja37-interior.xml</path> 
</model>
</syntaxhighlight>
* Unlike in Rembrandt, polygons facing the Sun are the ones used to generate the shadow map, so single sided surfaces and non-closed objects should be rendered correctly.

== Porting and developing Effects/Shaders ==

Effects can now have different implementations depending on the Compositor pipeline being used. For example, a grass Effect implemented for a high quality pipeline might have much more detail than one that targets low specification machines. Still, they both implement the "look" of grass, so they share the same Effect file (grass.eff).

The Compositor chooses which implementation of an Effect to render based on the <tt><scheme></tt> of the techniques.
<syntaxhighlight lang="xml">
<technique n="15">
<scheme>test-scheme</scheme>
[...]
</technique>
</syntaxhighlight>

In this case the technique will be chosen if the Compositor pipeline <tt><scene></tt> pass uses the <tt>test-scheme</tt> Effect scheme. Consequently, porting an Effect to a pipeline will require knowing which Effect schemes it uses and writing a technique for each one. The only exception to this is the Classic pipeline, which uses techniques with no scheme.

== Creating a custom rendering pipeline ==

Since the Compositor is completely data-driven, new rendering pipelines can be created by writing a custom XML pipeline definition. This section tries to document most of the available parameters, but the best and most up-to-date resource is the Compositor parsing code in SimGear ({{simgear file|simgear/scene/viewer}}). See existing pipelines in {{fgdata file|Compositor}} for practical examples on how to use these parameters.

Also keep in mind that every pipeline element can be enabled/disabled through a [[Conditions|<condition> block]]. This allows for dynamic rendering pipelines that have toggleable features. However, the pipeline can't be updated in real-time: the simulator has to be restarted or the Compositor has to be reloaded through the <tt>reload-compositor</tt> [[Fgcommands|fgcommand]].

=== Buffers ===

A buffer represents a texture or, more generically, a region of GPU memory.

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>name</tt>
| {{No}}
| string
|
| Passes will be able to address the buffer by this name
|-
! scope="row"| <tt>type</tt>
| {{No}}
| <tt>1d, 2d, 2d-array, 2d-multisample, 3d, rect, cubemap</tt>
|
| Any texture type allowed by OpenGL
|-
! scope="row"| <tt>width</tt>
| {{No}}
| Any unsigned integer or <tt>screen</tt> to use the physical viewport width. The <code><property></code> tag can also be used to use a property value
|
| Texture width
|-
! scope="row"| <tt>screen-width-scale</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
| If <tt>screen</tt> was used, this controls the width scaling factor
|-
! scope="row"| <tt>height</tt>
| {{No}}
| Any unsigned integer or <tt>screen</tt> to use the physical viewport height. The <code><property></code> tag can also be used to use a property value
|
| Texture height
|-
! scope="row"| <tt>screen-height-scale</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
| If <tt>screen</tt> was used, this controls the height scaling factor
|-
! scope="row"| <tt>depth</tt>
| {{No}}
| Any unsigned integer. The <code><property></code> tag can also be used to use a property value
|
| Texture depth
|-
! scope="row"| <tt>format</tt>
| {{Yes}}
| See {{simgear file|simgear/scene/viewer/CompositorBuffer.cxx}} for the latest available values
| <tt>rgba8</tt>
| Specifies the texture format. It corresponds to the ''internalformat'', ''format'' and ''type'' arguments of the OpenGL function ''glTexImage2D''
|-
! scope="row"| <tt>min-filter, mag-filter</tt>
| {{Yes}}
| <tt>linear, linear-mipmap-linear, linear-mipmap-nearest, nearest, nearest-mipmap-linear, nearest-mipmap-nearest</tt>
| <tt>linear</tt>
| Change the minification and magnification filtering respectively
|-
! scope="row"| <tt>wrap-s, wrap-t, wrap-r</tt>
| {{Yes}}
| <tt>clamp, clamp-to-edge, clamp-to-border, repeat, mirror</tt>
| <tt>clamp-to-border</tt>
| They change the wrap mode for each coordinate
|-
! scope="row"| <tt>anisotropy</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
|
|-
! scope="row"| <tt>border-color</tt>
| {{Yes}}
| vec4
| <tt>(0.0f, 0.0f, 0.0f, 0.0f)</tt>
|
|-
! scope="row"| <tt>shadow-comparison</tt>
| {{Yes}}
| bool
| <tt>true</tt>
|
|-
! scope="row"| <tt>shadow-texture-mode</tt>
| {{Yes}}
| <tt>luminance, intensity, alpha</tt>
| <tt>luminance</tt>
|
|-
! scope="row"| <tt>shadow-compare-func</tt>
| {{Yes}}
| <tt>never, less, equal, lequal, greater, notequal, gequal, always</tt>
| <tt>lequal</tt>
|
|}

=== Passes ===

A pass wraps around an [http://public.vrac.iastate.edu/vancegroup/docs/OpenSceneGraphReferenceDocs-3.0/a00089.html osg::Camera]. Passes all have some common parameters:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>clear-color, clear-accum, clear-depth and clear-stencil</tt>
| {{Yes}}
| vec4
| black, black, <tt>1.0</tt>, <tt>0</tt> respectively
| Pass clear colors
|-
! scope="row"| <tt>clear-mask</tt>
| {{Yes}}
| <tt>color, stencil, depth, accum</tt>
| <tt>color depth</tt>
| Pass clear mask
|-
! scope="row"| <tt>effect-scheme</tt>
| {{Yes}}
| Valid effect scheme name
| None
| The pass will try to use the specified effect scheme to draw every object.
|}

Passes can render to a buffer (Render to Texture), to several buffers (Multiple Render Targets) or directly to the framebuffer. This is accomplished by the <code><attachment></code> tag. Possible parameters of an attachment are:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>buffer</tt>
| {{No}}
| Valid buffer name
|
| The name of the buffer to output to
|-
! scope="row"| <tt>component</tt>
| {{No}}
| <tt>color, color0</tt> to <tt>color15, depth, stencil, depth-stencil</tt>
|
| FBO attachment point
|-
! scope="row"| <tt>level</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Mipmap level of the texture that is attached
|-
! scope="row"| <tt>face</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Face of cube map texture or z-level of 3d texture
|-
! scope="row"| <tt>mipmap-generation</tt>
| {{Yes}}
| bool
| <tt>false</tt>
| Whether mipmap generation should be done for texture
|-
! scope="row"| <tt>multisample-samples</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Multisample anti-aliasing (MSAA) samples
|-
! scope="row"| <tt>multisample-color-samples</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Multisample anti-aliasing (MSAA) color samples
|}

Passes can also receive buffers as input and use them in their shaders. This is accomplished by the <code><binding></code> tag, which has the following parameters:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>buffer</tt>
| {{No}}
| Valid buffer name
|
| The name of the buffer to bind
|-
! scope="row"| <tt>unit</tt>
| {{No}}
| int
|
| The texture unit to place the texture on. Effects will be able to access the buffer on this texture unit
|}

There are specific pass types, each with their own set of custom parameters.

==== scene ====
Renders the scene from the point of view given by the CameraGroup.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>cull-mask</tt>
| {{Yes}}
| A 32 bit number. See {{simgear file|simgear/scene/util/RenderConstants.hxx}} to know which bits enable what
| <tt>0xffffffff</tt>
| Specifies the cull mask to be used in the underlying <tt>osg::Camera</tt>
|-
! scope="row"| <tt>z-near, z-far</tt>
| {{Yes}}
| float
| 0.0 uses the value given by the CameraGroup
| Sets a custom near and far values. Useful for implementing depth partition and limiting the depth range on cubemap passes
|-
! scope="row"| <tt>cubemap-face</tt>
| {{Yes}}
| int
| <tt>-1</tt> (don't use cubemap)
| Ignores the given view and projection matrices and uses a custom one that renders the scene as if it was seen from inside a cubemap looking towards the specified face
|-
! scope="row"| <tt>use-shadow-pass</tt>
| {{Yes}}
| string
| Empty
| Name of a shadow mapping pass. Exposes shadow mapping related uniforms to the shaders of the current pass
|}

Scene passes can also use the tag <code><clustered-shading></code> to enable clustered shading (lights). The following parameters are available:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>max-pointlights</tt>
| {{Yes}}
| int
| 1024
| Maximum amount of point light sources allowed on the entire scene
|-
! scope="row"| <tt>max-spotlights</tt>
| {{Yes}}
| int
| 1024
| Maximum amount of spot light sources allowed on the entire scene
|-
! scope="row"| <tt>max-light-indices</tt>
| {{Yes}}
| int
| 256
| Size of the light indices texture. Keep in mind that it is a 2D texture, so the total size will be e.g. 256x256
|-
! scope="row"| <tt>tile-size</tt>
| {{Yes}}
| int
| 128
| Size of each clustered shading tile
|-
! scope="row"| <tt>num-threads</tt>
| {{Yes}}
| int
| 1
| Number of threads to use during the light culling process. Keep in mind that a high thread count when there aren't many lights will worsen performance due to the thread creation overhead
|-
! scope="row"| <tt>depth-slices</tt>
| {{Yes}}
| int
| 1
| Number of slices to partition the view frustum in the Z axis. Higher numbers will cull lights more aggressively, increasing performance if there are many lights further out that don't contribute much to the overall scene's lighting
|}

==== quad ====
Renders a fullscreen quad with an optional [[Effects|effect]] applied. Useful for screen space shaders (like SSAO, Screen Space Reflections or bloom) and deferred rendering.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>geometry</tt>
| {{Yes}}
| float values for <code><x>, <y>, <width>, <height>, <scale></code>
| <tt>0.0, 0.0, 1.0, 1.0, 1.0</tt> respectively
| Size of the fullscreen quad inside the viewport using normalized coordinates.
|-
! scope="row"| <tt>effect</tt>
| {{Yes}}
| Valid Effect file
| None
| This Effect will be applied to the quad geometry
|}

==== csm ====
Implements Cascaded Shadow Mapping by rendering the scene from a light's point of view (the Sun by default). For now it only supports directional light sources. There has to be one <tt>csm</tt> pass for each cascade.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>light-name</tt>
| {{Yes}}
| Valid light name that exists in the scene graph
| <tt>FGLightSource</tt> (Sun)
| The name of the <tt>osg::LightSource</tt> to use for this shadow map
|-
! scope="row"| <tt>render-at-night</tt>
| {{Yes}}
| bool
| true
| Whether to render the shadows at night or not
|-
! scope="row"| <tt>near-m, far-m</tt>
| {{No}}
| float (meters)
|
| They specify the range of the shadow map
|}

== References ==
{{Appendix}}

== Related content ==
=== Wiki articles ===
* [[Canvas View Camera Element]]
* [[CompositeViewer Support]]
* [[Uniform Buffer Objects]]
* [[FlightGear CIGI Support (Common Image Generator Interface)]]

=== Forum topics ===
* {{forum link|t=36269|text=The Compositor}}
* {{forum link|t=35095|text=Clustered Forward Rendering}} (12/2018)
* {{forum link|t=33045|text=Getting started with RTT}}

[[Category:Compositor]]

Talk:Building using CMake - Windows

2020-12-14T21:16:52Z

HHS:

== VS 2015 for win 10 ==

Can I use Visual studio 2015 for win 10?
--[[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 22:40, 3 February 2017 (EST)

Apperently not, it seems the Visual Studio to use is called "for Windows Desktop".. --[[User:Necolatis|Necolatis]] ([[User talk:Necolatis|talk]]) 00:33, 4 February 2017 (EST)

: Yes, [https://www.visualstudio.com/en-us/productinfo/vs2015-sysrequirements-vs Win10 is supported].

:[[User:Bugman|Bugman]] ([[User talk:Bugman|talk]]) 15:27, 4 February 2017 (EST)

== Still up to date? ==
It seem the article isn`t up to date anymore.

For noobs like me, who never compilated any program before, the tutorial is sometimes hard to follow.
So I already changed a small error in this tutorial which prevented to compilate.
Anyway, I get following error message every time I want to launch: base package not found, requird data files not found, check yout installation, looking for base-package files at:´../data´

So I tried the next part of the tutorial just to end here : "The first time you'll have to choose where FGDATA is -- to do this, select the 'fgdata' directory you cloned at the start." It is not clear to me where to select.

Any Idea?
--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 07:01, 13 December 2020 (EST)

> It seem the article isn`t up to date anymore.

Please do elaborate. It should be up to date as of November 2020.

> So I tried the next part of the tutorial just to end here : "The first time you'll have to choose where FGDATA is -- to do this, select the 'fgdata' directory you cloned at the start." It is not clear to me where to select.

It shouldn't ask you any more than once ...?
Did you have the folder structure matching the one given here? Example: https://i.imgur.com/9rEzkPu.png

[[User:Legoboyvdlp|Legoboyvdlp]] ([[User talk:Legoboyvdlp|talk]]) 10:07, 13 December 2020 (EST)

>> Please do elaborate. It should be up to date as of November 2020.

I had difficulties to follow some of the steps, especially downloading the right version of Qt5. The text didn`t match quite what I saw in the installer. When I get FGFS running here, I will try to impove by adding some explaining pictures. That would have helped me a lot.

>> It shouldn't ask you any more than once ...?
>> Did you have the folder structure matching the one given here? Example: https://i.imgur.com/9rEzkPu.png

It looks like for me it does: https://abload.de/img/fgbuild_filestructureopk15.jpg

But I don´t get it, where I have to select the 'fgdata'?
Everytime I try to launch via launch.bat or fgfs.exe, or via VisualStudio I get following image:
https://abload.de/img/flightgear.buildmbknm.jpg

Thanks

--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 11:55, 13 December 2020 (EST)

>>> I had difficulties to follow some of the steps, especially downloading the right version of Qt5. The text didn`t match quite what I saw in the installer. When I get FGFS running here, I will try to impove by adding some explaining pictures. That would have helped me a lot.

Thanks, that would be appreciated!

Ah, ok, I thought you meant a window like this: https://i.imgur.com/FoJ5rPZ.png
But as its looking for /data/ maybe try renaming fgdata to data... but for me, it looks for fgdata, that's why I set it to that :/

[[User:Legoboyvdlp|Legoboyvdlp]] ([[User talk:Legoboyvdlp|talk]]) 15:34, 13 December 2020 (EST)

It seems Qt5 is the reason for- after forcing it to the FGData location, fianlly FlightGear started but wihout launcher. The console said that it couldn´t finde the Qt launcher, because Qt didn´t compiled.
So I´ll try again with Qt5...
--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 16:16, 14 December 2020 (EST)

Talk:Building using CMake - Windows

2020-12-13T16:55:41Z

HHS:

Talk:Building using CMake - Windows

2020-12-13T12:01:57Z

HHS:

Building using CMake - Windows

2020-12-13T11:48:35Z

HHS: Change to windows-3rd-party otherwise it won`t compilate

{{Main article|Building Flightgear}}
This article is intended to give an overview of building FlightGear on modern Windows systems. It was created using Windows 10 and VS 2019. It ought to be transferrable to earlier versions of the Windows OS and software.

As FlightGear is now 64-bit only, the guide only describes building on a 64-bit system.

== Required software ==
* [https://cmake.org/download/ CMake for Windows]. Download and install the Windows Win64-x64 Installer.
* [https://visualstudio.microsoft.com/downloads/ Microsoft Visual Studio 2019] (MSVC). The Community version is free. There is no need for the premium versions; none of their features are required to build FlightGear. The C++ compiler will not be installed by default. You either choose this component during installation or after installation by starting MSVC and trying to create a new C++ project. The one to download is "Desktop Development with C++". Make sure to have the last version of the Windows SDK and C++ Compiler checked. As of 08/10/2020, the latest version of the compiler is "MSVC 142 - VS 2019 C++ x64/86 build tools (v14.27)".
* [https://www.qt.io/download-open-source/ Qt5] for the [[Integrated Qt5 Launcher]]. Download the online installer, and choose the version matching your toolchain of Visual Studio e.g. "Qt 5.15.1 --> MSVC 2019 64 bit". Any version past 5.9 will be fine; 5.15 recommended. Leave the default Developer and Designer Tools selection - these are needed for coding and compiling.
* [https://git-scm.com/download/win Git] to keep your build up to date. It also simplifies downloads of components. Optional, but can't recommend it enough!

== Obtaining source ==
{{Main article|FlightGear and Git}}
Throughout this article it is assumed that you have set up git clones of the various source repositories (FlightGear, SimGear, data...).
Using an organized directory (see below) will help significantly.

The commands to run are:

{{code|git clone https://git.code.sf.net/p/flightgear/simgear simgear}}

{{code|git clone https://git.code.sf.net/p/flightgear/flightgear flightgear}}

{{code|git clone https://git.code.sf.net/p/flightgear/fgdata fgdata}}

{{code|git clone https://git.code.sf.net/p/flightgear/windows-3rd-party windows-3rd-party}}

{{code|git clone -b fgfs-342-1 https://github.com/zakalawe/osg.git osg}}

After downloading these, I would suggest assembling a folder structure as below:

== Directory Tree ==
On Windows, assumptions on the directory structure are made to automate the discovery of dependencies. This recommended directory structure is described below. Clicking the links allows you to download pre-built parts. If you do not use the recommended structure you will need to enter paths by hand and some parts may not input correctly.

<tt>
: FlightGearBuild / </tt> (Main root directory) <tt>
:: fgdata / </tt> (FlightGear data files) <tt>
:: flightgear / </tt> (FlightGear sources) <tt>
:: install / </tt> (Directory where you will install the built binaries to)
::: launch.bat / </tt> (launch script if desired, see below)
:: osg / </tt> (OSG sources) <tt>
:: simgear / </tt> (SimGear sources) <tt>
:: windows-3rd-party /
:: build.bat / </tt> (build script, see below)
:: update.bat / </tt> (update script, see below)

== Building ==
=== Scripted Compilation ===
This script will allow you to build OpenSceneGraph, SimGear and FlightGear automatically.

{{collapsible script
| type = Windows batch file
| title = The <code>build.bat</code> script for configuring and compiling OSG, SG, and FG
| lang = batch
| script =
SET PATH=%PATH%;%ProgramFiles%\CMake\bin
SET QT5SDK64=C:\Qt\5.15.0\msvc2019_64
SET CMAKE_TOOLCHAIN="Visual Studio 16 2019"
SET ROOT_DIR=C:\path\to\FlightGearBuild

md osg-build
md simgear-build
md flightgear-build

cd %ROOT_DIR%\osg-build

cmake %ROOT_DIR%\osg -G %CMAKE_TOOLCHAIN% -A x64 ^
-DACTUAL_3RDPARTY_DIR=%ROOT_DIR%\windows-3rd-party/msvc140/3rdParty.x64 ^
-DCMAKE_RELWITHDEBINFO_POSTFIX:STRING= ^
-DOSG_USE_UTF8_FILENAME:BOOL=ON ^
-DWIN32_USE_MP:BOOL=ON ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install
cmake --build . --config RelWithDebInfo --target INSTALL

cd %ROOT_DIR%\simgear-build
cmake %ROOT_DIR%\simgear -G %CMAKE_TOOLCHAIN% -A x64 ^
-DOSG_FSTREAM_EXPORT_FIXED:BOOL=ON ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install
cmake --build . --config RelWithDebInfo --target INSTALL

cd %ROOT_DIR%\flightgear-build
cmake %ROOT_DIR%\flightgear -G %CMAKE_TOOLCHAIN% -A x64 ^
-DCMAKE_INSTALL_PREFIX:PATH=%ROOT_DIR%\install ^
-DCMAKE_PREFIX_PATH=%QT5SDK64% ^
-DOSG_FSTREAM_EXPORT_FIXED:BOOL=ON ^
-DENABLE_COMPOSITOR:BOOL=OFF

cmake --build . --config RelWithDebInfo --target INSTALL

pause
| show = 1
}}

Before starting to use the script, you need to edit the top few lines of the script. You will have to:

1. Set the path to your CMake installation.

2. Ensure that the path to your QT SDK is correct for your version of MSVC.

3. Ensure your toolchain version matches, e.g. "Visual Studio 16 2019" for MSVC 2019 or "Visual Studio 15 2017" for MSVC 2017.

4. Set ROOT_DIR to the FlightgearBuild folder you created (the above directory structure)

==== Post-compilation: Launching FlightGear ====
'''In the debugger:'''
Open flightgear-build/FlightGear.sln. You can then perform all your development / debugging directly in VS. You normally only need to run build.bat again, if you update SimGear or OSG.

To launch FlightGear from Visual Studio, you can follow the following steps:
The first time only:
# Make sure you set your build type to RelWithDebInfo in the top bar.
# To start with the launcher, click on the small black arrow beside Local Windows Debugger to open 'fgfs debug properties'. Switch to debugging; add {{code|--launcher}} to the 'Command Arguments'. Click Apply and then OK.
# Press the green arrow (Local Windows Debugger) to start up FlightGear.
# The first time you'll have to choose where FGDATA is -- to do this, select the 'fgdata' directory you cloned at the start.

Therafter, simply press the green arrow directly each time you want to start. If there are any local changes, it will recompile; alternatively it will start up directly. It will take a little longer to start as it loads symbols; however you also have the benefit that any segfaults will be caught allowing you to report them!

'''As a standard .exe:'''
NB these instructions overall are intended for setting up for development; there's a slightly more convoluted process for setting up for just plain flying (e.g. taking advantage of new features for aircraft development).

Essentially, Visual Studio doesn't copy in the DLLs into the /bin/ folder. It's also not ideal to manually copy in the DLLS as it can cause all sorts of issues. However, without the DLLs FlightGear won't work; therefore, you need to set the PATH so it knows where to look for them.
This launch script should work, put into your /install/bin/ folder:
{{collapsible script
| type = Windows batch file
| title = The <code>launch.bat</code> script for launching flightgear
| lang = batch
| script =
SET PATH=C:\path\to\FlightGearBuild\install\bin;C:\path\to\FlightGearBuild\windows-3rd-party\msvc140\3rdParty.x64\bin;C:\Qt\5.15.0\msvc2019_64\bin;%PATH%
fgfs.exe --launcher
| show = 1
}}

Adjust the "path\to" references to suit your own personal installation, as well as the QT5 path.

=== Updating ===
To update FlightGear, in general, just run ''git pull'' on the source directories and then re-run the build.bat script -- it will update what it needs to, relatively quickly.

=== Changing the Configuration ===
When the Simgear/FlightGear version numbers change, or you change configuration options (e.g. toggling Compositor, changing OSG versions, changing QT versions) you do have to re-configure in CMake. To do this, it's usually safest to delete the simgear-build and flightgear-build folders and re-run the build.bat script, to ensure the build is clean. There is no need to delete osg-build unless changing OSG version.

In case of problems, most of the time deleting the simgear-build and flightgear-build folders and re-running the build.bat script will be sufficient.

{{building}}
[[fr:compiler flightear avec CMake - Windows]]
[[Category:Windows specific]]
[[Category:Hackathon Materials]]

User talk:Vs

2020-11-05T12:13:56Z

HHS: note about helicopters

{{Welcome to the wiki|added-by=Johan G}}

==add some screenshots of well developed helicopters to motivate people learning==
That´s a nice idea- but I wouldn´t call the R44 well devloped- as long we speak about the one in FGAddon. It may look nice, but the fdm is far, far away from beeing realistic. The R22 instead uses realistic data and has a very plausible fdm- but may be a big challenge for new users. If you want to learn to fly a helicopter the graphics are not that important- it is the realism of the fdm, since helicopters has completly different flightdynamics as fixed-wings.

Cheers

--[[User:HHS|HHS]] ([[User talk:HHS|talk]]) 07:13, 5 November 2020 (EST)

-developer and contributor of many of your shown helicopters-

== Screenshots and categorization ==
Since you upload a lot of screenshots and I am a bit of a nitpick when it comes to organizing the screenshots I think I might be helped by asking you to first read the text below and then skim through [[Help:Categories]] and [[FlightGear wiki:FlightGear screenshot categories]].

You are using good file names and image descriptions, which is pretty much essential for the search feature to be useful.

Ideally you should only use one or maybe a few categories, and screenshot categories. Apart from that you use meaningful categories which really helps browsing the categories for meaningful screenshots.

Using a lot of categories for each screenshot will put a lot of screenshots in each category. This will make it harder to find good image for a certain purpose. To illustrate this there is still about 500 images left in <span class="plainlinks">[http://wiki.flightgear.org/index.php?title=Special:UncategorizedFiles&limit=1000&offset=0 Special:UncategorizedFiles]</span>. Before I started trying to separate the images of the wiki into categories with images the very most of them was there. Say 95% or at the time about 3000 if I recall correctly. A lot of them did not really have useful file names either, so finding a specific type of image was a lot of work. I messed up and initially only separated them into aircraft, scenery, etc, which still shows in for example [[:Category:Aircraft]] (currently nearly 400 images). Unfortunately since the upload wizard was added new screenshots are automatically categorized per content license, so probably thousands images are still rather hidden if they are not used on a wiki page.

Apart from my nitpicking about categories, go on. You are doing great!

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 06:43, 11 March 2020 (EDT)

: I will push this again. In particular "Using a lot of categories for each screenshot will put a lot of screenshots in each category." There is rarely a need to both add a category and its parent categories and their parent categories etc.
: I encourage you to click the category link at the bottom of a page and take 5-20 minutes more or less randomly browsing around on ''only'' the category pages.
: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 22:13, 31 October 2020 (EDT)

:: The old screenshot categories uploaded as part of SOTM were cleaned out/redone - I didn't know how to use talk pages at all, at first :D. Now I'm only using a category and it's sub-cateogries, at least on purpose, to use the category page as a gallery for that criteria. For example: all Screenshots at high settings, all Screenshots at high settings from different years, and all Screenshots at high settings in SOTM/non-SOTM categories. They come in useful when needing to show someone what FG looks like, for picking screenshots for draft articles, or for giving the flightsim.com editor who reached out recently a single link to look for suitable screenshots he can use. I'm not sure if there's a more elegant way to do this - it would also be nice to increase the size of the thumbnails a little bit in these categories.
:: [[User:Vs|Vs]] ([[User talk:Vs|talk]]) 05:04, 1 November 2020 (EST)

== What are overlays? ==
While categorizing uncategorized pages I found [[:Category:Screenshots of overlays]]. What are they? Are they the Canvas overlays or something scenery specific. For now I have just guessed scenery and ALS (I have been taken a break from FlightGear and have not fully caught up yet).

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 07:38, 11 March 2020 (EDT)

: Overlays are a new ALS specific effect. There's a new toggle slider in the rendering > shaders dialog. They use geometry shaders to create really small terrain detail. The grass effect uses overlays which create blades of grass that sway under downwash from rotors. The procedural texture page doesn't have the instructions for it yet. Overlays are performance intensive on older hardware. I added a bit about them in the [[anti-aliasing#Transparency_anti-aliasing|anti-aliasing]] page.
: --[[User:Vs|Vs]] ([[User talk:Vs|talk]]) 09:28, 11 March 2020 (EDT)

:: Thanks! Almost, but not quite what I expected. It will be interesting to see what people have done and will do with that feature.
:: —[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 10:29, 11 March 2020 (EDT)

== Pterosaur and Gazelle over Blue Mountains near Katoomba screenshots ==
I am very sorry, but trying to fix the naming of the two files below I have messed them up:

* [[:File:Pterosaur over Blue Mountains near Katoomba in Australia with signature blue haze (FlightGear 2020.x).jpg]]
* [[:File:Gazelle over Blue Mountains near Katoomba in Australia with signature blue haze (FlightGear 2020.x).jpg]].

The original files are still visible in the [http://wiki.flightgear.org/Special:ListFiles/Vs list of your uploads], so there must be ''some'' way to fix this.

It seems there was some trouble initially, but I have obviously made it worse trying to create a missing page and moving pages around while trying to fix the file names so they depict what they are saying.

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 08:04, 31 March 2020 (EDT)

: Oh don't worry. Thanks for trying to fix it!. The upload on some files had some sort of error, while other files in the same batch were fine.

:Error: There's a blank file page. No edit option, only create. When I click create the wiki asks for the anti-bot flightgear question. Then it says "Someone else has changed this page since you started editing it" and asks to view both and merge manually. The other edit is of course a blank page. Typing the text again takes asks the anti-bot question. The cycle repeats.

:Is there a way to not have wiki ask the anti-bot question by adding to a trusted list of users or something? I guess I can try to reupload, with the text position changed slightly to avoid a duplicate file I guess. Is there a way to filter file uploads with blank pages?

::----[[User:Vs|Vs]] ([[User talk:Vs|talk]]) 10:52, 12 April 2020 (EDT)

== Howto:Install aircraft ==
I noted [http://wiki.flightgear.org/index.php?title=Howto:Install_aircraft&curid=2581&diff=127196&oldid=127119 this edit].

Adding those screenshots really lifted that page. :-)

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 19:22, 1 September 2020 (EDT)

: :) I'm trying to do a pass for the LTS covering at least the few newcomer articles linked from the wiki front page, trying to avoid/clear up misconceptions. - [[User:Vs|Vs]] ([[User talk:Vs|talk]]) 07:15, 2 September 2020 (EDT)

== 2020 LTS Keflavik news post draft ==
While it still is a draft, I still want to put this here. Currently no links are pointing to the article and it has no category. In essence it is only "visible" from [[Special:RecentChanges|recent changes]] or a search for words in the article.

Adding links to it from related articles, in particular from the current [[:Category:Newsletter|newsletter]], and one or two categories (think ''leaf nodes'', not tag clouds) will help make this a lot easier to find without having to put in an effort to find it.

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 18:16, 28 October 2020 (EDT)

:Yep. I did link it to the ML and the forum, not sure what categories are appropriate for drafts - eventually the drafts will no longer be relevant, so they can be deleted I guess. I've added a section to the newsletter with the plan so far. [[User:Vs|Vs]] ([[User talk:Vs|talk]]) 06:56, 30 October 2020 (EDT)

Eurocopter EC135

2020-04-24T14:26:35Z

HHS: Updated issues regarding Compositor

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful Airbus H135 P3/T3 Helionix with 4-axis autopilot- already in developement by HHS.

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* not yet compatible with Compositor- needs changing the effect on the panel
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2020+ (in developement)==
<gallery mode=packed>
EC135_compositor.jpeg| EC135 showing shadows on the ground with the compositor enabled. Not yet available for all.
</gallery>
== Gallery (Flightgear 2018+)==
<gallery mode=packed>
EC135_Heer.jpeg| EC135 hovering near a forest
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
EC135_Bavaria.jpeg| EC135 Bavarian Police near Castle Neuschwanenstein, Füssen, Germany
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
EC135_Chasing_trains.jpg| EC135 chasing ICE-train near Frankfurt Airport
EC135_EHAM.jpg| Dutch police above EHAM
EC135_Rescue.jpeg| EC135 hovering above a sail ship
EC135_Sea_of_fog.jpg| Deutsche Rettungsflugwacht above a sea of fog, where the tops of the Black Forrest looking out
EC135_Wales.jpg| EC135 hovering in ground effect
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Compositor

2020-04-12T21:49:30Z

HHS: /* Notes for aircraft developers */

{{Template:Non-stable|version=2020.2|build_flags=-DENABLE_COMPOSITOR=ON|progress=100}}

{{forum|47|Effects & Shaders}}

{{infobox subsystem
|image = ALS Compositor pipeline.jpg
|name = Compositor Framework
|started = 01/2018 (Available since FlightGear 2019.2)
|description = Dynamic rendering pipeline configured via the property tree and XML
|status = Stable (merged and actively maintained)
|developers = Fernando García Liñán <ref>https://sourceforge.net/u/fgarlin/profile/</ref>
|changelog = https://sourceforge.net/u/fgarlin/profile/feed.rss
|folders =
* {{flightgear file|src/Viewer}}
* {{simgear file|simgear/scene/viewer}}
* {{fgdata file|Compositor}}
}}

The '''Compositor''' aims to bring multi-pass rendering to FlightGear. It encapsulates a rendering pipeline and exposes its parameters to a [[Property Tree]] interface. At startup, FlightGear reads the pipeline definition file for each physical viewport defined on the [[Howto:Configure camera view windows|CameraGroup settings]]. If no Compositor file is specified for a physical camera, the one given by the <code>--compositor=</code> startup command will be used. If such startup option is not used either, FlightGear will look for a valid Compositor file in $FG_ROOT/Compositor/default.xml

The Compositor introduces a new dedicated fgdata directory for new/custom rendering pipelines: {{Fgdata file|Compositor}}.

== Background ==
{{See also|Supporting multiple renderers|Howto:Canvas View Camera Element}}

First discussed in 03/2012 during the early [[Rembrandt]] days, Zan (Lauri Peltonen) came up with a set of patches demonstrating how to create an XML-configurable rendering pipeline.

Back then, this work was considered to look pretty promising <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28946515/
|title = <nowiki> Re: [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Mathias Fröhlich </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref> and at the time plans were discussed to unify this with the ongoing Rembrandt implementation (no longer maintained).

Adopting Zan's approach would have meant that efforts like [[Rembrandt]] (deferred rendering) could have been implemented without requiring C++ space modifications, i.e. purely in [[Base package]] space.

Rembrandt's developer (FredB) suggested to extend the format to avoid duplicating the stages when you have more than one viewport, i.e. specifying a pipeline as a template, with conditions like in effects, and have the current camera layout refer the pipeline that would be duplicated, resized and positioned for each declared viewport <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28944773/
|title = <nowiki> Re: [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Frederic Bouvier </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref>

Zan's original patches can still be found in his newcameras branches which allow the user to define the rendering pipeline in preferences.xml: {{gitorious source|proj=fg|repo=zans-flightgear|branch=newcameras|text=FlightGear}}, {{gitorious source|proj=fg|repo=zans-simgear|branch=newcameras|text=SimGear}}.

At that point, it didn't have everything Rembrandt's pipeline needs, but most likely could be easily enhanced to support those things.

Basically, the original version added support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28944733/
|title = <nowiki> [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Lauri Peltonen </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref>

Since the early days of Zan's groundwork, providing the (hooks) infrastructure to enable base package developers to prototype, test and develop distinct rendering pipelines without requiring C++ space modifications has been a long-standing idea, especially after the [[Canvas]] system became available in early 2012, which demonstrated how RTT-rendering buffers (FBOs) could be set up, created and manipulated procedurally (i.e. at run-time) using XML, the property tree and [[Nasal]] scripting. <ref>{{forum link|type=search|title=Zan's Rembrandt and Canvas work|keywords=zan+rembrandt+canvas}}</ref>

The new '''Compositor''' is an improved re-implementation of Zan's original work using not just XML, but also [[Property Tree|properties]] and a handful of [[Canvas]] concepts.

== Features ==

* Completely independent of other parts of the simulator, i.e. it's part of [[SimGear]] and can be used in a standalone fashion if needed, ala Canvas.
* Although independent, its aim is to be fully compatible with the current rendering framework in FG. This includes the [[Effects]] system, [[Howto:Configure camera view windows|CameraGroup]], [[Rembrandt]] and [[ALS]] (and obviously the [[Canvas]]).
* Its functionality overlaps Rembrandt: what can be done with Rembrandt can be done with the Compositor, but not vice versa.
* Fully configurable via an XML interface without compromising performance (ala Effects, using [[PropertyList XML File|PropertyList files]]).
* Flexible, expandable and compatible with modern graphics.
* It doesn't increase the hardware requirements, it expands the hardware range FG can run on. People with integrated GPUs (Intel HD etc) can run a Compositor with a single pass that renders directly to the screen like before, while people with more powerful cards can run a Compositor that implements deferred rendering, for example.
* Static branching support. Every pipeline element can be enabled/disabled at startup via a [[Conditions|<condition> block]].

== How to enable the Compositor ==

Currently, the Compositor can only be enabled at compile time via the <code>-DENABLE_COMPOSITOR=ON</code> CMake flag in FlightGear.
SimGear doesn't require any extra parameters.

On Linux, one can use <code>download_and_compile.sh --compositor</code> (see [[Scripted Compilation on Linux Debian/Ubuntu]]).

Once you have a binary with the Compositor enabled and you run it, you will be presented with the default rendering pipeline. At the time of writing, this is the low spec rendering pipeline. If you want to try the [[#ALS|ALS pipeline]], start FlightGear with the command line argument: <code>--compositor=Compositor/als</code>

If you want to enable shadows on all objects in the ALS pipeline use these options as a startup parameters (in QT GUI or in the commandline) <code>--prop:bool:/sim/rendering/als/shadows/enabled=true</code> and <code>--prop:int:/sim/rendering/als/shadows/sun-atlas-size=2048</code>. If you feel like the shadows are too low-quality (specially in the cockpit), increase the shadow resolution to 4096 or 8192 instead of 2048.

If you are having trouble with lights using an integrated GPU and the Mesa drivers under Linux, try starting FlightGear with the environment variable <tt>MESA_GL_VERSION_OVERRIDE="3.1COMPAT"</tt>

== Notes for aircraft developers ==

=== Lights ===

The Compositor introduces a new way of defining lights that is renderer agnostic, so every rendering pipeline will be able to access the lights that have been implemented like this. As of 2019/11, the only pipeline that supports dynamic lights is the ALS pipeline. It only illuminates 3d-objects. Ground and runways won`t be illuminated. The resulting light volumes can be visualized for debugging purposes by setting the property <tt>/sim/debug/show-light-volumes</tt> to true.

{|cellpadding=10|
|valign=top style="width: 20%;"|
<syntaxhighlight lang="xml">
<light>
<name>my-spotlight</name>
<type>spot</type>
<position>
<x-m>-7.7476</x-m>
<y-m>0</y-m>
<z-m>-1.7990</z-m>
</position>
<direction>
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</direction>
<ambient>
<r>0.03</r>
<g>0.03</g>
<b>0.03</b>
<a>1</a>
</ambient>
<diffuse>
<r>0.95</r>
<g>0.9</g>
<b>0.9</b>
<a>1</a>
</diffuse>
<specular>
<r>0.95</r>
<g>0.9</g>
<b>0.9</b>
<a>1</a>
</specular>
<attenuation>
<c>1.0</c>
<l>0.09</l>
<q>0.032</q>
</attenuation>
<spot-exponent>5</spot-exponent>
<spot-cutoff>40</spot-cutoff>
<range-m>50</range-m>
</light>
</syntaxhighlight>
|valign=top style="width: 80%;"|
* <tt>'''name'''</tt>. An {{tag|animation}} will be able to reference the light by this name. Most animations will work as expected (rotate, translate, spin etc).
* <tt>'''type'''</tt>. <tt>spot</tt> or <tt>point</tt>.
* <tt>'''position'''</tt>. The position of the light source in model space and in meters.
* <tt>'''direction'''</tt>. Only available in <tt>spot</tt> lights. It indicates the direction of the spotlight. This parameter can be specified in three different ways:
{| class="wikitable" style="border: 1px solid darkgray;"
! scope="col" style="width:33%;" |Direction vector
! scope="col" style="width:33%;" |Look-at point
! scope="col" style="width:33%;" |Rotation angles
|-
| style="padding: 10px" | A vector in model space that specifies the direction. Doesn't have to be normalized.
<syntaxhighlight lang="xml">
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</syntaxhighlight>
| style="padding: 10px" | The spotlight will calculate its direction by looking at this position from the light position. The point is in model space and in meters.
<syntaxhighlight lang="xml">
<lookat-x-m>-8.031</lookat-x-m>
<lookat-y-m>0</lookat-y-m>
<lookat-z-m>-2</lookat-z-m>
</syntaxhighlight>
| style="padding: 10px" | A three angle rotation in degrees that rotates the spotlight around the three axes. A 0 degree angle in all axes makes the spotlight point downwards (negative Z).
<syntaxhighlight lang="xml">
<pitch-deg>90</pitch-deg>
<roll-deg>0</roll-deg>
<heading-deg>0</heading-deg>
</syntaxhighlight>
|}
* <tt>'''ambient'''</tt>, <tt>'''diffuse'''</tt> and <tt>'''specular'''</tt>. Four-component vectors that specify the light color.
* <tt>'''attenuation'''</tt>. Three-component vector where <code><c></code> specifies the constant factor, <code><l></code> specifies the linear factor and <code><nowiki><q></nowiki></code> specifies the quadratic factor. These factors are plugged into the OpenGL light attenuation formula [[File:Spotlight_attenuation.png]] where d is the distance of the fragment to the light source. See this [http://wiki.ogre3d.org/tiki-index.php?page=-Point+Light+Attenuation table] for a list of attenuation values based on the range of the light.
* <tt>'''range-m'''</tt>. Maximum range from the light source position in meters. This value will be used by the renderers to determine if a fragment is illuminated by this source. Every fragment outside this range isn't guaranteed to be affected by the light, even if the attenuation factor isn't 0 in that particular fragment.
* <tt>'''cutoff'''</tt>. Only available in <tt>spot</tt> lights. It specifies the maximum spread angle of a light source. Only values in the range 0 90 are accepted. If the angle between the direction of the light and the direction from the light to the fragment being lighted is greater than the spot cutoff angle, it won't be lit.
* <tt>'''exponent'''</tt>. Only available in <tt>spot</tt> lights. Higher spot exponents result in a more focused light source, regardless of the spot cutoff angle.
* <tt>'''debug-color'''</tt> ('''Optional'''). Sets the color of the debug light volume. By default it's red.
|}

=== Shadows ===

The shadow mapping algorithm can be customized entirely by the rendering pipeline. This means that each one will have its own requirements when it comes to shadows. Here are some general recommendations:

* Use the <code><noshadow></code> animation to disable shadows on objects that don't need them. An example would be billboarded lights or really small cockpit elements that don't need shadows and would cause degraded performance.
* Try to mark as many cockpit objects as possible as <tt>interior</tt>.
<syntaxhighlight lang="xml">
<model>
<name>interior</name>
<usage>interior</usage>
<path>Aircraft/JA37/Models/ja37-interior.xml</path> 
</model>
</syntaxhighlight>
* Unlike in Rembrandt, polygons facing the Sun are the ones used to generate the shadow map, so single sided surfaces and non-closed objects should be rendered correctly.

== Porting and developing Effects/Shaders ==

Effects can now have different implementations depending on the Compositor pipeline being used. For example, a grass Effect implemented in the ALS pipeline might have much more detail than the one in the low-spec pipeline. Still, they both implement the "look" of grass, so they share the same Effect file (grass.eff).

The Compositor chooses which implementation of an Effect to render based on the <tt><scheme></tt> of the techniques.
<syntaxhighlight lang="xml">
<technique n="15">
<scheme>als-lighting</scheme>
[...]
</technique>
</syntaxhighlight>

In this case the technique will be chosen if the Compositor pipeline <tt><scene></tt> pass uses the <tt>als-lighting</tt> Effect scheme. Consequently, porting an Effect to a pipeline will require knowing which Effect schemes it uses and writing a technique for each one. The only exception to this is the Default (Low-Spec) pipeline, which uses techniques with no scheme.

Generally porting legacy Effects will require these steps:
* Remove <tt>/sim/rendering/shaders/skydome</tt> from the ALS techniques and add the <tt>als-lighting</tt> scheme.
* Remove Rembrandt techniques.
* Use technique numbers from 0 to 9 for the Default pipeline techniques and 10 to 19 for the ALS pipeline.
* Move the shaders to their correct directory. Now the <tt>$FG_ROOT/Shaders</tt> directory is subdivided into different folders for each pipeline. For example, shaders related to the ALS pipeline are located in <tt>$FG_ROOT/Shaders/ALS</tt>.

To add features specific to a particular pipeline (like shadows in the ALS pipeline), see each pipeline's documentation below.

=== ALS ===

==== Adding shadows ====

==== Rendering correct depth ====

The ALS pipeline uses a logarithmic depth buffer. This is accomplished by writing to <tt>gl_FragDepth</tt> in the fragment shader or by modifying <tt>gl_Position.z</tt> in the vertex shader. The second option is faster but doesn't work for polygons that intersect the near plane of the camera (e.g. terrain), so you should use it by default unless visual bugs appear.

* '''1st option'''
Add the following to the vertex shader:
<syntaxhighlight lang="glsl">
uniform float fg_Fcoef;
[...]
gl_Position = ...
gl_Position.z = (log2(max(1e-6, 1.0 + gl_Position.w)) * fg_Fcoef - 1.0) * gl_Position.w;
</syntaxhighlight>

* '''2nd option'''
Add the following to the vertex shader:
<syntaxhighlight lang="glsl">
varying float flogz;
[...]
gl_Position = ...
flogz = 1.0 + gl_Position.w;
</syntaxhighlight>
And the following to the fragment shader:
<syntaxhighlight lang="glsl">
uniform float fg_Fcoef;
varying float flogz;
[...]
gl_FragColor = ...
gl_FragDepth = log2(flogz) * fg_Fcoef * 0.5;
</syntaxhighlight>

== Pipeline technical notes ==

=== Default (Low-Spec) ===

A fixed function forward rendering pipeline mainly targeted to low spec systems. It imitates the classic forward pipeline used before multi-pass rendering was introduced by using two near/far cameras rendering directly to the screen.

[[File:Low-spec Compositor pipeline.png|thumb|Screenshot showing OSG stats of the Compositor-based low-spec rendering pipeline.]]

=== ALS ===
{{See also|ALS technical notes}}

The ALS pipeline tries to bring multipass rendering to the current ALS framework, effectively combining the best from ALS and Project Rembrandt.

==== Cascaded shadow mapping ====

The main issue with shadow mapping in FlightGear is the complexity of the scene graph. Culling times can become huge if we don't carefully select which parts of the scene graph we want to render in the shadow maps. Some possible optimizations:
* Study the minimum shadow map distance we can get without noticeable light leaking. Select an appropiate amount of cascades (more cascades = more passes over all geometry, and in general we want to keep the amount of forward passes to a minimum). We should have at least three cascades: the first just for cockpit/internal shadows, the second for the whole aircraft and the third for the rest of the scenery geometry. A fourth can be added if the transition between the second and the third is too harsh.
* Improve the culling masks (simgear/scene/util/RenderConstants.hxx). The CASTSHADOW_BIT flag is present in almost every object in the scene graph. Turning this flag off for trees, random buildings and other geometry intensive objects improves framerates by a very considerable amount. Should the user be able to select which objects cast shadows?
* Should the terrain cast shadows? The terrain is rarely steep enough to cast shadows. Apart from that, the terrain in FlightGear messes with automatic near/far computations for the shadow passes since the geometry is not tessellated enough. Also, the terrain LOD is not good enough to have decent cull times at far cascades.
* Adding a "internal only" shadow flag for aircraft developers. This allows farther shadow cascades to cull complex objects that are only visible in the nearest cascades. (Very important optimization for aircraft with complex cockpit geometry).
* Vegetation shadows will be done by the "legacy" method currently in use. Shadow mapping on vegetation is much more expensive in terms of performance and the current algorithm does the job well enough. <ref>https://forum.flightgear.org/viewtopic.php?f=47&p=357606</ref>

==== Post-processing ====

Gamma correction, night vision and other ALS filters should happen in a quad pass. The current filter_combined() should be left for post-processing that requires as much precision as possible - e.g. dithering to prevent banding). HDR is not a planned feature for now so ALS will be using rgba8 buffers for most of its features.

==== Real-time dynamic reflections ====

Rendering dynamically to a cubemap is possible. As with shadow mapping, minimizing the object count and number of forward passes is vital to get good performance in FlightGear. Rendering to six cubemap faces requires six forward passes, but we can render to a dual paraboloid map instead, reducing this number to two.

==== Transparency ====

When shadows (and multipass rendering in general) come into play, transparent objects have to be treated differently, even when we are dealing with a forward renderer. In OSG there are two ways to separate transparent surfaces:

* Using RenderBins. After a single scene cull traversal, surfaces which belong to a special RenderBin type (DepthSortedBin) are removed or moved to another camera. This is how Rembrandt does it and it is the most backwards compatible approach since RenderBins can be changed directly inside Effects.
* Using cull masks. Two separate traversals are done: one for opaque objects and another for translucent objects. This requires offering aircraft developers another way of tagging a surface as transparent. A trivial approach would be to add a new <animation> type called 'transparent', but that wouldn't be backwards compatible. Maybe we can add some kind of system where we can change cull masks inside Effects? Would that be too hacky or out of place?

== Creating a custom rendering pipeline ==

Since the Compositor is completely data-driven, new rendering pipelines can be created by writing a custom XML pipeline definition. This section tries to document most of the available parameters, but the best and most up-to-date resource is the Compositor parsing code in SimGear ({{simgear file|simgear/scene/viewer}}). See existing pipelines in {{fgdata file|Compositor}} for practical examples on how to use these parameters.

=== Buffers ===

A buffer represents a texture or, more generically, a region of GPU memory.

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>name</tt>
| {{No}}
| string
|
| Passes will be able to address the buffer by this name
|-
! scope="row"| <tt>type</tt>
| {{No}}
| <tt>1d, 2d, 2d-array, 2d-multisample, 3d, rect, cubemap</tt>
|
| Any texture type allowed by OpenGL
|-
! scope="row"| <tt>width</tt>
| {{No}}
| Any unsigned integer or <tt>screen</tt> to use the physical viewport width. The <code><property></code> tag can also be used to use a property value
|
| Texture width
|-
! scope="row"| <tt>screen-width-scale</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
| If <tt>screen</tt> was used, this controls the width scaling factor
|-
! scope="row"| <tt>height</tt>
| {{No}}
| Any unsigned integer or <tt>screen</tt> to use the physical viewport height. The <code><property></code> tag can also be used to use a property value
|
| Texture height
|-
! scope="row"| <tt>screen-height-scale</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
| If <tt>screen</tt> was used, this controls the height scaling factor
|-
! scope="row"| <tt>depth</tt>
| {{No}}
| Any unsigned integer. The <code><property></code> tag can also be used to use a property value
|
| Texture depth
|-
! scope="row"| <tt>format</tt>
| {{Yes}}
| See {{simgear file|simgear/scene/viewer/CompositorBuffer.cxx}} for the latest available values
| <tt>rgba8</tt>
| Specifies the texture format. It corresponds to the ''internalformat'', ''format'' and ''type'' arguments of the OpenGL function ''glTexImage2D''
|-
! scope="row"| <tt>min-filter, mag-filter</tt>
| {{Yes}}
| <tt>linear, linear-mipmap-linear, linear-mipmap-nearest, nearest, nearest-mipmap-linear, nearest-mipmap-nearest</tt>
| <tt>linear</tt>
| Change the minification and magnification filtering respectively
|-
! scope="row"| <tt>wrap-s, wrap-t, wrap-r</tt>
| {{Yes}}
| <tt>clamp, clamp-to-edge, clamp-to-border, repeat, mirror</tt>
| <tt>clamp-to-border</tt>
| They change the wrap mode for each coordinate
|-
! scope="row"| <tt>anisotropy</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
|
|-
! scope="row"| <tt>border-color</tt>
| {{Yes}}
| vec4
| <tt>(0.0f, 0.0f, 0.0f, 0.0f)</tt>
|
|-
! scope="row"| <tt>shadow-comparison</tt>
| {{Yes}}
| bool
| <tt>true</tt>
|
|-
! scope="row"| <tt>shadow-texture-mode</tt>
| {{Yes}}
| <tt>luminance, intensity, alpha</tt>
| <tt>luminance</tt>
|
|-
! scope="row"| <tt>shadow-compare-func</tt>
| {{Yes}}
| <tt>never, less, equal, lequal, greater, notequal, gequal, always</tt>
| <tt>lequal</tt>
|
|}

=== Passes ===

A pass wraps around an [http://public.vrac.iastate.edu/vancegroup/docs/OpenSceneGraphReferenceDocs-3.0/a00089.html osg::Camera]. Passes all have some common parameters:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>clear-color, clear-accum, clear-depth and clear-stencil</tt>
| {{Yes}}
| vec4
| black, black, <tt>1.0</tt>, <tt>0</tt> respectively
| Pass clear colors
|-
! scope="row"| <tt>clear-mask</tt>
| {{Yes}}
| <tt>color, stencil, depth, accum</tt>
| <tt>color depth</tt>
| Pass clear mask
|-
! scope="row"| <tt>effect-scheme</tt>
| {{Yes}}
| Valid effect scheme name
| None
| The pass will try to use the specified effect scheme to draw every object.
|}

Passes can render to a buffer (Render to Texture), to several buffers (Multiple Render Targets) or directly to the framebuffer. This is accomplished by the <code><attachment></code> tag. Possible parameters of an attachment are:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>buffer</tt>
| {{No}}
| Valid buffer name
|
| The name of the buffer to output to
|-
! scope="row"| <tt>component</tt>
| {{No}}
| <tt>color, color0</tt> to <tt>color15, depth, stencil, depth-stencil</tt>
|
| FBO attachment point
|-
! scope="row"| <tt>level</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Mipmap level of the texture that is attached
|-
! scope="row"| <tt>face</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Face of cube map texture or z-level of 3d texture
|-
! scope="row"| <tt>mipmap-generation</tt>
| {{Yes}}
| bool
| <tt>false</tt>
| Whether mipmap generation should be done for texture
|-
! scope="row"| <tt>multisample-samples</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Multisample anti-aliasing (MSAA) samples
|-
! scope="row"| <tt>multisample-color-samples</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Multisample anti-aliasing (MSAA) color samples
|}

Passes can also receive buffers as input and use them in their shaders. This is accomplished by the <code><binding></code> tag, which has the following parameters:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>buffer</tt>
| {{No}}
| Valid buffer name
|
| The name of the buffer to bind
|-
! scope="row"| <tt>unit</tt>
| {{No}}
| int
|
| The texture unit to place the texture on. Effects will be able to access the buffer on this texture unit
|}

There are specific pass types, each with their own set of custom parameters.

==== scene ====
Renders the scene from the point of view given by the CameraGroup.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>cull-mask</tt>
| {{Yes}}
| A 32 bit number. See {{simgear file|simgear/scene/util/RenderConstants.hxx}} to know which bits enable what
| <tt>0xffffffff</tt>
| Specifies the cull mask to be used in the underlying <tt>osg::Camera</tt>
|-
! scope="row"| <tt>z-near, z-far</tt>
| {{Yes}}
| float
| 0.0 uses the value given by the CameraGroup
| Sets a custom near and far values. Useful for implementing depth partition and limiting the depth range on cubemap passes
|-
! scope="row"| <tt>cubemap-face</tt>
| {{Yes}}
| int
| <tt>-1</tt> (don't use cubemap)
| Ignores the given view and projection matrices and uses a custom one that renders the scene as if it was seen from inside a cubemap looking towards the specified face
|-
! scope="row"| <tt>use-shadow-pass</tt>
| {{Yes}}
| string
| Empty
| Name of a shadow mapping pass. Exposes shadow mapping related uniforms to the shaders of the current pass
|}

Scene passes can also use the tag <code><clustered-shading></code> to enable clustered shading (lights). The following parameters are available:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>tile-size</tt>
| {{Yes}}
| int
| 128
| Size of each clustered shading tile
|-
! scope="row"| <tt>num-threads</tt>
| {{Yes}}
| int
| 1
| Number of threads to use during the light culling process. Keep in mind that a high thread count when there aren't many lights will worsen performance due to the thread creation overhead
|-
! scope="row"| <tt>depth-slices</tt>
| {{Yes}}
| int
| 1
| Number of slices to partition the view frustum in the Z axis. Higher numbers will cull lights more aggressively, increasing performance if there are many lights further out that don't contribute much to the overall scene's lighting
|}

==== quad ====
Renders a fullscreen quad with an optional [[Effects|effect]] applied. Useful for screen space shaders (like SSAO, Screen Space Reflections or bloom) and deferred rendering.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>geometry</tt>
| {{Yes}}
| float values for <code><x>, <y>, <width>, <height></code>
| <tt>0.0, 0.0, 1.0, 1.0</tt> respectively
| Size of the fullscreen quad inside the viewport using normalized coordinates.
|-
! scope="row"| <tt>effect</tt>
| {{Yes}}
| Valid Effect file
| None
| This Effect will be applied to the quad geometry
|}

==== shadow-map ====
Renders the scene from a light's point of view.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>light-name</tt>
| {{No}}
| Valid light name that exists in the scene graph
|
| The name of the <tt>osg::LightSource</tt> to use for this shadow map
|-
! scope="row"| <tt>near-m, far-m</tt>
| {{No}}
| Valid Effect file
|
| They specify the depth range of the shadow map
|}

== TODO ==

* Bring back distortion correction.
* Some kind of versioning system to be able to make breaking changes in the future if/when the compositor is updated in any significant way, without people having to manually update their configs.
* Rework node masks ({{simgear file|simgear/scene/util/RenderConstants.hxx}}). Each node type should have its own node mask bit, e.g. trees should only have <tt>TREE_BIT</tt> enabled, the main aircraft should only have <tt>AIRCRAFT_BIT</tt> enabled etc. This allows the Compositor cameras to properly filter scene graph nodes based on the cull mask. Shadow cameras can then choose what geometry they render dynamically.
* Automatically calculate light source attenuation based on radius and radius based on attenuation.
* Proper shader quality settings for both low-spec and ALS pipelines.
* Launcher and UI:
** [[Integrated Qt5 Launcher]]
** [[About dialog]]
** Rendering dialog
* Separate [[Developing using CMake|cmake build target (binary)]] for a "preview" binary with the [[Compositor]] enabled to get more testing/feedback and contributions from early-adopters <ref>https://sourceforge.net/p/flightgear/mailman/message/36977221/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36954518/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36679177/</ref>.

== Known Issues ==

* Setting a buffer scale factor different from 1.0 and rendering to it might not scale the splash screen correctly.
* There is some kind of moiré pattern at certain sunlight angles (specially at dusk/dawn). Shadow acne.
* Spotlights sometimes disappear at certain view angles.

== References ==
{{Appendix}}

== Related content ==
=== Wiki articles ===
* [[Canvas View Camera Element]]
* [[CompositeViewer Support]]
* [[Uniform Buffer Objects]]
* [[FlightGear CIGI Support (Common Image Generator Interface)]]

=== Forum topics ===
* {{forum link|t=36269|text=The Compositor}}
* {{forum link|t=35095|text=Clustered Forward Rendering}} (12/2018)
* {{forum link|t=33045|text=Getting started with RTT}}

[[Category:Core development projects]]

Compositor

2020-04-12T21:41:04Z

HHS: adding a limitation of current Compositor

{{Template:Non-stable|version=2020.2|build_flags=-DENABLE_COMPOSITOR=ON|progress=100}}

{{forum|47|Effects & Shaders}}

{{infobox subsystem
|image = ALS Compositor pipeline.jpg
|name = Compositor Framework
|started = 01/2018 (Available since FlightGear 2019.2)
|description = Dynamic rendering pipeline configured via the property tree and XML
|status = Stable (merged and actively maintained)
|developers = Fernando García Liñán <ref>https://sourceforge.net/u/fgarlin/profile/</ref>
|changelog = https://sourceforge.net/u/fgarlin/profile/feed.rss
|folders =
* {{flightgear file|src/Viewer}}
* {{simgear file|simgear/scene/viewer}}
* {{fgdata file|Compositor}}
}}

The '''Compositor''' aims to bring multi-pass rendering to FlightGear. It encapsulates a rendering pipeline and exposes its parameters to a [[Property Tree]] interface. At startup, FlightGear reads the pipeline definition file for each physical viewport defined on the [[Howto:Configure camera view windows|CameraGroup settings]]. If no Compositor file is specified for a physical camera, the one given by the <code>--compositor=</code> startup command will be used. If such startup option is not used either, FlightGear will look for a valid Compositor file in $FG_ROOT/Compositor/default.xml

The Compositor introduces a new dedicated fgdata directory for new/custom rendering pipelines: {{Fgdata file|Compositor}}.

== Background ==
{{See also|Supporting multiple renderers|Howto:Canvas View Camera Element}}

First discussed in 03/2012 during the early [[Rembrandt]] days, Zan (Lauri Peltonen) came up with a set of patches demonstrating how to create an XML-configurable rendering pipeline.

Back then, this work was considered to look pretty promising <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28946515/
|title = <nowiki> Re: [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Mathias Fröhlich </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref> and at the time plans were discussed to unify this with the ongoing Rembrandt implementation (no longer maintained).

Adopting Zan's approach would have meant that efforts like [[Rembrandt]] (deferred rendering) could have been implemented without requiring C++ space modifications, i.e. purely in [[Base package]] space.

Rembrandt's developer (FredB) suggested to extend the format to avoid duplicating the stages when you have more than one viewport, i.e. specifying a pipeline as a template, with conditions like in effects, and have the current camera layout refer the pipeline that would be duplicated, resized and positioned for each declared viewport <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28944773/
|title = <nowiki> Re: [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Frederic Bouvier </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref>

Zan's original patches can still be found in his newcameras branches which allow the user to define the rendering pipeline in preferences.xml: {{gitorious source|proj=fg|repo=zans-flightgear|branch=newcameras|text=FlightGear}}, {{gitorious source|proj=fg|repo=zans-simgear|branch=newcameras|text=SimGear}}.

At that point, it didn't have everything Rembrandt's pipeline needs, but most likely could be easily enhanced to support those things.

Basically, the original version added support for multiple camera passes, texture targets, texture formats, passing textures from one pass to another etc, while preserving the standard rendering line if user wants that. <ref>{{cite web
|url = https://sourceforge.net/p/flightgear/mailman/message/28944733/
|title = <nowiki> [Flightgear-devel] [Rembrandt] the plan </nowiki>
|author = <nowiki> Lauri Peltonen </nowiki>
|date = Mar 7th, 2012
|added = Mar 7th, 2012
|script_version = 0.36
}}</ref>

Since the early days of Zan's groundwork, providing the (hooks) infrastructure to enable base package developers to prototype, test and develop distinct rendering pipelines without requiring C++ space modifications has been a long-standing idea, especially after the [[Canvas]] system became available in early 2012, which demonstrated how RTT-rendering buffers (FBOs) could be set up, created and manipulated procedurally (i.e. at run-time) using XML, the property tree and [[Nasal]] scripting. <ref>{{forum link|type=search|title=Zan's Rembrandt and Canvas work|keywords=zan+rembrandt+canvas}}</ref>

The new '''Compositor''' is an improved re-implementation of Zan's original work using not just XML, but also [[Property Tree|properties]] and a handful of [[Canvas]] concepts.

== Features ==

* Completely independent of other parts of the simulator, i.e. it's part of [[SimGear]] and can be used in a standalone fashion if needed, ala Canvas.
* Although independent, its aim is to be fully compatible with the current rendering framework in FG. This includes the [[Effects]] system, [[Howto:Configure camera view windows|CameraGroup]], [[Rembrandt]] and [[ALS]] (and obviously the [[Canvas]]).
* Its functionality overlaps Rembrandt: what can be done with Rembrandt can be done with the Compositor, but not vice versa.
* Fully configurable via an XML interface without compromising performance (ala Effects, using [[PropertyList XML File|PropertyList files]]).
* Flexible, expandable and compatible with modern graphics.
* It doesn't increase the hardware requirements, it expands the hardware range FG can run on. People with integrated GPUs (Intel HD etc) can run a Compositor with a single pass that renders directly to the screen like before, while people with more powerful cards can run a Compositor that implements deferred rendering, for example.
* Static branching support. Every pipeline element can be enabled/disabled at startup via a [[Conditions|<condition> block]].

== How to enable the Compositor ==

Currently, the Compositor can only be enabled at compile time via the <code>-DENABLE_COMPOSITOR=ON</code> CMake flag in FlightGear.
SimGear doesn't require any extra parameters.

On Linux, one can use <code>download_and_compile.sh --compositor</code> (see [[Scripted Compilation on Linux Debian/Ubuntu]]).

Once you have a binary with the Compositor enabled and you run it, you will be presented with the default rendering pipeline. At the time of writing, this is the low spec rendering pipeline. If you want to try the [[#ALS|ALS pipeline]], start FlightGear with the command line argument: <code>--compositor=Compositor/als</code>

If you want to enable shadows on all objects in the ALS pipeline use these options as a startup parameters (in QT GUI or in the commandline) <code>--prop:bool:/sim/rendering/als/shadows/enabled=true</code> and <code>--prop:int:/sim/rendering/als/shadows/sun-atlas-size=2048</code>. If you feel like the shadows are too low-quality (specially in the cockpit), increase the shadow resolution to 4096 or 8192 instead of 2048.

If you are having trouble with lights using an integrated GPU and the Mesa drivers under Linux, try starting FlightGear with the environment variable <tt>MESA_GL_VERSION_OVERRIDE="3.1COMPAT"</tt>

== Notes for aircraft developers ==

=== Lights ===

The Compositor introduces a new way of defining lights that is renderer agnostic, so every rendering pipeline will be able to access the lights that have been implemented like this. As of 2019/11, the only pipeline that supports dynamic lights is the ALS pipeline. It only illuminates 3d-objects. Ground and runways won`t be lit. The resulting light volumes can be visualized for debugging purposes by setting the property <tt>/sim/debug/show-light-volumes</tt> to true.

{|cellpadding=10|
|valign=top style="width: 20%;"|
<syntaxhighlight lang="xml">
<light>
<name>my-spotlight</name>
<type>spot</type>
<position>
<x-m>-7.7476</x-m>
<y-m>0</y-m>
<z-m>-1.7990</z-m>
</position>
<direction>
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</direction>
<ambient>
<r>0.03</r>
<g>0.03</g>
<b>0.03</b>
<a>1</a>
</ambient>
<diffuse>
<r>0.95</r>
<g>0.9</g>
<b>0.9</b>
<a>1</a>
</diffuse>
<specular>
<r>0.95</r>
<g>0.9</g>
<b>0.9</b>
<a>1</a>
</specular>
<attenuation>
<c>1.0</c>
<l>0.09</l>
<q>0.032</q>
</attenuation>
<spot-exponent>5</spot-exponent>
<spot-cutoff>40</spot-cutoff>
<range-m>50</range-m>
</light>
</syntaxhighlight>
|valign=top style="width: 80%;"|
* <tt>'''name'''</tt>. An {{tag|animation}} will be able to reference the light by this name. Most animations will work as expected (rotate, translate, spin etc).
* <tt>'''type'''</tt>. <tt>spot</tt> or <tt>point</tt>.
* <tt>'''position'''</tt>. The position of the light source in model space and in meters.
* <tt>'''direction'''</tt>. Only available in <tt>spot</tt> lights. It indicates the direction of the spotlight. This parameter can be specified in three different ways:
{| class="wikitable" style="border: 1px solid darkgray;"
! scope="col" style="width:33%;" |Direction vector
! scope="col" style="width:33%;" |Look-at point
! scope="col" style="width:33%;" |Rotation angles
|-
| style="padding: 10px" | A vector in model space that specifies the direction. Doesn't have to be normalized.
<syntaxhighlight lang="xml">
<x>-1.0</x>
<y>0</y>
<z>-0.013</z>
</syntaxhighlight>
| style="padding: 10px" | The spotlight will calculate its direction by looking at this position from the light position. The point is in model space and in meters.
<syntaxhighlight lang="xml">
<lookat-x-m>-8.031</lookat-x-m>
<lookat-y-m>0</lookat-y-m>
<lookat-z-m>-2</lookat-z-m>
</syntaxhighlight>
| style="padding: 10px" | A three angle rotation in degrees that rotates the spotlight around the three axes. A 0 degree angle in all axes makes the spotlight point downwards (negative Z).
<syntaxhighlight lang="xml">
<pitch-deg>90</pitch-deg>
<roll-deg>0</roll-deg>
<heading-deg>0</heading-deg>
</syntaxhighlight>
|}
* <tt>'''ambient'''</tt>, <tt>'''diffuse'''</tt> and <tt>'''specular'''</tt>. Four-component vectors that specify the light color.
* <tt>'''attenuation'''</tt>. Three-component vector where <code><c></code> specifies the constant factor, <code><l></code> specifies the linear factor and <code><nowiki><q></nowiki></code> specifies the quadratic factor. These factors are plugged into the OpenGL light attenuation formula [[File:Spotlight_attenuation.png]] where d is the distance of the fragment to the light source. See this [http://wiki.ogre3d.org/tiki-index.php?page=-Point+Light+Attenuation table] for a list of attenuation values based on the range of the light.
* <tt>'''range-m'''</tt>. Maximum range from the light source position in meters. This value will be used by the renderers to determine if a fragment is illuminated by this source. Every fragment outside this range isn't guaranteed to be affected by the light, even if the attenuation factor isn't 0 in that particular fragment.
* <tt>'''cutoff'''</tt>. Only available in <tt>spot</tt> lights. It specifies the maximum spread angle of a light source. Only values in the range 0 90 are accepted. If the angle between the direction of the light and the direction from the light to the fragment being lighted is greater than the spot cutoff angle, it won't be lit.
* <tt>'''exponent'''</tt>. Only available in <tt>spot</tt> lights. Higher spot exponents result in a more focused light source, regardless of the spot cutoff angle.
* <tt>'''debug-color'''</tt> ('''Optional'''). Sets the color of the debug light volume. By default it's red.
|}

=== Shadows ===

The shadow mapping algorithm can be customized entirely by the rendering pipeline. This means that each one will have its own requirements when it comes to shadows. Here are some general recommendations:

* Use the <code><noshadow></code> animation to disable shadows on objects that don't need them. An example would be billboarded lights or really small cockpit elements that don't need shadows and would cause degraded performance.
* Try to mark as many cockpit objects as possible as <tt>interior</tt>.
<syntaxhighlight lang="xml">
<model>
<name>interior</name>
<usage>interior</usage>
<path>Aircraft/JA37/Models/ja37-interior.xml</path> 
</model>
</syntaxhighlight>
* Unlike in Rembrandt, polygons facing the Sun are the ones used to generate the shadow map, so single sided surfaces and non-closed objects should be rendered correctly.

== Porting and developing Effects/Shaders ==

Effects can now have different implementations depending on the Compositor pipeline being used. For example, a grass Effect implemented in the ALS pipeline might have much more detail than the one in the low-spec pipeline. Still, they both implement the "look" of grass, so they share the same Effect file (grass.eff).

The Compositor chooses which implementation of an Effect to render based on the <tt><scheme></tt> of the techniques.
<syntaxhighlight lang="xml">
<technique n="15">
<scheme>als-lighting</scheme>
[...]
</technique>
</syntaxhighlight>

In this case the technique will be chosen if the Compositor pipeline <tt><scene></tt> pass uses the <tt>als-lighting</tt> Effect scheme. Consequently, porting an Effect to a pipeline will require knowing which Effect schemes it uses and writing a technique for each one. The only exception to this is the Default (Low-Spec) pipeline, which uses techniques with no scheme.

Generally porting legacy Effects will require these steps:
* Remove <tt>/sim/rendering/shaders/skydome</tt> from the ALS techniques and add the <tt>als-lighting</tt> scheme.
* Remove Rembrandt techniques.
* Use technique numbers from 0 to 9 for the Default pipeline techniques and 10 to 19 for the ALS pipeline.
* Move the shaders to their correct directory. Now the <tt>$FG_ROOT/Shaders</tt> directory is subdivided into different folders for each pipeline. For example, shaders related to the ALS pipeline are located in <tt>$FG_ROOT/Shaders/ALS</tt>.

To add features specific to a particular pipeline (like shadows in the ALS pipeline), see each pipeline's documentation below.

=== ALS ===

==== Adding shadows ====

==== Rendering correct depth ====

The ALS pipeline uses a logarithmic depth buffer. This is accomplished by writing to <tt>gl_FragDepth</tt> in the fragment shader or by modifying <tt>gl_Position.z</tt> in the vertex shader. The second option is faster but doesn't work for polygons that intersect the near plane of the camera (e.g. terrain), so you should use it by default unless visual bugs appear.

* '''1st option'''
Add the following to the vertex shader:
<syntaxhighlight lang="glsl">
uniform float fg_Fcoef;
[...]
gl_Position = ...
gl_Position.z = (log2(max(1e-6, 1.0 + gl_Position.w)) * fg_Fcoef - 1.0) * gl_Position.w;
</syntaxhighlight>

* '''2nd option'''
Add the following to the vertex shader:
<syntaxhighlight lang="glsl">
varying float flogz;
[...]
gl_Position = ...
flogz = 1.0 + gl_Position.w;
</syntaxhighlight>
And the following to the fragment shader:
<syntaxhighlight lang="glsl">
uniform float fg_Fcoef;
varying float flogz;
[...]
gl_FragColor = ...
gl_FragDepth = log2(flogz) * fg_Fcoef * 0.5;
</syntaxhighlight>

== Pipeline technical notes ==

=== Default (Low-Spec) ===

A fixed function forward rendering pipeline mainly targeted to low spec systems. It imitates the classic forward pipeline used before multi-pass rendering was introduced by using two near/far cameras rendering directly to the screen.

[[File:Low-spec Compositor pipeline.png|thumb|Screenshot showing OSG stats of the Compositor-based low-spec rendering pipeline.]]

=== ALS ===
{{See also|ALS technical notes}}

The ALS pipeline tries to bring multipass rendering to the current ALS framework, effectively combining the best from ALS and Project Rembrandt.

==== Cascaded shadow mapping ====

The main issue with shadow mapping in FlightGear is the complexity of the scene graph. Culling times can become huge if we don't carefully select which parts of the scene graph we want to render in the shadow maps. Some possible optimizations:
* Study the minimum shadow map distance we can get without noticeable light leaking. Select an appropiate amount of cascades (more cascades = more passes over all geometry, and in general we want to keep the amount of forward passes to a minimum). We should have at least three cascades: the first just for cockpit/internal shadows, the second for the whole aircraft and the third for the rest of the scenery geometry. A fourth can be added if the transition between the second and the third is too harsh.
* Improve the culling masks (simgear/scene/util/RenderConstants.hxx). The CASTSHADOW_BIT flag is present in almost every object in the scene graph. Turning this flag off for trees, random buildings and other geometry intensive objects improves framerates by a very considerable amount. Should the user be able to select which objects cast shadows?
* Should the terrain cast shadows? The terrain is rarely steep enough to cast shadows. Apart from that, the terrain in FlightGear messes with automatic near/far computations for the shadow passes since the geometry is not tessellated enough. Also, the terrain LOD is not good enough to have decent cull times at far cascades.
* Adding a "internal only" shadow flag for aircraft developers. This allows farther shadow cascades to cull complex objects that are only visible in the nearest cascades. (Very important optimization for aircraft with complex cockpit geometry).
* Vegetation shadows will be done by the "legacy" method currently in use. Shadow mapping on vegetation is much more expensive in terms of performance and the current algorithm does the job well enough. <ref>https://forum.flightgear.org/viewtopic.php?f=47&p=357606</ref>

==== Post-processing ====

Gamma correction, night vision and other ALS filters should happen in a quad pass. The current filter_combined() should be left for post-processing that requires as much precision as possible - e.g. dithering to prevent banding). HDR is not a planned feature for now so ALS will be using rgba8 buffers for most of its features.

==== Real-time dynamic reflections ====

Rendering dynamically to a cubemap is possible. As with shadow mapping, minimizing the object count and number of forward passes is vital to get good performance in FlightGear. Rendering to six cubemap faces requires six forward passes, but we can render to a dual paraboloid map instead, reducing this number to two.

==== Transparency ====

When shadows (and multipass rendering in general) come into play, transparent objects have to be treated differently, even when we are dealing with a forward renderer. In OSG there are two ways to separate transparent surfaces:

* Using RenderBins. After a single scene cull traversal, surfaces which belong to a special RenderBin type (DepthSortedBin) are removed or moved to another camera. This is how Rembrandt does it and it is the most backwards compatible approach since RenderBins can be changed directly inside Effects.
* Using cull masks. Two separate traversals are done: one for opaque objects and another for translucent objects. This requires offering aircraft developers another way of tagging a surface as transparent. A trivial approach would be to add a new <animation> type called 'transparent', but that wouldn't be backwards compatible. Maybe we can add some kind of system where we can change cull masks inside Effects? Would that be too hacky or out of place?

== Creating a custom rendering pipeline ==

Since the Compositor is completely data-driven, new rendering pipelines can be created by writing a custom XML pipeline definition. This section tries to document most of the available parameters, but the best and most up-to-date resource is the Compositor parsing code in SimGear ({{simgear file|simgear/scene/viewer}}). See existing pipelines in {{fgdata file|Compositor}} for practical examples on how to use these parameters.

=== Buffers ===

A buffer represents a texture or, more generically, a region of GPU memory.

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>name</tt>
| {{No}}
| string
|
| Passes will be able to address the buffer by this name
|-
! scope="row"| <tt>type</tt>
| {{No}}
| <tt>1d, 2d, 2d-array, 2d-multisample, 3d, rect, cubemap</tt>
|
| Any texture type allowed by OpenGL
|-
! scope="row"| <tt>width</tt>
| {{No}}
| Any unsigned integer or <tt>screen</tt> to use the physical viewport width. The <code><property></code> tag can also be used to use a property value
|
| Texture width
|-
! scope="row"| <tt>screen-width-scale</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
| If <tt>screen</tt> was used, this controls the width scaling factor
|-
! scope="row"| <tt>height</tt>
| {{No}}
| Any unsigned integer or <tt>screen</tt> to use the physical viewport height. The <code><property></code> tag can also be used to use a property value
|
| Texture height
|-
! scope="row"| <tt>screen-height-scale</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
| If <tt>screen</tt> was used, this controls the height scaling factor
|-
! scope="row"| <tt>depth</tt>
| {{No}}
| Any unsigned integer. The <code><property></code> tag can also be used to use a property value
|
| Texture depth
|-
! scope="row"| <tt>format</tt>
| {{Yes}}
| See {{simgear file|simgear/scene/viewer/CompositorBuffer.cxx}} for the latest available values
| <tt>rgba8</tt>
| Specifies the texture format. It corresponds to the ''internalformat'', ''format'' and ''type'' arguments of the OpenGL function ''glTexImage2D''
|-
! scope="row"| <tt>min-filter, mag-filter</tt>
| {{Yes}}
| <tt>linear, linear-mipmap-linear, linear-mipmap-nearest, nearest, nearest-mipmap-linear, nearest-mipmap-nearest</tt>
| <tt>linear</tt>
| Change the minification and magnification filtering respectively
|-
! scope="row"| <tt>wrap-s, wrap-t, wrap-r</tt>
| {{Yes}}
| <tt>clamp, clamp-to-edge, clamp-to-border, repeat, mirror</tt>
| <tt>clamp-to-border</tt>
| They change the wrap mode for each coordinate
|-
! scope="row"| <tt>anisotropy</tt>
| {{Yes}}
| float
| <tt>1.0</tt>
|
|-
! scope="row"| <tt>border-color</tt>
| {{Yes}}
| vec4
| <tt>(0.0f, 0.0f, 0.0f, 0.0f)</tt>
|
|-
! scope="row"| <tt>shadow-comparison</tt>
| {{Yes}}
| bool
| <tt>true</tt>
|
|-
! scope="row"| <tt>shadow-texture-mode</tt>
| {{Yes}}
| <tt>luminance, intensity, alpha</tt>
| <tt>luminance</tt>
|
|-
! scope="row"| <tt>shadow-compare-func</tt>
| {{Yes}}
| <tt>never, less, equal, lequal, greater, notequal, gequal, always</tt>
| <tt>lequal</tt>
|
|}

=== Passes ===

A pass wraps around an [http://public.vrac.iastate.edu/vancegroup/docs/OpenSceneGraphReferenceDocs-3.0/a00089.html osg::Camera]. Passes all have some common parameters:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>clear-color, clear-accum, clear-depth and clear-stencil</tt>
| {{Yes}}
| vec4
| black, black, <tt>1.0</tt>, <tt>0</tt> respectively
| Pass clear colors
|-
! scope="row"| <tt>clear-mask</tt>
| {{Yes}}
| <tt>color, stencil, depth, accum</tt>
| <tt>color depth</tt>
| Pass clear mask
|-
! scope="row"| <tt>effect-scheme</tt>
| {{Yes}}
| Valid effect scheme name
| None
| The pass will try to use the specified effect scheme to draw every object.
|}

Passes can render to a buffer (Render to Texture), to several buffers (Multiple Render Targets) or directly to the framebuffer. This is accomplished by the <code><attachment></code> tag. Possible parameters of an attachment are:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>buffer</tt>
| {{No}}
| Valid buffer name
|
| The name of the buffer to output to
|-
! scope="row"| <tt>component</tt>
| {{No}}
| <tt>color, color0</tt> to <tt>color15, depth, stencil, depth-stencil</tt>
|
| FBO attachment point
|-
! scope="row"| <tt>level</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Mipmap level of the texture that is attached
|-
! scope="row"| <tt>face</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Face of cube map texture or z-level of 3d texture
|-
! scope="row"| <tt>mipmap-generation</tt>
| {{Yes}}
| bool
| <tt>false</tt>
| Whether mipmap generation should be done for texture
|-
! scope="row"| <tt>multisample-samples</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Multisample anti-aliasing (MSAA) samples
|-
! scope="row"| <tt>multisample-color-samples</tt>
| {{Yes}}
| int
| <tt>0</tt>
| Multisample anti-aliasing (MSAA) color samples
|}

Passes can also receive buffers as input and use them in their shaders. This is accomplished by the <code><binding></code> tag, which has the following parameters:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>buffer</tt>
| {{No}}
| Valid buffer name
|
| The name of the buffer to bind
|-
! scope="row"| <tt>unit</tt>
| {{No}}
| int
|
| The texture unit to place the texture on. Effects will be able to access the buffer on this texture unit
|}

There are specific pass types, each with their own set of custom parameters.

==== scene ====
Renders the scene from the point of view given by the CameraGroup.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>cull-mask</tt>
| {{Yes}}
| A 32 bit number. See {{simgear file|simgear/scene/util/RenderConstants.hxx}} to know which bits enable what
| <tt>0xffffffff</tt>
| Specifies the cull mask to be used in the underlying <tt>osg::Camera</tt>
|-
! scope="row"| <tt>z-near, z-far</tt>
| {{Yes}}
| float
| 0.0 uses the value given by the CameraGroup
| Sets a custom near and far values. Useful for implementing depth partition and limiting the depth range on cubemap passes
|-
! scope="row"| <tt>cubemap-face</tt>
| {{Yes}}
| int
| <tt>-1</tt> (don't use cubemap)
| Ignores the given view and projection matrices and uses a custom one that renders the scene as if it was seen from inside a cubemap looking towards the specified face
|-
! scope="row"| <tt>use-shadow-pass</tt>
| {{Yes}}
| string
| Empty
| Name of a shadow mapping pass. Exposes shadow mapping related uniforms to the shaders of the current pass
|}

Scene passes can also use the tag <code><clustered-shading></code> to enable clustered shading (lights). The following parameters are available:

{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>tile-size</tt>
| {{Yes}}
| int
| 128
| Size of each clustered shading tile
|-
! scope="row"| <tt>num-threads</tt>
| {{Yes}}
| int
| 1
| Number of threads to use during the light culling process. Keep in mind that a high thread count when there aren't many lights will worsen performance due to the thread creation overhead
|-
! scope="row"| <tt>depth-slices</tt>
| {{Yes}}
| int
| 1
| Number of slices to partition the view frustum in the Z axis. Higher numbers will cull lights more aggressively, increasing performance if there are many lights further out that don't contribute much to the overall scene's lighting
|}

==== quad ====
Renders a fullscreen quad with an optional [[Effects|effect]] applied. Useful for screen space shaders (like SSAO, Screen Space Reflections or bloom) and deferred rendering.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>geometry</tt>
| {{Yes}}
| float values for <code><x>, <y>, <width>, <height></code>
| <tt>0.0, 0.0, 1.0, 1.0</tt> respectively
| Size of the fullscreen quad inside the viewport using normalized coordinates.
|-
! scope="row"| <tt>effect</tt>
| {{Yes}}
| Valid Effect file
| None
| This Effect will be applied to the quad geometry
|}

==== shadow-map ====
Renders the scene from a light's point of view.
{| class="wikitable" style="text-align: center; font-size: 85%; width: auto; table-layout: fixed;
! scope="col" | Parameter Name
! scope="col" | Optional
! scope="col" | Value
! scope="col" | Default Value
! scope="col" | Description
|-
! scope="row"| <tt>light-name</tt>
| {{No}}
| Valid light name that exists in the scene graph
|
| The name of the <tt>osg::LightSource</tt> to use for this shadow map
|-
! scope="row"| <tt>near-m, far-m</tt>
| {{No}}
| Valid Effect file
|
| They specify the depth range of the shadow map
|}

== TODO ==

* Bring back distortion correction.
* Some kind of versioning system to be able to make breaking changes in the future if/when the compositor is updated in any significant way, without people having to manually update their configs.
* Rework node masks ({{simgear file|simgear/scene/util/RenderConstants.hxx}}). Each node type should have its own node mask bit, e.g. trees should only have <tt>TREE_BIT</tt> enabled, the main aircraft should only have <tt>AIRCRAFT_BIT</tt> enabled etc. This allows the Compositor cameras to properly filter scene graph nodes based on the cull mask. Shadow cameras can then choose what geometry they render dynamically.
* Automatically calculate light source attenuation based on radius and radius based on attenuation.
* Proper shader quality settings for both low-spec and ALS pipelines.
* Launcher and UI:
** [[Integrated Qt5 Launcher]]
** [[About dialog]]
** Rendering dialog
* Separate [[Developing using CMake|cmake build target (binary)]] for a "preview" binary with the [[Compositor]] enabled to get more testing/feedback and contributions from early-adopters <ref>https://sourceforge.net/p/flightgear/mailman/message/36977221/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36954518/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/36679177/</ref>.

== Known Issues ==

* Setting a buffer scale factor different from 1.0 and rendering to it might not scale the splash screen correctly.
* There is some kind of moiré pattern at certain sunlight angles (specially at dusk/dawn). Shadow acne.
* Spotlights sometimes disappear at certain view angles.

== References ==
{{Appendix}}

== Related content ==
=== Wiki articles ===
* [[Canvas View Camera Element]]
* [[CompositeViewer Support]]
* [[Uniform Buffer Objects]]
* [[FlightGear CIGI Support (Common Image Generator Interface)]]

=== Forum topics ===
* {{forum link|t=36269|text=The Compositor}}
* {{forum link|t=35095|text=Clustered Forward Rendering}} (12/2018)
* {{forum link|t=33045|text=Getting started with RTT}}

[[Category:Core development projects]]

Eurocopter EC135

2020-04-10T14:16:17Z

HHS:

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful Airbus H135 P3/T3 Helionix with 4-axis autopilot- already in developement by HHS.

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2020+ (in developement)==
<gallery mode=packed>
EC135_compositor.jpeg| EC135 showing shadows on the ground with the compositor enabled. Not yet available for all.
</gallery>
== Gallery (Flightgear 2018+)==
<gallery mode=packed>
EC135_Heer.jpeg| EC135 hovering near a forest
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
EC135_Bavaria.jpeg| EC135 Bavarian Police near Castle Neuschwanenstein, Füssen, Germany
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
EC135_Chasing_trains.jpg| EC135 chasing ICE-train near Frankfurt Airport
EC135_EHAM.jpg| Dutch police above EHAM
EC135_Rescue.jpeg| EC135 hovering above a sail ship
EC135_Sea_of_fog.jpg| Deutsche Rettungsflugwacht above a sea of fog, where the tops of the Black Forrest looking out
EC135_Wales.jpg| EC135 hovering in ground effect
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Eurocopter EC135

2020-04-10T14:14:19Z

HHS:

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful Airbus H135 P3/T3 Helionix with 4-axis autopilot- already in developement by HHS.

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2020+ (in developement)==
EC135_compositor.jpeg| EC135 showing shadows on the ground with the compositor enabled. Not yet available for all.
== Gallery (Flightgear 2018+)==
<gallery mode=packed>
EC135_Heer.jpeg| EC135 hovering near a forest
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
EC135_Bavaria.jpeg| EC135 Bavarian Police near Castle Neuschwanenstein, Füssen, Germany
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
EC135_Chasing_trains.jpg| EC135 chasing ICE-train near Frankfurt Airport
EC135_EHAM.jpg| Dutch police above EHAM
EC135_Rescue.jpeg| EC135 hovering above a sail ship
EC135_Sea_of_fog.jpg| Deutsche Rettungsflugwacht above a sea of fog, where the tops of the Black Forrest looking out
EC135_Wales.jpg| EC135 hovering in ground effect
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

File:EC135 compositor.jpeg

2020-04-10T14:11:50Z

HHS: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=EC 135 showing shadows on the ground. Currently only available with compositor enabled.}}
|date=2020-04-10 16:34:50
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Eurocopter]]
[[Category:Eurocopter EC135 screenshots]]

ALS technical notes

2020-04-08T21:26:53Z

HHS: /* Rotor wash */

== Quality level mapping ==
The rendering quality of ALS effects is controlled by two main sliders, the landmass effects and transition effects. The transition effects slider regulates the quality of overlaid textured, while the landmass effects slider regulates all other aspects of procedural texturing, such as pixel color post-processing (dust, snow or wet terrain effects) and apparent terrain roughness (bump and parallax mapping).

In addition, specific effects for certain terrain types (water, urban, forest, agriculture, etc.) and models in the scene can be switched on separately. In some cases, this may be needed for a consistent visual impression. For example, if a dust effect is used on the terrain, the water needs to be rendered using a separate water shader, otherwise it will appear dusty as well. Likewise, if the Rayleigh haze is used in the highest quality terrain effect, then the highest quality water effect needs to be used to see the same Rayleigh scattering effect on the water.

For technical reasons (landmass and transition control the same shader code) the settings are sometimes mutually dependent, e.g., if the transition quality is set to level 6, it won't have any effect until the landmass quality is also set to level 6.

=== Transition ===
The mapping of quality to visuals of the transition slider is as follows:

{| class="wikitable"
! Level !! Comments
|-
! scope="row" | 1
| Base texture scheme
|-
! scope="row" | 2
| Alternative hires airport keep effect
|-
! scope="row" | 3
|
* Base and overlay texture, runway effect (if landmass is above level 4)
* Secondary lights on runway and airport keep
|-
! scope="row" | 4
| Base, overlay and hires texture
|-
! scope="row" | 5
| Base, overlay, hires, detail, grain, dot and rock texture (if landmass is level 6)
|}

=== Landmass ===
{{Note|Quality levels 1 and 2 are reserved to represent fixed pipeline rendering and the "default renderer" in an eventually merged rendering GUI. However, ALS is currently switched on per checkbox and not by quality level, and so they do not have a function.}}

{| class="wikitable"
! Level !! Comments
|-
! scope="row" | 1
| ''See note above''
|-
! scope="row" | 2
| ''See note above''
|-
! scope="row" | 3
| ALS-rendered position-differential haze and light, moonlight
|-
! scope="row" | 4
|
* Procedural snow cover on terrain
* Procedural dust and vegetation effects
* Wet terrain effect with approximate reflection half vector
* Patchy fog distribution
|-
! scope="row" | 5
| Noise bump-mapping and parallax mapping of terrain
|-
! scope="row" | 6
| (''Requires transition effect level 6'')
* Wet terrain effect with correct reflection half vector
* Hires bump mapping and snow patchiness
* Variable upper haze layer surface
* Rayleigh haze
* Secondary lights on all terrain types
* Slope line and strata effects
|}

== ALS secondary lights ==
The ALS framework supports a generic implementation of landing lights and a searchlight which are based on a framerate-friendly computation in screen coordinates, i.e., the lights project correctly ''only if the light is close to the viewer'' (typically, that would be from cockpit view). In other words, this is not a full (and rather expensive) computation of light volumes as in Rembrandt, but a much faster test of illuminated screen areas.

[[File:Landing light03.jpg|400px|Cessna 172P using generic ALS landing lights]]

Two landing lights and a searchlight are supported. The landing lights have a fixed position with respect to the aircraft axis (technically, with respect to the default view axis as defined in the respective view), whereas the searchlight follows any offset of the view axis in view mode, i.e., when using the mouse to look around, the searchlight will follow the motion, the landing lights will not. The lights require ALS to run above basic quality level and work on runway and airport keep above transition setting 3 and everywhere else only at highest quality setting. All lights are controlled via properties in <code>/sim/rendering/als-secondary-lights/</code>.

The names of the properties should be self-explanatory, if for instance if <code>/sim/rendering/als-secondary-lights/use-searchlight</code> is set to true, then the searchlight (which always follows the current view axis) is used.

The properties <code>/sim/rendering/als-secondary-lights/landing-light1-offset-deg</code> and <code>/sim/rendering/als-secondary-lights/landing-light2-offset-deg</code> allow to specify angular offsets for the landing light which are then not centered on the view axis. This can be used to simulate one or two landing lights set in the wings.

[[File:Offsetv2.jpg|400px|Secondary lights vertical offset demo]]

A third offset <code>/sim/rendering/als-secondary-lights/landing-light3-offset-deg</code> is available which allows for a vertical offset. This is especially useful for tail dagger aircraft.

[[File:Offsetv.jpg|400px|Secondary lights vertical offset settings]]

The lights can be switched on and off from the [[Property Browser]] for any aircraft without any modifications to the aircraft definition. Implementing them correctly aircraft side thus just involves linking the landing light switches to the ALS control properties and setting the correct angular offsets. Additionally, it is recommended to switch the lights off unless in a cockpit view, as they don't project correctly for any external view.

Range, color, light cone opening angle or intensity of the lights can currently not be configured, and there are no plans to support such a feature in the near future.

All three lights will illuminate fog (if dense enough) and precipitation.

[[File:Als secondary light fog.jpg|400px|ALS generic lights illuminating dense fog]]

== ALS specific features of the model effect ==

In addition to the features supported by the model-combined-deferred effect in all three renderers (normal, light, specular, environment reflection and dirt map), ALS also supports a couple of unique effects (which, if configured, will not have any effect in other renderers.

=== The grain texture ===

ALS supports a grain texture for models. This is a semi-transparent overlay texture that works just as [[Procedural Texturing#The grain texture|its equivalent for terrain texturing]] and provides the option of generating centimeter-scale details such as rust or discoloration on a surface without having to use huge textures. An example of a surface rendered with grain texture is the image of the USS Vinson flightdeck below:

[[File:Grain rain01.jpg|700px|Grain and rain effects on Vinson's flightdeck]]

This is done using the following effect declaration inheriting from '''model-combined-deferred.eff''' as
<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>

<PropertyList>

<name>flightdeck</name>
<inherits-from>Effects/model-combined-deferred</inherits-from>
<parameters>
<grain-texture-enabled type="int">2</grain-texture-enabled>
<grain-magnification type="float">0.1</grain-magnification>
<rain-enabled type="int">2</rain-enabled>
<texture n="7">
<image>Models/Geometry/Nimitz/rust_texture.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>repeat</wrap-s>
<wrap-t>repeat</wrap-t>
<internal-format>normalized</internal-format>
</texture>
</parameters>

</PropertyList>
</syntaxhighlight>

The grain texture has the number 7 and needs to be enabled by
<syntaxhighlight lang="xml">
<grain-texture-enabled type="int">2</grain-texture-enabled>
</syntaxhighlight>

If the value is set to 1, the grain texture uses the uv-mapping of the underlying surface. If that is very irregular (as in the case of the Vinson flightdeck), alternatively the grain can be mapped in xy-model coordinates if the parameter is set to 2, the uv-mapping of the base texture layer is then discarded.

The resolution of the grain texture with respect to the base coordinate layer is specified by
<syntaxhighlight lang="xml">
<grain-magnification type="float">0.1</grain-magnification>
</syntaxhighlight>

If the number is less than 0, the grain resolution is lower than the base layer. If the parameter is greater than 0, it is higher (note that in the above case, the grain is mapped to (xy) rather than (uv), hence the base size is 1 m, so the grain texture is mapped on a 10x10 m patch on the flightdeck, for which a 1024x1024 pixel texture provides ~1 cm sized details).

=== The rain effect ===

Any number greater than 0 passed to
<syntaxhighlight lang="xml">
<rain-enabled type="int">2</rain-enabled>
</syntaxhighlight>

enables the splash effect of raindrops on the surface if it points upward. The surface does not have to be flat for this to work, the effect checks for the surface normal automatically, see the rain enabled for the Citation Bravo.

Thorsten noted about rain splashes: "Works fine here - runway needs to get really wet though before you see them (put the environment slider to max to achieve this quickly, it will take some waiting with just rain on)."

[[File:Grain rain02.jpg|700px|Rain effect on the Citation Bravo]]

=== Glossy surfaces ===

To better treat the environment reflections on a glossy surface, ALS contains two options not present in the other renderers.

<syntaxhighlight lang="xml">
<reflection-type type="int">1</reflection-type>
</syntaxhighlight>

This parameter can currently be set to 1 or 2 and regulates how the color of the environment reflection is merged with the color of the glossy surface. If set to 1, the shader uses a color mixing as in the other two renderers, if set to 2 it uses a technique called 'grain merge' which gives different weight to the color channels. The reason for introducing type 2 was a grey tint which changed the reflected color in a unrealistic way. With FlightGear 2017.2.0 this will be fixed and type set to 2 should be obsolete then.

<syntaxhighlight lang="xml">
<reflection-fresnel-factor type="float">0.0</reflection-fresnel-factor>
</syntaxhighlight>

This parameter regulates how strong the Fresnel term of a glossy surface is. Many smooth surfaces reflect much more under shallow angles such that an environment reflection is not very prominent when looking under 90 degrees but dominates the visuals when looking under a grazing angle. The parameter sets the relative strength of a Fresnel reflection with respect to the basic reflection definition which is assumed to hold for vertical viewing (i.e. setting the parameter to 0.8 gives you extra glossiness under shallow angles).

The following comparison shows the default color mixing (upper left) for a reflecting white livery and for grain merge (upper right). In addition, note the enhanced Fresnel reflectivity at the tail and the cowling on the pictures. The lower row shows (left) full reflection with default color mixing and (right) for grain merge. Default color mixing is more physically correct, while grain merge is less correct but preserves white color much better.

[[File:Reflect Model default2.jpg|400px|Effect of color mixing in a reflection]]
[[File:Reflect Grain merge2.jpg|400px|Effect of grain merge in reflection]]

[[File:Reflect Model Default Full.jpg|400px|Full reflection with default ]]
[[File:Reflect Grain Merge Full.jpg|400px|Full reflection with grain merge]]

== The exhaust flame effect ==

Rendering proper flames of e.g. afterburners or rocket thrusters with diffuse edges is notoriously difficult - all solutions based on textured models tend to have unnaturally sharp edges. Usually the particle system is used in such cases, however at high velocities this has other issues - particles become easily separated, making flames look disrupted and detached from the exhaust.

ALS includes a dedicated procedural effect in which the flame is rendered by numerically integrating a 3-dim distribution of glowing emitters inside a bounding box (i.e. re-creates the process by which a real flame would be seen). The function which determines the emitter distribution is partially user-controlled so that a wide range of shapes can be generated.

To use the effect, first the bounding box has to be defined. Note that the shape and alignment of the bounding box needs to be standardized for the effect to work, i.e. you need to use either the default bounding box under Aircraft/Generic/Effects/Thruster/ or make a custom one which fits inside the default box at the same location in model coordinates.

To change position, size and orientation of the bounding box to match with the airplane model, translate, scale and rotate animations or model offsets can later be used.

=== Model definition for effect ===
This is a standard XML model definition that needs to specify the geometry, all animations and the effect to use. For the geometry you can use the standard ''Aircraft/Generic/Effects/Thruster/thrust_flame.ac'' or make your own. The F-15 uses a slightly different 3D model to allow for the nozzles. The 3D model needs to be big enough to contain the flame, bearing in mind that the flame is drawn as a cylinder.

<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>

<path>Aircraft/Generic/Effects/Thruster/thrust_flame.ac</path>
<nopreview/>
<animation>
<type>scale</type>
<property alias="/params/augmentation-alight"/>
<x-min>0.2</x-min>
<y-min>0.3</y-min>
<z-min>0.3</z-min>
<y-max>1</y-max>
<z-max>1</z-max>
<x-factor>0.472</x-factor>
<y-factor>0.6</y-factor>
<z-factor>0.6</z-factor>
</animation>

<animation>
<type>select</type>
<object-name>Bounding_box</object-name>
<condition>
<greater-than>
<property alias="/params/augmentation-ignition"/>
<value>0.8</value>
</greater-than>
</condition>
</animation>

<effect>
<inherits-from>Aircraft/MyAircraft/Models/Effects/my-flame</inherits-from>
<object-name>Bounding_box</object-name>
</effect>

</PropertyList>
</syntaxhighlight>

=== Effect definition for model ===
To define the effect to apply to the model (as referenced in the ''effect'' section in the model XML) you need to create ''my-flame.eff'' as below. The ''.eff'' file defines the parameters that are passed into the shader and it is these that control how the flame looks.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>AB-flame</name>
<inherits-from>Effects/thrust-flame</inherits-from>
<parameters>
<base_flame_b type="float">0.8</base_flame_b>
<base_flame_density type="float">0.6</base_flame_density>
<base_flame_g type="float">0.9</base_flame_g>
<base_flame_r type="float">0.9</base_flame_r>
<deflection_coeff type="float">0</deflection_coeff>
<flame_color_high_b type="float">0.8</flame_color_high_b>
<flame_color_high_g type="float">0.85</flame_color_high_g>
<flame_color_high_r type="float">0.9</flame_color_high_r>
<flame_color_low_b type="float">0.07</flame_color_low_b>
<flame_color_low_g type="float">0.15</flame_color_low_g>
<flame_color_low_r type="float">0.35</flame_color_low_r>
<flame_radius_fraction type="float">0.8</flame_radius_fraction>
<noise_scale type="float">0.3</noise_scale>
<noise_strength type="float">0.2</noise_strength>
<thrust_collimation type="float">0.1</thrust_collimation>
<thrust_density type="float">0.7</thrust_density>
<use_noise type="int">1</use_noise>
<use_shocks type="int">1</use_shocks>
</parameters>
</PropertyList>
</syntaxhighlight>

There is also a detailed version (utilizing 3d noise and a higher sampling resolution) available. This has to be explicitly requested in a derived effect by overriding the default shader choice with the detailed version, i.e. bu inserting

<syntaxhighlight lang="xml">
<technique n="4">
<pass>
<program>
<fragment-shader n="0">Shaders/thrustflame-ALS-detailed.frag</fragment-shader>
</program>
</pass>
</technique>
</syntaxhighlight>

below the parameter section.

{{Note|The detailed shader uses four times as much performance at least - only use it if you really need it!}}

=== F-15 Afterburner example image ===
The F-15 afterburner flame shown below (at different ambient lighting based on time) uses the parameters above. The main parameters of importance, and therefore to tune, for an aircraft jet engine are the colors, the two densities, the flame radius fraction. The base density is at the start of the flame and this. The F-15 overlays a billboarded image to achieve the diamonds that are interleaved with the ALS drawn flame.

[[File:F-15 afterburner using ALS Thrust Effect.jpg|700px|This shows the F-15 afterburner at different ambient light.]]

The meaning of the parameters are as follows:

<syntaxhighlight lang="xml">
<use_shocks type="int">1</use_shocks>
<use_noise type="int">1</use_noise>
</syntaxhighlight>

<syntaxhighlight lang="xml" inline><use_shocks></syntaxhighlight> and <syntaxhighlight lang="xml" inline><use_noise></syntaxhighlight> are the parameters that control the random noise and the shock diamonds. Both are modestly computationally expensive, i.e. if these effects are not required it is better to switch them off by setting these values to zero.

<syntaxhighlight lang="xml">
<flame_color_low_r type="float">0.95</flame_color_low_r>
<flame_color_high_r type="float">1.0</flame_color_high_r>
<base_flame_r type="float">0.8</base_flame_r>
</syntaxhighlight>

(same for the (g,b) channels) set the color. base_flame refers to the part of the flame which is directly attached to the thruster and usually brightest. flame_color_high refers to the high density part of the flame, flame_color_low refers to the low density parts of the flame. (rgb) values always need to be [0:1]

<syntaxhighlight lang="xml">
<thrust_density type="float">1.0</thrust_density>
<base_flame_density type="float">0.1</base_flame_density>
</syntaxhighlight>

determine the overall emitter density in the flame and in the base directly at the thruster respectively. There's no formal upper limit for the parameters, but a flame with density 1 already appears fairly opaque.

<syntaxhighlight lang="xml">
<flame_radius_fraction type="float">0.8</flame_radius_fraction>
</syntaxhighlight>

governs how much of the bounding box the flame radius at the exhaust nozzle fills. If the flame needs to expand (as for the plume of a thruster operating in vacuum) or needs to bend (as for a flame deflected by the airstream) this parameter needs to be small, if the flame is essentially cylindrical the paramater can be chosen close to 1 to minimize clipping errors. Note that this determines the size of the flame relative to the bounding box - the overall size of the flame should be adjusted by using a scale animation on the bounding box

<syntaxhighlight lang="xml">
<noise_strength type="float">0.2</noise_strength>
<noise_scale type="float">0.3</noise_scale>
</syntaxhighlight>

determined how turbulent the flame looks. noise_strength [0:1] determines how prominently the noise influences the flame and noise_scale (in meters relative to the original bounding box) determines how large the visible patches of turbulence are (given that the original bounding box is not larger than 5 m in the longest direction, the parameter should probably kept between 0.1 and 5).

<syntaxhighlight lang="xml">
<shock_frequency>1.0</shock_frequency>
</syntaxhighlight>

influences at what distance shock diamonds appear in the flame. Useful values are perhaps between 0.2 and 5.

<syntaxhighlight lang="xml">
<thrust_collimation type="float">0.1</thrust_collimation>
</syntaxhighlight>

should take a value of between 0 and 1 and determines how collimated the flame is. For values > 0, the flame is widened - note that this requires a sufficiently small flame radius fraction to avoid clipping errors. For widened flames, the density is automatically lowered and shock diamonds are removed.

<syntaxhighlight lang="xml">
<deflection_coeff type="float">0.</deflection_coeff>
</syntaxhighlight>

should be somewhere between 0 and 0.06 and gives a lateral deflection (such as by an airstream) to the flame. Note that this re-positions the origin of the flame in the bounding box to better utilize the bounding box volume, i.e. if you need a dynamical deflection, you also need a translate animation for the bounding box.

Any of those parameters can be adjusted runtime by replacing the value with <syntaxhighlight lang="xml" inline><use>/my-property</use></syntaxhighlight>. Dependent on how <code>/my-property</code> is created it might be tied though (in particular JSBSim-computed properties are) in which case it is not picked up by the effect framework - you need to copy it via property rule to an untied property then. This allows to render dynamical changes of the flame.

For instance the [[SpaceShuttle - Project Overview|Space Shuttle]] main engines use

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

<PropertyList>
<name>ssme-flame</name>
<inherits-from>Effects/thrust-flame</inherits-from>
<parameters>
<flame_color_low_r>0.9</flame_color_low_r>
<flame_color_low_g>0.7</flame_color_low_g>
<flame_color_low_b>0.5</flame_color_low_b>
<flame_color_high_r>0.7</flame_color_high_r>
<flame_color_high_g>0.7</flame_color_high_g>
<flame_color_high_b>1.0</flame_color_high_b>
<base_flame_r type="float">0.8</base_flame_r>
<base_flame_g type="float">1.0</base_flame_g>
<base_flame_b type="float">1.0</base_flame_b>
<use_shocks type="int">1</use_shocks>
<use_noise type="int">1</use_noise>
<thrust_collimation><use>/sim/systems/various/ssme-flame-collimation</use></thrust_collimation>
<thrust_density><use>/sim/systems/various/ssme-flame-density</use></thrust_density>
<base_flame_density type="float">1.0</base_flame_density>
<shock_frequency>1.0</shock_frequency>
<noise_strength>0.3</noise_strength>
<noise_scale>0.1</noise_scale>
</parameters>
</PropertyList>
</syntaxhighlight>

to simulate the change of flame geometry in the thin upper atmosphere during ascent:

[[File:Shuttle flame05.jpg|400px|Space Shuttle main engine flames during early ascent]]
[[File:Shuttle flame06.jpg|400px|Space Shuttle main engine flames during late ascent]]

Using the deflection parameter, the curved SRB separation motor flames are rendered using

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

<PropertyList>
<name>SRBsep-flame</name>
<inherits-from>Effects/thrust-flame</inherits-from>
<parameters>
<flame_color_low_r type="float">0.95</flame_color_low_r>
<flame_color_low_g type="float">0.55</flame_color_low_g>
<flame_color_low_b type="float">0.1</flame_color_low_b>
<flame_color_high_r type="float">1.0</flame_color_high_r>
<flame_color_high_g type="float">1.0</flame_color_high_g>
<flame_color_high_b type="float">1.0</flame_color_high_b>
<use_shocks type="int">0</use_shocks>
<use_noise type="int">1</use_noise>
<thrust_collimation type="float">0.4</thrust_collimation>
<thrust_density type="float">1.0</thrust_density>
<base_flame_density type="float">0.0</base_flame_density>
<noise_strength type="float">0.7</noise_strength>
<noise_scale type="float">0.4</noise_scale>
<deflection_coeff type="float">-0.06</deflection_coeff>
<flame_radius_fraction type="float">0.1</flame_radius_fraction>
</parameters>
</PropertyList>
</syntaxhighlight>

[[File:Flame_sep.jpg|700px|Space Shuttle SRB separation motor flames]]

Application of the effect is not limited to flames, it can also do heat blur (think a very transparent, high-noise dark emitter distribution) or vapour trails and other smoke.

By itself, the effect does however not compute ambient and diffuse light channels, i.e. for non-emissive distributions lighting is the responsibility of the user. One quick way of obtaining a correct fading of color with light in the scene is to create an untied property based on

<code>/rendering/scene/diffuse/red</code>

and used this to scale all color values.

{{note|Do not use the full (rgb) information in the property tree for ALS, it will produce pronounced color mismatches with the rest of the scene as ALS determines light inside the shader and never uses the properties.}}

== Rotor wash ==

ALS provides an interface to render rotor wash on various terrain types - currently this is implemented for the volumetric grass as well as procedural water. This interface needs to be written aircraft-side for the effect to be rendered.

[[File:Rotor wash.jpg|600px|Rotor wash rendered on volumetric grass]]
[[File:EC135 Heer.jpeg|600px|Rotor wash rendered on volumetric grass]]
[[File:EC135 Rescue.jpeg|600px|Rotor wash rendered on water]]

Aircraft maintainers need to set three parameters in <b>/environment/aircraft-effects/</b>.

The position of the downwash column needs to be specified in <i>eye-relative</i> coordinates by setting <b>/environment/aircraft-effects/wash-x</b> and <b>/environment/aircraft-effects/wash-y</b>. If these are zero, the air column is assumed to be right underneath the eye point, any non-zero values displace the center northward or eastward from the eye point. To work in external views, the displacement needs to be computed by e.g. a Nasal script or property rules, the same is true if the rotor is not close to the eye point.

The strength of the downwash column <i>on the ground</i> is set by <b>/environment/aircraft-effects/wash-strength</b>. The parameter influences both the radius in which the effect is visible as well as the overall strength (up to a maximum). Aircraft maintainers need to adjust strength based on parameters like altitude AGL, rotor RPM, rotor radius and whatever else might influence the downwash.

== Chute animation effect ==

The chute animation effect is designed to provide a natural appearance of the deformation and the fluttering motion of a piece of cloth under changing stress.

[[File:Chute seq01.jpg|400px|Drag chute separation sequence 1]] [[File:Chute seq03.jpg|400px|Drag chute separation sequence 2]]

=== Coordinate system ===

The shader assumes that the 3d mesh of the chute is oriented in a particular coordinate system. The z-axis (upward) should extend from the zero point where the various ropes come together to the canopy above through the center of the model. The canopy of the chute should therefore roughly be in the xy plane.

To position the chute correctly with the aircraft, you then need to use appropriate offsets and rotations when loading.

=== Effect definition for model ===

To define the effect to apply to the model (as referenced in the ''effect'' section in the model XML) you need to create ''mychute.eff'' as below. The ''.eff'' file defines the parameters that are passed into the shader and it is these that control the behavior.

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>mychute</name>
<inherits-from>Effects/chute</inherits-from>
<parameters>
<chute_force><use>Aircraft/MyAircraft/myforce</use></chute_force>
<chute_projection_z>0.0</chute_projection_z>
<chute_fold>0.0</chute_fold>
<chute_bend>0.0</chute_bend>
</parameters>
</PropertyList>
</syntaxhighlight>

The meaning of these parameters is as follows:

<syntaxhighlight lang="xml">
<chute_projection_z>0.0</chute_projection_z>
</syntaxhighlight>

This is the distance of the branching point of the various lines leading to the canopy (at model coordinate zero) to the edge of the canopy. All transformations affecting the shape of the canopy (in particular the collapse of the canopy if the force is gone) will be applied with respect to this reference plane.

<syntaxhighlight lang="xml">
<chute_force><use>Aircraft/MyAircraft/myforce</use></chute_force>
</syntaxhighlight>

This is a normalized force applied to the canopy. The chute should be modeled with a deformation corresponding to a force parameter of 1 - any higher value will narrow the chute's radius, deepen the chute's deformation along the z-axis and increase the motion, any lower value will widen chute radius (compare screenshots above) and lessen its depth and slow down motion. The normal parameter range should be from [0:2], any higher or lower may look odd.

<syntaxhighlight lang="xml">
<chute_fold>0.0</chute_fold>
<chute_bend>0.0</chute_bend>
</syntaxhighlight>

These are deformation modes used to animate a chute after jettison when it is no longer pulled into shape and can flutter through the air. The first one [0:1] is a general collapse into the projection plane with random deformations around, the second one [-1:1] is a gross bending mode of the projection plane itself. Before jettison, these parameters should default to 0.

=== Jettison animation ===

A complete animated jettison sequence is quite complex and would usually require a Nasal sequence taking the chute through a deceleration trajectory (utilizing translation and rotation animations), bending ad folding oscillations and finally some unfolding as it sinks through the air. The Space Shuttle chute uses the following control loop for 10 seconds of jettison dynamics:

<syntaxhighlight lang="nasal">
var drag_chute_jettison_animation = func (time) {

var dt = getprop("/sim/time/delta-sec");
time = time + dt;

# horizontal motion

var x = 0.0;

if (time > 2.0)
{x = -16.0 + 20.0 * time;}
else
{x = 2.0 * time + 5.0 * time * time;}

setprop("/controls/shuttle/drag-chute-dist",x);

# vertical motion

var y = 0.0;
if (time > 5.0)
{
y = -2.5 + 0.6 * (time-5.0) * (time-5.0);
}
else
{
y = -0.2 * time;
}
if (y > 12.5) {y=12.5;}

setprop("/controls/shuttle/drag-chute-down",y);

# fold

var f = 0.5 * time;
if (f> 1.0) {f = 1.0;}
if (time > 9.5)
{f = 0.25 + 1.5 + (time-9.5);}
if (time > 6.0)
{
f = f -0.3* (time-7.0);
if (f<0.1) {f=0.1;}
}
setprop("/controls/shuttle/drag-chute-fold", f);

# rotate

var r = (time - 2.0) * 18.0;
if (r>90.0) {r=90.0;}
if (r<0.0) {r=0.0;}
setprop("/controls/shuttle/drag-chute-slant", r);

# bend

var b = 0;
if (time > 7.5)
{b = 0;}
else if (time >6.0)
{b = 0.75 - 0.5 * (time - 6.0);}
else if (time > 4.5)
{b = (time - 4.5) * 0.5;}
else {b=0;}

setprop("/controls/shuttle/drag-chute-bend", b);

if (time > 10.0)
{
print("Exiting...");
settimer (func { setprop("/controls/shuttle/drag-chute-deploy-timer", 0); }, 0.5);
return;
}

setprop("/test/timer", time);

settimer( func{ drag_chute_jettison_animation (time); }, 0);

}
</syntaxhighlight>

== ALS glass effect ==

As of FlightGear version 3.5, ALS supports a glass effect with dynamic response to the environment which can render, for instance, the splashes of raindrops on the canopy, frost or fogging.

[[File:Glass01.jpg|400px|Frost effect]]
[[File:Glass07.jpg|400px|Raindrop splashes]]

The base effect properties are controlled via inheritance and the environment response run-time via properties residing in <b>/environment/aircraft-effects</b>. Derived effects should inherit from <b>Effects/glass</b>. Any surface using the glass effect will automatically register itself as transparent for use in [[Project Rembrandt| Rembrandt]].

The glass effect is primarily intended for interior views. In particular, no external fog or haze is rendered for the glass, i.e. if the effect is used in an outside view, it is the responsibility of the aircraft modeler to take care (e.g. with LOD settings or range animations) that no problems in bad visibility occur.

=== Why a separate effect for glass seen from inside? ===

Basically because the two situations are rather different. Slight dirt on the glass against the background of the sky from inside is rather prominent, against the background of the cockpit seen from outside it is not. Visuals from inside are dominated by Mie forward scattering of light, leading to a bright glare effect when looking at dirt, frost, fog or scratches close to the sun. From outside, reflected light rather than transmitted light is dominant. The reflection of any external object on the outside of the glass changes as the aircraft moves, this is not the case for the reflection of the cockpit in the glass seen from the inside.

The viewing situation is also different. From the inside, we usually do not focus the eyes on the plane of the glass but look through it, from the outside the focus of the eyes is often close to the glass surface. For something half a meter before the eye, we also need to apply a lot more resolution and details than for an object typically seen from 10+ meters from the outside.

Add to this that atmospheric fog is never relevant for glass seen from inside but for glass seen from outside, and it suddenly makes sense to use a different effect.

The recommended effect for glass surfaces seen from outside is model-combined-transparent.eff.

=== Rain ===
Rain splashes will render automatically when the weather system reports rain via environment/rain-norm. In addition, the user can set rain splashes to render via <code>environment/aircraft-effects/ground-splash-norm</code> (this is intended to allow splashes to be rendered e.g., for water landings of aircraft equipped with floats).

By default, the rain splashes impact from above (more precisely the +z direction in model coordinates). This may be inadequate if the aircraft is moving. However, the shader can not know what the airstream at the glass will be, so the impact vector of rain splashes has to be modeled aircraft-side and set via <code>environment/aircraft-effects/splash-vector-x</code> (<code>splash-vector-y</code>, <code>splash-vector-z</code>). These are likewise in model coordinates.

As long as the length of the splash vector is less than 1, just the impact angle will change, as the length of the vector increases to 2, droplets will also be visibly moving. This allows fine control of the visuals dependent on any number of factors desired. A simple Nasal snipped varying the splash vector with airspeed for the F-16 is given below (but ''do not mindlessly copy and expect to work for any aircraft — it won't!''). This example is for normals pointing outwards, if the normals are pointing inwards the vector needs to be inverted.

<syntaxhighlight lang="nasal">
var splash_vec_loop = func(){
var airspeed = getprop("/velocities/airspeed-kt");

# f16
var airspeed_max = 120;

if (airspeed > airspeed_max) {
airspeed = airspeed_max;
}

airspeed = math.sqrt(airspeed / airspeed_max);

var splash_x = -0.1 - 2 * airspeed;
var splash_y = 0.0;
var splash_z = 1.0 - 1.35 * airspeed;

setprop("/environment/aircraft-effects/splash-vector-x", splash_x);
setprop("/environment/aircraft-effects/splash-vector-y", splash_y);
setprop("/environment/aircraft-effects/splash-vector-z", splash_z);

settimer(func(){
splash_vec_loop();
}, 1);
}
</syntaxhighlight>

Note the timing constant of the loop — running the update per-frame leads to a spurious movement of the coordinate system in which rain is rendered and spoils the effect.

Another method when using JSBSIM would be to use a combination of FCS Functions and Filters.

<syntaxhighlight lang="xml">
<system name="c172p-glass-effects">
<channel name="rain">
<fcs_function name="glass-effects/splashx">
<function>
<difference>
<value>-0.1</value>
<product>
<value>2.0</value>
<sqrt>
<quotient>
<min>
<property>/velocities/airspeed-kt</property>
<value>40</value>
</min>
<value>40</value>
</quotient>
</sqrt>
</product>
</difference>
</function>
</fcs_function>
<fcs_function name="glass-effects/splashz">
<function>
<difference>
<value>1.0</value>
<product>
<value>1.35</value>
<sqrt>
<quotient>
<min>
<property>/velocities/airspeed-kt</property>
<value>40</value>
</min>
<value>40</value>
</quotient>
</sqrt>
</product>
</difference>
</function>
</fcs_function>
</channel>
</system>
</syntaxhighlight>

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="UTF-8"?>
<PropertyList>
<filter>
<name>splashX</name>
<type>gain</type>
<input>
<property>/fdm/jsbsim/glass-effects/splashx</property>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-x</property>
</output>
</filter>
<filter>
<name>splashY</name>
<type>gain</type>
<input>
<value>0.0</value>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-y</property>
</output>
</filter>
<filter>
<name>splashZ</name>
<type>gain</type>
<input>
<property>/fdm/jsbsim/glass-effects/splashz</property>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-z</property>
</output>
</filter>
</PropertyList>
</syntaxhighlight>

You could reduce the above method and eliminate the "filters" by doing the following.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<system name="c172p-glass-effects">
<channel name="rain">
<fcs_function name="glass-effects/airspeed-clamped-sqrt">
<function>
<sqrt>
<quotient>
<min>
<property>/velocities/airspeed-kt</property>
<value>40</value>
</min>
<value>40</value>
</quotient>
</sqrt>
</function>
</fcs_function>
<fcs_function name="glass-effects/splashx">
<function>
<difference>
<value>-0.1</value>
<product>
<value>2.0</value>
<property>/fdm/jsbsim/glass-effects/airspeed-clamped-sqrt</property>
</product>
</difference>
</function>
<output>/environment/aircraft-effects/splash-vector-x</output>
</fcs_function>
<fcs_function name="glass-effects/splashy">
<function>
<value>0.0</value>
</function>
<output>/environment/aircraft-effects/splash-vector-y</output>
</fcs_function>
<fcs_function name="glass-effects/splashz">
<function>
<difference>
<value>1.0</value>
<product>
<value>1.35</value>
<property>/fdm/jsbsim/glass-effects/airspeed-clamped-sqrt</property>
</product>
</difference>
</function>
<output>/environment/aircraft-effects/splash-vector-z</output>
</fcs_function>
</channel>
</system>
</syntaxhighlight>

Yet another method (currently used in the c172p) limits movement to a range of table entries. This gives the developer the ability to control the behavior even more.
<syntaxhighlight lang="xml">
<PropertyList>
<filter>
<name>splash-xa</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/velocities/airspeed-kt</property>
<entry><ind> 0 </ind><dep> -0.33 </dep></entry>
<entry><ind> 4 </ind><dep> -0.33 </dep></entry>
<entry><ind> 5 </ind><dep> -1.7 </dep></entry>
<entry><ind> 50 </ind><dep> -2.1 </dep></entry>
</table>
</expression>
</input>
<output>
<property>/environment/aircraft-effects/splash-xa</property>
</output>
</filter>
<filter>
<name>splash-za</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/velocities/airspeed-kt</property>
<entry><ind> 0 </ind><dep> 0.82 </dep></entry>
<entry><ind> 4 </ind><dep> 0.82 </dep></entry>
<entry><ind> 5 </ind><dep> -0.17 </dep></entry>
<entry><ind> 50 </ind><dep> -0.35 </dep></entry>
</table>
</expression>
</input>
<output>
<property>/environment/aircraft-effects/splash-za</property>
</output>
</filter>
<filter>
<name>splash-xr</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/engines/active-engine/rpm</property>
<entry><ind> 0 </ind><dep> -0.33 </dep></entry>
<entry><ind> 600 </ind><dep> -0.33 </dep></entry>
<entry><ind> 601 </ind><dep> -1.3 </dep></entry>
<entry><ind> 1500 </ind><dep> -1.9 </dep></entry>
</table>
</expression>
</input>
<output>
<property>/environment/aircraft-effects/splash-xr</property>
</output>
</filter>
<filter>
<name>splash-zr</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<expression>
<table>
<property>/engines/active-engine/rpm</property>
<entry><ind> 0 </ind><dep> 0.82 </dep></entry>
<entry><ind> 600 </ind><dep> 0.82 </dep></entry>
<entry><ind> 601 </ind><dep> 0.127 </dep></entry>
<entry><ind> 1500 </ind><dep> -0.29 </dep></entry>
</table>0
</expression>
</input>
<output>
<property>/environment/aircraft-effects/splash-zr</property>
</output>
</filter>
<filter>
<name>splash-x</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<condition>
<greater-than-equals>
<property>/velocities/airspeed-kt</property>
<value>5</value>
</greater-than-equals>
</condition>
<property>/environment/aircraft-effects/splash-xa</property>
</input>
<input>
<condition>
<less-than>
<property>/velocities/airspeed-kt</property>
<value>5</value>
</less-than>
</condition>
<property>/environment/aircraft-effects/splash-xr</property>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-x</property>
</output>
</filter>
<filter>
<name>splash-y</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<value>0.0</value>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-y</property>
</output>
</filter>
<filter>
<name>splash-z</name>
<update-interval-secs type="double">0.1</update-interval-secs>
<type>gain</type>
<gain>1.0</gain>
<input>
<condition>
<greater-than-equals>
<property>/velocities/airspeed-kt</property>
<value>5</value>
</greater-than-equals>
</condition>
<property>/environment/aircraft-effects/splash-za</property>
</input>
<input>
<condition>
<less-than>
<property>/velocities/airspeed-kt</property>
<value>5</value>
</less-than>
</condition>
<property>/environment/aircraft-effects/splash-zr</property>
</input>
<output>
<property>/environment/aircraft-effects/splash-vector-z</property>
</output>
</filter>
</PropertyList>
</syntaxhighlight>

=== Frost and fogging ===

Frost on the canopy is rendered when environment/aircraft-effects/frost-level is set in the range from 0 to 1. Again, it is up to the aircraft developer to decide at what exterior conditions frosting should happen and whether the aircraft is equipped with heating to remove the frost again.

Fogging is controlled by environment/aircraft-effects/fog-level in the range 0 to 1. Unless a mask is used, fogging is homogeneous across the whole surface (it is really intended to be used with a mask).

=== Tint ===

Tinted glass can be easily created by changing

<syntaxhighlight lang="xml">
<glass-tint type="vec4d" n="0"> 1.0 1.0 1.0 1.0</glass-tint>
</syntaxhighlight>

to any value desired. This will affect all effects assumed outside of the glass layer (frost and rain splashes) but not fogging inside the glass. Use primarily for development and quick tests, don't misuse the alpha value available here, it has odd side effects.

=== Functional masks ===

If the glass surface is uv-mapped and textured, it is possible to switch on a mask functionality in the inheritance via

<syntaxhighlight lang="xml">
<texture n="2">
<image>my_mask.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>clamp</wrap-s>
<wrap-t>clamp</wrap-t>
<internal-format>normalized</internal-format>
</texture>
<use-mask type="int">1</use-mask>
<overlay-color type="vec3d" n="0">1.0 1.0 1.0</overlay-color>
</syntaxhighlight>

The red channel in my_mask.png controls the strength of fogging, full red corresponds to maximal fogging, no red to zero fogging. This allows to selectively model the position of heaters in the cockpit. Use <b>/environment/aircraft-effects/fog-level</b> to adjust the actual amount of fog runtime.

The green channel of my_mask.png is the amount of reduction of rain in an area. This is intended for airplanes equipped with windshield wipers to partially clear the wiped area of the rain. Whether the windshield wiper is actually on or not is controlled runtime via <b>/environent/aircraft-effects/use-wipers</b> (1 sets wipers to on).

The blue channel of my_mask.png is reserved for an overlay pattern which will be drawn in an optionally specified <overlay-color> vector (white in the example xml above) - the primary function is to render damage on the glass, but with a different color, also dirt or an alternative more finely controlled frost pattern can be used. The strength of the pattern can be adjusted runtime via <b>/environment/aircraft-effects/overlay-alpha</b>, allowing dynamical accumulation of dirt or sudden appearance of damage.

Examples for the result of a fog mask and a damage mask are shown below:

[[File:Glass12.jpg|400px|Crack pattern using a damage mask]]
[[File:Glass11.jpg|400px|Partial fogging using a mask texture]]

<b>Note that by default all the runtime switches for the mask are off / set to zero! Remember to to switch them on when testing the effect!</b>

=== Mie scattering ===

Most glass effects show prominent Mie forward scattering as in reality, i.e. frost patterns or fogging will appear much more prominent when looking almost towards the sun than under any other angle. While the frost pattern is normally not very prominent and one is able to look through unhindered, this changes substantially when looking into the sun, at which point it almost obscures the view.

[[File:Glass08.jpg|400px|Mie scattering of low light on frost]]
[[File:Glass13.jpg|400px|Morning sun Mie scattering on fog]]

For frost and fog, the strength of the effect is set automatically, but for the damage/dirt layer it is under user control at effect design time. Changing the parameter

<syntaxhighlight lang="xml">
<overlay-glare type="float">0.5</overlay-glare>
</syntaxhighlight>

from its default value allows to adjust the strength of the glare when looking through the overlay layer close to the sun.

=== Internal cockpit reflection ===

There is support for a reflection of the cockpit interior.

[[File:Reflect.jpg|640px|Internal glass cube map reflection]]

This needs to be provided as a cubemap specific for the airplane and switched on via the flag <use-reflection> set to 1. The relative strength of the reflection can be optionally via <reflection-strength>. The strength of the reflection in the cockpit is dynamically adjusted for a number of factors, among them balance of direct to indirect light, the approximate amount of light falling on the surface seen in the reflection and the amount of direct sunlight falling into the eye.

If the six cubemap faces are called my_cube_map_??.png, then using an effect file called c172p-reflect.eff the inheritance looks like this:

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

<PropertyList>
<name>c172-reflect</name>
<inherits-from>Effects/glass</inherits-from>
<parameters>
<texture n="3">
<type>cubemap</type>
<images>
<positive-x>my_cube_map_px.png</positive-x>
<negative-x>my_cube_map_nx.png</negative-x>
<positive-y>my_cube_map_py.png</positive-y>
<negative-y>my_cube_map_ny.png</negative-y>
<positive-z>my_cube_map_pz.png</positive-z>
<negative-z>my_cube_map_nz.png</negative-z>
</images>
</texture>
<use-reflection type="int">1</use-reflection>
<reflection-strength type="float">1.0</reflection-strength>
</parameters>
</PropertyList>
</syntaxhighlight>

The inheritance call includes all surface objects that use the effect.

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Aircraft/c172p/Models/Effects/c172p-reflect</inherits-from>
<object-name>glas</object-name>
<object-name>rightwindow</object-name>
<object-name>leftwindow</object-name>
</effect>
</syntaxhighlight>

See below (Interior shading), for details on cube_map creation and orientation.

=== Lightmaps for internal cockpit reflection ===

If the cockpit is illuminated at night, the reflection map will not show this change by default. However,the glass effect supports a lightmap for the reflection, which can be used in parallel with the lightmap for the panels to show the reflection of a lit panel at night.

Since the reflection map is a cube map, the lightmap for it has to be as well, the syntax is hence

<syntaxhighlight lang="xml">
<use-reflection-lightmap type="int">1</use-reflection-lightmap>
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Models/Effects/interior/reflection/light-px.png</positive-x>
<negative-x>Models/Effects/interior/reflection/light-nx.png</negative-x>
<positive-y>Models/Effects/interior/reflection/light-py.png</positive-y>
<negative-y>Models/Effects/interior/reflection/light-ny.png</negative-y>
<positive-z>Models/Effects/interior/reflection/light-pz.png</positive-z>
<negative-z>Models/Effects/interior/reflection/light-nz.png</negative-z>
</images>
</texture>
</syntaxhighlight>

The control parameters of the lightmap otherwise parallel those of the [[Model-combined_effect]] or the model interior effect described below, i.e. up to four channels can be independently specified on the lightmap.

=== Troubleshooting ===

By default, rain and frost are mapped to the shape of the canopy using coordinate systems that adapts to the splash vector and the canopy shape. This requires no particular action aircraft-side except to provide the bare geometry of a canopy/windshield, but may not be satisfactory in all instances - in particular for near vertical cockpit side windows the scheme does poorly.

There are two alternative coordinate maps available in this case, controlled by the parameter

<syntaxhighlight lang="xml">
<surface-mapping-scheme type="int">0</surface-mapping-scheme>
</syntaxhighlight>

If the parameter is changed to 1, the uv-mapping of the surface is used (it has to exist of course). For this to work properly, the uv-mapping needs to be sufficiently regular and roughly preserve the mapped area.

If the parameter is changed to 2, a local orthonormal system based on the normals of the surface is constructed. This no longer takes the splash vector consistently into account and works poorly for surfaces which are flat in the (xy)-plane, but gives decent result for side windows.

== The HUD effect ==

The HUD effect is a variant of the glass effect designed to render the visuals of a head-up display (HUD) closer to real life. This only works if the HUD is custom-created via [[Canvas]], not via the native FG HUD mechanism as the latter by-passes the effect framework.

The effect takes the same configuration options as the glass effect (i.e. it can render frost, damage, scratches, glare,...) but in addition it runs a blur over the HUD image and alters the color distribution of the projected symbols to de-saturate the bright parts in the center. The result looks less monochromatic and more like light projected onto a surface (left: bare canvas right: HUD effect)

[[File:HUD effect.jpg|800px|Comparison between a bare canvas HUD (left) and the ALS HUD shader run over it (right)]]

=== Usage ===

The effect is used from the model file by assigning it to the surface that also carries the canvas texture of the HUD via

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/hud</inherits-from>
<object-name>HUDImage</object-name>
</effect>
</syntaxhighlight>

This should usually work out of the box, but if the HUD brightness should be changeable or the glass properties adjusted, a derived effect needs to be created.

=== Parameters ===

In addition to the parameters supported by the glass shader (which, for instance in the case of rain splashes, may or may not be appropriate for a HUD, this is left at user's discretion), the HUD effect takes the following special parameters:

<syntaxhighlight lang="xml">
<brightness>1.0</brightness>
<sample-res>0.0006</sample-res>
<sample-far>2.5</sample-far>
</syntaxhighlight>

The first one is the relative brightness setting of the HUD (which should equal the alpha value assigned to the canvas image of the symbols). This parameter is used to de-saturate colors in the symbol centers.

Remaining two parameters represent the size and shape of the blur Kernel being used. The sample resolution (sample-res) determines the overall size of the blur region, the farthest sample (sample-far) how far out the tails of the blur region extend.

Note: The number of sampling steps is not computed adaptive to these parameters, if the steps get too coarse, then multiple image echoes instead of a proper blur will be generated - adjust these parameters with care (if at all).

== The display effect ==

Like the HUD effect, the display effect augments the visuals of a canvas, but in this case it simulates the effects on a multi-function display in cockpit, i.e. emissive light from a dark background.

For that reason, the effect takes the same set of configuration parameters as the [[#The ALS interior model effect|interior model effect]], i.e. it can be supplied for instance with an opacity map.

The expected and tested structure of the effect is that the display content is rendered on a canvas with transparent background color which in turn is above a different, dark-colored surface which stands for the display background. The best visuals are achieved when aircraft-internal shadows are rendered via opacity map on the dark surface and the corresponding contrast effects to the transparent canvas.

Currently the effect does three major things:

* at low light, it can make overly bright displays look slightly blurry and difficult to read as well as de-saturate the colors. This simulates the effects of a too-bright display on the eye and should prompt the user to dim the display.

[[File:Display effect03.jpg|640px|Display effect: blur at low light (left)]]

* at strong direct light, the effect can extinct the display content if it is set too dim. This should prompt the user to increase display brightness

[[File:Display effect04.jpg|640px|Display effect: extinction at strong illumination]]

* finally, if glancing light falls onto the display, the effect can render dust. Note that unlike normal diffuse lighting, the dust appears really strongest when the light almost hits the display from the side.

[[File:Display shader dust.jpg|640px|Display effect: dust]]

* in addition to that, the effect contains the same grain map the interior model effect offers. This can be used e.g. to superimpose a pixel raster (to simulate a CRT screen) or to dim the edges of the display as compared to the center as desired.

=== Usage ===

The effect is used from the model file by assigning it to the surface that also carries the canvas texture of the display via

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/model-interior-display</inherits-from>
<object-name>DisplayImage</object-name>
</effect>
</syntaxhighlight>

If brightness changes of the display need to be simulated, the aircraft needs to pass parameters to the effect, so usually a derived effect would be created and assigned instead of the base effect in the example above.

=== Parameters ===

The effect can be configured with all the parameters of the model interior effect, most useful of those is likely the opacity map.

As specifically new parameters, the following set is used:

<syntaxhighlight lang="xml">
<texture n="5">
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>clamp</wrap-s>
<wrap-t>clamp</wrap-t>
<internal-format>normalized</internal-format>
<image>Aircraft/Generic/Effects/dust-effect-overlay.png</image>
</texture>
<sample-res>0.0007</sample-res>
<dirt-factor>3.0</dirt-factor>
<contrast>1.0</contrast>
</syntaxhighlight>

The supplied texture is the image of the dust layer that is shown. The default image is reasonable to show a dirty screen, but it can be changed into a user-supplied image.

The first parameter is the sampling scale of the blur kernel (see the HUD effect). It describes how blurry the display will appear when overbright in a dark scene. For too large values, the finite number of samples will become very apparent, so this needs to be adjusted with care.

The second parameter describes how pronounced the dirt layer appears - it is a multiplier to the alpha value of the dust texture. For the default texture, values in the range [0:3] are appropriate.

The contrast parameter finally needs to be set by a model of the current mean light level in the cockpit (this is not just the ambient scene light, as there may be cockpit lights, instrument lights etc.) A contrast value of 0 means that the display is on the dim side with respect to the overall light level, a value of 2 means that it is set much to bright and will appear blurry and discolored.

Conversely, a very low contrast value leads to display content extinction if direct light falls onto the display (this needs an opacity map for best effect and queries the texel color values, so the screen brightness should be set up by changing the surface emissivity for this to work correctly).

Dependent on how the lighting inside the cockpit is modeled, it's the aircraft maintainer's responsibility to determine a good contrast value, FG does not have a good model of light inside a cockpit and eye adaption level.

== The ALS interior model effect ==

Since the interior of a cockpit is a large part of what a pilot gets to see in-flight, but this interior represents a rather special situation (light is reduced as it falls through windows, it may have artificial light, there is never any fog or haze,...) ALS offers a separate effect to specifically render the interior of a plane.

This effect also includes optional features which will be available at higher quality settings of the model shader.

=== Interior shadows and tinted glass effect ===

With FlightGear version 3.5 and above, ALS now supports interior shading; i.e. the sun shining through the windows and casting shadows on the panel.

[[File:interior01.jpg|640px|Interior shading effect]]

This effect is based on an opacity map - a cube map of textures which tells the renderer where the cockpit is transparent and where not. The opacity map has to be created beforehand, which allows to make it quite detailed. In this map, white stands for a completely transparent surface, black for an opaque surface, colors for tinted glass which will create a colored light spot in the cockpit, grey hues for partial shadowing allowing to paint dirt effects onto the windows, and caustics can be drawn using the alpha channel: (1-alpha) will be used as an enhancement of the light at a certain spot.

The effect is typically declared as derived by inheritance using an effect file such as c172-interior.eff which looks like this

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

<PropertyList>
<name>c172-interior-glass</name>
<inherits-from>Effects/model-interior</inherits-from>
<parameters>
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Models/Effects/interior/clr_px.png</positive-x>
<negative-x>Models/Effects/interior/clr_nx.png</negative-x>
<positive-y>Models/Effects/interior/clr_py.png</positive-y>
<negative-y>Models/Effects/interior/clr_ny.png</negative-y>
<positive-z>Models/Effects/interior/clr_pz.png</positive-z>
<negative-z>Models/Effects/interior/clr_nz.png</negative-z>
</images>
</texture>
<opacity-cube-center type="vec3d" n="0"> 0.5 0.0 0.3</opacity-cube-center>
<opacity-cube-scale type="vec3d" n="0"> 1.5 0.5 0.7</opacity-cube-scale>
<opacity-cube-angle type="float">0.0</opacity-cube-angle>
</parameters>
</PropertyList>
</syntaxhighlight>

which is called by inheritance in the model.xml file.

Imagine the opacity map as a box surrounding the cockpit and trying to closely follow its contours. The origin in the box needs to be placed into the center of the cockpit, which is what <b><opacity-cube-center></b> does. Each of the three dimensions then needs to be stretched to roughly fit the layout of the canopy, this is done by <b><opacity-cube-scale></b>.

If opacity map center and scale are wrong, you will still see shadows, but they won't match the real cockpit layout (the lightspot of a window will be seen displaced and at a different size of the real window). Thus, carefully measuring the best box layout in a 3d tool is moderately important.

Aircraft-side the effect is called as

<syntaxhighlight lang="xml">
<effect>
<inherits-from>Aircraft/c172p/Models/Effects/c172p-interior</inherits-from>
<object-name>Plane.010_0</object-name>
<object-name>Plane.010_1</object-name>
<object-name>PilotSeat</object-name>
<object-name>CopilotSeat</object-name>
<object-name>panel_1_1</object-name>
<object-name>InstrumentCover.001</object-name>
<object-name>doorint_right</object-name>
<object-name>doorint_left</object-name>
<object-name>doorhandleint_right</object-name>
<object-name>doorhandleint_left</object-name>
<object-name>Panel_0</object-name>
<object-name>Throttle</object-name>
<object-name>Mixture</object-name>
<object-name>Pedestal</object-name>
<object-name>TrimWheel</object-name>
<object-name>ParkingBrake</object-name>
<object-name>BackSeat</object-name>
<object-name>FuelSelectorFace</object-name>
</effect>
</syntaxhighlight>

Each object that you want the shadow effect to fall on must be included in the inheritance.

Unless you supply a path, the cube_.png's need to reside in the same directory as the model.xml where you added the <effect> tag pair that calls c172-interior.eff, not where you put the aircraft_interior.eff.

The orientation of the faces of each cube have to be adjusted based on the positive and negative axis of the model.

For example, using the c172p model as a reference.

The tail, right wing and top on the model are positive inside Blender. So the cube faces are laid out as follows.

Note: Depending on the image's orientation when photographed the rotation direction will vary. This is assuming the images are being taken from the center of the cockpit looking out. Using compass headings to describe how to rotate the images.

px (tail) rotate 90 deg from N or S to W

nx (nose) rotate 90 deg from N or S to E

py (starboard/right) from N do not rotate

ny (port/left) from N rotate 180 deg to S

pz (top) rotate 90 deg from N or S to W

nz (bottom) rotate 90 deg from N or S to W

[[File:C172p-cube.jpg|640px|Cube map layout of the c172p]]

With Blender, it's pretty easy to create the cubemap.

1. Add a camera where the cubemap will be. Set the FOV to 90 degrees.
2. Set the resolution to 1024x1024 (or any other square, power-of-two size).
3. Hide all lights and windows; disable ambient lighting (set it to black) and turn off ambient occlusion.
4. Set the world color to white.
5. Enable the compositor and add an invert node.
6. Render and save the six views as you would normally.
7. Add dirt, tinted glass color and caustics by hand

This process depends on the model setup but it should work for most aircraft with a few tweaks.

==== Cubemap Kit for Blender ====

[[File:Als-interior-shadow-blender-instructions.png|320px|How to make an interior cubemap with the cubemap kit]]

See [http://chateau-logic.com/content/flightgear-interior-shadow-cubemap-kit flightgear-interior-shadow-cubemap-kit] for a premade kit to create the cubemap and the .eff sample file to use it.

==== Important Notes ====

<b>Important note:</b> Currently (May 2015) the effect does not deal gracefully with child models included into the main model with offsets and/or rotations because these introduce a different coordinate system in which the shadow does not match. The general idea of a code solution is known, but not implemented. Right now this can only be addressed by explicitly positioning child models in the *.ac file and not using any offsets when including them.

=== ALS flashlight ===

This effect is meant to imitate a hand held flashlight for use in getting instruments in the cockpit turned on in dark conditions.
It is almost identical in nature to ALS searchlight only it is applied using interior-model.eff.
It has two user defined light color filters that can be applied and also a user defined light radius setting.

[[File:ALS flashlight.jpg|600px|ALS flashlight effect]]

To implement this effect use
<syntaxhighlight lang="xml"><inherits-from>Effects/model-interior</inherits-from></syntaxhighlight>
A full definition looks like this

<syntaxhighlight lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<PropertyList>
<name>c172-interior</name>
<inherits-from>Effects/model-interior</inherits-from>
<parameters>
<light-filter-one type="vec3d">0.5 0.5 0.5</light-filter-one>
<light-filter-two type="vec3d">0.9 0.2 0.2</light-filter-two>
<light-radius type="float">13</light-radius>
</parameters>
</PropertyList>
</syntaxhighlight>
In the example above light-filter-one is soft white light and light-filter-two is a soft red light.

After defining as above you can turn it on using the following property

/sim/rendering/als-secondary-lights/use-flashlight = 1 is light-filter-one

/sim/rendering/als-secondary-lights/use-flashlight = 2 is light-filter-two

'''Special note:'''
The flashlight effect inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.

<syntaxhighlight lang="xml">
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x>
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x>
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y>
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y>
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z>
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z>
</images>
</texture>
</syntaxhighlight>

=== Implicit lightmap ===

At lowest quality level, the effect supports an implicit lightmap, i.e. a color range of the basic texture can be selected and declared to act as a lightmap. This is specifically useful to render panel backlighting as in the example below:

[[File:Ilightmap.jpg|600px|An implicit lightmap used to simulate a backlit panel]]

The effect is off by default and switched on by setting

<syntaxhighlight lang="xml">
<implicit-lightmap-enabled type="int">1</implicit-lightmap-enabled>
</syntaxhighlight>

The following parameters are available:

<syntaxhighlight lang="xml">
<implicit-lightmap-tag-color type="vec3d">1.0 1.0 1.0</implicit-lightmap-tag-color>
</syntaxhighlight>

This sets the base color to be tagged, i.e. if the panel labels to be illuminated at night are white, the color needs to be set to white.

<syntaxhighlight lang="xml">
<implicit-lightmap-threshold-low type="float">0.5</implicit-lightmap-threshold-low>
<implicit-lightmap-threshold-high type="float">1.5</implicit-lightmap-threshold-high>
</syntaxhighlight>

The thresholds determine how similar a color may be to the base color in order to be still illuminated. The measure is the Euklidean distance of the color vectors. The lower thresholds determines when illumination will start to fade, the higher threshold at what distance in color space illumination will no longer take place. The thresholds have to be adapted to the specific situation - the technique works best for high-contrast panels (white labels on black background) and may not work at all for low contrast panels.

<syntaxhighlight lang="xml">
<implicit-lightmap-emit-color type="vec3d">1.0 1.0 1.0</implicit-lightmap-emit-color>
</syntaxhighlight>

The emit color specifies at which color the pixel will show if it is tagged (see above) and the implicit lightmap is on (see below) - set this to the color of the backlight.

<syntaxhighlight lang="xml">
<implicit-lightmap-intensity type="float">0.0</implicit-lightmap-intensity>
</syntaxhighlight>

Finally, the intensity determines how brightly the illuminated pixel will shine.

Ambiance lighting can be simulated with the following tags.

<syntaxhighlight lang="xml">
<residual-ambience-r type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-r</use></residual-ambience-r>
<residual-ambience-g type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-g</use></residual-ambience-g>
<residual-ambience-b type="float"><use>/fdm/jsbsim/systems/light/cockpit-ambience-b</use></residual-ambience-b>
</syntaxhighlight>

In the above example note the use of the "use" tag.

<syntaxhighlight lang="xml">
<use>/fdm/jsbsim/systems/light/cockpit-ambience-r</use>
</syntaxhighlight>

This can be any defined property or static value.

'''Special note:'''
The implicit lightmap inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.

<syntaxhighlight lang="xml">
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x>
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x>
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y>
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y>
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z>
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z>
</images>
</texture>
</syntaxhighlight>

=== Irradiance maps ===

<b>Note:</b> This effect requires higher than minimum model shader quality setting.

In the simplest rendering schemes, diffuse and specular light are assumed to be highly directional (i.e. it illuminates lit surfaces only) while ambient light is taken to be omnidirectional.

In reality, that is hardly ever true. In a typical outside location, ambient light is mainly coming from the sky above (which is why the ground underneath a car is dark even in the absence of directional light when the sky is overcast and the sun is not visible). In an enclosed space (like a room, or an aircraft cockpit), ambient light has to fall through the windows, i.e. is mainly not coming above but falling in horizontally.

The directional dependence is not very strong though, yet it leaves measurable effects. In rendering, this can be accounted for by irradiance maps. In the following, the interior of the C-172p is rendered in the first case using omnidirectional ambient light, in the second case using an irradiance map giving the ambient light the directionality of the cabin windows, i.e. the light falls in predominantly horizontally (in addition, a grain map is superimposed to provide structure). Note how the spatial structure of the roof, looking bland when rendered in omnidirectional light is brought out by the irradiance map.

[[File:Als-interior-irradiance01.jpg|400px|C-172p cabin interior rendered without irradiance and grain map]]
[[File:Als-interior-irradiance02.jpg|400px|C-172p cabin interior rendered with irradiance and grain map]]

Irradiance mapping is configured by the following parameters:

<syntaxhighlight lang="xml">
<irradiance-map-type type="int">2</irradiance-map-type>
<irradiance-map-strength type="float">0.5</irradiance-map-strength>
</syntaxhighlight>

There are several pre-configured irradiance map functions which can be chosen by map type.

0: (default) omndirectional light
1: light predominantly coming from above (most appropriate for fighter cockpits)
2: light predominantly coming from the horizon (most appropriate for GA aircraft)

The strength of the irradiance map regulates how pronounced the asymmetry of the map will be. A strength of zero always makes the light omnidirectional, whereas a strength of 1 implies that no light is coming from any direction 90 degree to the main direction (i.e. for the option 2, a strength of 1.0 means that no ambient light will fall in from above or below and that hence horizontal surfaces will appear pitch black unless direct light falls on them)

'''Special note:'''
The irradiance map inherits model-interior, model-interior.eff is setup around the opacity cube map, it won't allow you to go without one, and in the event you try, you get an environment reflection cube map as default which happens to have green grass on it and may cast a greenish hue over applied objects.
A workaround is to create a pseudo cubemap by creating a white.png 64x64 square, and creating the following structure to represent a transparent cubemap.

<syntaxhighlight lang="xml">
<texture n="4">
<type>cubemap</type>
<images>
<positive-x>Aircraft/c172p/Models/Effects/interior/white.png</positive-x>
<negative-x>Aircraft/c172p/Models/Effects/interior/white.png</negative-x>
<positive-y>Aircraft/c172p/Models/Effects/interior/white.png</positive-y>
<negative-y>Aircraft/c172p/Models/Effects/interior/white.png</negative-y>
<positive-z>Aircraft/c172p/Models/Effects/interior/white.png</positive-z>
<negative-z>Aircraft/c172p/Models/Effects/interior/white.png</negative-z>
</images>
</texture>
</syntaxhighlight>.

=== Explicit lightmap ===

<b>Note:</b> This effect requires higher than minimum model shader quality setting.

In addition to the implicit lightmap, it is also possible to explicitly specify a lightmap. The syntax for this exactly parallels the syntax of the [[Model-combined_effect]] which supplies lightmaps for the exterior.

For example

<syntaxhighlight lang="xml">
<texture n="3">
<image>Aircraft/MyAircraft/Effects/my_lightmap.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>clamp</wrap-s>
<wrap-t>clamp</wrap-t>
<internal-format>normalized</internal-format>
</texture>
<lightmap-enabled type="int">1</lightmap-enabled>
<lightmap-multi type="int">0</lightmap-multi>
<lightmap-factor type="float" n="0">1.0</lightmap-factor>
<lightmap-color type="vec3d" n="0"> 1.0 1.0 1.0 </lightmap-color>
</syntaxhighlight>

sets up a single channel lightmap in which pixel color times the lightmap color provides the illumination. Using the multi-channel function, up to four different maps can be specified in which the (rgba) values of a pixel encode where the light falls and the associated lightmap color what color the illumination takes. Each of these maps can be switched on and off or dimmed in intensity independently.

=== Grain map ===

<b>Note:</b> This effect requires higher than minimum model shader quality setting.

The grain map sets a repeating hires overlay texture which can supply a very credible illusion of structure to a surface for cheap. The syntax exactly parallels that of the [[Model-combined_effect]] ALS grain feature described above.

For instance, the following

<syntaxhighlight lang="xml">
<texture n="7">
<image>Aircraft/Effects/MyGrainmap.png</image>
<type>2d</type>
<filter>linear-mipmap-linear</filter>
<wrap-s>repeat</wrap-s>
<wrap-t>repeat</wrap-t>
<internal-format>normalized</internal-format>
</texture>
<grain-texture-enabled type="int">1</grain-texture-enabled>
<grain-magnification type="float">10</grain-magnification>
</syntaxhighlight>

sets up a grain overlay with a 10-time higher resolution over the base texture layer.

== ALS procedural lights ==

The ALS framework supports procedurally generated lights (for instance aircraft position lights, strobe lights,... ) for aircraft and models. Note that the effect produces the visuals of the lights themselves, but they do not illuminate their surroundings.

=== Why procedural lights? ===

Traditionally aircraft position lights have been implemented as billboarded emissive textures. This technique is limited in scope, as it has difficulty producing a directional light or changes in the light appearance (for instance glare) with changed scene lighting. The ALS procedural lights are designed to give visuals consistent with the auto-generated scene lights (runway lighting, street lights) and support configurable directionality, glare and even the illumination of fog by the lights.

=== Basic implementation ===

The base of the light is a texture quad which has Effects/procedural-light.eff assigned. Start from including the template provided into your model as

<syntaxhighlight lang="xml">
<model>
<path>/Models/Effects/procedural_light.xml</path>
<offsets>
<x-m> 0 </x-m>
<y-m> 0 </y-m>
<z-m> 2 </z-m>
</offsets>
</model>
</syntaxhighlight>

and configure from there according to your own needs.

<b>Do not billboard the light via animation!</b> The GLSL code will take care of the billboarding. Use a scale animation to change the size of the light, do not change the quad (the *.ac) itself in size, the shader code requires its geometry to be fixed.

The lights are currently not supported in the default or Rembrandt renderer and will simply be invisible in these frameworks.

=== Configuring the light ===

Make your own derived effect inheriting from Effects/procedural-light.eff and assign it in the xml wrapper of the light.

====The base light color set====

The base light color can be set via:

<syntaxhighlight lang="xml">
<light_color_base_r type="float">1.0</light_color_base_r>
<light_color_base_g type="float">0.0</light_color_base_g>
<light_color_base_b type="float">0.0</light_color_base_b>
</syntaxhighlight>

These take the normal set of values ranging from 0 to 1.

====Light full intensity in the center====

Now the light appears at full intensity in the center can be set via:

<syntaxhighlight lang="xml">
<light_color_center_r type="float">1.0</light_color_center_r>
<light_color_center_g type="float">1.0</light_color_center_g>
<light_color_center_b type="float">1.0</light_color_center_b>
</syntaxhighlight>

The idea behind this is that lights give a better visual appearance if their center is rendered visually brighter and de-saturated, but this occurs only if the light is at full intensity.

There are no sanity checks done, you can assign any center color you like even if this makes no sense - you can change center color or darken it, so use with care.

====Runtime change the light intensity====

To runtime change the light intensity, assign

<syntaxhighlight lang="xml">
<intensity_scale type="float">1.0</intensity_scale>
</syntaxhighlight>

to a property and change that property in the range from 0 to 1. Eg:

<syntaxhighlight lang="xml">
<intensity_scale>
<use>/rendering/nav-lights-factor</use>
</intensity_scale>
</syntaxhighlight>

====Set directional lights====

For directional lights, you need to assign a pointing vector in aircraft coordinates into which the light cone points and set the directionality flag to true to activate the computations. This is done via:

<syntaxhighlight lang="xml">
<pointing_x type="float">-1.0</pointing_x>
<pointing_y type="float">0.0</pointing_y>
<pointing_z type="float">0.0</pointing_z>
<is_directional type="bool">true</is_directional>
</syntaxhighlight>

It would be customary to pass a normalized vector, but if you don't know how to do it, the shader will do it for you. By assigning properties to the pointing coordinates, the light direction can be changed runtime.

<b>Do not use a rotation animation to change the light direction - it won't work.</b> Make the pointing vector properties and change them to your needs.

====Fading of a directional light====
[[File:Directional light.jpg|thumb|Explanation of a light radiation pattern]]
The fading of a directional light away from the pointing axis is controlled by passing angles (or rather sines of angles).

<syntaxhighlight lang="xml">
<inner_angle type="float">0.2</inner_angle>
<outer_angle type="float">0.4</outer_angle>
<zero_angle type="float">0.7</zero_angle>
<outer_gain type="float">0.5</outer_gain>
</syntaxhighlight>

Up to inner_angle, the light will have full intensity. From inner to outer angle the light will linearly fade to outer_gain. From outer angle to zero angle, the light intensity will linearly fade to zero.

====Strobe effect====

For get an automatic strobe effect you can set:

<syntaxhighlight lang="xml">
<is_strobe type="bool">true</is_strobe>
</syntaxhighlight>

to true. If you want your own strobe pattern, generate a strobe function and use <b>intensity_scale</b> instead to pass it to the shader.

=== Complete example ===

Here's the left nav light of the C-172p:

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

<name>procedural-light-nav-left</name>
<inherits-from>Effects/procedural-light</inherits-from>

<parameters>
<light_color_base_r type="float">1.000</light_color_base_r>
<light_color_base_g type="float">0.320</light_color_base_g>
<light_color_base_b type="float">0.320</light_color_base_b>
<light_color_center_r type="float">1.0</light_color_center_r>
<light_color_center_g type="float">1.0</light_color_center_g>
<light_color_center_b type="float">1.0</light_color_center_b>
<intensity_scale type="float">1.0</intensity_scale>


<pointing_x type="float">1.0</pointing_x>
<pointing_y type="float">0.7002075382097097</pointing_y>
<pointing_z type="float">0.0</pointing_z>

<is_directional type="bool">true</is_directional>
<is_strobe type="bool">false</is_strobe>


<inner_angle type="float">0.8191520442889918</inner_angle>
<outer_angle type="float">1.0</outer_angle>
<zero_angle type="float">0.982547593563</zero_angle>
<outer_gain type="float">0.1</outer_gain>
</parameters>

</PropertyList>
</syntaxhighlight>

=== Examples ===
The Cessna 182 by Heiko Schulz and Gilberto Agostinho with procedural lights activated:<br>
:''(To percieve the effect well, you probably have to darken your room and switch to fullscreen)''
[[File:Cessna 182 with procedural lights.jpg|800px]]

===Move dynamically the procedural light===

The position of a procedural light is declared in the '''<model>''' section, within the '''<PropertyList>''' XML code, for example:

<syntaxhighlight lang="xml">
<model>
<name>procedural-light-gear-white-left</name>
<path>Effects/lights/procedural_light_gear_white.xml</path>
<offsets>
<x-m> -3.08</x-m>
<y-m> -0.21 </y-m>
<z-m> -1.18 </z-m>
</offsets>
</model>
</syntaxhighlight>

The tag ''procedural-light-gear-white-left'' is very important because is the object name. This name will be used as the reference object.<BR>Next, we can define an animation in the same xml file:

<syntaxhighlight lang="xml">
<animation>
<type>rotate</type>
<object-name>GearFrontalDoor</object-name>
<object-name>procedural-light-gear-white-left</object-name>
<property>gear/gear/position-norm</property>
<axis>
<x1-m> -3.00240</x1-m>
<y1-m> 1.0</y1-m>
<z1-m> -1.02906</z1-m>
<x2-m> -3.00240</x2-m>
<y2-m> -1.0</y2-m>
<z2-m> -1.0290</z2-m>
</axis>
<interpolation>
<entry><ind>0.0</ind><dep>90</dep></entry>
<entry><ind>0.25</ind><dep>90</dep></entry>
<entry><ind>0.50</ind><dep>60</dep></entry>
<entry><ind>0.75</ind><dep>30</dep></entry>
<entry><ind>1.0</ind><dep>0</dep></entry>
</interpolation>
</animation>
</syntaxhighlight>

The ''procedural light'' object code is this:

<syntaxhighlight lang="xml">
<object-name>procedural-light-gear-white-left</object-name>
</syntaxhighlight>

== ALS fuselage shadow effect ==
ALS supports the manipulation of a (simplified) ground shadow. This effect uses an existing simplified shadow animation configuration and by default uses the gear-agl-m property to calculate the ground placement of that simplified shadow.

The system, techniques for using it, and several working examples are on [https://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=135 this extensive forum thread about the ALS shadow effects].

[[File:Alsshadow.jpg|800px|ALS Shadow]]

The effect can be applied easily in any aircraft that report the gear-agl-m property by simply adding a declaration inheriting from shadow.eff.

If the aircraft does not support the gear-agl-m property, (notably JSBSim), you need to create a [[Autopilot configuration reference | Property Rule]] to pass a supported AGL data to the gear-agl-m property. In this case we use altitude-agl-ft converted to meters using a property rule configuration file.

For the first example we'll use the "supported gear-agl-m" method for aircraft that don't require a property rule.

Simply add the following inheritance declaration after you declare your shadow animation statement.
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>name_of_the_shadow_object</object-name>
</effect>
</syntaxhighlight>
In the non-ALS simplified shadow code you normally use a "translate" animation to position the shadow on the ground.
When using the ALS method you must either remove, comment out, or apply a condition to restrict its use to non ALS shadow applications, because ALS is responsible for computing the shadows ground position.

Here is how we apply a condition to the translation to limit it effect to non-ALS application only.
<syntaxhighlight lang="xml">

<animation>
<type>translate</type>
<object-name>shadow</object-name>
<condition>
<not>
<property>/sim/rendering/shaders/skydome</property>
</not>
</condition>
<property>/position/altitude-agl-ft</property>
<factor>-0.3048</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>0</y>
<z>1</z>
</axis>
</animation>
</syntaxhighlight>

A complete shadow animation block looks like this.
<syntaxhighlight lang="xml">
<PropertyList>

<animation>


<object-name>shadow</object-name>
<type>select</type>
<condition>
<not>
<property>/sim/rendering/rembrandt/enabled</property>
</not>
</condition>
</animation>

<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>shadow</object-name>
</effect>

<animation>
<type>noshadow</type>
<object-name>shadow</object-name>
</animation>


<animation>
<type>rotate</type>
<object-name>shadow</object-name>
<property>/orientation/pitch-deg</property>
<factor>-1.0</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>1</y>
<z>0</z>
</axis>
</animation>


<animation>
<type>rotate</type>
<object-name>shadow</object-name>
<property>/orientation/roll-deg</property>
<factor>1.0</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>1</x>
<y>0</y>
<z>0</z>
</axis>
</animation>


<animation>
<type>translate</type>
<object-name>shadow</object-name>
<condition>
<not>
<property>/sim/rendering/shaders/skydome</property>
</not>
</condition>
<property>/position/altitude-agl-ft</property>
<factor>-0.3048</factor>
<center>
<x-m>0</x-m>
<y-m>0</y-m>
<z-m>0</z-m>
</center>
<axis>
<x>0</x>
<y>0</y>
<z>1</z>
</axis>
</animation>

</PropertyList>
</syntaxhighlight>

For aircraft requiring a [[Autopilot configuration reference | Property Rule]] there are a couple extra steps.

In aircraft-set.xml you add the property rule call to the "configuration file" in between the PropertyList/sim/systems tag pairs.
<syntaxhighlight lang="xml">
<property-rule n="101">
<name>gear_agl-m</name>
<path>Aircraft/c172p/Systems/gearAGL.xml</path>
</property-rule>
</syntaxhighlight>
Note: the n="101" needs to be =+100 as -100 is reserved for system wide property rules.
In the above example 101 was used because 100 was already being used by a previous property rule definition.

The "configuration file" normally goes in /Systems.
In this example we named the configuration file /Systems/gearAGL.xml.

Here is the complete /Systems/gearAGL.xml configuration file.
<syntaxhighlight lang="xml">
<?xml version="1.0"?>

<PropertyList>
<filter>
<type>gain</type>
<gain>0.3048</gain>
<input>/position/altitude-agl-ft</input>
<reference>6</reference>
<output>/position/gear-agl-m</output>
</filter>
</PropertyList>
</syntaxhighlight>
What the configuration file does is convert the input of altitude-agl-ft to the output of (((altitude-agl-ft)-6)*0.3048) or (convert ft-6 to m) and pass it to /position/gear-agl-m.

See [[Autopilot configuration reference | Input and reference properties or values <input> and <reference>]].

== ALS 3d shadow volume effect ==
What might be considered the next level of realism using a relatively "cheap" shadow effect is to use a 3d volume shadow.

[[File:Shadow vol02.jpg|800px|ALS 3d Shadow Volume]]

The procedure to implement the ALS shadow volume is similar to the ALS-shadow above with a few modifications.

First you have to have a 3d shadow volume model of the aircraft you are applying the effect to. This model should be a low poly model that is optimized to be as little of a footprint as possible.

A property rule is required, same as above. This is used to generate the above ground altitude in meters, (altitude-agl-m). The "altitude-agl-m" is used to place the shadow close to the ground in real time at an FDM rate of execution.
{{note|Do not confuse "altitude-agl-m" with the other type of non-3d ALS-shadow property of "gear-agl-m". The shaders involved use these two different properties respectively for the two different effect. They are not interchangeable.}}
<syntaxhighlight lang="xml">
<?xml version="1.0"?>
<PropertyList>
<filter>
<type>gain</type>
<gain>0.3048</gain>
<input>/position/altitude-agl-ft</input>
<reference>1.0</reference>
<output>/position/altitude-agl-m</output>
</filter>
</PropertyList>
</syntaxhighlight>

The other difference from the ALS-shadow above is that it uses a different inherited effect.
Instead of
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/shadow</inherits-from>
<object-name>shadow</object-name>
</effect>
</syntaxhighlight>
you use
<syntaxhighlight lang="xml">
<effect>
<inherits-from>Effects/shadow-vol</inherits-from>
<object-name>shadow</object-name>
</effect>
</syntaxhighlight>

To make sure there is no duplicate 3d model shown in other renderers besides ALS it is also important to use a different select animation:
<syntaxhighlight lang="xml">
<animation>

<object-name>shadow</object-name>
<type>select</type>
<condition>
<property>/sim/rendering/shaders/skydome</property>
</condition>
</animation>
</syntaxhighlight>

== Related content ==

* [[Procedural Texturing]]
* [[Atmospheric light scattering]]
* [[ALS infrared vision]]

[[Category:Atmospheric light scattering shader]]
[[Category:Aircraft enhancement]]

Eurocopter EC135

2020-04-08T20:28:23Z

HHS: /* Gallery (Flightgear 2018+) */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful Airbus H135 P3/T3 Helionix with 4-axis autopilot- already in developement by HHS.

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
EC135_Heer.jpeg| EC135 hovering near a forest
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
EC135_Bavaria.jpeg| EC135 Bavarian Police near Castle Neuschwanenstein, Füssen, Germany
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
EC135_Chasing_trains.jpg| EC135 chasing ICE-train near Frankfurt Airport
EC135_EHAM.jpg| Dutch police above EHAM
EC135_Rescue.jpeg| EC135 hovering above a sail ship
EC135_Sea_of_fog.jpg| Deutsche Rettungsflugwacht above a sea of fog, where the tops of the Black Forrest looking out
EC135_Wales.jpg| EC135 hovering in ground effect
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

File:EC135 Bavaria.jpeg

2020-04-08T20:26:47Z

HHS: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=EC135 Bavarian Police near Neuschwanenstein, Füssen, Germany}}
|date=2020-04-08 22:51:14
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Helicopters]]

Eurocopter EC135

2020-04-08T20:25:07Z

HHS: /* Gallery (Flightgear 2018+) */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful Airbus H135 P3/T3 Helionix with 4-axis autopilot- already in developement by HHS.

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
EC135_Heer.jpeg| EC135 hovering near a forest
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
EC135_Chasing_trains.jpg| EC135 chasing ICE-train near Frankfurt Airport
EC135_EHAM.jpg| Dutch police above EHAM
EC135_Rescue.jpeg| EC135 hovering above a sail ship
EC135_Sea_of_fog.jpg| Deutsche Rettungsflugwacht above a sea of fog, where the tops of the Black Forrest looking out
EC135_Wales.jpg| EC135 hovering in ground effect
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

File:EC135 Rescue.jpeg

2020-04-08T20:23:56Z

HHS: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=EC135 rescuing}}
|date=2020-04-08 22:48:44
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Helicopters]]

Eurocopter EC135

2020-04-08T20:22:44Z

HHS: /* Gallery (Flightgear 2018+) */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful Airbus H135 P3/T3 Helionix with 4-axis autopilot- already in developement by HHS.

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
EC135_Heer.jpeg| EC135 over Innsbruck, Austria
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
EC135_Chasing_trains.jpg| EC135 chasing ICE-train near Frankfurt Airport
EC135_EHAM.jpg| Dutch police above EHAM
EC135_Sea_of_fog.jpg| Deutsche Rettungsflugwacht above a sea of fog, where the tops of the Black Forrest looking out
EC135_Wales.jpg| EC135 hovering in ground effect
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

File:EC135 Heer.jpeg

2020-04-08T20:21:47Z

HHS: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=EC135 Heeresfliegerschule hovering above the ground}}
|date=2020-04-08 22:46:16
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Helicopters]]

Eurocopter EC135

2020-04-08T20:15:35Z

HHS: /* Gallery (Flightgear 2018+) */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful Airbus H135 P3/T3 Helionix with 4-axis autopilot- already in developement by HHS.

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
EC135_Chasing_trains.jpg| EC135 chasing ICE-train near Frankfurt Airport
EC135_EHAM.jpg| Dutch police above EHAM
EC135_Sea_of_fog.jpg| Deutsche Rettungsflugwacht above a sea of fog, where the tops of the Black Forrest looking out
EC135_Wales.jpg| EC135 hovering in ground effect
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

File:EC135 EHAM.jpg

2020-04-08T20:10:47Z

HHS: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Dutch Police above EHAM}}
|date=2020-04-08 22:31:14
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Helicopters]]
[[Category:Airports]]
[[Category:AI Traffic]]

File:EC135 Wales.jpg

2020-04-08T20:10:47Z

HHS: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=EC 135 hovering}}
|date=2020-04-08 22:28:02
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Helicopters]]

File:EC135 Sea of fog.jpg

2020-04-08T20:10:46Z

HHS: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=EC 135 Deutsche Rettungsflugwacht above a Sea of Fog common at the Black Forest}}
|date=2020-04-08 22:28:29
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Helicopters]]

File:EC135 Chasing trains.jpg

2020-04-08T20:10:46Z

HHS: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=EC135 Bundespolizei chasing an ICE-Train near Frankfurt Airport}}
|date=2020-04-08 22:30:53
|source={{own}}
|author=[[User:HHS|HHS]]
|permission=
|other versions=
}}

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

[[Category:Helicopters]]
[[Category:AI Traffic]]

Eurocopter EC135

2020-04-08T18:24:43Z

HHS:

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful Airbus H135 P3/T3 Helionix with 4-axis autopilot- already in developement by HHS.

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Eurocopter EC135

2020-04-08T18:23:51Z

HHS: /* Developement repositories */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful EC135 P3/T3

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github].
When milestones or other important steps had been taken [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will be updated.

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Eurocopter EC135

2020-04-08T18:23:07Z

HHS: /* Issues */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful EC135 P3/T3

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github]; when milestones or other important steps had been taken, [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will regularly updated

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autostart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Eurocopter EC135

2020-04-08T18:22:56Z

HHS: /* Todo/Expected */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful EC135 P3/T3

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github]; when milestones or other important steps had been taken, [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will regularly updated

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to Airbus H135 Helionix (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autosart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Eurocopter EC135

2020-04-08T18:22:00Z

HHS:

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful EC135 P3/T3

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github]; when milestones or other important steps had been taken, [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will regularly updated

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO, HHS and Martien van der Plas!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to EC 135 P3 (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autosart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Eurocopter EC135

2020-04-08T18:20:33Z

HHS: /* Gallery (Flightgear 2018+) */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful EC135 P3/T3

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github]; when milestones or other important steps had been taken, [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will regularly updated

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO and me!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to EC 135 P3 (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autosart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Eurocopter EC135

2020-04-08T18:19:48Z

HHS: /* Livery List */

{{:{{PAGENAME}}/info}}
This is an model of the '''Eurocopter EC135 P2''', a light twin-engine, multi-mission [[helicopter]].

The EC 135 descends from the MBB Bo 108. The Bo 108 was a demonstration prototype for fly-by-wire and has it's descent from the famous Bo 105.
When the Eurocopter company was founded, the Bo 108 came with. Eurocopter decided that there was a marketplace for such a helicopter and the development went on. From the French partners it got the fenestron, from MBB the hingeless rotor. The fenestron makes it very hard for dangerous situations in the range of the tail rotor and reduces the noise level about 50% to other helicopters. That's why the EC 135 is a highly recommended helicopter for EMS and the police, especially in Europe but also in the USA, Japan and other states.

=EC135 P2 in FGAddon=
This model for FlightGear simulates the EC135 P2, an older version which has been replaced later by the EC135 P2+. Since late autumn 2014 the current produced version of the EC135 by Airbus Helicopters is the much more powerful EC135 P3/T3

[[File:EC135 P2 Cockpit.jpg|thumb|270px|(02/27/2013) EC135 P2 photorealistic Cockpit with analog flight instruments.
Overhead panel and many other details done as well as some important center pedestal avionics. Unfortunately the GNS430 and GTX430 are not working yet. Now it needs to connect the switches to the electrical system. FDM is finally tuned to POH and matches climbrates AEO and OEI and airspeed in about 90% all of conditions. :-) ]]

==Developement repositories==
Developement takes place at [https://github.com/HHS81/ec135 Github]; when milestones or other important steps had been taken, [https://sourceforge.net/p/flightgear/fgaddon/HEAD/tree/trunk/Aircraft/ec135/ FGAddon] will regularly updated

==Development status/Features:==

* new 3d-model more accurate and detailed, single-livery-texture-file
* latest shader (bumpspec-reflection and glasshader)
* realistic startup
* new, much more accurate fdm matching 90% of Pilot Operations Handbook values AEO, OEI and Airspeed
* matching tech reports in flight handling
* more different configurations possible- lowskid, midskid and highskid, different sandfilter, different radomes etc...
* analog dual and single IFR panel available and selectable with photorealistic textures
* influence of configurations on weight and CoG based on Pilot Operations Handbook
* many different liveries by Sanni, D-ECHO and me!
* and of course completely Rembrandt compatible!
* Sounds remastered

==Todo/Expected ==
* Autostart, more accurate simulation of the systems (hydraulic, ....)
* emergency float simulation
* Sound needs a bit work on the "exhaust sound" and the aural warning system must be done (soundfiles mostly complete)
* making CAD and VEMD and the most important systems working (Canvas)
* different selectable interiors influencing weight HEMS modelled, VIP and Utility(Police)
* Digital Dual and Single IFR Panel
* conversion to EC 635 (needs some changes on exterior and interior model)
* conversion to EC 135 P3 (longer rotorblades, no endplates, smaller tailbumper, new IBF, more powerful engines = more lift, more power! )
* seperate AI model to keep mp-users happy
* and more to come....

==Issues==
* no autosart yet (}-key isn't working)
* no emergency float simulation yet

== Livery List==
* German Bundespolizei
* Air Zermatt
* ÖAMTC (without any markings)
* ADAC D-HDEC ( The real one after this model is made)
* ADAC D-HDAC
* DRF D-HYYY (First ever EC135 rescue helicopter in service)
* Polizei Brandenburg
* Polizei Bayern
* Marine Fluggeschwader 5
* Luftwaffe, Heeresfliegerschule (8265
* Korps Landelijke Politiediensten (PH-PXA)
* DRF (German Flightrescue)- Thanks to DRF for supporting Sanni making this livery!
* French Gendarmerie
* Lifeflight
* BMI (Federal Ministry for Interior) - Rescue helicopter
* Polisen (Swedish Police)
* Luftambulans
* Police Hamburg
* Police Innsbruck (Austrian Police)
* Primer Colors (that's how the EC135 looks without any paint)
* SHS (Austrian Rescue Helicopter based in Kufstein, Zell am See, Kaltenbach...)
* Suffolk Police
* VLL
* Wales Air Ambulance (G-WASC)
* White Default

== Gallery (Flightgear 2018+)==
<gallery mode=packed>
Eurocopter_EC135_at_Innsbruck,_Austria_(FlightGear_2018.x).jpg| EC135 over Innsbruck, Austria
SOTM-Sept17.jpg| EC135 at Mount Waialeale "Weeping wall" waterfalls in Hawaii
Rotor_wash.jpg| EC135 Hovering (effect not in FGaddon yet)
Eurocopter_EC135_over_wet_volumetric_grass_in_Innsbruck_Airport_(LOWI),_Austria_(Flightgear_2018.x).jpg| EC135, Innsbruck
Eurocopter_EC135_over_Zurich,_Switzerland_(FlightGear_2019.x).jpg| EC135 in Zurich, Switzerland
</gallery>

== Gallery (Flightgear 2012-2014) ==
<gallery mode=packed>
EC135 Swedish Police.jpg|New EC135 - "Swedish Police" made by Sanni
EC135 Air Zermatt.jpg|New EC135 - "Air Zermatt" by Sanni
EC135 P2 "Air Zermatt" near Matterhorn.jpg|EC135 P2 "Air Zermatt" near Matterhorn
EC135 P2 above some ground haze.jpg|EC135 P2 above volumetric ground haze in Washington
</gallery>

== External link ==
[http://www.airbushelicopters.com www.airbushelicopters.com]

{{Eurocopter}}

[[fr:Eurocopter EC135]]

Professional and educational FlightGear users

2020-02-07T18:36:29Z

HHS:

{{mergefrom|Technical Reports}}

[[FlightGear]] is used by dozens of organisations, companies and universities all over the world.

== Companies ==
* '''Aeronautical Development Agency''', Bangalore India. FlightGear is used as as the image generator for a flight simulation facility for piloted evaluation of ski-jump launch and arrested recovery of a fighter aircraft from an aircraft carrier.
* '''Veridian Engineering Division''', Buffalo, NY. FlightGear is used for the scenery and out-the-window view for the Genesis 3000 flight simulator.
* '''MathWorks''' provides the [http://www.mathworks.com/access/helpdesk/help/toolbox/aeroblks/ Aerospace Blockset] libraries for interfacing FlightGear to their Simulink software.
* '''NASA/Ames Human Centered System Lab''' - 737NG full scale cockpit simulator developed by [http://www.lfstech.com LFS Technologies]. FlightGear provides visuals for four large screen wrap around displays, improved turbo-fan math models, detailed fuel system models, and extendable network interface to cockpit displays and electronics. <ref>[http://human-factors.arc.nasa.gov/ihi/hcsl/publications.html Human Centered System Labs], NASA</ref>
* FlightGear was used by '''Pragolet s.r.o.''' in a motion platform based flight simulator of light and ultra-light sports aircraft. <ref>{{cite web |url=http://www.pragolet.cz/clanky/flight_simulator_of_light_and_ultralight_aircraft.html |title=Simulator of a Light and Ultra-Light Sport Aircraft |last=Thöndel |first=Evžen |date=29 January 2009 |publisher=Pragolet }}</ref>
* '''ATC Flight Simulator Company''' builds FAA approved flight simulators, that use FlightGear for the visuals.<ref>{{cite web |url=http://www.atcflightsim.com/ |title=ATC Flight Simulator }}</ref>
* '''ActiveFly''' has a worldwide unique paragliding simulator. FlightGear is used to provide the visuals. "In order to make practicing with the ActiveFly Simulator as realistic as possible, the harness as well as the risers and brakes are suspended below a frame in such a way that they can be operated"<ref>[http://www.activefly.com ActiveFly.com]</ref>
** [http://www.youtube.com/watch?v=YFcHebPaiEs Video] (YouTube)
* FlightGear was used to give a 3D visualiziation of a simulation by '''Robert Heffley Engineering'''. The simulation was used to examine the use of a Task-Pilot-Vehicle (TPV) model as a tool for flight simulator math model development.<ref>{{cite web |url=http://pdf.aiaa.org/getfile.cfm?urlX=6%3A7I%276D%26X%5BRW%2CS%20CIP4S%5EQ%3AO%224ZT%27%5FP%20%20%0A&urla=%26%2AR%28%27%230%2AC%0A&urlb=%21%2A%20%20%20%0A&urlc=%21%2A0%20%20%0A&urld=%28%2A%22P%26%22%406CTA%20%20%0A&urle=%28%2A%22H%23%230%22DU1X%20%0A |title=Use of a Task-Pilot-Vehicle (TPV) Model as a Tool for Flight Simulator Math Model Development |date=2-5 August 2010 |author=Heffley R.K. |publisher=American Institute of Aeronautics and Astronautics |acessdate=16 August 2012 }}</ref>
* Dutch roadable autogyro manufacturer '''PAL-V Europe NV''' uses FlightGear to provide the visuals and terrain data for their simulator. The simulator is currently used to prepare the test pilot and evaluate design options, but may be used to train customers in the future.<ref>{{cite web |url=http://pal-v.com/licenses/the-pal-v-simulator/ |title=The PAL-V simulator}}</ref>
* The '''Max Planck Institute for Biological Cybernetics''' of Germany uses FlightGear in several simulation environments:
** HeliLab<ref>{{cite web |url=https://www.cyberneum.de/27133/helilab |title=HeliLab (Tiled Display)}}</ref>
** MPI CyberMotion Simulator <ref>{{cite web |url=http://www.cyberneum.de/de/labore-forschung/cmslab.html |title=Der MPI-CyberMotion-Simulator}}</ref>
* The West Virginia based '''Institute for Scientific Research''' used FlightGear to perform simulated flight testing of the avionics and control system of a small autonomous UAV.<ref>{{cite web |url=ftp://ftp.uni-duisburg.de/pub/FlightGear/Docs/AIAA-2005-7083.pdf |title=Simulated Flight Testing of an Autonomous Unmanned Aerial Vehicle Using FlightGear |date=September 2005 |author=Eric F. Sorton, Sonny Hammaker }}</ref>
* '''Simuladores Guaraní''' in Argentina offers flight training devices running on FlightGear.<ref>{{cite web |url=http://simuladoresguarani.com.ar/|title=Simuladores Guaraní}}</ref>

=== ARINC ===
Todd Moyer of Aeronautical Radio, Incorporated (ARINC) used FlightGear as part of an effort to test and evaluate Flight Management Computer avionics and the corresponding ground systems. Certain capabilities of the Flight Management Computer are only available when airborne, which is determined by the FMC according to data it receives from GPS and INS sensors.

They wrote additional software that translates the NMEA output of FlightGear (including latitude, longitude, and altitude) into the ARINC 429 data words used by GPS and INS sensors. These data words are fed to the Flight Management Computer. the position information from FlightGear is realistic enough to convince the FMC that it is actually airborne, and allows ARINC to test entire `flights' with the avionics.

=== RWTH Aachen research simulator ===
The '''Institute of Aerospace Engineering''' at the RWTH Aachen is using FlightGear to drive the cockpit and the visuals of a general aviation simulator for training and research purpose. Micro Air Vehicles are being implemented by MATLAB/Simulink flight dynamics models; all I/O-related tasks, be they required by FDM, controls or instruments, are connected over network, using FlightGear native interfaces. <ref>http://www.dynamik.rwth-aachen.de/English/Simulators</ref>

=== Endless Runway Project ===
The '''Endless Runway Project''' is a consortium of aerospace instutes from France, Germany, the Netherlands, Poland and Spain. "The fundamental principle of The Endless Runway is that the aircraft take-off and land on a large circular structure. This will allow for the unique characteristic that the runway can be used in any wind direction, thus making the runway independent of the direction of the wind and therefore also the airport capacity independent of the wind direction."<ref>{{Cite web |url=http://endlessrunway-project.eu/downloads/d3.2-aircraft-aspects.pdf |title=Aircraft aspects of the Endless Runway |date=30 September 2013 |accessdate=16 January 2014}}</ref>

FlightGear and JSBSim were extensively used to simulate the landing and take-off performance of large aircraft on a circular runway. By using FlightGear, the consortium was able to select the radius, width and curvature of the runway.

More information and documents can be found at [http://endlessrunway-project.eu endlessrunway-project.eu]

== Universities ==
=== Africa ===
* The '''Minia University''' in Egypt developed a virtual lab with MATLAB and FlightGear. "It can be used easily by students to study and visualize classical control principles using FlightGear and MATLAB GUI with an attractive case study of a flight control system."<ref>{{cite web |url=http://www.researchgate.net/publication/236174210_automatic_control_education_using_flight_gear_and_matlab_based_virtual_lab/file/3deec5245860723ce4.pdf |title=Automatic control education using FlightGear and MATLAB based virtual lab |date=May 2012 }}</ref>

=== Asia ===
* The Department of Aircraft and Aeroengine from the Chinese '''Air Force Engineering University''' conducted a study on a new airworthiness compliance verification method based on pilot-aircraft-environment complex system simulation.<ref>{{Cite web |url=http://ac.els-cdn.com/S1000936111604342/1-s2.0-S1000936111604342-main.pdf?_tid=d3518780-834d-11e2-ba1b-00000aab0f26&acdnat=1362238285_cf85b59c1b58215e2a1559b6f42867aa |title=Airworthiness Compliance Verification Method Based on Simulation of Complex System |date=12 January 2012 |author=XU Haojun, LIU Dongliang, XUE Yuan, ZHOU Li, MIN Guilong |publisher=Chinese Journal of Aeronautics}}</ref>
* The Malaysian '''Universiti Teknologi Malaysia''' uses FlightGear for several projects.<ref>http://www.youtube.com/user/isfarazi</ref>
* The '''Nanjing University of Aeronautics and Astronautics''' in China made a 3D surface movement simulation system for [http://en.wikipedia.org/wiki/Advanced_Surface_Movement_Guidance_and_Control_System A-SMGCS] with FlightGear. The system displays ADS-B data in FlightGear through the multiplayer system and accurately predicts the aircraft's and/or vehicle's attitude (this is absent in ADS-B).<ref>{{cite web |url= http://www.joca.cn/EN/abstract/abstract16042.shtml|title=3D simulation of A-SMGCS surface movement based on FlightGear |date=16 May 2012 }}</ref>
* FlightGear was interfaced to MATLAB by the '''Indian Institute of Technology''' to develop a Vision-in-the-Loop Simulation facility for UAV landings.<ref>{{Cite web |url=http://www.ifac-papersonline.net/Detailed/64832.html |title=Vision Based Alignment to Runway During Approach for Landing of Fixed Wing UAVs |author=Marianandam, Peter Arun; Ghose, Debasish |date=2014}}</ref>
* The Chinese '''Shenyang Institute of Automation'''established a simulation system based on FlightGear and Matlab to validate a path planning method based on linear programming. The simulation results demonstrate the effectiveness and efficiency of this approach and the real flight test is under development.<ref>{{Cite web |url=http://ojs.unsysdigital.com/index.php/just/article/view/2 |title=LP Based Path Planning for Autonomous Landing of An Unmanned Helicopter on A Moving Platform |author=Chong Wu, Juntong Qi, Dalei Song, Jianda Han |date=24 May 2013 |publisher=Journal of Unmanned System Technology}}</ref>

=== Australia ===
* FlightGear was used by '''RMIT University''' in Melbourne, Australia to simulate the response to control inputs of a tethered kite system.<ref>{{cite web |url=https://researchbank.rmit.edu.au/eserv/rmit:160101/Thorpe.pdf |title=Modelling and Control of Tethered Kite Systems for Wind Energy Extraction |last=Thorpe |first=Dylan |date=April 2007 }}</ref>

=== Europe ===
* The '''University of Naples''', Italy used FlightGear in a six degrees of freedom (6dof) motion simulator, serving as a research and training tool.<ref>{{cite web |url=http://wpage.unina.it/agodemar/DSV-DQV/AIAA_MST_2007_DeMarco_Coiro_Nicolosi_paper.pdf |title=A 6DOF Flight Simulation Environment for General Aviation Aircraft with Control Loading Reproduction |last=Coiro |first=Domenico P. |coauthors=De Marco, Agostino; Nicolosi, Fabrizio |date=2007 }}</ref>
* The Intelligent Robotics Group at the '''University of Wales''', Aberystwyth, UK is using FlightGear as part of their aerobot research<ref>[http://users.aber.ac.uk/dpb/aerobots.html Aerobot Research], Dave Barne</ref> to design aerial vehicles that can operate in the atmosphere of other planets.
* '''Delft University of Technology''', the Netherlands
** FlightGear was used for the ICE project. The goal was to design, test, and evaluate computational techniques that can be used in the development of intelligent situation-aware crew assistance systems. Using methods from artificial intelligence, ICE focused primarily on the data fusion, data processing and reasoning part of these systems. <ref>{{cite web |url=http://www.kbs.twi.tudelft.nl/Research/Projects/ICE/index.html |title=The Intelligent Cockpit Environment (ICE) Project |last=Ehlert |first=Patrick |date=18 January 2005 |publisher=TU Delft }}</ref><ref>{{cite web |url=http://mmi.tudelft.nl/pub/patrick/Ehlert.P.A.M-GAMEON2002.pdf |title=Recognising situations in a flight simulator environment |date=November 2002 |author=Ehlert P.A.M., Mouthaan Q.M., Rothkrantz L.J.M. |accessdate=18 April 2012 |publisher=SCS Publishing House }}</ref><ref>{{cite web |url=http://www.kbs.twi.tudelft.nl/People/Students/D.Dragos/back/ice/index.htm |title=The ICE Project |author=Datcu Dragos |date=January 2003 |accessdate=8 May 2012 }}</ref>
** FlightGear is often used to provide the visuals on [http://www.lr.tudelft.nl/en/cooperation/facilities/simona/the-simona-research-simulator/ SIMONA], a 6-DOF research flight simulator. For example:
*** Study on whether simulator-based training of pilot responses to unexpected or novel events can be improved by including unpredictability and variability in training scenarios.<ref>{{cite web |url=https://journals.sagepub.com/doi/pdf/10.1177/0018720818779928 |title=Training Pilots for Unexpected Events: A Simulator Study on the Advantage of Unpredictable and Variable Scenarios |first=Annemarie |last=Landman |date=September 2018}}</ref>
* The German based '''Hamburg University of Applied Sciences''' used JSBSim and FlightGear to evaluate the handling qualities of a box wing aircraft.<ref>{{cite web |url=http://www.fzt.haw-hamburg.de/pers/Scholz/Airport2030/Airport2030_PUB_DLRK_12-09-10_Caja.pdf |title=Box Wing Flight Dynamics in the Stage of Conceptual Aircraft Design |author=Caja R., Scholz D. |date=23 November 2012}}</ref>
* For studentproject Daedalus, the Technical University of München uses FlightGear to optimize the flight characteristics of a zeppelin as well to simulate its performance. Another goal is to simulate prerecorded flights from a real model for further analysis. <ref>{{cite web |url=http://www.daedalus.ei.tum.de/index.php/de/mach-mit-mm |title=Mach mit ! - daedalus}}</ref>
* The '''Czech Technical University in Prague''' is working on a full motion simulator to do research on situation awareness. They're using FlightGear for the visuals. A video of the simulator can be seen [http://www.youtube.com/watch?v=d8SQa9_el8k&feature=autoshare at YouTube]. More info at http://measure.feld.cvut.cz/en/cast
* '''French Aerospace Lab (ONERA)''' and '''University of Toulouse''', France (2004). A thesis student Frédéric Dehais has used FlightGear and developed a cognitive counter-measures experimental environment (p.119 and following) to show the pilot/ATC scheme could be formalized and enhanced to avoid cognitive perturbation. Use of Atlas and Onera Messenger. Over 22 real-life pilots have been testing this environment.<ref>{{fr}} {{cite web |url=http://oatao.univ-toulouse.fr/2137/1/Dehais_2137.pdf |title=Modélisation des conflits dans l’activité de pilotage |first=Frédéric |last=Dehais |publisher=University of Toulouse |date=21 June 2004}}</ref>
* '''Pázmány Péter Catholic University''' and the '''Hungarian Academy of Sciences''' developed a collision avoidance system for UAVs using visual detection. The system was simulated with FlightGear serving the visuals.<ref>{{cite web |url=http://www.analogic.sztaki.hu/publications/UAV_Collision_avoidance.pdf |title=Collision avoidance for UAV using visual detection }}</ref>
* The '''University of Sheffield''', England, modeled and simulated a small UAV in FlightGear and JSBSim. The report describes the whole process of creating an UAV for use in FlightGear.<ref>{{Cite web |url=http://www.dcs.shef.ac.uk/intranet/teaching/public/projects/archive/msc2006/pdf/acq05taa.pdf |title=Modelling and Autonomous Flight Simulation of a Small Unmanned Aerial Vehicle |date=August 2006}}</ref>
* A MOOC on aerodynamics made by the French School '''Supaéro''' uses FlightGear.<ref>{{Cite web | url=https://www.france-universite-numerique-mooc.fr/courses/isaesupaero/25001/Trimestre_4_2014/about | title=Aerodynamics MOOC using FlightGear|date=February 2015}}</ref>
* '''Durham University''' in England has been using FlightGear as a test bed for developing fault detection and self-healing systems in aircraft.<ref>{{cite web|url = http://dro.dur.ac.uk/17084/1/17084.pdf|title = FlightGear as a tool for real time fault-injection, detection and self-repair|author = Alan Purvis|coauthors = Ben Morris; Richard McWilliam|date = 2015|publisher = Durham Research Online|format = PDF}}</ref>
* '''Cranfield Univeristy''' in the United Kingdom used FlightGear to visualize an airport environment which was then overlayed by a guidance system on a HUD. [[TerraGear]] and [[TerraGear GUI]] to generate the scenery.<ref>{{cite web |url=https://core.ac.uk/download/pdf/20338967.pdf |title=Aircraft head-up display surface guidance system |author=Jinxin Gu |date=November 2013}}</ref>

=== North-America ===
* '''University of Illinois''' at Urbana Champaign. FlightGear is providing a platform for icing research for the Smart Icing Systems Project. <ref>http://www.aae.uiuc.edu/sis/mainpapers.html</ref>
* '''Simon Fraser University''', British Columbia Canada. Portions of FlightGear were used in simulation to develop the needed control algorithms for an autonomous aerial vehicle.
* '''Iowa State University'''. A senior project intended to retrofit some older sim hardware with FlightGear based software.
* '''University of Minnesota''' - Human Factors Research Lab. FlightGear brings new life to an old Agwagon single seat, single engine simulator.
* FlightGear is being used as the basic framework to provide the UTC Challenger Center (and hopefully other centers in the future) a low cost virtual reality computer simulation in the '''University of Tennessee''' at Chattanooga. Our simulation is using flightgear and JSBSim, specifically the shuttle module, to develop a shuttle landing simulator. Currently, we are trying to get to the point of at least contributing instructions on how to interface our virtual reality hardware with Flightgear back to the OS community.<ref>{{cite web |url=http://www.flightgear.org/Projects/utc.html |title=University of Tennessee at Chattanooga |publisher=FlightGear |first=Dawn |last=Ellis |accessdate=18 April 2012}}</ref>
* '''Department of Aerospace Engineering at The Pennsylvania State University''' used FlightGear primarly for its graphics engine, in advanced research programs in the areas of flight control design, advanced rotorcraft flight dynamics modeling, and near real-time acoustics simulation.<ref>{{cite web |url=http://www.fkm.utm.my/ftp/pub/OSS/Win32/FlightGear/paper_PSU_2004AHS.pdf |title=A Multi-Disciplinary Rotorcraft Simulation Facility Composed of Commodity Components and Open Source Software |publisher=Department of Aerospace Engineering, The Pennsylvania State University }}</ref>
* A team of '''Northeastern University''' (Boston, USA) engineering students has developed a system that allows a pilot to fly a simulated airplane in FlightGear, using nothing more than his or her brainwaves.<ref>{{cite web |url=http://www.northeastern.edu/news/stories/2011/05/braincontrol.html |title=A brainy innovation takes flight |publisher=Northeastern University |date=31 May 2011 }}</ref>
* '''Arizona State University''' (USA) used a combination of engineering programmas (among which FlightGear) in its aerospace engineering program. The faculty shifted how they were teaching to put less focus on theory and more emphasis on simulation and visualization through the immediate use of engineering software. Students used those programms within [[MATLAB]].<ref>[http://campustechnology.com/Articles/2011/08/23/Arizona-State-Tries-Practice-over-Theory-in-Engineering-Education.aspx Arizona State Tries Practice over Theory in Engineering Education], Campus Technology</ref>
* A project by the '''University of Montreal''' and the '''University of Toulouse''' used FlightGear to visualize the effect of an active freedback system for pilot guidance assistance.<ref>{{cite web |url=http://pdf.aiaa.org/getfile.cfm?urlX=6%3A7I%276D%26X%5BRO%23S%20%27MP4S%5EQ%3AG%224%2A%28%21%5F%40%20%20%0A&urla=%26%2AR%28%27%230%2AC%0A&urlb=%21%2A%20%20%20%0A&urlc=%21%2A0%20%20%0A&urld=%28%2A%22P%26%22%406BUQ8%20%0A&urle=%28%2A%22H%23%230%22DU1X%20%0A |title=Preliminary Study of an Active Feedback System for Aircraft Guidance |date=13-16 August 2012 |author=Latorre-Costa P., Defay F., Saussi�é D. |publisher=American Institute of Aeronautics and Astronautics |accessdate=16 August 2012 }}</ref>
* The Center for Coastal & Ocean Mapping/Joint Hydrographic Center at the '''University of New Hampshire''' set up a ship simulator using FlightGear for the visuals.<ref>{{cite web |url=http://ccom.unh.edu/vislab/projects/simulator.html |title=Spatially Aware Hand-held Devices and the Boat Simulator |accessdate=20 October 2012 }}</ref>
* The '''University of Michigan''' used FlightGear to validate PID autopilot for unmanned aerial vehicles.<ref>{{Cite web |url=http://www-personal.umich.edu/~duncanlm/Miller_Duncan_AIAA_RegionIII_2011_Autolab.pdf | title=Autonomous Vehicle Laboratory for Sense and Avoid Research and Hardware-in-the-Loop Simulations |publisher=American Institute of Aeronautics and Astronautics |author=Duncan Miller |date=2011 |format=pdf}}</ref>
* FlightGear was used by the '''University of Toronto Institute for Aerospace Studies''' to simulate [[UTIAS Ornithopter No.1|their first ornithopter]] (engine powered).<ref>{{Cite web |url=http://www.ornithopter.net/MediaGallery/flightgear_e.html |title=Flying the Ornithopter in FlightGear Flight Simulator |author=Project Ornithopter |date=2006 |format=html }}</ref> In 2010 the team made aviation history when their second ornithopter became the first human-powered ornithopter to make a sustained flight.<ref>{{Cite web |url=http://media.utoronto.ca/media-releases/new-media-technology/human-powered-ornithopter-becomes-first-ever-to-achieve-sustained-flight/ |title=Human-powered ornithopter becomes first ever to achieve sustained flight |publisher=University of Toronto |date=22 September 2010 }}</ref>
* '''Purdue University''', Indiana visualized scenarios involving cyber attacks in FlightGear to demonstrate the vulnerabilities of current UAV autopilot systems.<ref>{{cite web |url=http://www.syprisresearch.com/Images/secure-control-systems/AIAA-Infotech_Threats-and-Vulnerabilities-Analysis.pdf |title=Cyber Attack Vulnerabilities Analysis for Unmanned Aerial Vehicles}}</ref>
* A thesis at the '''University of Arizona''' involved using FlightGear to enhance the ArduPilot autopilot of an UAV to detect and capitalize upon rising air.<ref>{{Cite web |url=http://arizona.openrepository.com/arizona/handle/10150/297776 |title=Thermal Energy Extraction Methods for UAV Gliders |author=Umashankar, Rohit |date=30 April 2013 }}</ref>

=== South-America ===
* The '''Aeronautical Engineering University''' of Argentina uses FlightGear to display the outside view of their simulator. Pictures can be seen at http://gsdv.com.ar/fotos/20110528/index.html.
* Brazilian '''Universidade Federal de Minas Gerais''' compared Microsoft Flight Simulator X to FlightGear for use in an UAV simulation. The authors concluded that, although the two sims were considerably close to each other, FlightGear is the better option for research, due to its flexible and open character and the higher frequency at which the simulation could run (independent of the visual frame rate).<ref>{{cite web |url=http://homepages.dcc.ufmg.br/~chaimo/public/SBAI09-cantoni.pdf |title=Analise Comparativa Entre Microsoft Flight Simulator E Flightgear Flight Simulator Em Testes Hardware-In-The-Loop }}</ref>

== Home built applications ==
* '''Team Viper''' built a 360 degrees roll and pitch simulator, that runs on FlightGear.<ref>{{cite web |url=http://www.the-viper.org/ |title=TheViper }}</ref>
* '''John Wojnaroski''''s 747 cockpit is a long time project.<ref>http://www.flightgear.org/Projects/747-JW/</ref>

{{Appendix|all|
* {{cite web |url=http://www.usenix.org/events/usenix04/tech/sigs/full_papers/perry/perry_html/Applications_Simulator.html |title=Applications for the Simulator |last=Perry |first=Alex }}
----
{{References||2}}
}}

[[Category:FlightGear]]