Hi Fred, You won't be able to do threading and the GraphicsWindowEmbedded functionality, the two are mutually exclusive as the embedded feature is just a crude non op implementation of a proper GraphicsWindow, so there isn't an implementation of makeCurrent, releaseContext and swapBuffers that are required for multi-threaded and multi-context work.
If you want threading then rather than embedded the OSG why not embed the 3rd party OpenGL code in an OSG created graphics context via a Camera pre/post draw callback. As for insulating state changes, you'll need to use a glPushAttrib/glPopAttrib. Robert. On Wed, Sep 23, 2009 at 4:03 PM, Frederic Marmond <[email protected]> wrote: > Hello world, > > I'm making a study on how integrate OSG inside an external openGL engine. > I know it's not the best use of osg, ok... :) > > So I used osgViewer::Viewer::setUpViewerAsEmbeddedInWindow() as a start. > It's ok, as long as I don't modify the opengl state outside OSG. > => how may I force OSG to consider the opengl state has changed (and > so, re-apply all its states) ? > => using that technique, would I be able to cull / draw osg stuff in > separate threads (handled by the hosting engine) ? > > thanks in advance for any answer or tips... > > cheers ! > Fred > _______________________________________________ > 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
