Changes

Jump to navigation Jump to search
866 bytes removed ,  10:01, 6 December 2020
Some tidying and simplification
Line 5: Line 5:  
{{infobox subsystem
 
{{infobox subsystem
 
|image      = Fg-cv-textures2.jpeg|Demonstration of multiple view windows in flightgear
 
|image      = Fg-cv-textures2.jpeg|Demonstration of multiple view windows in flightgear
|name        = CompositeViewer Support
+
|name        = CompositeViewer
|started    = 07/2020  
+
|started    = 2020 July
 
|description = Support for multiple independent scene views
 
|description = Support for multiple independent scene views
|status      = merged 11/2020, awaiting feedback <ref>https://sourceforge.net/p/flightgear/mailman/message/37158652/</ref>  <ref>https://sourceforge.net/p/flightgear/mailman/message/37159361/</ref>
+
|status      = Merged into next 2020 Nov <ref>https://sourceforge.net/p/flightgear/mailman/message/37158652/</ref>
|developers  = Julian Smith<ref>https://sourceforge.net/p/flightgear/mailman/message/37062319/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37077854/</ref>
+
|developers  = [[User:Cgdae|Julian Smith]]
|changelog = https://sourceforge.net/u/cgdae/profile/feed.rss
   
}}
 
}}
   Line 17: Line 16:       −
== CompositeViewer work ==
+
== CompositeViewer ==
 +
 
 +
CompositeViewer allows multiple independent views of the Flightgear scene, e.g. in independent top-level windows.
    
=== Status updates ===
 
=== Status updates ===
2020-11-22
  −
* To encourage wider testing, '''CompositeViewer support''' is to be enabled by default on next <ref>https://sourceforge.net/p/flightgear/mailman/message/37159361/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37159461/</ref> <ref>https://sourceforge.net/p/flightgear/mailman/message/37160096/</ref>
  −
2020-11-21
  −
