FlightGear Newsletter April 2013
|
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. At the end of each month, it's generally a good idea to get in touch with other contributors to ask them to add news about their contributions to the newsletter. Core developers are encouraged to add news about their latest work to the newsletter's development section and the changelog of the upcoming release.
Development news
Release-candidate builds for the 2.10.1 (bug-fix) release available
As previously mentioned on the devel list[1], James is now attempting a 2.10.1 release, to see if this improves our perceived quality. There's some bug fixes we already aware of, including a Windows path-handling one which is quite significant.
Now, the great news is that thanks to James' work, we are now able to crank out full installers right from the Jenkins build server. That will save us a bunch of downloading and hours of uploading for every new release candidate.
Continuing with the experimental creation of a bug fix release for 2.10:
These are the first Windows releases produced automatically (the Jenkins build server creates the installer) instead of via Curt, so please be on the look-out for anything that seems messed up / omitted. Based on very limited testing via a Windows VM everything seems sane and the apps run.
The intention is that the quality of these builds is 'at least as good' as 2.10.0. We would be happy for them to replace 2.10.0 on the web sites as soon as they pass a collective sanity check from people here.
If you find new bugs, that's fine, but unless they are regressions since 2.10.0 (which is unlikely, hopefully) then they should not block releasing; they can be fixed in a (hypothetical!) 2.10.2 or wait until 2.12.
In particular the Windows builds include the UTF-8 pathname fix which is significant for various people.
In general we're looking for 'yes the build works' or 'you've forgotten to include XYZ' feedback, not 'random shader bug 123 is still not fixed. So if there's a bug that is (still) troubling you, update its entry in the issue tracker, help with finding a test case, or fire up an editor and fix it.
Advanced Weather
Advanced Weather's cloud placement algorithms are currently receiving a major overhaul. In reality, many scattered cloud layers form rather complex patterns on the sky. One strategy is to simply take pictures of these and project them as 2d clouds layers into the scene, which looks fine from the ground, but fails from close-up. Advanced Weather has always preferred to model as 3d clouds whatever can be modelled in 3d. However, this means that the intricate patterns need to be created by a suitable algorithm.
So far, the first generation of placement algorithms have utilized rather simple geometries like grid patterns and random clusters. While this is usually not a major issue from the ground, it is quite apparent from high altitude - here is an example of a cloud distribution based on multiple clusters:
Second generation placement algorithms are based on more intricate semi-random patterns. These distribute clouds just in a different way (i.e. the result does not require higher rendering performance) and the placement algorithms are not even significantly more expensive computationally (perhaps 10% - the advantage all comes from smarter design) - yet they work much better approximating real cloud distributions.
Here are the results for the same weather situation from 'stick bundle' and 'domains' - two of the new placement methods:
Cloud distributions appear much more natural and appealing, especially from high altitude. Work is in progress to replace 1st generation by 2nd generation algorithms in both the online and offline weather models of Advanced Weather.
Project Rembrandt
A number of Mac users have been reporting issues related to running Project Rembrandt (deferred rendering/shadows) on Mac OSX with ATI/AMD GPUS, we are now looking for Mac users to provide feedback on running Rembrandt on Mac OSX, required information includes errors and warnings shown during startup/runtime, but also screen shots showing any issues. Please see: Project Rembrandt#Mac Issues.
Usability Improvements
Aircraft checklists can now include include commands to have the simulator/co-pilot/instructor execute checklist items. See the c172p for an example of this in action.
Air-to-Air Refueling Improvements
AI air-to-air refueling has been improved by Stuart and now offers increased realism and improved useability:
- You can now select from a range of refuelling tankers from within the simulator. In addition to the previous KA6-D Intruder and KC-135 Stratotanker, you can now use a A-4F buddy tanker or the A330-MMRT tanker. Additional tankers can easily be added in the future.
- The rate at which fuel is transferred between the tanker and the receiving aircraft is now configurable, both at the tanker and receiving aircraft.
- The refuelling "envelope" (e.g. how close you need to get to the tanker to refuel) is now configurable in-sim. a 5m envelope is very challenging indeed!
- As many aircraft don't have an easy to see fuel gauge (particularly if you're concentrating hard on keeping right up to the tanker!), you can now ask your virtual co-pilot to tell you when you engage/disengage.
- Finally, aircraft can now define the exact position of the refuelling point. Aircraft designers are encouraged to define refuelling points as described in Howto:Implement aerial refueling capability.
Tree Textures
Trees are now more compatible with Atmospheric shading - appearing snow-covered above the snow-line, and in winter foliage from late autumn (as set in Environment Settings). For texture artists, there is a format change for trees: Instead of using a different texture file for summer and winter trees, both are defined in the same file. See Docs/README.materials for details.
Getting involved as a programmer
Unfortunately, most of the active FG developers are currently very overstretched in terms of the areas that they have ownership of, which is affecting how much can actually be done. Fundamentally we need more core devs.
If you are interested in contributing as a core developer, please see Howto:Start core development.
Translators required
|
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. |
|
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 FlightGear wiki 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. |
New software tools and projects
osm2city.py
Dresden, Germany (EDDC 
) and Innsbruck, Austria (LOWI ) have recently been populated with about 50,000 buildings derived from openstreetmap data. The buildings are textured with hi-res facade and roof images. While this certainly improves visual impression over the current random buildings, rendering a huge number of individual models in a scene is quite demanding. The FG process eats ~3GB RAM when flying in those areas, you might see a severe fps hit, and the download is ~50 MB each. However, the buildings respect LOD settings, and there's work underway to also reduce the memory footprint.
The conversion is done by osm2city.py, currently being developed by forum user radi. The approach is similar to bob.pl or forum user Soitanen's scripts, (or osm2xp for X-Plane), both of which have been discussed in the forums. Being at a rather early stage of development, osm2city.py is currently not very user-friendly. You probably should know some python if you want to use it yourself.
If you want to help out anyway: take pictures of buildings where you live! Radi is especially interested in south-east asian style architecture, as he's planning to populate Hong Kong Kai Tak (VHXX) in the future. But any other areas are welcome, too. There's a howto on taking pictures ready for texture extraction.
Scenery corner
Custom scenery: France 850 v2
A new version of the france-850 has been released this month. This scenery has been created with the latest TerraGear tools and latest apt.dat version from X-Plane (04/2013). For people who like VFR flight it's a really nice scenery with lot of roads and rivers. Also this it give a good idea of the upcoming official scenery.
Scenery repository (Gitorious)- Forum topic
Regional textures Madagascar
Regional texturing for Madagascar has now arrived on GIT. The scheme is a full overlay texture scheme compatible with the high-quality terrain shaders of Atmospheric Light Scattering and offers tropical trees in the forest zones as well as red earth and grasslands in the central high plateau of Madagascar. Agriculture textures have specifically been adapted to reflect the same color of soil as shown in the other landclasses.
Wiki updates
Template for key presses
A new template, {{key press}}, has been created to illustrate keys and key combinations visually insted of as text. To use it, type for example:
To retract the landing gear, press {{key press|G}}, and to extend them press {{key press|Shift|G}}.
Which will render as: To retract the landing gear, press G, and to extend them press ⇧ Shift+G.
Community news
New tutorials and screencasts
Cross-Country Tutorial II - a VFR guide
This is a new tutorial and guide for V.F.R. opperations.
Get the download link for the latest version from the forum post under the "Documentation" tab.
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.
To learn more about how the project works, please see this short essay written by Thorsten, for a more detailed article see How the FlightGear project works.
Call for volunteers
- The Flightgear On Android team is looking for testers
- The Target4Today team is looking for volunteers to help improving FlightGear's combat support
- The FGFSPM (FlightGear Package Manager) is looking for a new maintainer.