Hackathon Proposal: CompositeViewer and Canvas: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
(Some refactoring)
No edit summary
Line 5: Line 5:
|supporters=
|supporters=
|status=
|status=
|summary=[[CompositeViewer_Support]] already allows us to create multiple top-level windows showing different views of the same scenery.
|summary=[[CompositeViewer_Support]] already allows us to create multiple top-level windows showing different views of the same scenery.


Line 18: Line 19:


|background=
|background=
[[CompositeViewer_Support]].


Information about Canvas from Hooray
Information about Canvas from Hooray
Line 27: Line 27:


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).
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]]
Line 35: Line 36:


|skills=C++
|skills=C++
|opportunities= <p/>
|opportunities= <p/>
* OpenSceneGraph
* OpenSceneGraph
Line 40: Line 42:
* CompositeViewer
* CompositeViewer
* 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 =
 
More info from Hooray:
 
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:
The basic boilerplate needed to add/register a new Canvas element can be seen below:

Revision as of 12:59, 13 November 2020


Title: CompositeViewer and Canvas

Fg-cv-textures2.jpeg
Potential mentors: Cgdae
Intro: (short intro)
Interested Parties:
Status:
Summary: CompositeViewer_Support already allows us to create multiple top-level windows showing different views of the same scenery.

We want to extend CompositeViewer to render different views of the scenery to Canvas elements.

Then by displaying these canvas elements in a cockpit we will be able to implement things like:

  • Modern avionics:
    • Exterior views (tail cam, gear cam etc).
    • Synthetic terrain.
  • Rear-view mirrors.
  • Shuttle RMS arm/END EFF mode [1] [2] etc) [3] [4]
Background: Information about Canvas from Hooray

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++
Learning Opportunities:

  • OpenSceneGraph
  • Canvas
  • CompositeViewer
  • Compositor
Notes: More info from Hooray:

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