Jump to: navigation, search

FlightGear Newsletter October 2016

13,592 bytes removed, 15:41, 16 November 2016
Update {{func link}} form
{{draft|newsletter|Please feel free to add content that you think will be of interest to the FlightGear community.<br>You can read the latest newsletter at [[FlightGear Newsletter September 2016]].}}
{{Newsletter-header|October 2016}}
<div style="border-bottom:3px double #BBB;">
[[#Next default airport|Next default airport]]<br>
[[#Git multimail script updated|Git multimail script updated]]<br>
{{Newsletter-cover-header[[#Local apt.dat versions support|In the hangar}}Local apt.dat versions support]]<br>[[#Standalone Canvas NavDisplay dialog|Standalone Canvas NavDisplay dialog]]<br>[[#Benchmarking Canvas path performance|Benchmarking Canvas path performance]]<br>[[#Streaming a Canvas via HTTP|Streaming a Canvas via HTTP]]<br>
| valign="top" width="33%" |
{{Newsletter-cover-header|In the hangar}}<br>
[[#MBB/Kawasaki BK 117|MBB/Kawasaki BK 117]]<br>
[[#2016 Camaro SS|2016 Camaro SS]]<br>
{{Newsletter-cover-header|Scenery Corner}}<br>
[[#Scenery/LOD experimentsNew experimental terrain engine|Scenery/LOD experimentsNew experimental terrain engine]]<br>{{Newsletter-cover-header|Community News}}<br>
| valign="top" width="33%" |
|author = chris_blues
|date = Oct 4th, 2016
}}</ref> Some details about the airport can be found [ here].
=== Git multimail script updated ===
=== Local apt.dat versions support ===
{{WIP}}Thanks to work by Florent Rougon, multiple apt.dat files (which contain airport data) can now be loaded, rather than the single <tt>''[[$FG_ROOT]]/Airports/apt.dat.gz''</tt>.<ref>{{cite web|url =|title = apt.dat now supports - local versionsversion(s)|author = Alant|date = Oct 18th, 2016|added = Oct 18th, 2016|script_version = 0.40}}</ref> These files (either <tt>*.dat</tt> or <tt>*.dat.gz</tt>) can be loaded from <tt>'''''Scenery path'''/NavData/apt/''</tt>, where '''Scenery path''' is any path specified by the <code>--fg-scenery</code> command line option. These will take precedence over the default one (<tt>''[[$FG_ROOT]]/Airports/apt.dat.gz''</tt>). 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.
Local NavData directory support was added very recently, it wasn't included in 2016.3.1. But even when you do have a more recent version, you still need to use TerraGear to actually generate the visible terrain. NavData is only used for maps, startup locations etc., while the physical layout including runways and taxiways has to be generated in advance with TerraGear.<ref>{{cite web |url = |title = <nowiki> Re: </nowiki> |author Standalone Canvas NavDisplay dialog = <nowiki> Gijs </nowiki> |date = Oct 25th, 2016 |added = Oct 25th, 2016 [[File:ND-dialog-customizable-size-and-instances.png|script_version = 0.40 }}</ref>thumb|Screenshot showing the dialog with two independent NavDisplay instances]]
the NavData/apt/*.dat[.gz] files will allow you to see airports Hooray has been working on the map, but a dialog to see actual 3D terrain different from what easily develop, test and prototype new [[NavDisplay]] styles. It is already in TerraSynccapable of showing multiple NavDisplay instances, running TerraGear which can be controlled and using its outputtested independently (*using different settings for range, modes, traffic, etc.) . The dialog will also reload the styles file (navdisplay.mfd) when it is reopened (or the selected style changed), meaning that FlightGear doesn't have to be necessaryrestarted every time changes are made.
<ref>{{cite web |url = https:As of 10// |title = <nowiki> Re: </nowiki> |author = <nowiki> rominet </nowiki> |date = Oct 25th, 2016 |added = Oct 25th, 2016 |script_version = 0this is pending review by Gijs and Hyde before it can be committed to the base package.40 }}</ref>
''Continue reading at [[Howto:Prototyping a new NavDisplay Style]]…''
It is now possible to have one or more local apt=== Benchmarking Canvas path performance ===[[File:Shuttle avionics meds pfd orbit.dat files each containing data for one or more airfields. The airfields in the local apt.dat files take precedence over the contents jpg|thumb|A screenshot of the apt.dat.g file that is distributed as ADI ball]]As part of fgdata. - in much the same way as local custom scenery takes preference over terragear scenerydevelopment of the [[Space Shuttle]], Thorsten has added a [[Canvas]]-based [[Shuttle ADI ball|ADI ball]].If you are using WEDHowever, the apt.dat output by that program it is suitable.To use it add somewhat of a folder NavData/apt in your fg-scenery and place your private files in that folderresource hog. <ref>{{cite web |url = p297596 |title = <nowiki> apt.dat - local version(s) </nowiki> Re: Nasal must go |author = <nowiki> Alant </nowiki> Thorsten |date = Oct 18th28th, 2016 |added = Oct 18th28th, 2016 |script_version = 0.40 }}</ref>Of course, your apt.dat changes should continue to As can be submitted to seen from the Xplane gateway so that they will eventually be included in the main distributionscreenshot of it, it is very complex and involves a lot of calculations.<ref>{{cite web |url = p297665 |title = <nowiki> apt.dat - local version(s) </nowiki> Re: Nasal must go |author = <nowiki> Alant </nowiki> Thorsten |date = Oct 18th29th, 2016 |added = Oct 18th29th, 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.
 No need for any command-line option. As I wrote in <>;, you have Some ways to put your apt.dat files help reduce bottlenecks include using {{func link|getprop(any name ending with .dat or .dat.g is OK) in a structure like the following: <pre>Scenery path├── NavData│ ├── apt}}/{{func link| | ├── vrmg.dat| | ├── vrmh.dat| | ├── vrmk.dat ├── vrmm.dat ├── vrmo.dat.gz └── vrmt.dat</pre> where "Scenery path" can be any of you scenery paths setprop(e.g., any component )}} instead of --fg-scenery[[Nasal library/$FG_SCENERY; the path given to --terrasync-dir is also one)props|props. The files read are all NavData/apt/*.dat[.gznas APIs]] files inside each scenery path, followed by the default $FG_ROOT/Airports/apt.dat.gz (last in precedence order, thus allowing your custom sceneries to override airports already present in $FG_ROOT/Airports/apt.dat.gz). In the typical case, just put your apt.dat files(*) in the NavData/apt subdirectory of your custom scenery and they will be picked up automatically. In each using variables instead of these files, you may include as many airport definitions as you want. (*) Actually, any name ending with .dat or .dat.gz---but the syntax inside, of course, must be valid "apt.dat syntax". And if the file name ends in .gz, of course the contents must be gzipped-compressedproperties where possible. <ref>{{cite web |url = |title = <nowiki> Re: [Flightgear-devel] apt.dat - add local version ? </nowiki> |author = <nowiki> Florent Rougon </nowiki> |date = Oct 17th, 2016 |added = Oct 17th, 2016 |script_version = 0.40 }}</ref> The rule is that your file(s) must end in .dat (or .dat.g if gzip-compressed), there is no requirement to use the airport code in the file name, although of course it is clearer this way if you have one apt.dat file per airport. But it is also possible to have many airports in one big apt.dat or apt.dat.gz file like the $FG_ROOT/Airports/apt.dat.gz that comes with FG.<ref>{{cite web |url = |title = <nowiki> Re: </nowiki> |author = <nowiki> rominet </nowiki> |date = Oct 25th, 2016 |added = Oct 25th, 2016 |script_version = 0.40 }}</ref>you shouldn't add things yourself to the TerraSync folder or even, in this case, to K:\Program Files (x86)\FlightGear 2016.3.1\data created by the FG installation. You should just create a '''new''' folder for your custom scenery (k:\myflightgear\myscenery was an example, choose whatever you want) and declare it as a scenery Nasal props API relative path to FG. The Airports, Objects and Terrain subfolders are standard folders inside custom sceneries, so in the end if your custom scenery is non-empty, you'll have at least Objects or<ref>{{cite web |url = |title = <nowiki> Re: </nowiki> |author = <nowiki> rominet </nowiki> |date = Oct 25th, 2016 |added = Oct 25th, 2016 |script_version = 0.40 }}</ref>As for the startup locations, it is definitely good for the future to include them in these files, but current FG only takes them from groundnet.xml files AFAIK, not apt.dat files (however, I've seen people post links about conversion tools from apt.dat format to groundnet.xml format, so probably the best way currently is to use apt.dat/WED as your primary data source even for startup locations/parkings and generate the groundnet.xml files from that). FFGo does read startup locations from $FG_ROOT/Airports/apt.dat.g, not yet from NavData/apt/*.dat[.gz] files inside scenery paths, but this is coming...<ref>{{cite web |url = |title = <nowiki> Re: </nowiki> |author = <nowiki> rominet </nowiki> |date = Oct 25th, 2016 |added = Oct 25th, 2016 |script_version = 0.40 }}</ref> === A standalone Canvas NavDisplay Dialog === [[File:ND-dialog-customizable-size-and-instances.png|left|thumb|Screenshot showing a [[PUI]] dialog with two [[NavDisplay]] instances, featuring support for customizable resolution/size of the ND as well as selectable number of NDs to be shown.]][[File:ND-Airbus-Style-With-Route.png|thumb|Screenshot showing Gijs' [[NavDisplay]] using the Airbus style created by artix in a [[PUI]] dialog with an embedded [[Canvas]] widget to render the ND and the corresponding widgets.]] In the last couple of days, we have created a new dialog that can be used to easily prototype new [[NavDisplay]] styles, showing multiple ND instances for each pilot, which can be controlled/tested independently (using different settings for range, modes, traffic etc). Once the dialog is closed/reopened, the underlying navdisplay.mfd/styles files are also automatically reloaded from disk, so that you don't need to exit/restart fgfs to test your changes. Under the hood, this is a conventoinal PUI/XML dialog with multiple embedded CanvasWidget areas that instantiate independent ND instances using a subset of the code commonly found in the aircraft specific ND.nas file, adapted to use the embedded Canvas region for rendering multiple NDs and GUI buttons/widgets added to control the whole thing without necessarily requiring a fully developed cockpit. Thus, this is also a great tool for people flying aircraft that may not even have access to n ND. Obviously, this is particularly useful for rapid prototyping ("RAD"), i.e. quickly testing additions and changes without having to exit/restart fgfs and without having a full aircraft developed yet. [[File:Canvas-nd-menubar-entry.png|thumb|Screenshot showing [[PUI]] menubar with added '''Canvas NavDisplay''' entry for the Canvas ND dialog.]]  This is currently 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 === 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|url = |title = Re: Space Shuttle |author = ThorstenRenk|date = Aug 26thApr 15th, 2016 2013|added = Aug 26thApr 15th, 2016 2013|script_version = 0.40
The bottleneck is rendering the ADI-created property IO when this is ''Continue reading at high quality if the GPU is fast enough.<ref>{{cite web |url = https[[Howto:// |title = <nowiki> Re: Space Shuttle </nowiki> |author = <nowiki> Thorsten </nowiki> |date = Aug 26th, 2016 |added = Aug 26th, 2016 |script_version = 0.40 }}</ref>Canvas Path Benchmarking]]…''
=== Streaming a Canvas via HTTP ===[[File:Shuttle avionics meds pfd orbitCanvas-ND-live-streaming-via-httpd.jpg|leftpng|thumb|The center portion of the ADI ball consists of the line grid which is generated by projecting Screenshot showing a pattern of meridians and coordinate circles on [[NavDisplay]]) streamed to Mozilla Firefox]]ThomasS has created a sphere into 2d space and then clipping the central portion out of itpatch for FlightGear for downloading any [[Canvas]] image from a running FlightGear process via HTTP.<ref>{{cite web |url = p296627 |title = <nowiki> Re: Nasal must go </nowiki> Canvas remote drawing |author = <nowiki> Thorsten </nowiki> ThomasS |date = Oct 29th10th, 2016 |added = Oct 29th10th, 2016 |script_version = 0.40 }}</ref>]]This is useful for situations such as displaying instruments on a separate monitor. This should be considered as merely the groundwork needed for more sophisticated use-cases and a corresponding implementation.
 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 = |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 = |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 = |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></ref>]]  Continue reading at [[Howto:Canvas Path Benchmarking]] ... === Live-Streaming a Canvas via HTTP === [[File:Canvas-ND-live-streaming-via-httpd.png|left|thumb|Screenshot showing a single Canvas texture ([[NavDisplay]]) streamed to firefox via httpd at 2hz <ref></ref>]] There are situations, e.g., for home cockpit builders <ref>{{cite web |url = |title = <nowiki> Canvas remote drawing </nowiki> |author = <nowiki> ThomasS </nowiki> |date = Oct 10th, 2016 |added = Oct 10th, 2016 |script_version = 0.40 }}</ref>, 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 <ref>{{cite web |url = |title = <nowiki> Need to Create a Standalone PFD </nowiki> |author = <nowiki> deena102 </nowiki> |date = Jul 18th, 2014 |added = Jul 18th, 2014 |script_version = 0.40 }}</ref> <ref>{{cite web |url = |title = <nowiki> Re: TQ/Panel for FG made with Kivy </nowiki> |author = <nowiki> pommesschranke </nowiki> |date = Jan 31st, 2014 |added = Jan 31st, 2014 |script_version = 0.40 }}</ref> <ref>{{cite web |url = |title = <nowiki> Re: using FGpanel to display various instruments and electri </nowiki> |author = <nowiki> someguy </nowiki> |date = Oct 23rd, 2012 |added = Oct 23rd, 2012 |script_version = 0.40 }}</ref>. 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 <ref>{{cite web |url = |title = <nowiki> Re: Atlas still in use ? </nowiki> |author = <nowiki> Torsten </nowiki> |date = Mar 17th, 2014 |added = Mar 17th, 2014 |script_version = 0.40 }}</ref>) <ref>{{cite web |url = |title = <nowiki> How to simulate capturing an image using a camera </nowiki> |author = <nowiki> roy111 </nowiki> |date = Oct 29th, 2013 |added = Oct 29th, 2013 |script_version = 0.40 }}</ref><ref>{{cite web |url = |title = <nowiki> FGWebPanel aka FGPanel 2.0 or: FGPanel goes html </nowiki> |author = <nowiki> Torsten </nowiki> |date = Sep 22nd, 2014 |added = Sep 22nd, 2014 |script_version = 0.40 }}</ref>.  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 <ref>{{cite web |url = |title = <nowiki> Serializing a </nowiki> |author = <nowiki> Hooray </nowiki> |date = Jun 22nd, 2014 |added = Jun 22nd, 2014 |script_version = 0.40 }}</ref> <ref>{{cite web |url = |title = <nowiki> Re: Atlas still in use ? </nowiki> |author = <nowiki> Hooray </nowiki> |date = Mar 18th, 2014 |added = Mar 18th, 2014 |script_version = 0.40 }}</ref>. 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 /Kawasaki BK 117 ===[[User:HHS{{usr|HHS]]}}, the author of the [[Eurocopter EC135|Eurocopter EC 135 EC135 P2]], [[EC130|EC 130 Eurocopter EC130 B4]] and [[Cessna 182S|Cessna 182 S182S Skylane]] will try again is trying to get the '''[[MBB Bk 117|MBB /Kawasaki BK 117]] model ready for FGAddon''' into FlightGear. Unfortunately time is limited, so he will need help.
When you have some spare time left, are interested in heliopters helicopters, and always wished to improve things, you might want to apply to for this job. More informations Find out more on: the [[MBB Bk 117|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 in tweaking YASIM [[YASim]] [[FDM]]s, you can apply the job by clicking find out more [ here].
== Scenery corner ==
=== Scenery/LOD experiments New experimental terrain engine ===psadro_gm has been working on an experimental terrain engine. It works by using shaders and raster images to form the normal calculationsterrain. As of 10/2016, now. Everything is being generated it allows for terrain generation on -the -fly. psadro_gm sees very little CPU usage.Still lot's to do - e.g. need to sample 1 extra pixel and changes in the DEM so edges level of tiles get correct normals detail ( you can see the edges LODAlso, 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.<ref>{{cite web |url = |title = <nowiki> Re: Next-generation scenery generating? </nowiki> |author = <nowiki> psadro_gm </nowiki> |date = Oct 1st, 2016 |added = Oct 1st, 2016 |script_version = 0.40 }}</ref> As far as creating ws3.0, let's see how If the experimental engine works out. It basically does away with terragearget integrated fully, and uses standard gis tools for all elevation, landclass editing.<ref>{{cite web |url = |title = <nowiki> Re: it will render [Flightgear-devel[TerraGear] apt] obsolete.dat - add local version ? </nowiki> |author = <nowiki> Peter Sadrozinski </nowiki> |date = Oct 24thHowever, 2016 |added = Oct 24th, 2016 |script_version = 0.40 }}</ref> Terragear was never meant as there is still a 'users' toollot of development work to do. It was designed to generate world scenery ( The below videos show the whole planet at once ), not individual custom scenery locations. That said, there have been some ( mostly unsuccessful ) attempts change in LOD as one flies closer to make it more user friendly. We will see how far the new scenery experiments get usterrain. 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.<ref>{{cite web |url = |title = <nowiki> Re: terragear wont build </nowiki> |author = <nowiki> psadro_gm </nowiki> |date = Oct 7th, 2016 |added = Oct 7th, 2016 |script_version = 0.40 }}</ref>   To learn more, see [[Experimental terrain engine]]
{{#ev:youtube|-eWEB0-j7zk}} {{#ev:youtube|v9M2La8ZN1U}}''To learn more, see [[Experimental terrain engine]]…''
== Community news =={{#ev:youtube|-eWEB0-j7zk}}{{#ev:youtube|v9M2La8ZN1U}}
== Contributing ==
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.

Navigation menu