Hello Robert,
Thank you for taking up this task. While not central to the mission of
graphics rendering, this feature will certainly make writing
applications around OSG a little bit easier for all of us.
My proposal for putting get/setUserValue convenience methods directly
osg::Object was based on the idea that the interface methods on
osg::UserDataContainer would accept the "parent" object as a parameter,
thus allowing a single container instance to be shared while providing
different data to different callers. Without that aspect, having
get/setUserValue on osg::Object still offers some convenience but also
introduces confusion and redundancy. Also, the ability to set any
osg::Object as the metadata container for any other osg::Object seems
like an invitation for chaos.
I think the pattern you describe as
"object->getUserDataContainer()->get...()" is acceptable, and is
perfectly consistent with the existing scene graph patterns in OSG
(setting up StateSets in particular comes to mind -- indeed recently
someone wanted to use StateSets as an ad-hoc metadata scheme).
My preference looks like:
class osg::Object {
// access _userDataContainer
osg::UserDataContainer* getUserDataContainer();
void setUserDataContainer(osg::UserDataContainer*);
osg::UserDataContainer* getOrCreateUserDataContainer();
// for backwards compatibility, defer to _userDataContainer
virtual get/setDescriptions();
virtual get/setUserData();
};
// abstract base class user data container
class osg::UserDataContainer : public osg::Object {
// returns self
osg::UserDataContainer* getUserDataContainer();
osg::UserDataContainer* getOrCreateUserDataContainer();
// throws exception/assertion or otherwise fails
void setUserDataContainer(osg::UserDataContainer*);
// return data on this object
virtual get/setDescriptions();
virtual get/setUserData();
// Abstract metadata interface
virtual get/setUserValue() = 0;
};
// Default implementation, used by
osg::Object::getOrCreateUserDataContainer()
class osg::StdUserDataContainer : public osg::UserDataContainer {
virtual get/setUserValue() { ... }
};
This seems very straightforward and avoids cluttering up osg::Object.
Is there a reason this approach was rejected, aside from a desire to
avoid the "object->getUserDataContainer()->get...()" pattern?
If a single user data container instance is referenced by multiple
nodes, will it be serialized once or multiple times?
Can a user data container contain references to osg::Objects in the same
scene graph? Can the serializers handle this?
Again, your work is very much appreciated!
Thanks,
Peter
On 6/7/2011 9:51 AM, Robert Osfield wrote:
> Hi All,
>
> After my first cut of the new osg::Object::UserData functionality I've
> been pondering on how best to provide the ability to customize the
> data storage container, if at all. Simplicity and performance are the
> key reasons for not providing the ability to customize the data
> storage container as it enevitablly requires use of virtual functions
> for data access, extra classes and public methods for these.
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
