FlightGear wiki - User contributions [en]

Howto:Make nice screenshots

2015-06-02T19:02:53Z

Zlsa: Rewrote and updated old page

{{mergefrom|Submitting Screenshots|Howto talk:Make nice screenshots#Merging Submitting Screenshots into this page|date=January 2014}}

This [[:Category:Howto|howto]] will explain '''how to make nice screenshots''' in [[FlightGear]].

== Basics ==

What separates good pictures from bad pictures?

Good pictures
* Appeal to us in some way, by telling a story, revealing something unexpected, or showing an interesting point of view.
* Encourage us to look at them for more than just a second, searching for more details. A good screen-shot can invite us to think about how it was made, maybe even inspire us to create images of our own.

The best screenshots are technically correct, the lighting and colors are right, and the composition is good.

Explaining how to compose a picture is difficult, so instead I suggest you to read tutorials and explanations given on many websites on the web like this one: [http://en.wikipedia.org/wiki/Composition_(visual_arts) Composition (visual arts)].

== Quality ==
From a broader perspective, it would be desirable if new screenshots could also showcase new FlightGear's capabilities using high quality settings. Say someone googles "VFR guide" because he wants to know something about VFR flying and comes across a bunch of screenshots of FlightGear - we'd really want to impress here so that user gets curious and tries FlightGear. Back when there were still manuals, all most simulators (Falcon 4.0 for instance) had the highest detail level for all the internal screenshots, not the lowest. So that's something to keep in mind when showcasing FlightGear.

A good virtual picture needs a good quality. That means:
* [[Anti-aliasing|Enabling AntiAliasing]] (AA)
* Appealing/true colors
* Size of the picture- not too small, not to big
* No Gui/Menu/FPS counter etc. visible
* Full effects

This means you need a decent computer with middle - good specs. At a minimum, you should able to run Flightgear with smooth framerate with high antialiasing settings.
Some people don't have this, so there is another solution proposed by Melchior Franz : [http://www.opensubscriber.com/message/flightgear-devel@lists.sourceforge.net/8196594.html].

== How to get some unusual/ interesting views ==
To get some ideas, it's a good idea to look for aircraft picture pages around the web like [http://www.airliners.net Airliners.net]. It will give you some ideas, and in addition, it is always a good idea to think about what you actually want to show case. While a snapshot of an airliner in mid flight is -for instance- a nice way of showing its latest features on the forum, it typically doesn't really last as an overall impressive screen shot. Placing the aircraft in a scene where some implied action is taking place will most of the time already make a huge difference. Capture the plane while it's banking, gear is retracting, etc. will imply some dynamic motion in your otherwise static image. In this respect, it may help to think of a little story, a scenario that you're reenacting. Trying to capture a few key scenes from a flight may also help to make the difference between an average and an interesting screen shot.

=== Air to Air ===
* '''Helicopter View:''' This assumes that you are in a virtual, invisible helicopter besides the aircraft. You are always flying level. With the mouse you can choose the position of the "helicopter".
* '''Chase View:''' This assumes you are chasing the aircraft. It is very similar to the first one.
* '''Chase View with yaw:''' Also chasing the aircraft, but the virtual camera doesn't turn with the aircraft.
Try switching between them to see what you like more(I prefer Chase view). Playing around with position of the camera will help too. As an example if the aircraft is turning and banking, make a shot from the wing to the aircraft facing the ground. Or while approaching the runway, a shot from behind the aircraft would be good.

=== Ground to Air ===
[[File:Wiki PlaceTower.jpg|thumb|270px|Setting the Tower on top of the mountain looking down to the airport with the [http://www.gidenstam.org/FlightGear/misc/place_tower.xml Place_Tower.xml]]]

For this we use the Tower view and Tower View look from. This assumes that the virtual camera is on the Airport Tower, ca. 30ft above the airport level. You can choose via the Menu which airport is used. That's nice, but limited.

Anders Gidenstam made a nice nasal script to move the tower whenever you control-click on the ground.
You can find it [http://www.gidenstam.org/FlightGear/misc/place_tower.xml here]. Copy the code between the <code><PropertyList></code>-tags and put in somewhere in your <code>preferences.xml</code> . Now, when you ''Ctrl + left click'' somewhere on the ground, you can set the position of the tower view. The view is still about 30 feet above ground level; assuming you want to stand at eye-level, you can change the line

setprop(tower ~ "/altitude-ft", 30 + MtoFT * click_pos.alt());

to

setprop(tower ~ "/altitude-ft", 6.5 + MtoFT * click_pos.alt());

=== Panorama ===
[[File:Fgfs-screen-560 stitch2.jpg|thumb|600px|180 degree panorama stitched with 20 images inside the C172P cockpit while flying above custom scenery for South France]]

A [http://en.wikipedia.org/wiki/Panorama panorama] is a wide-angle view. With this, you can show large areas of the scenery or flightdecks.

For this, use the cockpit, passenger, or tower view, then position the virtual camera at the point you want. Pause the sim and pan the virtual camera all the way around, saving many screenshots so they cover the entire visible area.
Now use your favourite panorama software and stitch it!
No software yet? Use Google; there are several freeware-programs outside. A common choice is [http://hugin.sourceforge.net/ Hugin]; it's free and open source, cross-platform and used by many professional photographers.

If you want to make full spherical panorama take a look at this [http://wiki.flightgear.org/index.php/Howto:_Make_full_spherical_panorama tutorial].

== Field of View (FoV) ==
[[File:wiki_FoV.jpeg|thumb|270px|The difference of wide/narrow angle. See how the background changes using a zoom.]]

You can change this by pressing {{Key press|Shift|X}} or {{key press|X}} or using the Mouse-wheel in View-mode.
The field of view is by default set to 55 (degrees).

Increasing the field you get wide angle up to 120 degrees. That's interesting as it covers a whole part of the scenery but also seems to make objects appear far away. Use it for showing large parts of sceneries, or long aircraft, etc. Another interesting feature of using a wide angle is that it exaggerates perspective. One effective use of this consists of using a wide angle lens combined with placing the camera near the object. This will make the object in question appear larger, more impressive than it really is. For an higher, wider angle make a panorama.

Decreasing the field you get a narrow angle and a zoom-effect. This means you can take far away objects virtually close to you. An interesting effect is, that it also makes the background more "dense". Another interesting side effect is distance foreshortening, meaning that the distance between various object is becoming compressed, suggesting less space between objects than there really is.

== Lighting and Daytime ==
[[File:Wiki low sun shaders.jpg|thumb|270px|Showing the effect of the low sun and the water shaders]]

The most appealing photos in real life are made in the morning or evening. The light has a warm color and the shadows and ambient colors are soft and long which gives fantastic impressions. The noon gives hard shadows and strong contrasts, which are hard to deal with.

This applies to FlightGear as well. So play a bit with the time of day, especially Dawn/Morning/Afternoon and Dusk. Play with the seasons and locations as well. In the winter near the poles, the sun is low, while near the equator the sun is standing high in the sky. As an example, this gives nice effects with the water shaders.

== Weather ==
Our weather has improved much with the addition of [[advanced weather]]. To enable it, you must open the Environment > Weather dialog, then check "Advanced Weather" and click "OK". With advanced weather enabled, clouds are placed while taking the terrain and wind patterns into account, making for much more realistic cloud and weather patterns. Advanced weather works best with [[atmospheric light scattering]] enabled as well.

== Locations ==
The choice of the location depends a bit what you want to show. So what want you to show? Do you have already a theme in mind?

As an example for showing an aircraft just for presentation, use an "empty" background like the sky, sea or desert. If you want to show the aircraft during operation you could choose some of FlightGear's better airports like [[EHAM]], [[LFPG]] as the background, or some of the more detailed custom sceneries.

== Colors and whitebalance ==
As in real life, in FGFS the pictures often have to be corrected in colors and whitebalance. This can be done with almost any image editor. In [http://www.gimp.org GIMP] this can be done through <tt>Layers > Colors > Brightness and contrast</tt>.

== Conclusion ==
When keeping this all in mind, you can make some stunning pictures. Try and play with as much you can, look at real images to get hints or try to copy a real life image in FlightGear. All this will help you to take good pictures!

[[Category:Howto|Make nice screenshots]]

ALS technical notes

2015-03-18T04:35:26Z

Zlsa: Separated glass and interior effects

== Quality level mapping ==

The rendering quality of ALS effects is controlled by two main sliders, landmass effects and transition effects. Transition effects regulate overlay texturing quality whereas landmass effects regulate all other aspects of procedural texturing like pixel color postprocessing (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...) and models in the scene can be switched on separately. In some cases this may be needed for a consistent visual impression: If a dust effect is used on the terrain, 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, i.e. transition quality level 6 won't have any effect unless landmass quality is also level 6.

=== Transition ===

The mapping of quality to visuals of the transition slider is

1:
* Base texture scheme
2:
* Alternative hires airport keep effect
3:
* Base and overlay texture, runway effect (if landmass > 4)
* Supports secondary lights on runway and airport keep
4:
* Base, overlay and hires texture
6:
* Base, overlay, hires, detail, grain, dot and rock texture (if landmass > 6)

=== Landmass ===

(Quality levels 1 and 2 are reserved to represent fixed pipeline rendering and the classic FG default renderer in an eventually merged rendering GUI, currently however ALS is switched on per checkbox and not by quality level, so they do not have a function).

3:
* ALS-rendered position-differential haze and light, moonlight

4:
* Procedural snow cover on terrain
* Procedural dust and vegetation effects
* Wet terrain effect with approximate reflection half vector
* Patchy fog distribution

5:
* Noise bump-mapping and parallax mapping of terrain

6: (requires transition 6 as well)
* 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'd be from cockpit view). In other words, this is not a full (rather expensive) computation of light volumes as Rembrandt does it but a much faster test of illuminated screen areas.

[[File:Landing light03.jpg|400px|Cessna 172 p 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 '''/sim/rendering/als-secondary-lights/'''.

The names of the properties should be self-explanatory, if for instance if '''use-searchlight=true''' then the searchlight (which always follows the current view axis) is used.

The properties '''landing-light1-offset-deg''' and '''landing-light2-offset-deg''' 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.

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

== The grain texture and the rain effect ==

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 cm-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 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 < 0, the grain resolution is lower than the base layer, if the parameter is > 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).

Finally, 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]]

== 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 Environment/aircraft-effects. Derived effects should inherit from Effects/glass.

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.

=== Internal cockpit reflection ===

There is support for a reflection of the cockpit interior. 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 the xml to use for the inheritance looks like this:

<syntaxhighlight lang="xml">

<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>
</syntaxhighlight>

=== 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 environment/aircraft-effects/ground-splash-norm (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 environment/aircraft-effects/splash-vector-x (splash-vector-y, splash-vector-z). These are likewise in model coordinates.

As long as the length of the splash vector is <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 (do not mindlessly copy and expect to work for any aircraft - it won't!)

<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.0 * 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.0);
}
</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.

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

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 /environent/aircraft-effects/use-wipers.

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 /environment/aircraft-effects/overlay-alpha, 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]]

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

== Interior shading ==

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.
This is typically created in an effect file such as

c172-interior.eff

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

ie:

<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. 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) Aircraft with solid bottom n/a. Aircraft with light penetrating bottoms, tbd.

[[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.

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

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

[[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>]].

=== General comments from forum discussion ===

{{FGCquote
|A few aircraft have a fake shadow, in essence a flat silhouette of the aircraft floating maybe a feet above ground. The silhouette get there using a few properties, possibly driving some calculations and basically the same kind of animations as is used to for example animate the control surfaces. I do not remember having seen a list with aircraft using a fake shadow, but I think that for example Helijah's Diamond twin has one. The big drawback with a fake shadow is that it has to float to not get broken through by even the slightest undulations in the ground, while still will not work as soon as there is a slope.|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859#p227134
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Johan G</nowiki>
|date=<nowiki>Mon Dec 15</nowiki>
}}
}}

{{FGCquote
|As the tree shadow code has shown, it's near-trivial to do the projective geometry not by an animation but in the vertex shader, i.e. fake shadows can be placed where the sun casts them, stretched by the projection, depth adjusted to weather condition and if the current terrain normal is passed, they can even be put co-planar with the local triangle, i.e. they'd project correctly even on sloped runways and terrain.

At a computational cost of almost zero, because you just process the four vertices of the shadow quad, and four is a number which isn't even a warm-up exercise for a GPU used to crunch millions of vertices. But of course, it wouldn't be a real shadow, in particular it wouldn't project correctly onto trees and buildings as a stencil buffer or shadow map solution would.|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859#p227202
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Mon Dec 15</nowiki>
}}
}}

{{FGCquote
|Having said that, it is fairly simple to do. Here's an implementation for the EC-130 which comes with an animation based fake shadow out of the box, switching the shadow projection to a GLSL shader:
The animation just puts the shadow onto the ground. The GLSL code can do some projection of the shadow, i.e. it magnifies a bit for low sun and changes position:
The shader can do a full light calculation of the surrounding scene, so the depth of the shadow can be varied according to the ambient to diffuse light balance:
Also, once the aircraft is in the air, it projects the shadow along the light ray rather than underneath the aircraft:
And of course, all that means shadow depth adjusts to weather conditions - no shadows in overcast skies:
Implementation (using current git) - make the quads displaying the fake shadow inherit from Effects/shadow.eff, don't translate the shadow (the shader expects it to be correctly positioned for the sun in the zenith for an aircraft standing on the runway), don't try to correct for low sun or to adjust shadow texture transparency, the shader just uses the texture alpha channel.|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859#p227285
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Tue Dec 16</nowiki>
}}
}}

{{FGCquote
|
Where should I put this? Into one of the *.eff files of any aircraft?
-you need the shadow itself as a model (a textured quad). In ac3d (blender,...) that has an object name - in my example shadow_fuselage. You can give it any you want.

-in the aircraft-set.xml (or files included there), animations, effects, sounds,... are declared and models included. In the scope where your shadow quad is included, you declare shadow.eff as your effect. What wlbragg has has done (inheriting a copy of the shadow effect under the aircraft effect directory) is probably more by the book, but not strictly necessary unless you want to pass parameters to the effect.|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859#p230005
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Sat Jan 17</nowiki>
}}
}}

{{FGCquote
|It works with anything that sets a property how far the gear is off the ground - it works with your home-made Nasal FDM if you like...|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=30#p232080
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Sat Feb 14</nowiki>
}}
}}

{{FGCquote
|
wlbragg wrote in Sat Feb 14, 2015 1:14 am:
After looking at how slow altitude-agl-ft update is, I don't think it would work very well anyway.
I'll try the "property rule".
But now I am curious why I couldn't get altitude-agl-ft to work at all?

If altitude-agl-ft seems to update slowly in the property browser it might be a tied property that can't be listened to so instead it is polled at a lower rate - but the property will actually be updated for each frame or FDM iteration.
This might also explain why you have problems getting its value into the effect - the effect system might also rely on listeners to get updates (I don't know).|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&p=232163#p232091
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>AndersG</nowiki>
|date=<nowiki>Sat Feb 14</nowiki>
}}
}}

{{FGCquote
|Yes - you can't pass tied properties to effects. Learned that one the hard way (took me a while to figure out...) That's probably the problem here as well. Okay, then we need an aircraft-side property rule in any case.

It doesn't need to be AP (they're updated at FDM rate), we only need it at framerate. I vaguely remember there was a catch that you had to give an index to airplane-side property rules to avoid overriding the system-wide which do e.g. weather - there's documentation on the wiki somewhere, I think in the AP howto.|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&p=232163#p232093
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Sat Feb 14</nowiki>
}}
}}

{{FGCquote
|After setting up two separate aircraft with the simplified shadow effect, here is what I found to work best.
Simply put I used a property rule for for both YSim and JSBSim aircraft and override gear-agl-m with a filter passing altitude-agl-ft to gear-agl-m in both aircraft.
The reason for this is to accommodate all the shadow AGL adjustment needed for both ASL-shadows and non-ALS-shadows.

My Cub has two configurations for tire size and thus two different altitude-agl-ft starting points. The c172p also has its own altitude-agl-ft starting point. I guess they would be dependent upon where and how the model designer created the center point of the aircraft.
To accommodate this variability you need to do an offset in the shadow.xml to place the shadow's AGL where you want it. But when using ALS-shadow method it has a tendency to put it where it thinks it needs to go based on the hard code. So you use the offset to position the initial shadow. Then you use the property rule configuration to position the shadow when ALS method takes control of the shadow's AGL.|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=30#p232163
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>wlbragg</nowiki>
|date=<nowiki>Sun Feb 15</nowiki>
}}
}}

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

=== General comments from forum discussion ===
{{FGCquote
|In real-time 3d rendering in general. To be very fast, all tasks are parallelized, so the GPU can crunch every vertex and every pixel independent of what the others do. The price for that to work is that you track only the ray from light (L) to object (O) to eye(E), so if that's the relevant geometry, you don't need to know anything else of the scene, you can get all the reflection angles at the object in one go.
To place a shadow, you want to know whether the ray L-O intersects somewhere else before it illuminates, i.e. evaluate L-O-O-E - and that's no longer factorizable - now at one vertex, you need to know all the others. I.e. a GPU can't evaluate this (raytracing still can easily, but that doesn't run in real time...) - which is where we need various tricks.
Which range from very cheap (fake shadows) to very expensive (additional shadow camera or shadow volume creation and stencil buffer passes over the whole scene).
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=45#p232315
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Tue Feb 17</nowiki>
}}
}}

{{FGCquote
|Not an issue - shadow alpha is set by the fragment shader anyway based on time of the day and cloud cover (if there's lots of clouds, you get very faint shadows).
I think the issue is simple - multiple layers are visible where only one should be, so I need to do a first pass over just the shadow to fill the depth buffer and then draw the uppermost layer of the shadow in the second pass.
If the shadow volume really is a low poly version of the model, that should be really cheap (on the other hand, if it's a full multi-million poly replica, then... let's say you will notice...). Anyway, I didn't touch fragment work at all yesterday, I just wanted to sort out the geometry.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=75#p234088
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Thu Mar 05</nowiki>
}}
}}

{{FGCquote
|It's not a shadow, it's a squished volume flat on the ground. Don't fall into the trap of thinking of it as a shadow while developing.

Don't need it. Volume and texture shadow are only different at the vertex stage only - to determine the pixel color, we can follow precisely the same steps.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=75#p234132
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Thu Mar 05</nowiki>
}}
}}

