Canvas view camera element: Difference between revisions

Jump to navigation Jump to search
(3 intermediate revisions by the same user not shown)
Line 13: Line 13:


{{infobox subsystem
{{infobox subsystem
|image      = cvcanvas-777.jpeg|Demonstration of multiple view windows in flightgear
|started    = 11/2020
|name        = Canvas Camera Views
|name        = Canvas Camera Views
|description = Rendering arbitrary views to a texture/Canvas
|description = Rendering arbitrary scene views to a texture/Canvas
|status      = planned/prototype
|status      = experimental prototype
|maintainers = none
|maintainers = none
|developers  = none
|developers  = Cgdae,  Icecode
}}
}}


Line 24: Line 27:
Several aircraft developers have manifested their interest in being able to render scene views to a texture (RTT) {{Wikipedia|Render target}} and use it inside cockpits as mirrors, external cameras (so called tail cams) and other uses.
Several aircraft developers have manifested their interest in being able to render scene views to a texture (RTT) {{Wikipedia|Render target}} and use it inside cockpits as mirrors, external cameras (so called tail cams) and other uses.


With the [[Compositor]] framework it's possible to configure custom render pipelines in XML space, which together with Effect schemes allow complete control over how a rendered scene looks. A synthetic terrain can be rendered by assigning an Effect scheme to a <tt>scene</tt> type pass, which textures all terrain with a brown checkerboard pattern and paints the sky in a solid blue color. All other objects are ignored and aren't rendered, saving a lot of computation time. Custom render distances independent from the main LOD settings can also be used to further optimize the performance of the display.
With the [[Compositor]] framework it's possible to configure custom render pipelines in XML space, which together with Effect schemes allow complete control over how a rendered scene looks. A synthetic terrain can be rendered by assigning an Effect scheme to a <tt>scene</tt> type pass, which textures all terrain with a brown checkerboard pattern and paints the sky in a solid blue color. All other objects are ignored and aren't rendered, saving a lot of computation time. Custom render distances independent from the main LOD settings can also be used to further optimize the performance of the display.<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=23929&p=318025&#p317946</ref>


== Use Cases ==
== Use Cases ==
Line 35: Line 38:


== Proof of Concept ==
== Proof of Concept ==
{{Main article|Hackathon Proposal: CompositeViewer and Canvas}}
<!--
{{Note|This is inspired by the long standing idea to render camera views to a texture for use as tailcams, gear views etc <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=23929</ref>, it's based on code originally provided by F-JJTH<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=23929#p317448</ref>, and subsequently reworked by Icecode GL and Hooray to integrate it with the Canvas system back in 2017<ref>https://forum.flightgear.org/viewtopic.php?f=47&t=32846&p=318046</ref>
{{Note|This is inspired by the long standing idea to render camera views to a texture for use as tailcams, gear views etc <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=23929</ref>, it's based on code originally provided by F-JJTH<ref>https://forum.flightgear.org/viewtopic.php?f=71&t=23929#p317448</ref>, and subsequently reworked by Icecode GL and Hooray to integrate it with the Canvas system back in 2017<ref>https://forum.flightgear.org/viewtopic.php?f=47&t=32846&p=318046</ref>
At the time, the main issue was that the new view element needed to be explicitly updated, but that should no longer be the case thanks to James' work on the setPixel() API <ref>https://sourceforge.net/p/flightgear/mailman/message/36926486/</ref> which also means that sc::Image now has a <code>dirtyPixels()</code> API which we can reuse <ref>https://sourceforge.net/p/flightgear/simgear/ci/ad3621e23b4056e1be7e8d9eb8dd4d513455add8/</ref>
At the time, the main issue was that the new view element needed to be explicitly updated, but that should no longer be the case thanks to James' work on the setPixel() API <ref>https://sourceforge.net/p/flightgear/mailman/message/36926486/</ref> which also means that sc::Image now has a <code>dirtyPixels()</code> API which we can reuse <ref>https://sourceforge.net/p/flightgear/simgear/ci/ad3621e23b4056e1be7e8d9eb8dd4d513455add8/</ref>
Line 429: Line 435:
  # Canvas
  # Canvas
</syntaxhighlight>
</syntaxhighlight>
-->


== Roadmap ==
== Roadmap ==
Line 446: Line 453:


=== Create a Canvas Element subclass {{Pending}} ===
=== Create a Canvas Element subclass {{Pending}} ===
{{Main article|Canvas_Development#Adding_a_new_Element}}
{{See also|Talk:Hackathon Proposal: CompositeViewer and Canvas}}


This derived class would require the following configuration:
This derived class would require the following configuration:
Line 452: Line 459:
* [[View manager|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).
* [[View manager|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 [[Howto:Extending Canvas to support rendering 3D models|render a custom model]]. A typical use-case would be instruments that need to [[Shuttle ADI ball|manipulate/render a 3D object]] (for which we have working code, too)
* Scene graph to use. By default the main scene graph would be used, but an arbitrary XML file can be loaded to [[Howto:Extending Canvas to support rendering 3D models|render a custom model]]. A typical use-case would be instruments that need to [[Shuttle ADI ball|manipulate/render a 3D object]] (for which we have working code, too)
* Several optimization/miscellaneous parameters like framerate cap, etc.
* Several optimization/miscellaneous parameters like framerate cap, node masks, LOD etc. <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=32845&p=318027&hilit=canvas+draw+masks#p318028</ref>


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

Navigation menu