Hi Peter, Robert, & all Thanks for your ideas, Peter. I really appreciate the proposal of having values in a separate structure with weak references. But is this a singleton? If so, how would you handle the case where you have to process things between two models (say you want to load two files and merge/process them anyhow)?
Robert, what is your opinion on Peter's idea? Sukender PVLE - Lightweight cross-platform game engine - http://pvle.sourceforge.net/ ----- "Peter Amstutz" <peter.amst...@tseboston.com> a écrit : > I have run into the same problem trying to get metadata from the > OpenFlight loader. > > In my application I handled the attributes problem by using the > "Description" field on osg::Node, which stores an arbitrary list of > strings and unlike UserData can be serialized by various osgDB > plugins. > I encoded attributes in "Key=Value" form, with only the most trivial > parsing of splitting on the '=' and any further type coercion handled > on > the user side. This works for my needs but is obviously unsuitable > for > storing large or complex data. > > For a thorough solution to this problem, my suggestion would be: > > a) Define a few primitive types, like integer, float and string. > Define > a couple of container types, vector and map. Containers can contain > other containers. > > b) Serializerizers translate the generic structure to/from other > formats > such as binary, XML, JSON, prettyprint etc as appropriate for target > format. > > c) Consider maintaining metadata in a table separately from the scene > graph. So instead of adding a getMetadata() to osg::Node, there > might > be an osgDB::Metadata object with a method > getMetadataForNode(osg::Node*). This avoids burdening the scene > graph > with additional fields. The osgDB::Metadata would hold weak > references > so it doesn't interfere with the existing object lifecycle of nodes. > This also has the advantage of being separate from the osg core and > not > requiring as much buy-in from Robert if he doesn't like it :-) > > Cheers, > Pete > > On 1/28/2011 4: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 > > 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
