FlightGear Newsletter July 2014: Difference between revisions

Jump to navigation Jump to search
m
No edit summary
Line 81: Line 81:
     |author=<nowiki>Hooray</nowiki>
     |author=<nowiki>Hooray</nowiki>
     |date=<nowiki>Fri Oct 03</nowiki>
     |date=<nowiki>Fri Oct 03</nowiki>
  }}
}}
== FGCanvas Updates ==
{{FGCquote
  |Since the early Canvas days, we started toying with the idea of providing an FGPanel-equivalent integrated right into FlightGear using the Canvas system:<br/>
<br/>
{{cquote|Creating a 'fgcanvas' client analogous to 'fgpanel' should be doable too, since the canvas simply renders to a single osg-Camera. Unlike fgpanel this will require OSG instead of raw GL of course, but that's the price we pay for unifying the rendering backend.<br/>
<br/>
If we're rendering each display as an OSG sub-camera, extracting that logic and  wrapping it in a stand-alone OSG viewer should be simplicity itself -  <br/>
and so long as it's driven by properties, those can be sent over a socket. That's an approach which seems a lot more bearable to me than  <br/>
sending per-frame pixel surfaces over shared memory or sockets / pipes.}}
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
    |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Jul 06</nowiki>
  }}
}}
The whole discussion dates back to the early FGPanel days:
{{FGCquote
  |I am going to be overhauls the 2D panels / displays code in the near future, and was planning to create exactly the same idea - a standalone app that can run a single panel - good to know the idea works! (I'm also planning to internally port the 2D panel code to the new system, but that should be invisible to most people).  It will be part of the main FG codebase, not a fork. As you say, the hope is to make fggc and some related things obsolete, since the same XML+Nasal can be used in the main sim or stand-alone. Anyway, all off-topic!
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=101044#p101044
    |title=<nowiki>Re: FSWeekend 2010</nowiki>
    |author=<nowiki>zakalawe</nowiki>
    |date=<nowiki>Tue Nov 02</nowiki>
  }}
}}
{{FGCquote
  |Since then, we made some first FGCanvas experiments, and things proved to be fairly tricky, because many C++ subsystems were not exactly easy to make entirely optional, and because of all the implicit assumptions in Nasal code that is unconditionally-loaded from $FG_ROOT/Nasal, and which assumes to have a full session up and running:<br/>
<br/>
{{cquote|Yeah, the stand alone mode won't be to easy. Maybe for now we should use a powerful enough computer which can also run the unneeded parts Separating the parts will be very important, not only for FGCanvas...}}
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
    |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Jul 06</nowiki>
  }}
}}
{{FGCquote
  |Fast forward a year later, many of those show stoppers have already been resolved, mainly thanks to the work done by Zakalawe and TheTom, who've both been working on reset&amp;re-init, but also overall better run-time re-initialization support, as can be seen in the screen-shot below:<br/>
<br/>
[[FGCanvas]]<br/>
[[File:Patching-fg-3.2-to-make-more-subsystems-optional.png|250px]]<br/>
Most subsystems still running in the screen shot shown here can be considered to be essential now, the only remaining subsystems that still need to be decoupled are:<br/>
<ul>
<li> flight (FDM)</li>
<li> scenery (tile manager, ephemeris)</li>
<li>view manager</li>
<li>lighting</li>
<li>terrasync</li>
</ul>
Otherwise, it's mostly Nasal code in $FG_ROOT/Nasal where dependencies need to be better established and formalized to get rid of implicit assumptions regarding availability of certain subsystems (e.g. view.nas)
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
    |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Jul 06</nowiki>
  }}
}}
{{FGCquote
  |This means that there's basically just a handful of subsystems that now need to be made optional, and that '''FGCanvas''' will actually become reality. I am going to help rework MapStructure and the ND code in order to ensure that there's no implicit assumptions on running instruments locally, so that we can eventually also drive displays remotely via properties. Roughly a year ago, I already posted some screen shots showing a FG instance that replicates a canvas property tree via telnet's "subscribe" command - it was a hack, but it worked well enough. Even though using UDP-based PUB/SUB, or maybe HLA, should probably scale better. Given the recent progress in this department, I am guessing that it may take us another ~2-3 release cycles until this materializes "automagically".<br/>
<br/>
In the mid-term, I would hope that we could agree to provide some dedicated API for implementing and initializing subsystems, to ensure that most future subsystems can be easily made optional/run-time configurable, which will entail establishing dependencies among subsystems in some "run-levels"-like setup, which will also touch Nasal bootstrapping, i.e. the stuff we're currently doing in FGNasalSys::init(), but which we're hoping to move into scripting space.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214206#p214206
    |title=<nowiki>FGCanvas Experiments & Updates</nowiki>
    |author=<nowiki>Hooray</nowiki>
    |date=<nowiki>Sun Jul 06</nowiki>
  }}
}}
{{FGCquote
  |I'll revisit bootstrapping soon, because it's the only sane way to resolve dependencies (intra-module or even subsystem support). FGCnvas definitely sounds like an excellent idea.
  |{{cite web |url=http://forum.flightgear.org/viewtopic.php?p=214207#p214207
    |title=<nowiki>Re: FGCanvas Experiments & Updates</nowiki>
    |author=<nowiki>Philosopher</nowiki>
    |date=<nowiki>Sun Jul 06</nowiki>
   }}
   }}
}}
}}

Navigation menu