Hi Robert,
2009/12/11 Robert Osfield <[email protected]>:
>
> 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.
>
It should be easy to change the extension at any time. So I'd like to
keep the polysemic name "bin" until the plugin is ready for public
testing. I agree that .osg is the best choice, but obviously ther is a
long way to go.
>
> 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.
>
In fact this is something like a DTD or XSD, which describes the
structures of classes of a specifed version. This could be placed at
the beginning of the binary file, or just as an individual one, for
instance, osg_3.0.schema. It will be automatically searched and used
by any files without a description header. The content of this schema
file could be simply filled with "keyword=value" pairs, or even in a
standard XML format. I'm dreaming of having a binary/ascii/xml
compatible file format in the future. :)
>
> 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.
>
Today I just overrided a series of operator<<() functions to make the
OutputStream class clearer and even ready to be serialized sometime
later, so do the InputStream class. And to implement ascii property
naming support, I coded one of them like:
OutputStream& operator<<( OutputProperty& prop )
{
if ( this->isBinary() ) // Ignored by binary formats
this->_stream << prop._name;
return *this;
}
Here OutputProperty is a custom struct for recording property name
temporarily. Then I could just modify the writing functions of each
wrapper using a PROPERTY macro:
os << PROPERTY("Name") << obj.getName();
The only thing it to totally rewrite all 102 existing classes. Oops..
I'd prefer use a limited number of core classes for test at present.
>
> 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?
>
I had the plan to recode the FPC algorithm if possible. But I'm also
very happy to have a rest if there are already other friendly and
useful float point compressions for use.
I'll be ready to be merged for fully tests and submissions after
having finished the initial ascii/binary support. May the plugin be
placed in an inconspicuous subdirectory and mentioned as
"not-recommended for public use", or just as a working copy in the
branch?
Cheers,
Wang Rui
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
