FlightGear Newsletter September 2014

From FlightGear wiki
Revision as of 16:24, 1 October 2014 by Gijs (talk | contribs) (Subject categories, shuffle around, wiki syntax)
Jump to navigation Jump to search
Magagazine.png
Enjoy reading the latest edition!
Please help us write the coming edition!
September 2014

DDS feedback needed

Development news
Aircraft moved to SVN
Improve the multiplayer experience
Preview of FGCamera v1.1 features
The hidden map

Other
Using Ada in FlightGear
Performance issues
Learning Canvas using copy and paste
Dynamic liveries via Canvas: exhaust dirt
Interview with a contributor

In the hangar
Airbus A300-600

Events
FSweekend 2014

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 and report your experiences at Switching default texture format to DDS...

Development news

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

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

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

Preview of FGCamera v1.1 features

FGCamera v1.1 is coming soon. New features:

  • View categories;
  • Each view can open GUI dialog;
  • Views can be cloned.

Improve the multiplayer experience

The previously introduced <usage>interior</usage> tag has been extended to support MP/AI models. A new level of detail (LOD) key is added to the LOD dialog which affects the distance of loading the interior model of AI/MP models. The default value is 50 meter. In other words, the interior model of AI/MP is loaded only when you are at less than 50 meters of the AI/MP models.

See Modelling guidelines for more tips on how to create optimized models.

The hidden map

FlightGear-Map-on-Android.png

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

Using Ada in FlightGear

FlightGear built with optional support for Ada

Recently, we've had an interesting discussion on the forum where some of FlightGear's threading issues were discussed, and a few contributors mentioned that Ada would have better tasking support than C++ because C++ support for tasking/multi-threading is generally considered fairly "low-level". Other programming languages, like Ada, provide native support for multi-threading using built-in primitives like tasks and protected types.

Meanwhile, a few contributors have teamed up to explore using Ada in FlightGear to make some experiments.

We're hoping to document the steps required to extend our CMake build system to support optional modules implemented in Ada as discussed by onox, Flying toaster and Hooray on the forum, including support for mapping existing C++ classes to Ada (e.g. from OSG and/or OpenRTI).

The main goal being here to leverage Ada's native tasking support for prototyping optional features that do not have to be running in the FlightGear main loop.

We've already found some existing CMake modules that we can reuse: The PLPlot project is implemented using C, C++ and Ada and provides a set of CMake modules that are scheduled to be merged into CMake soon.

Hooray has copied those files into a branch of $FG_SRC and ended up with a working build environment that successfully links in Ada modules. For starters, we'll be playing with optionally allowing fgcommands to be implemented in Ada, as well as new SGsubsystems.

Next, we'll be exploring how to add thin bindings using -fdump-ada-spec for existing SimGear/OpenRTI (HLA) headers and document the whole process on the wiki.

Using -fdump-ada-specc to create bindings for SG/HLA classes to create standalone HLA federates in Ada would make FG pretty compelling for anybody doing this kind of thing professionally, because Ada simply happens to be widely used in the aviation industry, and it seems there are even bindings of complex stuff like OSG available.

To learn more, please see Howto:Using Ada in FlightGear

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. Meanwhile, Stuart has joined Torsten to help with fixing the bug:

Cquote1.png Acutally, Stuart is working on this and has improved the UniformCache I started with. He has a much better insight in the Effect system than I do.

His work is much better than mine but still has some breakage for existing shaders, most prominent one is ALS. We are still investigating whats going on there and I have to ask for just some more patience.
Torsten


Cquote2.png

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[1][2]) - 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.

Learning Canvas using copy and paste

Given that we still have aircraft developers who consider Canvas programming too 'inaccessible', we've started a dedicate wiki article for gathering useful Canvas snippets - early Canvas adopters are obviously invited to help grow this library of snippets over time to turn this into a useful repository for all people wanting to do Canvas development in some shape or form. For starters, here's a simple snippet creating a GUI dialog:

Screenshot Code
This is what the Nasal/Canvas snippet will look like once you pasted it into the Nasal Console and click "Execute".
Note  This example uses so called method chaining, if you're not familiar with the concept, please see: Method Chaining.
# create a new window, dimensions are 320 x 160, using the dialog decoration (i.e. titlebar)
var window = canvas.Window.new([320,160],"dialog");

# adding a canvas to the new window and setting up background colors/transparency
var myCanvas = window.createCanvas().set("background", canvas.style.getColor("bg_color"));

# Using specific css colors would also be possible:
# myCanvas.set("background", "#ffaac0");

# creating the top-level/root group which will contain all other elements/group
var root = myCanvas.createGroup();

See: Canvas Snippets

Dynamic liveries via Canvas: exhaust dirt

by Algernon (talk)

To document the implementation on a FlightGear aircraft from the aircraft developer's point of view, I've chosen one of my pet projects, the Eurofighter EF2000 V2.0 which will be released in early 2015. The intention is to use Canvas to allow multiple textures per livery, in this case those textures being the original livery paintwork and another, alpha-transparent texture consisting of dirt streaks specifically added to the livery paintwork to match with vents, seams and other sources of grimy build-ups. The intention is to allow dynamic management of the transparency of the dirt layer according to time and exposure to various elements, maintaining compatibility with the standard livery switching method and working similarly whether Rembrandt is enabled or not.


To learn more, see Howto:Dynamic Liveries via Canvas

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.

In the hangar

Airbus A300-600

This Airbus A300-600 has been developed by Airbus330 and Toryx (Developer of the A310), using many parts of the A310. The flightdeck was taken from the A300-600ST, but has the addition of a Cockpit Controllable Autopilot. It has a reasonably detailed exterior model, with accurate flap, speed brake, and spoiler position animations, tail surface animations and tyre smoke. The interior now consists only of the cockpit, but that is fairly detailed except for the overhead panel. The version currently available for download from the forum or wiki has only the A300-603, but a version with the A300-600F will soon be released, (as soon as I make enough liveries). Currently, the engines are always on, but I am now working on an autostart system, which will also be in the next release.

Events

FSweekend 2014

Next month, in the weekend of 1 and 2 November 2014, a team of FlightGear developers will present FlightGear to the public at the world's largest flightsimulator event. The so called FSweekend is held yearly in the Aviodrome aviation museum at Lelystad Airport (EHLE), the Netherlands. The team would love to welcome you in Lelystad!

More info can be found at fsweekend.com

FSweekend banner 2014.jpg