Es/FlightGear Newsletter February 2014: Difference between revisions

Jump to navigation Jump to search
Switch to the {{forum link}} template for all "flightgear.org/forum" forum links.
(Switch to the {{forum link}} template for all "flightgear.org/forum" forum links.)
 
(3 intermediate revisions by 2 users not shown)
Line 29: Line 29:
Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow.  So, if your build fails, please check you've got a recent OSG build installed.
Stuart also replaced some OSG color/normal binding calls that were removed in OSG3.2.0, apparently because they were slow.  So, if your build fails, please check you've got a recent OSG build installed.


Please let us know if you see any issues with either change. And while at it, Stuart also fixed one of the longest-standing scenery glitches in FlightGear history[http://forum.flightgear.org/viewtopic.php?f=47&t=22168&p=202063#p202060].
Please let us know if you see any issues with either change. And while at it, Stuart also fixed one of the longest-standing scenery glitches in FlightGear history {{forum link|p=202060}}.
Stuart and Thorsten also fixed the black halo that could previously be seen around point lights [https://gitorious.org/fg/fgdata/commit/eaaf816b772649d5b0826a1d0bdd166dbc5b968f].
Stuart and Thorsten also fixed the black halo that could previously be seen around point lights [{{fgdata-old|commit=eaaf816b772649d5b0826a1d0bdd166dbc5b968f}}].


A suitable ALS version of the runway lights is now well under way which fogs runway lighting consistently with the rest of the scene. Having the lights inside the shader has additional benefits - it allows to make them more responsive to the environment, in particular the lights are rendered harder and with a sparkle effect, the distance out to which they are visible changes with the level of ambient lights, and in fog lights acquire a halo due to Mie forward scattering.
A suitable ALS version of the runway lights is now well under way which fogs runway lighting consistently with the rest of the scene. Having the lights inside the shader has additional benefits - it allows to make them more responsive to the environment, in particular the lights are rendered harder and with a sparkle effect, the distance out to which they are visible changes with the level of ambient lights, and in fog lights acquire a halo due to Mie forward scattering.
Line 87: Line 87:
getprop("canvas/by-index/texture[1]/name");
getprop("canvas/by-index/texture[1]/name");
</syntaxhighlight>
</syntaxhighlight>
: (see [https://gitorious.org/fg/flightgear/commit/5eee5e42ae4f5cf56283b3bf5a3be46efc2b51c4 merge request #54] and [https://gitorious.org/fg/flightgear/commit/34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353 actual commit])
: (see {{gitorious merge request|mr=54|text=merge request #54}} and {{flightgear commit|34ed79e5f88ffdfc5e651a1fe3e639cb8f4d3353|text=actual commit}})


== Canvas: two years later ==
== Canvas: two years later ==
[[File:Anniversary4.png|left|600px]]
[[File:Anniversary4.png|left|600px]]


According to [https://www.gitorious.org/fg/flightgear/merge_requests/26 Gitorious merge request #26], it's been two years now that [[Canvas]] (our property-driven 2D rendering API) made it into FlightGear, back in early 2012. Time to recap:
According to {{gitorious merge request|mr=26|text=Gitorious merge request #26}}, it's been two years now that [[Canvas]] (our property-driven 2D rendering API) made it into FlightGear, back in early 2012. Time to recap:


First of all, we'd like to use the opportunity to express our thanks to all the people involved in making it happen, first of all, obviously TheTom and Zakalawe the canvas core developers, who are going out of their way to ensure that base package developers can easily and efficiently use the Canvas, while also being extremely responsive on the forums whenever it comes to feature requests, or those -very rare- bug reports.
First of all, we'd like to use the opportunity to express our thanks to all the people involved in making it happen, first of all, obviously TheTom and Zakalawe the canvas core developers, who are going out of their way to ensure that base package developers can easily and efficiently use the Canvas, while also being extremely responsive on the forums whenever it comes to feature requests, or those -very rare- bug reports.
Line 132: Line 132:
Besides, we've also been discussing exposing camera views (e.g. scenery view manager) or even the underlying rendering stages to Canvas, which is based on ideas originally brought up by FredB and Zan on the devel list when they were talking about exposing the Rembrandt renderer to Tim Moore's effects framework[http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg36481.html], a feature which would make all kinds of fancy things possible via Canvas.  
Besides, we've also been discussing exposing camera views (e.g. scenery view manager) or even the underlying rendering stages to Canvas, which is based on ideas originally brought up by FredB and Zan on the devel list when they were talking about exposing the Rembrandt renderer to Tim Moore's effects framework[http://www.mail-archive.com/flightgear-devel%40lists.sourceforge.net/msg36481.html], a feature which would make all kinds of fancy things possible via Canvas.  


Another interesting idea that was recently raised on the forums was running Canvas on embedded hardware platforms like Raspberry PI by supporting OpenGL ES[http://forum.flightgear.org/viewtopic.php?f=71&t=21964], which could mean that all Canvas based systems (PFD, ND, HUDs, EICAS, dialogs) may eventually be supported on such devices (maybe in another 2 years from now ?).
Another interesting idea that was recently raised on the forums was running Canvas on embedded hardware platforms like Raspberry PI by supporting OpenGL ES {{forum link|t=21964}}, which could mean that all Canvas based systems (PFD, ND, HUDs, EICAS, dialogs) may eventually be supported on such devices (maybe in another 2 years from now ?).


Some of the things we'll be working on in the time to come include:
Some of the things we'll be working on in the time to come include:
Line 149: Line 149:


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


[[File:Interactive-Nasal-Console-REPL.png|600px|Philosopher's interactive Nasal console REPL]]
[[File:Interactive-Nasal-Console-REPL.png|600px|Philosopher's interactive Nasal console REPL]]
Line 269: Line 269:
=== Canvas System ===
=== Canvas System ===


The F-16CJ is being renovated to include the most realistic fighter HUDs yet. See the progress at [[F-16CJ HUD Project Newsletter]] and [[http://forum.flightgear.org/viewtopic.php?f=71&t=22014 this forum topic]].
The F-16CJ is being renovated to include the most realistic fighter HUDs yet. See the progress at [[F-16CJ HUD Project Newsletter]] and {{forum link|t=22014|text=this forum topic}}.


=== JSBSim Ground Effects ===
=== JSBSim Ground Effects ===
Line 418: Line 418:
It's almost been a year since the first release of Cross-Country Tutorial II.<br />
It's almost been a year since the first release of Cross-Country Tutorial II.<br />
Now with '''version three point zero''' the document is better than ever in many aspects.<br /> <br />
Now with '''version three point zero''' the document is better than ever in many aspects.<br /> <br />
Go to the respective [http://forum.flightgear.org/viewtopic.php?f=72&t=19600 forum topic] where you can: <br />  
Go to the respective {{forum link|t=19600|text=forum topic}} where you can: <br />  
*download this tutorial  
*download this tutorial  
*find out more about it  
*find out more about it  
Line 431: Line 431:
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, for a more detailed article see [[How the FlightGear project works]].
To learn more about how the project works, please see {{forum link|p=149971|text=this short essay}} written by Thorsten, for a more detailed article see [[How the FlightGear project works]].


{{Appendix}}
{{Appendix}}


[[Category:FlightGear Newsletter]]
[[Category:FlightGear Newsletter]]
[[Category:Changes after 3.00]]
[[Category:Changes after 3.0]]

Navigation menu