FlightGear Newsletter July 2012
|
We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.
Release status
On July, 17th, the release branches were created in the Git repositories of the source-code and data. This was the last major step in our Release Plan before the actual release of FlightGear 2.8.0. During the next two weeks, we are working hard to remove the last known bugs in the code before we start creating the packages for the major platforms. Please help us find bugs by testing the release candidates that are offered at the bottom of this page. Testers are encouraged to file bugs at the issue tracker.
To get an impression of what has changed since our last release (2.6.0), a changelog is currently being written at Changelog 2.8.0 (work in progress).
15 years of FlightGear, screenshot contest
To celebrate FlightGear's 15th birthday (July 17), we decided to organise a screenshot contest. Starting at August 1, two weeks of public voting will follow, leading to the winners being announced on August 18 with the release of FlightGear 2.8.0. The winning screenshots will be used to promote FlightGear to the wider public.
We would like to thank the 37 people that submitted a combined total of 165 screenshots. Vote for your favourites at flightgear.org/contest!
Interested in reading more about FlightGear's history? See FlightGear History.
Development news
Adopting the new Canvas 2D rendering system
As of July 2012, FlightGear core developers agreed to adopt Tom's new Canvas 2D rendering system which is purely property-driven and handles all 2D drawing via the FlightGear property tree. Initially, the idea will be to replace the current GUI toolkit (PUI/PLIB, which has shown many limitations over time) and use a purely Canvas-based implementation instead, which will be mostly implemented in scripting space using Nasal and merely use the Canvas system as its rendering backend. The implementation details are covered at Canvas Widgets. This step will make it eventually possible for end users to easily customize the FlightGear GUI and its appearance by creating custom GUI styles (themes/skins), but also by creating completely new GUI widgets using an SVG editor like Inkscape.
Currently (07/2012) only drawing inside an existing (PUI) dialog is possible, but the idea is to slowly implement the current functionally in Nasal and get rid of the hardcoded PUI widgets. Only some code for mouse/keyboard interaction with Nasal will be needed.
In contrary to using some hardcoded GUI system (PUI, osgWidget, etc.) this approach would give much more flexibility and also the means of modifying and creating new widgets without the need to touch any core code.
With the Canvas system every type of widget would be possible, so that also things like submenus can be realized. Another advantage of the Canvas approach is that it is heavily using the property tree and therefore is already fully accessible from Nasal code and also configurable with the existing xml formats.
The point of the canvas widget demo is to demonstrate how powerful and flexible the new canvas system really is, i.e. it cannot just be used for aircraft scripting (instruments, MFDs), but also for GUI scripting - which means that using the canvas system would unify the 2D rendering backend (all can be handled via canvas), while reducing the amount of C++ code we have doing these things, which would mean that the GUI system could be entirely maintained in scripting space, i.e. as part of the base package, by people who don't need to know C++ - some basic Nasal knowledge will do.
Basically, adopting the new canvas system for such and similar purposes, will mean that tons of old/oudated C++ code can be phased out and replaced by a single consistent implementation in C++, that is using modern C++/OSG code - which ultimately also means that OSG itself can make more assumptions about what's being rendered, so that more optimizations (= better frame rates) can be more easily accomplished by using OSG coding patterns and protocols, instead of outdated/custom/3rd party libraries which would need to be manually baked into the existing FG/SG/OSG eco system.
Now what's cool about the canvas system is that it's integrated in such a fashion that it will keep working with the old GUI code still in place.In addition, all of the exsting GUI features (layouting, XML processing) are implicitly supported due to the way the canvas system is implemented. These are real roadblocks when implementing a new GUI library next to PUI, because all of the existing stuff would need to be explicitly ported (either in C++ space or by converting tons of XML files). Overall, the canvas system will give us all of this "for free", and it will mean less C++ code in the source tree, too - i.e. better maintainability.
Also, once the standalone FGCanvas becomes available, it would also be possible to run the GUI in multiple windows or even in separate processes.
In addition, by using the canvas system for GUI widgets, it would also be possible to render aircraft instruments, MFDs, HUDs etc inside GUI dialogs, too.
Future plans include reimplementing the current HUD and 2D panel systems using the Canvas system. In addition, the canvas system will provide an opportunity to increasingly unify the 2D rendering backend in FlightGear in the months to come: Unifying the 2D rendering backend via canvas. Furthermore, the canvas system provides a novel way to abstract away the creation of fully interactive and dynamic moving map displays and GUI widgets for charting using so called Canvas Maps.
Procedural texturing
Usually, textures of models or scenery are prepared in advance, then loaded and rendered by Flightgear. Procedural texturing is the idea to compute the texture to be rendered inside the fragment shader rather than using a pre-defined texture. The main disadvantage of the scheme is its higher framerate cost. However, unlike pre-defined textures which show repetition ('tiling') over distances much larger than the texture size, a computation inside the fragment shader can evaluate a function which does not show tiling and use this as basis for the final texture. At the same time, details like a terrain heightmap or color variations at any size scale can be generated.
Since the textures are computed dynamically, it is also possible to let the terrain elevation or slope influence the result (as demonstrated by the existing snow and transition effect shaders). Using procedural texturing in the terrain shader to mix several textures and add environment effects allows to render the Flightgear terrain in unprecedented visual detail. The dynamical texture generation hides the seams between different landclasses, can generate terrain roughness at a high level of detail, can easily add the effect of light reflection from water puddles in wet terrain and can be used for extremely high resolution texturing of airport landclasses.
(all screenshots taken in default scenery)
In the hangar
All the way back in May 2011, we addopted 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 Google Docs. If you're an aircraft developer and your aircraft is/are 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.
A new hangar: Lukas' hangar
A new hangar for Flightgear has opened: Lukas' hangar. There you can find some Liveries and Scenery projects, inter alia airports of the Balearic and Canary Islands. The best is that you have a look in Lukas' hangar.
Scenery corner
Manhattan shapefile
Gijs' handmade shapefile for Manhatten, New York is finally available at the mapserver. Compared to the current (v0) shapefiles, the custom shapes are much more accurate and have a higher level of detail. The most obvious improvements are the additional parks and the islands, including Liberty Island.
Those of you that know how to use TerraGear can build Manhattan, others will see it in a next scenery build.
Tools
FlightGear made it again. For the first time in flight simulators history, it's never been that easy to contribute to scenery! If you have already copy/pasted once in your life, then you are able to contribute to FG scenery! A direct copy/paste of new objects lines (STG format) in a webform now allows you to update scenery objects all over the world for all FG users using Terrasync. Add your email address to be informed of the progress of the update. Import should happen soon (let's say between 24 and 72 hours, but it depends on the poor scenery maintainer(s) workload!).
Want to try it in production? Click here then choose mass import, or via the scenemodels website menu (Contribute => Mass shared object position insertion).
Please note:
- You must only import new objects, not the whole STG file you're working on!
- Don't add models not present in the FG scenemodels database, nor (yet) OBJECT_SIGN nor OBJECT_STATIC.
- Don't add forest or other items linked to the landcover. Those items have to be generated based on the landcover, not on objects! The only trees accepted will be those located on airport boundaries, for example.
- The data you're asking for import should be based for elevation on the terrain shipped with FlightGear/Terrasync, and not on a terrain you could have downloaded or compiled yourself. Else, your objects could appear floating or sunk in the terrain...
- Finally, the import is limited to 100 lines per submission (let's think about the poor scenery maintainer(s)...)
- The import is quite sensitive about the data in entry, which goes through quite a lot of checkings, including humans, before insertion.
Next step is the import script for 3D models. It's on its way, finished to approximately 90%. Be patient, it's quite a complex tool to achieve.
Mapserver
Some mapserver news here, as we have not been talking about this very useful tool for a while. Mapserver has been going through updates this month, one of the most useful being the possibility to view details on a object and to edit/delete it directly from the map. This has never been so easy to update/delete a shared object directly from the map (see the screenshot). Note that you need to have a sufficient zoom factor (>=16) to see the red arrows appear, then you can click on them. Special thanks to Martin, Julien and Gijs for updating and testing this tool. To use it, please have a look here.
OpenStreetMap license update
As you will probably know, OpenStreetMap is changing its license. When the license change is completed, we will be able to use OSM data in the official FlightGear scenery. As not all OSM contributors agreed to the new license, data from those sources had to be removed. This "redaction process" is completed as of the end of July. Even tough this is a big step forward, the license hasn't changed yet. See the OSM blog for updates and latest news on the matter: http://blog.osmfoundation.org/
Community news
FlightGear on YouTube
Fallen- revisited his old style video recording flying from San Francisco Int. to the Nimitz carrier, but at night with the new Rembrandt enabled F-14 Tomcat with new lights coming to FlightGear.
FlightGear 2.8 Night with Rembrandt
Multiplayer
Two more multiplayer servers have been setup:
- mpserver15.flightgear.org (North Point, Hong Kong)
- Courtesy of Hazuki Amamiya
- mpserver16.flightgear.org (Dallas, TX, USA)
- Courtesy of Rob Dosogne (truthsolo
) - Also hosts a new Server Status page.
And finally ...
Contributing
One of the regular thoughts expressed on the FlightGear forums is "I'd like to contribute but I don't know how to program, and I don't have the time". Unfortunately, there is a common mis-conception that contributing requires programming and lots of free time. In fact, there are a huge range of ways to contribute to the project without needing to write code or spending days working on something.
For ideas on starting to contribute to FlightGear, you may want to check out: Volunteer.