[osg-users] Backward compatibility with custom serializers

[Farshid Lashkari]

Hi,

I recently added serialization support for a custom osg::Object derived class in my application. I saved the object to a osgt and osgb file and attempted to load it into an older version of my application, which didn't have serialization support for my custom object yet.

Loading the osgt file gives me the following warning message:

InputStream::readObject(): Unsupported wrapper class MyLibrary::MyObject

This is expected. However, when I attempt to load the osgb file I get the following output then my application crashes:

InputStream::readObject(): Unsupported wrapper class MyLibrary::MyObject

InputStream::readObject(): Unsupported wrapper class

Before I spend time looking into this, I was wondering if it is expected for the binary loader to crash on unsupported objects? I'm working with osg 2.9.12, if that makes a difference.

Cheers,

Farshid

[Robert Osfield]

Hi Farshid,

I will have to defer to Wang Rui to get into the nitty gritty bits of
the serializers as he's the author of this feature. In general I
would say the intention of the serializers is not to crash when
handling unrecongized objects. Using 2.9.12 has to be a risk though,
the serializers have been improved since then and are more flexible
and robust now.

Robert.

> _______________________________________________
> osg-users mailing list
> osg-...@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-...@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Wang Rui]

Hi Farshid,

Unfortunately the InputStream doesn't have a good mechanism to handle
unsupported class in binary files without the version control macro
UPDATE_TO_VERSION (for IVE files, version control is supported
internally in the plugin source code). Text files can ignore unknown
class blocks because the advanceToCurrentEndBracket() method makes it
possible to jump to next block. But for binary files, there are no
straightforward flags to mark the beginning or end of a wrapper class'
data. So I think adding UPDATE_TO_VERSION macro in your serializers
would be the only way to keep compatibility at present.

Wang Rui


2012/10/4 Farshid Lashkari <fla...@gmail.com>:

[Farshid Lashkari]

Thanks Wang, Robert.

How would I go about using the UPDATE_TO_VERSION macro in this scenario? My understanding is that the macro is used when the version of OSG is updated. However, the version of OSG is the same between the two versions of my application, it's just that the serialization support for my custom object was added in the newer version.

On a related note, shouldn't new versions of OSG always be able to load osgt/osgb files generated by older versions? I just downloaded the pre-built binaries for 3.0.1, and they are not displaying the files generated from 2.9.12. The strange thing is that I'm not getting any error messages, it's just that nothing is being rendered. It's as if an empty node was returned by the loader.

Could this be a bug with current loader? I've attached a zip file that contains an ive, osgt, and osgb version of the same model. The ive loads and displays fine in 3.0.1, but as I mentioned, the osgt/osgb files do not display anything.

The current pre-built installer for the 3ds Max exporter uses 2.9.13, so this could cause some problems. Also, we have hundreds of customers generating models using 2.9.13, so it's important for newer versions of OSG to be able to load these models.

Cheers,

Farshid

[Wang Rui]

Hi Farshid,

2012/10/5 Farshid Lashkari <fla...@gmail.com>:

> Thanks Wang, Robert.
>
> How would I go about using the UPDATE_TO_VERSION macro in this scenario? My
> understanding is that the macro is used when the version of OSG is updated.
> However, the version of OSG is the same between the two versions of my
> application, it's just that the serialization support for my custom object
> was added in the newer version.
>

Oh, this seems to be already discussed in another thread. I was
thinking of implementing a user version macro at that time but then I
was a little too busy to worked on it. I will consider adding a new
UPDATE_TO_USER_VERSION macro to allow version control of custom
serializers as soon as possible, maybe tomorrow. :-)

> Could this be a bug with current loader? I've attached a zip file that
> contains an ive, osgt, and osgb version of the same model. The ive loads and
> displays fine in 3.0.1, but as I mentioned, the osgt/osgb files do not
> display anything.
>

Yes, this is a bug just found in osgWrappers/serializers/osg/Node.cpp,
which uses UPDATE_TO_VERSION incorrectly so it also affects the
following StateSet serializer. I think the brackets after the macro
really confuses us and will do something soon to make it more
readable.

Thanks,

Wang Rui

[Farshid Lashkari]

Hi Wang,

On Fri, Oct 5, 2012 at 10:19 AM, Wang Rui <wang...@gmail.com> wrote:

Oh, this seems to be already discussed in another thread. I was
thinking of implementing a user version macro at that time but then I
was a little too busy to worked on it. I will consider adding a new
UPDATE_TO_USER_VERSION macro to allow version control of custom
serializers as soon as possible, maybe tomorrow. :-)

Sorry, I missed that thread. That sounds excellent!

 

Yes, this is a bug just found in osgWrappers/serializers/osg/Node.cpp,
which uses UPDATE_TO_VERSION incorrectly so it also affects the
following StateSet serializer. I think the brackets after the macro
really confuses us and will do something soon to make it more
readable.

Great news, I was worried there for a second :)

Cheers,

Farshid