{{FGCquote
|You have to make it.
It is the same thing as the 3d model of the aircraft except it is (hopefully) low poly. Meaning it has only what is needed to make a 3 dimensional shadow that looks like the original model without all the details (no interior, etc).
This is something that really should have been considered back at the beginning of the FG project. Modelers should have by default make LOD versions of their aircraft for various reasons.
You can't use the effect without it.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=90#p234163
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>wlbragg</nowiki>
|date=<nowiki>Thu Mar 05</nowiki>
}}
}}

{{FGCquote
|"I guess the effect cannot handle moving gear or tilting nacelles?"

I suspect right now no - animations seem to all go into the gl_ModelViewMatrix and currently the projection generating the shadow is applied before the matrix is multiplied. In principle, it's just a question of sorting the math out to do the projection in eye space, i.e. after applying gl_ModeViewMatrix - then the shadow reflects the state of the model after all animation have been carried out - and then do the projection transformation to screen space separately. I suspect it's ugly though, since the up-direction along which we determine where the ground is needs to be rotated as well, then we may have to do the roll/pitch transformations which make the shadow flat by hand,...

I have a suspicion it's more trouble than it's worth - it's the sort of thing you'll only notice if you go looking for it.

"IIRC in OpenGL it's not that necessary to create low poly LODs for your 3D model, someone correct me if I'm wrong here, but I recall this being mentioned more than once."

I think the definition of 'low poly' depends on your hardware. My current graphics card will happily crunch six million scenery vertices at a decent framerate, so it won't even notice whether you add a model with 1000 or 10.000 polygons. However, I assure you that you will feel the effect of adding a 3 million polygon shadow model to the scene.

So you shouldn't waste a lot of time in desperately driving polygon count down, but you should strip down the shadow model from the original where this is feasible, especially if the original has excessive polygon count.

It actually requires a depth buffer fill followed by a depth equality test, that renders one layer only.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=90#p234209
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Thu Mar 06</nowiki>
}}
}}

{{FGCquote
|Let me re-iterate that the shader does not use the transparency you set for the material - the rasterizer and z-buffer however may, leading to unexpected and difficult to track behavior. For the texture shadow, you should use texture alpha only to draw the outline of the shadow, and for the shadow volume you should for the moment not use material or texture alpha at all (at a later stage, I can add support for texture alpha). The shader should determine the correct alpha of the shadow output pixel on its own.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?f=47&t=24859&start=120#p234459
|title=<nowiki>Re: 2D shadow on ground?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Thu Mar 08</nowiki>
}}
}}

== Related content ==

* [[Procedural Texturing]]
* [[Atmospheric light scattering]]

[[Category:Shader development]]

List of developed airports

2015-03-13T22:27:48Z

Zlsa:

This is an incomplete '''list of developed airports''' in the FlightGear [[TerraSync]] scenery.

Airports can be listed here if these two conditions are fulfilled:
* At least one building or [[Signs|taxi signs]] have been placed
* Objects are represented in the [[FlightGear Scenery Database]].

Every improvement listed here should be possible to download using TerraSync. These improvements will also be included in the next [[World Scenery]] release.

__TOC__

== For airport developers ==
If you are currently developing an airport, please feel free to add it to [[Airports under construction]]. For a list of currently ongoing scenery related projects, please check out [[Current Scenery Projects]].

== List of airports ==
The ICAO codes link to the FlightGear mapserver, which - among other things - contains information about the current status of the [[FlightGear Scenery Database]]. On a map, you will see:
* The current airport layout with runways, taxiways and aprons
* Red dots: static objects in the scenery database made especially for this airport
* Dark red dots: shared models in the scenery database placed at this airport
* Green dots: [[Signs|taxi signs]] placed at the airport

{{inote|You can sort the table by clicking one of the [[File:Sort none.gif]] symbols in the row headers.}}

