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
