FlightGear Newsletter October 2016: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Navbar)
Line 63: Line 63:
''Continue reading at [[Howto:Prototyping a new NavDisplay Style]]…''
''Continue reading at [[Howto:Prototyping a new NavDisplay Style]]…''


=== Benchmarking Canvas Path Performance ===
=== Benchmarking Canvas path performance ===
[[File:Shuttle avionics meds pfd orbit.jpg|thumb|A screenshot of the ADI ball]]
As part of the development of the [[Space Shuttle]], Thorsten has added a [[Canvas]]-based [[Shuttle ADI ball|ADI ball]]. However, it is somewhat of a resource hog.<ref>{{cite web
|url    = https://forum.flightgear.org/viewtopic.php?p=297596#p297596
|title  = Re: Nasal must go
|author = Thorsten
|date  = Oct 28th, 2016
|added  = Oct 28th, 2016
|script_version = 0.40
}}</ref> As can be seen from the screenshot of it, it is very complex and involves a lot of calculations.<ref>{{cite web
|url    = https://forum.flightgear.org/viewtopic.php?p=297665#p297665
|title  = Re: Nasal must go
|author = Thorsten
|date  = Oct 29th, 2016
|added  = Oct 29th, 2016
|script_version = 0.40
}}</ref> However, performance tests indicate that the cause of the bottleneck is the huge amount of [[Property Tree|property]] manipulation involved during each update, ''after'' the actual calculations have been completed. This has also been shown to be a problem for any very complex Canvas.


Thorsten has done a few performance tests, and the [[Shuttle ADI ball]] at full glory is a resource hog (mainly property throughput, canvas isn't good at that kind of problem...).<ref>{{cite web
Some ways to help reduce bottlenecks include using {{func link|getprop}}/{{func link|setprop}} instead of [[Nasal library/props|props.nas APIs]] and using variables instead of properties where possible.<ref>{{cite web
|url    = https://forum.flightgear.org/viewtopic.php?p=289447#p289447
|url    = https://sourceforge.net/p/flightgear/mailman/message/30724363/
|title  = Re: Space Shuttle
|title  = <nowiki>Re: [Flightgear-devel] Nasal props API relative path support</nowiki>
|author = Thorsten
|author = Thorsten Renk
|date  = Aug 26th, 2016
|date  = Apr 15th, 2013
|added  = Aug 26th, 2016
|added  = Apr 15th, 2013
|script_version = 0.40  
|script_version = 0.40
}}</ref>
}}</ref>


The bottleneck is rendering the ADI-created property IO when this is at high quality if the GPU is fast enough.<ref>{{cite web
''Continue reading at [[Howto:Canvas Path Benchmarking]]…''
  |url    =  https://forum.flightgear.org/viewtopic.php?p=293165#p293165
  |title  =  <nowiki> Re: Space Shuttle </nowiki>
  |author =  <nowiki> Thorsten </nowiki>
  |date  =  Aug 26th, 2016
  |added  =  Aug 26th, 2016
  |script_version = 0.40
  }}</ref>
 
[[File:Shuttle avionics meds pfd orbit.jpg|left|thumb|The center portion of the ADI ball consists of the line grid which is generated by projecting a pattern of meridians and coordinate circles on a sphere into 2d space and then clipping the central portion out of it.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297665#p297665
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> Thorsten </nowiki>
  |date  =  Oct 29th, 2016
  |added  =  Oct 29th, 2016
  |script_version = 0.40
  }}</ref>
]]
 
 
The actual bottleneck is the ADI ball canvas code, because all needs to be done in the same frame, and the ADI should be updating reasonably fast. Also, getting the properties to display is not the issue, setting the points for canvas is.
 
For the MFDs... let's go through the numbers. We have 40 pages by now, each displays on average something like 50 properties. That's 2000 getprop calls for the data provider to manage. At 3 Hz, and 30 fps, that's 200 requests per frame.
 
