Canvas view camera element: Difference between revisions

From FlightGear wiki
Jump to navigation Jump to search
Line 28: Line 28:


The first step would be to port the view code to SimGear so it can be used and known by the Compositor and Canvas. The view manager ({{flightgear file|src/Viewer/viewmgr.cxx}}) currently has some hardcoded assumptions, so it would either need to be rewritten to remove them or a new interface for the Views could be created specifically for the Canvas Camera View.
The first step would be to port the view code to SimGear so it can be used and known by the Compositor and Canvas. The view manager ({{flightgear file|src/Viewer/viewmgr.cxx}}) currently has some hardcoded assumptions, so it would either need to be rewritten to remove them or a new interface for the Views could be created specifically for the Canvas Camera View.
Instead of using tied properties, the adapted view manager code would either used propertyObject<> or the propertyBasedMgr abstraction, so that the corresponding canvas element can continue to use well-known conventions to manipulate views.


=== Create a Canvas Element subclass {{Pending}} ===
=== Create a Canvas Element subclass {{Pending}} ===

Revision as of 17:53, 9 April 2020

Canvas Camera Views
Description Rendering arbitrary views to a texture/Canvas
Maintainer(s) none
Contributor(s) none
Status planned/prototype

Background

Several aircraft developers have manifested their interest in being able to render to a texture (RTT) Render target This is a link to a Wikipedia article and use it inside cockpits as mirrors, external cameras (so called tail cams) and other uses.

Use Cases

  • Tail Cams
  • Mirrors
  • In-sim view configuration
  • On demand creation of views and windows (e.g. FGCamera previews)
  • Prototyping/testing HUDs or PFDs requiring synthetic terrain to work properly

Roadmap

Use CompositeViewer Pending Pending

Currently FlightGear uses only one instance of osg::Viewer, which is used by CameraGroup to manage the slave cameras. Supporting CompositeViewer would require modifying flightgear/src/Viewer/fg_os_osgviewer.cxx and creating some kind of wrapper class that manages the CompositeViewer instance and assigns a CameraGroup to each osg::View. It's also important to note that currently all FG subsystems assume there is a single instance of CameraGroup.

Standardize the View manager Pending Pending

The first step would be to port the view code to SimGear so it can be used and known by the Compositor and Canvas. The view manager (flightgear/src/Viewer/viewmgr.cxx) currently has some hardcoded assumptions, so it would either need to be rewritten to remove them or a new interface for the Views could be created specifically for the Canvas Camera View.

Instead of using tied properties, the adapted view manager code would either used propertyObject<> or the propertyBasedMgr abstraction, so that the corresponding canvas element can continue to use well-known conventions to manipulate views.

Create a Canvas Element subclass Pending Pending

This derived class would require the following configuration:

  • Compositor to use.
  • View to use. This could be one of the "main" ones (i.e. the ones on the main property tree), or a locally-defined one that is only known to this Canvas Element (think FLIR).
  • Scene graph to use. By default the main scene graph would be used, but an arbitrary XML file can be loaded to render a custom model (for which we have working code, too)
  • Several optimization/miscellaneous parameters like framerate cap, etc.

Simplifying a lot, this Canvas Element would be an aggregation of a Compositor instance, a View and a pointer to a osg::Group representing the scene graph to render. This setup could be replicated in flightgear/src/Viewer/fg_os_osgviewer.cxx, with the difference of ignoring Canvas and using native windowing features from OSG.

Related

Forum topics