20,741
edits
No edit summary |
m (add useful background info taken/rewritten from http://wiki.flightgear.org/index.php?title=Canvas_View_Camera_Element&oldid=121493) |
||
Line 10: | Line 10: | ||
We should be able to extend CompositeViewer to render these different views of the scenery to [[Canvas_Sandbox#CanvasCamera|Canvas elements]] instead of top-level OSG windows. Then if these canvas elements are displayed in a cockpit we will get things like tail cams, gear view and rear view mirrors. Which is a long standing feature request: [[Howto:Use a Camera View in an Instrument]]. | We should be able to extend CompositeViewer to render these different views of the scenery to [[Canvas_Sandbox#CanvasCamera|Canvas elements]] instead of top-level OSG windows. Then if these canvas elements are displayed in a cockpit we will get things like tail cams, gear view and rear view mirrors. Which is a long standing feature request: [[Howto:Use a Camera View in an Instrument]]. | ||
The original set of patches (touching SimGear and fgdata) implements a new Canvas::Element by creating a sub-class named Canvas::View. The meat of it is in the constructor, i.e. Canvas::View::View(), where an off-screen camera (RTT/FBO) is set up, the FGCanvasSystemAdapter file has been extended to provide access to the FlightGear view manager to compute/obtain the view-specific view matrix, which is then used by this new canvas view element to update the offscreen camera in Canvas::View::update() accordingly. | |||
BTW: This is also a good way to stress-test the renderer, as new cameras can be easily added to the scene at runtime, so that the impact of doing so can be easily measured. | |||
the patch is experimental, it will basically look up a view and dynamically add a slave camera to the renderer that renders the whole thing to a Canvas, a Canvas is a fancy word for a RTT/FBO context in FlightGear that can be updated by using a property-based API built on top of the property tree in the form of events/signals that are represented via listeners.Which is to say each Canvas has a handful of well-defined property names (and types) that it is watching to handle "events" - think stuff like changing the sie/view port etc. And then there is a single top-level root group, which serves as the top-level element to keep other Canvas elements.A Canvas element is nothing more than a rendering primitive that the Canvas system can handle - e.g. stuff like a raster image can be added to a Canvas group, a text string/font, and 2D drawing primitives in the form of OpenVG instrutions mapped to ShivaVG. And that's basically about it (with a few exceptions that handle use-case specific stuff like 2D mapping/charts).Apart from that, the main thing to keep in mind is that a Canvas is really just a FBO - i.e. an invisible RTT context - to become actually visible, you need to add a so called "placement" - this tells the rendering engine to look up a certain canvas and add it to the scene/cockpit or the GUI (dialogs/windows). | |||
|details= [[File:Canvas-view-element-prototype-by-icecode gl.png|thumb]] | |details= [[File:Canvas-view-element-prototype-by-icecode gl.png|thumb]] | ||
* [[Canvas Sandbox]] | * [[Canvas Sandbox]] |