Changelog 2.10

From FlightGear wiki
Revision as of 07:26, 13 September 2012 by Hooray (Talk | contribs) (Some of the major changes include:: copied from FlightGear_Newsletter_September_2012)

Jump to: navigation, search
This changelog is a draft.

This changelog is currently being written for the FG 3.0 release - FG 3.0 has not yet been released! But starting to write the changelog early, should make it much easier to come up with a comprehensive list of changes.

FlightGear 3.0.0 ChangeLog

The FlightGear development team is happy to announce the v3.0.0 release of FlightGear, the free, open-source flight simulator. This new version contains many exciting new features, enhancements and bugfixes. New features in this release include an experimental renderer supporting real-time lighting and shadows, and improved terrain rendering.

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.0.0 for free from

FlightGear - Fly Free!

Some of the major changes include:

Aircraft operations

AI system

AI Traffic

Flight dynamics

Random Buildings

Shortly after the 2.8 release, a number of users reported severe memory growth issues related to a new feature: Random Buildings.

Unfortunately, the buildings are generated when the tiles are loaded, and it is this that causes the memory occupancy problems rather than visibility itself (subject to big view ranges causing the loading of more tiles). Aggressively limiting the maximum available visibility range might help, if it's causing more tiles to be loaded, but it is very dependent on the amount of Urban and Town terrain.

For performance reasons, all the buildings within a tile are a single object currently. The memory capacity could be addressed by changing the implementation to something closer to the trees, where a (relatively) small number of buildings are instantiated at different locations. I don't know what this would do for performance though.

Stuart has now managed to get a prototype running using an instantiation of a shared geometry rather than a huge single object per tile.

So far the results are promising. Stuart's standard test is at KSFO with the c172p, waiting until the intial set of tiles is loaded with standard weather conditions (e.g. no excessive visibility). With random buildings switched off FG uses ~1GB memory. With v2.8.0 random buildings, it's 2GB. With instantiated buildings at present it is 1.5GB. At KLAX, it's down even further, from 2.7GB to 1.6GB. So far, without any frame-rate impact.

This work is now checked into next/master. You'll need an updated simgear and data to see any effect.

Basically, the design has been altered to use a scheme very similar to that of the random trees, where there are a small number of buildings created, and then instantiated multiple times.

The technique relies on a vertex shader, as the final position and rotation of the building are passed in on the gl_Color vector. This in turn has meant that I've been forced to create new version of various vertex shaders. It might be possible to clean that up by having a new parameter to existing shaders indicating that position/rotation information is in gl_Color

There are three known regressions from the previous implementation:

  • The reflection map appears to be broken, and is currently switched off. (this might be because the binormal or tangent are not being calculated correctly.)
  • The buidings do not cast shadows in Rembrandt, though other objects _do_ cast shadows on the buildings. I don't know the reason for this.
  • At high building densities and certain angles of view, one can see gaps in the building placement where the edges of the scenery triangles go. This is unfortunately inevitable, as we have less sizing information during placement.

You should now see significantly lower memory occupancy (500 - 2GB less depending on area and density) when running with random buildings enabled. This will obviously be available in the next FG release as well.

Feedback/comments appreciated as always.

Project Rembrandt

Fred's been working on some fancy new effects, especially useful for our film-making enthusiasts.

The Rembrandt renderer has a lot of potentiality when it comes to post processing effects. Indeed, the interesting property of a deferred shader is that all stages of rendering are kept into memory. Post-processing is as simple as using a filter on a camera.

So currently the effects added in git are :

  • Night vision including amplification grain and restrained field of view,
  • Cinema effect including :
    • Vignetting,
    • Color shift, with Sepia as default value,
    • Radial distortion (barrel and pincushion distortion, with scale compensation),
    • Lateral chromatic aberration (purple fringing),
    • Film wear simulation.


As most readers will be aware, FG supports two weather models - Basic Weather which represents METAR data directly, and Local Weather which models weather more realistically, with more variation. In 2.8.0 these were configured separately using different UIs. Stuart Buchanan and Thorsten Renk have been working on unifying the user interfaces to provide a more user-friendly and consistent interface.


A further usability enhancement has been made by Stuart Buchanan to allow configuration of joysticks through a GUI in-sim. Instead of configuring a joystick using XML, users can now change joystick bindings within the simulator - no XML knowledge required. The updated joystick configuration takes effect immediately. This work is also available in git, and should make it much easier for new users (or those with joysticks unknown to FG) to get flying.

Canvas System

The Nasal API wrappers for the Canvas system have been committed to $FG_ROOT, so that people no longer need to manually load the required modules. Furthermore, the fully scriptable Canvas 2D drawing system in FlightGear 3.0 has now support for:

  • creating GUI windows (not just widgets, but also windows - which can be used for popup menus or menubars)
  • native copy/paste via 2 new Nasal extension functions, see Howto:Clipboard access using Nasal
  • nested canvases, where a canvas may contain images created by another canvas texture Howto:Using raster images and nested canvases
  • window stacking
  • raster images (vector images were already supported)
  • handling GUI events using osgGA

Support for nested canvases will make it possible to also load canvas textures into other canvases, so that you can, for example, easily load an instrument into a GUI dialog, or even use GUI widgets in MFD instruments, which is a feature based on real avionics, i.e. as used in modern airliners like the A380 or the 787 - which are based on the ARINC661 standard.

Nested canvases also make it possible for people to easily implement GUI tools using the Canvas system, for example a GUI instrument or panel editor can be entirely implemented in scripting space now, without touching any C++ code. Similarly, GUI widgets could also be created in a WYSIWYG-fashion, too - so that even a dialog editor or full GUI builders can be built using the Canvas system.

In addition, Tom has also implemented support for window stacking in 08/2012. Check out the demo video below, which demonstrates how "nested" canvases and window stacking works:

Missing features, and features currently under development, are listed at Missing Canvas Features


Highlighted new and improved aircraft

Project infrastructure

Visual effects


  • Additional joysticks and rudder pedals are supported out-of-the-box:

Bug fixes

  • See our bugtracker for an extensive list of the bugs fixed in this release.