[osg-users] Removing objects with shared GL state from scene graph

Julien Valentin julienvalentin51 at gmail.com
Thu Mar 28 05:44:48 PDT 2019

Hi Chris,
I haven't dive into the problem, but would making the osgText::Text::program static (and share it with all instances) could be a proper way to handle this issue?

AnyOldName3 wrote:
> Hi,
> I know that when an OpenGL context is destroyed, the associated viewer can only call releaseGLObjects(osg::State *) for nodes still attached to the scene graph, so if you're removing things before that, you're manually supposed to call releaseGLObjects on the subgraph.
> However, as I see it, there's a potential problem here. If the subgraph contains nodes that share GL objects with things still attached to the main scenegraph, you'll end up releasing those, too. This can mostly be worked around by not sharing GL objects between nodes with different lifetimes, but sometimes that's not possible.
> For example, osgText::Text seems to have a global osg::Program used for all instances (or, at least, all instances with the same settings). If I always call releaseGLObjects when removing subgraphs containing an osgText::Text, it's going to kill the per-context programs and they'll need rebuilding for any other text nodes, which isn't desirable. If I never call releaseGLObjects, then that's even worse (for obvious reasons). It seems like the only good ways of handling this would be to either keep track of when the last text node was removed so the objects could be released when their last user was removed, or move 'removed' objects to another part of the scene graph (e.g. as a disabled osg::Switch child) so they're actually kept around without being drawn, but still get their GL objects released when the context is destroyed. There's also the hacky option of attaching another text node somewhere else in the scenegraph so it always gets released, which works in the specific 
 case of osgText::Text, but won't work in the general case, and doesn't seem desirable.
> Is there a better way of handling this than I've suggested here? If there's something intended for this built into OSG that I just don't know about, that would be great, but I'm not going to shy away from writing something custom if that's what's necessary.
> Cheers,
> Chris

Twirling twirling twirling toward freedom

Read this topic online here:

More information about the osg-users mailing list