FlightGear Newsletter February 2014

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

Development news

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

Advanced Weather

The Advanced Weather system has received a major upgrade, giving it the capability to draw clouds to whatever range is needed to the visible horizon (largest distance tested was 750 km from low Earth orbit).

The technique used for this utilizes so-called impostors, simple pre-generated texture sheets showing the contents of a 40x40 km weather tile from above in low resolution. Based on the current weather situation, impostors fill the range from the edge of the region where 3d clouds are simulated to the currently selected visibility range / cloud drawing range (whatever is lower). Since the impostors themselves are very simple models, the framerate impact is minimal and independent of the number of apparently visible clouds. A dedicated shader for Atmospheric Light Scattering takes care of matched lighting in low sun conditions.

On systems which can draw 3d clouds up to 80 km and support visibilities larger than that, this improves visuals at high altitude quite a bit.

The functionality is currently in an advanced proof of concept stage - METAR mode is not yet fully supported, and the placement algorithms may still be refined.

Point Lights exposed to Effects

Stuart committed a change that (finally) brings surface lights, including VASI/PAPI/taxi/runway etc. into the xml-defined Effects framework. Kudos to Tim Moore for his original Effects work - it made it very straightforward to enhance with support for point sprites and a custom texture generator required.

The relevant effect is data/Effects/surface-lights.eff. It should allow development of ALS and Rembrandt variants.

Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow. So, if your build fails, please check you've got a recent OSG build installed.

Please let us know if you see any issues with either change. And while at it, Stuart also fixed one of the longest-standing scenery glitches in FlightGear history[1]. Stuart and Thorsten also fixed the black halo that could previously be seen around point lights [2].

A suitable ALS version of the runway lights is now well under way which fogs runway lighting consistently with the rest of the scene. Having the lights inside the shader has additional benefits - it allows to make them more responsive to the environment, in particular the lights are rendered harder and with a sparkle effect, the distance out to which they are visible changes with the level of ambient lights, and in fog lights acquire a halo due to Mie forward scattering.

osg::Simplifier

Stuart has just committed a new rendering option, which allow simplification of the terrain mesh at runtime using the osgUtil::Simplifier node visitor. Many thanks to Clement for discovering this and providing the initial patch.

Driving by a new set of control properties under /sim/rendering/terrain/simplifier/ (some of which are exposed via the Rendering dialog), the Simplifier goes through the OSG terrain representation and simplifies the mesh. The idea is that frame-rates can be increased by reducing the terrain vertex count - I've seen the total vertex count on startup at KRHV drop from 18M to 11M using the Simplifier.

You can configure the Simplifier to run on none, all, or far terrain (i.e. beyond /sim/rendering/static-log/rough).

As there's no such thing as a free lunch, you should be aware of the following quite significant limitations:

• Simplifying the mesh costs CPU. On my laptop it increases the load time for complex tiles around KSFO by up to 20 seconds _per_tile_.
• If you enable it for all terrain, you may notice that the height of objects is incorrect, as they are based on the real tile mesh rather than the simplified one. Depending on the Simplifier configuration and the terrain mesh, this may or may not be obvious!
• If you enable it only for far terrain, the tile is reloaded when you get within /sim/rendering/static-lod/rough of the tile edge. This

shouldn't affect your frame-rate, as it's done by the same PagedLOD that loads random objects, lights and trees.

Stuart didn't see any frame-rate increase using this method, but we know that some people are concerned about the memory-occupancy of the scene-graph with Scenery 2.0, and this may provide some benefit.

The option is not switched on by default - you shouldn't see any impact unless you decide to switch it on in the Rendering dialog.

If this provides a significant frame-rate improvement for people, it might be worth looking into generating the simplified mesh offline or caching it to disk.

Revised Nasal APIs: getprop()/setprop()

As of FlightGear 3.1, getprop()/setprop() arguments (those that form a path) can now be numeric to specify a index, so:

getprop("canvas/by-index", "texture", 1, "name");

is now the same as:

getprop("canvas/by-index/texture[1]/name");

(see merge request 54 and actual commit)

Philosopher's fully interactive Nasal Console REPL

