Canvas view camera element: Difference between revisions

Jump to navigation Jump to search
m
→‎Create a Canvas Element subclass: https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26193.html
m (→‎Create a Canvas Element subclass: +stackoverflow posting about lazy OSG rendering: https://stackoverflow.com/a/12259344)
m (→‎Create a Canvas Element subclass: https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26193.html)
(10 intermediate revisions by the same user not shown)
Line 30: Line 30:


== Use Cases ==
== Use Cases ==
[[File:AFS-Panel-11-2020.png|thumb|MD11 Autopilot dialog implemented in Canvas to replace the existing PUI dialog.<ref>https://forum.flightgear.org/viewtopic.php?f=4&t=32822&p=377189#p377189</ref>]]
* Tail Cams (gear view)
* Tail Cams (gear view)
* Mirrors
* Mirrors
Line 37: Line 38:
* Prototyping/testing HUDs or PFDs requiring synthetic terrain to work properly
* Prototyping/testing HUDs or PFDs requiring synthetic terrain to work properly
* rendering an orthographic view to implement [[Canvas_Tile_Element|moving maps]] that render actual FlightGear terrain/DEM
* rendering an orthographic view to implement [[Canvas_Tile_Element|moving maps]] that render actual FlightGear terrain/DEM
* automated creation/rendering of cockpit GUI dialogs by rendering a perspective-corrected front-view of cockpit elements (MCP, AP, CDU etc) <ref>https://forum.flightgear.org/viewtopic.php?f=4&t=32822&p=377189&#p377189</ref>


== Proof of Concept ==
== Proof of Concept ==
{{Main article|Hackathon Proposal: CompositeViewer and Canvas}}
{{Main article|Hackathon Proposal: CompositeViewer and Canvas}}
All the work we did is on branch topics/cvcanvas of the main flightgear, simgear and fgdata repositories:
* {{repo link
| site  = sf
| repo  = flightgear
| branch = topics/cvcanvas/~
}}
* {{repo link
| site  = sf
| repo  = simgear
| branch = topics/cvcanvas/~
}}
* {{repo link
| site  = sf
| repo  = fgdata
| branch = topics/cvcanvas/~
}}


<!--
<!--
Line 445: Line 466:
Originally, FlightGear only used one instance of <tt>osg::Viewer</tt>, which is used by CameraGroup to manage the slave cameras. Supporting CompositeViewer did require modifying {{flightgear file|src/Viewer/fg_os_osgviewer.cxx}} to create some kind of wrapper class that manages the CompositeViewer instance and assign a CameraGroup to each <tt>osg::View</tt>. It's also important to note that currently all FG subsystems assume there is a single instance of [[Howto:CameraGroup talks|CameraGroup]].</small>
Originally, FlightGear only used one instance of <tt>osg::Viewer</tt>, which is used by CameraGroup to manage the slave cameras. Supporting CompositeViewer did require modifying {{flightgear file|src/Viewer/fg_os_osgviewer.cxx}} to create some kind of wrapper class that manages the CompositeViewer instance and assign a CameraGroup to each <tt>osg::View</tt>. It's also important to note that currently all FG subsystems assume there is a single instance of [[Howto:CameraGroup talks|CameraGroup]].</small>


=== Standardize the [[View manager]] ===
=== Standardize the View manager  ===
{{Note|As of 11/2020, Jules has already created a custom view manager implementation (Sview) that supports multiple independent instances, so this step might be obsolete by now.}}
{{Note|As of 11/2020, Jules has already created a custom view manager implementation [[StepView]] that supports multiple independent instances, so this step might be obsolete by now.}}


<small>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.
<small>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.
Line 456: Line 477:


=== Create a Canvas Element subclass ===
=== Create a Canvas Element subclass ===
[[File:CanvasView-Prototyping-UI.png|thumb|[[Canvas]] GUI dialog (code at [http://wiki.flightgear.org/File_talk:CanvasView-Prototyping-UI.png]) to provide a UI <ref>https://sourceforge.net/p/flightgear/mailman/message/37163870/</ref> for the experimental [[Canvas View Camera Element]] prototyped during the [[Virtual FSweekend Hackathon 2020]], for more details see: [[Hackathon Proposal: CompositeViewer and Canvas]]]]
[[File:CompositeViewer-prototype-UI.png|thumb|[[Canvas]] based GUI dialog to create [[CompositeViewer Support|CompositeViewer views]] dynamically using a configurable [[Compositor]] pipeline.]]
{{Progressbar|30}}
{{Progressbar|30}}
{{See also|Talk:Hackathon Proposal: CompositeViewer and Canvas}}
{{See also|Talk:Hackathon Proposal: CompositeViewer and Canvas}}
Line 467: Line 492:
* texture size/resolution (see Fernando's comments here: [[Talk:Hackathon_Proposal:_CompositeViewer_and_Canvas#SceneGraph_Cameras_vs._Prerender_Cams]] )
* texture size/resolution (see Fernando's comments here: [[Talk:Hackathon_Proposal:_CompositeViewer_and_Canvas#SceneGraph_Cameras_vs._Prerender_Cams]] )
* OSG rendering mode (continuous vs. lazy/on demand): <code>setRunFrameScheme( osgViewer::ViewerBase::ON_DEMAND );</code> <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=17650&hilit=knuq+taxiways&start=15#p166990</ref> <ref>https://stackoverflow.com/a/12259344</ref>
* OSG rendering mode (continuous vs. lazy/on demand): <code>setRunFrameScheme( osgViewer::ViewerBase::ON_DEMAND );</code> <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=17650&hilit=knuq+taxiways&start=15#p166990</ref> <ref>https://stackoverflow.com/a/12259344</ref>
* framerate cap via something like <code>view.setRunMaxFrameRate()</code> [https://www.programmersought.com/article/23264806182/] [https://www.mail-archive.com/osg-users@openscenegraph.net/msg14033.html]
* framerate cap via something like <code>view.setRunMaxFrameRate()</code> <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26193.html</ref> [https://www.programmersought.com/article/23264806182/] [https://www.mail-archive.com/osg-users@openscenegraph.net/msg14033.html] (background: https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26178.html )
* [[Draw masks|node masks]]
* [[Draw masks|node masks]]
* [[Level Of Detail (LOD) Ranges|LOD]] ranges etc. <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=32845&p=318027&hilit=canvas+draw+masks#p318028</ref>
* [[Level Of Detail (LOD) Ranges|LOD]] ranges etc. <ref>https://forum.flightgear.org/viewtopic.php?f=71&t=32845&p=318027&hilit=canvas+draw+masks#p318028</ref>
Line 473: Line 498:
* whether or not to enable OSG StatsHandler per view, i.e. for troubleshooting per view
* whether or not to enable OSG StatsHandler per view, i.e. for troubleshooting per view
* whether or not to enable event handling: "Extra view windows don't yet handle events so one cannot change the view angle/zoom after creation." <ref>https://sourceforge.net/p/flightgear/mailman/message/37161269/</ref>
* whether or not to enable event handling: "Extra view windows don't yet handle events so one cannot change the view angle/zoom after creation." <ref>https://sourceforge.net/p/flightgear/mailman/message/37161269/</ref>
Note, we can use the view's Camera's LODScale to adjust the which level of LOD child is selected for each view.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg66861.html</ref>
Another common suggestion is to control the update rate of slave cameras by inserting them into the scene graph as needed, and then use a PostDrawCallback for the camera that removes the
camera again when it is no longer needed.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg66868.html</ref>
Robert (OSG) states that most apps should manage the frame for their own applications and data.  The OSG is a general purpose scene graph rather than a domain specific IG.  It gives you the tools to do your
job, but it doesn't do it all for you.  The run() method stuff available in OSG/Viewer is really only for entry level app development.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26257.html</ref>
More sophisticated types of frame rate management are well beyond what  the viewer convenience methods like run are supposed to handle.  People  should expect to roll your own frame management for this type of app.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26184.html</ref>


Simplifying a lot, this Canvas Element would be an aggregation of:
Simplifying a lot, this Canvas Element would be an aggregation of:

Navigation menu