FlightGear Newsletter September 2014: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Added an "In The Hangar" Section and the A300-600)
(Switch to the {{forum link}} template for all forum links.)
 
(14 intermediate revisions by 5 users not shown)
Line 3: Line 3:
{| width="100%" |
{| width="100%" |
| valign="top" width="33%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|FlightGear 3.2 released (this time for real!)}}<br/>
{{Newsletter-cover-item|DDS feedback needed}}<br/><br/>
{{Newsletter-cover-item|DDS feedback needed}}<br/>
{{Newsletter-cover-header|Development news}}<br/>
{{Newsletter-cover-item|Aircraft moved to SVN}}<br/>
{{Newsletter-cover-item|Aircraft moved to SVN}}<br/>
{{Newsletter-cover-item|Improve the multiplayer experience}}<br/>
{{Newsletter-cover-item|Preview of FGCamera v1.1 features}}<br/>
{{Newsletter-cover-item|The hidden map}}<br/>
| valign="top" width="33%" |
| valign="top" width="33%" |
{{Newsletter-cover-header|Other}}<br/>
{{Newsletter-cover-item|Using Ada in FlightGear}}<br/>
{{Newsletter-cover-item|Performance issues}}<br/>
{{Newsletter-cover-item|Performance issues}}<br/>
{{Newsletter-cover-item|The hidden Map}}<br/>
{{Newsletter-cover-item|Learning Canvas using copy and paste}}<br/>
 
{{Newsletter-cover-item|Dynamic liveries via Canvas: exhaust dirt}}<br/>
{{Newsletter-cover-item|Interview with a contributor}}<br/>
| valign="top" width="33%" |
| valign="top" width="33%" |
{{Newsletter-cover-item|Interview with a contributor}}
{{Newsletter-cover-header|In the hangar}}<br/>
{{Newsletter-cover-item|Airbus A300-600}}<br/><br/>
{{Newsletter-cover-header|Events}}<br/>
{{Newsletter-cover-item|FSweekend 2014}}<br/>
|}
|}
</div>
</div>
Line 30: Line 39:
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.
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]]...
Continue reading and report your experiences at [[Switching default texture format to DDS]]...


