[osg-users] osgQt doesn't set a context ID

Chris Djali krizdjali at gmail.com
Tue Mar 12 11:36:20 PDT 2019


For context, this discussion is about the OpenMW CS tool, the source of which is available here: https://gitlab.com/OpenMW/openmw/tree/master/apps/opencs. I've kind of inherited maintenance responsibilities for the graphical parts of this without necessarily knowing much of how it works. It might well do dumb things, but in cases where it's significantly more work to remove the dumb things than work around them, a workaround is preferable. Anyhow...

The OpenMW CS uses osgQt to render an OSG scene onto a QWidget. The widget can be closed and reopened without closing the whole application, and when this happens, the widget and its OpenGL context both are destroyed. When something else needs rendering, a new widget and new OpenGL context are created, but the same OSG scene graph is reused. For the most part, everything's fine with this. However, as I've mentioned in this GitHub issue (https://github.com/openscenegraph/osgQt/issues/24) osgQt isn't ever setting up a context ID, so things like per-context programs think it's the same OpenGL context and this causes OpenGL errors as they try to use objects that don't exist in the new context.

To quote the important part of what I said in the issue report:

> When an OpenGL context is created with regular OSG, the window implementation calls osg::GraphicsContext::createNewContextID() to generate a unique ID for that context and passes it to osg::State::setContextID(), allowing things like per-context programs and vertex buffers to work. When a new context is created with osgQt, however, the state's context ID is never set, so if an application uses multiple contexts with the same OSG objects, things break.

I can avoid the symptoms by setting the context ID from within my application, but this seems to me like something osgQt should be handling itself.

I could take a stab at working out where exactly a new context is created in osgQt and in which cases it actually shares objects with an existing one to try and resolve this myself, but hopefully, someone with better knowledge of the codebase is around and can do a better job. The issue report I made doesn't seem to have garnered any attention, so I'm hoping that a forum post gets more visibility.

Many thanks,


Read this topic online here:

More information about the osg-users mailing list