FlightGear Newsletter March 2014

From FlightGear wiki
Revision as of 16:30, 14 March 2014 by Hamster (Talk | contribs) (Bash Completion: cleared up history)

Jump to: navigation, search

Welcome to the FlightGear Newsletter!
Please help us write the next edition!
Enjoy reading the latest edition!

Template:Newsletter being written

Development news

Note to all contributors: Please also copy your newsletter additions to the changelog for the upcoming release: Next Changelog.

Installing TerraGear in 10 seconds on Linux

TerraGear hgtchop running in a 64bit TurnKeyLinux VM using saiarcot895's debian/wheezy packages

As part of working on a long-standing feature request, namely having a central shared TerraGear scenery build server, saiarcot895 has created Linux packages for Debian/Ubuntu (deb/ppa) to install precompiled TerraGear binaries. This now greatly simplifies installing TerraGear, because people no longer need to manually set up a complete Linux build environment and all SimGear/TerraGear dependencies. Everything is now done in an automated fashion.

Next, we're hoping to use this to install TerraGear on a public server for which people can ask for remote shell access (SSH). People interested in exploring this, should be getting in touch via the forum or the wiki.

Obviously, users will still need to be familiar with TerraGear, but they may benefit from reduced bandwidth restrictions and/or more horsepower in comparison to running TerraGear locally (e.g. one user offered to contribute hosting on a 32gb RAM and 8-core server). So this could be a great opportunity for people to run scripted/unattended jobs, without having to go through the hassle of downloading/building/installing and configuring TerraGear. But so far, being familiar with TerraGear and Linux is going to be a prerequisite still.

Once that is working, we'll investigate making the setup reproducible by using TurnKeyLinux. Once we have a working TKL distro, we can install a full TG setup in just a few minutes by downloading an ISO file and installing it in a VM (VMWare/VirtualBox). This would basically allow people to easily download/install TerraGear locally, either installed next to their OS, or as a virtual machine.

The long term idea is to hook up TerraGear GUI to it, so that the GUI front-end talks to TerraGear across SSH.

This is currently still a use-case for which TG wasn't designed for, and the TG developers mentioned already on the forums that there may be some roadblocks ahead, so everything here is still highly experimental. But ultimately we hope to provide a front-end to a Linux-based TerraGear VM, either by reusing TerraGear GUI or by coming up with a custom web-based front-end (please get in touch if you can help with this!).

If you're interested in helping or learning more, please get in touch via the forum or via TerraGear scenery build server.

Modified JSBSim search paths

AndersG has changed the search paths for JSBSim engines, propellers and systems in FlightGear to make it possible to have engines, propeller and system files shared by several aircraft stored in one place instead of keeping copies below each aircraft directory.

The change adds $FG_ROOT/Aircraft/Generic/JSBSim/{Engines,Systems} to the JSBSim engine, propeller and system search paths.

JSBSim searches <aircraft_dir>/Engines and <aircraft_dir>/Systems for the requested files before looking in the shared directories. This is consistent with how JSBSim works as a standalone program and should not cause any existing aircraft to load a different file than before.

Reset & Reinit

Over the next few days James is going to start switching over the reset system to use the new code. The following changes will happen, in order:

  • places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally.
  • the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path that triggers a reset its the actual menu command / key-shortcut - If anyone knows of some strange way we trigger a reset, please do let me know)
  • the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used
  • Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but James will try to address issues as quickly as possible. Unfortunately each time a fix in preferences.xml is made, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :)

James is not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file.

Continue reading at Reset & re-init...

built-in httpd updated

While working on the new radio/atis implementation, Torsten rediscovered the internal httpd (aka webserver) to browse the property tree. It's much easier to have multiple browser windows open and point to various locations in the property tree than to reopen the internal property browser and navigate to the locations after each sim restart.

After a while, Torsten got disappointed by the functionality and the look&feel of the http property-browser, so he had a look at the code to see if it could be improved, he quickly realized, that the implementation was simple but not scalable, so he looked for something allready available on the GPL market.

And he found Mongoose as a well maintained, feature rich and yet simple implementation of a web server and started to embedd that into FlightGear.

What is ready so far and pushed to next is:

  • A single threaded httpd running in the main loop (should probably get its own thread soon)
  • Running as a replacement for the old httpd
  • Serving FGDATA/Docs as the document root
  • Serving the uri /props/ as a replacement for the old property browser (improved functionality, improved l&f, styling via css)
  • Serving the uri /run.cgi as a replacement for the old interface to run fg_commands
  • Serving the uri /json/ to return selected properties as JSON (read-only so far)

