Re: [osg-users] New serialization scheme
Hi Lionel,
I'm not clear on what you are looking for, in terms of further information,
or functionality.
The OSG's SO version is currently used to version the .osgb, .osgt and
.osgx file formats. Does this help you?
When implementing your own wrappers it probably best to just look at the
how similar classes to yours are serialized with the
src/osgWrappers/serializer/*/*.cpp files. There are quite a few macros
that make it easy to wrap basic types, such floats, int, strings, etc.
Serialization of UserData is also supported - all you need to do is
subclass from osg::Object and implement the wrappers.
Robert.
On 23 March 2015 at 09:47, Lionel Lagarde lionel.laga...@oktal-se.fr
wrote:
Hi,
Better late than never, I'm writing the serializers of my own classes
for the osgt, osgb... file formats.
Theses classes exist for a long time, they have evolved a lot. Both the
interfaces
and the implementations have changed.
I try to make a loader that is able to load the files written using a
previous
version of the software. Of course, because the osg{t,b...} support is
new, a new
format will not appear soon but I want to foresee this case.
In the deprecated osg and ive reader writer, because the read and write
procedure were
functions, I was able to read a version number, and according to it, read
the right
parameters and build the class using the right methods.
Because the members of the classes are now loaded independently from each
other, it is now
a little bit more complicated. I'm planning to make my own serialization
classes (TemplateSerializer, PropByValSerializer...) that are able to read
the
current version number, read the ''thing'' if needed, and store it
somewhere.
Using a FinishedObjectReadCallback, I should be able to build correctly
the classes.
Right now I'm looking for a reading state structure. This structure has to
be
readable/writable by all the serializer classes. Maybe the user data of
the node
is the right place.
Does someone has already faced a similar problem? If so, how you resolved
it?
I don't know well the new serialization scheme, maybe there is a better
solution?
Any clue?
Lionel Lagarde
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New serialization scheme
Hi,
While writing the post, I realized that I wasn't clear.
I'm trying to do:
REGISTER_OBJECT_WRAPPER(...)
{
ADD_INT_SERIALIZER(Version, -1);
ADD_CONDITIONAL_SERIALIZER(Version, 1, TheDeprecatedProperty);
ADD_CONDITIONAL_SERIALIZER(Version, 2, TheNewProperty);
...
wrapper-addFinishedObjectReadCallback(new UpgradeCallback);
}
The conditional serializer checks the version of the node being read is
equal
to the version in the macro. If so, it reads property and stores it
somewhere.
The upgrade callback collects the deprecated properties and build a
ready to
use node.
Maybe I can get out using the _firstVersion and the _lastVersion members
of BaseSerializer:
ADD_INT_SERIALIZER(TheMember, -1);
wrapper-_serializers.back()-_firstVersion = N;
wrapper-_serializers.back()-_lastVersion = N;
or using the macros:
UPDATE_TO_VERSION(N);
ADD_INT_SERIALIZER(TheMember, -1);
UPDATE_TO_VERSION(N+1);
REMOVE_SERIALIZER(TheMember);
Using the first/last version members of the serializers, I think I can
make the serializers
work as I want. I just have to:
- keep the olds interfaces inside the classes
- make sure there is no name collision between the old and the new
interfaces
Or I stop over-thinking it and create a new class with its own
serializers when the class changes.
Using a read file callback, I can upgrade the loaded scene graph if it
contains old nodes.
I think get it.
Thanks.
Lionel Lagarde.
On 23/03/2015 12:33, Robert Osfield wrote:
Hi Lionel,
I'm not clear on what you are looking for, in terms of further
information, or functionality.
The OSG's SO version is currently used to version the .osgb, .osgt and
.osgx file formats. Does this help you?
When implementing your own wrappers it probably best to just look at
the how similar classes to yours are serialized with the
src/osgWrappers/serializer/*/*.cpp files. There are quite a few
macros that make it easy to wrap basic types, such floats, int,
strings, etc. Serialization of UserData is also supported - all you
need to do is subclass from osg::Object and implement the wrappers.
Robert.
On 23 March 2015 at 09:47, Lionel Lagarde lionel.laga...@oktal-se.fr
mailto:lionel.laga...@oktal-se.fr wrote:
Hi,
Better late than never, I'm writing the serializers of my own classes
for the osgt, osgb... file formats.
Theses classes exist for a long time, they have evolved a lot.
Both the interfaces
and the implementations have changed.
I try to make a loader that is able to load the files written
using a previous
version of the software. Of course, because the osg{t,b...}
support is new, a new
format will not appear soon but I want to foresee this case.
In the deprecated osg and ive reader writer, because the read and
write procedure were
functions, I was able to read a version number, and according to
it, read the right
parameters and build the class using the right methods.
Because the members of the classes are now loaded independently
from each other, it is now
a little bit more complicated. I'm planning to make my own
serialization
classes (TemplateSerializer, PropByValSerializer...) that are able
to read the
current version number, read the ''thing'' if needed, and store it
somewhere.
Using a FinishedObjectReadCallback, I should be able to build
correctly the classes.
Right now I'm looking for a reading state structure. This
structure has to be
readable/writable by all the serializer classes. Maybe the user
data of the node
is the right place.
Does someone has already faced a similar problem? If so, how you
resolved it?
I don't know well the new serialization scheme, maybe there is a
better solution?
Any clue?
Lionel Lagarde
___
osg-users mailing list
osg-users@lists.openscenegraph.org
mailto:osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] New serialization scheme
Hi,
Better late than never, I'm writing the serializers of my own classes
for the osgt, osgb... file formats.
Theses classes exist for a long time, they have evolved a lot. Both the
interfaces
and the implementations have changed.
I try to make a loader that is able to load the files written using a
previous
version of the software. Of course, because the osg{t,b...} support is
new, a new
format will not appear soon but I want to foresee this case.
In the deprecated osg and ive reader writer, because the read and write
procedure were
functions, I was able to read a version number, and according to it,
read the right
parameters and build the class using the right methods.
Because the members of the classes are now loaded independently from
each other, it is now
a little bit more complicated. I'm planning to make my own serialization
classes (TemplateSerializer, PropByValSerializer...) that are able to
read the
current version number, read the ''thing'' if needed, and store it
somewhere.
Using a FinishedObjectReadCallback, I should be able to build correctly
the classes.
Right now I'm looking for a reading state structure. This structure has
to be
readable/writable by all the serializer classes. Maybe the user data of
the node
is the right place.
Does someone has already faced a similar problem? If so, how you
resolved it?
I don't know well the new serialization scheme, maybe there is a better
solution?
Any clue?
Lionel Lagarde
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] The OSG SIGGRAPH BOF train is leaving the station
AND WILL ARRIVE AT SIGGRAPH. Birds of a Feather Session Title: OpenScenegraph BOF Date: Wednesday August 12 Location: Los Angeles Convention Center Time: 10:00 - 11:00 am Note: and yes, I still am on the hook for pictures of past BOF's and materials.. EXCUSE INSERT EXCUSE HERE /EXCUSE EXCUSE, the only XML tag you will ever need. Last note: TRIP OVER YOURSELF RUSHING TO MAKE OSG BOF PRESENTATIONS / TRIP OVER YOURSELF RUSHING TO MAKE OSG BOF PRESENTATIONS TRIP OVER YOURSELF RUSHING TO MAKE OSG BOF PRESENTATIONS. Not the only necessary and sufficient XML tag, but occasionally useful as a supplemental and vicarious standards based enumeration. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
