On Sun, Sep 19, 2010 at 7:06 PM, Thomas Dickerson <osgfo...@tevs.eu> wrote:
> Hi Robert, > > Thank you for the time you take to make your response, and the level of > information you included in it. Unfortunately I think you may have > misunderstood my original question. I was not inquiring about the > possibility of serializing my own classes into the native binary format, but > rather I was wishing to know whether a class that implements the > ReaderWriter functionality (i.e. the readNode and writeNode methods present > in all osgDB plugins) for a new format must be compiled into an external > plugin (.so), or whether it can be incorporated directly into my application > code, and compiled as part of my application binary. The instructions I was > able to find on the wiki regarding plugin implementation is a bit sketchy, > and only covered the possibility of helping the osgDB locate ReaderWriter > plugins that are actually stored as external plugins and not compiled into > my application. > > You don't need to do anything special for a ReaderWriter that you wish to link into your application. You write the class in exactly the same way, including the REGISTER_OSGPLUGIN macro. Your plugin will be registered early and OSG will use your code to load that file extension without searching for an external plugin. Depending on your platform, you might need to perform some additional magic to ensure that your code is actually linked into the application. On Unix, for example, if your plugin code is in a statically-linked library, the .o file containing the REGISTER_OSGPLUGIN "call" won't be linked in unless you create some external reference to code in that file. Additionally I was wondering what "proper plugin etiquette" is for plugins > that read a format, but do not also write to it. I noticed some plugins > conditionally return a > Code: > WriteResult(WriteResult::FILE_NOT_HANDLED); > > > My question on this second issue is whether it is "better manners" for my > ReaderWriter class to implement a writeNode function that ALWAYS returns > FILE_NOT_HANDLED, or whether it is best to just leave the function > unimplemented. > Not FILE_NOT_HANDLED, but NOT_IMPLEMENTED. Since the default virtual methods return NOT_IMPLEMENTED, it's cleaner not to implement them yourself; you might get the return result wrong :) Tim > > Thanks, > Thomas > > ------------------ > Read this topic online here: > http://forum.openscenegraph.org/viewtopic.php?p=31803#31803 > > > > > > _______________________________________________ > 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
