Hi Robert, 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. :)
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. 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 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. Wang Rui 2010/1/15 Robert Osfield <[email protected]>: > Hi Wang, > > Thanks for the OutputStream.cpp update. I've now merged this with me > local version. > > I'm currently reviewing the code with a view of see what parts we can > extract out and place in osgDB. I see that you adapted/greatly > enhanced osgDB::Serializer, merging the new an improved one mean that > I'd have to adapt the code that uses the present Serializer, and the > only place that does is VPB, so it should be relatively straight > forward. This would then have the knock on effect that VPB's .source > ascii format would become an example of the new parsing scheme which > is a good thing, the only awkwardness is judging the timing of when to > make this change. > > I'm also looking at how we might start moving the old .osg > functionality to become a deprecated feature, and how we might have > osgDB decide whether a .osg file is a new one or an old one and choose > which of the plugins to load. Me thought is that the > ReaderWriterOSG.cpp and ReaderWriterOSG2.cpp implementations might > need migrating into osgDB, and the plugins then become the source of > the wrappers, just like the osgParticle, osgText plugins do for > provide .osg ascii support. With the new support I'm expecting to > that temporarily we'll have two sets of these NodeKit plugins one for > each type of .osg - the new and the old. > > During the review I've noted that you have placed any copyright notice > on any of the files, or notification of which license they are under. > I presume it's the standard OSGPL that you intend, but I can't merged > anything until I get confirmation. > > Cheers, > Robert. > _______________________________________________ > osg-submissions mailing list > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org > _______________________________________________ osg-submissions mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
