On Tue, 2011-08-16 at 12:42 -0400, Jeremy Moles wrote: > 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?
As an addendum, this may simply be a misuse on my part. Perhaps if someone is deriving from osg::Image, that person should also consider creating a custom image "type" and, thus, writing an osgPlugin for their image type to do the various kinds of extra stuff they need to do. For example, in osgCairo, though I may actually be using PNG data, I could create a ".cairo" file type which will force my custom loader instead of the default loader (which will allow me to do things like pre-multiply the alpha, which Cairo expects internally). Just thinking out loud here. :) > _______________________________________________ > 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