Re: [osg-users] Using shared OpenGL contexts
Thank you Robert and Paul for this information. To further clarify, my goal is to be able to use multiple GL contexts representing the same scene from different camera angles, and those contexts could well be GL views in windows, FBOs, or even Core Animation GL layers (Mac). As said previously, having textures on 3D objects being the result of some GPU image processing (Core Image), or the other way around, using the result of 3D rendering as input to GPU filters (Core Image) are possible applications. But all these things require some kind of flexibility in the way you create/declare (possibly shared) contexts, to avoid duplicating VBO, DL and other GPU resources all over. A nice extension to OSG would be to make it possible to work with external contexts, even if some constraints need to be enforced (such as state preserving across OSG calls, or other threading constraints). But this is probably easier to say than to implement. I will dig some more in the source to find out. Thanks, Raphael On Fri, Aug 14, 2009 at 6:33 PM, Paul Martz pma...@skew-matrix.com wrote: Robert -- Thanks for replying to this; I saw the post and was curious myself as to how this could be done. Let's assume the app has created their own contexts and done so with object sharing set up correctly. Taking just DLs as an example, could the app enforce their own DL sharing with a Drawable draw callback? Seems like this would be possible, but I'd have to dig further. Not sure at all how an app would do with with shared buffer objects, texture objects, etc. Paul Martz Skew Matrix Software LLC *http://www.skew-matrix.com* http://www.skew-matrix.com/ +1 303 859 9466 Robert Osfield wrote: Hi Raphael, On Tue, Aug 11, 2009 at 6:36 PM, Raphael Sebberaphael.se...@gmail.com raphael.se...@gmail.com wrote: Is it possible in OSG to use shared opengl contexts that are created outside of OSG, and yet declare to OSG that they are sharing their texture spaces (and VBO, etc)? I searched the documentation, but could not find a way to do that. There isn't any support for doing this directly. If you use the GraphicsWindowEmedded feature of osgViewer they you could probably do it, but you'd loose threading and multi-context support provided by osgViewer. If you just need a single context and single threading then this would be OK. See the osgviewerSDL and osgviewerGLUT for examples of this in action. In general though, the OSG is designed to be the primary way you drive OpenGL apps rather than something that is secondary and piggy backing on the back of another part of the app that does OpenGL. Lazy state updating, state sorting, threading and and multi-context management that make the scene graph so useful are all things that make mixing with 3rd party OpenGL code awkward. Robert. ___ osg-users mailing listosg-us...@lists.openscenegraph.orghttp://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using shared OpenGL contexts
Hi Raphael, On 17/08/09 2:10 PM, Raphael Sebbe wrote: To further clarify, my goal is to be able to use multiple GL contexts representing the same scene from different camera angles, and those contexts could well be GL views in windows, FBOs, or even Core Animation GL layers (Mac). As said previously, having textures on 3D objects being the result of some GPU image processing (Core Image), or the other way around, using the result of 3D rendering as input to GPU filters (Core Image) are possible applications. But all these things require some kind of flexibility in the way you create/declare (possibly shared) contexts, to avoid duplicating VBO, DL and other GPU resources all over. A nice extension to OSG would be to make it possible to work with external contexts, even if some constraints need to be enforced (such as state preserving across OSG calls, or other threading constraints). But this is probably easier to say than to implement. I will dig some more in the source to find out. I would also find this a helpful extension. A while ago I wrote some code to that effect for passing an AGLContext* as traits-sharedContext to GraphicsWindowCarbon. The code would first do the usual dynamic_cast to GraphicsWindowCarbon and PixelBufferCarbon and if both fail would simply static_cast the pointer to AGLContext. This was an ugly hack of course. A better(?) way might be to create a GraphicsWindowCarbon constructor with an existing AGLContext*. Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using shared OpenGL contexts
Hi Raphael, On Tue, Aug 11, 2009 at 6:36 PM, Raphael Sebberaphael.se...@gmail.com wrote: Is it possible in OSG to use shared opengl contexts that are created outside of OSG, and yet declare to OSG that they are sharing their texture spaces (and VBO, etc)? I searched the documentation, but could not find a way to do that. There isn't any support for doing this directly. If you use the GraphicsWindowEmedded feature of osgViewer they you could probably do it, but you'd loose threading and multi-context support provided by osgViewer. If you just need a single context and single threading then this would be OK. See the osgviewerSDL and osgviewerGLUT for examples of this in action. In general though, the OSG is designed to be the primary way you drive OpenGL apps rather than something that is secondary and piggy backing on the back of another part of the app that does OpenGL. Lazy state updating, state sorting, threading and and multi-context management that make the scene graph so useful are all things that make mixing with 3rd party OpenGL code awkward. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using shared OpenGL contexts
Robert -- Thanks for replying to this; I saw the post and was curious myself as to how this could be done. Let's assume the app has created their own contexts and done so with object sharing set up correctly. Taking just DLs as an example, could the app enforce their own DL sharing with a Drawable draw callback? Seems like this would be possible, but I'd have to dig further. Not sure at all how an app would do with with shared buffer objects, texture objects, etc. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 Robert Osfield wrote: Hi Raphael, On Tue, Aug 11, 2009 at 6:36 PM, Raphael Sebberaphael.se...@gmail.com wrote: Is it possiblein OSGto use shared opengl contexts that are created outside of OSG, and yet declare to OSG that they are sharing their texture spaces (and VBO, etc)? I searched the documentation, but could not find a way to do that. There isn't any support for doing this directly. If you use the GraphicsWindowEmedded feature of osgViewer they you could probably do it, but you'd loose threading and multi-context support provided by osgViewer. If you just need a single context and single threading then this would be OK. See the osgviewerSDL and osgviewerGLUT for examples of this in action. In general though, the OSG is designed to be the primary way you drive OpenGL apps rather than something that is secondary and piggy backing on the back of another part of the app that does OpenGL. Lazy state updating, state sorting, threading and and multi-context management that make the scene graph so useful are all things that make mixing with 3rd party OpenGL code awkward. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using shared OpenGL contexts
Hi, Is it possible in OSG to use shared opengl contexts that are created outside of OSG, and yet declare to OSG that they are sharing their texture spaces (and VBO, etc)? I searched the documentation, but could not find a way to do that. Thank you, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
