[osg-users] Node/Object Serialization

[Jeremy]

Is the serialization support of osg in active development? I made an
attempt to implement a custom osgDB::OutputStream class along
with writeObjectFields in order to try and piggy back the built in
serialization functionality in order to be able to populate a GUI tree view
I'm working on.

Loading Image...

It quickly became apparent that the serialization output in OSG is lacking
in enough ways that it doesn't appear that I can use it in this way, which
is very unfortunate. The same issues I ran into appear to be issues with
the in built serialization mechanisms, because the ascii and xml versions
of ReaderWriterOSG2 appear to be awkwardly formatted as well.

Since the serializers are implemented as a streaming set of values,
including 'count' type variables, there isn't enough context interleaved
through the stream to isolate the write* values for the property values
from formatting writes such as counts and type names and such.

I don't suppose there is any ongoing effort to improve upon this or
possibly add an alternate parallel reflection interface that one could
query and iterate the named properties of the entire hierarchy. Ultimately
I'm looking for a way to visualize the internal state of all the various
osg object types to a UI, or to script interfaces or whatever.

Thanks
Jeremy

[Robert Osfield]

Hi Jeremy,

You don't really provide enough info about how you are doing things to know
what be going amiss so I'll provide general information.

Since OSG-3.2 I have done quite a bit of work on making the serialization
scheme support introspection sufficient for the purposes of integrating the
OSG with scripting languages. There is now a lua plugin that uses this to
allow you to create and modify scene graphs all with lua and have this
integrated with the OSG application via callbacks etc.

The make the introspection a bit more user friendly I have write a
osgDB::ClassInterface class that provides a range of methods for enquiring
about properties of classes, creating objects and setting/getting
properties and invoking methods. This is available in the OSG-3.3.x dev
releases and svn/trunk.

I would have thought your usage case would fit well with the capabilities
of the new ClassInterface.

Robert.

Post by Jeremy
Is the serialization support of osg in active development? I made an
attempt to implement a custom osgDB::OutputStream class along
with writeObjectFields in order to try and piggy back the built in
serialization functionality in order to be able to populate a GUI tree view
I'm working on.
https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
It quickly became apparent that the serialization output in OSG is lacking
in enough ways that it doesn't appear that I can use it in this way, which
is very unfortunate. The same issues I ran into appear to be issues with
the in built serialization mechanisms, because the ascii and xml versions
of ReaderWriterOSG2 appear to be awkwardly formatted as well.
Since the serializers are implemented as a streaming set of values,
including 'count' type variables, there isn't enough context interleaved
through the stream to isolate the write* values for the property values
from formatting writes such as counts and type names and such.
I don't suppose there is any ongoing effort to improve upon this or
possibly add an alternate parallel reflection interface that one could
query and iterate the named properties of the entire hierarchy. Ultimately
I'm looking for a way to visualize the internal state of all the various
osg object types to a UI, or to script interfaces or whatever.
Thanks
Jeremy
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[Jeremy]

Excellent. Sounds perfect for my needs. I will check that out. I'm on 3.2
at the moment.

Post by Robert Osfield
Hi Jeremy,
You don't really provide enough info about how you are doing things to
know what be going amiss so I'll provide general information.
Since OSG-3.2 I have done quite a bit of work on making the serialization
scheme support introspection sufficient for the purposes of integrating the
OSG with scripting languages. There is now a lua plugin that uses this to
allow you to create and modify scene graphs all with lua and have this
integrated with the OSG application via callbacks etc.
The make the introspection a bit more user friendly I have write a
osgDB::ClassInterface class that provides a range of methods for enquiring
about properties of classes, creating objects and setting/getting
properties and invoking methods. This is available in the OSG-3.3.x dev
releases and svn/trunk.
I would have thought your usage case would fit well with the capabilities
of the new ClassInterface.
Robert.