All this has a lot of potential. With the JSON interface extended to being able to write properties, the CGI interface of Mongoose turned on, the webserver running stable in it's own thread, It should be possible to run e.g. PHP with jQuery or dojo.

If you want to test the new functions, go to:

Please mind the trailing slash for /props/ and /json/ (no, it's not bug-free yet.)

Torsten has just pushed a litte quick-and-dirty example to fgdata. If you have a recent build from git/next, start fgfs with --httpd=8080 and point your browser at http://localhost:8080/gui/radio.html You need to be online to see the goodies as the jQuery js is loaded from code.jquery.com and not (yet) pushed to fgdata. The updates every five seconds and does not write back to fg yet.

If you can't run the latest codebase, here is a screenshot: https://www.dropbox.com/s/98ejva4n4m38po1/HTMLRadioSettings.jpg.

Cloud Shadows (by Thorsten)

Thorsten implemented an improved shadow finder on the Nasal side, better shape on the GLSL side... and started teaching the other effects to respect cloud shadows:

In a way, I appreciate the conceptual simplicity of deferred rendering where this can simply be done in pixel postprocessing. If it would just run faster... but anyway, now I got buildings to go out of light properly. nd the cloud shadows now project. Well - sort of - not exactly following terrain and season, just based on mean, but it's good enough if you don't go looking for deviations.

For those interested, here's some details to the technique and why it's implemented the way it is:

I've read up a bit on shadow generation techniques in the literature, and clouds appear to be tricky. Shadow volume techniques are out because they don't work for semi-transparent texture stacks, so it's got to be shadow maps.

Generating a shadow map on the fly requires a shadow camera pass over clouds. I know from prior experience optimizing cloud rendering performance by means of a z-buffer filling first pass that any second pass over clouds is prohibitively expensive - any attempt to pass over clouds a second time drove me below 10 fps for even moderately clouded scenes. If I were to speculate, I'd say that this is the reason clouds in Rembrandt don't cast any shadows in spite of Rembrandt being easily able to include clouds in the shadow camera pass. There are other disadvantages to this approach, for instance a cloud texture could be fairly opaque (i.e. zero alpha) but we still might not want to render a shadow since the cloud is too high and diffraction would erase it, or because the cloud is translucent white and does in fact not cast a shadow, we may want to draw different depth of shadow etc.

So I believe a cloud shadow map needs to be generated procedurally from meta-information supplied by the weather system rather than in the rendering pipeline, since only the weather system knows what a cloud is and whether we want to draw a shadow or not.

There are still two different ways this could be done:

  • the CPU gets the meta-info and assembles a shadow map as texture and passes that texture to the rendering pipeline
  • the GPU gets the meta-info and assembles the shadow map inside the rendering pipeline

In the event, I've chosen the second approach, since evaluating 'simple' functions on the GPU is in my experience (a lot) faster than looking up a large texture (my rule of thumb is that a texture lookup is worth about 10 exp() functions or ~100 simple functions such as smoothstep()). Moreover, texture units are limited to 8, and the model ubershader already uses all available texture units, so there's some merit to not passing a texture.

The current code then passes 40 uniform position data points of clouds with shadow strength and depth encoded in the position information, allowing to draw 20 distinct cloud shadows. The weather system registers a shadow candidate every time a cloud which would cast a shadow is generated (currently that's Cu and Congestus type clouds) and a subroutine of the weather system selects which of these candidates should be drawn by the shader based on the current view position (and fov if the flag is on). The shadows are projected in a rudimentary way, but not exactly, i.e. the projection does not account for season and for terrain elevation - that's the price of framerate-friendliness, but one really has to go look hard to see the projection errors.

So, I believe this technique has pros and cons over an on the fly generation by a camera pass, but framerate friendliness certainly is a big pro here. As indicated above, I will gradually deal with proper shadows in all special-purpose shadows and also register different types of clouds for shadow candidates in the weather system.

I'm not sure whether this can easily be generalized to the way Basic Weather handles clouds, and one point of discussion may be down to which quality level this feature should be supported, so there's plenty to be discussed.

Random Buildings

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.

Canvas System

High Level Architecture

Usability Improvements

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.

If you interested in other developing, i.e. not C++ but Nasal scripting and/or XML, there are some articles listed at Category:Popular Community Requests that have been suggested, but not fully or partially implemented, and are "mentored efforts". That means that the community is looking for a hand in implementing them -- help from you -- but will also have more experienced developers willing to help you, for example by having tailored tutorials or even code snippets written for you. As mentioned in each page, please get in touch if you would like to help with one of those projects. In comparison to C/C++, Nasal is simpler and easier to learn quickly. It also doesn't require recompiling, which means that you can test and develop changes with a standard FlightGear release, i.e. off of the main download page. As long as you can run FlightGear, you can also run Nasal code and contribute. Many tutorials covering a wide range of projects are listed at Nasal, so if you know a programming/scripting language already, or would like to try something new, go ahead: read, write, try and get involved! When it comes to Nasal scripting, playing around with different tutorials and code snippets is more important than being an experienced coder.

Of course, you're also free to work on whatever you want -- FlightGear as a community-driven doesn't tell people what to do, but welcomes any contributions from anybody, as long as they have acceptable quality and are free to be licensed under the GNU GPL. So if you have something you would like to contribute back to FlightGear, please get in touch! (Preferably using Gitorious for larger merge requests, and the forums or (core-) developer's mailing list to inform the developers of what you want to contribute back.) Changes contributed 6-8 weeks before a release will usually appear in the next release, so your changes can be spread across the world.

Release ChangeLog

This section lists changes committed this month that will be available in the next release, these will be copied to the release changelog shortly before a release (for each month), so that we hopefully get a comprehensive list of new features.

Interview with a contributor (NAME)

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?
  • What are your major interests in FlightGear?
  • What project are you working on right now?
  • What do you plan on doing in the future?
  • Are you happy with the way the FlightGear project is going?
  • What do you enjoy most about developing for FlightGear?
  • Are there any "hidden features" you have worked on in FlightGear that new users may miss?
  • What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

More questions are being collected here: Interview questions.

Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX

Nasal for newbies

New software tools and projects

Bash Completion

A new Bash completion script is now available for the fgfs-command. You just have to install the completion script as explained here.

New feature??? Yes, you are right! Bash completion has existed for Flightgear since 2005 (a time where this feature has been really rare!), but not been updated since 2008.

The new release now supports auto-completion for all options from "fgfs --help --verbose", as well as airport codes, aircraft names, parking positions, runways, carrier names, scenarios, navaids, and some more.

If you have questions or comments regarding that script, please post them to this forum thread.

FlightGear addons and mods

In the hangar

New aircraft

Vespa Scooter for FlightGear

Really not a new aircraft per se, but it's flight model borrows from YAsim prop drive aircraft. Some years back I had made a scooter model for Flying Model Simulator, the RC model training simulator. This is the 3D model with some improvements of the basic 3D and additional animations. In use it operates much like a modern 'Twist and Go' CVT transmissioned scooter. You apply throttle and it accelerates, apply brakes, ( both wheels are braked.) using the joystick button 0 or trigger button..) or the period key, (.) for rear and comma (,) for front brakes. Using the rear brake is handy because it applies less braking force and can be used as a 'trailing brake' through corners. My future plans include re-editing the FDM and adding some nasal so this bike has a 4 speed gearbox.
I'm presenting this model for a Multiplayer Event of a Scooter tour of the Isle of Man's famous motorcycle Time Trial Race Course. I'm preparing some 3D scenery files to add to the existing scenery used in the new 2.0 FG scenery for the UK/Europe areas, with it's improved roads.


There will be a couple other bikes made for the FG, although I don't think they will be done in time for the MP event.
I've been approached by Detlef Faber, who offer to adapt his walker figure to use with this scooter. So the user/pilot will have the ability do first person excursions from the bike after parking it. It will also have improved rider animations. I'm also providing the aero-winch tow functions from the FG YAsim glider FDM's on this bike, because it tends to get stuck fast in rough terrain, much like the conifer forest terrain tiles. This is a 'feature' of the YAsim wheel modeling that I like, because it models rough ground and you can make trips off the pavement on some kinds of terrain without having it get stuck.
Start finish of the Isle of Man TT course from the MPMap view
Small displacement TT road racer in development

Updated aircraft


Scenery corner


Aircraft of the month

Airport of the month

Screenshot of the month

Flying by Denali, Alaska, in tricky weather

Near Denali, Alaska

Suggested flights

Aircraft reviews

Piper PA-22

This section contains a review.   Please note that statements made here are (mostly based on) a single person's opinion.
Flying over northeast Ohio
A look out the left side
The cockpit

The PA-22 is a classic post-World War II aircraft. The plane includes an autostart option as well as a tutorial to step you through the process. The takeoff is smooth and steady, only minimal rudder is needed to keep the aircraft lined up with the runway. We rotate at about 55 MPH, accelerate to about 85 MPH, and climb. The climb rate is decent, and pretty soon we reach our cruising altitude of 1000 feet.

After leaning out the mixture a bit, pulling the throttle back to three quarters, I decide to turn on autopilot. There is a tutorial to step you through the use of the autopilot, which is quite simple. Since the autopilot only takes care of roll, we reach up to the ceiling to adjust the vertical trim. Clicking it will cause it to rotate in one direction, middle clicking will rotate it in the other direction.

Now that the plane is flying in a hands-off configuration, we can look around. Since the day I took off on was pretty warm, I decided to open the window for a little breeze. This is easily done by clicking on it. The vents on all four windows also open and close when clicked. If it's dark out you can click the dome light behind you to light up the cockpit. Red-tinted instrument lights are also available.

A little experimentation will show you that it is pretty hard to stall this aircraft. What happens instead is the aircraft mushes with full elevator, and the plane just falls from the sky. You still have control and dipping the nose down a bit and increasing power should get you flying normally again.

We head back to the airport at about 110 MPH to test out the landing charactersitics. As we approach the airport, we slow down to about 90 MPH and lower the flaps fully. Our over-the-fence speed is about 85 MPH, and raising the nose slightly and cutting power over the runway sets us gently on the ground.

The flight isn't over yet though. A little judicial movement on the rudder pedals makes sure we don't turn off the runway. In this regard, a stitch in time saves nine, and small movements as soon as you see a little lateral movement saves having to make large embarrassing ones a second later. Be careful with the brakes, as this plane has a tendancy to dip a wing if applied too roughly.

The flight dynamics seem pretty realistic, the model is excellent (it even has four liveries and a paintkit), and the 3D cockpit is superb. One thing I would suggest is having it remember your preference whether to show or hide the wheel pants, but apart from that I don't see anything lacking.

-- Flyingfisch (talk) 20:54, 13 March 2014 (UTC)

Wiki updates

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.
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 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.

Community news

FlightGear on YouTube

New tutorials and screencasts

Forum news


Virtual airlines

FlightGear events

Hang gliding simulator

Hang gliding simulator using FlightGear
FlightGear is being used to power a hang gliding simulator to be presented on March 8th/9th in Bremen at the Rad+Outdoor / Passion 2014 convention, hall 4B, booth 60.

The pilot sees the simulation through an Oculus Rift head mounted display ([2]). Input is controlled by a joystick that is mounted upside down to catch user input. The whole simulator runs out of the box with proper command line/config options in FlightGear.

See the Forum thread for some details.

Useful links

And finally ...


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.

YASim looking for a new maintainer

Cquote1.png There are some pending merge requests to add some Yasim features, but we have an issue that since none of the current C++ developers own, or are experts in Yasim, we're reluctant to be the person who merges such changes, and potentially introduces subtle regressions.

Obviously this is chicken-and-egg, since no one can become expert enough in the code to become a maintainer :)

So, I'm more than happy to apply patches *providing* I can be convinced they are sane+reasonable from a pure code perspective (happy to help with that, too, if people are new to C++), and providing we have some assurance that a representative sample of yasim aircraft are unchanged or improved by the patch. Suggestions for that means in practice, are most welcome!

Otherwise I worry, given the nature of the solver, we'll keep optimising the solver for some aircraft, and making other existing aircraft worse - until someone tests them, and announced that they're no longer working.[1]
— James Turner
Cquote1.png I am still broadly happy to answer questions if posed (as long as I remember enough to come up with a meaningful answer). Just cc: me if you do, because my

latencies here are measured in weeks.

Bugs can always be fixed. What YASim needs is a maintainer, not really expertise per se. The latter comes from the former.[2]
— Andy Ross
  1. James Turner (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.
  2. Andy Ross (Fri, 05 Oct 2012 03:54:43 -0700). YASim and documentation.

Call for volunteers

  • The Target4Today team is looking for volunteers to help improving FlightGear's combat support

Did you know