20,741
edits
Canvas sandbox: Difference between revisions
Jump to navigation
Jump to search
→CanvasNasal
| Line 271: | Line 271: | ||
The key thing here is that we want to ensure that the Canvas system, and OSG itself, know what an element is all about, without all this knowledge having to exist solely in scripting space. | The key thing here is that we want to ensure that the Canvas system, and OSG itself, know what an element is all about, without all this knowledge having to exist solely in scripting space. | ||
This is also the prerequisite for supporting multi-instance or multiplayer setups where Canvas-specific state may need to be propagated to multiple fgfs instances for replication. | This is also the prerequisite for supporting multi-instance or multiplayer setups where Canvas-specific state may need to be propagated to multiple fgfs instances for replication: | ||
{{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 }}}} | |||
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". | 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". | ||