Mock up Newsletter Oct 2015
|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 2020.
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. In addition, the effect maps textures to a physical size and doesn't attempt to stretch the texture across the whole runway, which makes many more details apparent.
Read more at Procedural Texturing § The dirt runway effect.
PUI2Canvas: parsing PUI/XML using Nasal and Canvas
Screen shot showing the FlightGear about dialog procedurally created and rendered by a Nasal/Canvas parser that turns PUI/XML markup into Canvas widgets/properties. The about dialog is making heavy use of dynamic text labels using printf formatting for displaying OpenGL related info, so needs to be mapped to Nasal sprintf/getprop calls
As of 10/2015, a simple framework is being prototyped to serve as a proof-of-concept and demonstrate how existing PUI GUI dialogs 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 dialogs 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 dialogs (and widgets), without having to adopt an external library.
Simple dialogs are likely to work, while more sophisticated dialogs may require some additional work, especially when it comes to layouting 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 actually used anywhere-but that doesn't really 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 dialogs 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/dialogs 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 prior to dialog creation, and cleanup code executed when closing the dialog)
- 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
|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.|
|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.|
|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.|
|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.|
|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.|
|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.|
|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.|
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.