Hackathon Proposal: CompositeViewer and Canvas: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
m (add useful background info taken/rewritten from http://wiki.flightgear.org/index.php?title=Canvas_View_Camera_Element&oldid=121493)
m (boilerplate pointers taken from Canvas_Sandbox#CanvasModel)
Line 27: Line 27:
* Compositor
* Compositor
|notes = It would make sense to reach out to Jules (CompositeViewer) and Fernando (Compositor) to learn how to best approach this today.
|notes = It would make sense to reach out to Jules (CompositeViewer) and Fernando (Compositor) to learn how to best approach this today.
The basic boilerplate needed to add/register a new Canvas element can be seen below:
{{Custom_Canvas_Element
|baseclass=Image
|elementName=Model
|elementTitle=Canvas Model
|description=Stub for exposing OSG/SG model loading support as a dedicated Canvas element
|file=Models/Aircraft/HR200-ba.ac
}}
}}
}}
[[Category:Canvas Element Proposals]]
[[Category:Canvas Element Proposals]]

Revision as of 10:55, 10 November 2020


Title: CompositeViewer and Canvas

Fg-cv-textures2.jpeg
Potential mentors: Cgdae
Intro: (short intro)
Interested Parties:
Status: several years ago, people on the forum came up with a working proof-of-concept patches implementing experimental support, predating Compositor/CompositeViewer support: Canvas_View_Camera_Element#Proof_of_Concept
Summary: make it possible to render arbitrary scene views to a canvas, so that the canvas can be reused to implement modern avionics (exterior views, synthetic terrain etc)
Background: CompositeViewer allows us to create multiple windows showing different views of the same scenery.

We should be able to extend CompositeViewer to render these different views of the scenery to 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:
Canvas-view-element-prototype-by-icecode gl.png
Ideas:
Required skills: C++, OpenSceneGraph 3.6
Learning Opportunities:

  • Canvas
  • CompositeViewer
  • Compositor
Notes: It would make sense to reach out to Jules (CompositeViewer) and Fernando (Compositor) to learn how to best approach this today.

The basic boilerplate needed to add/register a new Canvas element can be seen below:


You will want to add a new Canvas::Element subclass whenever you want to add support for features which cannot be currently expressed easily (or efficiently) using existing means/canvas drawing primitives (i.e. via existing elements and scripting space frameworks).

For example, this may involve projects requiring camera support, i.e. rendering scenery views to a texture, rendering 3D models to a texture or doing a complete moving map with terrain elevations/height maps (even though the latter could be implemented by sub-classing Canvas::Image to some degree).

Another good example for implementing new elements is rendering file formats like PDF, 3d models or ESRI shape files.

To create a new element, you need to create a new child class which inherits from Canvas::Element base class (or any of its child-classes, e.g. Canvas::Image) and implement the interface of the parent class by providing/overriding the correspond virtual methods.

To add a new element, these are the main steps:

  • Set up a working build environment (including simgear): Building FlightGear
  • update/pull simgear,flightgear and fgdata
  • check out a new set of topic branches for each repo: git checkout -b topic/canvas-Model
  • Navigate to $SG_SRC/canvas/elements
  • Create a new set of files Model.cxx/.hxx (as per Adding a new Canvas element)
  • add them to $SG_SRC/canvas/elements/CMakeLists.txt (as per Developing using CMake)
  • edit $SG_SRC/canvas/elements/CanvasGroup.cxx to register your new element (header and staticInit)
  • begin replacing the stubs with your own C++ code
  • map the corresponding OSG/library APIs to properties/events understood by the Canvas element (see the valueChanged() and update() methods)
  • alternatively, consider using dedicated Nasal/CppBind bindings

Below, you can find patches illustrating how to approach each of these steps using boilerplate code, which you will need to customize/replace accordingly:







References