Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

FlightGear Newsletter September 2014

From FlightGear wiki
Revision as of 03:50, 15 September 2014 by T3r (Talk | contribs) (The hidden map)

Jump to: navigation, search
Enjoy reading the latest edition!
Please help us write the coming edition!
September 2014

FlightGear 3.2 released (this time for real!)
DDS feedback needed
Aircraft moved to SVN

Performance issues
The hidden Map

Interview with a contributor

DDS feedback needed

We are looking for feedback about possibly adopting DDS textures in FlightGear. There are several advantages in doing so:

  • DDS is a more compact format than png, hence the download size of the FG base package may be decreased
  • Compressed DDS can be directly used by many graphics cards, reducing also GPU memory consumption
  • DDS stores all texture resolution levels, i.e. no lower resolution levels have to be generated when the texture is used, hence it loads much faster into memory
  • The resolution levels ('mipmaps') can be customized, allowing for some interesting effects at no performance cost

Practically all commercial simulations use DDS for these reasons.

However, the DDS compression algorithm is patented, which means that it is not readily available for open source graphics drivers used by most Linux distributions. Dependent on the specific hardware, this may or may not be a problem (modern graphics cards typically do not need the driver to process DDS, for older graphics cards there are non-patented workarounds available which decompress the DDS on the software level). The development team is concerned about making the FlightGear experience pleasant for all users, hence we would like to gather feedback how many users would be affected by a change in practice.

If there are no problems reported, FG will change defaults to textures in DDS format with the 3.4 release, and then phase out the use of png textures.

Continue reading at Switching default texture format to DDS...

Aircraft moved to SVN

Some months ago we decided to host our aircraft on an SVN repository in order to relieve fgdata. The fgdata repo would be a mirror of the base package.

We finally moved all our aircraft to the new SVN repo: http://sourceforge.net/p/flightgear/fgaddon/

This repository is named "FGAddon" because its content is not required to run FlightGear but provides a new feature (aircraft in this case); this is usually called an "addon".


On the user side, the most important feature is to be able to checkout only desired aircraft, as you no longer need to download the 400+ aircraft at once.

On the developer side, the most important interest is to have a base package (fgdata) which is lighter to sync for new contributors and easier to keep up to date.

A mini HowTo

Then to fetch an aircraft (in this example we pick up the DR400 Dauphin):

svn co https://svn.code.sf.net/p/flightgear/fgaddon/trunk/Aircraft/DR400-dauphin

Then you can regularly fetch the latest updates with

svn up

If you are used to use Git, svn co and svn up are similar to git clone or git pull.

The aircraft will remain in the fgdata Git repository for a few months, until everyone has transitioned to the SVN repositories.


For our aircraft developers who don't regularly read the mailing list (even though any aircraft developers should already be subscribed), please read this topic: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971

Performance Issues

Several FlightGear users have pointed out inexplicable "slowness" that originally seemed related to the property rules subsystem - which is a subsystem that Torsten originally wrote/ported, so he investigated a little and managed to track this down to a pretty serious bug in the effects subsystem that may end up registering thousands of identical listeners, despite effects/shaders not even being in use necessarily.

So the property rules code wasn't even the culprit but obviously it deals with properties, so easy to mis-identify as the troublemaker.

As some of you may know from working with Nasal code: listeners are not in and of themselves expensive, but running identical listeners over and over again each frame is getting unnecessarily expensive quickly. This doesn't just apply to scripting space, but also to C++ space - here, it's the sheer performance offered by native C++ code that makes it much harder to identify such problems, because code that would bring the simulator down to its knees in Nasal may very well still be "fast enough" for most people with fast computers, despite being still very much "broken", and plain wrong.

As can be seen on the devel list, Torsten has been spending the last weeks troubleshooting the effects system, which isn't exactly straightforward because its original developer is not currently involved in FlightGear, and the code is pretty sophisticated and even multi-threaded (which means that parts of the code may be running concurrently on different CPUs) - however, Torsten did report pretty significant performance improvements recently - he's just pushed his work to a new branch so that other developers (and people building from source!) can have a look and test his changes and report feedback/issues - this will probably mean that it may take a few weeks until all the feedback has come in and implemented - but performance should be improved significantly by then - which also addresses the whole "when will 3.2 be released" question.

Also, Hooray recently built fg on a dual-core netbook with Intel GMA graphics (1gb RAM) to see if/how well Canvas is supported there (some people reported white RTTs due to lack of FBO support) - it is true that doing this more regularly would probably help identify certain issues much earlier - it seems that a few contributors are still trying to spin up FG once in a while on their old computers - Thorsten repeatedly mentioned doing that for regression testing purposes when testing his own work.

But FG would indeed be in a better shape if had some way to do this more often, possibly automatically on some kind of headless build/regression testing server - which kinda is what a few people have been working towards:

