Canvas sandbox: Difference between revisions

Canvas sandbox (view source)

628 bytes added , 15 November 2015

m

20,741

edits

@@ Line 274: / Line 274: @@
 {{FGCquote|1= I think of some kind of separation that will also be good if we would do HLA between a viewer and an application computing physical models or controlling an additional view hooking into a federate ...|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/19718364/  | title  = <nowiki>Re: [Flightgear-devel] RFC: changes to views and cameras</nowiki>  | author = <nowiki>Mathias Fröhlich</nowiki>  | date   = Jul 1st, 2008  }}}}
+{{FGCquote|1= 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 - 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 sending per-frame pixel surfaces over shared memory or sockets / pipes.|2= {{cite web  | url    = http://sourceforge.net/p/flightgear/mailman/message/20014214/  | title  = <nowiki>Re: [Flightgear-devel] Cockpit displays (rendering, modelling)</nowiki>  | author = <nowiki>James Turner</nowiki>  | date   = Aug 4th, 2008  }}}}
 Which is to say, in an interlinked FlightGear setup, we want to avoid having to replicate low-level scenegraph information, but deal with a high-level representation, e.g. sending information about update a "navaid layer" rather than a "VOR symbol" or even a much lower-level "SVG/OpenVG group".