{| class="wikitable sortable" border="0" cellspacing="0"
|-
! ICAO !! Name !! Country !! Continent !! class="unsortable" | Comment

|-
| [http://mapserver.flightgear.org/map/?lon=13.76716&lat=51.13277&zoom=14&layers=B000000TFFFFTFFFTTFFF EDDC] || [[Dresden Airport]] || Germany || Europe || Fully modeled with tower, terminal, animated hangars etc.

|-
| [http://mapserver.flightgear.org/map/?lon=8.56293&lat=50.03795&zoom=14&layers=B000000TFFFFTFFFTTFFF EDDF] || [[Frankfurt am Main Airport]] || Germany || Europe || Fully modeled with [[Signs]] and [[Interactive Traffic]] and unique scycrapers downtown

|-
| EDDG || [[Münster Osnabrück]] || Germany || Europe || 1 static + 100 shared objects

|-
| EDDH || [[Hamburg Airport]] || Germany || Europe || Fully modeled, plus unique buildings downtown

|-
| [http://mapserver.flightgear.org/map/?lon=13.40379&lat=52.47502&zoom=15&layers=B000000TFFFFTFFFTTFFF EDDI] ||[[Berlin Tempelhof Airport]] || Germany || Europe || Fully modeled

|-
| EDDL || [[Düsseldorf International Airport|Düsseldorf Airport]] || Germany || Europe || Tower and terminal

|-
| [http://mapserver.flightgear.org/map/?lon=11.78609&lat=48.35378&zoom=14&layers=B000000TFFFFTFFFTTFFF EDDM] || [[Munich Airport]] || Germany || Europe || Fully modelled

|-
| [http://mapserver.flightgear.org/map/?lon=12.23603&lat=51.42262&zoom=14&layers=B000000TFFFFTFFFTTFFF EDDP] || [[Leipzig/Halle Airport]] || Germany || Europe || Fully modelled with [[Signs]]

|-
| EDDS || [[Stuttgart Airport]] || Germany || Europe || Fully modelled based on Shared-Models, incl. [[Signs]]

|-
| [http://mapserver.flightgear.org/map/?lon=13.28992&lat=52.55917&zoom=15&layers=B000000TFFFFTFFFTTFFF EDDT] || [[Berlin Tegel Airport]] || Germany || Europe || Tower, terminals, [[Signs]] and unique buildings downtown

|-
| EDFM || [[Mannheim City Airport]] || Germany || Europe || Basic models of tower, terminals and hangars

|-
| [http://mapserver.flightgear.org/map/?lon=10.71706&lat=53.80496&zoom=15&layers=B000000TFFFFTFFFTTFFF EDHL] || [[Lübeck Blankensee Airport]] || Germany || Europe || Almost complete, home of the [[Piper PA34-200T Seneca II|Seneca]] used to model the FlightGear version. A modified tile is available at [http://www.t3r.de/fg/scenery/ Torsten's scenery site]

|-
| [http://mapserver.flightgear.org/map/?lon=7.16278&lat=50.76767&zoom=15&layers=B000000TFFFFTFFFTTFFF EDKB] || [[Bonn-Hangelar Airport]] || Germany || Europe ||

|-
| EDVE || [[Braunschweig Airport]] || Germany || Europe || Fully modelled

|-
| EEKE || Kuressaare Airport || Estonia || Europe ||

|-
| EETN || Lennart Meri Tallinn Airport || Estonia || Europe ||

|-
| EETU || Tartu Airport || Estonia || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=25.04487&lat=60.25318&zoom=15&layers=B000000TFFFFTFFFTTFFF EFHF] || Helsinki-Malmi Airport || Finland || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=24.95253&lat=60.3206&zoom=14&layers=B000000TFFFFTFFFTTFFF EFHK] || Helsinki-Vantaa Airport || Finland || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=22.26281&lat=60.51412&zoom=14&layers=B000000TFFFFTFFFTFFFF EFTU] || Turku Airport || Finland || Europe || Tower and terminal modelled

|-
| EGFF || Cardiff Airport || United Kingdom || Europe || One building: British Airways Maintenance Facility

|-
| EGGP || Liverpool John Lennon Airport || United Kingdom || Europe ||

|-
| EGGW || London Luton Airport || United Kingdom || Europe ||

|-
| EGKA || Shoreham Airport || United Kingdom || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=-0.19224&lat=51.14869&zoom=14&layers=B000000TFFFFTFFFTTFFF EGKK] || [[London Gatwick]] || United Kingdom || Europe || Complete and fully modeled to highest level of detail with day and night textures; AI parking and ground network

|-
| [http://mapserver.flightgear.org/map/?lon=-0.46095&lat=51.47139&zoom=14&layers=B000000TFFFFTFFFTTFFF EGLL] || London Heathrow Airport || United Kingdom || Europe || Basic development only

|-
| EGPH || Edinburgh Airport || United Kingdom || Europe || Tower, terminal, park deck, and some shared models

|-
| [http://mapserver.flightgear.org/map/?lon=1.28469&lat=52.67713&zoom=15&layers=B000000TFFFFTFFFTTFFF EGSH] || Norwich Airport || United Kingdom || Europe ||

|-
| EH01 || [[VU University Medical Center]] || Netherlands || Europe || Complete hospital building including on-roof heli platform.

|-
| [http://mapserver.flightgear.org/map/?lon=4.75487&lat=52.31296&zoom=14&layers=B000000TFFFFTFFFTTFFF EHAM] || [[Amsterdam Airport Schiphol]] || Netherlands || Europe || Fully modeled, bussiest AI airport currently

|-
| EHEH || Eindhoven Airport || Netherlands || Europe || Basic development only

|-
| [http://mapserver.flightgear.org/map/?lon=5.51885&lat=52.45717&zoom=15&layers=B000000TFFFFTFFFTTFFF EHLE] || [[Lelystad Airport]] || Netherlands || Europe || Fully modeled

|-
| EHVK || [[Volkel Air Base]] || Netherlands || Europe || Shelters and detailed airport layout.

|-
| EIDW || [[Dublin Airport]] || Ireland || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=6.11017&lat=62.56037&zoom=15&layers=B000000TFFFFTFFFTTFFF ENAL] || Ålesund Airport || Norway || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=6.10949&lat=61.83027&zoom=15&layers=B000000TFFFFTFFFTTFFF ENSD] || Sandane Airport || Norway || Europe ||

|-
| ENVA || Trondheim Værnes Airport || Norway || Europe ||

|-
| ESGP || Göteborg Airport || Sweden || Europe || Basic development only

|-
| [http://mapserver.flightgear.org/map/?lon=-106.60912&lat=35.04021&zoom=14&layers=B000000TFFFFTFFFTTFFF KABQ] || Albuquerque Sunport Airport, NM || USA || America || Basic development only

|-
| [http://mapserver.flightgear.org/map/?lon=-84.42809&lat=33.63672&zoom=14&layers=B000000TFFFFTFFFTTFFF KATL] || [[Hartsfield - Jackson Atlanta International Airport]], GA || USA || America || Terminal modeled

|-
| [http://mapserver.flightgear.org/map/?lon=-81.4629595&lat=41.0421187&zoom=15&layers=B000000TFFFFTFFFTTFFF KAKR] || [[Akron-Fulton International Airport]], OH || USA || America || Fully modelled

|-
| [http://mapserver.flightgear.org/map/?lon=-81.43676804&lat=40.91510112&zoom=15&layers=B000000TFFFFTFFFTTFFF KCAK] || Akron-Canton Regional Airport, OH || USA || America || Fully modelled

|-
| KAUS || Austin-Bergstrom Airport, TX || USA || America ||

|-
| KFNT || Bishop Intl, MI || USA || America || Fully modelled

|-
| [http://mapserver.flightgear.org/map/?lon=-76.66833&lat=39.17535&zoom=14&layers=B000000TFFFFTFFFTTFFF KBWI] || Baltimore-Washington International, MD || USA || America || Terminal modeled with jetways, parking garage, support buildings and [[Signs]]

|-
| [http://mapserver.flightgear.org/map/?lon=-76.92254&lat=38.98062&zoom=15&layers=B000000TFFFFTFFFTTFFF KCGS] || College Park Airport, MD || USA || America ||

|-
| KDCA || Reagan National Airport, VA || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-104.67318&lat=39.86166&zoom=13&layers=B000000TFFFFTFFFTTFFF KDEN] || [[Denver_International_Airport|Denver Airport, CO]] || USA || America || One terminal modelled

|-
| KDTW || Detroit Metropolitan Wayne County Airport, MI || USA || America || Basic development only

|-
| KFHR || Friday Harbor Airport, WA || USA || America ||

|-
| KIND || Indianapolis Airport, IN || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-90.07589&lat=32.31118&zoom=14&layers=B000000TFFFFTFFFTTFFF KJAN] || Jackson-Evers Airport, MS || USA || America ||

|-
| KJFK || [[John F. Kennedy International Airport]], NY || USA || America ||

|-
| KLAS || Las Vegas McCarran Airport, NV || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-118.40809&lat=33.9425&zoom=14&layers=B000000TFFFFTFFFTTFFF KLAX] || [[Los Angeles International Airport]], CA || USA|| America || Fully modeled

|-
| KLSV || [[Nellis Air Force Base]], NV || USA || America || Fully modeled

|-
| [http://mapserver.flightgear.org/map/?lon=-109.4667&lat=47.04924&zoom=14&layers=B000000TFFFFTFFFTTFFF KLWT] || Lewistown Municipal Airport, MT || USA || America ||

|-
| KMCI || Kansas City Airport, MO || USA || America || Basic development only

|-
| KMPI || Mariposa-Yosemite Airport, CA || USA || America || Hangars and FBO.

|-
| KMTN || Martin State Airport, MD || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-117.69181&lat=35.68565&zoom=14&layers=B000000TFFFFTFFFTTFFF KNID] || China Lake Naval Air Weapons Station, CA || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-122.04918&lat=37.4162&zoom=15&layers=B000000TFFFFTFFFTTFFF KNUQ] || Moffett Federal Airfield, CA || USA || America || Fully modeled

|-
| [http://mapserver.flightgear.org/map/?lon=-122.22062&lat=37.7214&zoom=14&layers=B000000TFFFFTFFFTTFFF KOAK] || [[Oakland International Airport]], CA || USA || America || Realistic terminal, currently undergoing maintenance

|-
| KORD || Chicago [[O'Hare International Airport]], IL || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-88.55704&lat=43.98436&zoom=14&layers=B000000TFFFFTFFFTTFFF KOSH] || Wittman Regional Airport, Oshkosh, WI || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-75.12398&lat=38.31045&zoom=14&layers=B000000TFFFFTFFFTTFFF KOXB] || Ocean City Municipal Airport, MD || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-122.59751&lat=45.58871&zoom=14&layers=B000000TFFFFTFFFTTFFF KPDX] || Portland Airport, OR || USA || America ||

|-
| KPHX || Phoenix Sky Harbor Airport, AZ || USA || America ||

|-
| KRNO || Reno/Tahoe Airport, NV || USA || America ||

|-
| KSEA || [[Seattle-Tacoma International Airport]], WA || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-122.3749&lat=37.61897&zoom=14&layers=B000000TFFFFTFFFTTFFF KSFO] || [[San Francisco International Airport]], CA || USA || America || FlightGear's default airport, terminal buildings, airport lights and airport train.

|-
| KSLC || Salt Lake City International Airport, UT || USA || America ||

|-
| KXTA || Edwards Airforce Base Detachment 3 (Homey Airport, or Area 51), NV || USA || America || Fully Modelled

|-
| KVUO || Pearson Field Airport, Vancouver, WA || USA || America ||

|-
| LDSP || Split Airport || Croatia || Europe || Basic development only

|-
| LEBB || Bilbao || Spain || Europe || Fully modeled

|-
| LEMD || Madrid - Barajas || Spain || Europe || Fully modeled

|-
| LFEA || Belle-Ile || France || Europe ||

|-
| LFEQ || Quiberon || France || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=-3.66479&lat=48.05247&zoom=15&layers=B000000TFFFFTFFFTTFFF LFES] || Guiscriff Scaër || France || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=2.35465&lat=49.04626&zoom=15&layers=B000000TFFFFTFFFTTFFF LFFE] || Enghien Moisselles Airfield || France || Europe || Fully modeled, high resolution textures

|-
| [http://mapserver.flightgear.org/map/?lon=4.8264&lat=45.25226&zoom=15&layers=B000000TFFFFTFFFTTFFF LFLR] || Saint Rambert d'Albon Airport || France || Europe || Fully modeled, high resolution textures

|-
| [http://mapserver.flightgear.org/map/?lon=13.76716&lat=51.13277&zoom=15&layers=B000000TFFFFTFFFTTFFF LFMA] || Aix - Les Milles Airfield || France || Europe || Fully modeled, high resolution textures

|-
| [http://mapserver.flightgear.org/map/?lon=0.08816&lat=49.53404&zoom=14&layers=B000000TFFFFTFFFTTFFF LFOH] || Le Havre Octeville Airport || France || Europe || Fully modeled, high resolution textures

|-
| [http://mapserver.flightgear.org/map/?lon=5.36736&lat=43.50499&zoom=14&layers=B000000TFFFFTFFFTTFFF LFPG] || Charles de Gaulle International Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [http://mapserver.flightgear.org/map/?lon=2.60632&lat=48.89629&zoom=14&layers=B000000TFFFFTFFFTTFFF LFPH] || Chelles Le Pin Airport || France || Europe || Fully modeled, high resolution textures

|-
| LFPL || Lognes Emerainville Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| LFPO || Paris-Orly Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| LFPZ || St-Cyr-l’École Airport || France || Europe || Fully modeled, very detailed, high resolution textures

|-
| [http://mapserver.flightgear.org/map/?lon=-4.41785&lat=48.44413&zoom=12&layers=B00000000000FTFFTFFTFFFTFFFF LFRB] || Brest Bretagne Airport || France || Europe || Modeled airport with static models

|-
| [http://mapserver.flightgear.org/map/?lon=-4.15167&lat=48.53014&zoom=14&layers=B000000TFFFFTFFFTTFFF LFRL] || Lanvéoc Naval Air Base || France || Europe || Airport fitted with shared models (for helos and training)

|-
| [http://mapserver.flightgear.org/map/?lon=-4.15167&lat=48.53014&zoom=14&layers=B000000TFFFFTFFFTTFFF LFRJ] || [[Landivisiau Naval Air Base]] || France || Europe || Modeled airport with arresting cables and [[Signs]]

|-
| LFRQ || Quimper || France || Europe ||

|-
| LFRU || Morlaix || France || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=7.531611&lat=47.599621&zoom=14 LFSB] || [[EuroAirport Basel-Mulhouse-Freiburg|Basel Mulhouse]] || Switzerland || Europe || Nice modelling of Terminal.

|-
| LILN || Venegono Airport || Italy || Europe || Developed airport

|-
| LILQ || Massa Cinquale Airport || Italy || Europe ||

|-
| LILV || Valbrembo Airport || Italy || Europe ||

|-
| LIMC || Milano-Malpensa Airport || Italy || Europe ||

|-
| [http://mapserver.flightgear.org/map/?lon=9.70741&lat=45.66952&zoom=14&layers=B000000TFFFFTFFFTTFFF LIME] || [[Orio al Serio Airport]], Bergamo || Italy || Europe || Fully modeled

|-
| [http://mapserver.flightgear.org/map/?lon=9.27521&lat=45.44776&zoom=14&layers=B000000TFFFFTFFFTTFFF LIML] || [[LIML|Milano-Linate Airport]] || Italy || Europe || Fully modeled

|-
| [http://mapserver.flightgear.org/map/?lon=7.36789&lat=45.73857&zoom=15&layers=B000000TFFFFTFFFTTFFF LIMW] || Aosta Airport || Italy || Europe || Fully modeled

|-
| [http://mapserver.flightgear.org/map/?lon=14.26&lat=50.100833&zoom=15&layers=B000000TFFFFTFFFTTFFF LKPR] || [[Václav Havel Airport Prague]] (Ruzyne) || Czech Republic || Europe || Fully modeled

|-
| [http://mapserver.flightgear.org/map/?lon=11.34397&lat=47.26023&zoom=15&layers=B000000TFFFFTFFFTTFFF LOWI] || [[Innsbruck Airport]] || Austria || Europe ||

|-
| LROP || Bucharest Otopeni || Romania || Europe ||

|-
| LSGS || Sion Airport || Switzerland || Europe || Basic development only

|-
| LSZB || Bern-Belp Airport || Switzerland || Europe || Basic development only

|-
| PANC || Ted Stevens Anchorage International Airport || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=136.80541&lat=34.85841&zoom=14&layers=B000000TFFFFFFFFTTFFF RJGG] || [[Chūbu Centrair International Airport]] || Japan || Asia || Detailed airport buildings, taxiway layout and customized terrain.

|-
| [http://mapserver.flightgear.org/map/?lon=139.78114&lat=35.5533&zoom=14&layers=B000000TFFFFTFFFTTFFF RJTT] || [[Tokyo Haneda International Airport]] || Japan || Asia ||

|-
| [http://mapserver.flightgear.org/map/?lon=126.45051&lat=37.46909&zoom=14&layers=B000000TFFFFTFFFTTFFF RKSI] || Seoul Incheon Airport || South Korea || Asia ||

|-
| [http://mapserver.flightgear.org/map/?lon=121.01349&lat=14.51024&zoom=14&layers=B000000TFFFFTFFFTTFFF RPLL] || Manila Aquino Airport || Philippines || Asia || Tower and three large terminals

|-

| [[SVMI]] || Aeropuerto Internacional Simon Bolivar || Venezuela || America || Several static buildings

|-

| TAPA || V.C. Bird Intl Airport || Antigua and Barbuda || America ||

|-
| TDPD || Melville Hall Airport || Dominica || America ||

|-
| TFFF || Martinique Aimé Césaire International Airport || Martinique, France || America ||

|-
| TFFG || Grand Case Airport || St. Maarten, Netherlands || America ||

|-
| TIST || Cyril E. King Airport || US Virgin Islands || America ||

|-
| TJSJ || Luis Muñoz Marín International Airport || Puerto Rico || America ||

|-
| TKPK || Robert L. Bradshaw International Airport || St. Kitts || America ||

|-
| TNCM || [[Princess Juliana International Airport]] || St. Maarten, Netherlands || America || Fully modeled, customized terrain

|-
| TNCS || Juancho E. Yrausquin Airport || Saba || America || Fully modeled

|-
| TQPF || Clayton J. Lloyd International Airport || Anguilla || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-49.17201&lat=-25.53101&zoom=15&layers=B0000000TFFFTFFFTFFFFFFF SBCT] || Afonso Pena International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [http://mapserver.flightgear.org/map/?lon=-46.65768&lat=-23.62558&zoom=15&layers=B0000000TFFFTFFFTFFFFFFF SBSP] || Congonhas Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [http://mapserver.flightgear.org/map/?lon=-46.46864&lat=-23.43351&zoom=15&layers=B0000000TFFFTFFFTFFFFFFF SBGR] || Guarulhos International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| [http://mapserver.flightgear.org/map/?lon=-48.54304&lat=-27.6685&zoom=15&layers=B0000000TFFFTFFFTFFFFFFF SBFL] || Hercílio Luiz International Airport || Brazil || South America || 3D Fully modeled - Download [http://djrick1.wix.com/grupofgbr/aeroportos#!__aeroportos Site Group FGBR]

|-
| SKRG || Jose Maria Cordoba International Airport, Rionegro, Antioquia || Colombia || South America || Fully Modelled

|-
| VIDP || Indira Gandhi International Airport || India || Asia ||

|-
| [http://mapserver.flightgear.org/map/?zoom=14&lat=27.39994&lon=89.42272&layers=B0 VQPR] || [[Paro Airport]] || Bhutan || Asia || Terminal, Buildings, Refernce Points and other POIs

|-
| [http://mapserver.flightgear.org/map/?lon=91.50917&lat=27.25961&zoom=12&layers=B0 VQ10] || [[Yongphulla Airport]] || Bhutan || Asia || Terminal, some other Buildings

|-
| [http://mapserver.flightgear.org/map/?lon=113.9183&lat=22.308&zoom=14&layers=B000000TFFFFTFFFTTFFF VHHH] || Hong Kong International Airport || Hong Kong || Asia || Terminals, control towers, some other buildings

|-
| [http://mapserver.flightgear.org/map/?lon=-81.41707414&lat=41.15689289&zoom=15&layers=B000000TFFFFTFFFTTFFF 1G3] || Kent State University Airfield, OH || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-81.76281774&lat=41.13448335&zoom=15&layers=B000000TFFFFTFFFTTFFF 1G5] || [[Medina Municipal Airport]], OH || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-81.24620281&lat=41.20973295&zoom=15&layers=B000000TFFFFTFFFTTFFF 29G] || Portage Co, OH || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-90.13769&lat=43.83872&zoom=15&layers=B000000TFFFFTFFFTTFFF 82C] || Mauston-New Lisbon Union Airport, WI || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-89.02545&lat=44.50485&zoom=15&layers=B000000TFFFFTFFFTTFFF 68C] || Iola Central County Airport, WI || USA || America ||

|-
| [http://mapserver.flightgear.org/map/?lon=-123.00815977&lat=43.93009927&zoom=12 77S] || Hobby Field, Creswell, OR || USA || America || Nearly complete: Hangars (one accidently missing), fuel pump, GA aircraft, cars, trees, bushes (shared models)

|}

== External links ==
* [http://iveze.nl/fgmap/ Builtup airports in Flightgear] – Interactive world map by KL-666. ''See also related forum topic [http://forum.flightgear.org/viewtopic.php?f=5&t=23613 Map of airports with buildings in terrasync].''

{{Suggested}}

[[Category:Lists]]
[[Category:Airports]]

User:Johan G/Howto:Create an aircraft

2015-03-13T04:36:42Z

Zlsa: created page, started work on it

{{progressbar|10}}

You're here because you've seen what FlightGear can do, and you want to create a new aircraft. Here's a primer on how the process works.

== What's needed to create an aircraft? ==

There are several parts to a FlightGear aircraft. There's the visuals --- the 3D model, the associated sounds, and the cockpit; and there's the [[FDM|flight dynamics model]], also known as the FDM, and the aircraft's mechanical systems (electrical, vacuum, static and pitot, etc.) These parts, while they may appear connected, are completely separate and interface with each other mainly through the [[property tree]].

== Visuals ==

JSBSim vs YASim

2015-03-12T02:14:58Z

Zlsa: Changed wording

[[JSBSim]] and [[YASim]] are the two most commonly used [[FDM|flight dynamics models]] used within FlightGear. They each have their pros and cons; they'll be discussed here.

== Accuracy and realism ==

Accuracy and realism of the flight dynamics model are two common points raised in the argument against YASim. In reality, if you give YASim or JSBSim garbage parameters, they'll both return garbage aerodynamics. The accuracy of the algorithm is constrained by its input.

YASim and JSBSim have different problems with regards to accurately emulating a real-life aircraft. Since YASim is solver-based, you do not need wind-tunnel data or accurate tables of propeller performance; you simply tell it some basic aircraft parameters and it will attempt to find a solution that approximates the aircraft's aerodynamics model. JSBSim uses detailed tables of performance and lift/drag numbers instead; JSBSim has no concept of wings or fuselage. Instead, drag, lift, and other forces are computed as functions of alpha (pitch), beta (yaw), control deflection, flap deflection, etc. This means that JSBSim needs accurate data to produce an accurate flight model.

Both YASim and JSBSim have their niche; YASim is simpler to get started with but it's not as easily matched to a real aircraft's performance, while JSBSim is much more difficult to use but is more controllable.

== YASim ==

YASim uses a solver-based approach to aerodynamics; you lay out the physical characteristics of the aircraft (such as its wings, fuselage, engines, stabilizers, etc.) as well as its flying characteristics (cruise speed and altitude, the angle of attack during landing) and YASim attempts to solve for the given configuration. It's not always successful (since there are many possible aerodynamic solutions for a given set of parameters) and it's generally not too accurate unless it's been iteratively fine-tuned by the author to match the performance of the real-life aircraft.

== JSBSim ==

JSBSim, on the other hand, uses a data-driven approach to flight dynamics. If it were given all the proper tables for the real-life aircraft it's simulating (which is effectively impossible), it will produce perfectly realistic dynamics; if you wanted to, you could simulate a brick. It's commonly used for older aircraft with published performance data; it's very difficult to create a JSBSim FDM without any wind-tunnel data.

== Which one should I use? ==

Continue down until you answer 'yes'.

# Do you have wind-tunnel data for the aircraft in question? If so, use JSBSim.
# Is this your first FDM? If so, use YASim.
# Do you dislike YASim's open-ended solver? If so, use JSBSim.
# Do you dislike JSBSim's necessary reams of data? If so, use YASim.
# See 3.

In the end, it really doesn't matter which one you use --- just pick one and use it. It's not a life-or-death decision.

Realism

2015-03-11T23:20:32Z

Zlsa: added magnetic compass sticking note

{{cleanup}}

How realistic is [[FlightGear]]'s [[aircraft]] and environment? What is needed to get more realism and immersion from the FlightGear environment?

== Aircraft ==

[[File:DR400_Dauphin_Rembrandt_02.jpg|800px|center|The [[DR400|DR400 Dauphin]].]]

The underlying instrumentation models are very accurate, with many physical effects accounted for.

* The heading indicator has a small delay when it's slewing to your heading.
* The artificial horizon can tumble.
* The magnetic compass will rotate in all three axes and get stuck if the aircraft is tilted.
* The altimeter uses air pressure to determine altitude; if the sea level air pressure is set incorrectly, it will display the wrong altitude as in real life.
* All of the instruments that need engine power in real life are tied to the virtual engine; if the engine is not running, all vacuum-powered instruments (such as the artificial horizon and the heading indicator) will not function properly.
* Some aircraft feature accurate electrical systems with batteries that will drain over time and instruments that need electricity.

== Flight dynamics ==

Since FlightGear uses many [[FDM|flight dynamics models]] under the hood, including [[YASim]] and [[JSBSim]], the realism of an aircraft depends on its FDM. Both of these support winds and turbulence; YASim generally has more realistic ground interactions with different surfaces, while JSBSim FDMs are generally truer to the real-life aircraft. It's important to note that both of these can produce similar results if the FDM is worked on enough.

== Scenery==

<gallery mode="packed">
File:Southwest04.jpg|
File:Kansas_Scenery_Two.jpg|
</gallery>

* Over 20,000 real world airports included in the full [[scenery]] set. The recent world scenery version 2 brought many major improvements, including more detailed heightmaps and man-made features such as roads, rivers, and train tracks.
* Correct runway markings, runway lighting, and approach lighting.
* Detailed taxiways available for many airports.
* Sloping runways.
* Airport beacon lights with rotating beacons.
* Accurate worldwide terrain based on the most recently released SRTM terrain data. 3 arc second resolution (about 90m spacing) for North and South America, Europe, Asia, Africa, and Australia.
* Roads, rivers, and train tracks.
* Realistic night lighting with lit urban areas and headlights on roads.

Real world tower registration data was used to locate towers in the United States. The data was sourced from the United States Federal Communications Commission tower registration database.

Over one million objects have been added to the [http://scenemodels.flightgear.org/ FlightGear Scenery Database].

To download scenery for the entire world as you fly over it, open the File > Scenery Download menu and check "Enable automatic download/update".

== Weather ==

[[File:Local_weather_1.00_06.jpg|center|[[Advanced weather]].|800px]]

With [[Advanced weather]], cloud patterns and winds will change throughout the day. With [[atmospheric light scattering]] enabled, fog and clouds are more realistic, and lighting changes throughout the day and during overcast periods. Advanced weather can be driven with live [[METAR]] data or manually configured for specific weather scenarios.

Enable advanced weather in the Environment > Weather dialog.

== Rendering ==

[[Atmospheric light scattering]], or ALS, features a realistic skydome and properly lit terrain, in addition to detailed terrain texturing and trees swaying in the wind. With advanced weather enabled as well, cloud shadows and volumetric fog are also fully supported. It can be enabled via the View > Rendering Options menu. Be sure to check out the quality slider, and if you're adventurous, enable custom settings.

[[Rembrandt]] is FlightGear's shadow and lighting engine; with Rembrandt enabled, realistic shadows and lighting are possible. Note that not all aircraft support Rembrandt yet. In addition, it's not possible to use Rembrandt in conjunction with ALS. Rembrant is enabled with the <tt>--enable-rembrandt</tt> [[Command line options|command line option]].

== Sky ==

<gallery mode="packed">
File:Southwest09.jpg|
File:Water-sky01.jpg|
File:Rayleigh_blue.jpg|
File:Tree02.jpg|
</gallery>

FlightGear's night sky features accurate placement and lighting of stars, planets, and the moon.

Atmospheric light scattering features accurate lighting of the sky and terrain; in addition, oceans and rivers are realistically shaded with ripples and sun reflections. Rayleigh scattering of distant terrain is supported, tinting the ground blue or red depending on the sun angle. With random trees, tree shadows are available; experimental aircraft ground shadows are also available.

JSBSim vs YASim

2015-03-11T23:03:52Z

Zlsa: Created page.

[[JSBSim]] and [[YASim]] are the two most commonly used [[FDM|flight dynamics models]] used within FlightGear. They each have their pros and cons; they'll be discussed here.

== Accuracy and realism ==

Accuracy and realism of the flight dynamics model are two common points raised in the argument against YASim. In reality, if you give YASim or JSBSim garbage parameters, they'll both return garbage aerodynamics. The accuracy of the algorithm is constrained by its input.

YASim and JSBSim have different problems with regards to accurately emulating a real-life aircraft. Since YASim is solver-based, you do not need wind-tunnel data or accurate tables of propeller performance; you simply tell it some basic aircraft parameters and it will attempt to find a solution that approximates the aircraft's aerodynamics model. JSBSim uses detailed tables of performance and lift/drag numbers instead; JSBSim has no concept of wings or fuselage. Instead, drag, lift, and other forces are computed as functions of alpha (pitch), beta (yaw), control deflection, flap deflection, etc. This means that JSBSim needs accurate data to produce an accurate flight model.

Both YASim and JSBSim have their niche; YASim is simpler to get started with but it's not as easily matched to a real aircraft's performance, while JSBSim is much more difficult to use but is more controllable.

== YASim ==

YASim uses a solver-based approach to aerodynamics; you lay out the physical characteristics of the aircraft (such as its wings, fuselage, engines, stabilizers, etc.) as well as its flying characteristics (cruise speed and altitude, the [[angle of attack]] during landing) and YASim attempts to solve for the given configuration. It's not always successful (since there are many possible aerodynamic solutions for a given set of parameters) and it's generally not accurate unless it's been iteratively fine-tuned by the author to match the performance of the real-life aircraft.

== JSBSim ==

JSBSim, on the other hand, uses a data-driven approach to flight dynamics. If it were given all the proper tables for the real-life aircraft it's simulating (which is effectively impossible), it will produce perfectly realistic dynamics; if you wanted to, you could simulate a brick. It's commonly used for older aircraft with published performance data; it's very difficult to create a JSBSim FDM without any wind-tunnel data.

== Which one should I use? ==

Continue down until you answer 'yes'.

# Do you have wind-tunnel data for the aircraft in question? If so, use JSBSim.
# Is this your first FDM? If so, use YASim.
# Are you frustrated with YASim's open-endedness? If so, use JSBSim.
# Are you frustrated with JSBSim's complexity? If so, use YASim.
# See 3.

In the end, it really doesn't matter which one you use --- just pick one and use it. It's not a life-or-death decision.

Realism

2015-03-11T22:53:07Z

Zlsa: Fixed incorrect reference of HI as 'panel-mounted compass' and added more instrumentation examples

{{cleanup}}

How realistic is [[FlightGear]]'s [[aircraft]] and environment? What is needed to get more realism and immersion from the FlightGear environment?

== Aircraft ==

[[File:DR400_Dauphin_Rembrandt_02.jpg|800px|center|The [[DR400|DR400 Dauphin]].]]

The underlying instrumentation models are very accurate, with many physical effects accounted for.

* The heading indicator has a small delay when it's slewing to your heading.
* The artificial horizon can tumble.
* The magnetic compass will rotate in all three axes.
* The altimeter uses air pressure to determine altitude; if the sea level air pressure is set incorrectly, it will display the wrong altitude as in real life.
* All of the instruments that need engine power in real life are tied to the virtual engine; if the engine is not running, all vacuum-powered instruments (such as the artificial horizon and the heading indicator) will not function properly.
* Some aircraft feature accurate electrical systems with batteries that will drain over time and instruments that need electricity.

== Flight dynamics ==

Since FlightGear uses many [[FDM|flight dynamics models]] under the hood, including [[YASim]] and [[JSBSim]], the realism of an aircraft depends on its FDM. Both of these support winds and turbulence; YASim generally has more realistic ground interactions with different surfaces, while JSBSim FDMs are generally truer to the real-life aircraft. It's important to note that both of these can produce similar results if the FDM is worked on enough.

== Scenery==

<gallery mode="packed">
File:Southwest04.jpg|
File:Kansas_Scenery_Two.jpg|
</gallery>

* Over 20,000 real world airports included in the full [[scenery]] set. The recent world scenery version 2 brought many major improvements, including more detailed heightmaps and man-made features such as roads, rivers, and train tracks.
* Correct runway markings, runway lighting, and approach lighting.
* Detailed taxiways available for many airports.
* Sloping runways.
* Airport beacon lights with rotating beacons.
* Accurate worldwide terrain based on the most recently released SRTM terrain data. 3 arc second resolution (about 90m spacing) for North and South America, Europe, Asia, Africa, and Australia.
* Roads, rivers, and train tracks.
* Realistic night lighting with lit urban areas and headlights on roads.

Real world tower registration data was used to locate towers in the United States. The data was sourced from the United States Federal Communications Commission tower registration database.

Over one million objects have been added to the [http://scenemodels.flightgear.org/ FlightGear Scenery Database].

To download scenery for the entire world as you fly over it, open the File > Scenery Download menu and check "Enable automatic download/update".

== Weather ==

[[File:Local_weather_1.00_06.jpg|center|[[Advanced weather]].|800px]]

With [[Advanced weather]], cloud patterns and winds will change throughout the day. With [[atmospheric light scattering]] enabled, fog and clouds are more realistic, and lighting changes throughout the day and during overcast periods. Advanced weather can be driven with live [[METAR]] data or manually configured for specific weather scenarios.

Enable advanced weather in the Environment > Weather dialog.

== Rendering ==

[[Atmospheric light scattering]], or ALS, features a realistic skydome and properly lit terrain, in addition to detailed terrain texturing and trees swaying in the wind. With advanced weather enabled as well, cloud shadows and volumetric fog are also fully supported. It can be enabled via the View > Rendering Options menu. Be sure to check out the quality slider, and if you're adventurous, enable custom settings.

[[Rembrandt]] is FlightGear's shadow and lighting engine; with Rembrandt enabled, realistic shadows and lighting are possible. Note that not all aircraft support Rembrandt yet. In addition, it's not possible to use Rembrandt in conjunction with ALS. Rembrant is enabled with the <tt>--enable-rembrandt</tt> [[Command line options|command line option]].

== Sky ==

<gallery mode="packed">
File:Southwest09.jpg|
File:Water-sky01.jpg|
File:Rayleigh_blue.jpg|
File:Tree02.jpg|
</gallery>

FlightGear's night sky features accurate placement and lighting of stars, planets, and the moon.

Atmospheric light scattering features accurate lighting of the sky and terrain; in addition, oceans and rivers are realistically shaded with ripples and sun reflections. Rayleigh scattering of distant terrain is supported, tinting the ground blue or red depending on the sun angle. With random trees, tree shadows are available; experimental aircraft ground shadows are also available.

Realism

2015-03-11T22:37:21Z

Zlsa: Added options information

{{cleanup}}

How realistic is [[FlightGear]]'s [[aircraft]] and environment? What is needed to get more realism and immersion from the FlightGear environment?

== Aircraft ==

[[File:DR400_Dauphin_Rembrandt_02.jpg|800px|center|The [[DR400|DR400 Dauphin]].]]

The underlying instrumentation models are very accurate, with many physical effects accounted for.

* The panel-mounted magnetic compass takes time to slew to your heading.
* The artificial horizon can tumble.
* The windshield or panel-mounted compass will rotate in all three axes.

== Flight dynamics ==

Since FlightGear uses many [[FDM|flight dynamics models]] under the hood, including [[YASim]] and [[JSBSim]], the realism of an aircraft depends on its FDM. Both of these support winds and turbulence; YASim generally has more realistic ground interactions with different surfaces, while JSBSim FDMs are generally truer to the real-life aircraft. It's important to note that both of these can produce similar results if the FDM is worked on enough.

== Scenery==

<gallery mode="packed">
File:Southwest04.jpg|
File:Kansas_Scenery_Two.jpg|
</gallery>

* Over 20,000 real world airports included in the full [[scenery]] set. The recent world scenery version 2 brought many major improvements, including more detailed heightmaps and man-made features such as roads, rivers, and train tracks.
* Correct runway markings, runway lighting, and approach lighting.
* Detailed taxiways available for many airports.
* Sloping runways.
* Airport beacon lights with rotating beacons.
* Accurate worldwide terrain based on the most recently released SRTM terrain data. 3 arc second resolution (about 90m spacing) for North and South America, Europe, Asia, Africa, and Australia.
* Roads, rivers, and train tracks.
* Realistic night lighting with lit urban areas and headlights on roads.

Real world tower registration data was used to locate towers in the United States. The data was sourced from the United States Federal Communications Commission tower registration database.

Over one million objects have been added to the [http://scenemodels.flightgear.org/ FlightGear Scenery Database].

To download scenery for the entire world as you fly over it, open the File > Scenery Download menu and check "Enable automatic download/update".

== Weather ==

[[File:Local_weather_1.00_06.jpg|center|[[Advanced weather]].|800px]]

With [[Advanced weather]], cloud patterns and winds will change throughout the day. With [[atmospheric light scattering]] enabled, fog and clouds are more realistic, and lighting changes throughout the day and during overcast periods. Advanced weather can be driven with live [[METAR]] data or manually configured for specific weather scenarios.

Enable advanced weather in the Environment > Weather dialog.

== Rendering ==

[[Atmospheric light scattering]], or ALS, features a realistic skydome and properly lit terrain, in addition to detailed terrain texturing and trees swaying in the wind. With advanced weather enabled as well, cloud shadows and volumetric fog are also fully supported. It can be enabled via the View > Rendering Options menu. Be sure to check out the quality slider, and if you're adventurous, enable custom settings.

[[Rembrandt]] is FlightGear's shadow and lighting engine; with Rembrandt enabled, realistic shadows and lighting are possible. Note that not all aircraft support Rembrandt yet. In addition, it's not possible to use Rembrandt in conjunction with ALS. Rembrant is enabled with the <tt>--enable-rembrandt</tt> [[Command line options|command line option]].

== Sky ==

<gallery mode="packed">
File:Southwest09.jpg|
File:Water-sky01.jpg|
File:Rayleigh_blue.jpg|
File:Tree02.jpg|
</gallery>

FlightGear's night sky features accurate placement and lighting of stars, planets, and the moon.

Atmospheric light scattering features accurate lighting of the sky and terrain; in addition, oceans and rivers are realistically shaded with ripples and sun reflections. Rayleigh scattering of distant terrain is supported, tinting the ground blue or red depending on the sun angle. With random trees, tree shadows are available; experimental aircraft ground shadows are also available.

Realism

2015-03-11T22:32:47Z

Zlsa: Revamped and updated the entire page.

{{cleanup}}

How realistic is [[FlightGear]]'s [[aircraft]] and environment? What is needed to get more realism and immersion from the FlightGear environment?

== Aircraft ==

[[File:DR400_Dauphin_Rembrandt_02.jpg|800px|center|The [[DR400|DR400 Dauphin]].]]

The underlying instrumentation models are very accurate, with many physical effects accounted for.

* The panel-mounted magnetic compass takes time to slew to your heading.
* The artificial horizon can tumble.
* The windshield or panel-mounted compass will rotate in all three axes.

== Flight dynamics ==

Since FlightGear uses many [[FDM|flight dynamics models]] under the hood, including [[YASim]] and [[JSBSim]], the realism of an aircraft depends on its FDM. Both of these support winds and turbulence; YASim generally has more realistic ground interactions with different surfaces, while JSBSim FDMs are generally truer to the real-life aircraft. It's important to note that both of these can produce similar results if the FDM is worked on enough.

== Scenery==

<gallery mode="packed">
File:Southwest04.jpg|
File:Kansas_Scenery_Two.jpg|
</gallery>

* Over 20,000 real world airports included in the full [[scenery]] set. The recent world scenery version 2 brought many major improvements, including more detailed heightmaps and man-made features such as roads, rivers, and train tracks.
* Correct runway markings, runway lighting, and approach lighting.
* Detailed taxiways available for many airports.
* Sloping runways.
* Airport beacon lights with rotating beacons.
* Accurate worldwide terrain based on the most recently released SRTM terrain data. 3 arc second resolution (about 90m spacing) for North and South America, Europe, Asia, Africa, and Australia.
* Roads, rivers, and train tracks.
* Realistic night lighting with lit urban areas and headlights on roads.

Real world tower registration data was used to locate towers in the United States. The data was sourced from the United States Federal Communications Commission tower registration database.

Over one million objects have been added to the [http://scenemodels.flightgear.org/ FlightGear Scenery Database].

== Weather ==

[[File:Local_weather_1.00_06.jpg|center|[[Advanced weather]].|800px]]

With [[Advanced weather]], cloud patterns and winds will change throughout the day. With [[atmospheric light scattering]] enabled, fog and clouds are more realistic, and lighting changes throughout the day and during overcast periods. Advanced weather can be driven with live [[METAR]] data or manually configured for specific weather scenarios.

== Rendering ==

[[Atmospheric light scattering]], or ALS, features a realistic skydome and properly lit terrain, in addition to detailed terrain texturing and trees swaying in the wind. With advanced weather enabled as well, cloud shadows and volumetric fog are also fully supported.

[[Rembrandt]] is FlightGear's shadow and lighting engine; with Rembrandt enabled, realistic shadows and lighting are possible. Note that not all aircraft support Rembrandt yet. In addition, it's not possible to use Rembrandt in conjunction with ALS.

== Sky ==

<gallery mode="packed">
File:Southwest09.jpg|
File:Water-sky01.jpg|
File:Rayleigh_blue.jpg|
File:Tree02.jpg|
</gallery>

FlightGear's night sky features accurate placement and lighting of stars, planets, and the moon.

Atmospheric light scattering features accurate lighting of the sky and terrain; in addition, oceans and rivers are realistically shaded with ripples and sun reflections. Rayleigh scattering of distant terrain is supported, tinting the ground blue or red depending on the sun angle. With random trees, tree shadows are available; experimental aircraft ground shadows are also available.

Piper Archer CX

2015-03-10T16:44:44Z

Zlsa: Removed extraneous period.

{{infobox Aircraft
| image = Piper_Archer_CX_in_flight_with_provisional_texture.jpg
| alt = External view with [[Atmospheric_light_scattering|ALS]] and [[advanced weather]] enabled
| image2 = Piper_Archer_CX_cockpit_view_with_Rembrandt.png
| alt2 = Cockpit view with Rembrandt enabled
| name = Piper Archer CX
| type = Civilian aircraft
| fdm = JSBSim
| status-fdm = 1
| status-systems = 3
| status-cockpit = 3
| status-model = 4
| authors = Jon Ross
| fgname = pa28-181, piper-archer-cx
| development = http://github.com/zlsa/pa28-181/
| download = http://zlsa.github.io/pa28-181/releases/pa28-181-latest.zip
}}

[[File:Rembrandtready.png|left]]

The [http://zlsa.github.io/pa28-181/ Piper Archer CX] is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe. Unlike its real-life counterparts, the Archer TX and LX, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Electrical system ==

The Piper Archer CX has a custom-made realistic electrical system; for example, the lights will dim when you crank the engine. The aircraft starts with the battery and alternator switches on which can be confirmed with the battery voltage gauge to the left of the pilot's yoke. If both the battery and alternator are turned off, no electrical systems will work (including the starter and fuel pump).

== Status ==

The exterior model is complete but needs livery support and a normal map; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like a Piper, but it has not been tested with regards to the real life Piper Archer TX.

== Feedback ==

Open a [https://github.com/zlsa/pa28-181/issues GitHub issue] if you've found anything wrong with the aircraft in any way.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]
[[Category:Civil_trainer_aircraft]]

Shader requests

2015-03-07T19:40:23Z

Zlsa: Added propeller request

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

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

= Open shader requests =

== Spinning propeller ==

Since a spinning propeller is not, in fact, a flat quad with a texture, I'm going to request a spinning propeller shader. See War Thunder: http://imgur.com/kQ1b1HI,OAwik2K,C3AUAzy

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

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

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

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

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

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

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

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

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

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

== Lens distortion shader for Oculus Rift ==

Probably already on someone's list; but the shader from [https://github.com/bjornblissing/osgoculusviewer] to correct for lens distortion in Oculus Rift would be helpful.

: I'm (slowly) working on that one [[User:Gijs|Gijs]] ([[User talk:Gijs|talk]]) 15:09, 11 March 2014 (UTC)

= Ideas =

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

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

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

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

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

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

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

osm2city uses a nice traffic shader with 2D Images of moving cars. For trains I'd wish a similar effect, just with trains instead of cars which move slower and appear less frequently. [[User:Laserman|Laserman]] ([[User talk:Laserman|talk]])

{{FGCquote
|A more promising/better-performing approach would involve using shaders, as per a number of "traffic shader" discussions we've had (especially affected by OSM2City)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=224434#p224434
|title=<nowiki>Re: How to creat moving traffic</nowiki>
|author=<nowiki>Hooray</nowiki>
|date=<nowiki>Sat Nov 15</nowiki>
}}
}}

{{FGCquote
| If we have linear features like roads mapped in the proper direction and classified into left and right lanes, we could add overlay textures and normalmaps with the shader (think urban effect) and translate them with time, creating the semblance of traffic (like the urban effect, this would break at low altitude, but from reasonably high up might look credible)
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=180587#p180587
|title=<nowiki>What effects are we missing?</nowiki>
|author=<nowiki>Thorsten</nowiki>
|date=<nowiki>Mon Apr 01</nowiki>
}}
}}

{{FGCquote
|Note that there are two road effects, and fgdata/Effects/road*eff is Emilian's traffic shader. Though the correct way of using it would be to set TRAFFIC_SHADER_ENABLE {{=}} True and then run roads.py.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=221316#p221316
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Mon Oct 20</nowiki>
}}
}}

{{FGCquote
|all credit goes to Emilian. He is improving the shader side, I will continue on the model side. So this is very much work in progress.
The shader requires the default renderer. No ALS/Rembrandt yet.
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212460#p212460
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Fri Jun 13</nowiki>
}}
}}

{{FGCquote
|(see the [https://dl.dropboxusercontent.com/u/24846517/fg/traffic_shader.jpg linked image]) 
Thanks Emilian!
|{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=212325#p212325
|title=<nowiki>Re: osm2city.py development</nowiki>
|author=<nowiki>radi</nowiki>
|date=<nowiki>Wed Jun 11</nowiki>
}}
}}

== motion blur, bloom & HDR ==

See forum post:

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

== Tessellation via geometry shaders (or fractals) ==

Something like a LOD animation in which we subdivide the triangles in more little ones, so we always get detailed terrain when camera is near. (Textures included too). That wouldn't be very hard to implement with geometry shaders. Another way could be with fractals and OSG code, but geometry shaders would be more viable I think.

[[Category:Contribution requests]]
[[Category: Shaders]]

FlightGear Newsletter September 2014

2014-09-14T21:09:58Z

Zlsa: Cleaned up grammar, added contents

{{Newsletter-header|September 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}} 
{{Newsletter-cover-item|DDS feedback needed}} 
{{Newsletter-cover-item|Aircraft moved to SVN}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Performance issues}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
|}
</div>

== DDS feedback needed ==

We are looking for feedback about possibly adopting DDS textures in FlightGear. There are several advantages in doing so:

* DDS is a more compact format than png, hence the download size of the FG base package may be decreased
* Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
* DDS stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by most Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.

Continue reading at [[Switching default texture format to DDS]]...

== Aircraft moved to SVN ==
Some months ago we decided to host our aircraft on an SVN repository in order to relieve <code>fgdata</code>.
The <code>fgdata</code> repo would be a mirror of the base package.

We finally moved all our aircraft to '''the new SVN repo''': http://sourceforge.net/p/flightgear/fgaddon/

This repository is named "FGAddon" because its content is not required to run FlightGear but provides a new feature (aircraft in this case); this is usually called an "addon".

=== Advantages ===
On the user side, the most important feature is to be able to checkout only desired aircraft, as you no longer need to download the 400+ aircraft at once.

On the developer side, the most important interest is to have a base package (<code>fgdata</code>) which is lighter to sync for new contributors and easier to keep up to date.

=== A mini HowTo ===
* For Windows: Install TortoiseSVN (http://tortoisesvn.net/)
* For Linux/Mac: Install SVN

Then to fetch an aircraft (in this example we pick up the [[DR400 Dauphin]]):
svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DR400-dauphin

Then you can regularly fetch the latest updates with
svn up

If you are used to use Git, <code>svn co</code> and <code>svn up</code> are similar to <code>git clone</code> or <code>git pull</code>.

The aircraft will remain in the <code>fgdata</code> Git repository for a few months, until everyone has transitioned to the SVN repositories.

=== Background ===
For our aircraft developers who don't regularly read the mailing list (even though any aircraft developers should already be subscribed), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971

== Performance Issues ==
Several FlightGear users have pointed out inexplicable "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily.

So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker.

As some of you may know from working with Nasal code: listeners are not in and of themselves expensive, but running identical listeners over and over again each frame is getting unnecessarily expensive quickly. This doesn't just apply to scripting space, but also to C++ space - here, it's the sheer performance offered by native C++ code that makes it much harder to identify such problems, because code that would bring the simulator down to its knees in Nasal may very well still be "fast enough" for most people with fast computers, despite being still very much "broken", and plain wrong.

As can be seen on the devel list, Torsten has been spending the last weeks troubleshooting the effects system, which isn't exactly straightforward because its original developer is not currently involved in FlightGear, and the code is pretty sophisticated and even multi-threaded (which means that parts of the code may be running concurrently on different CPUs) - however, Torsten did report pretty significant performance improvements recently - he's just pushed his work to a new branch so that other developers (and people building from source!) can have a look and test his changes and report feedback/issues - this will probably mean that it may take a few weeks until all the feedback has come in and implemented - but performance should be improved significantly by then - which also addresses the whole "when will 3.2 be released" question.

Also, Hooray recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - it seems that a few contributors are still trying to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work.

But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:

* [[FlightGear Headless|Running FlightGear headless]] (i.e. without a window, used for subsystem performance testing)

* [[Testing|Testing Performance]]

Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.

People wanting to change that, need to roll up their sleeves and get involved, and PLEAE provide feedback.

'''All''' testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: [[Howto:Optimizing FlightGear for mobile devices]].

And here some initial observations based on running FlightGear on an underpowered Netbook with integrated Intel GMA graphics:

* our existing GUI truly sucks: whenever a PUI dialog is opened, the frame rate is becoming single-digit
* once the dialog is closed, it will spike up to ~30 fps, with the Canvas/REPL window still shown (!)
* hiding the PUI menubar further helps increase frame rate and improve frame spacing
* hiding the menubar AND closing the REPL dialog, I am getting ~45-50 fps using the minimal startup profile, frame spacing is then roughly in the 60s
* the navcache is a huge resource hog for people on such systems - initializinig/rebuilding the cache is taking ages (10-20+ minutes here !)
* it would make sense to refactor the navcache and turn it into a library, so that we can prebuild the navcache - and either do so while packaging a release, or alternatively, during installation (plenty of time there!)
* in addition, threading would make sense probably, when the navcache was being rebuilt, the 2nd core was idling all the time while 1 core was at 100%
* Canvas/RTT (FBOs) actually work here (which is a good thing for FGPanel/FGCanvas usage)
* there are a bunch of default options that will "break" FG for users on such systems, including a number of options that will trigger OpenGL/OSG errors early on

Hooray is hoping to do further testing, using the system monitor and the built-in profiler - keep in mind that this still is the code that contains some pretty severe performance bugs.

If we had more people doing this kind of testing, we could definitely identify, and hopefully eliminate, quite a few performance issues that would not be noticeable on a typical developer's machine.
So this could be a worthwhile thing to do, and it would help FG in the long term - i.e. even benefit power users who have 2048 MB of VRAM and 8 cores/12 gb of RAM.

The really interesting "benchmark" here is running osgviewer and fgviewer as comparison, because what FG is doing here isn't much different functionality-wise, and it's using the same technology stack (i.e. OSG), so should provide similar performance.

Unofortunately, we generally don't have many people who do a lot of testing, troubleshooting - or even just provide feedback via the issue tracker - it is definitely true that the Canvas GUI is much faster here, despite containing a ton MORE Nasal code, and despite being MUCH more dynamic/flexible than our existing PUI dialogs.

It would really be awesome to find a handful of people with access to old/slow hardware interested in testing and maybe troubleshooting things - while it would be great if those people knew how to build from source, and how to use git/gitorious, I don't think that's even necessary - we can definitely provide a lot of infrastructure and advice, but most of us don't typically have access to these kinds of computers. And while some of us admittedly aren't bothered by it, it is very true that FlightGear as a whole will benefit from teasing out certain bugs/issues, no matter if those are slowing things down due to CPU/GPU or RAM/VRAM utilization.

But we really need more people willing to do this kind of testing and who can provide feedback regularly - and start yelling once something that previously worked, stops working or is becoming unnecessarily slow - there are a bunch of issues that should have never made it into the code, but which went unnoticed for months (or even years), because it's really only power users/contributors and developers who do this kind of testing, and as I am seeing right now, certain issues are pretty well "masked" on an 8-core, 10 gb, 2gb VRAM machine obviously ...

We've been hoping to create some kind of "benchmark" for years - and this is one of those things that would truly help FlightGear in the long term, because we'd get quantifiable data over time, so that we can easily tell how a certain startup/run-time feature behaves in correlation with how it behaved previously, i.e. compared to updated dependencies (OpenAL, PLIB, OSG) - but also changes to the C++ code in SG/FG itself.

People are generally quick to point at Nasal and its known GC issues, but are usually not experienced enough to look behind the scenes, and the amount of existing C++ code that is doing things in a slow fashion, code that's been lurking in the source tree for years more often than not. Creating some kind of simple benchmark would help all of us, no matter the kind of hardware we have: [[FlightGear_Benchmark]].

If you're interested in getting involved with testing FlightGear and improving compatibility for older/slow systems, please get in touch with Hooray on the forum.

<gallery mode=packed widths=230px heights=230px>
Fgfs 3.2 on a dual-core netbook.png|FlightGear 3.2/Canvas working on a dual-core Netbook with Intel GMA graphics showing the [[Interactive Nasal Console]] dialog
Comparing Native Canvas GUI Performance over PUI.png|A native [[Canvas]] window showing the new [[Aircraft Center]] dialog (good performance)
System-monitor-on-netbook.png|Screen shot showing a number of performance issues in a handful of FG subsystems, especially the PUI GUI
Pui slowness.png|The old PLIB/PUI GUI is shown here rendering a Canvas Widget with a [[MapStructure]] layer, a few users have reported that PUI is significantly slowing down the simulator
MapStructure self test over embedded PUI widget.png|And for comparison a native Canvas window also using the [[MapStructure]] framework,without going through PUI (better performance)
</gallery>

== Interview with a contributor ==

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.

'''What is your forum nickname, ZLSA?''' ZLSA.

'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?

'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.

'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.

'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.

'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.

'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

'''Have you previously used other flight simulators or simulation software in general?''' No.

'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?

'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

'''Have you ever used FlightGear professionally or for educational purposes?''' No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.

'''What about FlightGear as a "game", do you think it can be used as such?''' Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.

'''On average, how much time do you spend working with/contributing to FlightGear?''' Probably in the hundreds of hours at this point.

'''Which of the more recent FlightGear developments do you consider most interesting/appealing?''' Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.

'''Is there some feature that you'd truly like to see in FlightGear one day?''' Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)

'''What do you think could be done to attract even more new users and contributors to FlightGear?''' Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.

'''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' Back up your FlightGear data directory and play around with things.

'''Have you ever recommended FlightGear to other users, friends/family?''' No, whenever I mention it they suddenly disappear...

'''Is there anything else you'd like to share with us?''' No.

'''Good day then, and thanks for agreeing to this interview.''' No problem.

Switching default texture format to DDS

2014-09-04T15:14:43Z

Zlsa: Added my GPU/driver combination

{{WIP}}

== Feedback needed - should Flightgear switch the defaults to dds format for terrain texturing? ==

=== What is this about? ===

The FG development team is considering to switch the format for terrain textures from png to dds. This would offer a number of significant advantages:

* dds is a compressed format, hence the download size of the FG base package may be decreased
* compressed dds can be directly used by many graphics cards, reducing also GPU memory consumption
* dds stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
* the resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use dds for these reasons.

However, the dds compression algorithm is patented, which means that it is not readily available for OpenSource graphics drivers used by Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process dds, for older graphics cards there are non-patented workarounds available which decompress the dds on the software level). The development team is concerned about making the Flightgear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to textures in dds format with the 3.4 release, and then phase out the use of png textures.

== What would we need? ==

Flightgear already provides the simple option to test a dds texture set. If you are running on Linux and use an OpenSource graphics driver, please take 5 minutes to help during your next FG session:

* Open the dialog under View -> Rendering

* Under 'Terrain texture scheme', change the default 'Region-specific' to 'Global alternative (DDS format)'

* Press 'Okay' - FG will reload the terrain

* Do you see proper textures on the terrain (they may look different and may also not fit the location perfectly)? If yes, you're fine. If you see monochromatic colors or other rendering artifacts, your system may have problems with dds.

* Change back to the texture scheme you like best

* Enter your experiences in the list below

Thanks for your help!

== Tested hardware and graphis drivers ==

=== NVIDIA proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|GeForce GTX 670M
|310.19
|{{yes}}
|ThorstenR
|-
|GeForce GT 540M
|331.82
|{{yes}}
|Gijs
|-
|N13M-NS Optimus
|340.32
|{{yes}}
|Tom_ch
|-
|GeForce GT640
|343.13
|{{yes}}
|lumni1968
|-
|GeForce GTX 780 Ti
|340.52
|{{yes}}
|Avionyx
|-
|GeForce GT 750M
|331.38
|{{yes}}
|Dutchguy
|}

=== NVIDIA OpenSource driver ===

=== Intel proprietary driver ===

=== Intel OpenSource driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|HD Graphics 3000 (i7-2600K)
|10.2.6
|{{yes}}
|cdesai
|}

=== ATI/AMD proprietary driver ===
{| class="wikitable sortable"
!Card
!Driver
!DDS ok
!Reported by
|-
|ATI Radeon HD 6310
|14.6-1
|{{yes}}
|ZLSA
|}

=== ATI/AMD OpenSource driver ===

== Excerpts from the ongoing discussion ==

{{FGCquote
|Here is my suggestion how to proceed:

* Let's do your 1) and 2) on as many information channels we have.
* Collect the responses on a public place, I'd suggest a wiki page
* Do this for a well defined time frame. Is three month too much/too short?
* If we have the impression, it's safe to switch to DDS, define the dds texture sets as default, keeping the png sets as a fallback and publish how to use this fallback
* Keep this for one release.
* Depending on the feedback we get, keep it that way or move entirely to DDS.

Does that sound reasonable for everybody?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32788459/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|let's collect some some feedback until late November and restart this 
topic. We probably know by then what we do for the next release. 
 
"Somebody" needs to collect the feedback, however. That's definitely not 
me - any volunteers? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32791750/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-03</nowiki>
}}
}}

== Misc ==
{{FGCquote
|I'd propose [...] this process:
# Get out the information first that one can change materials files, where to do it and what the characteristics of the different sets are.
# Ask users (especially those running with ATI or Intel on Linux) nicely to do a quick check whether dds works fine.

I think we have an information management problem in relation to the user base - a frequent forum situation is that a user requests something that's already there, but the information is just not out. So if we even envision such a change, I would start spreading the relevant information basically yesterday.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Challenges ==
{{FGCquote
|"dds on an open source driver (radeon and intel) I was forced to use radeon at some time, and it was fun, the planes were pink :) once libtxc-dxtn installed, dds were loaded fine again, so it can be used on open source if you are ok to use the lib." 
 
Unless there's some way to make sure Linux users have that lib installed automatically, I'd say that's a no. We can't have a random user guess what additional packages to install. And maybe someone can educate me - googling the lib, this appears to be working for mesa - which usually is what we try to avoid if users do 3d rendering via mesa for performance reasons? 
 
Also, what does 'If you are okay to use the lib' mean precisely? If that's some piece of code which circumvents a patented thing and isn't exactly legal and needs to be obtained from special servers outside the normal repo (sort of like the DVD decryption under Linux), then I doubt that's an option. Can anyone clarify?
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32786414/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Another potential option would be to convert regions to .dds but keep 
both global-png and global-dds, but making that user-friendly would 
require a way to automatically detect lack of .dds support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|On my system (Intel Ivybridge), DDS works with or without libtxc, but 
this may not be true of all Intel hardware. 

|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787117/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|You can specify the dependency on libtxc_dxtn, but then distributions like 
openSUSE cannot ship FlightGear anymore. libtxc_dxtn implements S3 texture 
compression which is patented in many parts of the world. Linux distributions 
therefore cannot ship it. You can easily find it in add-on repositories, but 
as I said, distributions would not be able to include FlightGear creating a 
huge hurdle to installation for users.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787143/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Stefan Seifert</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Debian/Ubuntu's libtxc is libtxc-dxtn-s2tc, which claims to avoid the 
patent at a small cost in visual quality: 
https://github.com/divVerent/s2tc/wiki/libtxc_dxtn 
That site also states that modern hardware doesn't need this software 
fallback anyway (and hence won't hit either this quality loss or the 
slowness of any software decoder), but doesn't define "modern hardware".
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787296/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|The dds textures seem to have some advantages over our png textures and 
using them is tempting. 
But the points from Thorsten R. are good points and if there is any 
chance to have a step-wise transition to the new format, I'd prefer that 
path. 
 
Don't we have an alternate dds texture set already in fgdata that is 
enabled with an option? What about making this the default, keeping the 
png texture set as an alternate. That would get us reports from users 
unable to run dds textures and provide an easy fallback method.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787378/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|We currently have regions-png, global-png and global-dds; as I noted 
earlier, switching to regions-dds, global-png and global-dds has the 
issue that while changing the texture set is easy (dropdown in View > 
Rendering Options), knowing that one needs to do so may not be.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787717/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Can we invert the logic in, say, preferences.xml so xxx-dds is enabled 
by default and switching to xxx-png has to be done in rendering options? 
 
Torsten
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787787/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Torsten Dreyer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|Changing the default (which is in preferences.xml) is easy: the problem 
is how do users with non-.dds-supporting hardware (if this exists) know 
they need to change back.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787851/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Rebecca Palmer</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Conversion ==
{{FGCquote
|Automatic conversion script is welcome indeed. Also I'm pretty sure that we have some people here ready to convert a PNG to DDS as soon as you say "Hey boys I created a new PNG file, can you convert this file for me please ?" :-)
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785592/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Clement de l'Hamaide</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|A few world about the conversion: once a png/rgb/jpg found, the script 
try to guess the suitable dds format: with or without alpha channel, 
bumpmap, if a .dds is allready found we just erase the png one, if not 
we use nvcompress to get the dds. After we change the textures name 
called in the differents files and that's it. There's a way to tell the 
script what to do for each file, if the automatic mode is a failure. 
 
I guess speaking theorically is not the best to make an opinion, so if 
some of you are interested to make a test, I will make a 3.2 minimal dds 
fgdata this we, once on my FG pc.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}
== Pros ==
{{FGCquote
|I always got a loading problem with png textures, large textures take 
seconds to load and convert, and that ruin my close flight where you 
can't afford to take pause in the air. 
that's why i did a batch script to convert to dds ALL the textures in 
the data, not only the matérial set, but everything. Now i only flight a 
dds version of flightgear, and am quite happy with it, that's why i 
propose to provide a dds fgdata for test, and maybe to make it an 
alternate download possibility.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32785602/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>jean</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

== Contra ==
{{FGCquote
|FG actually runs with dds textures, it just doesn't render anything reasonable, I believe you get monochromatic colors. But I don't expect the menu to be affected, it doesn't use textures.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787957/
|title=<nowiki>Re: [Flightgear-devel] .dds textures (was Unused and/or sourceless textures‏)</nowiki>
|author=<nowiki>Renk Thorsten</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

{{FGCquote
|If it's relevant, I recall having S2TC compression problems when running Flightgear, and updating this package to a newer version manually (outside of the main repos) fixed the issue. I'm on an Intel HD 3000, but I'm guessing that Intel HD 4000 doesn't have this problem, since it seems to have better OpenGL and OpenCL support.
|{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32787875/
|title=<nowiki>Re: [Flightgear-devel] Download size,
and hardware support (was .dds textures)</nowiki>
|author=<nowiki>Saikrishna Arcot</nowiki>
|date=<nowiki>2014-09-02</nowiki>
}}
}}

FlightGear Newsletter September 2014

2014-09-04T15:14:32Z

Zlsa: Cleared up grammar with DDS section

Template:POTW/2014-36

2014-09-04T14:56:21Z

Zlsa: Fixed image link

{{POTW
|image = Piper Archer CX in flight with provisional texture.jpg
|description = The [[Piper Archer CX]] in flight over the Central Valley in California
|article = Piper_Archer_CX
}}<noinclude>[[Category:Picture of the week 2014]]<noinclude>

Template:POTW/2014-36

2014-09-04T14:54:30Z

Zlsa: Created page, added Piper Archer CX

<!-- There was no picture for this week so I self-promoted my own picture; if you want to change it feel free.

{{POTW
|image = Piper_Archer_CX_in_flight_with_provisional_texture.jpg
|description = The [[Piper Archer CX]] in flight over the Central Valley in California
|article = Piper_Archer_CX
}}<noinclude>[[Category:Picture of the week 2014]]<noinclude>

FlightGear Newsletter September 2014

2014-09-04T02:32:20Z

Zlsa: Dang wiki

{{Newsletter-header|September 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|(this is the second column)}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
|}
</div>

== Interview with a contributor ==

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.

'''What is your forum nickname, ZLSA?''' ZLSA.

'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?

'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.

'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.

'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.

'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.

'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

'''Have you previously used other flight simulators or simulation software in general?''' No.

'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?

'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

'''Have you ever used FlightGear professionally or for educational purposes?''' No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.

'''What about FlightGear as a "game", do you think it can be used as such?''' Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.

'''On average, how much time do you spend working with/contributing to FlightGear?''' Probably in the hundreds of hours at this point.

'''Which of the more recent FlightGear developments do you consider most interesting/appealing?''' Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.

'''Is there some feature that you'd truly like to see in FlightGear one day?''' Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)

'''What do you think could be done to attract even more new users and contributors to FlightGear?''' Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.

'''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' Back up your FlightGear data directory and play around with things.

'''Have you ever recommended FlightGear to other users, friends/family?''' No, whenever I mention it they suddenly disappear...

'''Is there anything else you'd like to share with us?''' No.

'''Good day then, and thanks for agreeing to this interview.''' No problem.

FlightGear Newsletter September 2014

2014-09-04T02:26:04Z

Zlsa: /* Interview with a contributor */ Grammar

{{Newsletter-header|September 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|(this is the second column)}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
|}
</div>

--[[User:Zlsa|Jon Ross]] ([[User talk:Zlsa|talk]]) 02:26, 4 September 2014 (UTC)--[[User:Zlsa|Jon Ross]] ([[User talk:Zlsa|talk]]) 02:26, 4 September 2014 (UTC)== Interview with a contributor ==

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.

'''What is your forum nickname, ZLSA?''' ZLSA.

'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?

'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.

'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.

'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.

'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.

'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

'''Have you previously used other flight simulators or simulation software in general?''' No.

'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?

'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

'''Have you ever used FlightGear professionally or for educational purposes?''' No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.

'''What about FlightGear as a "game", do you think it can be used as such?''' Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.

'''On average, how much time do you spend working with/contributing to FlightGear?''' Probably in the hundreds of hours at this point.

'''Which of the more recent FlightGear developments do you consider most interesting/appealing?''' Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.

'''Is there some feature that you'd truly like to see in FlightGear one day?''' Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)

'''What do you think could be done to attract even more new users and contributors to FlightGear?''' Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.

'''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' Back up your FlightGear data directory and play around with things.

'''Have you ever recommended FlightGear to other users, friends/family?''' No, whenever I mention it they suddenly disappear...

'''Is there anything else you'd like to share with us?''' No.

'''Good day then, and thanks for agreeing to this interview.''' No problem.

FlightGear Newsletter September 2014

2014-09-04T02:19:04Z

Zlsa: Finished interview.

{{Newsletter-header|September 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|(this is the second column)}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
|}
</div>

== Interview with a contributor ==

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used with FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.

'''What is your forum nickname, ZLSA?''' ZLSA.

'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?

'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.

'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.

'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.

'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.

'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

'''Have you previously used other flight simulators or simulation software in general?''' No.

'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?

'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

'''Have you ever used FlightGear professionally or for educational purposes?''' No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.

'''What about FlightGear as a "game", do you think it can be used as such?''' Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.

'''On average, how much time do you spend working with/contributing to FlightGear?''' Probably in the hundreds of hours at this point.

'''Which of the more recent FlightGear developments do you consider most interesting/appealing?''' Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.

'''Is there some feature that you'd truly like to see in FlightGear one day?''' Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)

'''What do you think could be done to attract even more new users and contributors to FlightGear?''' Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.

'''What about interacting with the FlightGear community? Any tips/experiences you'd like to share?''' Back up your FlightGear data directory and play around with things.

'''Have you ever recommended FlightGear to other users, friends/family?''' No, whenever I mention it they suddenly disappear...

'''Is there anything else you'd like to share with us?''' No.

'''Good day then, and thanks for agreeing to this interview.''' No problem.

Piper Archer CX

2014-09-04T00:38:46Z

Zlsa: Now has texture.

{{infobox Aircraft
| image = Piper_Archer_CX_in_flight_with_provisional_texture.jpg
| alt = External view with [[Atmospheric_light_scattering|ALS]] and [[advanced weather]] enabled
| image2 = Piper_Archer_CX_cockpit_view_with_Rembrandt.png
| alt2 = Cockpit view with Rembrandt enabled
| name = Piper Archer CX
| type = Civilian aircraft
| fdm = JSBSim
| status-fdm = 1
| status-systems = 3
| status-cockpit = 3
| status-model = 4
| authors = Jon Ross
| fgname = pa28-181, piper-archer-cx
| development = http://github.com/zlsa/pa28-181/
| download = http://zlsa.github.io/pa28-181/releases/pa28-181-latest.zip
}}

[[File:Rembrandtready.png|left]].

The [http://zlsa.github.io/pa28-181/ Piper Archer CX] is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe. Unlike its real-life counterparts, the Archer TX and LX, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Electrical system ==

The Piper Archer CX has a custom-made realistic electrical system; for example, the lights will dim when you crank the engine. The aircraft starts with the battery and alternator switches on which can be confirmed with the battery voltage gauge to the left of the pilot's yoke. If both the battery and alternator are turned off, no electrical systems will work (including the starter and fuel pump).

== Status ==

The exterior model is complete but needs livery support and a normal map; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like a Piper, but it has not been tested with regards to the real life Piper Archer TX.

== Feedback ==

Open a [https://github.com/zlsa/pa28-181/issues GitHub issue] if you've found anything wrong with the aircraft in any way.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]
[[Category:Civil_trainer_aircraft]]

File:Piper Archer CX in flight with provisional texture.jpg

2014-09-04T00:37:10Z

Zlsa: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Uses a temporary texture.}}
|date=2014-09-03 17:37:29
|source={{own}}
|author=[[User:Zlsa|Jon Ross]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Screenshots of civil utility aircraft]]

FlightGear Newsletter September 2014

2014-09-03T01:25:31Z

Zlsa: Grammar.

{{Newsletter-header|September 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|(this is the second column)}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
|}
</div>

== Interview with a contributor ==

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used with FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions.

'''What is your forum nickname, ZLSA?''' ZLSA.

'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?

'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.

'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.

'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.

'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.

'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

'''Have you previously used other flight simulators or simulation software in general?''' No.

'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?

'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

FlightGear Newsletter September 2014

2014-09-03T01:21:04Z

Zlsa: Created page, started self-interview.

{{Newsletter-header|September 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|(this is the second column)}} 
| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
|}
</div>

== Interview with a contributor ==

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used with FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask ''myself'' questions? Wait, nobody said I'd have to ask ''myself'' questions. I'm not ready for this!

'''What is your forum nickname, ZLSA?''' ZLSA.

'''How long have you been involved with FlightGear?''' The first version I used was 1.9.1, I think. So circa 2008?

'''What are your major interests in FlightGear?''' Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

'''I think you're pretty good at it.''' So my primary interest in FlightGear is modeling things; I modeled the [[Piper Archer CX]] exterior and interior. I also enjoy writing Nasal.

'''What projects are you working on right now?''' Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

'''What do you plan on doing in the future?''' Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

'''Why is it that you are interested in flight simulation or aviation in general?''' FlightGear sparked my interest in aviation when I first <s>played</s> used it. I was just wondering what this <code>fgfs</code> program was.

'''Are you happy with the way the FlightGear project is going?''' In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

'''What do you enjoy most about contributing to FlightGear?''' Seeing my creations used by other people.

'''Are there any "hidden features" you have worked on in FlightGear that new users may miss?''' Nope, sorry.

'''What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script?''' Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <nowiki><PropertyList></nowiki> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <nowiki><file></nowiki> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

'''Have you previously used other flight simulators or simulation software in general?''' No.

'''How does FlightGear compare in your opinion?''' If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

'''What was your first impression about FlightGear?''' How the heck do you pronounce ornithopter?

'''Compared to other flight simulation software, what are FlightGear's major benefits in your opinion?''' It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

'''Do you think it is necessary to know how to program in order to contribute to FlightGear?''' Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

User:Zlsa

2014-09-02T00:10:51Z

Zlsa: Created page

I'm a 3d modeler who likes accurate shapes at the cost of performance. I like [[Nasal]]. The [[Piper Archer CX]] is entirely my own work except for the textures and sounds.

Piper Archer CX

2014-09-01T22:20:43Z

Zlsa: added civil trainer tag

{{infobox Aircraft
| image = Piper_Archer_CX_with_ALS_in_flight.png
| alt = External view with [[Atmospheric_light_scattering|ALS]] and [[advanced weather]] enabled
| image2 = Piper_Archer_CX_cockpit_view_with_Rembrandt.png
| alt2 = Cockpit view with Rembrandt enabled
| name = Piper Archer CX
| type = Civilian aircraft
| fdm = JSBSim
| status-fdm = 1
| status-systems = 3
| status-cockpit = 3
| status-model = 4
| authors = Jon Ross
| fgname = pa28-181, piper-archer-cx
| development = http://github.com/zlsa/pa28-181/
| download = http://zlsa.github.io/pa28-181/releases/pa28-181-latest.zip
}}

[[File:Rembrandtready.png|left]].

The [http://zlsa.github.io/pa28-181/ Piper Archer CX] is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe. Unlike its real-life counterparts, the Archer TX and LX, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Electrical system ==

The Piper Archer CX has a custom-made realistic electrical system; for example, the lights will dim when you crank the engine. The aircraft starts with the battery and alternator switches on which can be confirmed with the battery voltage gauge to the left of the pilot's yoke. If both the battery and alternator are turned off, no electrical systems will work (including the starter and fuel pump).

== Status ==

The exterior model is complete but needs to be textured; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like a Piper, but it has not been tested with regards to the real life Piper Archer TX.

There are no textures on most surfaces yet; I want to get feedback about modeling inaccuracies first.

== Feedback ==

Open a [https://github.com/zlsa/pa28-181/issues GitHub issue] if you've found anything wrong with the aircraft in any way.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]
[[Category:Civil_trainer_aircraft]]

User talk:Zlsa

2014-09-01T22:08:08Z

Zlsa: /* Categories versus tags */

== Categories versus tags ==
I see that you use often add several categories when you upload screenshots. The categories are not really tags, but more or less "a couple of trees with some cobwebs". Usually it is sufficient to use one or maybe two categories as far out in the branches as possible.

To get an idea of the tree structure, click a category link at the bottom of a page and browse around the category pages (have you tested clicking the blue triangles in front of some subcategories?). Another tool I use a ''lot'' is the [[Special:CategoryTree/Screenshots of aircraft|category tree browser]].

Apart from that, please continue. :-)

—[[User:Johan G|Johan G]] ([[User_talk:Johan_G|Talk]] | [[Special:Contributions/Johan_G|contribs]]) 21:59, 1 September 2014 (UTC)

I didn't even know it was the same category tree, thanks! I'm new to MediaWiki.

[[User:Zlsa|Jon Ross]] ([[User talk:Zlsa|talk]]) 22:08, 1 September 2014 (UTC)

Piper Archer CX

2014-09-01T21:42:24Z

Zlsa: Moved rembrandt badge

FlightGear Newsletter August 2014

2014-09-01T21:40:21Z

Zlsa: Added Piper CX

{{Newsletter-header|August 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|3.2 Released}} 
{{Newsletter-cover-header|Development news}} 
{{Newsletter-cover-item|FGCamera 1.0 Released}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery corner}} 
{{Newsletter-cover-item|Yongphulla Domestic Airport - VQ10}} 
{{Newsletter-cover-header|Other}} 
{{Newsletter-cover-item|FG logo proposal by Cossack90}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|In the hangar}} 
{{Newsletter-cover-item|Beechcraft B1900D template}} 
{{Newsletter-cover-item|Eurofighter EF2000}} 
{{Newsletter-cover-item|Piper Archer CX}} 
{{Newsletter-cover-header|Multiplayer events}} 
|}
</div>
==3.2 Released==
The FlightGear development team is delighted to announce that the long awaited v3.2 release of FlightGear, the free, open-source flight simulator has been released on  INSERT FINAL RELEASE DATE HERE. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include:

* Optional cloud shadows if [[advanced weather]] and [[atmospheric light scattering]] are enabled

Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

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

Download FlightGear v3.2 for free from [http://www.flightgear.org FlightGear.org]

FlightGear - Fly Free!
''Read more at: [[Next Changelog|Version 3.2 Changelog]]''

==Development news==
===FGCamera 1.0 Released===
{{#ev:youtube|DMZB7QXpR9I|250|right|FGCamera v1.0 in action}}
FGCamera v1.0 is available to download. Features of current version:
* 4 camera types:
** Virtual cockpit,
** Aircraft (look-at),
** Aircraft (look-from),
** World (look-from);
* Arbitrary number of preset views;
* Smooth/discrete transition between the views of the same camera type.

v1.0 has graphical user interface to create and manage camera views:

<gallery widths=200px heights=200px>
Fgcamera main dialog.jpg|Main dialog with cameras management tools.
Fgcamera new camera dialog.jpg|Dialog used to create new cameras. Four camera types are available
Fgcamera camera settings dialog.jpg|Settings for currently selected camera
</gallery>
Read more at updated [http://wiki.flightgear.org/FGCamera FGCamera wiki article].

==Scenery corner==
===Yongphulla Domestic Airport - VQ10===
High mountains, deep valleys, strong winds and sometimes the rain looks something like snow. You are at the Bhutanese '''[[Yongphulla Airport|Yongphula Domestic Airport]]''' (VQ10) at an altitude of 2573 metres. After [[Paro Airport|Paro]], this airport has been improved. Besides the Terminal and Apron, shared models and other little things have now been added. [[TerraSync]] has it all! Have a nice flight in the Kingdom of Bhutan.
<gallery mode=packed heights=240px>
VQ10 Yongphula Airport.jpg|Yonghula Airport
VQ10 Yongphula Apron.jpg|Tower and Terminal of Yongphula
</gallery>

==In the Hangar==
===Beechcraft B1900D template===
A new template for the [[Beechcraft_B1900D|Beechcraft B1900D]] is available in the [http://liveries.flightgear.org/paintkits.php Paintkits] section of the [http://liveries.flightgear.org/ flightgear liveries database website]. The template comes in svg format (best used with [http://www.inkscape.org Inkscape]) and features:
* full rivets, panel lines and stencils details in vector format
* ambient occlusion layer
* dirt layer
Some B1900d liveries made with this template are available to download in the [http://liveries.flightgear.org/aircraft.php?limit=25&display=2&page=0&id=21 flightgear liveries database website]

===Eurofighter EF2000===
{{#ev:youtube|_MaxljfrPBY||right|A brief in-cockpit demo of the EF2000's FCS}}
A big milestone has been achieved in the ongoing development of the EF2000, which I (Algernon) has been managing since its branching from the main Eurofighter Typhoon project some years back: finally, after a lot of fiddling, a completely computerised Flight Control System (FCS) has been implemented which can simulate its real-life counterpart, with fully autonomous surface control and with an autopilot-based processor interpreting pilot input and commanding the system to fly its maximum performance envelope to obey, but not exceed, safety or design limits. While a lot of these features are not yet implemented, we have established a working practice for the core system which allows extra elements to be introduced simply and effectively. I have heard it said that FG is incapable of simulating such systems, and I hope here we have proved otherwise, and, a bit self-indulgently, that maybe this will be the first truly fly-by-wire aircraft in FlightGear! (I am of course prepared to stand corrected there...)

Particular thanks for this objective go to StuartC, who designed the basis of the FDM, and Tomaskom, whose help in fields where I am not much of a master (like mathematics) has been invaluable. Many updates are planned for the EF2000, including a whole new custom paintjob with many liveries, and it is hoped a final, V2.0 release may be available in the later part of the year. You can also get hold of a pre-release copy if you visit the [http://fguk.eu/index.php/forum/index FGUK Forum] and register your interest, for testing purposes - your feedback will be appreciated. Pre-releases will probably not be available until at least September 2014.

Other points being addressed in the V2.0 release of the Eurofighter Typhoon 2000 are:

* New modular Nasal approach and many new scripts. Upgraded to Eno audio management.
* New UV map for N-SCOT, leading to sexy new textures and liveries and hopefully a paintkit too
* Improvements to helmet-mounted display and HUD for improved navigation, target acquisition and weapons management
* Disintegration, explosion, real damage and real maintenance
* External lighting redesigned
* Experimental and deprecated code bumph removed

===Piper Archer CX===

[[File:Piper_Archer_CX_with_ALS_in_flight.png|thumb|left|alt=The Piper Archer CX in flight with ALS and advanced weather enabled|Exterior view of the Archer CX]]
[[File:Piper_Archer_CX_cockpit_view_with_Rembrandt.png|thumb|alt=The cockpit of the Archer CX with Rembrandt enabled|Cockpit view of the Archer CX]]

A new aircraft is now available for testing: the semi-fictional [[Piper Archer CX]] single-engine trainer aircraft. While based mostly on the real life Piper Archer TX and LX, it features an analog cockpit such as seen in the Piper Archer II/III. It's completely Rembrandt-ready and features a highly detailed interior and exterior, along with a realistic electrical system. If you'd like, download the [http://zlsa.github.io/pa28-181/ beta build] and test it; report any inaccuracies to the [http://forum.flightgear.org/viewtopic.php?t=23962 forum thread] dedicated to it. Note that the aircraft uses a highly-detailed model and is not suitable for lower-end hardware. It's being actively developed by ZLSA, and the exterior will be textured as soon as most modeling/simulation inaccuracies have been resolved.

Currently, all exterior control surfaces are modeled and animated; details can be added once I find decent reference images of the Piper Archer TX/LX. The interior features detailed 3d instruments, all modeled to fit the cockpit, and the realistic electrical system uses Rembrandt-compatible lights. If you find any inaccuracies or flaws, do not hesitate to report it on the [http://forum.flightgear.org/viewtopic.php?t=23962 forum thread]; I highly appreciate any criticism as it will help improve the final product.

If there are enough requests, the creation of a TX/LX glass cockpit version will be considered.

 

== Other ==

=== FG logo proposal by Cossack90 ===

Cossack90 proudly presents a proposal for a new FlightGear logo. I hope you like it.
[[File:Logo proposal by Cossack90.png|thumb|FG logo proposal by Cossack90 aka UR-AOK]]

Piper Archer CX

2014-09-01T21:18:48Z

Zlsa: Added Rembrandt-ready badge

{{infobox Aircraft
| image = Piper_Archer_CX_with_ALS_in_flight.png
| alt = External view with [[Atmospheric_light_scattering|ALS]] and [[advanced weather]] enabled
| image2 = Piper_Archer_CX_cockpit_view_with_Rembrandt.png
| alt2 = Cockpit view with Rembrandt enabled
| name = Piper Archer CX
| type = Civilian aircraft
| fdm = JSBSim
| status-fdm = 1
| status-systems = 3
| status-cockpit = 3
| status-model = 4
| authors = Jon Ross
| fgname = pa28-181, piper-archer-cx
| development = http://github.com/zlsa/pa28-181/
| download = http://zlsa.github.io/pa28-181/releases/pa28-181-latest.zip
}}

[[File:Rembrandtready.png]].

The [http://zlsa.github.io/pa28-181/ Piper Archer CX] is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe. Unlike its real-life counterparts, the Archer TX and LX, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Electrical system ==

The Piper Archer CX has a custom-made realistic electrical system; for example, the lights will dim when you crank the engine. The aircraft starts with the battery and alternator switches on which can be confirmed with the battery voltage gauge to the left of the pilot's yoke. If both the battery and alternator are turned off, no electrical systems will work (including the starter and fuel pump).

== Status ==

The exterior model is complete but needs to be textured; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like a Piper, but it has not been tested with regards to the real life Piper Archer TX.

There are no textures on most surfaces yet; I want to get feedback about modeling inaccuracies first.

== Feedback ==

Open a [https://github.com/zlsa/pa28-181/issues GitHub issue] if you've found anything wrong with the aircraft in any way.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Piper Archer CX

2014-09-01T20:32:27Z

Zlsa: Changed image

{{infobox Aircraft
| image = Piper_Archer_CX_with_ALS_in_flight.png
| alt = External view with [[Atmospheric_light_scattering|ALS]] and [[advanced weather]] enabled
| image2 = Piper_Archer_CX_cockpit_view_with_Rembrandt.png
| alt2 = Cockpit view with Rembrandt enabled
| name = Piper Archer CX
| type = Civilian aircraft
| fdm = JSBSim
| status-fdm = 1
| status-systems = 3
| status-cockpit = 3
| status-model = 4
| authors = Jon Ross
| fgname = pa28-181, piper-archer-cx
| development = http://github.com/zlsa/pa28-181/
| download = http://zlsa.github.io/pa28-181/releases/pa28-181-latest.zip
}}

The [http://zlsa.github.io/pa28-181/ Piper Archer CX] is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe. Unlike its real-life counterparts, the Archer TX and LX, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Electrical system ==

The Piper Archer CX has a custom-made realistic electrical system; for example, the lights will dim when you crank the engine. The aircraft starts with the battery and alternator switches on which can be confirmed with the battery voltage gauge to the left of the pilot's yoke. If both the battery and alternator are turned off, no electrical systems will work (including the starter and fuel pump).

== Status ==

The exterior model is complete but needs to be textured; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like a Piper, but it has not been tested with regards to the real life Piper Archer TX.

There are no textures on most surfaces yet; I want to get feedback about modeling inaccuracies first.

== Feedback ==

Open a [https://github.com/zlsa/pa28-181/issues GitHub issue] if you've found anything wrong with the aircraft in any way.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

File:Piper Archer CX with ALS in flight.png

2014-09-01T20:30:47Z

Zlsa: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=The Piper Archer CX with ALS and advanced weather enabled}}
|date=2014-09-01 13:29:36
|source={{own}}
|author=[[User:Zlsa|Jon Ross]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Screenshots]]
[[Category:Screenshots of aircraft]]

Piper Archer CX

2014-09-01T17:43:30Z

Zlsa: Removed fuel systems section

{{infobox Aircraft
| image = Piper_Archer_CX_external_view_with_Rembrandt.png
| alt = External view with Rembrandt enabled
| image2 = Piper_Archer_CX_cockpit_view_with_Rembrandt.png
| alt2 = Cockpit view with Rembrandt enabled
| name = Piper Archer CX
| type = Civilian aircraft
| fdm = JSBSim
| status-fdm = 1
| status-systems = 3
| status-cockpit = 3
| status-model = 4
| authors = Jon Ross
| fgname = pa28-181, piper-archer-cx
| development = http://github.com/zlsa/pa28-181/
| download = http://zlsa.github.io/pa28-181/releases/pa28-181-latest.zip
}}

The [http://zlsa.github.io/pa28-181/ Piper Archer CX] is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe. Unlike its real-life counterparts, the Archer TX and LX, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Electrical system ==

The Piper Archer CX has a custom-made realistic electrical system; for example, the lights will dim when you crank the engine. The aircraft starts with the battery and alternator switches on which can be confirmed with the battery voltage gauge to the left of the pilot's yoke. If both the battery and alternator are turned off, no electrical systems will work (including the starter and fuel pump).

== Status ==

The exterior model is complete but needs to be textured; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like a Piper, but it has not been tested with regards to the real life Piper Archer TX.

There are no textures on most surfaces yet; I want to get feedback about modeling inaccuracies first.

== Feedback ==

Open a [https://github.com/zlsa/pa28-181/issues GitHub issue] if you've found anything wrong with the aircraft in any way.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Piper Archer CX

2014-09-01T17:38:59Z

Zlsa: fixed markup right curly brace bug

{{infobox Aircraft
| image = Piper_Archer_CX_external_view_with_Rembrandt.png
| alt = External view with Rembrandt enabled
| image2 = Piper_Archer_CX_cockpit_view_with_Rembrandt.png
| alt2 = Cockpit view with Rembrandt enabled
| name = Piper Archer CX
| type = Civilian aircraft
| fdm = JSBSim
| status-fdm = 1
| status-systems = 3
| status-cockpit = 3
| status-model = 4
| authors = Jon Ross
| fgname = pa28-181, piper-archer-cx
| development = http://github.com/zlsa/pa28-181/
| download = http://zlsa.github.io/pa28-181/releases/pa28-181-latest.zip
}}

The Piper Archer CX is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe.

== Variants ==

The CX is a fictional variant of the Piper Archer TX/LX series; while both the Archer TX and LX have glass cockpits, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Fuel system ==

The Piper Archer CX starts with the collector tank half full; you can start the engines by turning the key to the right three times (press {{key press|<nowiki>}</nowiki>}} three times), then start it by holding down either {{key press|s}} or {{key press|<nowiki>}</nowiki>}} until the engine starts.

== Electrical system ==

The Piper Archer CX has a custom-made realistic electrical system; for example, the lights will dim when you crank the engine. The aircraft starts with the battery and alternator switches on (which can be confirmed with the battery voltage gauge to the left of the pilot's yoke). If both the battery and alternator are turned off, all electrical systems will not work (including the starter and fuel pump); if only the alternator is on but the engine is off, there will be no power as well.

== Status ==

The exterior model is complete but needs to be textured; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like a Piper, but it has not been tested with regards to the real life Piper Archer TX.

There are no textures on most surfaces yet; I want to get feedback about modeling inaccuracies first.

== Feedback ==

Open a [https://github.com/zlsa/pa28-181/issues GitHub issue] if you've found anything wrong with the aircraft in any way.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Piper Archer CX

2014-09-01T17:33:51Z

Zlsa: Huge edits

{{infobox Aircraft
| image = Piper_Archer_CX_external_view_with_Rembrandt.png
| alt = External view with Rembrandt enabled
| image2 = Piper_Archer_CX_cockpit_view_with_Rembrandt.png
| alt2 = Cockpit view with Rembrandt enabled
| name = Piper Archer CX
| type = Civilian aircraft
| fdm = JSBSim
| status-fdm = 1
| status-systems = 3
| status-cockpit = 3
| status-model = 3
| authors = Jon Ross
| fgname = pa28-181, piper-archer-cx
| development = http://github.com/zlsa/pa28-181/
| download = http://zlsa.github.io/pa28-181/releases/pa28-181-latest.zip
}}

The Piper Archer CX is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe.

== Variants ==

The CX is a fictional variant of the Piper Archer TX/LX series; while both the Archer TX and LX have glass cockpits, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Fuel system ==

The Piper Archer CX starts with the collector tank half full; you can start the engines by turning the key to the right three times (press {{key press|\}}} three times), then start it by holding down either {{key press|s}} or {{key press|\}}}.

== Electrical system ==

The Piper Archer CX has a custom-made realistic electrical system; for example, the lights will dim when you crank the engine. The aircraft starts with the battery and alternator switches on (which can be confirmed with the battery voltage gauge to the left of the pilot's yoke). If both the battery and alternator are turned off, all electrical systems will not work (including the starter and fuel pump); if only the alternator is on but the engine is off, there will be no power as well.

== Status ==

The exterior model is complete but needs to be textured; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like a Piper, but it has not been tested with regards to the real life Piper Archer TX.

There are no textures on most surfaces yet; I want to get feedback about modeling inaccuracies first.

== Feedback ==

Open a [https://github.com/zlsa/pa28-181/issues GitHub issue] if you've found anything wrong with the aircraft in any way.

== Development ==

The aircraft is hosted on GitHub: https://github.com/zlsa/pa28-181.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

File:Piper Archer CX external view with Rembrandt.png

2014-09-01T17:15:27Z

Zlsa: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Piper Archer CX in flight with Rembrandt enabled}}
|date=2014-09-01 10:15:31
|source={{own}}
|author=[[User:Zlsa|Jon Ross]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Screenshots]]
[[Category:Screenshots of aircraft]]
[[Category:Civilian aircraft]]

File:Piper Archer CX cockpit view with Rembrandt.png

2014-09-01T17:13:36Z

Zlsa: User created page with UploadWizard

=={{int:filedesc}}==
{{Information
|description={{en|1=Piper Archer CX cockpit view with Rembrandt}}
|date=2014-09-01 10:12:33
|source={{own}}
|author=[[User:Zlsa|Jon Ross]]
|permission=
|other_versions=
}}

=={{int:license-header}}==
{{self|cc-zero}}

[[Category:Screenshots]]
[[Category:Screenshots of aircraft]]
[[Category:Civil trainer aircraft]]
[[Category:Piper]]

FlightGear Newsletter August 2014

2014-09-01T13:50:15Z

Zlsa: Expanded article and cleaned up grammar

{{Newsletter-header|August 2014}}
<div style="border-bottom:3px double #BBB;">
{| width="100%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|3.2 Released}} 
{{Newsletter-cover-header|Development news}} 
{{Newsletter-cover-item|FGCamera 1.0 Released}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|Scenery corner}} 
{{Newsletter-cover-item|Yongphulla Domestic Airport - VQ10}} 
{{Newsletter-cover-header|Other}} 
{{Newsletter-cover-item|FG logo proposal by Cossack90}} 
| valign="top" width="33%" |
{{Newsletter-cover-header|In the hangar}} 
{{Newsletter-cover-item|Beechcraft B1900D template}} 
{{Newsletter-cover-header|Multiplayer events}} 
|}
</div>
==3.2 Released==
The FlightGear development team is delighted to announce that the long awaited v3.2 release of FlightGear, the free, open-source flight simulator has been released on  INSERT FINAL RELEASE DATE HERE. This new version contains many exciting new features, enhancements and bugfixes. Highlights in this release include:

* Optional cloud shadows if [[advanced weather]] and [[atmospheric light scattering]] are enabled

Founded in 1997, FlightGear is developed by a worldwide group of volunteers, brought together by a shared ambition to create the most realistic flight simulator possible that is free to use, modify and distribute. FlightGear is used all over the world by desktop flight simulator enthusiasts, for research in universities and for interactive exhibits in museums.

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

Download FlightGear v3.2 for free from [http://www.flightgear.org FlightGear.org]

FlightGear - Fly Free!
''Read more at: [[Next Changelog|Version 3.2 Changelog]]''

==Development news==
===FGCamera 1.0 Released===
{{#ev:youtube|DMZB7QXpR9I|250|right|FGCamera v1.0 in action}}
FGCamera v1.0 is available to download. Features of current version:
* 4 camera types:
** Virtual cockpit,
** Aircraft (look-at),
** Aircraft (look-from),
** World (look-from);
* Arbitrary number of preset views;
* Smooth/discrete transition between the views of the same camera type.

v1.0 has graphical user interface to create and manage camera views:

<gallery widths=200px heights=200px>
Fgcamera main dialog.jpg|Main dialog with cameras management tools.
Fgcamera new camera dialog.jpg|Dialog used to create new cameras. Four camera types are available
Fgcamera camera settings dialog.jpg|Settings for currently selected camera
</gallery>
Read more at updated [http://wiki.flightgear.org/FGCamera FGCamera wiki article].

==Scenery corner==
===Yongphulla Domestic Airport - VQ10===
High mountains, deep valleys, strong winds and sometimes the rain looks something like snow. You are at the Bhutanese '''[[Yongphulla Airport|Yongphula Domestic Airport]]''' (VQ10) at an altitude of 2573 metres. After [[Paro Airport|Paro]], this airport has been improved. Besides the Terminal and Apron, shared models and other little things have now been added. [[TerraSync]] has it all! Have a nice flight in the Kingdom of Bhutan.
<gallery mode=packed heights=240px>
VQ10 Yongphula Airport.jpg|Yonghula Airport
VQ10 Yongphula Apron.jpg|Tower and Terminal of Yongphula
</gallery>

==In the Hangar==
===Beechcraft B1900D template===
A new template for the [[Beechcraft_B1900D|Beechcraft B1900D]] is available in the [http://liveries.flightgear.org/paintkits.php Paintkits] section of the [http://liveries.flightgear.org/ flightgear liveries database website]. The template comes in svg format (best used with [http://www.inkscape.org Inkscape]) and features:
* full rivets, panel lines and stencils details in vector format
* ambient occlusion layer
* dirt layer
Some B1900d liveries made with this template are available to download in the [http://liveries.flightgear.org/aircraft.php?limit=25&display=2&page=0&id=21 flightgear liveries database website]

===Eurofighter EF2000===
{{#ev:youtube|_MaxljfrPBY||right|A brief in-cockpit demo of the EF2000's FCS}}
A big milestone has been achieved in the ongoing development of the EF2000, which I (Algernon) has been managing since its branching from the main Eurofighter Typhoon project some years back: finally, after a lot of fiddling, a completely computerised Flight Control System (FCS) has been implemented which can simulate its real-life counterpart, with fully autonomous surface control and with an autopilot-based processor interpreting pilot input and commanding the system to fly its maximum performance envelope to obey, but not exceed, safety or design limits. While a lot of these features are not yet implemented, we have established a working practice for the core system which allows extra elements to be introduced simply and effectively. I have heard it said that FG is incapable of simulating such systems, and I hope here we have proved otherwise, and, a bit self-indulgently, that maybe this will be the first truly fly-by-wire aircraft in FlightGear! (I am of course prepared to stand corrected there...)

Particular thanks for this objective go to StuartC, who designed the basis of the FDM, and Tomaskom, whose help in fields where I am not much of a master (like mathematics) has been invaluable. Many updates are planned for the EF2000, including a whole new custom paintjob with many liveries, and it is hoped a final, V2.0 release may be available in the later part of the year. You can also get hold of a pre-release copy if you visit the [http://fguk.eu/index.php/forum/index FGUK Forum] and register your interest, for testing purposes - your feedback will be appreciated. Pre-releases will probably not be available until at least September 2014.

Other points being addressed in the V2.0 release of the Eurofighter Typhoon 2000 are:

* New modular Nasal approach and many new scripts. Upgraded to Eno audio management.
* New UV map for N-SCOT, leading to sexy new textures and liveries and hopefully a paintkit too
* Improvements to helmet-mounted display and HUD for improved navigation, target acquisition and weapons management
* Disintegration, explosion, real damage and real maintenance
* External lighting redesigned
* Experimental and deprecated code bumph removed

== Other ==
=== FG logo proposal by Cossack90 ===
Cossack90 proudly presents a FlightGear logo proposal. I hope you like it.
[[File:Logo proposal by Cossack90.png|thumb|FG logo proposal by Cossack90 aka UR-AOK]]

Anti-aliasing

2014-09-01T04:19:48Z

Zlsa: Clarified text

By default, [[FlightGear]] will not use [http://en.wikipedia.org/wiki/Anti-aliasing '''anti-aliasing'''] during the simulation. This results in incorrect rendering of sharp straight lines and very small objects. In order to correct this, you can apply the anti-aliasing function; however, this will slow down rendering and is not guaranteed to work on all graphics cards.
== Example ==
{{Gallery
|height = 300
|width = 300
|No-anti-aliasing.png|Anti-aliasing disabled
|With-anti-aliasing.png|Anti-aliasing enabled
}}

== How to set anti-aliasing ==
=== Command line ===
When starting FlightGear via the [[command line]], add the following two arguments:
--prop:/sim/rendering/multi-sample-buffers=1
--prop:/sim/rendering/multi-samples=4

=== FGRun ===
[[File:Fgrun-anti-aliasing.png|200px|thumb|right|Setting anti-aliasing in FGrun]]
When you use [[FGRun]], add these commands under ''Advanced... > Properties''.

=== Rembrandt ===
Antialiasing does not work with [[rembrandt]] enabled due to GLSL limitations; some graphics cards have hardware antialising which may work.

== Options ==
If preferred, you can choose another value for the number of samples. The number has to be greater than 1. The greater the number of samples, the slower rendering will be.

Credits: Thanks to ''fredb'' for publishing this information in the [http://forum.flightgear.org/viewtopic.php?f=5&t=10007 FlightGear forum].

[[Category:FlightGear feature]]

[[fr:Anti-aliasing]]

Piper Archer CX

2014-08-31T22:43:49Z

Zlsa: WIP editing

{{infobox Aircraft

|name = Piper Archer TX
|type = Civilian aircraft
|fdm = JSBSim
|status = beta
|authors = Jon Ross
|fgname = pa28-181
}}

The Piper Archer CX is a low wing, single engine semi-fictional civilian aircraft based off of the Piper Cherokee airframe.

== Variants ==

The CX is a fictional variant of the Piper Archer TX/LX series; while both the Archer TX and LX have glass cockpits, the CX (C for conventional cockpit) uses old-style analog gauges similar to the ones used in the Piper Archer II/III aircraft.

== Status ==

The exterior model is complete but needs to be textured; the interior is highly detailed, with most of the major instruments in place. The FDM is a tweaked Aeromatic FDM that feels like the PA28-161 in FlightGear, but it has not been tested with regards to the real life Piper Archer TX.

There are no textures on most surfaces yet; I want to get feedback about modeling inaccuracies first.

== Development ==

The aircraft is hosted on GitHub: https://github.com/zlsa/pa28-181.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Piper Archer TX

2014-08-31T21:56:04Z

Zlsa: Zlsa moved page Piper Archer TX to Piper Archer CX: The Archer TX uses a glass panel...

#REDIRECT [[Piper Archer CX]]

Piper Archer CX

2014-08-31T21:55:49Z

Zlsa: Zlsa moved page Piper Archer TX to Piper Archer CX: The Archer TX uses a glass panel...

{{infobox Aircraft

|name = Piper Archer TX
|type = Civilian aircraft
|fdm = JSBSim
|status = development
|authors = Jon Ross
|fgname = pa28-181
}}

The Piper Archer TX is a low wing, single engine civilian aircraft based off of the Piper Cherokee airframe.

== Development ==

The aircraft is hosted on GitHub: https://github.com/zlsa/pa28-181.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Bindings

2014-08-31T18:13:32Z

Zlsa: /* property-adjust */ replaced incorrect "factor" with "step", added comments

{{Incomplete}}

'''Bindings''' define what happens when a user:
* [[Howto: Make a clickable panel#Pick|clicks an object]] in the [[scenery]] or an [[aircraft]]
* press a key on the keyboard or [[joystick]]
* clicks a [[menu]] item
* click a buttons or fields in a dialog
You can assign multiple bindings to one object/button/key. Each binding may contain one [[conditions|condition]] element to make it conditionally executed. Each binding must specify a command node with its particular type, see below.

This article gives a small overview of frequently used bindings. Please refer to <tt>[[$FG_ROOT]]/Docs/README.commands</tt> for additional information and a complete list of available bindings.

All given codes are examples, found on various places in the [[FlightGear]] package.

== Commands ==

Below are a number of useful commands. See further [http://mapserver.flightgear.org/git/?p=flightgear;a=blob;f=src/Main/fg_commands.cxx;h=4c3272916f56a3180e29b9d8457e697bb71cfecb;hb=HEAD#l1555 fg_commands.cxx].

To learn more about adding your own custom fgcommands to the source code, see [[Howto:Add new fgcommands to FlightGear]]

=== dialog-close ===
Closes the active dialog.
<syntaxhighlight>
<binding>
<command>dialog-close</command>
</binding>
</syntaxhighlight>

=== dialog-show ===
Shows a dialog, which should be present in <tt>[[$FG ROOT]]/gui/dialogs</tt>. Starting with FlightGear 2.7 dialog files located in <tt><Current aircraft directory>/gui/dialogs</tt> are also loaded. This should be used for dialogs specific to a certain aircraft.
<syntaxhighlight>
<binding>
<command>dialog-show</command>
<dialog-name>location-in-air</dialog-name>
</binding>
</syntaxhighlight>
* '''dialog-name:''' the name of the dialog, as designated in its .xml file.

=== nasal ===
[[Nasal]] is frequently used for complicated systems, because it can execute virtually any function and allows running previously-defined Nasal functions.
<syntaxhighlight>
<binding>
<command>nasal</command>
<script>b777.afds.input(0,1);</script>
</binding>
</syntaxhighlight>
The [[List of Nasal extension functions#cmdarg.28.29|cmdarg()]] function is often useful in these situations to extract offset values passed to the binding. It returns the specific <tt><binding></tt> node, which contains a <tt><setting></tt> node at runtime if used in a joystick axis that represents the value of that axis.

In joysticks and keyboard keys the script is run in a specific namespace; please refer to the documentation for what the namespace is.

=== property-adjust ===
Increases or decreases a property's value with a given step. Maximum and minimum values are optional.
<syntaxhighlight>
<binding>
<command>property-adjust</command>
<property>/autopilot/settings/heading-bug-deg</property>
<step>1</step> 
<min>000</min> 
<max>360</max> 
<wrap>true</wrap> 
</binding>
</syntaxhighlight>

=== property-assign ===
One of the most important commands. It sets a property to a predefined value.
<syntaxhighlight>
<binding>
<command>property-assign</command>
<property>/autopilot/settings/target-speed-kt</property>
<value>0</value>
</binding>
</syntaxhighlight>

=== property-cycle ===
Cycles between a list of values and assigns one to a property. The value-list can vary in length. If the current value is "value1", it will change to "value2"; if it is "value2", it will change to "value3", and so on, wrapping around the end. If the current value is not in the list, it will jump to the first one.
<syntaxhighlight>
<binding>
<command>property-cycle</command>
<property>/autopilot/autobrake/setting</property>
<value type="string">ARM</value>
<value type="string">DISARM</value>
<value type="string">OFF</value>
</binding>
</syntaxhighlight>
As of May 2013, the command supports additional behaviours to simplify use with the new [[Knob_/_slider_animation|knob and slider animations]]. The wrapping behaviour can be disabled by setting <wrap>0</wrap>, and the command uses the 'offset' argument to select a direction of movement. This means a property-cycle bound to a multi-position knob will function as expected for movement in both directions.

=== property-interpolate ===
Interpolates to a value with a given rate of change (per second).
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<value type="double">0</value>
<rate>0.5</rate>
</binding>
</syntaxhighlight>

Instead of using <rate>, one could use <time>, to specify the time (in seconds) it takes to go to the new value, independent of the current value.
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<value type="double">0</value>
<time>2</time>
</binding>
</syntaxhighlight>

You can also interpolate to a value given by a property.
<syntaxhighlight lang="xml">
<binding>
<command>property-interpolate</command>
<property>/controls/flight/aileron-trim</property>
<property>/controls/flight/default-aileron-trim</property>
<rate>0.5</rate>
</binding>
</syntaxhighlight>

=== property-multiply ===
Multiply the value of a property by a given factor.
<syntaxhighlight>
<binding>
<command>property-multiply</command>
<property>/controls/flight/aileron</property>
<factor>0.5</factor>
<min>-1</min>
<max>1</max>
<mask>all</mask>
<wrap>true</wrap>
</binding>
</syntaxhighlight>
*'''factor:''' the amount to multiply by.
*'''min:''' minimum value.
*'''max:''' maximum value.
*'''mask:'''
** '''integer:''' mutiply only left of the decimal point.
** '''decimal:''' multiply only the right of the decimal point.
** '''all:''' multiply the entire value.
*'''wrap:''' true if the value should be wrapped if it passes min/max. It is required to set both min and max in that case.

=== property-randomize ===
Assigns a random value (between min and max) to a property.
<syntaxhighlight>
<binding>
<command>property-randomize</command>
<property>/orientation/pitch-deg</property>
<min>0</min>
<max>360</max>
</binding>
</syntaxhighlight>

=== property-scale ===
Set the value of a property based on an axis, often used in [[joystick]] configuration files.
<syntaxhighlight>
<binding>
<command>property-scale</command>
<property>/controls/flight/aileron</property>
<offset>0.001</offset>
<factor>-1</factor>
<power>3</power>
</binding>
</syntaxhighlight>

* '''offset:''' the offset to shift by, before applying the factor.
* '''factor:''' the factor to multiply by (use negative to reverse).
* '''squared:''' if true will square the resulting value (same as power=2).
* '''power:''' the resulting value will be taken to the power of this integer value (overrides squared).

Remember: <tt>((property+offset)*factor)^power=result</tt>

=== property-swap ===
Swaps the values of two properties, useful for radio panels.
<syntaxhighlight>
<binding>
<command>property-swap</command>
<property>/instrumentation/comm/frequencies/selected-mhz</property>
<property>/instrumentation/comm/frequencies/standby-mhz</property>
</binding>
</syntaxhighlight>

=== property-toggle ===
Toggles the value of a property on each click, between true (1) and false (0).
<syntaxhighlight>
<binding>
<command>property-toggle</command>
<property>/controls/gear/gear-down</property>
</binding>
</syntaxhighlight>
Or - if defined - it toggles between two custom values.
<syntaxhighlight>
<binding>
<command>property-toggle</command>
<property>/controls/gear/gear-down</property>
<value>2</value>
<value>3</value>
</binding>
</syntaxhighlight>

===request-metar ===
{{cquote|
<syntaxhighlight lang="nasal">
fgcommand("request-metar", var n = props.Node.new({ "path": "/foo/mymetar", "station":"LOWI"}));
</syntaxhighlight>

If you pass an existing path, the station ID will be updated, and if you pass the same station ID as before, no additional request is made. As usual for metar-properties, there's a time-to-live and valid flags you can check, and the metar refreshes automatically every 900 seconds. You can also write to the station ID directly to change station, update the time-to-live, and wait for the valid signal.

There's also an unregister command ('clear-metar') to cancel the binding into the property tree.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38372.html|title=<nowiki>[Flightgear-devel] Requesting arbitrary metar</nowiki>|author=James Turner|date=Sun, 23 Sep 2012 08:56:48 -0700}}</ref>|James Turner}}
<references/>

== Related content ==
* <tt>[[$FG_ROOT]]/Docs/README.commands</tt> [https://gitorious.org/fg/fgdata/blobs/master/Docs/README.commands view online]
* [[Howto: Make a clickable panel]]

[[Category:Development]]
[[Category:XML]]

JSBSim Fuel System

2014-08-29T03:12:26Z

Zlsa: Fixed duplicate section, cleaned up unit order

[[JSBSim]] provides a framework for aerodynamics. This page will attempt to explain how to create fuel and oxidizer tanks for the JSBSim framework.

== FGTank ==
Tanks are a subsection of the Propulsion block.

=== Fuel Temperature ===

Fuel temperature is calculated using the following assumptions:

Fuel temperature will only be calculated for tanks which have an initial fuel
temperature specified in the configuration file.

The surface area of the tank is estimated from the capacity in pounds. It
is assumed that the tank is a wing tank with dimensions h by 4h by 10h. The
volume of the tank is then 40(h)(h)(h). The area of the upper or lower
surface is then 40(h)(h). The volume is also equal to the capacity divided
by 49.368 lbs/cu-ft, for jet fuel. The surface area of one side can then be
derived from the tank's capacity.

The heat capacity of jet fuel is assumed to be 900 Joules/lbm/K, and the
heat transfer factor of the tank is 1.115 Watts/sq-ft/K.

=== Fuel Dump: ===

Fuel dumping is handled by the FGPropulsion class. A standpipe can be defined
here for each tank which sets the level of contents (in pounds) which is not dumpable.
Default standpipe level is zero, making all contents dumpable.

=== Fuel Transfer: ===

Fuel transfer is handled by the FGPropulsion class, however the contents of tanks
may be manipulated directly using the SetContents() function here, or via the property
tree at <tt>propulsion/tank[i]/contents-lbs</tt>, where i is the tank number (Tanks
are automatically numbered, starting at zero, in the order in which they are read in
the aircraft configuration file). The latter method allows one to use a system of FCS
components to control tank contents.

There is also a property <tt>propulsion/tank[i]/external-flow-rate-pps</tt>. Setting
this property to a positive value causes the tank to fill at the rate specified.
Setting a negative number causes the tank to drain. The value is the rate in pounds
of fuel per second. The tank will not fill past 100% full and will not drain below 0%.
Fuel may be transfered between two tanks by setting the source tank's external flow rate
to a negative value and the destination's external flow rate to the same positive value.
Care must be taken to stop fuel flow before the source tank becomes empty to prevent
phantom fuel being created.

=== Configuration File Format ===
<syntaxhighlight lang="xml">
<tank type="{FUEL | OXIDIZER}">
<grain_config type="{CYLINDRICAL | ENDBURNING}">
<length unit="{FT | M | IN}"> {number} </radius>
</grain_config>
<location unit="{FT | M | IN}">
<x> {number} </x>
<y> {number} </y>
<z> {number} </z>
</location>
<drain_location unit="{FT | M | IN}">
<x> {number} </x>
<y> {number} </y>
<z> {number} </z>
</drain_location>
<radius unit="{FT | M | IN}"> {number} </radius>
<capacity unit="{LBS | KG}"> {number} </capacity>
<contents unit="{LBS | KG}"> {number} </contents>
<temperature> {number} </temperature> 
<standpipe unit="{LBS | KG"}> {number} </standpipe>
<priority> {integer} </priority>
<density unit="{KG/L | LBS/GAL}"> {number} </density>
<type> {string} </type> 
</tank>
</syntaxhighlight>

=== Definition of the tank configuration file parameters: ===
{| class="prettytable"

|type
|One of FUEL or OXIDIZER. This is required.
|-
|radius
|Equivalent radius of tank for modeling slosh, defaults to inches.
|-
|grain_config type
|One of CYLINDRICAL or ENDBURNING.
|-
|length
|length of tank for modeling solid fuel propellant grain, defaults to inches.
|-
|capacity
|Capacity, defaults to pounds.
|-
|contents
|Initial contents, defaults to pounds.
|-
|temperature
|Initial temperature, defaults to degrees Fahrenheit.
|-
|standpipe
|Minimum contents to which tank can dump, defaults to pounds.
|-
|priority
|Establishes feed sequence of tank. "1" is the highest priority.
|-
|density
|Density of liquid tank contents.
|-
|type
|Named fuel type. One of AVGAS, JET-A, JET-A1, JET-B, JP-1, JP-2, JP-3, JP-4, JP-5, JP-6, JP-7, JP-8, JP-8+100, RP-1, T-1, ETHANOL, HYDRAZINE, F-34, F-35, F-40, F-44, AVTAG, AVCAT
|-
|location:
|-
|
|x - Location of tank on aircraft's x-axis, defaults to inches.
|-
|
|y - Location of tank on aircraft's y-axis, defaults to inches.
|-
|
|z - Location of tank on aircraft's z-axis, defaults to inches.
|-
|drain_location:
|-
|
|x - Location of tank drain on aircraft's x-axis, defaults to inches.
|-
|
|y - Location of tank drain on aircraft's y-axis, defaults to inches.
|-
|
|z - Location of tank drain on aircraft's z-axis, defaults to inches.
|}

===Default values of the tank configuration file parameters:===
{| class="prettytable"
|type
|ttUNKNOWN (causes a load error in the propulsion configuration)
|-
|location drain_location
|both optional, but a warning message will be printed to the console if the location is not given
|-
|
|x - 0.0 (both full and drained CG locations)
|-
|
|y - 0.0 (both full and drained CG locations)
|-
|
|z - 0.0 (both full and drained CG locations)
|-
|radius
|0.0
|-
|capacity
|0.00001 (tank capacity must not be zero)
|-
|contents
|0.0
|-
|temperature
| -9999.0 (flag which indicates no temperature is set)
|-
|standpipe
|0.0 (all contents may be dumped)
|-
|priority
|1 (highest feed sequence priority)
|-
|density
|6.6
|}
===Fuel Densities (lb/gallon):===
{| class="prettytable"
|Type
|Density
|-
|AVGAS
|6.02
|-
|JET-A
|6.74
|-
|JET-A1
|6.74
|-
|JET-B
|6.48
|-
|JP-1
|6.76
|-
|JP-2
|6.38
|-
|JP-3
|6.34
|-
|JP-4
|6.48
|-
|JP-5
|6.81
|-
|JP-6
|6.55
|-
|JP-7
|6.61
|-
|JP-8
|6.66
|-
|JP-8+100
|6.66
|-
|RP-1
|6.73
|-
|T-1
|6.88
|-
|ETHANOL
|6.58
|-
|HYDRAZINE
|8.61
|-
|F-34
|6.66
|-
|F-35
|6.74
|-
|F-40
|6.48
|-
|F-44
|6.81
|-
|AVTAG
|6.48
|-
|AVCAT
|6.81
|}
{{FDM}}

{{JSBSim}}

Piper Archer CX

2014-08-26T19:27:17Z

Zlsa: changed name

Piper Archer LX

2014-08-26T19:26:20Z

Zlsa: Zlsa moved page Piper Archer LX to Piper Archer TX: Incorrect aircraft name...

#REDIRECT [[Piper Archer TX]]

Piper Archer CX

2014-08-26T19:26:05Z

Zlsa: Zlsa moved page Piper Archer LX to Piper Archer TX: Incorrect aircraft name...

{{infobox Aircraft

|name = Piper Archer LX
|type = Civilian aircraft
|fdm = JSBSim
|status = development
|authors = Jon Ross
|fgname = pa28-181
}}

The Piper Archer LX is a low wing, single engine civilian aircraft based off of the Piper Cherokee airframe.

== Development ==

The aircraft is hosted on GitHub: https://github.com/zlsa/pa28-181.

[[Category:Civil utility aircraft]]
[[Category:Low wing aircraft]]
[[Category:Propeller aircraft]]
[[Category:Single-engine aircraft]]

Piper Archer CX

2014-08-26T17:18:54Z

Zlsa: Created page

Portal:Developer/Aircraft

2014-06-17T02:07:17Z

Zlsa: fixed grammar

{{Main page/Header
|title=Welcome to the [[aircraft]] developer portal!
|introduction=Please visit [http://forum.flightgear.org/viewforum.php?f=4 our forum] if you cannot find what you're looking for.
|rightbox=[[Portal:Developer|Back to the Developer portal]]

|rightcolumn1= </div>
Getting started 

[[Howto:Make an aircraft|Making an aircraft]] · [[Howto:Make a helicopter|Making a helicopter]] 
[[Modeling - Getting Started|Modeling]] ·[[Knob animation]]
|rightcolumn2= </div>
General 

[[Formalizing Aircraft Status|Aircraft status]] · [[Aircraft maintenance]] 
[[Howto:Create custom splash screens|Creating custom splash screens]] 
[[Howto:Configure views in FlightGear|Configuring views]] · [[Walk view|Adding walk view]] 
[[Howto:Define limits|Defining (speed) limits]]
|rightcolumn3= [[File:Portal aircraft.png|40px]] </div>
[[Flight dynamics model]] 

[[Howto: Add thrust reversal|Adding thrust reversal]] · [[Howto:Implement pushback|Implementing pushback]] 
[[Howto:Implement aerial refueling capability|Implementing aerial refueling]] 
[[Howto:Write a fuel system in JSBSim|Writing a JSBSim fuel system]] · [[Howto: Name fuel tanks|Naming fuel tanks]] 
[[JSBSim Commander]] 
[[JSBSim]] · [[UIUC]] · [[YASim]]
|rightcolumn4= [[File:Portal instrumentation.png|40px]] </div>
Instrumentation 

[[Soaring instrumentation sdk]]
[[Creating instruments for FG|Creating instruments]] · [[Howto:Adding instruments to an aircraft|Adding instruments]] 
[[Howto:Make a clickable panel|Making a clickable panel]] · [[Glass reflection effect for instruments|Glass reflection effect]] 
[[Howto:Implement a Control Display Unit|Control Display Unit]] · [[Ground proximity warning system]] 
[[Howto: Design an autopilot|Designing an autopilot]] · [[GPS]] · [[Route manager]] 
[[Avionics Development Resources|Avionics resources]]
|rightcolumn5= [[File:Portal modeling.png|40px]] </div>
Modeling 

[[Howto: 3D Aircraft Models|3D aircraft models]] · [[3D Model Rotates Around Nose]] 
[[Howto:Animate models|Animating models]] · [[Howto:Use the normal map effect in aircraft|Using a normal map]] 
[[Howto: Add aircraft lights|Adding lights]] · [[Howto:Implement wing flex|Implementing wing flex]] 
[[Howto:Implement generic tyre smoke|Adding tyre smoke]] · [[Howto:Edit a livery|Editing liveries]] 
[[Model Import and Export|Importing and exporting]] 
[[Modeling Resources|Resources]] · [[Normals and Transparency Tutorial]] 
[[AC3D]] · [[Blender]] · [[SketchUp]] · [[Wings 3D]]

|sections=
{{Main page/Leftbox|title=Aircraft, the fundamental part of flight
|contents=Without any '''aircraft''', there is no flight simulator. Aircraft development is one of the fundamental parts of a flight simulator. Contributing is fun and can be done at all levels of experience.
}}
{{Main page/Leftbox|title=Rating aircraft status
|contents=All the way back in May 2011, we adopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.
}}
}}

[[Category:Portals]]

[[es:Portal:Desarrolladores/Aeronaves]]
[[pt:Portal:Desenvolvedor/Avião]]