Re: [osg-users] Meta-data in core OSG - project started
Hi Peter,
On Thu, Jun 9, 2011 at 10:07 PM, Peter Amstutz
peter.amst...@tseboston.com wrote:
I understand the circular reference problem with setting
_userDataContainer to this, so overriding get/setUserDataContainer()
and ignoring _userDataContainer seems like a reasonable solution to me.
Making _userDataContainer a private (not protected) field of osg::Object
prevents end-runs around subclasses that overrides getUserDataContainer().
Having UserDataContainer::getUserDataContainer() return this would
still create a
circular reference as any code that chained calls to use data would
end up in an infinite loop.
The osg::Object serializers automatically write out the
UserDataContainer so is one
example of code that would end up in an infinite loop. One could put
work arounds in
to such code but it's not particularily robust.
Logically I don't think it make sense either, as osg::Object agregates
UserDataContainer, and
UserDataContainer is a osg::Object so should logically do the same.
I don't think the UserDataContainer having an active
getUserDataContainer() is a problem,
but osg::Object::set/getUserValue not working how you'd expect in on a
UserDataContainer is
so I would suggest that this template functions implementation be
tweaked to return use this
pointer if it's dynamic_cast to UserDataContainer.
I have gone for the following implemetation:
/** provide implementation of osg::Object::getUserValue(..) template*/
templatetypename T
bool osg::Object::getUserValue(const std::string name, T value) const
{
typedef TemplateValueObjectT UserValueObject;
const osg::UserDataContainer* udc = dynamic_castconst
osg::UserDataContainer*(this);
if (!udc) udc = _userDataContainer;
const UserValueObject* uvo = udc ? dynamic_castconst
UserValueObject*(udc-getUserObject(name)) : 0;
if (uvo)
{
value = uvo-getValue();
return true;
}
else
{
return false;
}
}
/** provide implementation of osg::Object::setUserValue(..) template.*/
templatetypename T
void osg::Object::setUserValue(const std::string name, const T value)
{
typedef TemplateValueObjectT UserValueObject;
osg::UserDataContainer* udc = dynamic_castosg::UserDataContainer*(this);
if (!udc)
{
getOrCreateUserDataContainer();
udc = _userDataContainer;
}
unsigned int i = udc-getUserObjectIndex(name);
if (iudc-getNumUserObjects()) udc-setUserObject(i, new
UserValueObject(name,value));
else udc-addUserObject(new UserValueObject(name,value));
}
Let me know if you spot a problem with this approach.
Cheers,
Robert.
Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, hi all, first, thank you for what you've done with this project! I must say i didn't expect the meta data to be in before the 3.0 ... Right now, Sukender is more or less dying under his heavy workload, so I think he reads his emails but unfortunately doesn't have enough time to deeply look into everything you've said. As for me I have two main questions: 1. This first question is not directly linked with the meta feature it's just that i'm still very new to OSG and even more to serialization. How are we going to serialize a custom type meta in our container? I've looked into the UserDataContainer serializer, and I get that when it serializes the _objectList, every object serialializer is called depending on the object type. But I still couldn't figure how and where I should specify the proper serialization for a custom object. 2. When I see the 3 diffent attributes in the UserDataContainer for _userData, _descriptionList and _objectList, I don't know if there's something awkward, or if I don't fully understand the issues. The _userData and _desciptionList are, to me, meta values like any other meta value, so why the special treatment? It makes the UserDataContainer a little heavier to have these three attributes instead of one std::vector. Couldn't we imagine some kind of _userData and _desciptionList subclassing from Object? Maybe this way we could make UserDataConainer inherit from std::vector directly? Instead of being a container containing our real containers. Well I hope my questions are not off-board ;) Gregoire. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Grogoire, On Fri, Jun 10, 2011 at 2:58 PM, Gregoire Tarizzo gregoire.tari...@virtuelcity.com wrote: As for me I have two main questions: 1. This first question is not directly linked with the meta feature it's just that i'm still very new to OSG and even more to serialization. How are we going to serialize a custom type meta in our container? I've looked into the UserDataContainer serializer, and I get that when it serializes the _objectList, every object serialializer is called depending on the object type. But I still couldn't figure how and where I should specify the proper serialization for a custom object. I provide an example of serializer in the osguserdata example, and there are plenty of other examples of serializers in src/osgWrappers/serializes for all the core OSG classes. 2. When I see the 3 diffent attributes in the UserDataContainer for _userData, _descriptionList and _objectList, I don't know if there's something awkward, or if I don't fully understand the issues. The _userData and _desciptionList are, to me, meta values like any other meta value, so why the special treatment? For backwards compatibility UserData is a osg::Referenced, you can't just assign it as a UserObject as this requires the Objects to be subclassed from osg::Object. You could in their have a custom Obect that holds the a ref_ptr for the UserData but this really would be an ungodly hack. In the case of the Descriptions list it's also backwards compatibility - you can fake compatibiity using a custom UserObject just for holding the Descriptions vector but it's a real hack to do so. So the approach I took actually has far less special treatment than the alternative, and fits very seamlessly in with the old API and it's usage. It makes the UserDataContainer a little heavier to have these three attributes instead of one std::vector. Couldn't we imagine some kind of _userData and _desciptionList subclassing from Object? Maybe this way we could make UserDataConainer inherit from std::vector directly? Instead of being a container containing our real containers. The extra cost a ref_ptr and std::vectorstd::string is pretty small, and in normal usage I woudl expect only a small number of UserDataContainer objects to ever be created so this cost really is likely to be very small indeed. Given we have removed the std::vectorstd::string from osg::Node I would expect the new scheme to result in small scene graphs for everybody. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi All, I wasn't planning to revist the user data implementation this week, but the weaknesses in design has been lurking at the back of my mind, it just wasn't as clean as I'd have liked. With the feature freeze for 3.0 happening at the end of next week I couldn't help but want to get the implementation right for the stable release, so this morning I revisted the implementation. The key awkwardness in the version checked in earlier this week was that osg::Object had a number of virtual access methods for user objects with this overriden by the UserDataContainer, but also the osg::Object agregated the UserDataContainer, so the releationship was one of both inheritance and composition. It worked and was easier to use, but it wasn't clean conceptually. Peter picked up on this design/implementation awkwardness and suggested that this could be resolved by moving the virtual access methods for UserDataContainer out of osg::Object and into UserDataContainer make this class a pure virtual class, with a DefaultUserDataContainer subclassing from this to provide the standard implementation. Moving the access methods out of osg::Object does mean that accessing the user objects will require an checks against and usage of object.getUserDataContainer(), and it introduces an implementation issue of osg::Object having a ref_ptrUserDataContainer when UserDataContainer is a subclass from osg::Object, which introduces a potential definition order problem for getting the code compiled. When mulling over the design I came to the conclusion that Peter's suggestion was a more elegant design, I had originall consider such an approach but the definition order issue is one that I wasn't original comfortable with so didn't pursue it. With thinking about the definition order issue I realised it could easily be walked around by using a C pointer to the UserDataContainer in osg::Object and have the osg::Object::setUserDataContainer(UserDataContainer*) implementation manage the ref()/unref() rather than rely upon osg::ref_ptr that requires the class definiation for it be able to be compiled. 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. Now osg::Object has one set of access method that I didn't move - the templated s/getUserValue(..) methods, I could have moved these to UserDataContainer but as the methods are implementated with forward declared templates there isn't an order definition issue so the implementation is free to provided separately and use the full UserDataContainer interface. In terms of convinience it's couldn't be simpler than having the g/setUserValue methods available in osg::Object, and the osguserdata example itself didn't have to be modified at all where s/getUserValue access was used so it works well. The only parts of the osguserdata example I have had to modify to account for these changes is the adding of the osg::Geometry object as a UserObject, and output of the UserObject list as both of these require the access methods only available in osg::UserDataContainer. I have been able to update the serialization support to handle the new implementation so everything functions as well as it did on the previous rev - only with a cleaner class relationship. These changes are now checked into svn/trunk so please test them out. 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
Re: [osg-users] Meta-data in core OSG - project started
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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, On Thu, Jun 9, 2011 at 4:02 PM, Peter Amstutz peter.amst...@tseboston.com wrote: 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, I debated setting the UserDataContainer's _userDataContainer to itself but it woudl create a circular reference so ceratinly a no go. Potentially you could override the Object::s/getUserDataContainer methods to return self but would in itself introduce an inconsistency between how objects and containers behave. I also have no objection to UserDataContainer's having their own User data objects nested within them. 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. I hadn't spotted this issue, and agree it's potentially confusing when a UserData In the cases where you have nested UserDataContainer. The current implementation won't work with UserDataContainer::s/getUserValue(..) without a nested UserDataContainer, it'll just return false. Could one override the s/getUserValue() template in UserDataContainer? I haven't ever tried this type of template usage so can't say whether it might work. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
On 6/9/2011 11:54 AM, Robert Osfield wrote:
I debated setting the UserDataContainer's _userDataContainer to itself but it
woudl create a circular reference so ceratinly a no go.
Potentially you could override the Object::s/getUserDataContainer
methods to return self
but would in itself introduce an inconsistency between how objects and
containers behave.
I also have no objection to UserDataContainer's having their own User
data objects
nested within them.
I can't think of a use case for allowing a UserDataContainer to have its
own separate UserDataContainer (meta-meta-data?). If you need to chain
them together or be nested, you can just as easily have an entry in the
user data object list point to another UserDataContainer.
I understand the circular reference problem with setting
_userDataContainer to this, so overriding get/setUserDataContainer()
and ignoring _userDataContainer seems like a reasonable solution to me.
Making _userDataContainer a private (not protected) field of osg::Object
prevents end-runs around subclasses that overrides getUserDataContainer().
I have attached a patch which makes
osg::UserDataContainer::getUserDataContainer() and related methods
return this as I describe above.
In the patch, get/setUserValue() call getUserDataContainer() and use the
container that is returned, rather than accessing _userDataContainer
directly. This means the behavior will defer to the embeded
_userDataContainer by default except when the object is itself a
UserDataContainer, in which case get/setUserValue() operate on the
object itself.
Arguably this is slightly inconsistent, but I think it is much more
useful and desirable behavior than manipulating the _userDataContainer
itself embedded in _userDataContainer.
--
Peter Amstutz
Senior Software Engineer
Technology Solutions Experts
Natick, MA
02131
Index: include/osg/Object
===
--- include/osg/Object (revision 12513)
+++ include/osg/Object (working copy)
@@ -122,17 +122,17 @@
/** set the UserDataContainer object.*/
-void setUserDataContainer(osg::UserDataContainer* udc);
+virtual void setUserDataContainer(osg::UserDataContainer* udc);
/** get the UserDataContainer attached to this object.*/
-osg::UserDataContainer* getUserDataContainer() { return
_userDataContainer; }
+virtual osg::UserDataContainer* getUserDataContainer() { return
_userDataContainer; }
/** get the const UserDataContainer attached to this object.*/
-const osg::UserDataContainer* getUserDataContainer() const { return
_userDataContainer; }
+virtual const osg::UserDataContainer* getUserDataContainer() const {
return _userDataContainer; }
/** Convinience method that returns the UserDataContainer, and if one
doesn't already exist creates and assigns
* a DefaultUserDataContainer to the Object and then return this new
UserDataContainer.*/
-osg::UserDataContainer* getOrCreateUserDataContainer();
+virtual osg::UserDataContainer* getOrCreateUserDataContainer();
/**
@@ -186,10 +186,10 @@
std::string _name;
DataVariance _dataVariance;
+private:
+
osg::UserDataContainer* _userDataContainer;
-private:
-
/** disallow any copy operator.*/
Object operator = (const Object) { return *this; }
};
Index: include/osg/UserDataContainer
===
--- include/osg/UserDataContainer (revision 12513)
+++ include/osg/UserDataContainer (working copy)
@@ -158,9 +158,6 @@
/** Get the index position of first user data object that matches
specified name.*/
virtual unsigned int getUserObjectIndex(const std::string name,
unsigned int startPos=0) const;
-
-
-
/** Set the list of string descriptions.*/
virtual void setDescriptions(const DescriptionList descriptions);
@@ -175,6 +172,18 @@
/** Add a description string.*/
virtual void addDescription(const std::string desc);
+
+/** Not allowed to set user data on a user data. */
+virtual void setUserDataContainer(osg::UserDataContainer* udc) { }
+
+/** Return self */
+virtual osg::UserDataContainer* getUserDataContainer() { return this; }
+
+/** Return self */
+virtual const osg::UserDataContainer* getUserDataContainer() const {
return this; }
+
+ /** Return self */
+virtual osg::UserDataContainer* getOrCreateUserDataContainer() {
return this; }
protected:
Index: include/osg/ValueObject
===
--- include/osg/ValueObject (revision 12513)
+++ include/osg/ValueObject (working copy)
@@ -172,7 +172,9 @@
bool osg::Object::getUserValue(const std::string name, T value) const
{
typedef
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter,
On Tue, Jun 7, 2011 at 9:51 PM, Peter Amstutz
peter.amst...@tseboston.com wrote:
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.
Um... I find this idea to be a bit awkward and only really at useful for very
specific usage model where you want a single custom UserDataContainer
to maanage all user data access for the scene graph. If you don't use
share a single UserDataContainer between objects then passing the
Object pointer is pointless and confusing - and this will be the default
scheme used by the vast majority of users.
Having multiple custom UserDataContainer that reference single central
data container is possible with the current scheme and wouldn't polute a
small numbers of users needs into the core classes.
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 chaos is a rather overblown suggestion. The latest rev isn't an
ideal class layout, and as I've said it does feel awkward but I don't
ever expect anything other
than a tiny proportion of users to ever need to assign their own
UserDataContainer
let alone provide a custom UserDataContainer, I strongly doubt that
the ability to
attach a normal osg::Object as a user data container is likely to cause any
problems.
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*);
small note, I'm avoiding use of exceptions in the core, due to the
needs of embedded OSG usage - I don't
want different behaviours on different builds.
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?
There is a little awkward issue of having a ref_ptr to sublcass of osg::Object
from within an osg::Object itself. To get around this you'd need to
define any subclass
as a nested class of osg::Ojbect, which... polutes osg::Object so it's
swings and
rounabouts with sticking the functionality in a subclass.
If a single user data container instance is referenced by multiple
nodes, will it be serialized once or multiple times?
Once, all osg::Object are serailized with an unique object id that is
written out
once then subsequent refrences to the that Object used the object id. When the
data is read back in the serializers just create on instance and then
share it.
This feature automatically will work for user data.
Can a user data container contain references to osg::Objects in the same
scene graph? Can the serializers handle this?
They are all just osg::Object's they all just get seralized out. The
osguserdata
example attaches an osg::Geometry as a user object and it gets serialized in and
out correctly. The only thing you'd need to be minful of is if a
UserDataContainer
holds a referneced to a paret - this would cause a circular refefence
that would
prevent all the objects in the loop and their children from being
deleted. This is
a standard issue for any ref counted data strucutre so isn't a
specific to user data,
it's just an issue users need to be mindful.
W.r.t you suggestion. Feel free to go ahead an implement what you are
thinking of,
reviewing stuff thta actually is implemented and working in header and
source files is
far more pratical than second guessing write ups in emails. The only
part I feel strongly
is the wrong way is the passing of the Object* to the access methods
in UserData,
Re: [osg-users] Meta-data in core OSG - project started
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. I personally don't see performance when using user data as being that critical - it will only be an occassional node that will have user data and the data won't typically be accessed in such an intense manner as data strucutres like drawables and statesets. Given this assumption the issue of using virtual functions for data access won't be a critical issue. This left the issue of code simplicity. The orignal code I checked in was pretty well the simplicist I could come up with whilst still providing the basic user object functionality. Adding the ability to subclasses forces extra complexity into the implementation and interface as we have to make the interface for setting and getting the UserDataContainer public, as well as the provide the class interface to the user data access methods. If we are to add the subclassing feature than we can't avoid this extra complexity completly, the best we can do is minimize this complexity creep. This morning I set about seeing if I could do this. One of the constraints I set myself was the ability to add serialization support for the new user data functionality, I've already provided this for the ValueObject types, and to add this for a customizable UserDataContainer we then have to subclass this container from osg::Object. The conudrum with this is that the convinince methods for accessing the UserData, the UserObject list and the Descriptions list are all in osg::Object and my original implememtation just defered this to the UserDataContainer, but if UserDataContainer subclasses from osg::Object it will inherit all these access methods so there is potential for confusion and duplication. I couldn't find a way around this - we either move out the access methods out of osg::Object into a UserDataContainer class and have users do a object-getUserDataContainer()-get...(), or provide an new class ObjectWithUserDataContainerInterface that subclasses from osg::Object and provides the data access methods with StateSet,Node, Drawable etc. inheriting from this ObjectWithUserDataContainerInterface to get the functionality. I did originally try that later approach but inserting an extra node in the class inheritance of these core OSG classes just ended up being an unweildly mess and provided a knock on effect on all the serializers. Yuck. Another approach I original toyed with before I simplified things was to make all the key user data access methods in osg::Object virtual and have them defer to an agregated UserDataContainer for their implementation. The UserDataContainer being subclased from osg::Object would then override this default implementations of the access methods and rather than deferring to it's onw internal _userDataContainer for it's implementation would provide the data structures itself. This approach I felt was a bit awkward, so for my first pass implementation ended up going for non virtual methods and a simply UserDataContainer struct to store the required data. Having reviewed all the options again I came back to the virtual functions in osg::Object in the above a paragraph as being the most pratical way to provide the customizable UserDataContainer functionality. I have now gone ahead and implemented it to test out how much complexity creeps in and how easy it is to manage the implementation and serialization support. The implementation works fine, and I don't believe the extra complexity isn't so great that it will be hinderance to maintainability or a hinderance to users getting to grips with it. I still feel that the virtual functions being all embedded in osg::Object is a bit hacky, but I can't see an easy way around this whilst retaining backwards compatibility. If I were to write the OSG from scratch with this user data functionality I'd probably go for a different scheme, but we don't really have this luxury, but with a mature project sometimes you just have to find a workable compromise. So what does it look in practice? We'll I'm comfortable enough with the implementation that I've gone ahead and checked it into svn/trunk, so please do an svn update and let me know how you get on with build and runtime. In the osguserdata example I've added a very simple MyUserDataContainer subclass along with a very simple serializer for it, you can run the app and use this custom container by running the app with the --mydc (my data container) and if it works you'll get the usual output plus lines like MyUserDataContainer::getUserObject(9). The custom user data container in this example is kept very simply by just subclassing from
Re: [osg-users] Meta-data in core OSG - project started
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
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, I have now checked the changes into svn/trunk so would appreciate feedback on build and runtime of these latest changes, fingers crossed the template and macros used won't introduce any platform portability issues. My x86 build seemed to go fine, as you can see on cdash. My x64 one finished successfully but failed to submit results to cdash, probably just a hiccup in the cdash server's connection or something, but it did finish. So seems you're ok for now :-) Hopefully people will start using it and send feedback soon. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi All, After quite a few trials I have now got serialization working for the new osg::Object user object support and the associated osg::ValueObject. I believe what I have implemented is a reasonable first stab at a basic user object scheme and should solve a range of problems relating to adding extra user info to osg::Object in the scene graph. I have now checked in the changes so look forward to feedback from the community. The key areas of changes can be found in include include/osg/Object and a new header include/osg/ValueObject, with a new example osguserdata providing both a test bed for the new functionality and an example of setting and getting values as well as IO support. I have now checked the changes into svn/trunk so would appreciate feedback on build and runtime of these latest changes, fingers crossed the template and macros used won't introduce any platform portability issues. Thanks in advance for testing and feedback, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter,
I'm open to suggestions on making the implementation more flexible,
however, any extra complexity has to be strongly justified - i.e. with
concrete usage case, so could you flesh out what you'd want to do with
the subclassing from UserDataContainer.
Another route for adding extra flexiblity would be to just subclass
your own user data scheme from osg::Object and assign it as UserData
or as UserObject, then do a dynamic cast to get access to your custom
implementation. Currenly you can share UserData and UserObjects
between their owner osg::Object.
As for sharing whole UserDataContainer objects between their owner
osg::Objects, this is something I considered and implemented initially
but then decided to make things simpler and just have an internal data
container subclassed from osg::Referenced. Adding the capability of
sharing UserDataContainer won't be difficult, but will require us to
push the declaration of the UserDataContainer into the public scope
something that will constain how flexibile we can be with the
implementation and it's interface, and would require us to implement
UserDataContainer as an osg::Object rather than Referenced so we could
get the cloning support that osg::Object provides.
A subclassable UserDataContainer would also push us towards
subclassing from osg::Object, which isn't difficult, but it does open
the doors users nesting UserDataContainer within a UserDataContainer,
now this could be seen as an advantage or just extra complexity.
Initially I implemented UserDataContainer as a subclass from
osg::Object but then pulled back as the public interface for access to
the
internal UserDataContainer conflicted with the UserDataContainer's own
access functions - I had to make the osg::Object methods virtual and
override then in UserDataContainer and it ended up being rather messy.
The other issue that a subclassable UserDataContainer brings is that
what happens during serialization - when we writing out we could use
the standard UserDataContainer access methods, but when reading back
in you'd want to construct explitly the custom UserDataContainer for
each node than needs it. You can probably solve this by serializng
the UserDataContainer itself, and have a custom wrapper to implement
the CustomUserDataContainer so that the serializer creates everything
appropriately. This is fine but it leaves the question of how to map
the old UserData and Description list in a backwards compatible way.
For now I am going to get the serializers working for
.osgb/.osgt,/osgx as they are and if that all works I'll check my work
in so that others can test the build and runtime side. Once we have
the simplicist implementation working fine we'll be able to a base for
concrete proposals for adding even greater flexibility, but be
prepared to fight your corner if the extra flexibility comes with
extra complexity ;-)
Robert.
On Tue, May 31, 2011 at 5:36 PM, Peter Amstutz
peter.amst...@tseboston.com wrote:
Hi Robert,
This looks pretty straightforward and I agree that less complexity is
good. However a would modify it slightly to support two related
features I have been lobbying for, which are the ability to share
UserDataContainers between osg::Objects, and the ability to subclass a
custom UserDataContainer implementation.
The idea is that there is generally not a 1:1 correlation between the
application entity model and the scene graph. Because of this, one
often wants to be able to share or inherit metadata information, or look
up metadata on the fly to avoid copying large amounts of application
data into the scene graph.
I think it feasible to add one level of indirection without adding too
much complexity. For example:
- Make osg::UserDataContainer a pure abstract class.
class OSG_EXPORT UserDataContainer : public osg::Referenced
{
public:
void addUserObject(Object* owner, Object* obj) = 0;
void setUserObject(Object* owner, unsigned int i, Object* obj) = 0;
void removeUserObject(Object* owner, unsigned int i);
unsigned int getUserObjectIndex(Object* owner, const osg::Object* obj)
const = 0;
unsigned int getUserObjectIndex(Object* owner, const std::string
name) const = 0;
Object* getUserObject(Object* owner, unsigned int i) = 0;
const Object* getUserObject(Object* owner, unsigned int i) const = 0;
Object* getUserObject(Object* owner, const std::string name) = 0;
const Object* getUserObject(Object* owner, const std::string name)
const = 0;
unsigned int getNumUserObjects(Object* owner) const = 0;
};
- Provide a default implementation which doesn't do anything with the owner
field
class OSG_EXPORT DefaultUserDataContainer : public UserDataContainer
{
ref_ptrReferenced _userData;
b DescriptionList _descriptionList;
ObjectList _objectList;
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, hi all, Sorry for being silent these days... I just got back on the OSG development. Well I've read your posts and I must admit I'm a bit disapointed because proposed changes seem rather radical to me, and implies some features will be dropped/reduced... The backwards compatibility support for UserData looks like it'll introduce a memory leak Ok. You're right. Sorry! 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. I did not understand why you hardwired userData and descriptionList instead of letting them be metadata as any other. I don't think this is less complicated. On the contrary, I feel we must factorize code as much as possible. And this seems akward to me because this forces to have more lines of code, and thus have more things to debug. I feel more confortable with less methods and less lines of code, don't you? BTW, moving descriptionList availability from Node to Object seems not a good idea as we're trying to make them disapear. However this may centralize metadata to one place, so why not, as long as deprecation is clear and explicit...? This is subject to discussion! The idea of having a ValueBase class which only provides the Referenced class and a local clone() seems rather too minimal. Object has clone functionality built into it and hooks into the OSG's serializers I'm quite in favor of using osg::Object as a base for metadata, especially for serialization. But the fact it already stores a name is problemetic when you want your data to be indexed by name, or if you wish your data be put in a database backend. For instance, using a map would require names duplicaion (one in the map, one in osg::Object), or a strange mapstring*, Object, string pointer compare thing. Any opinion/idea on this? Mine is that an osg::Object without name would be ideal, but this would bring another class! Unless we move the name as a metadata too? Well this could be a nice idea: some meta names would be reserved, and especially one for the name, one for userData, and one for descriptionList. Thoughts? I also wonder if perhaps ValueContainer and ValueContainerMap might just become oen class ValueMap I'm not in favor of this. Grégoire and I explicitely made two classes to let the user choose the container. Especially we wanted to let database backend (a requirement of some OSG users) be easy to plug. As Peter told, I guess the ability to subclass a custom UserDataContainer implementation is important. However I uderstand your point of view on sharing containers, especially regarding to serialization. So what about something not sharable, but which user can subclass? Another route for adding extra flexiblity would be to just subclass your own user data scheme from osg::Object and assign it as UserData or as UserObject The proposal of putting a user-defined container as a metadata may solve the problem but seems also a bit a burden for the user. The container used within ValueContainer could be an std::vectorosg::ref_ptrosg::Object to allow indexing via a conventional array style access The proposal of a vectorref_ptrObject seems okay for a default implementation (instead of a map). You're right about trying to keep the class count down (and my implementation is certainely not optimal), but I keep thinking the container should be customizable and I would keep the ValueContainer class. As a conclusion, I can say this subject is not closed yet! ;-) Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Peter, I'm open to suggestions on making the implementation more flexible, however, any extra complexity has to be strongly justified - i.e. with concrete usage case, so could you flesh out what you'd want to do with the subclassing from UserDataContainer. Another route for adding extra flexiblity would be to just subclass your own user data scheme from osg::Object and assign it as UserData or as UserObject, then do a dynamic cast to get access to your custom implementation. Currenly you can share UserData and UserObjects between their owner osg::Object. As for sharing whole UserDataContainer objects between their owner osg::Objects, this is something I considered and implemented initially but then decided to make things simpler and just have an internal data container subclassed from osg::Referenced. Adding the capability of sharing UserDataContainer won't be difficult, but will require us to push the declaration of the UserDataContainer into the public scope something that will constain how flexibile we can be with the implementation and it's interface, and would require us to implement UserDataContainer as an
Re: [osg-users] Meta-data in core OSG - project started
Hi Sukender, On Wed, Jun 1, 2011 at 2:00 PM, Sukender suky0...@free.fr wrote: Well I've read your posts and I must admit I'm a bit disapointed because proposed changes seem rather radical to me, and implies some features will be dropped/reduced... I'm striving to find a good balance between extensibility and flexibiity and complexity of the implementation and interface. It's very easy to get carried away at try to solve too many problems in one place and end up with a system that might server the needs of small number of power users but be too complicated for the majority of users to use easily for their needs. We also have to maintain and document and support the API's we come up with, the more complex they are the greater the burden. 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. I did not understand why you hardwired userData and descriptionList instead of letting them be metadata as any other. I don't think this is less complicated. On the contrary, I feel we must factorize code as much as possible. And this seems akward to me because this forces to have more lines of code, and thus have more things to debug. I feel more confortable with less methods and less lines of code, don't you? My reason to provide the UserData and Descriptions list hardwired is three fold - backwards compatibility is much easier when the data strucutres are mapped 1:1, compatibility with older files is much to achieve when the same granulatiry is kept, and finally I I found the solution that you came up with a real cludge - it wasn't easy to read and follow what was going on, it is was possible to break it due to the hardwiring of the names not being protected. BTW, moving descriptionList availability from Node to Object seems not a good idea as we're trying to make them disapear. However this may centralize metadata to one place, so why not, as long as deprecation is clear and explicit...? This is subject to discussion! It's all just access methods, the Descrptions list will be available via osg::Object no matter what solution we go for, it's just whether we have public accessors for it that make it convinient to use. Originally I had felt that we should probably not be encouraging use of UserData and the Descriptions list, but now I'm not sure they do any harm, and if this functionality is exactly what you wanted in the first place then any other access to it other than through the current conience methods will be more awkward to use. I now feel there is little harm in keeping this methods available and making placing them in osg::Object, there is no memory overhed, it's more consistent. The idea of having a ValueBase class which only provides the Referenced class and a local clone() seems rather too minimal. Object has clone functionality built into it and hooks into the OSG's serializers I'm quite in favor of using osg::Object as a base for metadata, especially for serialization. But the fact it already stores a name is problemetic when you want your data to be indexed by name, or if you wish your data be put in a database backend. For instance, using a map would require names duplicaion (one in the map, one in osg::Object), or a strange mapstring*, Object, string pointer compare thing. Any opinion/idea on this? Mine is that an osg::Object without name would be ideal, but this would bring another class! Unless we move the name as a metadata too? Well this could be a nice idea: some meta names would be reserved, and especially one for the name, one for userData, and one for descriptionList. Thoughts? I don't think using a map or equivilant backend is sensible due to the duplication and potential for maps and containers getting out of sync. osg::Object has a Name field, we can't just remove this because it doesn't fit nicely with using a std::map in a nieche feature like User data values, we can't just go breaking compatibility for small stuff like this. Given we have to keep the Object Name field it makes sense to use it in the context of user data. I also wonder if perhaps ValueContainer and ValueContainerMap might just become oen class ValueMap I'm not in favor of this. Grégoire and I explicitely made two classes to let the user choose the container. Especially we wanted to let database backend (a requirement of some OSG users) be easy to plug. As Peter told, I guess the ability to subclass a custom UserDataContainer implementation is important. However I uderstand your point of view on sharing containers, especially regarding to serialization. So what about something not sharable, but which user can subclass? I am yet to be convienced providing the ability to subclass from the UserDataContainer is worthwhile. Subclassing from
Re: [osg-users] Meta-data in core OSG - project started
Hi All,
On Tue, May 31, 2011 at 5:01 PM, Robert Osfield
robert.osfi...@gmail.com wrote:
Right now my main priority is working out how to provide the IO support
Yesterday afternoon and this morning I tried to get serializer support
working, and it now
works for osg::Object subclasss that provide their own serializer
wrappers, but I have
struggled to get things to work for the ValueObject templates and hit
what looks like a
bit of dead end.
So have had to back up a little and implement a ValueObject base class
that provides
two Vistor interface classes for getting and setting the values that
the ValueObject subclasses
provided. I now have a TemplateValueObject that sublcasses from
ValueObject and make it
easy to provide the support various basic data types.
Attached is my modification to my include/osg/Object and the new
osguserdata.cpp example code.
In the example I've tested the new vistor interface to list all the
data values and types via:
class MyGetValueVisitor : public osg::ValueObject::GetValueVisitor
{
public:
virtual void apply(bool value) { OSG_NOTICE bool value; }
virtual void apply(char value) { OSG_NOTICE char value; }
virtual void apply(unsigned char value) { OSG_NOTICE uchar
value; }
virtual void apply(short value) { OSG_NOTICE short value; }
virtual void apply(unsigned short value) { OSG_NOTICE
ushort value; }
virtual void apply(int value) { OSG_NOTICE int value; }
virtual void apply(unsigned int value) { OSG_NOTICE uint value; }
virtual void apply(float value) { OSG_NOTICE float value; }
virtual void apply(double value) { OSG_NOTICE double value; }
virtual void apply(const std::string value) { OSG_NOTICE
string value; }
virtual void apply(const osg::Vec2f value) { OSG_NOTICE
Vec2f value; }
virtual void apply(const osg::Vec3f value) { OSG_NOTICE
Vec3f value; }
virtual void apply(const osg::Vec4f value) { OSG_NOTICE
Vec4f value; }
virtual void apply(const osg::Vec2d value) { OSG_NOTICE
Vec2d value; }
virtual void apply(const osg::Vec3d value) { OSG_NOTICE
Vec3d value; }
virtual void apply(const osg::Vec4d value) { OSG_NOTICE
Vec4d value; }
virtual void apply(const osg::Quat value) { OSG_NOTICE
Quat value; }
virtual void apply(const osg::Plane value) { OSG_NOTICE
Plane value; }
virtual void apply(const osg::Matrixf value) { OSG_NOTICE
Matrixf value; }
virtual void apply(const osg::Matrixd value) { OSG_NOTICE
Matrixd value; }
};
I'm thinking that this would provide something that can aid the
serialization support a bit more easily - I'll know this later once I
start using it in this context. I'll provide an update if this works
out.
The visitor also allows us to implement adaption of types
automatically, the example now implements the follow:
templatetypename T
class GetNumeric : public osg::ValueObject::GetValueVisitor
{
public:
GetNumeric():
_set(false),
_value(0) {}
virtual void apply(bool value) { _value = value; _set = true; }
virtual void apply(char value) { _value = value; _set = true; }
virtual void apply(unsigned char value) { _value = value; _set
= true; }
virtual void apply(short value) { _value = value; _set = true; }
virtual void apply(unsigned short value) { _value = value;
_set = true; }
virtual void apply(int value) { _value = value; _set = true; }
virtual void apply(unsigned int value) { _value = value; _set = true; }
virtual void apply(float value) { _value = value; _set = true; }
virtual void apply(double value) { _value = value; _set = true; }
bool_set;
T _value;
};
templatetypename T
T getNumeric(osg::Object* object)
{
osg::ValueObject* bvo = dynamic_castosg::ValueObject*(object);
if (bvo)
{
GetNumericT gn;
if (bvo-get(gn) gn._set) return gn._value;
}
return T(0);
}
Which is invoked:
std::coutNumerical Value is
getNumericfloat(node-getUserObject(myvalue));
I'm not sure we should provide such a specific template function as
once you get started down this route one really has to wonder where to
draw the line. Also how users might want to handle cases where the
UserObject doesn't exist or is an imcompatible type - this all is
rather opened and while we could code something complete enough to do
this it's just more code and more complexity to overload the OSG
headers with. So I'm inclined to provide examples in the osguserdata
example and then leave it to end users to decide how they want to
manage things.
Robert.
Object
Description: Binary data
/* OpenSceneGraph example, osganalysis.
*
* Permission is hereby granted, free of charge, to any person obtaining a copy
* of this software and associated documentation files (the Software), to deal
* in the Software without restriction, including without limitation the
Re: [osg-users] Meta-data in core OSG - project started
Hi All,
This morning I've been experimenting with extending the user data
support in the OSG, along the lines set out by Sukender. I've tried
to keep the class count down, and keep the user interface relatively
straight forward. Implementation wise I have gone for an
osg::Object::UserDataContainer that is used an internal implementation
structure in osg::Object, and this doesn't have any public interface.
This simple nested class is defined within the osg::Object protected
scope and looks like:
class OSG_EXPORT UserDataContainer : public osg::Referenced
{
public:
UserDataContainer();
UserDataContainer(const UserDataContainer udc, const
osg::CopyOp copyop=CopyOp::SHALLOW_COPY);
virtual void setThreadSafeRefUnref(bool threadSafe);
typedef std::vector osg::ref_ptrosg::Object ObjectList;
ref_ptrReferenced _userData;
DescriptionList _descriptionList;
ObjectList _objectList;
};
Access methods for the old UserData and Descriptions list are
maintained, with the later moved in from osg::Node to allow all
osg::Object classes access to these convinience methods. These
methods automatically create the UserDataContainer when required and
can be used in an identical was as before.
The new element is the ObjectList vector in UserDataContainer, this
can store any object subclasses from osg::Object which can be access
either via index into the vector or by the name of the osg::Object
(i.e. Object::setName()/getName()). I have put convience methods into
osg::Object public scope to access the UserDataContainer:
void addUserObject(Object* obj);
void setUserObject(unsigned int i, Object* obj);
void removeUserObject(unsigned int i);
unsigned int getUserObjectIndex(const osg::Object* obj) const;
unsigned int getUserObjectIndex(const std::string name) const;
Object* getUserObject(unsigned int i);
const Object* getUserObject(unsigned int i) const;
Object* getUserObject(const std::string name);
const Object* getUserObject(const std::string name) const;
unsigned int getNumUserObjects() const;
This gets us so far, but... it forces us to provide our own subclasses
of osg::Object to be able to put in our own Data, to ease the burden I
have introduced a templatetypename T ValueObject implementation that
has a T _value member.
templatetypename T
class ValueObject : public osg::Object
{
public:
ValueObject():
Object(true),
_value()
{
}
ValueObject(const std::string name, T value):
Object(true),
_value(value)
{
setName(name);
}
ValueObject(const ValueObject rhs, const osg::CopyOp
copyop=osg::CopyOp::SHALLOW_COPY):
Object(rhs,copyop),
_value(rhs._value)
{
}
META_Object(osg, ValueObject)
void setValue(const T value) { _value = value; }
const T getValue() const { return _value; }
protected:
T _value;
};
And a couple of convinience methods in osg::Object to create/access these:
templatetypename T
bool getUserValue(const std::string name, T value) const
{
typedef ValueObjectT UserValueObject;
UserValueObject* uvo =
dynamic_castUserValueObject*(getUserObject(name));
if (uvo)
{
value = uvo-getValue();
return true;
}
else
{
return false;
}
}
templatetypename T
void setUserValue(const std::string name, const T value)
{
typedef ValueObjectT UserValueObject;
unsigned int i = getUserObjectIndex(name);
if (igetNumUserObjects()) setUserObject(i, new
UserValueObject(name,value));
else addUserObject(new UserValueObject(name,value));
}
It's these methods that I'd expect the access to go through. As a
quick test I have created an osguserdata example than we can use as a
test bed for this new functionality. My current rev looks like:
int main(int argc, char** argv)
{
osg::ref_ptrosg::Group node = new osg::Group;
int i = 10;
node-setUserValue(Int value,i);
int j = 0;
if (node-getUserValue(Int value,j))
{
OSG_NOTICEInt value=jstd::endl;
}
else
{
OSG_NOTICEInt value not foundstd::endl;
}
std::string testString(All seems fine);
node-setUserValue(Status,testString);
std::string readString;
if (node-getUserValue(Status,readString))
{
OSG_NOTICEStatus=readStringstd::endl;
}
else
{
OSG_NOTICEStatus not foundstd::endl;
}
return 0;
}
So far I'm getting the correct values, and everything compiles OK
under g++ 4.5.2, hopefully
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert,
Just an observer of the thread ... I like what you've done so far, as I
think it has far more reaching applications (even outside of OSG). I've
put together something similar on a separate project that doesn't use
OSG. The biggest issue that I found was how to handle getting/setting
values when the variable types don't match. And as such, I just wanted
to send along a heads-up on that issue.
For me, I wanted to still maintain the get/set functionality even if the
variable type was different. For instance, if my base value was a
double, but yet the calling routine wanted an integer return, I wanted
to return a valid value as an integer (if possible). I was able to work
around the issue by using the boost library and it's numeric_cast
functionality (for me, the use of the boost library was not an issue).
I realize that this is not really an option for OSG as it presents a
significant additional dependency, and you've stayed away from such in
the past. But, maybe a look into the boost library may help address the
issue. Of course, that's if you wanted to handle type casting to begin
with.
Regards,
Chuck
On Tue, 2011-05-31 at 09:19 -0500, Robert Osfield wrote:
Hi All,
This morning I've been experimenting with extending the user data
support in the OSG, along the lines set out by Sukender. I've tried
to keep the class count down, and keep the user interface relatively
straight forward. Implementation wise I have gone for an
osg::Object::UserDataContainer that is used an internal implementation
structure in osg::Object, and this doesn't have any public interface.
This simple nested class is defined within the osg::Object protected
scope and looks like:
class OSG_EXPORT UserDataContainer : public osg::Referenced
{
public:
UserDataContainer();
UserDataContainer(const UserDataContainer udc, const
osg::CopyOp copyop=CopyOp::SHALLOW_COPY);
virtual void setThreadSafeRefUnref(bool threadSafe);
typedef std::vector osg::ref_ptrosg::Object ObjectList;
ref_ptrReferenced _userData;
DescriptionList _descriptionList;
ObjectList _objectList;
};
Access methods for the old UserData and Descriptions list are
maintained, with the later moved in from osg::Node to allow all
osg::Object classes access to these convinience methods. These
methods automatically create the UserDataContainer when required and
can be used in an identical was as before.
The new element is the ObjectList vector in UserDataContainer, this
can store any object subclasses from osg::Object which can be access
either via index into the vector or by the name of the osg::Object
(i.e. Object::setName()/getName()). I have put convience methods into
osg::Object public scope to access the UserDataContainer:
void addUserObject(Object* obj);
void setUserObject(unsigned int i, Object* obj);
void removeUserObject(unsigned int i);
unsigned int getUserObjectIndex(const osg::Object* obj) const;
unsigned int getUserObjectIndex(const std::string name) const;
Object* getUserObject(unsigned int i);
const Object* getUserObject(unsigned int i) const;
Object* getUserObject(const std::string name);
const Object* getUserObject(const std::string name) const;
unsigned int getNumUserObjects() const;
This gets us so far, but... it forces us to provide our own subclasses
of osg::Object to be able to put in our own Data, to ease the burden I
have introduced a templatetypename T ValueObject implementation that
has a T _value member.
templatetypename T
class ValueObject : public osg::Object
{
public:
ValueObject():
Object(true),
_value()
{
}
ValueObject(const std::string name, T value):
Object(true),
_value(value)
{
setName(name);
}
ValueObject(const ValueObject rhs, const osg::CopyOp
copyop=osg::CopyOp::SHALLOW_COPY):
Object(rhs,copyop),
_value(rhs._value)
{
}
META_Object(osg, ValueObject)
void setValue(const T value) { _value = value; }
const T getValue() const { return _value; }
protected:
T _value;
};
And a couple of convinience methods in osg::Object to create/access these:
templatetypename T
bool getUserValue(const std::string name, T value) const
{
typedef ValueObjectT UserValueObject;
UserValueObject* uvo =
dynamic_castUserValueObject*(getUserObject(name));
if (uvo)
{
value = uvo-getValue();
return true;
}
else
{
return false;
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert,
This is great! Being able to store meta-data in any osg::Object derived
class has been something we've wanted for a while now.
Regarding serialization, will your changes break loading of older models
that contained node descriptions? This is a big concern for us because we
have hundreds of models that contain description strings.
Anyways, I'll begin playing around with these changes and report any issues
I encounter.
Cheers,
Farshid
On Tue, May 31, 2011 at 7:19 AM, Robert Osfield robert.osfi...@gmail.comwrote:
Hi All,
This morning I've been experimenting with extending the user data
support in the OSG, along the lines set out by Sukender. I've tried
to keep the class count down, and keep the user interface relatively
straight forward. Implementation wise I have gone for an
osg::Object::UserDataContainer that is used an internal implementation
structure in osg::Object, and this doesn't have any public interface.
This simple nested class is defined within the osg::Object protected
scope and looks like:
class OSG_EXPORT UserDataContainer : public osg::Referenced
{
public:
UserDataContainer();
UserDataContainer(const UserDataContainer udc, const
osg::CopyOp copyop=CopyOp::SHALLOW_COPY);
virtual void setThreadSafeRefUnref(bool threadSafe);
typedef std::vector osg::ref_ptrosg::Object ObjectList;
ref_ptrReferenced _userData;
DescriptionList _descriptionList;
ObjectList _objectList;
};
Access methods for the old UserData and Descriptions list are
maintained, with the later moved in from osg::Node to allow all
osg::Object classes access to these convinience methods. These
methods automatically create the UserDataContainer when required and
can be used in an identical was as before.
The new element is the ObjectList vector in UserDataContainer, this
can store any object subclasses from osg::Object which can be access
either via index into the vector or by the name of the osg::Object
(i.e. Object::setName()/getName()). I have put convience methods into
osg::Object public scope to access the UserDataContainer:
void addUserObject(Object* obj);
void setUserObject(unsigned int i, Object* obj);
void removeUserObject(unsigned int i);
unsigned int getUserObjectIndex(const osg::Object* obj) const;
unsigned int getUserObjectIndex(const std::string name) const;
Object* getUserObject(unsigned int i);
const Object* getUserObject(unsigned int i) const;
Object* getUserObject(const std::string name);
const Object* getUserObject(const std::string name) const;
unsigned int getNumUserObjects() const;
This gets us so far, but... it forces us to provide our own subclasses
of osg::Object to be able to put in our own Data, to ease the burden I
have introduced a templatetypename T ValueObject implementation that
has a T _value member.
templatetypename T
class ValueObject : public osg::Object
{
public:
ValueObject():
Object(true),
_value()
{
}
ValueObject(const std::string name, T value):
Object(true),
_value(value)
{
setName(name);
}
ValueObject(const ValueObject rhs, const osg::CopyOp
copyop=osg::CopyOp::SHALLOW_COPY):
Object(rhs,copyop),
_value(rhs._value)
{
}
META_Object(osg, ValueObject)
void setValue(const T value) { _value = value; }
const T getValue() const { return _value; }
protected:
T _value;
};
And a couple of convinience methods in osg::Object to create/access these:
templatetypename T
bool getUserValue(const std::string name, T value) const
{
typedef ValueObjectT UserValueObject;
UserValueObject* uvo =
dynamic_castUserValueObject*(getUserObject(name));
if (uvo)
{
value = uvo-getValue();
return true;
}
else
{
return false;
}
}
templatetypename T
void setUserValue(const std::string name, const T value)
{
typedef ValueObjectT UserValueObject;
unsigned int i = getUserObjectIndex(name);
if (igetNumUserObjects()) setUserObject(i, new
UserValueObject(name,value));
else addUserObject(new UserValueObject(name,value));
}
It's these methods that I'd expect the access to go through. As a
quick test I have created an osguserdata example than we can use as a
test bed for this new functionality. My current rev looks like:
int main(int argc, char** argv)
{
osg::ref_ptrosg::Group node = new osg::Group;
int i = 10;
node-setUserValue(Int value,i);
Re: [osg-users] Meta-data in core OSG - project started
Hi Chuck, On Tue, May 31, 2011 at 4:44 PM, Chuck Cole charles.e.c...@nasa.gov wrote: Just an observer of the thread ... I like what you've done so far, as I think it has far more reaching applications (even outside of OSG). I've put together something similar on a separate project that doesn't use OSG. The biggest issue that I found was how to handle getting/setting values when the variable types don't match. And as such, I just wanted to send along a heads-up on that issue. Right now there isn't any support getting a different type than has been set, for now I'm happy to just require users to either explict get the correct type for a field or have them get the basic Object and then use C++'s RTTI to detmine the object type and then let them deal with it. Automtically casting from one type to another on getting is an awkward issue as it's so open ended. Casting between int/float/double is relatively straight forward, but your this there isn't any obvious mapping. Perhaps one could specialize the ValueObject template into a NumbericObject which provides a range of getValueAsInt, getValueAsFloat etc. In terms of setting it is straight forward to explictly assign the type in the method so that it's able to use C++'s automatically casting. For example: node-setUserValuefloat(Height,1.4); Is able to get C++ to cast the 1.4 double into a float so that it creates a ValueObjectfloat object when assigning it to the Object::UserDataContainer::_objectList. Right now my main priority is working out how to provide the IO support and keeping the whole infrastructure simple and straightforward to use, rather than trying to cover all types of usage. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Farshid, On Tue, May 31, 2011 at 5:01 PM, Farshid Lashkari fla...@gmail.com wrote: Regarding serialization, will your changes break loading of older models that contained node descriptions? This is a big concern for us because we have hundreds of models that contain description strings. I haven't modified how the UserData and Description strings are supported so right now all existing files should just work as before. I am still considering how to add support for the more generic UserObject list, it might be that for .ive and .osg we'll just leave support out and just add support into the new serializer formats. With all these changes backwards compatibility is something we need to retain, so if something does break then we'll need to work out how to address this. So the testing out in the community will be really important even for those apps that don't use the new functionality. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert, That definitely sounds very sensible as it can get out of hand very quickly. In fact, what you present as an example is exactly what I ended up doing (i.e., implementing numerous methods such as getVariableAsFloat, getVariableAsInteger, etc.). But I wasn't sure which way you were heading on this, thus my previous comment. What you've done so far does look very promising though. Thanks. Chuck On Tue, 2011-05-31 at 11:01 -0500, Robert Osfield wrote: Hi Chuck, On Tue, May 31, 2011 at 4:44 PM, Chuck Cole charles.e.c...@nasa.gov wrote: Just an observer of the thread ... I like what you've done so far, as I think it has far more reaching applications (even outside of OSG). I've put together something similar on a separate project that doesn't use OSG. The biggest issue that I found was how to handle getting/setting values when the variable types don't match. And as such, I just wanted to send along a heads-up on that issue. Right now there isn't any support getting a different type than has been set, for now I'm happy to just require users to either explict get the correct type for a field or have them get the basic Object and then use C++'s RTTI to detmine the object type and then let them deal with it. Automtically casting from one type to another on getting is an awkward issue as it's so open ended. Casting between int/float/double is relatively straight forward, but your this there isn't any obvious mapping. Perhaps one could specialize the ValueObject template into a NumbericObject which provides a range of getValueAsInt, getValueAsFloat etc. In terms of setting it is straight forward to explictly assign the type in the method so that it's able to use C++'s automatically casting. For example: node-setUserValuefloat(Height,1.4); Is able to get C++ to cast the 1.4 double into a float so that it creates a ValueObjectfloat object when assigning it to the Object::UserDataContainer::_objectList. Right now my main priority is working out how to provide the IO support and keeping the whole infrastructure simple and straightforward to use, rather than trying to cover all types of usage. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Robert,
This looks pretty straightforward and I agree that less complexity is
good. However a would modify it slightly to support two related
features I have been lobbying for, which are the ability to share
UserDataContainers between osg::Objects, and the ability to subclass a
custom UserDataContainer implementation.
The idea is that there is generally not a 1:1 correlation between the
application entity model and the scene graph. Because of this, one
often wants to be able to share or inherit metadata information, or look
up metadata on the fly to avoid copying large amounts of application
data into the scene graph.
I think it feasible to add one level of indirection without adding too
much complexity. For example:
- Make osg::UserDataContainer a pure abstract class.
class OSG_EXPORT UserDataContainer : public osg::Referenced
{
public:
void addUserObject(Object* owner, Object* obj) = 0;
void setUserObject(Object* owner, unsigned int i, Object* obj) = 0;
void removeUserObject(Object* owner, unsigned int i);
unsigned int getUserObjectIndex(Object* owner, const osg::Object* obj)
const = 0;
unsigned int getUserObjectIndex(Object* owner, const std::string name)
const = 0;
Object* getUserObject(Object* owner, unsigned int i) = 0;
const Object* getUserObject(Object* owner, unsigned int i) const = 0;
Object* getUserObject(Object* owner, const std::string name) = 0;
const Object* getUserObject(Object* owner, const std::string name)
const = 0;
unsigned int getNumUserObjects(Object* owner) const = 0;
};
- Provide a default implementation which doesn't do anything with the owner
field
class OSG_EXPORT DefaultUserDataContainer : public UserDataContainer
{
ref_ptrReferenced _userData;
b DescriptionList _descriptionList;
ObjectList _objectList;
public:
void addUserObject(Object* owner, Object* obj) {
_objectList.push_back(obj);
}
/* etc */
};
- The methods implementated in osg::Object just forward to the container along
with the owner:
void osg::Object::addUserObject(Object* obj) {
if (!_container) {
_container = new osg::DefaultUserDataContainer();
}
_container-addUserObject(this, obj);
}
void osg::Object::setUserObject(Object* owner, unsigned int i, Object*
obj) {
if (!_container) {
_container = new osg::DefaultUserDataContainer();
}
_container-setUserObject(this, i, obj);
}
/* etc */
- osg::Object also gains a couple of new methods:
osg::UserDataContainer* osg::Object::getUserDataContainer();
osg::Object::setUserDataContainer(osg::UserDataContainer*);
Does this seem reasonable?
- Peter
--
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
Re: [osg-users] Meta-data in core OSG - project started
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::vectorstd::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::vectorosg::ref_ptrosg::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_ptrValueContainer 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
Re: [osg-users] Meta-data in core OSG - project started
Hi DJ,
You're welcome! And thank you for exposing your thoughts.
Well, you're right, the problem has always been there. And of course,
removing the container will remove userData and descriptionList. However I
think that a developer removing the container MUST know what (s)he's doing. You
must not blindly remove it hoping userData and descriptionList will be kept.
Maybe this would require additional documentation? And maybe we could provide a
function to clear all but things for backward compatibility? For instance:
/// Empties a container from all but userData and descriptionList, for
backward-compatibility.
void clearValuesButUserDataAndDescriptionList(osg::ValueContainer vc)
{
Iterate over values
if value isn't userData or descriptionList, remove it
}
/// Removes the container of an object and replaces it with a default one, and
also keeps userData and descriptionList, for backward-compatibility.
void removeContainerButKeepUserDataAndDescriptionList(osg::Object o)
{
if (o has no userData nor descriptionList) { Remove ValueContainer from
'o'; return; }
Create a new (default) container
Copy user userData pointer and/or descriptionList from old container to the
new one
Add new container to 'o', replacing the old one
}
But clearly your project may benefit from being ported to the new metadata
system, as our project is currently being. You'll not suddenly gain astonishing
features, but at least you'll have something which will not interfere with
existing 3rd-party meta and/or userData and/or descriptionList.
Maybe we should put this discussion (once finished and summarized) in a v6 of
the document?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- D.J. Caldwell dlcaldwel...@gmail.com a écrit :
Hi Gregoire, Sukender, and everyone,
While writing this email, I have come to the conclusion that I/we do
not really have anything (more) to be concerned about with tying user
data and description list to the meta-data system. If you are
interested in some of the concerns I already had, and that were
further clarified while reviewing the proposed meta-data system, read
on. I appreciate the responses I have received thus far. Again, thanks
for all the hard work! :-)
...here is what I was thinking...
My concern is not so much that the underlying structure will be
unavailable, per se. It is that userData and descriptionList will now
be tied to the meta-data system, with no built in alternatives. With
the proposed implementation, replacing an existing meta-data container
would effectively clear any existing userData or descriptionList.
Further, if the special hooks for exotic types are part of the
container, and that container is not written to handle generic data
such as userData and descriptionList, use of userData/descriptionList
may cause problems.
Really, I am just trying to make sure I/we understand all the
implications of tying userData, descriptionList, and meta-data
together in the same core feature.
Here is one problem scenario that I have some concern about:
[code]
// load some data
osg::Node* p = osgDB::readNodeFile ( ... );
...
p-addDescription ( ... );
...
// if the following third party function calls setValueContainer,
// this destroys any existing userData and/or descriptionList
thirdParty::doSomeWork ( p );
[/code]
In my project, we have been using descriptionList as a work-around to
userData and the fact that each osg::Node is restricted to not more
than one attached instance of userData. I did not want to interfere
with any existing userData generated by geometry and scene files, so I
used descriptionList to store our runtime data, because
descriptionList appears to have no explicit restrictions beyond that
of a std::vector. If a third party function happens to cause the
description list to be cleared after we have added some data to it, we
would lose the data we need to do some of our runtime work.
In reality, the proposed meta-data system does not cause the above
problem scenario; the problem has always been there (the third part
function could have directly called setDescriptions). However, this is
one more way to clear the description list.
I suppose, in the end, there really is no need for my concern. You
propose (or I have inferred) a required interface with specific
guaranteed behavior for writing custom containers; if container
providers follow the rules, userData and descriptionList (or whatever
a client may want to use) will still be supported. As long as no one
takes the opportunity to replace an existing meta-data container
without documenting that this is what they are doing, we should be
fine.
I will review version 5 of your document, and I will give myself some
more time to digest what you have written. I already like what I have
seen, and the more that I think about it, the better understanding I
Re: [osg-users] Meta-data in core OSG - project started
Hi Sergey,
Thank you for the links.
You're right when saying variant causes a lot of issues. I won't bring an
answer about Variant here, but just some points about the current design:
I must say I wondered about adding a support for basic types (conversion
from/to int/string/double...). The question is: which types should be
considered as basic? fundamental types only? string? vectorstring?... Well it
depends on the usage actually. And the problem with a variant, as described in
trac.rtmpd.com, or the one in boost.variant, is that you must know (into OSG)
all the types you'll use beforehand. Which is pretty impossible regarding to
the different uses.
This is why I preferred something very neutral (hence osg::ValueBase). Of
course another problem arises: it's very common to need the type of a ValueBase
to get its (casted) value, or trigger specific code, etc (as specified in
section 3 of the PDF you sent the link). For now, and using current
implementation draft, we wrote a simple (yet very slow) solution with
dynamic_cast:
unsigned int getType(...) {
if (dynamic_castosg::ValueTYPE_1*(p)) return ...;
if (dynamic_castosg::ValueTYPE_2*(p)) return ...;
// etc.
}
This is clearly too slow if you call the function too ofen. Fortunately for us
this seems not critical at all. And this is less memory consuming creating a
TypedValueBase class, storing an integer (for instance) indicating the type.
But this may be useful to some developpers which often ask for the type of a
value. The base class would then look like:
class TypedValueBase : public ValueBase
{
public:
typedef unsigned int ValueType;
ValueType getType() const { return _type; }
protected:
ValueType _type;
};
or
class TypedValueBase : public ValueBase
{
public:
typedef unsigned int ValueType;// Should this be a string?
virtual ValueType getType() const =0;
};
or you may imagine the same virtual methods as Node (className(),
libraryName(), etc...)
Then using this base class you could create, say, TypedValueInt,
TypedValuePotato, etc.
Do you think this should be provided in core OSG alongside (and as an
alternative to) ValueT? Which version of TypedValueBase do you prefer?
Cheers,
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sergey Kurdakov sergey.fo...@gmail.com a écrit :
Hi Sukender,
concerning Variant,
for simple types
something like
http://trac.rtmpd.com/browser/trunk/sources/common/src/utils/misc/variant.cpp
http://trac.rtmpd.com/browser/trunk/sources/common/include/utils/misc/variant.h
http://trac.rtmpd.com/browser/trunk/sources/common/include/utils/misc/variantmap.h
might go,
but it looks like you would like more, then discussion here
http://stackoverflow.com/questions/5319216/implementing-a-variant-class
( esp use of boost variant instead of boost any ) might be of some
use.
My concern though is about speed of dynamic cast ( which is slow ), so
maybe sort of custom rtti ( see example
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=C4231214774C16E32EA2B2C879DAACB3?doi=10.1.1.164.1009rep=rep1type=pdf
) could be used here...
but if custom rtti
here comes to mind http://www.rcs.hu/Articles/RTTI_Part1.htm
http://www.rcs.hu/Articles/RTTI_Part2.htm and then both osgReflection
(now osgIntrospection ) and Wang Rui's reflection wrappers should be
considered as they already have some functionality.
so simple question of variant ( and degree of it's complexity and it's
speed and then maybe serialization of very special variant ) causes a
lot of issues to surface.
Regards
Sergey
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Meta-data in core OSG - project started
Hi Sukender,
for your suggestion
class TypedValueBase : public ValueBase
{
public:
typedef unsigned int ValueType;
ValueType getType() const { return _type; }
protected:
ValueType _type;
};
consider
templatetypename T
struct VarValue{
VarValue(T _t) : m_T(_t){}
typedef T value_type;
T getType() const { return value_type
; }
T m_T;
};
(typename might be needed maybe )
this is so called templated traits trick
as for virtual methods consider this article
http://aigamedev.com/open/highlights/optimize-virtual-functions/ and
mentioned *template method pattern*
many thanks for your efforts - but currently I'm finishing project, so my
replies are somewhat sparse and
maybe lack details and correctness. But it is what I can allow myself now.
Regards
Sergey
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Meta-data in core OSG - project started
Hi Sukender,
while
templatetypename T
struct VarValue{
VarValue(T _t) : m_T(_t){}
typedef T value_type;
T m_T;
};
was correct in my last mail
T getType() const { return value_type; }
was incorrect, still anyway take a look at how such things are done in Ogre
http://www.ogre3d.org/docs/api/html/classOgre_1_1Any.html
Regards
Sergey
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hello Sukender,
In response to your backward compatibility suggestions, I believe clear
documentation is the key, and I believe you all are off to a good start in
that regard.
Inlining the deprecated functions with appropriate comment is a good start
for clear documentation in the source code.
It may be a bit redundant, but attempting to drive the point home for the
user, might I suggest the following type of comment for the deprecated
functions:
[code]
/**
* \deprecated
* note: implemented in terms of meta-data; consider using meta-data directly
... */
[/code]
My current opinion is that the two functions you suggest, as straight
forward as they may be to write correctly, may not be useful enough for the
OSG group at large to justify adding even that small wrinkle of complexity
to the design. userData and descriptionList specific functions will be
deprecated features, and, as such, we should probably actively discourage
continued use. clearValuesButUserDataAndDescriptionList and
removeContainerButKeepUserDataAndDescriptionList might put an undo burden on
clients for the sake of supporting functions that are slotted for removal.
I can already see one or two design alternatives using meta-data for my
project to replace descriptionList. We were able to isolate how and where
we were using descriptionList, so the change for us would thankfully be
fairly straight forward.
On a purely aesthetic note, might I suggest for the sake of consistency
using the same spelling of meta-data, meta data, or metadata in all official
documentation. I can be real nit picky, I know. ;-)
Thanks...
D.J.
On Wed, May 4, 2011 at 9:13 AM, Sergey Kurdakov sergey.fo...@gmail.comwrote:
Hi Sukender,
while
templatetypename T
struct VarValue{
VarValue(T _t) : m_T(_t){}
typedef T value_type;
T m_T;
};
was correct in my last mail
T getType() const { return value_type; }
was incorrect, still anyway take a look at how such things are done in
Ogre
http://www.ogre3d.org/docs/api/html/classOgre_1_1Any.html
Regards
Sergey
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Gregoire, Sukender, and everyone, While writing this email, I have come to the conclusion that I/we do not really have anything (more) to be concerned about with tying user data and description list to the meta-data system. If you are interested in some of the concerns I already had, and that were further clarified while reviewing the proposed meta-data system, read on. I appreciate the responses I have received thus far. Again, thanks for all the hard work! :-) ...here is what I was thinking... My concern is not so much that the underlying structure will be unavailable, per se. It is that userData and descriptionList will now be tied to the meta-data system, with no built in alternatives. With the proposed implementation, replacing an existing meta-data container would effectively clear any existing userData or descriptionList. Further, if the special hooks for exotic types are part of the container, and that container is not written to handle generic data such as userData and descriptionList, use of userData/descriptionList may cause problems. Really, I am just trying to make sure I/we understand all the implications of tying userData, descriptionList, and meta-data together in the same core feature. Here is one problem scenario that I have some concern about: [code] // load some data osg::Node* p = osgDB::readNodeFile ( ... ); ... p-addDescription ( ... ); ... // if the following third party function calls setValueContainer, // this destroys any existing userData and/or descriptionList thirdParty::doSomeWork ( p ); [/code] In my project, we have been using descriptionList as a work-around to userData and the fact that each osg::Node is restricted to not more than one attached instance of userData. I did not want to interfere with any existing userData generated by geometry and scene files, so I used descriptionList to store our runtime data, because descriptionList appears to have no explicit restrictions beyond that of a std::vector. If a third party function happens to cause the description list to be cleared after we have added some data to it, we would lose the data we need to do some of our runtime work. In reality, the proposed meta-data system does not cause the above problem scenario; the problem has always been there (the third part function could have directly called setDescriptions). However, this is one more way to clear the description list. I suppose, in the end, there really is no need for my concern. You propose (or I have inferred) a required interface with specific guaranteed behavior for writing custom containers; if container providers follow the rules, userData and descriptionList (or whatever a client may want to use) will still be supported. As long as no one takes the opportunity to replace an existing meta-data container without documenting that this is what they are doing, we should be fine. I will review version 5 of your document, and I will give myself some more time to digest what you have written. I already like what I have seen, and the more that I think about it, the better understanding I have of the developing situation. Thanks, again... D.J. On Mon, May 2, 2011 at 10:05 AM, Sukender suky0...@free.fr wrote: Hi D.J., hi all, Here is the v5 update! Not a huge thing but we modified it according to our experiments. Check out the [v5] tags in the document. @DJ: Well, as Gregroire said, the methods are always here to access userData and desriptionList, but you cannot access the members directly, as they disapeared. In core OSG, we spotted that there were very few direct accesses. Do you fear this would not be the same for OSG users? @Gregoire: On the right path you are, padawan! ;) Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Gregoire Tarizzo gregoire.tari...@virtuelcity.com a écrit : Hi D.J. , hi all, First, thanks a lot to all, for your feedback and ideas. I’ve been following with a lot of interest your ideas and propositions on this topic and it helped us a lot. The v5 of the documentation will be out soon (likely monday), with more detailed information and the latest changes we made in our implementation. @D.J. About the deprecation of _userData and _descriptions : Well yes, this behaviour is intended. One of the objectives of this meta-data system was to replace _userData and _descriptions from the object and node and by doing so, make it a few bytes lighter when not using any of those, while providing a tool able to handle multiple values from multiple types. Moreover _userData and _descriptions may be removed, but it doesn’t mean that all the _userData and _descriptions methods won’t work anymore. We reforged them so that they use the new metadata system. So hopefully it won’t change anything for the user. One of our first issues was the “protected” access to _userData, meaning we can’t reach the 100% backward compatibility
[osg-users] Meta-data in core OSG - project started
Hi Sukender, concerning Variant, for simple types something like http://trac.rtmpd.com/browser/trunk/sources/common/src/utils/misc/variant.cpp http://trac.rtmpd.com/browser/trunk/sources/common/include/utils/misc/variant.h http://trac.rtmpd.com/browser/trunk/sources/common/include/utils/misc/variantmap.h might go, but it looks like you would like more, then discussion here http://stackoverflow.com/questions/5319216/implementing-a-variant-class ( esp use of boost variant instead of boost any ) might be of some use. My concern though is about speed of dynamic cast ( which is slow ), so maybe sort of custom rtti ( see example http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=C4231214774C16E32EA2B2C879DAACB3?doi=10.1.1.164.1009rep=rep1type=pdf ) could be used here... but if custom rtti here comes to mind http://www.rcs.hu/Articles/RTTI_Part1.htm http://www.rcs.hu/Articles/RTTI_Part2.htm and then both osgReflection (now osgIntrospection ) and Wang Rui's reflection wrappers should be considered as they already have some functionality. so simple question of variant ( and degree of it's complexity and it's speed and then maybe serialization of very special variant ) causes a lot of issues to surface. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi D.J. , hi all, First, thanks a lot to all, for your feedback and ideas. I’ve been following with a lot of interest your ideas and propositions on this topic and it helped us a lot. The v5 of the documentation will be out soon (likely monday), with more detailed information and the latest changes we made in our implementation. @D.J. About the deprecation of _userData and _descriptions : Well yes, this behaviour is intended. One of the objectives of this meta-data system was to replace _userData and _descriptions from the object and node and by doing so, make it a few bytes lighter when not using any of those, while providing a tool able to handle multiple values from multiple types. Moreover _userData and _descriptions may be removed, but it doesn’t mean that all the _userData and _descriptions methods won’t work anymore. We reforged them so that they use the new metadata system. So hopefully it won’t change anything for the user. One of our first issues was the “protected” access to _userData, meaning we can’t reach the 100% backward compatibility if we delete _userData because of the possibility of a direct access to this member w/ using the getter. In the end, we thought that the side effect is not major enough, and easy to deal with (juste replace the direct _userData accesses in Object derived classes by the getUserData() method, and it works fine). 1st post on this mailing list/forum, yay. \o/ Regards,___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Sukender and fellow interested parties,
I've finally had a chance to review your meta-data doc (version 4) to see
what you all have been designing, and how we might be able to use it in our
project.
Overall, I must say the design looks good. I really appreciate the effort
you have put into it.
I do have a few design points you may (not) find interesting, so feel free
to accept/modify/comment/ignore as you see fit (as long as you take credit
for any mods/comments that you make ;-) ). If you think I've misunderstood
something, feel free to give me pointers where I may have gone off track; I
only hope I am not stating the obvious, thereby wasting people's time.
1) By deprecating user data and description lists, and integrating them into
the proposed meta-data system until those interfaces are removed, you have
some major side effects:
a) With the current proposal, replacing a meta-data container destroys
any legacy user data or descriptions that may already be present. If this
is a desirable side effect, so be it, but users should be explicitly made
aware of this side effect.
b) User data and description lists will not be a viable work around
(because they will are deprecated) for users who cannot, or will not,
convert to the new meta-data system and also do not wish to replace any
existing meta-data on a node. They will be forced to use some other means
(probably external) to store their data. Again, if this is a desirable side
effect, so be it.
c) For data base accessors, user data and/or description lists may (not)
be totally inappropriate when choosing the proxy container route; a
meta-data value that holds a proxy container may be preferred. I have
little to know experience with data bases, so others will have more insight
into this sort of thing, but I thought it worth mentioning.
2) I think you might be missing an interface layer that is necessary for the
type system to work for user defined containers that have proxy values,
but do not want to pay the default cost of storing a T value:
[code]
// slight mod from current design
class ValueBase : public Referenced
{
protected:
// do we not need a virtual destructor here, since containers will
// hold ref_ptr to this?
virtual ~ValueBase() {}
};
// type specific interface for getting type specific values into/out of
// containers, without revealing how the value itself is stored here
templatetypename T ValueT : public ValueBase
{
public:
// interface layer needs to able to virtually assign values; copy
// constructors need more detail, so we must go to the most derived
// type for that, and we should be using clone for that anyway
ValueT operator=(const ValueT val)
{ xassign(val.value()); return *this; }
ValueT operator=(const T val) { xassign(val); return *this; }
virtual T value() = 0;
virtual const T value() const = 0;
// const so we can use it anywhere excpet for assignment to this
// value
operator T() const { return value (); }
protected:
// derived types tend to need explicitly defined destructors
virtual ~ValueT() {}
private:
// yes, this is virtual and private, but client code should not be
// calling this unless we provided set methods other than straight
// assignment; the pattern is unusual, but it works
virtual void xassign(const T val) = 0;
};
// renamed from ValueT with slight mods
templateclass T class BasicValue : public ValueTT
{
public:
//virtual const char * className() const;
/** Constructor*/
BasicValue() {}
/** Contructor from T.*/
BasicValue(const T val) { _value = val; }
/** Copy constructor*/
BasicValue(const BasicValueT val) { _value = val._value; }
BasicValue operator=(const T val) { _value = val; return *this; }
BasicValue operator=(const BasicValue val) { _value = val._value;
return *this; }
T value() { return _value; }
const T value() const { return _value; }
/* Implicit conversion */
// see ValueT, above
//operator T() { return _value; }
protected:
/** the stored value*/
T _value;
// derived types tend to need explicitly defined destructors
virtual ~BasicValue() {}
/** overloaded == operators, we have to be extra careful because T type
doesn't necessarily have ==
* overloaded.*/
friend inline bool operator==(const BasicValueT left,const
BasicValueT right){ return left._value==right._value; }
friend inline bool operator==(const T left,const BasicValueT right){
return left==right._value; }
friend inline bool operator==(const BasicValueT left,const T right){
return left._value==right; }
private:
// virtual assignment for use with the interface layer, ValueTT
virtual void xassign(const T val) { _value = T; }
};
[/code]
By forcing users to derive from the interface template, ValueTT, you can
guarantee a common type safe interface for casting inside your generic
meta-data containers, without the expense of storing T
Re: [osg-users] Meta-data in core OSG - project started
Hi, all...
I just realized, if you write your proxy correctly, your original class
ValueT probably works just fine for more exotic types (when T is your
proxy class giving access to the underlying type), without my proposed
interface layer. In fact, for purposes of reference semantics, the original
is probably preferred.
Perhaps I should have read that doc more than three times...
Regardless, I look forward to your comments and the final product.
D.J.
On Fri, Apr 29, 2011 at 11:01 PM, D.J. Caldwell dlcaldwel...@gmail.comwrote:
Hi Sukender and fellow interested parties,
I've finally had a chance to review your meta-data doc (version 4) to see
what you all have been designing, and how we might be able to use it in our
project.
Overall, I must say the design looks good. I really appreciate the effort
you have put into it.
I do have a few design points you may (not) find interesting, so feel free
to accept/modify/comment/ignore as you see fit (as long as you take credit
for any mods/comments that you make ;-) ). If you think I've misunderstood
something, feel free to give me pointers where I may have gone off track; I
only hope I am not stating the obvious, thereby wasting people's time.
1) By deprecating user data and description lists, and integrating them
into the proposed meta-data system until those interfaces are removed, you
have some major side effects:
a) With the current proposal, replacing a meta-data container destroys
any legacy user data or descriptions that may already be present. If this
is a desirable side effect, so be it, but users should be explicitly made
aware of this side effect.
b) User data and description lists will not be a viable work around
(because they will are deprecated) for users who cannot, or will not,
convert to the new meta-data system and also do not wish to replace any
existing meta-data on a node. They will be forced to use some other means
(probably external) to store their data. Again, if this is a desirable side
effect, so be it.
c) For data base accessors, user data and/or description lists may
(not) be totally inappropriate when choosing the proxy container route; a
meta-data value that holds a proxy container may be preferred. I have
little to know experience with data bases, so others will have more insight
into this sort of thing, but I thought it worth mentioning.
2) I think you might be missing an interface layer that is necessary for
the type system to work for user defined containers that have proxy
values, but do not want to pay the default cost of storing a T value:
[code]
// slight mod from current design
class ValueBase : public Referenced
{
protected:
// do we not need a virtual destructor here, since containers will
// hold ref_ptr to this?
virtual ~ValueBase() {}
};
// type specific interface for getting type specific values into/out of
// containers, without revealing how the value itself is stored here
templatetypename T ValueT : public ValueBase
{
public:
// interface layer needs to able to virtually assign values; copy
// constructors need more detail, so we must go to the most derived
// type for that, and we should be using clone for that anyway
ValueT operator=(const ValueT val)
{ xassign(val.value()); return *this; }
ValueT operator=(const T val) { xassign(val); return *this; }
virtual T value() = 0;
virtual const T value() const = 0;
// const so we can use it anywhere excpet for assignment to this
// value
operator T() const { return value (); }
protected:
// derived types tend to need explicitly defined destructors
virtual ~ValueT() {}
private:
// yes, this is virtual and private, but client code should not be
// calling this unless we provided set methods other than straight
// assignment; the pattern is unusual, but it works
virtual void xassign(const T val) = 0;
};
// renamed from ValueT with slight mods
templateclass T class BasicValue : public ValueTT
{
public:
//virtual const char * className() const;
/** Constructor*/
BasicValue() {}
/** Contructor from T.*/
BasicValue(const T val) { _value = val; }
/** Copy constructor*/
BasicValue(const BasicValueT val) { _value = val._value; }
BasicValue operator=(const T val) { _value = val; return *this; }
BasicValue operator=(const BasicValue val) { _value = val._value;
return *this; }
T value() { return _value; }
const T value() const { return _value; }
/* Implicit conversion */
// see ValueT, above
//operator T() { return _value; }
protected:
/** the stored value*/
T _value;
// derived types tend to need explicitly defined destructors
virtual ~BasicValue() {}
/** overloaded == operators, we have to be extra careful because T type
doesn't necessarily have ==
* overloaded.*/
friend inline bool
Re: [osg-users] Meta-data in core OSG - project started
Hi all, this meta system looks very interesting. I started to implement such a system for osgVisual for data management, but it seems that your approach is much more sophisticated and finally allows me to plug in my use cases quite easy. I'm happy that such a framework is developed for OSG. I have cross-read the V4 document, but unfortunately I'm currently too much occupied by my doctoral thesis to add usefull ideas/components. I'll try to stay up to date and maybe can add some comments. Thanks for your effort, it is great work! Best regards from Salzburg, Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=38841#38841 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, hi all,
We're working on impementing the meta-data system. We found that there was very
few feedback, and feel it's a bad sign of inacceptance of it... Anyone?
Peter, when you told about immutability, it was with a database backend in
mind, right? If so, I think it may be better not to have immutable Values.
Indeed, DescriptionList and more generally user data may be mutable. So to get
this database backend wokring properly, I think one should:
- Define a ValueDB, derivate from ValueBase.
- Define a DBProxy, derivate from ComponentContainer (well, we renamed it
ValueContainer to avoid misinterpretation)
- Make DBProxy give ValueDB when getting
- Make ValueDB know DBProxy so that modifying a ValueDB will call appropriate
method in DBProxy
- Make DBProxy also accept ValueT as an input, and convert it to appropriate
SQL/request/whatever
Thoughts?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Sukender suky0...@free.fr a écrit :
Hi all,
From your feedback and our first tests/prototypes, here is the revised
document.
Please comment!
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
- Peter Amstutz peter.amst...@tseboston.com a écrit :
Immutable means cannot be changed. So I mean that the Value
class
should not have a set method and all get methods should be
const.
E.g.
templateT
class Value {
private:
T v;
public:
Value(const T _v) : v(_v) { }
const T get() { return v; }
// type conversion operator, so you can write
// Valueint a(5);
// int b = a;
const T operator T () { return v; }
};
On 4/19/2011 5:46 AM, Sukender wrote:
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant
to
be derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you
mean you preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes. And that's of course easier to write and read.
--
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Sukender, On Wed, Apr 27, 2011 at 3:09 PM, Sukender suky0...@free.fr wrote: We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? I don't have any comments beyond what others have added so I've been happy to sit back and watch the discussion evolve. I have enough other work to think about so rather than get wrapped up in another topic I am deliberately kept my head down so I can keep my brain capacity and time from being too thinly spread. So me being quiet is not in-acceptance or disinterest, but comfort that all those who've been contributing to the thread look to be going in a resonable direction and don't seem to need any guidance from me. Keep up the good work :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Keep up the good work :-) Nice to read it, Robert! ;) And you're right, keep your mind resources for all other important things here! Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Wed, Apr 27, 2011 at 3:09 PM, Sukender suky0...@free.fr wrote: We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? I don't have any comments beyond what others have added so I've been happy to sit back and watch the discussion evolve. I have enough other work to think about so rather than get wrapped up in another topic I am deliberately kept my head down so I can keep my brain capacity and time from being too thinly spread. So me being quiet is not in-acceptance or disinterest, but comfort that all those who've been contributing to the thread look to be going in a resonable direction and don't seem to need any guidance from me. Keep up the good work :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Sukender, I, too, have been following this thread with interest. I have not had the time or resources to go over your documentation, yet, but I hope to do so soon. In my current project, we have adapted the osg::Node::DescriptionList to store some basic run time data at the node level. My hope is that the meta-data system you all are designing will give us a more type safe option that does not require string conversion. Thanks for taking the time and effort to work on this. Even if this turns out not to be the solution I am looking for, I am sure others will be able to leverage it to great effect. D.J. On Wed, Apr 27, 2011 at 10:23 AM, Sukender suky0...@free.fr wrote: Keep up the good work :-) Nice to read it, Robert! ;) And you're right, keep your mind resources for all other important things here! Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Wed, Apr 27, 2011 at 3:09 PM, Sukender suky0...@free.fr wrote: We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? I don't have any comments beyond what others have added so I've been happy to sit back and watch the discussion evolve. I have enough other work to think about so rather than get wrapped up in another topic I am deliberately kept my head down so I can keep my brain capacity and time from being too thinly spread. So me being quiet is not in-acceptance or disinterest, but comfort that all those who've been contributing to the thread look to be going in a resonable direction and don't seem to need any guidance from me. Keep up the good work :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Thanks DJ. I must say the conversion of our project to the new meta-data system is not that instant... Hopefully the code is 99% backward compatible and the use of userData and Description list still work as expected. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - D.J. Caldwell dlcaldwel...@gmail.com a écrit : Hi Sukender, I, too, have been following this thread with interest. I have not had the time or resources to go over your documentation, yet, but I hope to do so soon. In my current project, we have adapted the osg::Node::DescriptionList to store some basic run time data at the node level. My hope is that the meta-data system you all are designing will give us a more type safe option that does not require string conversion. Thanks for taking the time and effort to work on this. Even if this turns out not to be the solution I am looking for, I am sure others will be able to leverage it to great effect. D.J. On Wed, Apr 27, 2011 at 10:23 AM, Sukender suky0...@free.fr wrote: Keep up the good work :-) Nice to read it, Robert! ;) And you're right, keep your mind resources for all other important things here! Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Robert Osfield robert.osfi...@gmail.com a écrit : Hi Sukender, On Wed, Apr 27, 2011 at 3:09 PM, Sukender suky0...@free.fr wrote: We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? I don't have any comments beyond what others have added so I've been happy to sit back and watch the discussion evolve. I have enough other work to think about so rather than get wrapped up in another topic I am deliberately kept my head down so I can keep my brain capacity and time from being too thinly spread. So me being quiet is not in-acceptance or disinterest, but comfort that all those who've been contributing to the thread look to be going in a resonable direction and don't seem to need any guidance from me. Keep up the good work :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
On 4/27/2011 8:41 AM, D.J. Caldwell wrote: Hi Sukender, I, too, have been following this thread with interest. I have not had the time or resources to go over your documentation, yet, but I hope to do so soon. Likewise, I'm interested, and I trust you know what you're doing. At the moment, i don't have the resources to extensively read and comment, but I skimmed the proposal and it looked promising to me. -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Digital Imaging. OpenGL. Scene Graphs. GIS. GPS. Training. Consulting. Contracting. There is no Truth. There is only Perception. To Perceive is to Exist. - Xen ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Sorry about that, you sent out the previous email on the weekend and I didn't have a chance to look at it; when Monday rolled around I had forgotten about it. Regarding the Value class, I think I understand the difference of opinion a little better. Let me present both sides. // Option A. Value types are osg::Referenced and mutable osg::ref_ptrValueint v = container-getMetaint(foo); assert(v-get() == 3); v-set(5); assert(v-get() == 5); - A value object can be held by many nodes. Changing it in once places affects all nodes. - Similar to how other reference counted elements of the scene graph work, e.g. osg::Uniform - ValueT will probably need a parent list to track its owners - Awkward to map metadata values onto a database. In addition to getMeta() and setMeta(), must derive from ValueT or come up with a callback interface to tie to the data store. - Potential for race conditions if a thread changes the contents of value while another thread is using it // Option B. Value types are not refcounted and immutable Valueint v = container-getMetaint(foo); assert(v == 3); node-setMetaint(foo, 6); assert(v == 3); assert(node-getMetaint(foo) == 5); - A value object cannot be held by multiple nodes. If you want to logically share a value across nodes, must store a pointer or id into a separate table as the value. - Similar to non-reference counted elements of the scene graph. - ValueT can be very simple and doesn't need to track or backreference anything. - Straightforward to map to a database, only need to implement getMeta() and setMeta() - No race condition concerns. Laying it out like this, I could support a design going either way. However my instinct is to prefer immutable data structures as a general rule as they tend to reduce programming errors (especially when threads are involved). I also think the metadata facility should be simple and easy to extend by implementing a new MetadataContainer class rather than putting in complicated hook/callback/proxy mechanisms that try to handle everything. I think the next step should be to put together some header files / class definitions so that we can discuss the proposed API in specifics. - Peter On 4/27/2011 10:09 AM, Sukender wrote: Hi Peter, hi all, We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? Peter, when you told about immutability, it was with a database backend in mind, right? If so, I think it may be better not to have immutable Values. Indeed, DescriptionList and more generally user data may be mutable. So to get this database backend wokring properly, I think one should: - Define a ValueDB, derivate from ValueBase. - Define a DBProxy, derivate from ComponentContainer (well, we renamed it ValueContainer to avoid misinterpretation) - Make DBProxy give ValueDB when getting - Make ValueDB know DBProxy so that modifying a ValueDB will call appropriate method in DBProxy - Make DBProxy also accept ValueT as an input, and convert it to appropriate SQL/request/whatever Thoughts? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ --- -- 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
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, Your analysis seems fine. However, I must add a precision: In the current design, there is a ValueBase class (actually an empty class derived from Referenced). This way it's a bit easier dealing with values as the base class is not templated. Well, not something enough to change your mind! :-) I understand your choice, but fear that simple uses may be not straightforward to understand for OSG beginners, or simply for OSG users that don't want/need to have complex systems. So my feeling is better a simple thing that may be complexified by advanced users, even if it's a bit difficult, rather than a less straightforward system. As an advanced user, it's a frustration and heartbreak to say okay, let's go for a system with less features, but there will always be more beginners than experts... don't you think? However I don't wan't the system to be tied exclusively to simple uses only. Yes, having a database backend may not be that simple, but I want this to be possible. For instance, we're currently coding first things and found it was a good thing to let the container know about its parent objects for this DB backend. So the Object::setValueContainer() looks like: tell the current container we're detatching replace the current container with the new one tell the new container we're attaching I guess some little things like this may help creating a DB backend. And after all, why not having an osgMySQL or osgPostGre later on, as both an out-the-box default DB backend and a model for other ones? BTW, I think next steps on our side are: 1. Finish the first implementation (almost done) 2. Convert our project to use these new metas, to check everything goes fine. 3. Debug 4. Send OSG modified files on the mailing list (osg-users) for a first review. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : Sorry about that, you sent out the previous email on the weekend and I didn't have a chance to look at it; when Monday rolled around I had forgotten about it. Regarding the Value class, I think I understand the difference of opinion a little better. Let me present both sides. // Option A. Value types are osg::Referenced and mutable osg::ref_ptrValueint v = container-getMetaint(foo); assert(v-get() == 3); v-set(5); assert(v-get() == 5); - A value object can be held by many nodes. Changing it in once places affects all nodes. - Similar to how other reference counted elements of the scene graph work, e.g. osg::Uniform - ValueT will probably need a parent list to track its owners - Awkward to map metadata values onto a database. In addition to getMeta() and setMeta(), must derive from ValueT or come up with a callback interface to tie to the data store. - Potential for race conditions if a thread changes the contents of value while another thread is using it // Option B. Value types are not refcounted and immutable Valueint v = container-getMetaint(foo); assert(v == 3); node-setMetaint(foo, 6); assert(v == 3); assert(node-getMetaint(foo) == 5); - A value object cannot be held by multiple nodes. If you want to logically share a value across nodes, must store a pointer or id into a separate table as the value. - Similar to non-reference counted elements of the scene graph. - ValueT can be very simple and doesn't need to track or backreference anything. - Straightforward to map to a database, only need to implement getMeta() and setMeta() - No race condition concerns. Laying it out like this, I could support a design going either way. However my instinct is to prefer immutable data structures as a general rule as they tend to reduce programming errors (especially when threads are involved). I also think the metadata facility should be simple and easy to extend by implementing a new MetadataContainer class rather than putting in complicated hook/callback/proxy mechanisms that try to handle everything. I think the next step should be to put together some header files / class definitions so that we can discuss the proposed API in specifics. - Peter On 4/27/2011 10:09 AM, Sukender wrote: Hi Peter, hi all, We're working on impementing the meta-data system. We found that there was very few feedback, and feel it's a bad sign of inacceptance of it... Anyone? Peter, when you told about immutability, it was with a database backend in mind, right? If so, I think it may be better not to have immutable Values. Indeed, DescriptionList and more generally user data may be mutable. So to get this database backend wokring properly, I think one should: - Define a ValueDB, derivate from ValueBase. - Define a DBProxy, derivate from ComponentContainer (well, we renamed it ValueContainer to avoid misinterpretation) - Make DBProxy give ValueDB when getting - Make ValueDB know DBProxy so that
[osg-users] Meta-data in core OSG - project started
Hi Sukender, while not directly, but very related project is http://sourceforge.net/apps/mediawiki/delta3d-extras/index.php?title=DtEntity take a look, maybe few ideas could be used. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Sergey, Thanks for the link. However I think the entity thing is far more high level than just metas. Are you thinking about something specific metas should support? If so, I would certainly try to insert the requirements. Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Sergey Kurdakov sergey.fo...@gmail.com a écrit : Hi Sukender, while not directly, but very related project is http://sourceforge.net/apps/mediawiki/delta3d-extras/index.php?title=DtEntity take a look, maybe few ideas could be used. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Meta-data in core OSG - project started
Hi Sukender, However I think the entity thing is far more high level than just metas. that is correct. still there is need to assemble metas as objects into something useful and also exchange info ( message system ). this functionality might be a separate addition, but it's presence ( or considering it's use with metas; I'm not sure, but it might add some additional fields, methods etc ) will greatly extend 'use' cases to jump start to apply your metas in projects. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
I think the metadata system under discussion will be useful for associating scene graph nodes with their owner entities. This is necessary for various scene-graph oriented operations like picking, custom culling, etc that need to refer back to your application domain entities . You certainly could use it to store your entity components, but that should be up to the user. I think we need to be careful to avoid scope creep. This discussion does bring up one related issue, though. Regarding serialization, I had been thinking that the metadata system should only be allowed to contain data that can be safely serialized. I realize now that is wrong, for precisely this issue that the metadata system will be used to hold pointers to application domain entities that are opaque to the serialization system. Peter On 4/20/2011 8:30 AM, Sergey Kurdakov wrote: Hi Sukender, However I think the entity thing is far more high level than just metas. that is correct. still there is need to assemble metas as objects into something useful and also exchange info ( message system ). this functionality might be a separate addition, but it's presence ( or considering it's use with metas; I'm not sure, but it might add some additional fields, methods etc ) will greatly extend 'use' cases to jump start to apply your metas in projects. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter and Sergey, Well for now serialization of userData is made blindly. I guess unsafe things will be serialized the same way. And yes, I guess metadata will be a base for more applications, but as long as there is no hard requirement in the basement, I don't think about coding things towards actor/entities management in a first implementation. Don't you think, Sergey? Cheers, Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : I think the metadata system under discussion will be useful for associating scene graph nodes with their owner entities. This is necessary for various scene-graph oriented operations like picking, custom culling, etc that need to refer back to your application domain entities . You certainly could use it to store your entity components, but that should be up to the user. I think we need to be careful to avoid scope creep. This discussion does bring up one related issue, though. Regarding serialization, I had been thinking that the metadata system should only be allowed to contain data that can be safely serialized. I realize now that is wrong, for precisely this issue that the metadata system will be used to hold pointers to application domain entities that are opaque to the serialization system. Peter On 4/20/2011 8:30 AM, Sergey Kurdakov wrote: Hi Sukender, However I think the entity thing is far more high level than just metas. that is correct. still there is need to assemble metas as objects into something useful and also exchange info ( message system ). this functionality might be a separate addition, but it's presence ( or considering it's use with metas; I'm not sure, but it might add some additional fields, methods etc ) will greatly extend 'use' cases to jump start to apply your metas in projects. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Meta-data in core OSG - project started
Hi Sukender in a first implementation. OK, just maybe browse mentioned code and related articles (linked from that page ) for inspirations. Regards Sergey ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant to be
derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you mean you
preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes. And that's of course easier to write and read.
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Peter Amstutz peter.amst...@tseboston.com a écrit :
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly converted to:
addMeta(std::string(myMeta), Valueint(5));
Two considerations:
- There is some copying involved, which might be undesirable for
large
arrays. C++ 2011 move constructors are intended to solve this
problem
in general, but it's unlikely that OSG compatibility requirements
will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for ValueT must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new ValueT(v).
On a related note, my preference would be for the ValueT class to
be
immutable so that you are required to set metadata values through the
API rather than poking ValueT objects directly. This is necessary
if
you want to support alternate backing stores which don't use ValueT
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this
will force you to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
--
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
hmmm...
Why did you write
templateT void addMeta(const std::string, const ValueT v);
?
Wouldn't this be simpler:
templateT void addMeta(const std::string, const T v);
?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
- Peter Amstutz peter.amst...@tseboston.com a écrit :
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly converted to:
addMeta(std::string(myMeta), Valueint(5));
Two considerations:
- There is some copying involved, which might be undesirable for
large
arrays. C++ 2011 move constructors are intended to solve this
problem
in general, but it's unlikely that OSG compatibility requirements
will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for ValueT must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new ValueT(v).
On a related note, my preference would be for the ValueT class to
be
immutable so that you are required to set metadata values through the
API rather than poking ValueT objects directly. This is necessary
if
you want to support alternate backing stores which don't use ValueT
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this
will force you to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight cross-platform game engine -
http://pvle.sourceforge.net/
--
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
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
On 4/19/2011 5:49 AM, Sukender wrote:
hmmm...
Why did you write
templateT void addMeta(const std::string, const ValueT v);
?
Wouldn't this be simpler:
templateT void addMeta(const std::string, const T v);
?
You're right, that is confusing. Here's a better way to compare the
alternatives:
templateT void addMeta(const std::string, const ValueT v) {
// Supports v as a subclass of ValueT
ValueT* localcopy = v.clone();
}
templateT void addMeta(const std::string, const T v) {
// Can only customize ValueT through template specialization
ValueT* localcopy = new ValueT(v);
}
--
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
Re: [osg-users] Meta-data in core OSG - project started
Immutable means cannot be changed. So I mean that the Value class
should not have a set method and all get methods should be const. E.g.
templateT
class Value {
private:
T v;
public:
Value(const T _v) : v(_v) { }
const T get() { return v; }
// type conversion operator, so you can write
// Valueint a(5);
// int b = a;
const T operator T () { return v; }
};
On 4/19/2011 5:46 AM, Sukender wrote:
Hi Peter,
Okay, we'll certainely try your ideas. I guess ValueBase is meant to be
derived, but ValueT isn't.
However, I'm not sure I understand the immutable thing. Do you mean you
preference goes to
function( someParam )
rather than
function( ValueSomeType(someParam) )
?
If so, yes. And that's of course easier to write and read.
--
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
Re: [osg-users] Meta-data in core OSG - project started
Hi JS, About other serializers (Collada, FBX...), I guess it would be nice using the OSG serialization (as you say), or a default/fallback one. Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit : Hi Sukender, Actually I hoped someone would help us on the serialization subject! And yes, I guess new serializers may help. I think so, I haven't used them that much but from the description they seem simple to use, and as long as the class you want to save is serializable then when the osg::Object serializes itself it can serialize all its metadata at the same time. But what about formats supporting metas? It may be helpful to add somewhere a callback/serializer/anything, which may be called by plugins to convert from/to a string representation when not handled natively. No? Ah, so you're talking about saving to formats other than .osgt/.osgb right? In that case perhaps the same serializers can be used to serialize the metadata, and then put that in a string inside metadata of the other format file. And then when reading you just check if one of the metadata in the file corresponds to some OSG-serialized data, and deserialize it. That could work. And if the format has additional data that OSG doesn't know about, but which the reader might want to store as metadata in the OSG nodes when reading the file (like the recent discussion about OpenFlight Surface Material Codes), the ReaderWriter can easily add metadata when reading too. But I think perhaps loading/saving metadata to/from OSG-native formats would be enough for now... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
You could use an implicit constructor, e.g.
templatetypename T
class Value {
Value(T);
Value(const ValueT);
};
class Valueint;
templateT
void addMeta(const std::string, const ValueT v) {
ValueT* localcopy = new ValueT(v);
}
so the function call:
addMeta(myMeta, 5);
is implicitly converted to:
addMeta(std::string(myMeta), Valueint(5));
Two considerations:
- There is some copying involved, which might be undesirable for large
arrays. C++ 2011 move constructors are intended to solve this problem
in general, but it's unlikely that OSG compatibility requirements will
allow the use of C++ 2011 features for a while.
- The way it is described here, any customization for ValueT must
occur through template specialization, rather than subclassing. To
support subclassing, use a clone() method instead of new ValueT(v).
On a related note, my preference would be for the ValueT class to be
immutable so that you are required to set metadata values through the
API rather than poking ValueT objects directly. This is necessary if
you want to support alternate backing stores which don't use ValueT
objects in the backend at all.
- Peter
On 4/15/2011 11:10 AM, Sukender wrote:
Hi Peter,
Thanks... but what for the addMetaT()?
I mean it's okay having a addMeta(string, ValueBase *), but this will force
you to write
o-addMeta( myMeta, new Valueint(5) );
instead of simply
o-addMeta( myMeta, 5 );
which could be nice. Any idea?
Sukender
PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/
--
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
Re: [osg-users] Meta-data in core OSG - project started
My initial impression is that this seems pretty well thought out, but a little incomplete. Some comments: - The ComponentContainer interface is lacking a way to iterate over all values. - The add/find/delete methods on ComponentContainer should take the owner osg::Object as a parameter. This is necessary if you want to share a single ComponentContainer instance across many nodes, for the case where the ComponentContainer is actually a front end to a separate data store. - For serialization, storing simple value types is pretty straightforward. The harder part is dealing with compound types (structs/classes) and/or containers (map/vector). Perhaps there is a way to leverage osgIntrospection? On 4/15/2011 6:30 AM, Sukender wrote: [cross-post osg-users/osg-submissions] Hi Robert, hi all, We often discussed about handling name-value pairs in core OSG. Now it's time for action! Grégoire Tarizzo and I wrote a first specification document about a metadata system. We would like you (I mean all those interested in the subject) to review it and give your feeling and feedback. Please take this document as an advanced proposal. We *WILL* for sure code a first version of the meta-data system. But even if we tried to cover most aspects and most usages, wee need you to ensure this submission to be widely accepted. Thank you very much. Happy reading! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, - For serialization, storing simple value types is pretty straightforward. The harder part is dealing with compound types (structs/classes) and/or containers (map/vector). Perhaps there is a way to leverage osgIntrospection? I think the new serializers make it simple to make new classes serializable... If the requirement is simply that a class added as metadata needs to be serializable that way, it would take care of that problem right? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, Well observed. We'll add methods to iterate and a pointer to object. But we just spotted a flaw in our design: we wrote some virtual templated methods (which is impossible of course)... Any idea on how to return a T* in ComponentContainer::findFirstMeta()? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : My initial impression is that this seems pretty well thought out, but a little incomplete. Some comments: - The ComponentContainer interface is lacking a way to iterate over all values. - The add/find/delete methods on ComponentContainer should take the owner osg::Object as a parameter. This is necessary if you want to share a single ComponentContainer instance across many nodes, for the case where the ComponentContainer is actually a front end to a separate data store. - For serialization, storing simple value types is pretty straightforward. The harder part is dealing with compound types (structs/classes) and/or containers (map/vector). Perhaps there is a way to leverage osgIntrospection? On 4/15/2011 6:30 AM, Sukender wrote: [cross-post osg-users/osg-submissions] Hi Robert, hi all, We often discussed about handling name-value pairs in core OSG. Now it's time for action! Grégoire Tarizzo and I wrote a first specification document about a metadata system. We would like you (I mean all those interested in the subject) to review it and give your feeling and feedback. Please take this document as an advanced proposal. We *WILL* for sure code a first version of the meta-data system. But even if we tried to cover most aspects and most usages, wee need you to ensure this submission to be widely accepted. Thank you very much. Happy reading! Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi J-S, Actually I hoped someone would help us on the serialization subject! And yes, I guess new serializers may help. But what about formats supporting metas? It may be helpful to add somewhere a callback/serializer/anything, which may be called by plugins to convert from/to a string representation when not handled natively. No? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com a écrit : Hi Peter, - For serialization, storing simple value types is pretty straightforward. The harder part is dealing with compound types (structs/classes) and/or containers (map/vector). Perhaps there is a way to leverage osgIntrospection? I think the new serializers make it simple to make new classes serializable... If the requirement is simply that a class added as metadata needs to be serializable that way, it would take care of that problem right? J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Put the dynamic_castT inside the method. On 4/15/2011 10:53 AM, Sukender wrote: Hi Peter, Well observed. We'll add methods to iterate and a pointer to object. But we just spotted a flaw in our design: we wrote some virtual templated methods (which is impossible of course)... Any idea on how to return a T* in ComponentContainer::findFirstMeta()? Sukender -- 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
Re: [osg-users] Meta-data in core OSG - project started
Hi Peter, Thanks... but what for the addMetaT()? I mean it's okay having a addMeta(string, ValueBase *), but this will force you to write o-addMeta( myMeta, new Valueint(5) ); instead of simply o-addMeta( myMeta, 5 ); which could be nice. Any idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ - Peter Amstutz peter.amst...@tseboston.com a écrit : Put the dynamic_castT inside the method. On 4/15/2011 10:53 AM, Sukender wrote: Hi Peter, Well observed. We'll add methods to iterate and a pointer to object. But we just spotted a flaw in our design: we wrote some virtual templated methods (which is impossible of course)... Any idea on how to return a T* in ComponentContainer::findFirstMeta()? Sukender -- 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Meta-data in core OSG - project started
Hi Sukender, Actually I hoped someone would help us on the serialization subject! And yes, I guess new serializers may help. I think so, I haven't used them that much but from the description they seem simple to use, and as long as the class you want to save is serializable then when the osg::Object serializes itself it can serialize all its metadata at the same time. But what about formats supporting metas? It may be helpful to add somewhere a callback/serializer/anything, which may be called by plugins to convert from/to a string representation when not handled natively. No? Ah, so you're talking about saving to formats other than .osgt/.osgb right? In that case perhaps the same serializers can be used to serialize the metadata, and then put that in a string inside metadata of the other format file. And then when reading you just check if one of the metadata in the file corresponds to some OSG-serialized data, and deserialize it. That could work. And if the format has additional data that OSG doesn't know about, but which the reader might want to store as metadata in the OSG nodes when reading the file (like the recent discussion about OpenFlight Surface Material Codes), the ReaderWriter can easily add metadata when reading too. But I think perhaps loading/saving metadata to/from OSG-native formats would be enough for now... J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com http://www.cm-labs.com/ http://whitestar02.dyndns-web.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
