Hi Robert, I thought you forgot me. XD
> ... this extensions isn't suitalbe to role out as part of the OSG as it's has > other established meanings, I would suggest a name that indicates a 3d scene format, for example, .osgs or .sgs. > Second up, ... It doesn't look like it'd be able to handle changes such as > removal, additions to or refactoring > of the classes that the old plugin supports and the new more modern file > provides in a modified way. One idea is that we maintain a unique id for each member of the class, which will help point out the right reading order. This could be easily done in .osg plugin and any other ascii-format parsers because members' names are already declared in file. But for a binary format, I wonder if these excess ids will make the file clumsy and large-sized. A better way is to make use of osgIntrospection, I think, but I'm not very familiar with it at present. > My third observation ... To enable ascii support one would have to add a > property name as an identifier when reading properties. > However, one could do this and just ignore it for binary formats. Perhaps > another possibility would be treat each property > as something that should be wrapped, with class wrappers aggregating the > individual property wrappers. As I just said in the last post, it should be easy to save files in both binary/ascii format. I would like to rewrite the DataInputStream and DataOutputStream classes soon to support ascii parsing, as well as adding property names if necessary. > Forth thought ... Replacing .ive with .bin would improve things because .bin > is simply a better approach with it's more decoupled and > extensible design, but... even better would be to be able to replace both > .osg and .ive with a further evolved .bin. Emm.. I hope so. :) > So what steps next... runtime testing... adding support for one other > NodeKit to test how the plugins can be extended at runtime. Perhaps > the core of .bin could be integrated into osgDB like the current .osg > parsing and have the wrappers provided by the osg, osgText, osgFX > plugins in the same way as the present wrappers... just maintain the > two sets of wrappers in side by side subdirectories from each of these > plugins. I've already been working on osgposter for weeks and I believe I nearly see the light now, as well as open up a can of worms... I will try submit this new example in 1-2 days, which merges osgautocapture and can automatically select highest LOD levels while rendering hi-res pictures, for the community to debug and test it better. After that, I'll be back to improve the new file format, adding ascii/binary support, loading wrapper libraries automatically, and prepare to move some functionalities into osgDB if possible. I'm also interested in a double-precision floating-point compressor named FPC (http://www.csl.cornell.edu/~burtscher/research/FPC/) and just wonder if it coule be reimplemented in this plugin. I would like to submit a new version of .bin plugin next week, and keep on discussing with you and others with a happy feeling. ;) Cheers, Wang Rui _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
