Hi All,
Last Friday I dived in and did my first pass review of Sukender's work
on a meta data system for the OSG. Now that I've got the 2.9.15 dev
release out the door I've returned for a second look. My current
reaction is that it feels rather too complicated and with it a bit
awkward to understand how it works and how to use it. I can work how
it works and I think I understand how to use it, but it does take
several reads so this makes me concerned about the burden of support
that might come with it - i.e. lots of traffic on osg-users.
So I'm now thinking about whether we can come up with a lighter weight
meta data system, and with it try and make it possible to wire up with
osgDB serialization. Serialization in osgDB is based around providing
wrappers per osg::Object subclass, so to leverage serialization we'll
either need to modify osgDB's serialization so it can handle something
even lower level than osg::Object, or for use to have the meta data
system use osg::Object.
Since osg::Object is pretty low level and lightweight - coming in at
only 48 bytes on my 64bit linux system, I'm inclined to say it's small
enough to be be used for meta data objects, and it also comes with an
inbuilt std::string for it's name, so this name could potentially be
used for the indexing of the data if we want to get/set the elements
by name.
In terms of providing convience for setting/getting int, string, float
etc. types I wonder if an series of IntObject, FloatObject,
StringObject etc types my provided that use multiple inheritance ("is
a"), or agregation "have a" to store the value. Serializers for these
could be added to osgDB's wrappers so end users wouldn't need to do
anything for basic types like these. We could use a template to
provide this mapping and then a series of typedefs or convinience
methods could provide settings and getters, either via templates or
just parameters i.e.
ValueContainer : public osg::Object
{
void insert(Object*)
Object* getObject(const std::string&);
void setValue(const std::string& name, int& value);
bool getValue(const std::string& name, int& value);
void setValue(const std::string& name, float& value);
bool getValue(const std::string& name, std::string& value);
};
For the existing UserData and DescriptionList I'm currently inclined
to hardwire this into ValueContainer as getUserData() and
getDescitionList(). This is a bit clunky but it'll be less
complicated trying to adapt both of these into osg::Object. So we
might have something like:
ValueContainer : public osg::Object
{
void setUserData(osg::Referenced*)
Referenced* getUserData();
typedef std::vector<std::string> DescriptionList;
void setDecriptionList(DescrtionList& dl);
DescriptionList& getDescritionList();
void setValue(const std::string& name, int& value);
bool getValue(const std::string& name, int& value);
void setValue(const std::string& name, float& value);
bool getValue(const std::string& name, std::string& value);
};
The container used within ValueContainer could be an
std::vector<osg::ref_ptr<osg::Object>> to allow indexing via a
conventional array style access, with linear search used to locate the
values in the vector when you want to access via a name. We wouldn't
normally expect to find huge data structues stored in these containers
so I wouldn't expect this to be a performance issue. If one did
require quick access to very large string data then one could just
create a custom class subclassed from osg::Object.
The above scheme would also be able to nest ValueContainers as entries
in the value vector. osg::Object itself will have a a
ref_ptr<ValueContainer> and associated get/set methods for it so I
guess this might be a little confusing if one thought about it too
long. Given this is a free feature gained by using osg::Object as the
base of the storage and most users would never require this nesting I
don't think we'd need worry about it.
For naming I've using ValueContainer here as it's what been used in
Sukender's implememtation. I feel it's a bit too generic though,
perhaps even something like UserDataContainer might convey a bit more
what it's role is.
I'm open to suggestions, please let me know what you think.
Cheers,
Robert.
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
