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 {{Pending}} === | + | === Use CompositeViewer === |
− | {{See also|CompositeViewer Support}} | + | {{Progressbar|80}} {{See also|CompositeViewer Support}} |
| + | <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> |
| | | |
− | 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 === |
| + | {{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.}} |
| | | |
− | === Standardize the [[View manager]] {{Pending}} ===
| + | <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. |
− | | |
− | 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. | |
| | | |
| In FlightGear, the Canvas system (which resides in SimGear) is integrated using the equivalent of a FGCanvasSystemAdapter, which provides all FG APIs to SimGear and makes the Canvas system available inside FG: {{flightgear file|src/Canvas/FGCanvasSystemAdapter.cxx}} | | In FlightGear, the Canvas system (which resides in SimGear) is integrated using the equivalent of a FGCanvasSystemAdapter, which provides all FG APIs to SimGear and makes the Canvas system available inside FG: {{flightgear file|src/Canvas/FGCanvasSystemAdapter.cxx}} |
| | | |
| Instead of using tied properties, the adapted view 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: ({{flightgear file|src/Viewer/view.cxx}}) | | Instead of using tied properties, the adapted view 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: ({{flightgear file|src/Viewer/view.cxx}}) |
| + | </small> |
| | | |
− | === Create a Canvas Element subclass {{Pending}} === | + | === Create a Canvas Element subclass === |
| + | {{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). |
− | * 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, 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. | + | 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> <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] (background: https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg26178.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> |
| + | * PagedLOD settings for <code>PIXEL_SIZE_ON_SCREEN</code> mode [https://sourceforge.net/p/flightgear/mailman/message/36438416/] [http://alphapixel.com/wp-content/uploads/2015/04/LOD-Level-of-detail-in-OpenSceneGraph-OSG.pdf] [https://osg-users.openscenegraph.narkive.com/DNuWtUiR/pagedlods-and-pixel-to-screen-size] |
| + | * 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 == |