20,741
edits
Canvas sandbox: Difference between revisions
Jump to navigation
Jump to search
→CanvasNasal
m (→CanvasNasal) |
|||
| 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= 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= I'm guessing it would be somewhat similar to ARINC661, and the actual arrangement of these widgets could be marked up in an XML file. The framework could render to a texture (for display in a 3D virtual cockpit), a memory buffer (for direct blitting onto the screen) or to a separate device context altogether (for an external display). Network support on this would be a really interesting feature -- allowing outboard 'dumb' cockpit displays to be run off a diskless thin client.|2= {{cite web | url = http://sourceforge.net/p/flightgear/mailman/message/20009948/ | title = <nowiki>Re: [Flightgear-devel] Cockpit displays (rendering, modelling)</nowiki> | author = <nowiki>R. van Steenbergen</nowiki> | date = Aug 3rd, 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 }}}} | {{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 }}}} | ||