On Thu, Jun 3, 2010 at 2:31 AM, Gerrit Voß <vo...@vossg.org> wrote: > > 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.
I would agree if the location that invokes the destroy GL functor has enough information to reset the ID, then it would be a lot more robust for this reset to happen in a single location. >> 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 We are actually only using a single passive window inside of Qt. I believe that we are running into this because we are dynamically creating and destroying a lot of geometry and textures. Our application is based on a globe, so we start by zooming into a city. This causes geometry and textures to be paged into and out of the system. Once at a city view if we add and remove geometry with a shader attached we will see this problem occur. -Aron ------------------------------------------------------------------------------ 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