Things like the recently discovered listener issue in the effects subsystem or massive memory leaks would stand less of a chance of going unnoticed if we had more people testing FG on old hardware - but it's a chicken/egg problem because you need to be pretty familiar with FG to make it work at all, so most people don't bother - and as a coder you tend to prefer writing code over testing obviously, so given the lack of feedback, FG is leaning more towards power users with the latest GPUs and 1+ gb of VRAM unfortunately - simply because that's where all the testing manpower typically is.

People wanting to change that, need to roll up their sleeves and get involved, and PLEAE provide feedback.

All testing on, and development for, such systems would benefit FG in the long term, because hardware support/compatibility would increase over time - which would also make it possible to target other architectures, i.e. gaming hardware, Rasberry Pi and so on: Howto:Optimizing FlightGear for mobile devices.

And here some initial observations based on running FlightGear on an underpowered Netbook with integrated Intel GMA graphics:

  • our existing GUI truly sucks: whenever a PUI dialog is opened, the frame rate is becoming single-digit
  • once the dialog is closed, it will spike up to ~30 fps, with the Canvas/REPL window still shown (!)
  • hiding the PUI menubar further helps increase frame rate and improve frame spacing
  • hiding the menubar AND closing the REPL dialog, I am getting ~45-50 fps using the minimal startup profile, frame spacing is then roughly in the 60s
  • the navcache is a huge resource hog for people on such systems - initializinig/rebuilding the cache is taking ages (10-20+ minutes here !)
  • it would make sense to refactor the navcache and turn it into a library, so that we can prebuild the navcache - and either do so while packaging a release, or alternatively, during installation (plenty of time there!)
  • in addition, threading would make sense probably, when the navcache was being rebuilt, the 2nd core was idling all the time while 1 core was at 100%
  • Canvas/RTT (FBOs) actually work here (which is a good thing for FGPanel/FGCanvas usage)
  • there are a bunch of default options that will "break" FG for users on such systems, including a number of options that will trigger OpenGL/OSG errors early on

Hooray is hoping to do further testing, using the system monitor and the built-in profiler - keep in mind that this still is the code that contains some pretty severe performance bugs.

If we had more people doing this kind of testing, we could definitely identify, and hopefully eliminate, quite a few performance issues that would not be noticeable on a typical developer's machine. So this could be a worthwhile thing to do, and it would help FG in the long term - i.e. even benefit power users who have 2048 MB of VRAM and 8 cores/12 gb of RAM.

The really interesting "benchmark" here is running osgviewer and fgviewer as comparison, because what FG is doing here isn't much different functionality-wise, and it's using the same technology stack (i.e. OSG), so should provide similar performance.

Unofortunately, we generally don't have many people who do a lot of testing, troubleshooting - or even just provide feedback via the issue tracker - it is definitely true that the Canvas GUI is much faster here, despite containing a ton MORE Nasal code, and despite being MUCH more dynamic/flexible than our existing PUI dialogs.

It would really be awesome to find a handful of people with access to old/slow hardware interested in testing and maybe troubleshooting things - while it would be great if those people knew how to build from source, and how to use git/gitorious, I don't think that's even necessary - we can definitely provide a lot of infrastructure and advice, but most of us don't typically have access to these kinds of computers. And while some of us admittedly aren't bothered by it, it is very true that FlightGear as a whole will benefit from teasing out certain bugs/issues, no matter if those are slowing things down due to CPU/GPU or RAM/VRAM utilization.

But we really need more people willing to do this kind of testing and who can provide feedback regularly - and start yelling once something that previously worked, stops working or is becoming unnecessarily slow - there are a bunch of issues that should have never made it into the code, but which went unnoticed for months (or even years), because it's really only power users/contributors and developers who do this kind of testing, and as I am seeing right now, certain issues are pretty well "masked" on an 8-core, 10 gb, 2gb VRAM machine obviously ...

We've been hoping to create some kind of "benchmark" for years - and this is one of those things that would truly help FlightGear in the long term, because we'd get quantifiable data over time, so that we can easily tell how a certain startup/run-time feature behaves in correlation with how it behaved previously, i.e. compared to updated dependencies (OpenAL, PLIB, OSG) - but also changes to the C++ code in SG/FG itself.

People are generally quick to point at Nasal and its known GC issues, but are usually not experienced enough to look behind the scenes, and the amount of existing C++ code that is doing things in a slow fashion, code that's been lurking in the source tree for years more often than not. Creating some kind of simple benchmark would help all of us, no matter the kind of hardware we have: FlightGear_Benchmark.

If you're interested in getting involved with testing FlightGear and improving compatibility for older/slow systems, please get in touch with Hooray on the forum.

The hidden Map


