Hello Aron, Aron Bierbaum wrote: > We have been running into what appears to be a corner case in the > ShaderProgram. As most of you probably know each OpenSG object that > needs to track a GL object ID registers it's OpenGL creation and > destruction functors through Window::registerGLObject(). This > registration returns a unique OpenSG ID for each registered object. > This unique OSG is then used in each objects handleGL() and > handleDestroy() methods to get the context specific OpenGL object ID > from each window. (ex: win->getGLObjectId(getGLId())) The normal > operation is that when an object is created for a window you call the > OpenGL function and set the OpenGL object ID in the ID map. Then in > handleDestroyGL() you clear this ID mapping by setting it back to > zero. It is important to note that these OpenSG object IDs are > intelligently reused when objects are created/destroyed. > > The issue that we are running into is that the current ShaderProgram > code relies on the shared OSG IDs to have their mappings in each > window reset to zero by all other objects in the system. > > http://www.opensg.org/browser/trunk/Source/System/State/Shader/Base/OSGShaderProgram.cpp#L528 > > This causes a big problem because there are a number of places where > these IDs are not being cleared correctly in their handleDestroyGL() > equivalent function. I did a quick search and found the following > locations where the mapping from OpenSG ID to OpenGL ID is not being > reset to zero correctly when destroying the OpenGL object.
hm, that is a nasty one - thanks for figuring out what the problem is. I wonder if ShaderProgram should simply check if mode == window::initialize instead of testing for a 0 gl id? I don't think there are cases were we want to create a new shader object and mode != initialize. Gerrit: is it possible to get a gl id of 0 even if mode != initialize? > http://www.opensg.org/browser/trunk/Source/System/NodeCores/Drawables/Geometry/Base/WS/OSGGeometry.cpp#L280 > http://www.opensg.org/browser/trunk/Source/System/NodeCores/Drawables/Geometry/Base/WS/OSGGeometry.cpp#L359 > http://www.opensg.org/browser/trunk/Source/System/State/Base/WS/OSGTextureObjChunk.cpp#L1487 > > http://www.opensg.org/browser/trunk/Source/System/Depreciated/State/OpenGL/OSGCubeTextureChunk.cpp#L242 > http://www.opensg.org/browser/trunk/Source/System/State/OpenGL/OSGCubeTextureObjChunk.cpp#L253 > http://www.opensg.org/browser/trunk/Source/System/Window/FrameBufferObjects/OSGFrameBufferObject.cpp#L576 > http://www.opensg.org/browser/trunk/Source/System/NodeCores/Drawables/Geometry/Properties/OSGGeoMultiPropertyData.cpp#L221 > http://www.opensg.org/browser/trunk/Source/System/NodeCores/Drawables/Geometry/Properties/OSGGeoProperty.cpp#L317 > http://www.opensg.org/browser/trunk/Source/System/Window/FrameBufferObjects/OSGRenderBuffer.cpp#L242 > http://www.opensg.org/browser/trunk/Source/System/NodeCores/Drawables/Nurbs/OSGSurface.cpp#L1880 I checked all handleDestroyGL functions and fixed those that did not reset the mapping. > Although I think that we should fix these locations so that the IDs > are rest correctly, can the ShaderProgram code be changed to not have > such a fragile requirement for checking the OpenGL ID against zero. I > have attached a patch for an older revision of OpenSG 2.0 that relaxes > this requirement and we have been using for a few weeks without any > issues. I've also committed a patch similar to the one you sent, but made surrounded the test with #ifdef OSG_DEBUG. If indeed ShaderProgram can test the mode instead of the gl id, this can be removed again. Thanks again for the bug analysis and patch! Cheers, Carsten ------------------------------------------------------------------------------ _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
