Hi Paul, Thanks for this explanation about identifying nodes. Actually we also implemented a node identification using child index... However I did not spot metadata related classes in osgWorks. Well, ok, I just had a very quick overview... Can you tell me where to look at? Thanks.
Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ----- "Paul Martz" <[email protected]> a écrit : > If a specific node in a scene graph can be reliably identified, > application data > can be stored separately from the scene graph. Unfortunately, OSG's > mechanism > for identifying a node (the NodePath) is address-based, making it > unsuitable for > this task, as addresses change from one app invocation to the next. > > osgWorks has a solution for this. It has a set of NodePathUtils that > identify > nodes based on child index, node name, and class name, along with > conversion > utilities to switch between NodePaths and the string representation. > Because the > string isn't address-based, these utilities allow an app to identify a > specific > node between application invocations. Application-specific data can be > stored > saved to a database keyed by the NodePath's string representation, > then restored > later, for example. > > Just wanted to mention this, as the osgWorks metadata solution is > already > available and requires no changes to core OSG. > -Paul > > > On 1/28/2011 2:54 AM, Sukender wrote: > > Hi Robert, hi (SELECT name FROM "OSG_USERS" WHERE name<>"Robert > Osfield";), > > > > ** Context ** > > I spotted the DAE plugin is able to "return" some values to the > calling program by writing in the "plugin data" > (options->getPluginData()). But when writing, this plugin data is... > const! This thus requires an ugly and unsafe const_cast<> (or an even > uglier C-style cast). In other words: readers should not return any > value except the scene graph itself, or generally speaking "predefined > return values". I also think that using "void*" is just a > maintanability pain, with high risks of writing unallocated memory > parts, and such. > > > > ** Topic ** > > More generally, it is hard to store and pass "not predifined" > variables between main program and plugins, or between OSG itself and > the main program (I mean "adding some type-safe user values to the > graph"). > > This makes me think about something I discussed a bit before: the > ability to handle "metadata" in OSG (post named "Suggestion: Add > components in nodes (aggregation)"). To sum up the discussion, it was > roughly said that "it's on user side", and "use userData!". > > > > However, the "meta" system I implemented for my app is now quite > used and stable. I want it to be open sourced so that partners using > OSG also have access to metadata, and I propose this to be integrated. > But I don't wan't to simply copy-paste it into a submission; I'd like > to have a real reflexion around it, to make it useable for all. After > all, more and more file formats handle these metas, so why not OSG, as > long as it does not disturb existing features? > > > > ** Ideas ** > > So... starting the reflexion, I have a few ideas: > > > > 1. What is a meta? > > A meta is a "name/typed value" pair. Possible implementation is to > have a base class (with the name, say "MetaBase"), and several derived > (Meta<int>, deriving from MetaBase, and then Meta<std::string>...). > There could be as many meta types as you wish, but only a few > "standard" ones should be defined in OSG (int, double, string...). > > > > 2. How to store them (the container)? > > 2.1. Have a simple, yet easy and stable way: a basic container > (vector/list). Duplicate meta names should be handled on user's side > if necessary. > > 2.2. Have a name->value map. Implementation may be a bit less > flexible, but this ensures faster lookup (is this necessary?), and > name unicity (is this necessary?). > > 2.3. Other ideas: multimap, unordered_map, etc. > > 2.4. Have a user-defined container. That way, user may ask for a > simple vector, or a very complex DataBase-type container. As my > colleague told me: "usages can be too different to tell beforehand the > container type". This is surely a good idea, but how to implement it? > Work with iterators? Have a container base class? Use templates > somewhere? Help! > > > > FYI: my implementation uses a vector container (having generally > less than 10-20 metas in a container), with the MetaBase / > Meta<something> idea. > > > > 3. Where to store them? > > - Maybe there is a need to store them just in another variable, > alongside userData. This is one of my needs, but I still can use > userData as I do, even if that's not as clean as having directly a > container in osg::Object. Note: to avoid burdening osg::Object too > much, this could be a ref_ptr<> to a container. > > - Maybe there is a need for ReaderWriters, as I told at the begining > of my email? I guess so, but this does not solve the "constness" > problem if put in the Options structure. Or maybe we should provide > ReaderWriter a non const container to play with? > > > > 4. How to serialize/deserialize them? > > I personnally have straightforward "toString()/fromString()" methods > to convert back and forth. This is then used by my own plugins to > read/write those metas. This is certainly not the best implementation, > but surely the simplest. Another idea would be make plugins (or other > code) directly read values and (de)serialize them as they want; > however, I suggest to keep the "toString()/fromString()" methods in > order to handle unknown types. > > > > Many thanks to those who have read entirety this text. > > More thanks for your > thougts/ideas/remarks/insults(?)/comments/whatever. > > > > Cheers, > > > > Sukender > > PVLE - Lightweight cross-platform game engine - > http://pvle.sourceforge.net/ > > _______________________________________________ > > osg-users mailing list > > [email protected] > > > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > > > > > > -- > -Paul Martz Skew Matrix Software > http://www.skew-matrix.com/ > _______________________________________________ > osg-users mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
