20,741
edits
m (→Create a Canvas Element subclass {{Pending}}: https://sourceforge.net/p/flightgear/mailman/message/37161269/) |
|||
(18 intermediate revisions by the same user not shown) | |||
Line 36: | Line 36: | ||
* Missile/payload views | * Missile/payload views | ||
* 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 | |||
== Proof of Concept == | == Proof of Concept == | ||
Line 439: | Line 440: | ||
== Roadmap == | == Roadmap == | ||
=== Use CompositeViewer {{ | === Use CompositeViewer === | ||
{{See also|CompositeViewer Support}} | {{Progressbar|80}} {{See also|CompositeViewer Support}} | ||
Currently FlightGear uses only one instance of <tt>osg::Viewer</tt>, which is used by CameraGroup to manage the slave cameras. Supporting CompositeViewer would require modifying {{flightgear file|src/Viewer/fg_os_osgviewer.cxx}} and creating some kind of wrapper class that manages the CompositeViewer instance and assigns 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]]. | Currently FlightGear uses only one instance of <tt>osg::Viewer</tt>, which is used by CameraGroup to manage the slave cameras. Supporting CompositeViewer would require modifying {{flightgear file|src/Viewer/fg_os_osgviewer.cxx}} and creating some kind of wrapper class that manages the CompositeViewer instance and assigns 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]]. | ||
=== Standardize the [[View manager]] {{ | === Standardize the [[View manager]] === | ||
{{Note|Jules has already created a custom view manager implementation (Sview) that supports multiple independent instances, so this step might be obsolete by now.}} | |||
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. | ||
Line 453: | Line 454: | ||
=== Create a Canvas Element subclass {{Pending}} === | === Create a Canvas Element subclass {{Pending}} === | ||
{{Progressbar|30}} | |||
{{See also|Talk:Hackathon Proposal: CompositeViewer and Canvas}} | {{See also|Talk:Hackathon Proposal: CompositeViewer and Canvas}} | ||
This derived class would require the following configuration: | This derived class would require the following configuration: | ||
* [[Compositor]] to use. | * [[Compositor]] to use. | ||
* 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) | |||
* [[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). | ||
Simplifying a lot, this Canvas Element would be an aggregation of a Compositor instance | Several optimization/miscellaneous parameters exposed in the form of properties per element, like: | ||
* 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> | |||
* 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] | |||
* [[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> | |||
* 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> | |||
Simplifying a lot, this Canvas Element would be an aggregation of: | |||
* a Compositor instance / effect scheme | |||
* a View | |||
* a pointer to a <tt>osg::Group</tt> representing the scene graph to render (e.g. alias or filename based). | |||
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 (see Jules' fgcommands to clone a view and open a dedicated GraphicsContext/window). | |||
== Related == | == Related == |