Hi Sylvain, n 22 April 2014 14:30, Sylvain Comtois <[email protected]> wrote: > Hi Robert, > > I use two way to modify my scene graph. > > The first one is using the UpdateCallback each time it is possible. > The second one is when we are outside the ViewerBase::frame() function. > Our application have a lot of threads and i use a mutex to be sure the OSG > tree is never access in the same time by two or more threads. > > The code like this: > > mRenderingTreeMutex.lock > mViewer->frame() > mRenderingTreeMutex.Unlock > > And each time i touch the OSG tree, i use the same mutex. > > mRenderingTreeMutex.lock > Modifiying OSG tree > mRenderingTreeMutex.Unlock > > So in my case i call the Viewer::setLightingMode between my > mRenderingTreeMutex and the function modify the internal variable > _lightingMode. According to the debugger, this variable is process during the > cull_draw that is made by all camera's thread in the same time. > > So, during one thread call the _globalStateSet->removeMode(GL_LIGHTING) > function, another one use the _globalStateSet variable and this variable is > the same for all threads that cause the crash. > > Everything append in the void SceneView::setLightingMode(LightingMode > mode) function. > > To temporary solve my problem, i add a mutex to protect the access to the > _globalStateSet variable. > > Maybe this variable can be process in the update instead of the cull/draw?
Thanks for the update. Looking through where SceneView::setLightingMode() gets called the one that looks suspicious is the SceneView::inheritCullSettings. The inheritCullSettings is meant to update the SceneView's local data to reflect settings that are inherited from above. What it shouldn't be doing is modifying external data - which in this case is the _globalStateSet as this is the data structured that is shared between the different viewer Cameras that are being threaded. SceneView's design is a bit of hang up of it's role in the early days of the OSG development, before the days of multi-threading. The particular bug you've uncovered is likely something that others users haven't come across simply because most users of multi-theaded OSG apps don't need to go change LightingMode like yours does. I haven't yet worked out the best solution, but my current inclination is to move the OpenGL lighting configuration in response to the View(er)::setLightingMode() to be moved out of SceneView and into View::setLightingMode(), the SceneView::inheritCullSettings would then ignore the local LightingMode settings. Or for use to move the setting of the Light/GLMode modes in SceneView from working on the global stateset to one of the local StateSet's that SceneView manages. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
