20,741
edits
CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
→Background
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] | ||