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.
Robert Osfield wrote:
Hi Raphael,
On Tue, Aug 11, 2009 at 6:36 PM, Raphael Sebbe<[email protected]> 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
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
|
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