Post by Jeremy
Is the serialization support of osg in active development? I made an
attempt to implement a custom osgDB::OutputStream class along
with writeObjectFields in order to try and piggy back the built in
serialization functionality in order to be able to populate a GUI tree view
I'm working on.
https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
It quickly became apparent that the serialization output in OSG is
lacking in enough ways that it doesn't appear that I can use it in this
way, which is very unfortunate. The same issues I ran into appear to be
issues with the in built serialization mechanisms, because the ascii and
xml versions of ReaderWriterOSG2 appear to be awkwardly formatted as well.
Since the serializers are implemented as a streaming set of values,
including 'count' type variables, there isn't enough context interleaved
through the stream to isolate the write* values for the property values
from formatting writes such as counts and type names and such.
I don't suppose there is any ongoing effort to improve upon this or
possibly add an alternate parallel reflection interface that one could
query and iterate the named properties of the entire hierarchy. Ultimately
I'm looking for a way to visualize the internal state of all the various
osg object types to a UI, or to script interfaces or whatever.
Thanks
Jeremy
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Jeremy]

Robert. Are there plans to expose more information through this interface?
Currently It appears that it is largely exposing the properties that are
serialized, and I was also hoping to expose read only access to
informational data about the various object types as well.

Post by Jeremy
Excellent. Sounds perfect for my needs. I will check that out. I'm on 3.2
at the moment.

Post by Robert Osfield
Hi Jeremy,
You don't really provide enough info about how you are doing things to
know what be going amiss so I'll provide general information.
Since OSG-3.2 I have done quite a bit of work on making the serialization
scheme support introspection sufficient for the purposes of integrating the
OSG with scripting languages. There is now a lua plugin that uses this to
allow you to create and modify scene graphs all with lua and have this
integrated with the OSG application via callbacks etc.
The make the introspection a bit more user friendly I have write a
osgDB::ClassInterface class that provides a range of methods for enquiring
about properties of classes, creating objects and setting/getting
properties and invoking methods. This is available in the OSG-3.3.x dev
releases and svn/trunk.
I would have thought your usage case would fit well with the capabilities
of the new ClassInterface.
Robert.

Post by Jeremy
Is the serialization support of osg in active development? I made an
attempt to implement a custom osgDB::OutputStream class along
with writeObjectFields in order to try and piggy back the built in
serialization functionality in order to be able to populate a GUI tree view
I'm working on.
https://www.dropbox.com/s/07t5zk7hw8jp2r7/Screenshot%202015-01-24%2023.06.38.png?dl=0
It quickly became apparent that the serialization output in OSG is
lacking in enough ways that it doesn't appear that I can use it in this
way, which is very unfortunate. The same issues I ran into appear to be
issues with the in built serialization mechanisms, because the ascii and
xml versions of ReaderWriterOSG2 appear to be awkwardly formatted as well.
Since the serializers are implemented as a streaming set of values,
including 'count' type variables, there isn't enough context interleaved
through the stream to isolate the write* values for the property values
from formatting writes such as counts and type names and such.
I don't suppose there is any ongoing effort to improve upon this or
possibly add an alternate parallel reflection interface that one could
query and iterate the named properties of the entire hierarchy. Ultimately
I'm looking for a way to visualize the internal state of all the various
osg object types to a UI, or to script interfaces or whatever.
Thanks
Jeremy
_______________________________________________
osg-users mailing list
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

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

[Robert Osfield]

Hi Jeremy,

Post by Jeremy
Robert. Are there plans to expose more information through this interface?
Currently It appears that it is largely exposing the properties that are
serialized, and I was also hoping to expose read only access to
informational data about the various object types as well.

I extended the serializers interface to handle cases where there is only a
get, and added a few wrappers to expose these methods but I haven't done it
for the whole OSG, I only did it for the bits that I needed on the
scripting work. Wrappers aren't free to implement or in memory cost so
implementing on a need basis helps keep the work and costs down. If there
are specific things that aren't exposed then let me know or add them
yourself.

Robert.