Philosopher has created a very cool Canvas-based, fully-interactive, Nasal Console with a real REPL interpreter (Read-eval-print loop). See his gitorious clone (branch "nasal-console") for the code: [3] - it's currently one file (which can even be copied into the existing Nasal Console) with a menubar entry (under "Debug") for easy access. You can also uncomment the last line of the file to open it immediately. The dialog accepts user input in lines, and if it detects the user has completed a snippet, it executes the last code it's seen and prints a result of the expression on the same area. The most common way to continue input onto another line is to have an unclothed pair of braces/brackets/parentheses, but this REPL is unique in allowing unfinished expressions: blocks (e.g. just plain "if" on one line -- no condition, no body -- or "foreach (var e; list)" -- no body of the loop) and binary/prefix operators (e.g. "1 >", since that doesn't have a right side of the ">"). This however needs some work and tweaking, so it's always a WIP. The other big issue is the text styling -- the latest optimization leads to overlapping if a line of input/output is more than one line when wrapped. The output of print()/printlog()/etc. still goes to the startup OS terminal instead of the dialog. However, it still is useful for quick experimenting -- quam celerrime.

Copy & Paste Programming: A Compass Widget using Nasal/Canvas

Inspired by a a recent forum discussion, we thought that creating a compass widget would be a neat little project for someone interested in learning a bit more about Nasal and Canvas coding, and it should be possible to accomplish with less than 50-80 lines of code actually - there's a ton of stuff that you could reuse (SVG compass rose or an existing 2D panel texture), we have quite a few tutorials on Nasal, Canvas and Image processing (check the wiki). Furthermore, we have the long-term plan to eventually phase out the old 2D panel code and used a modernized Canvas-based version to help with Unifying the 2D rendering backend via canvas. Continue reading at Howto:Parsing 2D Instruments using the Canvas...

A Nasal/Canvas based compass widget

Paste this into your Nasal Console and click Execute:

var CanvasApplication = {
    ##
    # constructor
    new: func(x=300,y=200) {
        var m = { parents: [CanvasApplication] };
        m.dlg = canvas.Window.new([x,y],"dialog");
        m.canvas = m.dlg.createCanvas().setColorBackground(1,1,1,0.5);
        m.root = m.canvas.createGroup();
        m.timer = maketimer(0.1, func m.update() );
        m.init();
        return m;
    },

    del: func me.timer.stop(),

    update: func() {
        var hdg=getprop("/orientation/heading-deg");
        me.compass.setRotation(-hdg*D2R);
    },

    init: func() {
        var filename = "/Aircraft/Instruments/gyro.xml";
        var temp= io.read_properties(getprop("/sim/fg-root") ~ filename); 
        var layers = temp.getValues().layers.layer;

        var z=100;
        foreach(var layer; layers ) {
            print("new layer:", layer.name);

            # if it's  not a texture, skip
            if (!contains(layer, "texture")) continue;

            # get a handle to the texture of the layer
            var texture = layer.texture;
 
            # create an image child for the texture
            var child=me.root.createChild("image")
                             .setFile( texture.path )
                             .setSourceRect( texture.x1, texture.x2, texture.y1, texture.y2 )
                             .setSize(layer.w,layer.h)
                             .setTranslation(20,20)
                             .set("z-index", z +=1 )
                             .setScale(2.5);

           if (layer.w != nil and layer.h != nil)
               child.setCenter(layer.w/2, layer.h/2);

           if (layer.name=="compass rose") {
               print("Found compass layer");
               # child.setCenter(55,55);
               me.compass = child;
           }
        } # foreach

         me.timer.start();
     },
}; # end of CanvasApplication


var InstrumentWidget = {
    new: func(x,y) {
        var m = CanvasApplication.new(x:x,y:y);
    },
};

var compass = InstrumentWidget.new(x:300, y:300);

print("Compass Loaded...!");

Canvas & Shaders: A match made in Heaven ?

For quite a while, we've been thinking that at some point, the Canvass system could probably benefit from being also able to also use FlightGear's Effects/Shader framework, so that canvas textures can also be processed via effects and shaders optionally, before they get drawn. That should make all sorts of fancy effects possible, such as night vision cameras or thermal view, rendered to canvas textures/groups.

That would then disable the default rendering pipeline for those canvas textures and use shaders.

Basically, anything that's not directly possible via the core canvas system or via its Nasal wrappers, would then be handled via effects/shaders. So we would gain lots of flexibility, and performance benefits.

So if people really want to create really fancy textures or camera views, they could use effects/shaders then, which would keep the design truly generic, and it would ensure that there's no bloat introduced into the main canvas system.

We did have some discussions about supporting per-canvas (actually per canvas::Element) effects and shaders via properties recently, TheTom even mentioned a while ago that he is interested in supporting this at some point, especially given the number of projects that could be realized like that (FLIR, night vision, thermal imaging etc).

At the time of writing this (02/2014) the Canvas does not yet include any support for applying custom effects or Shaders to canvas elements or the whole canvas itself - however, supporting this is something that's been repeatedly discussed over time, so we're probably going to look into supporting this eventually[4].

Some very basic prototyping has already taken place and looks pretty encouraging:

• 

  airport selection dialog with a greyscale fragment shader applied to the canvas

• 

  a trivial fragment shader applied to a canvas (the original colors used in the Nasal code were not changed!)

• 

  unmodified airport selection canvas with fragment shader applied

• 

  more canvas fragment shading experiments

Continue reading at Canvas & Shaders

JSBSim Ground Effects

This is a heads up for JSBSim aircraft maintainers that user their own ground detection and handling code. As of today JSBSim, just like YASim, supports ground effects like bumpiness, solid-ground detection and adjusting of friction actors.

Actually JSBSim supports an extra feature, BOGEY contact points sink in a non-solid ground surface but STRUCTURE contact point do not, making it easy to define floats using STRUCTURE contact points.

In order not to pollute /fdm/jsbim too much I've added the following properties:

/sim/fdm/surface/override-level A user defined property which if defined and set to a something higher than 0 will disable the JSBSim ground reactions code completely and the following properties are set to false: /sim/fdm/surface/active /sim/fdm/surface/valid

Otherwise the following applies: /sim/fdm/surface/active

• is set to true

/sim/fdm/surface/valid

• is set to true if there is a valid material available or set to false

otherwise (the material defaults are set).

The following properties are set to their respective values:

/fdm/jsbsim/ground/solid

• flag which defines if the surface is solid not

/fdm/jsbsim/ground/bumpiness

• defines the bumpiness factor

/fdm/jsbsim/ground/maximum-force-lbs

• maximum allowed force for this surface

/fdm/jsbsim/ground/rolling_friction-factor

• rolling friction factor - applies to rolling friction

/fdm/jsbsim/ground/static-friction-factor

• static friction factor - applies to static friction and dynamic friction

These properties are also set for the appropriate gear and contact units.

If you want to keep your old behaviour just set sim/fdm/surface/override-level to 1 somewhere in the configuration files, for Nasal this becomes: setprop("sim/fdm/surface/override-level", 1);

I've updated the Nasal code for the following aircraft in the base package: Aircraft/Alouette-III/Systems/terrain.nas Aircraft/Cap10C/Nasal/cap10c.nas Aircraft/DR400-dauphin/Nasal/dr400.nas Aircraft/DR400/Nasal/dr400.nas Aircraft/F-8E-Crusader/Systems/terrain.nas Aircraft/JA37/Nasal/crash.nas Aircraft/MiG-15/Nasal/MiG-15bis.nas Aircraft/Noratlas/Systems/terrain.nas Aircraft/P-38-Lightning/Systems/terrain.nas Aircraft/PBY-Catalina/Systems/terrain.nas Aircraft/PC-6/Nasal/pc6-b2h4.nas Aircraft/SR71-BlackBird/Systems/terrain.nas Aircraft/VMX22-Osprey/Nasal/terrain_under.nas Aircraft/Short_Empire/Systems/mooring.nas

Not that some of these might actually be YASim aircraft but YASim will just ignore the property.

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.

A MapStructure Debugger

MapStructure Debugger running a NavDisplay and profiling a few layers.

MapStructure is a Nasal-space framework (designed and maintained by Philosopher) for managing layers of symbols in Nasal/Canvas-based mapping displays, which can be used in both aircraft MFDs/instruments like the NavDisplay (ND) and GUI dialogs, like the airport selection or Map dialogs. MapStructure is all about separating the visualization of the map from the visualized data itself, and the way it is shown to, and controlled by, the user. MapStructure is designed as a Model/View/Controller (MVC) framework.

The MapStructure debugger is a simple GUI dialog intended to be used for debugging and benchmarking MapStructure-based charting layers. In its current form, it simply shows a NavDisplay inside the dialog with several layers enabled, including a 2D graph to benchmark each individual layer (such as APT, DME, FIX, TFC). Currently, the dialog is fairly simple and pretty crude, the plotting code is entirely based on FGPlot and needs to be further generalized eventually (see Canvas Plotting Framework). However, so far it's actually working nicely and can help determine where time is spent, i.e. which layers are "expensive" compared to others. In addition, the MapStructure debugger dialog can be used to easily test MapStructure-based maps/charts like Gijs' NavDisplay, without having to start up a complex aircraft like the 747-400 or 777-200ER. In other words, the ND can be easily tested by using the ufo or ogeL - which are usually up and running within ~10 seconds.

Continue reading at MapStructure Debugger...

Canvas System

The F-16CJ is being renovated to include the most realistic fighter HUDs yet. See the progress here:F-16CJ HUD Project Newsletter. It is also online the FG Forum here: FG Forum Topic

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

In the hangar

New aircraft

Junkers Ju 390

Emmanuel BARANGER, (helijah)

The tail gets up during the opening of the bay

above the sea

flying

flying 2

The Junkers Ju 390 was a German aircraft intended to be used as a heavy transport, maritime patrol aircraft, and long-range bomber, a long-range derivative of the Ju 290. It was one of the aircraft designs submitted for the abortive Amerika Bomber project, along with the Messerschmitt Me 264, the Focke-Wulf Ta 400, the Heinkel He 277 (source Wikipedia)

You can now find it in my hangar and on GIT hoping that you like as much as I enjoyed doing it.

Aichi M6A "Seiran"

Emmanuel BARANGER, (helijah)

On the water

The Aichi M6A Seiran (晴嵐?, "Clear Sky Storm" or "Mist on a Fair Day") was a submarine-launched attack floatplane designed for the Imperial Japanese Navy during World War II. It was intended to operate from I-400 class submarines whose original mission was to conduct aerial attacks against the United States. (source Wikipedia)

You can now find it in my hangar and on GIT hoping that you like as much as I enjoyed doing it.

Updated aircraft

Sikorsky SH-60 Bravo Seahawk

James Cusick, (X7cusick8X)

SH-60B Taking off from the USS Carl Vinson

SH-60 Landing

Rotor Wash

The FG Seahawk is an incredibly easy to fly helicopter designed for naval conditions, with its integrated FCS and FDM landing on carrier decks is a blast.

Recently i have take a break form FG but I am proud to announce the updated SH-60B Seahawk! The updates include:

Integrated Pushback

Selectable payloads

95% complete folding animation for carrier deck transit

New Liveries

FDM Fixes

and more

Scenery corner

A great work has been done this month for Spain, such as the city of Barcelona, with the addition of landmarks such as Sagrada Familia, Agbar tower and its airport. These updates are available using Terrasync.

Airports

List of updated airports (mostly in Spain, Brazil, and France):

• LEAB Albecete
• LEAT Alfes
• LEBG Burgos
• LEBL Barcelona - El Prat
• LECD La Cerdenya
• LECI Santa Cilia-Los Pirineos
• LECN Pinar de Castellon
• LEDA Lleida
• LEGE Girona
• LEHC Huescas/Pirineos
• LELL Sabadell
• LELN Leon
• LEPP Pamplona
• LERE Requena
• LESB Son Bonet
• LESL San Luis
• LESO San Sebastian
• LESU Seo de Urgel
• LETL Teruel Plata
• LEVD Valladollid
• LFLG Le Versoud
• LFRB Brest Bretagne
• LFRN Rennes St Jacques
• PHNL Honolulu Intl
• SBNF Ministro Victor Konder
• SBPK Pelotas
• SBRJ Santos Dumont Airport
• SBUR Uberaba
• SPAF Camana

Regional texturing

New regional texture definitions are now available on GIT for Ireland in the CORINE-landcover based WorldScenery 2.0. Enjoy the boglands of Connemara, or the hills and lakes of Kerry. With hires scenery and special textures, the Green Isle is now quite a nice place to explore.

The Ireland texture definitions have full support for procedural texturing and for the autumn coloring effect of ALS.

Models optimizations

Since a few months, works have been done on the scenery to clean existing models to make them lighter but keeping or even improving the overall quality. Among the tasks are deleting unseen faces, making face singled-sided, reducing texture size or removing unused alpha from texture.

Wiki updates

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.

Community news

FlightGear on YouTube

You can stay updated with FlightGear news, updates and tutorials by visiting and subscribing to osjcag's channel on YouTube.

FlightGear ♦ Cross-Country Tutorial II ♦ a VFR guide

It's almost been a year since the first release of Cross-Country Tutorial II.
Now with version three point zero the document is better than ever in many aspects.

Go to the respective FG Forum thread: http://forum.flightgear.org/viewtopic.php?f=72&t=19600 where you can:

• download this tutorial
  • find out more about it
    • post your comments and suggestions

coming up soon is the X-Country 2's own wiki page!

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, for a more detailed article see How the FlightGear project works.

YASim looking for a new maintainer

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. — James Turner

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. — Andy Ross

Call for volunteers

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