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

Reply via email to