Hi Robert
> A couple of quick thoughts. I would love to replace the .osg and .ive
> formats with a new single native binary/ascii format. Would it be
> possible to do both with a single plugin?
It's not hard to support both binary and ascii format, I think. In the
case of mine, just leave user-defined wrappers alone and modify only
the read*()/write*() functions like this:
void writeCharArray( const char* s, unsigned int size )
{
if ( _isBinary )
_out->write(s, size);
else
_out << s;
}
But it won't be easy to make a friendly one. For example, cow.osg
includes these lines:
StateSet {
rendering_hint OPAQUE_BIN
renderBinMode INHERIT
GL_CULL_FACE OFF
GL_LIGHTING ON
}
With the new plugin, which lacks enum descriptions, it may come like:
StateSet {
rendering_hint 1
renderBinMode 8
2884 0
2896 1
}
Hardly to realize it unless you are very familiar with OSG and OpenGL
(GL_CULL_FACE=0x0B44 and GL_LIGHTING=0x0B50). And it really will be a
pain if we had to modify each wrapper to comvert enums to strings.
> The extension .osg would be the appropriate thing for a native .osg
> format. An appropriate header could say which version of is
> represented in the file. Perhaps a .osgb could be used for a binary
> if needed.
As Paul said, .osgb may be already used. I suggest .oa for ascii files
and .ob for binary ones, or .osgs (osg scene) for both. Any more
ideas? :)
> In VirtualPlanetBuilder I experimented with serialization of class
> members using a series of templated classes to bind the reading and
> writing of members. Perhaps something similar could be used - perhaps
> you already use such an approach, tomorrow I should have chance to
> review your code.
I just took a review of osgDB::Serializer and related classes. They
use osgDB::Output and Input for I/O operations. In fact I've leart
into these two classes before, attempting to make them work both
'asciily' and 'binarily'. But the heavy workload forces me to give up
at this stage. Maybe we could have a plan of rewriting osgDB::Output
and Input classes, and then benefit from existing Serializer? Instead
of developing a totally new series of serialization classes.
> I also do wonder about whether osgIntrospection could be used to help
> fill out the serialization details, or... perhaps even the reverse,
> have the plugin specify accessors to the class members to provide a
> form of introspection... and then osgIntrospection could then be
> deprecated...
Sorry to say, I've no idea about this at present. :)
Wang Rui
_______________________________________________
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
