Hi, On Wed, 2010-06-02 at 12:17 -0500, Carsten Neumann wrote: > 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.
not quite, the reset should have happened from where the destroyed functor is called but it seems in the wrong place. I would prefer to have it there instead of pushing the responsibility to every class that uses the gl id infrastructure. > 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? I'll have to check. > > 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! to understand it better, how many windows are in your environment ? In general something looks not quite right in the whole gl object handling inside the window so I will have a further look. kind regards gerrit ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Opensg-users mailing list Opensg-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/opensg-users
