20,741
edits
Canvas sandbox: Difference between revisions
Jump to navigation
Jump to search
m
→CanvasNasal
m (→CanvasNasal) |
|||
| Line 270: | Line 270: | ||
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. | ||
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 "SVG group". | |||
Dealing with Canvas features at the element level is the only sane way of doing so, but is causing quite some traffic for low-level primitives, so that it makes sense to introduce higher level elements for specific use-cases. | Dealing with Canvas features at the element level is the only sane way of doing so, but is causing quite some traffic for low-level primitives, so that it makes sense to introduce higher level elements for specific use-cases. | ||