20,741
edits
CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
no edit summary
m (https://sourceforge.net/p/flightgear/mailman/message/37086211/) |
mNo edit summary |
||
| Line 37: | Line 37: | ||
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.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059117/</ref> | 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.<ref>https://sourceforge.net/p/flightgear/mailman/message/37059117/</ref> | ||
<!-- | |||
There is some tight coupling between the Renderer.cxx and CameraGroup files (now to be found in SimGear<ref>v</ref>) The camera-infos can be configured from XML, eg to additional post-processing stages, but within each CameraInfo the actual osg::Cameras (each of which is really a rendering pass/stage) is determined by one of the buildXXXXX methods.<ref>https://sourceforge.net/p/flightgear/mailman/message/35828189/</ref> | There is some tight coupling between the Renderer.cxx and CameraGroup files (now to be found in SimGear<ref>v</ref>) The camera-infos can be configured from XML, eg to additional post-processing stages, but within each CameraInfo the actual osg::Cameras (each of which is really a rendering pass/stage) is determined by one of the buildXXXXX methods.<ref>https://sourceforge.net/p/flightgear/mailman/message/35828189/</ref> | ||
--> | |||
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. <ref>https://sourceforge.net/p/flightgear/mailman/message/24811861/</ref> | 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. <ref>https://sourceforge.net/p/flightgear/mailman/message/24811861/</ref> | ||
| Line 123: | Line 125: | ||
Regarding VSG specifically, Jules asked on the vsg-users group and it looks like VSG will certainly support what OSG CompositeView does<ref>https://sourceforge.net/p/flightgear/mailman/message/37076818/</ref>. See: https://groups.google.com/forum/#!topic/vsg-users/a68-CjA8kso | Regarding VSG specifically, Jules asked on the vsg-users group and it looks like VSG will certainly support what OSG CompositeView does<ref>https://sourceforge.net/p/flightgear/mailman/message/37076818/</ref>. See: https://groups.google.com/forum/#!topic/vsg-users/a68-CjA8kso | ||
About this specific feature, there’s one concern: from memory (which may be incorrect), the CompositeViewer changes the OSG multi-threading model significantly, because there are multiple contexts. And since most of our long-standing crashing bugs are around OSG multi-threading, usually in combination with some other feature (eg, particles, or reset), James is not in agreement about the ‘risk free’ nature, if it touches threading at all. But, hopes, if it’s off by default, we can find out. | About this specific feature, there’s one concern: from memory (which may be incorrect), the CompositeViewer changes the OSG multi-threading model significantly, because there are multiple contexts. And since most of our long-standing crashing bugs are around OSG multi-threading, usually in combination with some other feature (eg, particles, or reset), James is not in agreement about the ‘risk free’ nature, if it touches threading at all. But, hopes, if it’s off by default, we can find out. | ||
| Line 160: | Line 161: | ||
{{Note|As a general note, osgViewer::CompositeViewer should have osgViewer::View attached to it NOT osgViewer::Viewer. It's a composite of View's not composite of Viewer. If you look at all the OSG example they illustrate the correct usage.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70462.html</ref>}} | {{Note|As a general note, osgViewer::CompositeViewer should have osgViewer::View attached to it NOT osgViewer::Viewer. It's a composite of View's not composite of Viewer. If you look at all the OSG example they illustrate the correct usage.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg70462.html</ref>}} | ||
The OSG's osgViewer is designed to support multiple views on to one or more | The OSG's osgViewer is designed to support multiple views on to one or more scenes using the osgViewer::CompositeViewer class. See the osgcompositeviewer example.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg69640.html</ref> | ||
scenes using the osgViewer::CompositeViewer class. See the | |||
osgcompositeviewer example.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg69640.html</ref> | |||
The CompositeViewer was written specifically for multiple Views. | The CompositeViewer was written specifically for multiple Views. | ||
| Line 205: | Line 204: | ||
* For multiple views the way to do it with the OSG is to use the osgViewer::CompositeViewer class, and then each osgViewer::View you set up the approrpiate Camera's CullMask.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg78309.html</ref> | * For multiple views the way to do it with the OSG is to use the osgViewer::CompositeViewer class, and then each osgViewer::View you set up the approrpiate Camera's CullMask.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg78309.html</ref> | ||
* The draw traversal doesn't touch the scene graph nodes so NodeMasks/TraversalMask have no baring on it. The OSG's cull traversal builds the internal rendering graphs each frame and the draw traversal simply traversals these rendering graphs. So to control the draw traversal you use the masks in the cull traversal.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg78308.html</ref> | * The draw traversal doesn't touch the scene graph nodes so NodeMasks/TraversalMask have no baring on it. The OSG's cull traversal builds the internal rendering graphs each frame and the draw traversal simply traversals these rendering graphs. So to control the draw traversal you use the masks in the cull traversal.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg78308.html</ref> | ||
* shader handling with multiple views: The OSG provides equivalents to the OpenGL built ins for you so you don't need to provide them yourself, so just ditch the callbacks and | * shader handling with multiple views: The OSG provides equivalents to the OpenGL built ins for you so you don't need to provide them yourself, so just ditch the callbacks and just use gl_ModelViewMatrix or osg_ModelViewMatrix. The OSG has provision for doing automatic conversion from gl_ModelViewMatrix to osg_ModelViewMartrix, it's enabled by default for GL3 and GLES2 builds, but if not then you can enable if you want to use it. See the osgsimplegl3 example. These uniforms that the OSG provides for the projection and modelview matrices work seamlesly across multiple views. Just use them and it'll work out of the box. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75995.html</ref> | ||
just use gl_ModelViewMatrix or osg_ModelViewMatrix. The OSG has provision for doing automatic conversion from gl_ModelViewMatrix to osg_ModelViewMartrix, it's enabled by default for GL3 and GLES2 builds, but if not then you can enable if you want to use it. See the osgsimplegl3 example. These uniforms that the OSG provides for the projection and modelview matrices work seamlesly across multiple views. Just use them and it'll work out of the box. <ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg75995.html</ref> | |||
The two options for off screen rendering are a PixelBuffer context or | The two options for off screen rendering are a PixelBuffer context or | ||