FlightGear Newsletter September 2012: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (Switch to the {{forum link}} template for all forum links.)
 
(21 intermediate revisions by 4 users not shown)
Line 5: Line 5:


== Development news ==
== Development news ==
Note to all developers: Please also copy your newsletter additions to the changelog of the upcoming release: [[Changelog_3.0.0]].
<!-- These are currently just a bunch of placeholders for the latest projects (as of 08/2012)  -->
=== Random Buildings ===
=== Random Buildings ===
Shortly after the 2.8 release, a number of users reported severe memory growth issues related to a new feature: [[Random Buildings]].
Shortly after the 2.8 release, a number of users reported severe memory growth issues related to a new feature: [[Random Buildings]].


This was a side-effect of the way in which the buildings were created during tile loading. Stuart has now completely changed the way in which random buildings are generated and displayed to reduce the memory occupancy by using a shader-based scheme similar to random trees.  You should now see significantly lower memory occupancy (500 - 2GB less depending on area and density) when running with random buildings enabled.
This was a side-effect of the way in which the buildings were created during tile loading. Stuart has now completely changed the way in which random buildings are generated and displayed to reduce the memory occupancy by using a shader-based scheme similar to random trees.  You should now see significantly lower memory occupancy (500 - 2GB less depending on area and density) when running with random buildings enabled.
=== NavCache ===
James has pushed a large change to next, which adds a binary cache of most of  the navigation data. The cache is stored in FG_HOME/navdata.cache, and rebuilt if the timestamps on any of the data files change (apt.dat, nav.data, fix.dat and so on). When the cache needs to be rebuilt, startup will take a bit longer  than before, but when the cache is valid, startup is /much/ faster, especially for debug builds:
{{cquote|Memory consumption is also lower, since we don't keep airports / fixes /  taxiways / runways in memory until they're needed.
This is a fairly large change, so please look out for any bugs related to navaids / startup position / GPS / route-manager searches and lookups either getting different results or failing. I've tested here locally and things seem
sane, and have had positive feedback from various testers on IRC and email, but I still expect to find some edge cases which need further work.
There's future work to move even more data into the cache - eg parking positions - which will further help performance for FMS / map systems since we won't need to parse lots of XML data repeatedly. I'm going to let this change settle down before adding more cached data, however.<ref>{{cite web |url=http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg38330.html |title=[Flightgear-devel] Nav-cache|author=James Turner |date=Wed, 19 Sep 2012}}</ref>|James Turner}}
===Initial work on dynamic subsystem creation===
James has added initial code to work on dynamic subsystem creation, so that subsystems become create-able and removable from commands. Only some subsystems are supported so far, since many have non-default constructors or other complexities (see [[FlightGear Run Levels]] for further details). With this, change, it's now possible to dynamically add and remove the traffic-manager at runtime, for example:
<syntaxhighlight lang="php">
fgcommand( "add-subsystem", props.Node.new( { "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}) );
</syntaxhighlight>
The idea is to improve this further so that more and more subsystems in FlightGear can be optionally toggled on/off at runtime, which should help facilitate other ongoing efforts, like the [[FGCanvas]] project for example - ultimately, this will help make FlightGear become more configurable and scalable, but also better usable for other purposes, such as distributed (multi-machine) setups-so that a single binary can be easily used for different purposes.
In addition, it will be much easier for developers to do regression testing and benchmarking once subsystems can be completely disabled, which is another long-standing feature request (see [[FlightGear Headless]]), that should also simplify release preparations.


=== Project Rembrandt ===
=== Project Rembrandt ===
The night vision effect, as well as the cinema effects, are now available for 2.8 users. See {{forum link|t=17602|text=here}} for the download links, details and feedback.
=== Canvas System ===
=== Canvas System ===
<!--additions should also be added to:http://wiki.flightgear.org/Changelog_3.0.0#Some_of_the_major_changes_include: -->
Work has now started to develop a dedicated Nasal module specifically for [[Canvas Maps|mapping/charting purposes]]. A first proof of concept is available in $FG_ROOT/Nasal/canvas/map.nas, but we expect to commit more changes (and a real API) soon. Initially, we'll be collecting all related features in a single "map.nas" module, and refactor/improve things later on.
 
In particular, the idea is to have a single Nasal module as the backend for all mapping/charting tasks in FlightGear, so that existing hard-coded features can be unified and re-implemented via a single consistent Nasal module that serves as a shared backend.
 
Ultimately, this will make it possible to re-implement existing features such as [[ATC-FS]], the [[Map]] dialog and even Brisa's [[Airport Diagram Generator]] or the [[Kelpie Flight Planner]] directly in FlightGear, using Nasal scripting and the [[Canvas]] system, without having to write any C++ code - so that people won't need to use external tools or programming languages to create such applications.
 
In the long run, we want to come up with a very flexible design so that the "map.nas" module cannot only be used for creating maps used in GUI dialogs, but also for creating moving map displays like the existing hard-coded [[Navigation display]] or the [[TCAS]] and WXRADAR displays ("glass" displays), i.e. as cockpit instruments/avionics.
This approach would also make it possible to directly show instruments in GUI dialogs or vice versa.
 
As a first proof of concept, Stuart has added a Canvas-based map to the airport selection dialog, and Hooray has demonstrated that the same technique could be used to add a map widget to the route manager dialog - so that airport selection and route planning could become more intuitive using the [[Canvas]] system. A first stab at an MVC-oriented design to create map layers has now been committed to the base package, documented at [[Canvas Map API]] - this will soon be re-worked to add support for additional dialogs and instruments.
 
For additional info, please see: {{forum link|t=17625}}.
 
In addition, ShivaVG (the vector drawing engine behind canvas) has been extended to support some kind of a non-zero fill rule. It's not really non-zero because instead of incrementing and decrementing depending on the orientation of the drawn overlapping regions it simply checks if at least a single region covers a pixel. For our use cases it
should be enough tough.
 
Some further performance improvements were added: Now the texture is only redrawn if something has changed. So if you don't change the map there shouldn't be any noticeable performance impact anymore.
 
Also the bounding boxes are now only written to the property tree if they are recalculated. This should take some fair amount of changing properties away.
 
 
Seems like now tessellating takes much longer than before due to the amount of data in one single path.
 
The current problem with zooming is that every position of every path gets recalculated with the updated projection, even though this isn't really needed as the projection doesn't noticeably while just zooming
and scrolling around at a single airport.
 
=== Flightplan access via Scripting ===
In advance of converting the Map and NavDisplay to use the [[Canvas]], James has improved the "flightplan()" extension function of the [[Nasal]] scripting interpreter to expose the full route-path vector for each flight plan leg, as a vector on the leg .


=== High Level Architecture ===
=== FlightGear On Android ===


=== Mailing list digest ===
<syntaxhighlight lang="php">
var fp = flightplan();
for (var i=0; i<fp.getPlanSize(); i += 1)
{
  var leg = fp.getWP(i);
  debug.dump(leg.path());
}
</syntaxhighlight>


(by far the easiest option to populate the newsletter with contents is copying/pasting stuff from the forum and the mailing list or the git logs)
With these changes in place, it is already possible to directly show a SVG image for each waypoint and connect them using OpenVG paths, even without separate "icon" support.


=== Usability Improvements ===
=== Usability Improvements ===
Line 41: Line 94:
==== Select Airport ====
==== Select Airport ====


[[File:Select_Airport_dialog.jpg|thumb| The new Select Airport dialog with Canvas display of the airport ]]
[[File:Airport-selection-dialog.png|thumb|The new Airport Selection dialog with Canvas display of the airport]]


The Select Airport and Position on Ground dialogs have been combined.  The combined dialog displays the lon/lat/alt of the selected airport, and also uses [[Canvas]] to display an airport diagram.
The Select Airport and Position on Ground dialogs have been combined.  The combined dialog displays the lon/lat/alt of the selected airport, and also uses [[Canvas]] to display an airport diagram.
Line 48: Line 101:


Aircraft typically have a large number of checklists, covering almost every phase of flight.  Previously, aircraft authors have added checklists to the help text for the aircraft.  This is a bit unwieldy.  To improve matters, there is now an Aircraft Checklists dialog under the Help menu specifically designed to organize and display checklists.  Aircraft authors can create new checklists easily without having to worry about how they will be displayed.  See [[Aircraft Checklists]] for details.
Aircraft typically have a large number of checklists, covering almost every phase of flight.  Previously, aircraft authors have added checklists to the help text for the aircraft.  This is a bit unwieldy.  To improve matters, there is now an Aircraft Checklists dialog under the Help menu specifically designed to organize and display checklists.  Aircraft authors can create new checklists easily without having to worry about how they will be displayed.  See [[Aircraft Checklists]] for details.


==== Integrated Documentation Browser ====
==== Integrated Documentation Browser ====


[[File:Fg-30-doc-browser.png|thumb|Add caption here]]
[[File:Nasal-doc-browser-3.0.png|thumb|New integrated documentation browser]]


Often, especially new FlightGear users are not aware of all the documentation that comes with FlightGear. While the manual is fairly easy to find and pretty accessible (being a PDF file), most of the other documentation in $FG_ROOT/Docs is hardly easy to find and often pretty inaccessible to new users, even though these files are standard text files, because of the non-standard file extensions used by most README* files there.  
Often, especially new FlightGear users are not aware of all the documentation that comes with FlightGear. While the manual is fairly easy to find and pretty accessible (being a PDF file), most of the other documentation in $FG_ROOT/Docs is hardly easy to find and often pretty inaccessible to new users, even though these files are standard text files, because of the non-standard file extensions used by most README* files there.  
That's why we have now added a new built-in dialog to FlightGear which shows most plain text files in $FG_ROOT/Docs directly inside FlightGear, without having to start any other applications.
That's why we have now added a new built-in dialog to FlightGear which shows most plain text files in $FG_ROOT/Docs directly inside FlightGear, without having to start any other applications.
=== Forum digest ===
=== Git digest ===
=== Getting involved as a programmer ===
Please see [[Howto:Start core development]]
== 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 (Thorsten Renk) ==
== Interview with a contributor (Thorsten Renk) ==
''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.''
''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?
* '''How long have you been involved in FlightGear?'''
 
Since late 2009.
Since late 2009.


* What are your major interests in FlightGear?
* '''What are your major interests in FlightGear?'''
 
In the broadest sense, modelling of the environment. I've started out modelling clouds and weather, then as I discovered shaders I've also included dust, haze and light scattering effects, and of late I am into improved ways of texturing the terrain.
In the broadest sense, modelling of the environment. I've started out modelling clouds and weather, then as I discovered shaders I've also included dust, haze and light scattering effects, and of late I am into improved ways of texturing the terrain.


All these areas are related, so it's actually pretty powerful if the same person knows how to affect all of them - for instance, on a rainy day, we not only see an overcast cloud layer, but also the light beneath the clouds is dimmed, the sunrise has a different color hue, the ground is wet and hence darker than usual and there may be water on the ground. Being able to do all these things with the same environment model is pretty cool.
All these areas are related, so it's actually pretty powerful if the same person knows how to affect all of them - for instance, on a rainy day, we not only see an overcast cloud layer, but also the light beneath the clouds is dimmed, the sunrise has a different color hue, the ground is wet and hence darker than usual and there may be water on the ground. Being able to do all these things with the same environment model is pretty cool.


* What project are you working on right now?
* '''What project are you working on right now?'''
 
Procedural texturing, i.e. computing the texture mix to be displayed on the terrain inside the shader code - this allows for effects which would be impossible to achieve with the standard way of assigning textures due to the huge memory footprint.
Procedural texturing, i.e. computing the texture mix to be displayed on the terrain inside the shader code - this allows for effects which would be impossible to achieve with the standard way of assigning textures due to the huge memory footprint.


* What do you plan on doing in the future?
* '''What do you plan on doing in the future?'''
 
Who knows? I have plenty of things I would like to do and in principle know how to do - the problem is just making them run fast enough. It's pretty amazing how fast a graphics card can crunch numbers, but there are limits eventually. And basically every day, looking out of the window and observing the richness in detail on a real sky, I see how inadequate even our most advanced shading models really are. It's amazing how nature solves all the rendering equations in real time.
Who knows? I have plenty of things I would like to do and in principle know how to do - the problem is just making them run fast enough. It's pretty amazing how fast a graphics card can crunch numbers, but there are limits eventually. And basically every day, looking out of the window and observing the richness in detail on a real sky, I see how inadequate even our most advanced shading models really are. It's amazing how nature solves all the rendering equations in real time.


* Are you happy with the way the FlightGear project is going?
* '''Are you happy with the way the FlightGear project is going?'''
 
Mostly. I know many people think FlightGear should have a project structure which works more like a commercial project, i.e. with clearly defined project goals and well-defined tasks. Rather, it is a somewhat anarchic collection of different individual projects merged together, often with multiple ways to solve the same problem (we support as many as four different ways to generate clouds for instance) which makes it not always easy for new contributers in need of a feature. But, coming from a research environment, I actually feel quite at home with such a development model - science works the same way, and for instance, while having several independent ways of doing the same thing can be seen as a waste of resources, it can also be seen as a feature - we explore many different ways of doing things which helps us find the best solution.
Mostly. I know many people think FlightGear should have a project structure which works more like a commercial project, i.e. with clearly defined project goals and well-defined tasks. Rather, it is a somewhat anarchic collection of different individual projects merged together, often with multiple ways to solve the same problem (we support as many as four different ways to generate clouds for instance) which makes it not always easy for new contributers in need of a feature. But, coming from a research environment, I actually feel quite at home with such a development model - science works the same way, and for instance, while having several independent ways of doing the same thing can be seen as a waste of resources, it can also be seen as a feature - we explore many different ways of doing things which helps us find the best solution.


What I don't like is that there is often a lot of friction - for instance 3-D modellers feel underappreciated since most of the project decisions are made by the coders, there's an ongoing controversy between scripting space (Nasal) and C++ coding, and there are contributors of world scenery vs. custom scenery creators. While some level of discussion seems useful to me, related discussions often reach a point which I find no longer productive.
What I don't like is that there is often a lot of friction - for instance 3-D modellers feel underappreciated since most of the project decisions are made by the coders, there's an ongoing controversy between scripting space (Nasal) and C++ coding, and there are contributors of world scenery vs. custom scenery creators. While some level of discussion seems useful to me, related discussions often reach a point which I find no longer productive.


* What do you enjoy most about developing for FlightGear?
* '''What do you enjoy most about developing for FlightGear?'''
 
The same thing Tolkien enjoyed about writing 'The Lord of the Rings' - the possibility to do subcreation. The visible FlightGear scenery is a world to explore, and this world is directly and visibly influenced by code I write. I can place myself high up in the air, look down and wave my mouse - and a whole layer of clouds appears. I get to decide what color the sunrise has. That's pretty fascinating as far as that goes.
The same thing Tolkien enjoyed about writing 'The Lord of the Rings' - the possibility to do subcreation. The visible FlightGear scenery is a world to explore, and this world is directly and visibly influenced by code I write. I can place myself high up in the air, look down and wave my mouse - and a whole layer of clouds appears. I get to decide what color the sunrise has. That's pretty fascinating as far as that goes.


And actually, I've always enjoyed flying through clouds in flight simulators - in the early ones, they were just so bad, but now I can make them just the way I've always wanted them to be. Flying between two scattered cloud layers is still one of my favourite activities.
And actually, I've always enjoyed flying through clouds in flight simulators - in the early ones, they were just so bad, but now I can make them just the way I've always wanted them to be. Flying between two scattered cloud layers is still one of my favourite activities.


* Are there any "hidden features" you have worked on in FlightGear that new users may miss?
* '''Are there any "hidden features" you have worked on in FlightGear that new users may miss?'''
 
Plenty. Several I decided not to release since they are too tricky to control, so flags switch them off. For instance, there's a working model for wave lift in the Advanced Weather code, but there is no code to automatically place it (that's much more tricky to develop), so the wave needs to be placed by hand with a suitable line of Nasal. There are experimental cloud layer definitions which are just too expensive to render on a normal system. Many things I just try, and when I find no good way of implementing them, they stay in the code in a de-activated mode.
Plenty. Several I decided not to release since they are too tricky to control, so flags switch them off. For instance, there's a working model for wave lift in the Advanced Weather code, but there is no code to automatically place it (that's much more tricky to develop), so the wave needs to be placed by hand with a suitable line of Nasal. There are experimental cloud layer definitions which are just too expensive to render on a normal system. Many things I just try, and when I find no good way of implementing them, they stay in the code in a de-activated mode.


* What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?
* '''What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?'''
 
Be patient. The world doesn't revolve around you, but good work is recognized eventually.
Be patient. The world doesn't revolve around you, but good work is recognized eventually.


Line 112: Line 145:


I know it looks pretty unwelcoming if someone wants to contribute and needs to go a long way before getting help. On the other hand, I know the other perspective of investing a lot of work into someone's project, just to see the other person disappear and all that work being lost. So I understand much better that established developers want to see that someone is serious about what he proposes to do before they jump in.  
I know it looks pretty unwelcoming if someone wants to contribute and needs to go a long way before getting help. On the other hand, I know the other perspective of investing a lot of work into someone's project, just to see the other person disappear and all that work being lost. So I understand much better that established developers want to see that someone is serious about what he proposes to do before they jump in.  
More questions are being collected here: [[Interview questions]].
Stay tuned for next month's interview, featuring FlightGear contributor XXXXXXXX
== Snapshot releases ==
Every now and then, easy-to-install development snapshots are created (usually, twice montlhy). These snapshos depict a recent state of the development version of FlightGear. By using them users can test out features that will be included in the upcoming release. Testers are encouraged to file bugs at [http://code.google.com/p/flightgear-bugs/ the issue tracker].
The snapshot can be download via the links at the bottom of this page: http://www.flightgear.org/download/. Updates and feedback can be found [http://flightgear.org/forums/viewtopic.php?f=28&t=10488&p=144233&hilit=snapshot#p144233 at the forum].


== Translators required ==
== Translators required ==
Line 133: Line 157:
|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 [[:nl:Help:Vertalen|Help:Vertalen]].
|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 [[:nl:Help:Vertalen|Help:Vertalen]].
|}
|}
== Nasal for newbies ==
== New software tools and projects ==
== FlightGear addons and mods ==
== In the hangar ==
All the way back in May 2011, we addopted a new status-rating system for aircraft. So far, only a few have actually been rated, as can be seen in the list 'hockenberry' set up at [https://docs.google.com/spreadsheet/ccc?key=0ApzphjA4w05ndF94Y2F0bzJTbHQ5QTJXZXJRcUVRbWc&hl=en_US Google Docs]. If you're an aircraft developer and your aircraft is/are not on the list, please consider rating their status. All you'll need to know/do is described at [[Formalizing Aircraft Status]]. If you'd just like to get started contributing to FlightGear, this would also seem like an excellent way to get started.
=== New aircraft ===
=== Updated aircraft ===
=== Liveries ===


== Scenery corner ==
== Scenery corner ==
=== OpenStreetMap license change completed ===
=== OpenStreetMap license change completed ===
On September 12, [[OpenStreetMap]] (OSM) completed its long expected license change. From now on, OSM data is licensed under the [http://opendatacommons.org/licenses/odbl/ Open Database Licence].
On September 12, [[OpenStreetMap]] (OSM) completed its long expected license change. From now on, OSM data is licensed under the [http://opendatacommons.org/licenses/odbl/ Open Database Licence]. Since the new license is compatible with the GNU GPL license that FlightGear falls under, FlightGear scenery projects can make use of a whole new class of data.


* [[OpenStreetMap import]]
With the switch only just completed, it is still to be decided in what way OSM data can and will be used in official FlightGear scenery. Several possibilities are discussed in the following wiki articles:
* [[OpenStreetMap buildings]]
* [[OpenStreetMap import]]: using object positions for shared objects, like windturbines, oil tanks and power line pylons.
* [[OpenStreetMap buildings]]: extracting 3D models from building floorplans.
* OpenStreetMap line data: roads, rivers and railroads can be included in scenery. The scenery building tools (TerraGear) are currently improved to be able to handle the large density of roads that OSM has in some regions of the world. The required process is discussed in:
** [[TerraGear CORINE]]
** [[TerraGear texmapped line data]]
 
=== TerraGear GUI received new functions ===
The [[TerraGear GUI]], an user interface to generate FlightGear scenery, received several improvements this month. Besides a couple of (small) bug fixes, two features deserve to be highlighted here:
* The list of materials to choose from now displays the respective textures. This makes it easier to pick the right material.
* Elevation data can now be downloaded for the entire world. The GUI does this automatically, all you need to do is specify a bounding box for the to-be-created scenery.
* Besides 3 arcsec elevation data (SRTM-3), more accurate 1 arcsec data (SRTM-1) can be downloaded for the USA.
Feedback is welcome as always!


=== Tools ===
=== Tools ===
It is now possible to update the geographical data of static models using our webtools, just like you are now used to to with the shared objects. You just have to select the object corresponding to the 3D model, and then click on "update".
It is now possible to update the geographical data of static models using our webtools, just like you are now used to to with the shared objects. You just have to select the object corresponding to the 3D model, and then click on "update".


=== Airports ===
=== Iberia ===
[[File:Zones of the Iberian scenary.png|thumb|270px|Zones of the scenery]]
Taking advantage of the license change of OpenStreetMap, a project to improve the Iberian Peninsula (Europe) has started. This area includes the continental territories of Spain, Portugal and Andorra. The project uses the data from CORINE database for the land use, and OpenStreetMap for the landmass and roads. Moreover, the models of Barcelona-LEBL, Reus-LERS, Menorca-LEMH, Valencia-LEVC and Granada-LEGR are updated to the last version of FlightGear and included in the project files. The scenery files has been divided in 10 zones to allow an efficient management of the data.


== Aircraft of the month ==
{|
== Airport of the month ==
| [[File:San Sebastian.png|x250px|San Sebastian Bay (ICAO: LESO)]]
== Screenshot of the month ==
| [[File:Camp de Tarragona.png|x250px|Costa Daurada (ICAO: LERS)]]
|-
| [http://en.wikipedia.org/wiki/San_Sebasti%C3%A1n Bay of La Concha] (Airport: LESO)
| [http://en.wikipedia.org/wiki/Costa_Daurada Costa Daurada] (Airport: LERS)
|}


== Suggested flights ==
The creation of the scenary is still an on-going project. Additional information and temporary data files can be found at [http://flightgear.creatuforo.com/-temas30521.html?sid=976c97a07264ae7e75b15fbee03373a0#30521 Vive FG!]
== Aircraft reviews ==


== Wiki updates ==
== Community news ==
===New articles===
=== FSweekend 2012 ===
<DynamicArticleList>
[[Image:FSweekend_2011.jpg|thumb|270px|The FlightGear booth at FSweekend 2011.]]
  type=new
On 3 and 4 November 2012, FlightGear will be present at [[FSweekend 2012]], the world's largest flight simulator event. A team of FlightGear developers from all over Europe will introduce FlightGear to the visitors and answer questions from interested simmers. Every year people are surprised to find out that there is a free and open alternative to the known flightsims.
  count=10
</DynamicArticleList>
===New aircraft articles===
<DynamicArticleList>
  type=new
  count=10
  categoryRoot=Aircraft
</DynamicArticleList>
===Most popular newsletters===
<DynamicArticleList>
  type=hot
  count=5
  categoryRoot=FlightGear Newsletter
</DynamicArticleList>


== Community news ==
Will you visit our booth? More information can be found at the event's page: [[FSweekend 2012]].
=== FlightGear on YouTube ===


=== New tutorials and screencasts ===
[[File:FSweekend banner 2012.jpg]]
=== Forum news ===
=== Multiplayer ===
=== Virtual airlines ===
=== FlightGear events ===


== Useful links ==
== And finally ... ==
== And finally ... ==
=== Contributing ===
=== Contributing ===
Line 204: Line 208:
For ideas on starting to contribute to FlightGear, you may want to check out: [[Volunteer]].
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 [http://flightgear.org/forums/viewtopic.php?f=42&t=15267#p149971 this short essay] written by Thorsten.
To learn more about how the project works, please see {{forum link|p=149971|text=this short essay}} written by Thorsten.


=== Call for volunteers ===
=== Call for volunteers ===
Line 212: Line 216:
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.
* The [[FGFSPM]] (FlightGear Package Manager) is looking for a new maintainer.


=== Did you know ===
{{Appendix}}


[[Category:FlightGear Newsletter]]
[[Category:FlightGear Newsletter|2012 09]]

Latest revision as of 22:10, 7 June 2019

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


We would like to emphasize that the monthly newsletter can not live without the contributions of FlightGear users and developers. Everyone with a wiki account (free to register) can edit the newsletter and every contribution is welcome. So if you know about any FlightGear related news or projects such as for example updated scenery or aircraft, please do feel invited to add such news to the newsletter.

Development news

Random Buildings

Shortly after the 2.8 release, a number of users reported severe memory growth issues related to a new feature: Random Buildings.

This was a side-effect of the way in which the buildings were created during tile loading. Stuart has now completely changed the way in which random buildings are generated and displayed to reduce the memory occupancy by using a shader-based scheme similar to random trees. You should now see significantly lower memory occupancy (500 - 2GB less depending on area and density) when running with random buildings enabled.

NavCache

James has pushed a large change to next, which adds a binary cache of most of the navigation data. The cache is stored in FG_HOME/navdata.cache, and rebuilt if the timestamps on any of the data files change (apt.dat, nav.data, fix.dat and so on). When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is /much/ faster, especially for debug builds:

Cquote1.png Memory consumption is also lower, since we don't keep airports / fixes / taxiways / runways in memory until they're needed.

This is a fairly large change, so please look out for any bugs related to navaids / startup position / GPS / route-manager searches and lookups either getting different results or failing. I've tested here locally and things seem sane, and have had positive feedback from various testers on IRC and email, but I still expect to find some edge cases which need further work.

There's future work to move even more data into the cache - eg parking positions - which will further help performance for FMS / map systems since we won't need to parse lots of XML data repeatedly. I'm going to let this change settle down before adding more cached data, however.[1]
— James Turner
Cquote2.png

Initial work on dynamic subsystem creation

James has added initial code to work on dynamic subsystem creation, so that subsystems become create-able and removable from commands. Only some subsystems are supported so far, since many have non-default constructors or other complexities (see FlightGear Run Levels for further details). With this, change, it's now possible to dynamically add and remove the traffic-manager at runtime, for example:

 fgcommand( "add-subsystem", props.Node.new( { "subsystem": "traffic-manager", "name":"traffic-manager", "do-bind-init":1}) );

The idea is to improve this further so that more and more subsystems in FlightGear can be optionally toggled on/off at runtime, which should help facilitate other ongoing efforts, like the FGCanvas project for example - ultimately, this will help make FlightGear become more configurable and scalable, but also better usable for other purposes, such as distributed (multi-machine) setups-so that a single binary can be easily used for different purposes.

In addition, it will be much easier for developers to do regression testing and benchmarking once subsystems can be completely disabled, which is another long-standing feature request (see FlightGear Headless), that should also simplify release preparations.

Project Rembrandt

The night vision effect, as well as the cinema effects, are now available for 2.8 users. See here This is a link to the FlightGear forum. for the download links, details and feedback.

Canvas System

Work has now started to develop a dedicated Nasal module specifically for mapping/charting purposes. A first proof of concept is available in $FG_ROOT/Nasal/canvas/map.nas, but we expect to commit more changes (and a real API) soon. Initially, we'll be collecting all related features in a single "map.nas" module, and refactor/improve things later on.

In particular, the idea is to have a single Nasal module as the backend for all mapping/charting tasks in FlightGear, so that existing hard-coded features can be unified and re-implemented via a single consistent Nasal module that serves as a shared backend.

Ultimately, this will make it possible to re-implement existing features such as ATC-FS, the Map dialog and even Brisa's Airport Diagram Generator or the Kelpie Flight Planner directly in FlightGear, using Nasal scripting and the Canvas system, without having to write any C++ code - so that people won't need to use external tools or programming languages to create such applications.

In the long run, we want to come up with a very flexible design so that the "map.nas" module cannot only be used for creating maps used in GUI dialogs, but also for creating moving map displays like the existing hard-coded Navigation display or the TCAS and WXRADAR displays ("glass" displays), i.e. as cockpit instruments/avionics. This approach would also make it possible to directly show instruments in GUI dialogs or vice versa.

As a first proof of concept, Stuart has added a Canvas-based map to the airport selection dialog, and Hooray has demonstrated that the same technique could be used to add a map widget to the route manager dialog - so that airport selection and route planning could become more intuitive using the Canvas system. A first stab at an MVC-oriented design to create map layers has now been committed to the base package, documented at Canvas Map API - this will soon be re-worked to add support for additional dialogs and instruments.

For additional info, please see: [1] This is a link to the FlightGear forum..

In addition, ShivaVG (the vector drawing engine behind canvas) has been extended to support some kind of a non-zero fill rule. It's not really non-zero because instead of incrementing and decrementing depending on the orientation of the drawn overlapping regions it simply checks if at least a single region covers a pixel. For our use cases it should be enough tough.

Some further performance improvements were added: Now the texture is only redrawn if something has changed. So if you don't change the map there shouldn't be any noticeable performance impact anymore.

Also the bounding boxes are now only written to the property tree if they are recalculated. This should take some fair amount of changing properties away.


Seems like now tessellating takes much longer than before due to the amount of data in one single path.

The current problem with zooming is that every position of every path gets recalculated with the updated projection, even though this isn't really needed as the projection doesn't noticeably while just zooming and scrolling around at a single airport.

Flightplan access via Scripting

In advance of converting the Map and NavDisplay to use the Canvas, James has improved the "flightplan()" extension function of the Nasal scripting interpreter to expose the full route-path vector for each flight plan leg, as a vector on the leg .


var fp = flightplan();
for (var i=0; i<fp.getPlanSize(); i += 1)
{
  var leg = fp.getWP(i);
  debug.dump(leg.path());
}

With these changes in place, it is already possible to directly show a SVG image for each waypoint and connect them using OpenVG paths, even without separate "icon" support.

Usability Improvements

The Nasal console in FG 3.0 with copy/paste buttons

There have been a number of improvements made to the GUI this month, all aiming to improve usability.

Nasal Console

The built-in Nasal Console has been updated to also add native copy/paste support, a feature that got implemented as part of the ongoing Canvas effort (see Howto:Clipboard access using Nasal for details ). This feature makes it now possible to easily copy/paste snippets of code FlightGear, without having to use the "dump" feature.

About Dialog

The about dialog in FG 3.0 with extended graphics information

In addition, the "about" dialog has also been slightly updated so that it now shows a handful of OpenGL-related parameters, this info should make it easier for people to provide useful issue reports, especially related to their system's graphics support. For this very purpose, the dialog box has now also support for copying this info to the clipboard or simply take a screen shot that users can post on the forums.

Select Airport

The new Airport Selection dialog with Canvas display of the airport

The Select Airport and Position on Ground dialogs have been combined. The combined dialog displays the lon/lat/alt of the selected airport, and also uses Canvas to display an airport diagram.

Aircraft Checklists

Aircraft typically have a large number of checklists, covering almost every phase of flight. Previously, aircraft authors have added checklists to the help text for the aircraft. This is a bit unwieldy. To improve matters, there is now an Aircraft Checklists dialog under the Help menu specifically designed to organize and display checklists. Aircraft authors can create new checklists easily without having to worry about how they will be displayed. See Aircraft Checklists for details.

Integrated Documentation Browser

New integrated documentation browser

Often, especially new FlightGear users are not aware of all the documentation that comes with FlightGear. While the manual is fairly easy to find and pretty accessible (being a PDF file), most of the other documentation in $FG_ROOT/Docs is hardly easy to find and often pretty inaccessible to new users, even though these files are standard text files, because of the non-standard file extensions used by most README* files there. That's why we have now added a new built-in dialog to FlightGear which shows most plain text files in $FG_ROOT/Docs directly inside FlightGear, without having to start any other applications.

Interview with a contributor (Thorsten Renk)

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?

Since late 2009.

  • What are your major interests in FlightGear?

In the broadest sense, modelling of the environment. I've started out modelling clouds and weather, then as I discovered shaders I've also included dust, haze and light scattering effects, and of late I am into improved ways of texturing the terrain.

All these areas are related, so it's actually pretty powerful if the same person knows how to affect all of them - for instance, on a rainy day, we not only see an overcast cloud layer, but also the light beneath the clouds is dimmed, the sunrise has a different color hue, the ground is wet and hence darker than usual and there may be water on the ground. Being able to do all these things with the same environment model is pretty cool.

  • What project are you working on right now?

Procedural texturing, i.e. computing the texture mix to be displayed on the terrain inside the shader code - this allows for effects which would be impossible to achieve with the standard way of assigning textures due to the huge memory footprint.

  • What do you plan on doing in the future?

Who knows? I have plenty of things I would like to do and in principle know how to do - the problem is just making them run fast enough. It's pretty amazing how fast a graphics card can crunch numbers, but there are limits eventually. And basically every day, looking out of the window and observing the richness in detail on a real sky, I see how inadequate even our most advanced shading models really are. It's amazing how nature solves all the rendering equations in real time.

  • Are you happy with the way the FlightGear project is going?

Mostly. I know many people think FlightGear should have a project structure which works more like a commercial project, i.e. with clearly defined project goals and well-defined tasks. Rather, it is a somewhat anarchic collection of different individual projects merged together, often with multiple ways to solve the same problem (we support as many as four different ways to generate clouds for instance) which makes it not always easy for new contributers in need of a feature. But, coming from a research environment, I actually feel quite at home with such a development model - science works the same way, and for instance, while having several independent ways of doing the same thing can be seen as a waste of resources, it can also be seen as a feature - we explore many different ways of doing things which helps us find the best solution.

What I don't like is that there is often a lot of friction - for instance 3-D modellers feel underappreciated since most of the project decisions are made by the coders, there's an ongoing controversy between scripting space (Nasal) and C++ coding, and there are contributors of world scenery vs. custom scenery creators. While some level of discussion seems useful to me, related discussions often reach a point which I find no longer productive.

  • What do you enjoy most about developing for FlightGear?

The same thing Tolkien enjoyed about writing 'The Lord of the Rings' - the possibility to do subcreation. The visible FlightGear scenery is a world to explore, and this world is directly and visibly influenced by code I write. I can place myself high up in the air, look down and wave my mouse - and a whole layer of clouds appears. I get to decide what color the sunrise has. That's pretty fascinating as far as that goes.

And actually, I've always enjoyed flying through clouds in flight simulators - in the early ones, they were just so bad, but now I can make them just the way I've always wanted them to be. Flying between two scattered cloud layers is still one of my favourite activities.

  • Are there any "hidden features" you have worked on in FlightGear that new users may miss?

Plenty. Several I decided not to release since they are too tricky to control, so flags switch them off. For instance, there's a working model for wave lift in the Advanced Weather code, but there is no code to automatically place it (that's much more tricky to develop), so the wave needs to be placed by hand with a suitable line of Nasal. There are experimental cloud layer definitions which are just too expensive to render on a normal system. Many things I just try, and when I find no good way of implementing them, they stay in the code in a de-activated mode.

  • What advice can you give to new developers who want to get started on their first aircraft/new feature/Nasal script?

Be patient. The world doesn't revolve around you, but good work is recognized eventually.

Many people seem to expect that the FlightGear development community is just waiting for their contribution and jump to fill every requirement. But every developer has his own agenda, and the way things actually work is by convincing people that spending their time to support another project is a good idea. For instance, demonstrating that a project is feasible is a good idea before expecting help.

I know it looks pretty unwelcoming if someone wants to contribute and needs to go a long way before getting help. On the other hand, I know the other perspective of investing a lot of work into someone's project, just to see the other person disappear and all that work being lost. So I understand much better that established developers want to see that someone is serious about what he proposes to do before they jump in.

Translators required

En.gif The FlightGear Wiki still needs help for translating it into various languages. If you are interested in making the FlightGear Wiki multi-language then start at Help:Translate.
De.gif Das FlightGear Wiki benötigt immer noch Hilfe bei der Übersetzung in verschiedene Sprachen. Wenn Du Interesse daran hast, das FlightGear Wiki Mehrsprachig zu machen, dann fang doch mit Help:Übersetzen an.
Nl.gif De FlightGear Wiki kan nog steed hulp gebruiken bij het vertalen van artikelen. Als je interesse hebt om de wiki meertalig te maken, raden we je aan om een kijkje te nemen bij Help:Vertalen.

Scenery corner

OpenStreetMap license change completed

On September 12, OpenStreetMap (OSM) completed its long expected license change. From now on, OSM data is licensed under the Open Database Licence. Since the new license is compatible with the GNU GPL license that FlightGear falls under, FlightGear scenery projects can make use of a whole new class of data.

With the switch only just completed, it is still to be decided in what way OSM data can and will be used in official FlightGear scenery. Several possibilities are discussed in the following wiki articles:

  • OpenStreetMap import: using object positions for shared objects, like windturbines, oil tanks and power line pylons.
  • OpenStreetMap buildings: extracting 3D models from building floorplans.
  • OpenStreetMap line data: roads, rivers and railroads can be included in scenery. The scenery building tools (TerraGear) are currently improved to be able to handle the large density of roads that OSM has in some regions of the world. The required process is discussed in:

TerraGear GUI received new functions

The TerraGear GUI, an user interface to generate FlightGear scenery, received several improvements this month. Besides a couple of (small) bug fixes, two features deserve to be highlighted here:

  • The list of materials to choose from now displays the respective textures. This makes it easier to pick the right material.
  • Elevation data can now be downloaded for the entire world. The GUI does this automatically, all you need to do is specify a bounding box for the to-be-created scenery.
  • Besides 3 arcsec elevation data (SRTM-3), more accurate 1 arcsec data (SRTM-1) can be downloaded for the USA.

Feedback is welcome as always!

Tools

It is now possible to update the geographical data of static models using our webtools, just like you are now used to to with the shared objects. You just have to select the object corresponding to the 3D model, and then click on "update".

Iberia

Zones of the scenery

Taking advantage of the license change of OpenStreetMap, a project to improve the Iberian Peninsula (Europe) has started. This area includes the continental territories of Spain, Portugal and Andorra. The project uses the data from CORINE database for the land use, and OpenStreetMap for the landmass and roads. Moreover, the models of Barcelona-LEBL, Reus-LERS, Menorca-LEMH, Valencia-LEVC and Granada-LEGR are updated to the last version of FlightGear and included in the project files. The scenery files has been divided in 10 zones to allow an efficient management of the data.

San Sebastian Bay (ICAO: LESO) Costa Daurada (ICAO: LERS)
Bay of La Concha (Airport: LESO) Costa Daurada (Airport: LERS)

The creation of the scenary is still an on-going project. Additional information and temporary data files can be found at Vive FG!

Community news

FSweekend 2012

The FlightGear booth at FSweekend 2011.

On 3 and 4 November 2012, FlightGear will be present at FSweekend 2012, the world's largest flight simulator event. A team of FlightGear developers from all over Europe will introduce FlightGear to the visitors and answer questions from interested simmers. Every year people are surprised to find out that there is a free and open alternative to the known flightsims.

Will you visit our booth? More information can be found at the event's page: FSweekend 2012.

FSweekend banner 2012.jpg

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 This is a link to the FlightGear forum. written by Thorsten.

Call for volunteers

  • The Flightgear On Android team is looking for testers
  • The Target4Today team is looking for volunteers to help improving FlightGear's combat support
  • The OpenRadar project is looking for a new maintainer.
  • The FGFSPM (FlightGear Package Manager) is looking for a new maintainer.
References
  1. James Turner (Wed, 19 Sep 2012). [Flightgear-devel Nav-cache].