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 Sebbe<raphael.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