Did you know that FlightGear has an internal web server? And did you ever ask yourself the question, what does a flight simulator needs a web server for? A nice and impressive use case is a map application that has just been brought to the main menu. Click on "Equipment" and select "Map (opens in browser)". Your web browser will pop up and show a map based on current web standards. It can display OpenStreetMap maps as a base layer as well as satelite image or roads from MapQuest. Overlays for current (real) weather like precipitation and isobares exist. The map can display FlightGear internal navigation data like airports, navaids etc. And it can display AI traffic and multiplayer aircraft, too. Of course, it runs on any descent browser, but not only the one on your FlightGear computer. It is web-app-capable so you can install it to your mobile device (IOS and Android) to have a full screen map App on your tablet or phone displaying your current FlightGear status. All this at almost zero cost for the FlightGear main loop. All the rendering computations are done within your browser. The FlightGear webserver only provides the HTML and JavaScript files and transmits the internal properties over a websocket. To enable the internal browser based map, you need to enable the internal web server by adding --httpd=8080 to your command line. Consult your mobile devices operation manual about how to add a web page as a full screen App.

Interview with a contributor

This month, the interview comes back. Hey everyone, I'm ZLSA. I've used FlightGear for a while now, but I only got into the development side recently.

Um, I'm supposed to ask myself questions? Wait, nobody said I'd have to ask myself questions.

What is your forum nickname, ZLSA? ZLSA.

How long have you been involved with FlightGear? The first version I used was 1.9.1, I think. So circa 2008?

What are your major interests in FlightGear? Well, I like 3d modeling and I'm rather good at it. Do you think I'm good at 3d modeling?

I think you're pretty good at it. So my primary interest in FlightGear is modeling things; I modeled the Piper Archer CX exterior and interior. I also enjoy writing Nasal.

What projects are you working on right now? Well I worked a bit on the Piper last night (just minor tweaks). Did you know that unless you use textures, the ambient color shown in FlightGear is always gray regardless of the exported ambient color? Makes cockpits look awful. Anyway, right now I'm working on a tee hangar. FlightGear doesn't seem to have any tee hangars.

What do you plan on doing in the future? Finish the Piper and add more scenery objects. Having shaders on full with Rembrandt on doesn't help if the only buildings are 80-meter wide cubes.

Why is it that you are interested in flight simulation or aviation in general? FlightGear sparked my interest in aviation when I first played used it. I was just wondering what this fgfs program was.

Are you happy with the way the FlightGear project is going? In general, yes. It's come very far in the past few years. The biggest issue in my opinion is the scenery; I realize that at this point it's infeasible to redesign the scenery model to support dynamic subdivision and landclass transitions, but nothing breaks immersion more than flying over the desert until it suddenly turns into grass.

What do you enjoy most about contributing to FlightGear? Seeing my creations used by other people.

Are there any "hidden features" you have worked on in FlightGear that new users may miss? Nope, sorry.

What advice can you give to new contributors who want to get started on their first aircraft/new feature/Nasal script? Well I'll start this off with an example: when I first started making aircraft (it was an abysmally-modeled aircraft with horrible proportions that I stupidly released) I had no idea what I was doing. It took me several hours to figure out that the <PropertyList> XML file was actually just the property tree in XML. That made things much easier for me. The same thing happened with Nasal when I realized that the name of the <file> parent tag was just the Nasal "namespace". So it might seem complicated, but once you play around with things for a bit, it will make sense.

Have you previously used other flight simulators or simulation software in general? No.

How does FlightGear compare in your opinion? If FSX and X-Plane were both free and open-source, I'd probably choose X-Plane because of the incredible graphics. But since they're both closed and paid products (and FSX is Windows-only while I use Linux), I would (and did) choose FlightGear over the other two major contenders.

What was your first impression about FlightGear? How the heck do you pronounce ornithopter?

Compared to other flight simulation software, what are FlightGear's major benefits in your opinion? It's free and open source. That attracts people, some of whom will contribute back. That is a huge benefit that's often overlooked.

Do you think it is necessary to know how to program in order to contribute to FlightGear? Of course not. It would help, but it's definitely not needed. If every 3d artist reading this contributed a high-quality (but low-poly) model to the scenery database, it would make a huge difference. Similarly, placing objects with the UFO doesn't require any programming and makes a huge difference in the quality of a single FlightGear's airport.

Have you ever used FlightGear professionally or for educational purposes? No and yes. While I haven't ever sat in any GA aircraft, FlightGear has helped me understand flight much better than reading and watching videos ever would.

What about FlightGear as a "game", do you think it can be used as such? Of course. It can also be used as a filler for your hard drive. It's whatever you want to use it for.

On average, how much time do you spend working with/contributing to FlightGear? Probably in the hundreds of hours at this point.

Which of the more recent FlightGear developments do you consider most interesting/appealing? Procedural textures. Rembrandt. Atmospheric light scattering/cloud shadows.

Is there some feature that you'd truly like to see in FlightGear one day? Procedural terrain like in Outerra (not to add craters but to allow client-side scenery improvements while using the same dataset.)

What do you think could be done to attract even more new users and contributors to FlightGear? Higher quality in general. Many users want a flight simulator that just works and looks good; currently, FlightGear is not suited to them.

What about interacting with the FlightGear community? Any tips/experiences you'd like to share? Back up your FlightGear data directory and play around with things.

Have you ever recommended FlightGear to other users, friends/family? No, whenever I mention it they suddenly disappear...

Is there anything else you'd like to share with us? No.

Good day then, and thanks for agreeing to this interview. No problem.