On Thu, Jul 15, 2010 at 6:40 PM, Tom Pearce <[email protected]> wrote:
> Hi JP, Tim, > > Thanks for the replies. > > Using the single threaded mode gets rid of the flicker, as does setting the > state set data variance to dynamic when I create the scene graph: > mt->getOrCreateStateSet()->setDataVariance(osg::Object::DYNAMIC); > > I'm convinced that your explanation of collision between draw and update > traversals is in play, since those fixes worked. However, I'm still unsure > of why(whether?) the flickering was related to creating 'new' materials in > the callback. When I use multi-threaded viewer The graphics state management system is complex. Rather than try to analyze exactly what's going on, I'll point you to a pair of articles I wrote on the subject: http://www.bricoworks.com/articles/stateset/stateset.html on StateSets and StateAttributes and http://www.bricoworks.com/articles/stategraph/stategraph.html on the StateGraph mechanism. You'll see that changing a StateAttribute in a StateSet while the draw phase is changing graphics state is not a good thing. Tim > mode and I don't set variance to dynamic (i.e., ripe for collisions), the > color does NOT flicker if I'm NOT using a 'new' material, but does flicker > when I do use 'new'. In addition, it is only the second sphere that > flickers, while both of them are creating new materials and modifying the > state set each time, which leads me to believe there is something more > complicated going on. The collisions would be occurring in all of these > cases but the flickering does not always follow as the result. > > I'm not sharing state sets at all - there are two different matrixtransform > nodes, each with it's own state set. That's why I'm confused about how the > color of the first one is ever applied to the second. Each newly created > material has its color defined before the state set is modified to include > that attribute, so even with thread collisions happening I don't understand > how stateset2 knows what color stateset1 is. > > Again, you are both absolutely right about how to avoid the issue, and I > understand that the test code I originally included does things one > shouldn't do. I was just trying to understand what was happening in memory > to get that effect - probably it is just that traveral collisions are doing > stranger things than I imagine. They have never crashed the test app > though. ;) > > Thank you! > > Cheers, > Tom > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=30042#30042 > > > > > > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
