Difference between revisions of "CompositeViewer Support"

From FlightGear wiki
Jump to: navigation, search
m (General information)
m (Background)
(3 intermediate revisions by the same user not shown)
Line 43: Line 43:
  
 
=== Background  ===
 
=== 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>
 
* 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>
 
* 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>
 
* 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 ===
 
* 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]

Revision as of 09:42, 3 December 2020


CompositeViewer Support
Fg-cv-textures2.jpeg
Started in 07/2020
Description Support for multiple independent scene views
Contributor(s) Julian Smith[1] [2]
Status merged 11/2020, awaiting feedback [3] [4]
Changelog https://sourceforge.net/u/cgdae/profile/feed.rss



CompositeViewer work

Status updates

2020-11-22

  • To encourage wider testing, CompositeViewer support is to be enabled by default on next [5] [6] [7]

2020-11-21

2020-11-16

2020-11-11

  • concrete merge discussions, scheduled for 11/2020 [9]

2020-10-17:

  • Allow non-Compositor builds (without support for CompositeViewer).

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.

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.[10]
  • 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. [11]
  • 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.[12]
  • 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. [13]
  • osgViewer::CompositeViewer runs all of the views synchronously - one frame() call dispatches update, event, cull and draw traversals for all the views. [14]
  • 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.[15]
  • 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.[16]
  • 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.[17]
  • 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. [18]
  • 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. [19]
  • an OpenGL context is tied to a single window or pixel buffer. [20]
  • 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. [21]
  • 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. [22]
  • 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.[23]

General information

  • Video showing extra view windows and initial implementation of Canvas View: 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.
  • 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 be resized.
  • Extra view windows can clone Pilot View, Helicopter View, Chase View or Tower View.
  • 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
  • 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.
  • There doesn't seem to be any noticeable speed penalty if no extra view windows are opened.
  • Extra view windows 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.

Problems

  • for the time being, use of reset/re-init and aggressive OSG threading options seems to cause stability problems even without having cloned any views [24]
  • Using OpenSceneGraph-3.6 causes problems elsewhere: OSGText Issues (under investigation as of 11/2020) [25]

Current limitations that we know how to fix

  • Extra view windows don't have event handling, so for example one cannot change the angle of a cloned Helicopter view.
  • Sview does not support some views, e.g. Tower View AGL, Fly-past view.
  • Sview does not support aircraft-specific views.

Issues when using OpenSceneGraph-3.4

OpenSceneGraph-3.4 seems to get event handling wrong which causes problems if we open extra view windows - resize/close events get sent to our main window event handler which confuses things. There is currently no workaround for this.

These problems appear to be fixed in OpenSceneGraph-3.6.

Symptoms with OpenSceneGraph-3.4 include:

  • Creating extra view windows can cause the main window to seemingly think it has same size as the new window, so menubar and dialogues are shown partially or not at all. A manual resize of the main window seems to sort things out.
  • Attempting to closing an extra view windows sometimes closes a different extra view window.
  • Attempting to closing an extra view windows sometimes closes Flightgear down because the code thinks the main window has been closed.

Code

Latest code can be found on the 'next' branch of flightgear, simgear and fgdata.

Motivation

Experimental CompositeViewer Support showing 3 cloned views, with Draw masks set (only skydome shown) + OSG stats (~ 120 fps/window) while using CullThreadPerCameraDrawThreadPerContext [26]

Until mid-2020, FlightGear only supported one view position at a time. Multiple independent view positions (e.g. one screen for the tower view and a second screen for the plane) would complicate a "locked to cache" flag quite a lot...[27].

Aircraft can define their own views and so on. But only one view can be active at a time. So no matter how many windows and cameras you define in Defaults.xml, they all are relative to the current view in FG (i.e. cockpit, tower...). [28]

Back in 2008, Tim Moore provided a patch (mailing lists search for CameraGroup FlightGear Mailing Lists) to use the osgViewer class to set up windows, manage the main camera, etc. [29]

