Hi Wang Rui, On Fri, Jan 15, 2010 at 1:16 PM, Wang Rui <[email protected]> wrote: > Of course, all the code submitted should be OSGPL, as a big part of > the core OSG library. I'm always glad to contribute to the open source > community. :)
Great. > I'd like to help rewrite some parts of VPB to make it compatible with > the new serializer as soon as possible. And I'll also write a tutorial > about how to write user-defined wrappers for the osg2 plugin at this > weekend, which may be added to the wiki page if necessary. Hope these > will help. Don't worry about VPB, I'll deal with that when the time comes. The tutorial would be a real help though. Another would be implementation of one the IO for one of the core OSG NodeKits such as osgText. For this I guess we'll need to move the core osg2 implementation classes into osgDB, then make the wrappers separate plugins. > I agree that we could have a new nodekit aiming at implementing the > native reader and writer. Other core namespace wrappers like osgText > and osgPartice could be wrote into external .so libraries, for > instance, osgIO_Text.so. (is osgIO a suitable name?) And the old .osg > and .ive format could still be used as a plugin. Because the osg2 > parser could check the stream header and easily find out if a file is > in recognizable format, and leave unknown ones unhandled to the chain > of responsibility. I'm inclined to keep the wrappers for the new format under the names osgDB_osg, osgDB_osgText etc. in the same way as the .osg is done right now. I'd also prefer to keep osgDB the place for these new IO classes rather than having another utility library for it. For the old .osg wrappers I'm thinking about moving them all into a single plugin and move the Input/Output etc. classes from osgDB into this new uber plugin. This would make it much easier to wrap up as single deprecated plugin used for backwards compatibility. The downside is this approach is that 3rd party NodeKits that add their own .osg support will be left in lurch and forced to port across to the new scheme. Is there any chance we can get old .osg/NodeKit .osg files read by the new parser? Another alternative is to make the old functionality a osgDB_deprecated library and plugins as part of this... although this ain't exactly perfect for backwards compatibility. Or.. just stick with what we have already in osgDB and add to it. One compromise might be to merge header like Filed, FieldReader, FieldReadIterator, Input, Output, DotOsgWrapper all into one to two headers that sole role is backwards compatibility. This way osgDB doesn't end up a quagmire of old and new classes with users not sure which ones a current and the ones to use. > I'm also interested in the osgDB::Input and FieldReaderIterator > classes, which uses a pre-reading mechanism and seems better than > working with std::istream methods only. I'd like to explore into the > source code and try to merge it with the InputStream in the next step. Yikes. osgDB::Field* and osgDB::Input classes are a very early attempt of mine to do parsing of files. They work, but they are horribly verbose and over complicated for what they do. I certainly wouldn't write them the same way today. I'd be happy to see all of these classes deprecated and superseded. I do understand that they make some things easier than when parsing ascii using istreams, so perhaps we can look at what specific problems you'd like addressed and we can then look at how we might achieve it. As general guide, all the old .osg support I'm intending to wrap up and isolate as much as not to distract from what we'll be wanting to be the standard way to do native class IO going forward. I also would like to see the old .osg and .ive formats become components for backwards compatibility only, and going forward we shouldn't have to maintain them beyond keeping them compiling and working reliably. I'll continue thinking about the options for making this transition smooth and will keep you informed of my thoughts. Robert. _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