Now, if these 40, no more than 9 different ones can actually be on at any given time - so that's 450 getprop calls if you do it without data provider.<ref>{{cite web
  |url    =  https://forum.flightgear.org/viewtopic.php?p=297596#p297596
  |title  =  <nowiki> Re: Nasal must go </nowiki>
  |author =  <nowiki> Thorsten </nowiki>
  |date  =  Oct 28th, 2016
  |added  =  Oct 28th, 2016
  |script_version = 0.40
  }}</ref>
 
Assembling a property path by string manipulation may be in theory less appealing, but it is in practice 3 to 10 times faster than using the props module (implemented in scripting space)- Thorsten has made several benchmark tests, all leading to the same result. Large-scale property manipulation from Nasal is performance hungry and should be avoided if possible by using Nasal-internal variables instead, and if it needs to be done, getprop() /setprop() offer significantly superior performance. If you dig a bit in the mailing list archive, there should be a post with the actual benchmark test results.<ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/30724363/
  |title  =  <nowiki> Re: [Flightgear-devel] Nasal props API relative path support </nowiki>
  |author =  <nowiki> Renk Thorsten </nowiki>
  |date  =  Apr 15th, 2013
  |added  =  Apr 15th, 2013
  |script_version = 0.40
  }}</ref>
 
In the second case the property tree is being walked trough by the C++ code while in the first case it's done in Nasal. <ref>{{cite web
  |url    =  https://sourceforge.net/p/flightgear/mailman/message/26170047/
  |title  =  <nowiki> Re: [Flightgear-devel] Musings on optimizing Nasal code </nowiki>
  |author =  <nowiki> Erik Hofman </nowiki>
  |date  =  Sep 15th, 2010
  |added  =  Sep 15th, 2010
  |script_version = 0.40
  }}</ref>
 
[[File:Canvas-path-benchmarking.png|thumb|Screenshot showing a Canvas GUI dialog with 3000 random OpenVG paths (line segments) drawn (for benchmarking purposes) <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=30864&hilit=removeAllChildren</ref>]]
 
 
Continue reading at [[Howto:Canvas Path Benchmarking]] ...


=== Live-Streaming a Canvas via HTTP ===
=== Live-Streaming a Canvas via HTTP ===

Revision as of 13:44, 4 November 2016

This newsletter is a draft.

Please feel free to add content that you think will be of interest to the FlightGear community.
You can read the latest newsletter at FlightGear Newsletter September 2016.


Magagazine.png
Enjoy reading the latest edition!
Please help us write the coming edition!
October 2016

Development news
Next default airport
Git multimail script updated
Local apt.dat versions support
Standalone Canvas NavDisplay dialog
Benchmarking Canvas Path Performance
Live-Streaming a Canvas via HTTP
In the hangar

Scenery Corner
Scenery/LOD experiments
Community News

Contributing
Translators required
FlightGear logos
Screenshots
Screenshot of the Month

Development news

Next default airport

Zürich Airport (LSZH) has been chosen as the default airport for the next FlightGear version, v2016.4.[1] Some details about the airport can be found here.

Git multimail script updated

For all Git repositories on SourceForge, Edward d'Auvergne has updated the git-multimail repository hook script to 1.5-dev (the current master branch) from 1.2-dev, with a few customisations/simplifications for our commitlogs ML. If you see any error messages when committing, please report these. A failure of the git-multimail Python script will only result in a failure of the sending of an email to the ML, as this is a post-receive hook - the commit will have been successfully pushed/etc.[2]

Local apt.dat versions support

Thanks to work by Florent Rougon, multiple apt.dat files (which contain airport data) can now be loaded, rather than the single $FG_ROOT/Airports/apt.dat.gz.[3] These files (either *.dat or *.dat.gz) can be loaded from Scenery path/NavData/apt/, where Scenery path is any path specified by the --fg-scenery command line option. These will take precedence over the default one ($FG_ROOT/Airports/apt.dat.gz). Note that any change to apt.dat files should continue to be submitted to the X-Plane gateway so that they will eventually be included in the main distribution.

