Difference between revisions of "Canvas View Camera Element"

From FlightGear wiki
Jump to: navigation, search
Line 40: Line 40:
== Related ==
== Related ==
=== Forum topics ===
* {{forum link|t=32846|text=Canvas::View Development}}
* {{forum link|t=23929|text=Gear View in Cockpit}}
* {{forum link|t=20057|text=Rear-View mirror}}
* {{forum link|t=18905|text=Progress on synthetic terrain}}
* {{forum link|t=17184|text=Instruments with heightmaps}}

Revision as of 11:31, 9 April 2020

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


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


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.

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.
  • 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.
  • 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.


Forum topics