[osg-users] Node::Description into a generalized property mechanism?
u.hertlein at sandbox.de
Mon Nov 30 03:12:00 PST 2009
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
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?
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.
More information about the osg-users