However, these windows have to use the same camera group as the main window so can only show the view from the same eye position, though typically at a different angle/offset so that one can emulate things like side windows of a cockpit displayed in a different window or monitor.[30]


Mathias Fröhlich used the slave camera feature of osgViewer to provide a "video wall" style of multiple displays that was demonstrated at LinuxTag for years. Later on, Tim generalized this to support general monitor arrangements (like a panoramic arc) and general combinations of screens and graphics cards. [31]

The default OSG model is that slave cameras are different views offset from a common viewpoint. This is easy to understand when considering a camera's view matrix, but not necessarily intuitive when thinking about the projection matrix. Because FG has its own view system we mostly treat the slaves as independent. It seems that most other uses of cameras during rendering -- for example, render to texture cameras for effects -- are best handled by slave cameras with independent views as well.[32]

People requiring multiple independent views on the same scenery, e.g. cockpit and tower view [...] these each need their own camera groups and so require OSG's CompositeViewer.[33]

And that's not really supported by the current architecture, neither by the tile cache nor by osgViewer::Viewer. We would need to move to a CompositeViewer model, which supports several scene graphs, and rely completely on the osg database paging machinery.[34]

That would require a change in current fg architecture to use a CompositeViewer instead of a single Viewer, but we're contemplating that anyway.[35]

The cameras in a camera group don't need to render directly to the screen. They can render to a texture which can be used either in the scene, like in a video screen in the instrument panel, or for distortion correction in a projected or dome environment. [36]

Open Scene Graph supports a CompositeViewer object that supports rendering from several widely separated viewpoints, complete with support for multiple terrain pager threads. We could move to CompositeViewer and support simultaneous views from e.g., the tower, AI models, drones, etc.[37]

Neither of these are supported at the present time, but it would be a good project. We would have to start using a different OSG class, CompositeViewer, to support multiple views from independent view points. Our terrain pager would need a complete overhaul to use the PagedLOD scheme of OSG, and the Flightgear View manager would need to be aware multiple active views.[38]

Related

Docs

Discussions

Search

References

References
  1. https://sourceforge.net/p/flightgear/mailman/message/37062319/
  2. https://sourceforge.net/p/flightgear/mailman/message/37077854/
  3. https://sourceforge.net/p/flightgear/mailman/message/37158652/
  4. https://sourceforge.net/p/flightgear/mailman/message/37159361/
  5. https://sourceforge.net/p/flightgear/mailman/message/37159361/
  6. https://sourceforge.net/p/flightgear/mailman/message/37159461/
  7. https://sourceforge.net/p/flightgear/mailman/message/37160096/
  8. https://sourceforge.net/p/flightgear/mailman/message/37158652/
  9. https://sourceforge.net/p/flightgear/mailman/message/37148460/
  10. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70958.html
  11. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg61172.html
  12. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg22273.html
  13. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg17372.html
  14. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18308.html
  15. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07305.html
  16. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16029.html
  17. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg18291.html
  18. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32676.html
  19. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75584.html
  20. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75586.html
  21. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg16791.html
  22. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg32658.html
  23. https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07360.html
  24. https://forum.flightgear.org/viewtopic.php?f=6&t=38334
  25. https://sourceforge.net/p/flightgear/mailman/message/37157550/
  26. https://forum.flightgear.org/viewtopic.php?f=6&t=38334
  27. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28864.html
  28. http://forum.flightgear.org/viewtopic.php?p=146136#p146136
  29. https://sourceforge.net/p/flightgear/mailman/message/19718339/
  30. https://sourceforge.net/p/flightgear/mailman/message/37059117/
  31. https://sourceforge.net/p/flightgear/mailman/message/24811861/
  32. https://sourceforge.net/p/flightgear/mailman/message/36295606/
  33. https://sourceforge.net/p/flightgear/mailman/message/37059117/
  34. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg28869.html
  35. http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg17263.html
  36. http://sourceforge.net/p/flightgear/mailman/message/19718339/
  37. http://sourceforge.net/p/flightgear/mailman/message/19718339/
  38. =http://www.mail-archive.com/flightgear-devel@lists.sourceforge.net/msg27134.html