Hi Chris,
have you noticed the "Suggestion: Add components in nodes (aggregation)" thread from
around 29/10/2009? It deals with something similar, namely to introduce something like a
osg::KeyValueMap (derived from osg::Referenced) that can be attached to osg::Objects as
user-data. (These could also serialize to and from files.)
I would also like having a general purpose key/value object so that loaders can attach
data to images for example.
osgDB::Options could use this as well instead of getOptionsString() (which is used by
heaps of plugins that do a find('myOption') on it) and getPluginData() (which is a
string->void* map).
Of course this doesn't yet solve your problem with there being only one user-data field.
The problem I see with adding a new meta-data field to objects is what happens with name
conflicts when two plugins/programs want to use the same 'key' name? In that case we'd
need to introduce namespaces (like a map of string->KeyValueMap) so that each plugin can
have its own key/value map?
Thoughts?
/ulrich
On 30/11/09 5:09 AM, Chris 'Xenon' Hanson wrote:
Mattias Helsing wrote:
Is there a reason to why you don't use setUserData(osg::Referenced*) ?
If you provide the proper read/write routines for your osg::Referenced
derived class it would also persist across .osg file writes/reads.
Because there's only one UserData, and in my library code that I might share
with
others, I try to avoid taking exclusive use of some asset that others might be
used in
their application code.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
