Hi Wang Rui, On Thu, Dec 10, 2009 at 9:14 AM, Wang Rui <[email protected]> wrote: >> ... 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.
I believe .osg would be the most appropriate extension, the header could declare which version of the format it is - whether it's binary, new ascii or old ascii. We could possible have a .osgb for binary. The main issue with using .osg and then changing it's format would be new apps generating the new new .osg files and then trying to read these with older versions of the OSG. One could port the new plugin to older versions of the OSG though, so one could still provide a new plugin for them to handle the new files so all is not lost. Even the present .osg plugin should be able to read the files robustly enough to fail gracefully when reading the new format. My preference for using the .osg extension is that I don't want there to be a proliferation of extensions that are less descriptive of what they are. For instance .ive really doesn't sound like it's anything native to the OSG, same would apply to something like .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. In the ascii format the unique id for each class porperty is effectively the keyword that identifies it, this could work with a xml style ascii or an existing .osg style ascii format. Having a keyword string for each class property would obviously be very inefficient for a binary format, both in terms of speed and size, using a string to id mapping in the form of dictionary placed at the beginning of the binary file might map between them so that id's could be used in the data section of the binary format. Another alternative for the binary format would be to version each class individually, and then allow multiple wrappers for each class in the plugin, and choose the appropriate wrapper based on the version info included in the binary/ascii format. Since a single binary file will just use one version of class for the whole file then one could just place the class used and their version number in header section. A further extension to this idea might be to have the header section list the classes used and their properties + type of the properties - like an inbuilt schema. > A better way is to make use of osgIntrospection, I think, but I'm not > very familiar with it at present. I think the use of osgIntrospection is something you'd leave for wrapper generation, and isn't an issue till we get to the point where we have formalized the file format and come up with a series of easy to use macro's that register the classes and their members. One thing I also have in the back of my mind is that osgIntrospection itself is problematic to maintain, is rather heavy weight, and has had little use out in the community. It might be that the new ascii/binary format mechanism might be a lighter weight way of provide property introspection than osgIntrospection. One could also adapt a tool like genwrapper to spit out the new types of wrappers rather than the present osgIntrospection ones. > 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. This would be a useful addition. Did you have an idea how you'd provide the property naming? With the DataInpurStream did you have an idea how to cope with the potentially altered ordering of properties - or do we just declare such changes in ordering as invalid ascii files? Declaring an invalid ordering would certainly make the reading code easier. >> 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. :) It'd be a huge step forward for the OSG, more work short term, but long term it'll ease our maintenance burden, make extending the OSG easier for the community, and make it easier to publish the format and make it easier to allow 3rd party apps to be interoperability with the OSG. >> 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. Great, look for see it posted :- > 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. ;) I just checke he FPC webpage out, the license doesn't look open source friendly, so were you just thinking of learning about the technique and then re-implementing from scratch? In terms of really useful compression I'd say the float point compression rather than double compression would be more useful as the all the large data structures in scene graphs are Vec2/Vec3/Vec4's. Cheers, Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
