Mock up Newsletter Oct 2015

From FlightGear wiki
Jump to navigation Jump to search
Warning  This article is a temporary mock up which will be deleted. If you are searching for the newsletter, see FlightGear Newsletter October 2015.
This newsletter is a draft.

Please feel free to add content you think will be of interest to the FlightGear community. You can read the latest newsletter at FlightGear Newsletter October 2022.

Enjoy reading the latest edition!
Please help us write the coming edition!
January 1999

Development news
ALS dirt runway effect
Processing PUI/XML using Nasal
In the hangar

Scenery Corner
Community News

Translators required
FlightGear logos
Screenshot of the Month

Development news

ALS dirt runway effect

The Atmospheric Light Scattering framework has received some upgrades to the rendering of unpaved runway surfaces. The effect can now be controlled in multiple ways by setting parameters for the distribution of overlay textures, allowing to generate a structure of patchy grass or to blend the runway smoothly into the surrounding landclass. Besides, the effect maps textures to physical size and doesn't attempt to stretch the texture across the whole runway, which makes many more details apparent.

Dirt runway example 1 Dirt runway example 5 Dirt runway example 2

Read more at Procedural Texturing § The dirt runway effect.

PUI2Canvas: parsing PUI/XML using Nasal and Canvas

As of 10/2015, a simple framework is being prototyped to serve as a proof-of-concept and demonstrate how existing PUI GUI dialogues can be processed by a parser written in Nasal, which turns PUI/XML markup into the corresponding Canvas GUI widgets/properties.

This will enable the removal of PLIB PUI (our legacy OpenGL GUI engine), which is known for using inefficient legacy OpenGL code that is not suitable to be used in conjunction with OSG (preventing compatibility with newer OpenGL versions, as well as affecting performance-unlike Canvas which is directly using Osg::Text, Osg::Image - as well as ShivaVG for supporting OpenVG - so a Canvas-based UI engine will be much easier to support for the OSG optimizer.), and it will also let existing dialogues be supported without having to manually update/port them.

In its current form, this is not intended to be a completely functional alternative to PUI but just intended to document the necessary steps for supporting the existing PUI dialogues (and widgets), without having to adopt an external library.

Simple dialogues are likely to work, while more sophisticated dialogues may require some additional work, especially when it comes to layout and styling (including PUI themes).

This extra work would typically involve extending or creating custom Canvas widgets for wrapping PUI widgets and integrating those with the parser shown below.

At the time of writing, it isn't clear if this approach is going to be used anywhere-but that doesn't matter, because the parser is fairly straightforward and simple, which makes it an excellent stress test to exercise the underlying Canvas/C++ code or use the same approach for porting other legacy GL code (e.g. 2D panels, HUDs or even just the splash screen).

Creating a Canvas property tree hierarchy for even simple PUI/XML dialogues will easily cause the creation of dozens of layout instances and hundreds of Canvas groups in the tree, many of which may have attached listeners/timers for event handling purposes. The Nasal/Property Tree overhead is fairly remarkable, and also noticeable on older systems.

So running the parser and benchmarking/profiling FlightGear is a pretty good way to determine Canvas/Nasal related bottlenecks and come up with ideas for extending/optimizing the Canvas C++ code a little, which will be beneficial to unrelated efforts (including any aircraft/dialogues using Canvas/MapStructure based displays), but also the long-term idea to help unify the 2D rendering back-end by porting the HUD/2D panels code to use Canvas.

For the time being, the parser correctly supports:

  • embedded nasal/close blocks (code executed before dialogue creation, and cleanup code executed when closing the dialogue)
  • bindings in the form of fgcommands and Nasal scripts
  • C-format style labels/legends
  • dynamically patched fgcommands to transparently dispatch PUI fgcomands to their Canvas equivalents (e.g. dialog-close)

Learn more at Howto:Processing_legacy_PUI_dialogs_using_Canvas

In the hangar

Scenery corner


Translators required

En.gif The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate.
Fr.gif Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire Help:Traduire.
De.gif Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit Help:Übersetzen an.
Nl.gif De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij Help:Vertalen.
Es.gif La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en Help:Traducir.
Cat.gif La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a Help:Traduir.
Pt.gif A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em Help: Traduzir.

FlightGear logos

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


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

Screenshot of the Month

Entries for this month's best screenshot can be submitted to this forum topic. Be sure to see the first post for participation rules. For purposes of convenience and organization, after all entries have been submitted, a new post will be started containing all shots in an easy to view layout. There voting will take place. The best screenshot which will be presented on this page.