FlightGear Newsletter September 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.
Development news
Random Buildings
Shortly after the 2.8 release, a number of users reported severe memory growth issues related to a new feature: Random Buildings.
This was a side-effect of the way in which the buildings were created during tile loading. Stuart has now completely changed the way in which random buildings are generated and displayed to reduce the memory occupancy by using a shader-based scheme similar to random trees. You should now see significantly lower memory occupancy (500 - 2GB less depending on area and density) when running with random buildings enabled.
James has pushed a large change to next, which adds a binary cache of most of the navigation data. The cache is stored in FG_HOME/navdata.cache, and rebuilt if the timestamps on any of the data files change (apt.dat, nav.data, fix.dat and so on). When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is /much/ faster, especially for debug builds:
|
Memory consumption is also lower, since we don't keep airports / fixes / taxiways / runways in memory until they're needed.
This is a fairly large change, so please look out for any bugs related to navaids / startup position / GPS / route-manager searches and lookups either getting different results or failing. I've tested here locally and things seem sane, and have had positive feedback from various testers on IRC and email, but I still expect to find some edge cases which need further work. There's future work to move even more data into the cache - eg parking positions - which will further help performance for FMS / map systems since we won't need to parse lots of XML data repeatedly. I'm going to let this change settle down before adding more cached data, however.[1]— James Turner
|
|
Initial work on dynamic subsystem creation
James has added initial code to work on dynamic subsystem creation, so that subsystems become create-able and removable from commands. Only some subsystems are supported so far, since many have non-default constructors or other complexities (see FlightGear Run Levels for further details). With this, change, it's now possible to dynamically add and remove the traffic-manager at runtime, for example:
fgcommand( "add-subsystem", props.Node.new( { "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}) );
The idea is to improve this further so that more and more subsystems in FlightGear can be optionally toggled on/off at runtime, which should help facilitate other ongoing efforts, like the FGCanvas project for example - ultimately, this will help make FlightGear become more configurable and scalable, but also better usable for other purposes, such as distributed (multi-machine) setups-so that a single binary can be easily used for different purposes.
In addition, it will be much easier for developers to do regression testing and benchmarking once subsystems can be completely disabled, which is another long-standing feature request (see FlightGear Headless), that should also simplify release preparations.
Project Rembrandt
The night vision effect, as well as the cinema effects, are now available for 2.8 users. See here 
for the download links, details and feedback.
Canvas System
Work has now started to develop a dedicated Nasal module specifically for mapping/charting purposes. A first proof of concept is available in $FG_ROOT/Nasal/canvas/map.nas, but we expect to commit more changes (and a real API) soon. Initially, we'll be collecting all related features in a single "map.nas" module, and refactor/improve things later on.
In particular, the idea is to have a single Nasal module as the backend for all mapping/charting tasks in FlightGear, so that existing hard-coded features can be unified and re-implemented via a single consistent Nasal module that serves as a shared backend.
Ultimately, this will make it possible to re-implement existing features such as ATC-FS, the Map dialog and even Brisa's Airport Diagram Generator or the Kelpie Flight Planner directly in FlightGear, using Nasal scripting and the Canvas system, without having to write any C++ code - so that people won't need to use external tools or programming languages to create such applications.
In the long run, we want to come up with a very flexible design so that the "map.nas" module cannot only be used for creating maps used in GUI dialogs, but also for creating moving map displays like the existing hard-coded Navigation display or the TCAS and WXRADAR displays ("glass" displays), i.e. as cockpit instruments/avionics. This approach would also make it possible to directly show instruments in GUI dialogs or vice versa.
As a first proof of concept, Stuart has added a Canvas-based map to the airport selection dialog, and Hooray has demonstrated that the same technique could be used to add a map widget to the route manager dialog - so that airport selection and route planning could become more intuitive using the Canvas system. A first stab at an MVC-oriented design to create map layers has now been committed to the base package, documented at Canvas Map API - this will soon be re-worked to add support for additional dialogs and instruments.
For additional info, please see: [1] .
In addition, ShivaVG (the vector drawing engine behind canvas) has been extended to support some kind of a non-zero fill rule. It's not really non-zero because instead of incrementing and decrementing depending on the orientation of the drawn overlapping regions it simply checks if at least a single region covers a pixel. For our use cases it should be enough tough.
Some further performance improvements were added: Now the texture is only redrawn if something has changed. So if you don't change the map there shouldn't be any noticeable performance impact anymore.
Also the bounding boxes are now only written to the property tree if they are recalculated. This should take some fair amount of changing properties away.
Seems like now tessellating takes much longer than before due to the amount of data in one single path.
The current problem with zooming is that every position of every path gets recalculated with the updated projection, even though this isn't really needed as the projection doesn't noticeably while just zooming and scrolling around at a single airport.
Flightplan access via Scripting
In advance of converting the Map and NavDisplay to use the Canvas, James has improved the "flightplan()" extension function of the Nasal scripting interpreter to expose the full route-path vector for each flight plan leg, as a vector on the leg .
var fp = flightplan();
for (var i=0; i<fp.getPlanSize(); i += 1)
{
var leg = fp.getWP(i);
debug.dump(leg.path());
}
With these changes in place, it is already possible to directly show a SVG image for each waypoint and connect them using OpenVG paths, even without separate "icon" support.
Usability Improvements
There have been a number of improvements made to the GUI this month, all aiming to improve usability.
Nasal Console
The built-in Nasal Console has been updated to also add native copy/paste support, a feature that got implemented as part of the ongoing Canvas effort (see Howto:Clipboard access using Nasal for details ). This feature makes it now possible to easily copy/paste snippets of code FlightGear, without having to use the "dump" feature.
About Dialog
In addition, the "about" dialog has also been slightly updated so that it now shows a handful of OpenGL-related parameters, this info should make it easier for people to provide useful issue reports, especially related to their system's graphics support. For this very purpose, the dialog box has now also support for copying this info to the clipboard or simply take a screen shot that users can post on the forums.
Select Airport
The Select Airport and Position on Ground dialogs have been combined. The combined dialog displays the lon/lat/alt of the selected airport, and also uses Canvas to display an airport diagram.
Aircraft Checklists
Aircraft typically have a large number of checklists, covering almost every phase of flight. Previously, aircraft authors have added checklists to the help text for the aircraft. This is a bit unwieldy. To improve matters, there is now an Aircraft Checklists dialog under the Help menu specifically designed to organize and display checklists. Aircraft authors can create new checklists easily without having to worry about how they will be displayed. See Aircraft Checklists for details.
Integrated Documentation Browser
Often, especially new FlightGear users are not aware of all the documentation that comes with FlightGear. While the manual is fairly easy to find and pretty accessible (being a PDF file), most of the other documentation in $FG_ROOT/Docs is hardly easy to find and often pretty inaccessible to new users, even though these files are standard text files, because of the non-standard file extensions used by most README* files there. That's why we have now added a new built-in dialog to FlightGear which shows most plain text files in $FG_ROOT/Docs directly inside FlightGear, without having to start any other applications.
Interview with a contributor (Thorsten Renk)
In each edition we have an interview with a contributor. Suggestions for possible questions are available on interview questions, you are invited to come up with new questions and interview ideas obviously! Anyone is free to write an interview (with him-/herself or others) for next month's newsletter! If you'd like to help interview a contributor or get interviewed, please do consider adding yourself to the list of interview volunteers! To keep this going and less awkward, we are currently trying to come up with the convention that former interviewees become next month's interviewers.
- How long have you been involved in FlightGear?
Since late 2009.
- What are your major interests in FlightGear?
In the broadest sense, modelling of the environment. I've started out modelling clouds and weather, then as I discovered shaders I've also included dust, haze and light scattering effects, and of late I am into improved ways of texturing the terrain.
All these areas are related, so it's actually pretty powerful if the same person knows how to affect all of them - for instance, on a rainy day, we not only see an overcast cloud layer, but also the light beneath the clouds is dimmed, the sunrise has a different color hue, the ground is wet and hence darker than usual and there may be water on the ground. Being able to do all these things with the same environment model is pretty cool.
- What project are you working on right now?
Procedural texturing, i.e. computing the texture mix to be displayed on the terrain inside the shader code - this allows for effects which would be impossible to achieve with the standard way of assigning textures due to the huge memory footprint.
- What do you plan on doing in the future?
Who knows? I have plenty of things I would like to do and in principle know how to do - the problem is just making them run fast enough. It's pretty amazing how fast a graphics card can crunch numbers, but there are limits eventually. And basically every day, looking out of the window and observing the richness in detail on a real sky, I see how inadequate even our most advanced shading models really are. It's amazing how nature solves all the rendering equations in real time.
- Are you happy with the way the FlightGear project is going?
Mostly. I know many people think FlightGear should have a project structure which works more like a commercial project, i.e. with clearly defined project goals and well-defined tasks. Rather, it is a somewhat anarchic collection of different individual projects merged together, often with multiple ways to solve the same problem (we support as many as four different ways to generate clouds for instance) which makes it not always easy for new contributers in need of a feature. But, coming from a research environment, I actually feel quite at home with such a development model - science works the same way, and for instance, while having several independent ways of doing the same thing can be seen as a waste of resources, it can also be seen as a feature - we explore many different ways of doing things which helps us find the best solution.
What I don't like is that there is often a lot of friction - for instance 3-D modellers feel underappreciated since most of the project decisions are made by the coders, there's an ongoing controversy between scripting space (Nasal) and C++ coding, and there are contributors of world scenery vs. custom scenery creators. While some level of discussion seems useful to me, related discussions often reach a point which I find no longer productive.
- What do you enjoy most about developing for FlightGear?
The same thing Tolkien enjoyed about writing 'The Lord of the Rings' - the possibility to do subcreation. The visible FlightGear scenery is a world to explore, and this world is directly and visibly influenced by code I write. I can place myself high up in the air, look down and wave my mouse - and a whole layer of clouds appears. I get to decide what color the sunrise has. That's pretty fascinating as far as that goes.
And actually, I've always enjoyed flying through clouds in flight simulators - in the early ones, they were just so bad, but now I can make them just the way I've always wanted them to be. Flying between two scattered cloud layers is still one of my favourite activities.
- Are there any "hidden features" you have worked on in FlightGear that new users may miss?
Plenty. Several I decided not to release since they are too tricky to control, so flags switch them off. For instance, there's a working model for wave lift in the Advanced Weather code, but there is no code to automatically place it (that's much more tricky to develop), so the wave needs to be placed by hand with a suitable line of Nasal. There are experimental cloud layer definitions which are just too expensive to render on a normal system. Many things I just try, and when I find no good way of implementing them, they stay in the code in a de-activated mode.
- What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?
Be patient. The world doesn't revolve around you, but good work is recognized eventually.
Many people seem to expect that the FlightGear development community is just waiting for their contribution and jump to fill every requirement. But every developer has his own agenda, and the way things actually work is by convincing people that spending their time to support another project is a good idea. For instance, demonstrating that a project is feasible is a good idea before expecting help.
I know it looks pretty unwelcoming if someone wants to contribute and needs to go a long way before getting help. On the other hand, I know the other perspective of investing a lot of work into someone's project, just to see the other person disappear and all that work being lost. So I understand much better that established developers want to see that someone is serious about what he proposes to do before they jump in.
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. |
Scenery corner
OpenStreetMap license change completed
On September 12, OpenStreetMap (OSM) completed its long expected license change. From now on, OSM data is licensed under the Open Database Licence. Since the new license is compatible with the GNU GPL license that FlightGear falls under, FlightGear scenery projects can make use of a whole new class of data.
With the switch only just completed, it is still to be decided in what way OSM data can and will be used in official FlightGear scenery. Several possibilities are discussed in the following wiki articles:
- OpenStreetMap import: using object positions for shared objects, like windturbines, oil tanks and power line pylons.
- OpenStreetMap buildings: extracting 3D models from building floorplans.
- OpenStreetMap line data: roads, rivers and railroads can be included in scenery. The scenery building tools (TerraGear) are currently improved to be able to handle the large density of roads that OSM has in some regions of the world. The required process is discussed in:
TerraGear GUI received new functions
The TerraGear GUI, an user interface to generate FlightGear scenery, received several improvements this month. Besides a couple of (small) bug fixes, two features deserve to be highlighted here:
- The list of materials to choose from now displays the respective textures. This makes it easier to pick the right material.
- Elevation data can now be downloaded for the entire world. The GUI does this automatically, all you need to do is specify a bounding box for the to-be-created scenery.
- Besides 3 arcsec elevation data (SRTM-3), more accurate 1 arcsec data (SRTM-1) can be downloaded for the USA.
Feedback is welcome as always!
Tools
It is now possible to update the geographical data of static models using our webtools, just like you are now used to to with the shared objects. You just have to select the object corresponding to the 3D model, and then click on "update".
Iberia
Taking advantage of the license change of OpenStreetMap, a project to improve the Iberian Peninsula (Europe) has started. This area includes the continental territories of Spain, Portugal and Andorra. The project uses the data from CORINE database for the land use, and OpenStreetMap for the landmass and roads. Moreover, the models of Barcelona-LEBL, Reus-LERS, Menorca-LEMH, Valencia-LEVC and Granada-LEGR are updated to the last version of FlightGear and included in the project files. The scenery files has been divided in 10 zones to allow an efficient management of the data.
|
|
| Bay of La Concha (Airport: LESO) | Costa Daurada (Airport: LERS) |
The creation of the scenary is still an on-going project. Additional information and temporary data files can be found at Vive FG!
Community news
FSweekend 2012
On 3 and 4 November 2012, FlightGear will be present at FSweekend 2012, the world's largest flight simulator event. A team of FlightGear developers from all over Europe will introduce FlightGear to the visitors and answer questions from interested simmers. Every year people are surprised to find out that there is a free and open alternative to the known flightsims.
Will you visit our booth? More information can be found at the event's page: FSweekend 2012.
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.
To learn more about how the project works, please see this short essay written by Thorsten.
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 OpenRadar project is looking for a new maintainer.
- The FGFSPM (FlightGear Package Manager) is looking for a new maintainer.
References
|