20,741
edits
CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
→Background
m (→Current limitations: https://sourceforge.net/p/flightgear/mailman/message/37161269/) |
m (→Background) |
||
| Line 72: | Line 72: | ||
== 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> | * 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 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> | ||
| Line 107: | Line 106: | ||
=== DatabasePager === | === DatabasePager === | ||
* osgViewer::Viewer/CompositeViewer all have the DatabasePager built into them, and will automatically run the database pager thread on demand and take care of all the operations required to manage a paged database.<ref>https://groups.google.com/d/msg/osg-users/eMh8DfsKZhQ/F1V5BZS3hLEJ</ref> | |||
* it might just be far more productive to use the OSG's built in database paging support. All you need to do is decorate your subgraphs with a osg::PagedLOD or osg::ProxyNode, with osg::PagedLOD being the method of choice as it'll do load balancing for you - both loading new tiles on demand and deleting ones that are no longer required, all automatically done by osgDB::DatabasePager/osgViewer. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg12365.html</ref> | * it might just be far more productive to use the OSG's built in database paging support. All you need to do is decorate your subgraphs with a osg::PagedLOD or osg::ProxyNode, with osg::PagedLOD being the method of choice as it'll do load balancing for you - both loading new tiles on demand and deleting ones that are no longer required, all automatically done by osgDB::DatabasePager/osgViewer. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg12365.html</ref> | ||
* The OSG has an database paging class call osgDB::DatabasePager that is built into the osgViewer::Viewer/CompositeViewer that will automatically load databases and merge them with the main scene graph during the update traversal. This is built around the osg::PagedLOD class, but you can also use the osg::ProxyNode.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg68474.html</ref> | * The OSG has an database paging class call osgDB::DatabasePager that is built into the osgViewer::Viewer/CompositeViewer that will automatically load databases and merge them with the main scene graph during the update traversal. This is built around the osg::PagedLOD class, but you can also use the osg::ProxyNode.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg68474.html</ref> | ||
| Line 113: | Line 113: | ||
=== Threading === | === Threading === | ||
* osgViewer::CompositeViewer is designed for applications that have multiple Views. The only thing to be careful of is when you are adding and removing View's from the CompositeViewer you should do is calling stopThreading() on the viewer prior to adding or removing views, then call startThreading() afterwards. If you are running SingleThreaded or CullDrawThreadPerContext you won't need to worry about stop and starting threads.<ref>https://groups.google.com/d/msg/osg-users/7OojxLpBGdw/mzorZe3rKwEJ</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> | ||
* OpenGL doesn't support multi-threading within a single graphics context, so you are constrained to doing the rendering for each context in a single thread. The threading models that the OSG provides reflect this, enabling threading of the update, event and cull traversals in parallel with the draw thread. <ref>https://groups.google.com/d/msg/osg-users/iMJF1vp0U48/9RSD3DlPAAAJ<</ref> | * OpenGL doesn't support multi-threading within a single graphics context, so you are constrained to doing the rendering for each context in a single thread. The threading models that the OSG provides reflect this, enabling threading of the update, event and cull traversals in parallel with the draw thread. <ref>https://groups.google.com/d/msg/osg-users/iMJF1vp0U48/9RSD3DlPAAAJ<</ref> | ||
* if any code executed by the cull or draw threads (such as your own callbacks or custom nodes) isn't thread safe, then you must use SingleThreaded. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg09620.html</ref> | * if any code executed by the cull or draw threads (such as your own callbacks or custom nodes) isn't thread safe, then you must use SingleThreaded. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg09620.html</ref> | ||