== Aircraft moved to SVN ==
==Development news==
=== Aircraft moved to SVN ===
Some months ago we decided to host our aircraft on an SVN repository in order to relieve <code>fgdata</code>.
Some months ago we decided to host our aircraft on an SVN repository in order to relieve <code>fgdata</code>.
The <code>fgdata</code> repo would be a mirror of the base package.
The <code>fgdata</code> repo would be a mirror of the base package.
Line 40: Line 50:
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".
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 ===
'''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 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 (<code>fgdata</code>) which is lighter to sync for new contributors and easier to keep up to date.
On the developer side, the most important interest is to have a base package (<code>fgdata</code>) which is lighter to sync for new contributors and easier to keep up to date.


=== A mini HowTo ===
'''A mini HowTo'''
* For Windows:  Install TortoiseSVN (http://tortoisesvn.net/)  
* For Windows:  Install TortoiseSVN (http://tortoisesvn.net/)  
* For Linux/Mac:  Install SVN
* For Linux/Mac:  Install SVN
Line 59: Line 69:
The aircraft will remain in the <code>fgdata</code> Git repository for a few months, until everyone has transitioned to the SVN repositories.
The aircraft will remain in the <code>fgdata</code> Git repository for a few months, until everyone has transitioned to the SVN repositories.


=== Background ===
'''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: https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971
For our aircraft developers who don't regularly read the mailing list (even though any aircraft developers should already be subscribed), please read [https://sourceforge.net/p/flightgear/mailman/flightgear-devel/thread/DUB127-W168600DE27B42094E5263EC3C10%40phx.gbl/#msg3280971 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.
{{#ev:youtube|YUG7G0IMpXc}}
{{#ev:youtube|jZnIB1gKpYM}}
 
=== Improve the multiplayer experience ===
The previously introduced <code><usage>interior</usage></code> 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 ===
[[File:FlightGear-Map-on-Android.png|right|x400px]]
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 <code>--httpd=8080</code> 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 ==
[[File:FlightGear built using gnatmake.png|thumb|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 [[Developing using CMake|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 [http://plplot.sourceforge.net/ 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.


== Performance Issues ==
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 [[Howto:Add new fgcommands to FlightGear|fgcommands]] to be implemented in Ada, as well as new [[Howto:Create new subsystems|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.  
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.  


Line 69: Line 121:
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 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.
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:


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.  
{{FGCquote
  |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.<br/>
Torsten
  |{{cite web |url=http://sourceforge.net/p/flightgear/mailman/message/32846172/
    |title=<nowiki>Re: [Flightgear-devel] crash in SGPropertyNode::fireValueChanged</nowiki>
    |author=<nowiki>Torsten Dreyer</nowiki>
    |date=<nowiki>2014-09-18</nowiki>
  }}
}}
 
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 {{forum link|t=21496}} {{forum link|p=192091}}) - 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:
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:


* [[FlightGear Headless|Running FlightGear headless]] (i.e. without a window, used for subsystem performance testing)
* [[FlightGear Headless|Running FlightGear headless]] (i.e. without a window, used for subsystem performance testing)
* [[Testing|Testing Performance]]
* [[Testing|Testing Performance]]


Line 123: Line 186:
Pui slowness.png|The old PLIB/PUI GUI is shown here rendering a Canvas Widget with a [[MapStructure]] layer, a few users have reported that PUI is significantly slowing down the simulator
Pui slowness.png|The old PLIB/PUI GUI is shown here rendering a Canvas Widget with a [[MapStructure]] layer, a few users have reported that PUI is significantly slowing down the simulator
MapStructure self test over embedded PUI widget.png|And for comparison a native Canvas window also using the [[MapStructure]] framework,without going through PUI (better performance)
MapStructure self test over embedded PUI widget.png|And for comparison a native Canvas window also using the [[MapStructure]] framework,without going through PUI (better performance)
Canvas aircraft center on intel GMA graphics.png|[[Aircraft Center]] running on integrated Intel GMA graphics (25ms/@60 fps, 20-30% performance impact when interacting )
</gallery>
</gallery>
-->


== The hidden Map ==
== Learning Canvas using copy and paste ==
[[File:FlightGear-Map-on-Android.png|right|400px]]
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:
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.
{| class="wikitable"
To enable the internal browser-based map, you need to enable the internal web server by adding <code>--httpd=8080</code> to your command line.
|-
Consult your mobile devices operation manual about how to add a web page as a full screen App.
! Screenshot !! Code !!
|-
| [[File:Snippets-canvas-dialog.png|left|thumb|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: [[Object_Oriented_Programming_with_Nasal#More_on_methods:_Chaining|Method Chaining]].}}
 
<syntaxhighlight lang="nasal" enclose="div">
# 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();
</syntaxhighlight>
|-
|}
 
See: [[Canvas Snippets]]
 
== Dynamic liveries via Canvas: exhaust dirt==
''by [[User:Algernon|Algernon]] ([[User talk: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.  
 
<gallery mode="packed">
Two-layers.jpg|The two textures concerned, the ASG paintwork and the separate alpha transparency with dirt streaks
Dynamic-Textures-First-Try.jpg|A first (failed) attempt to put a canvas onto a model object in place of its texture.
Ef2000dyn1.jpg|The EF2000 showing a dynamically-changed texture on the fuselage - at the moment, the resolution appears to be wrong and the UV coordinates seem to be being ignored.
File:Ef2000dyn2.jpg|Changing the dialog window size to be the same size as the texture fixed the issue - note that the fuselage sections are free of dirt (except the APU exhaust smudge, which is a special case) where as the wings and tail have integral dirt in the texture.
File:Ef2000dyn3.jpg|A full-screen illustration using the updated Canvas code to make the canvas independent of the window, but with the window still displaying the canvas. Here, only the base "clean" paintwork texture is added to the fuselage element.
File:Ef2000dyn4.jpg|After creating a canvas with the base "clean" paintwork texture, another child is added containing the dirt layer transparency. The effect is seen both in the dialog window and on the airframe.
</gallery>
 
 
To learn more, see [[Howto:Dynamic Liveries via Canvas]]


== Interview with a contributor ==
== Interview with a contributor ==
Line 190: Line 293:
'''Good day then, and thanks for agreeing to this interview.''' No problem.
'''Good day then, and thanks for agreeing to this interview.''' No problem.


==In the Hangar==
== In the hangar ==
 
=== Airbus A300-600 ===
'''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).
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.  
Currently, the engines are always on, but I am now working on an autostart system, which will also be in the next release.  


<gallery mode=packed widths=230px heights=230px>
<gallery mode=packed widths=230px heights=230px>
Line 201: Line 303:
File:A300-600 Flightdeck.png|The "Office"
File:A300-600 Flightdeck.png|The "Office"
</gallery>
</gallery>
== 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 [http://fsweekend.com fsweekend.com]
[[File:FSweekend banner 2014.jpg]]
[[Category:FlightGear Newsletter|2014 09]]

Latest revision as of 12:28, 6 June 2019

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


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