Hi Robert, once again, we all really appreciate your work on Open Scene Graph and on picking up this feature in particular. I've reviewed the new check in, comments below --
On 6/9/2011 9:33 AM, Robert Osfield wrote: > With the C pointer trick in the bag it became a simple refactor of the > osg::Object and osg::UserDataContainer interfaces and implementations, > with the s/getUserObject(..) access methods moving from osg::Object > into pure virtual UserDataContainer base > class. The setUserData/getUserData() stay put in osg::Object but are > virtual to allow the UserDataContainer to override them. The > Description list access methods were then moved back into osg::Node, > keeping the osg::Object cleaner and avoiding > the conceptual overlap between osg::Object and UserDataContainer. > Finally a DefaultUserDataContainer implementation is > provided, and is almost identical to my original UserDataContainer. I noticed that DefaultUserDataContainer does not set the parent _userDataContainer field to "this", nor does it override getUserDataContainer() / setUserDataContainer(). I suppose this allows meta-data about meta-data, but it means that calling getUserValue() / setUserValue() on a UserDataContainer will not work that way you would expect, because it will pass through to the underlying chained _userDataContainer field which is empty instead of setting data fields on the UserDataContainer itself. > One suggestion of Peter's that I have gone with is passing in an > osg::Object* to the UserDataContainer methods that would have enabled > him to share a single custom UserDataContainer implementation between > objects in the scene and have the custom container work the correct > data for each object. I rejected this suggestion in my previous email > and still feel it's inappropriate. If one does want centralized > access to user data associated with objects then there is no reason to > place this in the scene graph - if you are going to have a data > structure that is mapping Object pointers to internal data objects > then it's global operation already, it's not something that needs or > should be distributed throughut the scene graph. Even if one did > create such a global mapping I'm doubtful that a Object pointer would > even be the appropriate key is to use to access it as pointers to > Object change when being serialized in and out - so re-run your app > and all your pointers are different for the same scene graph objects. > For this type of task I would lean towards have a user manage unique > ObjectID that is used as the key, and the natural place to put this > would be... in a custom UserDataContainer. I have come to the same conclusion. I'm satisfied with the current design now (except for the comment above). -- Peter Amstutz Senior Software Engineer Technology Solutions Experts Natick, MA 02131h _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