* merged into next: {{flightgear commit|f62e5b9ce3462758b48f4c711eb7c3bf4bcc7061|CompositeViewer:Support for multiple view windows using osgViewer::CompositeViewer}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37158652/</ref>
     −
2020-11-16
+
* 2020-11-21: Merged into next: {{flightgear commit|f62e5b9ce3462758b48f4c711eb7c3bf4bcc7061|CompositeViewer:Support for multiple view windows using osgViewer::CompositeViewer}} <ref>https://sourceforge.net/p/flightgear/mailman/message/37158652/</ref>
* Some [[Hackathon_Proposal:_CompositeViewer_and_Canvas|progress on Canvas Views]] was made at the Hackathon.
  −
* Compositor is now the default on next
     −
2020-11-11
+
* 2020-11-16: Some [[Hackathon_Proposal:_CompositeViewer_and_Canvas|progress on Canvas Views]] was made at the Hackathon.
* concrete merge discussions, scheduled for 11/2020 <ref>https://sourceforge.net/p/flightgear/mailman/message/37148460/</ref>
     −
2020-10-17:
+
* 2020-10-5: Issues with window resize/close appear to be bugs in OpenSceneGraph-3.4, and are fixed by building with OpenSceneGraph-3.6.
* Allow non-Compositor builds (without support for CompositeViewer).
     −
2020-10-5:
+
* 2020-9-27: Extra view windows now show textures and clouds etc, and rendering appears to be identical to the main view. This works by creating a new Compositor instance for each extra view window, and calling its '''update()''' method each frame.
* Issues with window resize/close appear to be bugs in OpenSceneGraph-3.4, and are fixed by building with OpenSceneGraph-3.6.
  −
 
  −
2020-9-27:
  −
* Extra view windows now show textures and clouds etc, and rendering appears to be identical to the main view.
  −
* This works by creating a new Compositor instance for each extra view window, and calling its '''update()''' method each frame.
  −
 
  −
=== Background  ===
  −
* As a general approach, if you want multiple View's which have their own or share Scene's then the appropriate class to use is CompositeViewer as it's written specifically for this purpose.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70958.html</ref>
  −
* The usual way to manage multiple window views of a single scene graph is to use a CompositeViewer with multiple View's each view using its own or sharing a graphics window. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg61172.html</ref>
  −
* The CompositeViewer and Viewer should have exactly the same performance characteristics w.r.t managing multiple cameras - as it's exactly the same ViewerBase code underneath that is managing all the threading and graphics rendering.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg22273.html</ref>
  −
* CompositeViewer and Viewer share much of their implementation, the only key difference is that Viewer "is a" View, while CompositeViewer has a list of Views.  All the event handling, camera manipulator and scene graph setting is done a the View level so has identical API to access. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg17372.html</ref>
  −
* osgViewer::CompositeViewer runs all of the views synchronously - one frame() call dispatches update, event, cull and draw traversals for all the views. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18308.html</ref>
  −
* sharing a scene between View's is OK within one CompositeViewer as they will Views on the same scene will share the same FrameStamp i.e. there will be all at the same point in time. Sharing one scene between multiple Viewers will hit up against the problem that in one set of traversals the scene graph is one time and then the traversals from the other viewer will try to change the time back - and likely to cause a mess.  This timing issue isn't likely to cause problems with high level rendering though - it should just mess up things like particle systems and sequences.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07305.html</ref>
  −
* The best thing we could do would be to create a single GraphicsWindow and then share this between all our Views, we then won't have any problems with rendering order and sharing of textures or FBOs as it'll all be on one graphics context.  See the sogcompositeviewer example for how to set up the Views/Camera & GraphicsWindow.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16029.html</ref>
  −
* Sharing a single window between multiple views is demonstated in the osgcompositeviewer example - you simply assign the same GraphicsWindow to the Camera's in each of the Views.  You change views you can stop the viewer threads and then add/remove views you need then restart the threading, this will drop a few frames though due to stopping/start of threads.  The other way is to switch off the rendering of the view by setting its Camera's NodeMask to 0x0 to disable it.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18291.html</ref>
  −
* It's possible to share contexts in the OSG [...]  As for general desirability of share GL objects between contexts, yes it can reduce memory usage, but it forces you to use the OSG single threaded otherwise two contexts will be contended for the same resources that deliberately aren't mutex locked for performance reasons.  There is also on a limited set of cases where drivers/hardware will actually share OpenGL contexts. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32676.html</ref>
  −
* Neither the OSG or OpenGL can provide thread safe sharing of GL  objects when sharing contexts.  If you want to run multiple context with multiple threads you will have to keep these contexts independent. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75584.html</ref>
  −
* an OpenGL context is tied to a single window or pixel buffer. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75586.html</ref>
  −
* Sharing contexts is also something the forces a few limits on how you use the graphics contexts, such as it's only really safe to use them single threaded. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16791.html</ref>
  −
* If you are creating new graphics contexts and applying and old scene graph to it then you can't use the Texture::setUnRefImageDataAfterApply(true) feature of osg::Texture as this will discard the imagery once it's applied to all the graphics contexts that it knows about. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32658.html</ref>
  −
* Sharing of images is possible by using a frame buffer copy to osg::Image, or just having multiple FBO's all within one graphics context.  If you can have the frames all done synchronously then perhaps you could have one frame loop and just disable the cameras via camera->setNodeMask(0x0);  that you don't need updating on each frame, i.e. main viewer runs at 60Hz, and the other RTT cameras run at 20Hrz so get update on frame in 3.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07360.html</ref>
      
=== General information ===
 
=== General information ===
 +
* Use of CompositeViewer is enabled at runtime with: '''--composite-viewer=1'''
 
* Video showing extra view windows and initial implementation of Canvas View: [http://op59.net/cvcanvas-demo.ogv cvcanvas-demo.ogv]
 
* Video showing extra view windows and initial implementation of Canvas View: [http://op59.net/cvcanvas-demo.ogv cvcanvas-demo.ogv]
* Use of CompositeViewer is enabled at runtime with: '''--composite-viewer=1'''
  −
* CompositeViewer requires a [[Compositor]] build.
   
* When enabled, CompositeViewer requires OpenSceneGraph-3.6 to work well.
 
* When enabled, CompositeViewer requires OpenSceneGraph-3.6 to work well.
* The UI for creating new view windows uses new View menu items to clone the current view or take eye/target points from two earlier views. This seems to be convenient and avoids the need for a separate dialogue box or similar.
+
* Extra view windows:
* Extra view windows can be resized.
+
** The UI for creating new view windows uses new View menu items to clone the current view or take eye/target points from two earlier views. This seems to be convenient and avoids the need for a separate dialogue box or similar.
* Extra view windows can clone Pilot View, Helicopter View, Chase View or Tower View.
+
** Can be resized.
* One can create an extra view window that keeps two aircraft in view with one in the foreground. E.g. see this video from 2020-9-6 (prior to getting textures working): http://op59.net/fg-cv-demo3.mpeg
+
** Can clone Pilot View, Helicopter View, Chase View or Tower View.
* One can create an extra view window that uses the eye points from two recent views as eye and target. For example this allows a window to show a view from one aircraft to another.
+
** One can create an extra view window that keeps two aircraft in view with one in the foreground. E.g. see this video from 2020-9-6 (prior to getting textures working): http://op59.net/fg-cv-demo3.mpeg
* There doesn't seem to be any noticeable speed penalty if no extra view windows are opened.
+
** One can create an extra view window that uses the eye points from two recent views as eye and target. For example this allows a window to show a view from one aircraft to another.
* Extra view windows use a new view system called sview (step view), which allows multiple instances and dynamic specification of eye and target points.
+
** There doesn't seem to be any noticeable speed penalty if no extra view windows are opened.
 +
** Use a new view system called Sview (step view), which allows multiple instances and dynamic specification of eye and target points.
 
* CompositeViewer support will allow us to render a view to a canvas and implement things like rear-view mirrors etc - see: [[Canvas_View_Camera_Element]].
 
* CompositeViewer support will allow us to render a view to a canvas and implement things like rear-view mirrors etc - see: [[Canvas_View_Camera_Element]].
   Line 76: Line 48:  
* Using OpenSceneGraph-3.6 causes problems elsewhere: [[OSGText Issues]] (under investigation as of 11/2020) <ref>https://sourceforge.net/p/flightgear/mailman/message/37157550/</ref>
 
* Using OpenSceneGraph-3.6 causes problems elsewhere: [[OSGText Issues]] (under investigation as of 11/2020) <ref>https://sourceforge.net/p/flightgear/mailman/message/37157550/</ref>
   −
=== Current limitations that we know how to fix ===
+
=== Current limitations ===
    
* Extra view windows don't have event handling, so for example one cannot change the angle of a cloned Helicopter view.
 
* Extra view windows don't have event handling, so for example one cannot change the angle of a cloned Helicopter view.
Line 97: Line 69:     
Latest code can be found on the 'next' branch of flightgear, simgear and fgdata.
 
Latest code can be found on the 'next' branch of flightgear, simgear and fgdata.
 +
 +
 +
== Background  ==
 +
* As a general approach, if you want multiple View's which have their own or share Scene's then the appropriate class to use is CompositeViewer as it's written specifically for this purpose.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70958.html</ref>
 +
* The usual way to manage multiple window views of a single scene graph is to use a CompositeViewer with multiple View's each view using its own or sharing a graphics window. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg61172.html</ref>
 +
* The CompositeViewer and Viewer should have exactly the same performance characteristics w.r.t managing multiple cameras - as it's exactly the same ViewerBase code underneath that is managing all the threading and graphics rendering.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg22273.html</ref>
 +
* CompositeViewer and Viewer share much of their implementation, the only key difference is that Viewer "is a" View, while CompositeViewer has a list of Views.  All the event handling, camera manipulator and scene graph setting is done a the View level so has identical API to access. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg17372.html</ref>
 +
* osgViewer::CompositeViewer runs all of the views synchronously - one frame() call dispatches update, event, cull and draw traversals for all the views. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18308.html</ref>
 +
* sharing a scene between View's is OK within one CompositeViewer as they will Views on the same scene will share the same FrameStamp i.e. there will be all at the same point in time. Sharing one scene between multiple Viewers will hit up against the problem that in one set of traversals the scene graph is one time and then the traversals from the other viewer will try to change the time back - and likely to cause a mess.  This timing issue isn't likely to cause problems with high level rendering though - it should just mess up things like particle systems and sequences.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07305.html</ref>
 +
* The best thing we could do would be to create a single GraphicsWindow and then share this between all our Views, we then won't have any problems with rendering order and sharing of textures or FBOs as it'll all be on one graphics context.  See the sogcompositeviewer example for how to set up the Views/Camera & GraphicsWindow.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16029.html</ref>
 +
* Sharing a single window between multiple views is demonstated in the osgcompositeviewer example - you simply assign the same GraphicsWindow to the Camera's in each of the Views.  You change views you can stop the viewer threads and then add/remove views you need then restart the threading, this will drop a few frames though due to stopping/start of threads.  The other way is to switch off the rendering of the view by setting its Camera's NodeMask to 0x0 to disable it.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18291.html</ref>
 +
* It's possible to share contexts in the OSG [...]  As for general desirability of share GL objects between contexts, yes it can reduce memory usage, but it forces you to use the OSG single threaded otherwise two contexts will be contended for the same resources that deliberately aren't mutex locked for performance reasons.  There is also on a limited set of cases where drivers/hardware will actually share OpenGL contexts. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32676.html</ref>
 +
* Neither the OSG or OpenGL can provide thread safe sharing of GL  objects when sharing contexts.  If you want to run multiple context with multiple threads you will have to keep these contexts independent. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75584.html</ref>
 +
* an OpenGL context is tied to a single window or pixel buffer. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75586.html</ref>
 +
* Sharing contexts is also something the forces a few limits on how you use the graphics contexts, such as it's only really safe to use them single threaded. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16791.html</ref>
 +
* If you are creating new graphics contexts and applying and old scene graph to it then you can't use the Texture::setUnRefImageDataAfterApply(true) feature of osg::Texture as this will discard the imagery once it's applied to all the graphics contexts that it knows about. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32658.html</ref>
 +
* Sharing of images is possible by using a frame buffer copy to osg::Image, or just having multiple FBO's all within one graphics context.  If you can have the frames all done synchronously then perhaps you could have one frame loop and just disable the cameras via camera->setNodeMask(0x0);  that you don't need updating on each frame, i.e. main viewer runs at 60Hz, and the other RTT cameras run at 20Hrz so get update on frame in 3.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07360.html</ref>
    
== Motivation ==
 
== Motivation ==
90

edits

Navigation menu