Hi Wang Rui,

Many thanks for all the updates.  I think the rate of progress and the
feature set is just plain awesome ;-)

I really like the way that the macro's are working and making it a
pretty streamlined task.  The .osgt format looks really clean - more
consistent and with a better mapping to the underlying features than
.osg.  The new plugin/format is very clearly better for maintenance
than either of .osg and .ive.

I'm still learning about the plugin, and need to get my head around
the various options.  One option that might not be perfected yet is
handling of writing of images into the file.  I tried but got an error
report:

> osgconv -e osg2 cow.osg cow.osgb -O WriteImageHint=IncludeFile
OutputStream::writeImage(): Failed to open image file Images/reflect.rgb
Data written to 'cow.osgb'.

The error report suggests to me that the path to the original file is
being lost and then not subsequently found.  I'm surprised this is an
issue as the .ive plugin just uses the image data in memory but the
error from the osg2 plugin suggests that it's going back to the
original image file.  Using the image data that's loaded into memory
would be probably a better approach.

I've also done some quick comparisons of plugin size.   I'm getting

883968     osgdb_osg.so
969502     osgdb_ive.so
2319842   osgdb_osg2.so

So it would like the OO approach to wrapping results in a bigger
plugin footprint. However, it's not a huge difference considering the
.osg plugin code is spread into osgDB, and that the osg2 plugin does
both binary and ascii format.  The size is still bigger than .osg +
.ive plugins put together.  It's not a great concern to me, but it
does make me wonder if there might be ways of slimming things down a
bit more.  Any ideas?

Just to give a bit of grounding of the size optimization, just have a
look at what size the osgIntrospections wrappers are for the .osg
library:

70230433 osgwrapper_osg.so

So that 2.3Mb for you osg2 lib for property serialization vs 70Mb for
osgIntrospection support.  This suggests that osg2 is actually pretty
efficient at it's serialization of properties, or that
osgIntrospection wrappers with all their template magic are a bit of
disaster area.

Which... brings me on to me next observation, could the .osg2 scheme
be added for generic querying and setting of scene graph properties?
Could it unseat some of the need for osgIntrospection?

Many thanks for you efforts on this plugin, it's realy a huge step
forward.  I'll continue my review tomorrow and get it ready for
merging with svn/trunk.

Cheers,
Robert.
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org

Reply via email to