Standalone Canvas NavDisplay dialog

Screenshot showing the dialog with two independent NavDisplay instances

Hooray has been working on a dialog to easily prototype new NavDisplay styles. It is capable of showing multiple NavDisplay instances, which can be controlled and tested independently (using different settings for range, modes, traffic, etc.). The dialog will also reload the styles file (navdisplay.mfd) when it is reopened, meaning that FlightGear doesn't have to be restarted every time changes are made.

As of 10/2016, this is pending review by Gijs and Hyde before it can be committed to the base package.

Continue reading at Howto:Prototyping a new NavDisplay Style

Benchmarking Canvas path performance

A screenshot of the ADI ball

As part of the development of the Space Shuttle, Thorsten has added a Canvas-based ADI ball. However, it is somewhat of a resource hog.[4] As can be seen from the screenshot of it, it is very complex and involves a lot of calculations.[5] However, performance tests indicate that the cause of the bottleneck is the huge amount of property manipulation involved during each update, after the actual calculations have been completed. This has also been shown to be a problem for any very complex Canvas.

Some ways to help reduce bottlenecks include using getprop /setprop instead of props.nas APIs and using variables instead of properties where possible.[6]

Continue reading at Howto:Canvas Path Benchmarking

Live-Streaming a Canvas via HTTP

Screenshot showing a single Canvas texture (NavDisplay) streamed to firefox via httpd at 2hz [7]

There are situations, e.g., for home cockpit builders [8], where it is useful to display instruments like a PFD, ND, EICAS or any MFD externally from the FlightGear 3D main window in a separate window or on a separate monitor, computer or a mobile device [9] [10] [11].

Many of these avionics/graphics are created by FlightGear's 2D drawing Canvas system internally.


In addition there, are a number of other use-cases where being able to obtain a Canvas from fgfs using a network protocol like http may be desirable (e.g. imagine getting a tilemap based on actual scenery from FlightGear [12]) [13][14].


ThomasS has created a patch for FlightGear for downloading any canvas image from a running FlightGear process by HTTP by serializing it to a raster image and serving that via the built-in mongoose based httpd server created by Torsten [15] [16].

This could be considered the groundwork needed for more sophisticated use-cases such as e.g. actually streaming a live video of a certain MFD to a browser.


Continue reading at Read canvas image by HTTP

In the hangar

MBB BK117

HHS, the author of the Eurocopter EC 135 P2, EC 130 B4 and Cessna 182 S will try again to get the MBB BK 117 model ready for FGAddon. Unfortunately time is limited, so he will need help.

When you have some spare time left, interested in heliopters and always wished to improve things, you might want to apply to this job. More informations on: MBB Bk 117 wiki-page

2016 Camaro SS and more

Auskunst is currently seeking help to improve the handling of his 2016 Camaro SS and another future automobile project. If you have experience of tweaking YASIM FDM, you can apply the job by clicking here

Scenery corner

Scenery/LOD experiments

psadro_gm has the normal calculations, now. Everything is being generated on the fly. psadro_gm sees very little CPU usage. Still lot's to do - e.g. need to sample 1 extra pixel in the DEM so edges of tiles get correct normals ( you can see the edges )

Also, psadro_gm hasn't created skirts, yet, so there are gaps between levels.

psadro_gm will add to Mathias' tunables to select grid spacing at each LOD level, to see if we can minimie the popping. Note: the texture is just 1 4096x4096 sheet for the whole planet. It'll be nice to see what we can do with procedural texturing.[17]

As far as creating ws3.0, let's see how the experimental engine works out. It basically does away with terragear, and uses standard gis tools for all elevation, landclass editing.[18]

Terragear was never meant as a 'users' tool. It was designed to generate world scenery ( the whole planet at once ), not individual custom scenery locations.

That said, there have been some ( mostly unsuccessful ) attempts to make it more user friendly. We will see how far the new scenery experiments get us. If it shows enough promise, perhaps it will become the way forward, and terragear will mostly disappear. QGIS or GRASS, along with a few scripts will all that you would need to generate custom scenery, then.[19]


