On Wed, 2011-08-17 at 08:48 +0800, Wang Rui wrote:
> Hi Jeremy and Robert,
>
> In fact the osg::Image class can be derived and it is possible to
> write serializers for the subclasses. In
> osgWrappers/serializers/osg/ImageStream.cpp you will find an example
> which has no difference from other serializers. I'm not sure if this
> could work for osgCairo images, but I think a subclass that doesn't
> change osg::Image's basic functionalities can work fine with
> serializers at present.
I'm not entirely sure this is accurate; if you look at osgimagesequence
example, it lets you write the file out to disk:
osgimagesequence -o foo.osgt
...but that file isn't readable by OSG. In fact, I had no trouble ever
writing my custom Image to disk, only reading it back in.
However, the serializer backend is very complex (or rather, quite
abstracted away in macros), and so I've found it difficult to track down
where exactly to investigate...
> After reviewing the source code, I think it also possible to replace
> the readImage() and writeImage() in Input/OutputStream classes with an
> Image serializer, too. I can't remember why I use special
> reader/writer functions to handle images. Maybe it is only a
> plagiarism of old osgDB::Input/Output class' methods. :-P
Perhaps this is where I should look then. :)
> Cheers,
>
> Wang Rui
>
>
> 2011/8/17 Jeremy Moles <jer...@emperorlinux.com>:
> > Hello everyone; this is probably a question only a few people could
> > possibly, answer (Robert, Wang), but here goes:
> >
> > I have created a derived osg::Image class (osgCairo::Image), and this
> > has worked just fine for the last few years. However, I want to add
> > strong serialization support for my nodekits, and I'm finding
> > customizing an Images behavior in the serialization code is quite
> > difficult.
> >
> > Images are treated as special kinds of Objects, so any custom behavior
> > you might add confuses the base serializers, and there doesn't appear to
> > be any way to avoid this.
> >
> > My question is: should the serialization backend be modified to support
> > osg::Image subclasses, or should programmers be encouraged NOT to derive
> > from osg::Image directly and instead create "contains-a" objects
> > instead?
> >
> > _______________________________________________
> > 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 mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
