Re: [osg-users] Node::Description into a generalized property mechanism?
Hi Chris, On Mon, Nov 30, 2009 at 5:59 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: Robert Osfield wrote: Isn't this breaking all existing code that uses UserData/Description though? No, no user code need be change, you can hide all the internal implementation details via the methods that access getUserData and getDescriptions(). What would change as far as the user is concerned is that we add extra methods that access other data elements in the CompositeUserData strucutre. Let me toss back what I think you're proposing. We create a new class called something like UserPropertySet (this is my name for what you called CompositeUserData). This thing has a container for storing some collection of heterogeneous things: strings, floats, maybe even ref_ptrs to things?(I don't know how the ref_ptr aspect would work, but it seems people wish to associate all sorts of things with their Nodes.) The container uses a key/value map, so you can ask for a thing by key. To support the existing Description API, we use string-type things in the container, with a unique-namespace key name like osg internal Description or something. We either permit multiple items with the same key string (so we can have multiple Description entries), or we have to name each Description entry uniquely osg internal Description #1 osg internal Description #245, ... and then find a way to query for all keys that have a unique prefix osg internal Description #. I'm just brainstorming here, so don't take offense at my potential ignorance. it odes sound like a lot of us need to hang diverse data off our Nodes and have been constrained by this. Comments? The existing style UserData and Descriptions could be stored in the exactly the same way as they are now, only shifted into the CompositeUserData structure. The additional new key based stored could be added alongside these. What kind of container can do this for us, and sort out the diverse types we might cram in there, and find entities by their key name? The key to making the transition seamlessly would be to not have one data structure in the new container but several for the different purposes. Since the data structure is only ever created when needed the fact that it has some extra members that aren't used in all cases won't cause too my in memory bloat. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into a generalized property mechanism?
Hi Paul, On Mon, Nov 30, 2009 at 8:23 PM, Paul Martz pma...@skew-matrix.com wrote: Chris 'Xenon' Hanson wrote: Isn't this breaking all existing code that uses UserData/Description though? It's not as bad as you might think. If someone were to add CompositeUserData to OSG, they'd need to port all (internal) OSG code to use the new system. External apps that use UserData would not be compatible with the new system until their authors take the time to port, but that's not really a problem, as it's no worse of a situation than we have right now. I'll also add that this would not be the first time OSG has had a non-backwards compatible change (parameters to the draw callback that changed in the 2.0 release being the other change that comes to mind in recent memory), and everyone lived through that :-) . In this case I believe we could keep the compatibility of the API, but the binary compatibility would be broken. To keep compatibility we'd need to retain the s/getUserData() and the Description methods as is, and just add the new methods for the new data structures alongside these. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into a generalized property mechanism?
Hi Robert, Chris, Paul, On 1/12/09 10:45 AM, Robert Osfield wrote: The existing style UserData and Descriptions could be stored in the exactly the same way as they are now, only shifted into the CompositeUserData structure. The additional new key based stored could be added alongside these. This sounds like a good solution, it keeps API compatibility but only stores one object instead of _userData/_descriptions in every Object/Node created. And the getters/setters would divert the call to the CompositeUserData instead, right? This would work nicely for my problem of attaching image specific data to osg::Image in the loader (as long as CompositeUserData provides some sort of key/value storage). As mentioned earlier osgDB::Options (derived from osg::Object) has getters/setters for PluginData as well. I imagine these could use the same mechanism as well? And getOptionString() too? So many birds with one stone :-) Cheers, /ulrich ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into a generalized property mechanism?
Ulrich Hertlein wrote: This sounds like a good solution, it keeps API compatibility but only stores one object instead of _userData/_descriptions in every Object/Node created. This sounds good. I had forgotten that access to UserData was only through the set/get API. Perfect. So many birds with one stone :-) Ulrich, do you have a sense of how this should be done? I don't know if I have a lot of time to work on it right now (starting a new project already), but I can try to help. I could sketch out some architecture and maybe some prototypes in my spare time. Robert said: The key to making the transition seamlessly would be to not have one data structure in the new container but several for the different purposes. Since the data structure is only ever created when needed the fact that it has some extra members that aren't used in all cases won't cause too my in memory bloat. I'm sort of thinking out loud, on (e-)paper here, so feel free to shoot holes in this design: We design a class called something like CompositeUserData (I dislike this name, and prefer something like UserPropertiesCollection). It is allocated only when requested by one of the UserData/Description/Property APIs. In it is simply a container (STL map?) of some new class UserProperty. UserProperty could either be an abstract base class with a derived implementation for each property type (UserData pointer, Description string, float, etc). Or, it could be a concrete implementation itself of a single class with a member or members that can store any of the possible data types (I think Visual Basic had something called a Variant http://en.wikipedia.org/wiki/Variant_type ). I don't have any preference either way, so perhaps others who have a dog in this race might comment on their feelings for the architecture. A new API can be added like setUserProperty(keyname, SOME_TYPE, value); and value = getUserProperty(keyname, SOME_TYPE); Not sure if SOME_TYPE is a string or an enum. We can prevent key name collisions between types, and avoid considering the whole issue of using getUserProperty with the wrong TYPE by name-manging the type into the actual keyname used to store the property. So you could set a STRING of keyname foo and a FLOAT of keyname foo and they would co-exist because they're actually stored as fooSTRING and fooFLOAT. In the same way, we can implement the existing UserData and Description APIs with specialized types like DESC and UDATA, so that they won't collide with the generalized API. The existing Description API seems to respect the order of the Descriptions and existing code might rely on that, so they'd probably be stored with key names like DESC1, DESC2, etc to preserve the order. Comments heartily requested. Cheers, /ulrich -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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] Node::Description into a generalized property mechanism?
Hi Chris,
have you noticed the Suggestion: Add components in nodes (aggregation) thread from
around 29/10/2009? It deals with something similar, namely to introduce something like a
osg::KeyValueMap (derived from osg::Referenced) that can be attached to osg::Objects as
user-data. (These could also serialize to and from files.)
I would also like having a general purpose key/value object so that loaders can attach
data to images for example.
osgDB::Options could use this as well instead of getOptionsString() (which is used by
heaps of plugins that do a find('myOption') on it) and getPluginData() (which is a
string-void* map).
Of course this doesn't yet solve your problem with there being only one user-data field.
The problem I see with adding a new meta-data field to objects is what happens with name
conflicts when two plugins/programs want to use the same 'key' name? In that case we'd
need to introduce namespaces (like a map of string-KeyValueMap) so that each plugin can
have its own key/value map?
Thoughts?
/ulrich
On 30/11/09 5:09 AM, Chris 'Xenon' Hanson wrote:
Mattias Helsing wrote:
Is there a reason to why you don't use setUserData(osg::Referenced*) ?
If you provide the proper read/write routines for your osg::Referenced
derived class it would also persist across .osg file writes/reads.
Because there's only one UserData, and in my library code that I might share
with
others, I try to avoid taking exclusive use of some asset that others might be
used in
their application code.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into a generalized property mechanism?
Chris 'Xenon' Hanson wrote: Mattias Helsing wrote: Hi Chris, Is there a reason to why you don't use setUserData(osg::Referenced*) ? If you provide the proper read/write routines for your osg::Referenced derived class it would also persist across .osg file writes/reads. Because there's only one UserData, and in my library code that I might share with others, I try to avoid taking exclusive use of some asset that others might be used in their application code. I find UserData rather limited for this reason as well. I support a system like this, but am reluctant to take the time to code a change to core OSG if it is likely to be rejected. For the records, I suggested a similar map idea back in about 2004 shortly after I started using OSG. At the time, I was told just use UserData and set up some kind of composite system to store multiple data. Unfortunately, that doesn't work with other OSG code that is not under my control. I'd be glad to implement something like this in osgWorks.googlecode.com, but it would have to ride on UserData rather than be a part of core OSG, which would put it in conflict with any other code that already uses UserData, thereby rendering it pretty much useless. -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into a generalized property mechanism?
Paul Martz wrote: data. Unfortunately, that doesn't work with other OSG code that is not under my control. I'd be glad to implement something like this in osgWorks.googlecode.com, but it would have to ride on UserData rather than be a part of core OSG, which would put it in conflict with any other code that already uses UserData, thereby rendering it pretty much useless. Yeah, this is my worry. Let's say osgOcean used UserData. And then osgBullet used UserData. Now, you cannot use osgOcean and osgBullet together because they both want UserData to themselves. I am ok using UserData in my actual apps, but in any code I might share with others, I refrain from stealing it, as I'm sure everyone wants it for their app-side code. If we came up with a system like Ulrich proposes, perhaps it would be worthy enough to merit a change to the core to support it? It seems like if we're worried about bloating the memory footprint of the base Object class, then it might be worth considering incorporating the Description API into the design, so that the new design could use the space already dedicated to Description, but in some sort of heterogeneous rather than homogeneous container. I don't know how this would be done, but I imagine we could keep the existing Description API unchanged for code that uses it, without breaking anything. -Paul -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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] Node::Description into a generalized property mechanism?
Hi Chris, Paul, Ulrich, I won't dive in to much right now as I have enough other topics swishing around in my skull to keep me occupied, but a few general notes. Description kinda bloat osg::Node already, I would like to reduce this bloat and stream line the base classes even more ;-) I would also like generalize UserData but... not use any more than the present pointer that we already have in place, don't forget we need to aim for less bloat not more... All is not lost though... you just have to be a bit more creative :-) My thought was that you could possibly create a CompositeUserData or similar class that you attach as the via the present _userData pointer when you need the extra services such as description, user data accessed via int/string descriptors etc. Such as scheme could be hidden by accessors methods in the base class that only even attach the full blow CompositeUserData when actual data is attached to the object. Since most object in the scene never have any UserData or descriptions it does feel like an efficient way to reduce bloat whilst offer more flexible extensions. Perhaps other data could also be move out the base classes this way too... Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into a generalized property mechanism?
Robert Osfield wrote: Description kinda bloat osg::Node already, I would like to reduce this bloat and stream line the base classes even more ;-) I would also like generalize UserData but... not use any more than the present pointer that we already have in place, don't forget we need to aim for less bloat not more... My thought was that you could possibly create a CompositeUserData or similar class that you attach as the via the present _userData pointer when you need the extra services such as description, user data accessed via int/string descriptors etc. Such as scheme could be hidden by accessors methods in the base class that only even attach the full blow CompositeUserData when actual data is attached to the object. Isn't this breaking all existing code that uses UserData/Description though? Let me toss back what I think you're proposing. We create a new class called something like UserPropertySet (this is my name for what you called CompositeUserData). This thing has a container for storing some collection of heterogeneous things: strings, floats, maybe even ref_ptrs to things?(I don't know how the ref_ptr aspect would work, but it seems people wish to associate all sorts of things with their Nodes.) The container uses a key/value map, so you can ask for a thing by key. To support the existing Description API, we use string-type things in the container, with a unique-namespace key name like osg internal Description or something. We either permit multiple items with the same key string (so we can have multiple Description entries), or we have to name each Description entry uniquely osg internal Description #1 osg internal Description #245, ... and then find a way to query for all keys that have a unique prefix osg internal Description #. I'm just brainstorming here, so don't take offense at my potential ignorance. it odes sound like a lot of us need to hang diverse data off our Nodes and have been constrained by this. Comments? What kind of container can do this for us, and sort out the diverse types we might cram in there, and find entities by their key name? Robert. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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] Node::Description into a generalized property mechanism?
Hi Chris, Is there a reason to why you don't use setUserData(osg::Referenced*) ? If you provide the proper read/write routines for your osg::Referenced derived class it would also persist across .osg file writes/reads. Mattias On Sun, Nov 29, 2009 at 11:10 PM, Chris 'Xenon' Hanson xe...@alphapixel.com wrote: I'm looking for a way to annotate nodes with numeric information at runtime. The data need not be stored during scenegraph writes, but I don't mind if it is. I've used the Description before for similar purposes, but you can't precisely and reversibly store a floating-point value in a string. I'm considered extending the Description API to support storing, and search/retrieving typed key=value pairs (MYVALUE_FP, 3.14159265) in the description container. Non-text-compatible types like floats/doubles would be stored by converting the FP value to the actual binary value, then encoding that binary value as text, either as decimal, hex, or base64. Is there already a good way to do this, or is this a technique that others would find useful in core OSG? -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node::Description into a generalized property mechanism?
Mattias Helsing wrote: Hi Chris, Is there a reason to why you don't use setUserData(osg::Referenced*) ? If you provide the proper read/write routines for your osg::Referenced derived class it would also persist across .osg file writes/reads. Because there's only one UserData, and in my library code that I might share with others, I try to avoid taking exclusive use of some asset that others might be used in their application code. -- Chris 'Xenon' Hanson, omo sanza lettere Xenon AlphaPixel.com PixelSense Landsat processing now available! http://www.alphapixel.com/demos/ 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