To learn more, see Experimental terrain engine

Community news

Contributing

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 multilingual, you can start by looking at Help:Translate.
Fr.gif Le wiki de FlightGear a toujours besoin d'aide pour être traduit en différentes langues. Si vous êtes intéressé par le rendre multilingue, commencez par lire Help:Traduire.
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 mit dem 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.
Es.gif La wiki de FlightGear todavía necesita ayuda para traducirla a varios lenguajes. Si estás interesado en hacer la FlightGear wiki multilingüe, entonces comienza en Help:Traducir.
Cat.gif La wiki de FlightGear encara necessita ajuda per traduir-la a diverses llengües. Si esteu interessat en fer la wiki de FlightGear multilingüe, llavors comenceu a Help:Traduir.
Pt.gif A wiki de FlightGear ainda necessita de ajuda para traduzi-la em vários idiomas. Se estás interessado em tornar a wiki de FlightGear multi-lingual, por favor começa em Help:Traduzir.

FlightGear logos

If you want some graphic elements for your FlightGear-related site (such as a hangar or YouTube channel), please feel free to visit FlightGear logos for a repository of logos. And if you have some art skills, please don't hesitate to contribute with your own design creations.

Screenshots

The FlightGear project always needs screenshots, which show features that were added since the last release. These should be of good quality, especially in content and technical image properties. It is therefore recommended to use the best viable filter settings (anti-aliasing, texture sharpening, etc.). More info at Howto:Make nice screenshots.

Screenshot of the Month

FlightGear's Screenshot of the month October 2016 is C182 takeoff at dawn by xcvb

C182 takeoff at dawn


If you want to participate in the screenshot contest of November 2016, you can submit your candidate to this forum topic. Be sure to see the first post for participation rules. For purposes of convenience and organization, after all the entries have been submitted, a new forum topic will be started containing all shots in an easy-to-view layout. The voting will then take place there. Once the voting has finished, the best screenshot will be presented in the Newsletter edition of November 2016.

References
  1. chris_blues (Oct 4th, 2016). Re: Please vote for the next default airport.
  2. Edward d'Auvergne (Oct 18th, 2016). Re: [Flightgear-devel] Git-multimail repository hook script merge-request bug (was Re: apt.dat - add local version ?).
  3. Alant (Oct 18th, 2016). apt.dat - local version(s).
  4. Thorsten (Oct 28th, 2016). Re: Nasal must go.
  5. Thorsten (Oct 29th, 2016). Re: Nasal must go.
  6. Thorsten Renk (Apr 15th, 2013). Re: [Flightgear-devel] Nasal props API relative path support.
  7. https://forum.flightgear.org/viewtopic.php?f=71&t=30642&p=297716#p297716
  8. ThomasS  (Oct 10th, 2016).  Canvas remote drawing .
  9. deena102  (Jul 18th, 2014).  Need to Create a Standalone PFD .
  10. pommesschranke  (Jan 31st, 2014).  Re: TQ/Panel for FG made with Kivy .
  11. someguy  (Oct 23rd, 2012).  Re: using FGpanel to display various instruments and electri .
  12. Torsten  (Mar 17th, 2014).  Re: Atlas still in use ? .
  13. roy111  (Oct 29th, 2013).  How to simulate capturing an image using a camera .
  14. Torsten  (Sep 22nd, 2014).  FGWebPanel aka FGPanel 2.0 or: FGPanel goes html .
  15. Hooray  (Jun 22nd, 2014).  Serializing a .
  16. Hooray  (Mar 18th, 2014).  Re: Atlas still in use ? .
  17. psadro_gm  (Oct 1st, 2016).  Re: Next-generation scenery generating? .
  18. Peter Sadrozinski  (Oct 24th, 2016).  Re: [Flightgear-devel] apt.dat - add local version ? .
  19. psadro_gm  (Oct 7th, 2016).  Re: terragear wont build .