Hi Marco, Thanks for the file. I've done the test and don't see any stateset's shared so I can reproduce the issue you are seeing so its a good first step.
As for what piece of code should be fixed, I think it's much a design > choice. A fundamental question is: what is the postcondition of > Object::computeDataVariance()? I find it logical to state that after > computeDataVariance() is called, the object's variance is either STATIC or > DYNAMIC. If the function doesn't find any reason why the object should be > tagged as dynamic, it should mark it as static. After all, if an object is > dynamic because the user externally modifies it, it's user's responsibility > to set its data variance accordingly. I will review the Optimizer code that should be setting the the DataVariance. > Another concern is what an osgDB plugin should do when it reads from a > format that doesn't provide information about data variance. Since the user > receives only the root node of a scene graph that is created in an "opaque" > way, should child nodes and attributes be marked as STATIC if not explicitly > made dynamic by the plugin itself? > > BTW, was the UNSPECIFIED flag really necessary? :-) Let me see.... do I usually add things that have no use or reason for existence.... So yes, UNSPECIFIED help solve the problem of deciding what data variance an StateAttribute should have, if the user has explicitly set STATIC or DYNAMIC then this is a formal decision made by the user and its inappropriate to override this with automatic codes that try to work out what data variance is appropriate. However, if the DataVariance is UNSPECIFIED then its just that, on creation it isn't know how it'll be used and whether it'll vary or not. Once the whole scene graph is setup and callback attached then it one can start making much better guesses at what DataVariance is likely to be appropriate as the the user will have attached callback generally before the Optimizer has run. The question right now is to review Optimizer to see if it needs updating. Robert.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
