Hi Robert,
When reading your reply I can agree that putting something like ColladaOptions
into osgDB might not be the best thing to do. My thoughts when writing the code
was to change as little as possible and still be able to get access to
plugin internal stuff and to have the option to pass in another pointer to be
used.
I'd think adding a std::map to ReaderWriter::Options and some methods to
operate
on it (set, get, remove - anything else needed?) would be better than just a
userdata object.
But I'm not sure what would be an appropriate name for it. I don't think
ExternalData
really describes it since it can be used to pass back data from the plugin.
/ Mattias
On Wed, Sep 26, 2007 at 11:51:29AM +0100, Robert Osfield wrote:
> Hi Mattias,
>
> Thanks for the changes. I have done a quick review and am not happy
> with placing a plugin specific data structure like ColladaOptions into
> a general purpose library like osgDB. Once one starts going down the
> road in placing plugin specific data structures in osgDB you'll end up
> on a slippery slope of messy and difficult to maintain library.
>
> I don't have a solution to this problem yet. Perhaps a general
> purpose UserData object for passing in/out void pointers would be
> sufficient. Or perhaps one could provide a
> std::map<std::string,void*> in ReaderWriter::Options base class for
> passing in and out different types of data, i.e.
>
> options->setExternalData("DAE",dataPtr);
>
> DAE* daePtr = (DAE*)options->getExternalData("DAE");
>
>
> The aim must be to keep things with a very loose coupling in osgDB,
> and to make any extensions general purpose.
>
> Robert.
>
>
> On 9/26/07, Mattias Linde <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I've attached some suggested changes to the collada plugin:
> >
> > I've added a ColladaOptions class which can specify which DAE instance
> > should
> > be used. If no options are used when osgDB::readNodeFile is called the
> > plugin
> > will work just as before.
> > (include/osgDB/ColladaOptions and src/osgDB/ColladaOptions.cpp in the
> > tarball)
> >
> > With the colladaoptions one can use an "external" (as in outside of osg)
> > dae-instance which possibly already holds parsed data or an internal
> > instance
> > (the plugin creates one unless it has already done so). The options object
> > also makes it possible to get a pointer to the dae instance so it can be
> > used outside of osg.
> >
> > src/osgPlugins/dae/ReaderWriterDAE.cpp have been updated to use
> > ColladaOptions.
> > daeReader.h and daeWriter.h have one minor change each, a ; was removed
> > after the
> > namespace end } which caused a warning.
> >
> > CMakeLists.txt have also been updated to link with collada_dom_shared and
> > collada_dae_shared (if not under win32) instead of collada_dom and
> > collada_dae.
> > This is because of collada-dom now supports building shared libs under linux
> > (been tested on OS X aswell). Linking with the static libs in the plugin
> > can (and have) cause problems if the application using osg links with
> > collada-dom
> > libraries.
> >
> > / Mattias
> >
> > _______________________________________________
> > osg-submissions mailing list
> > [email protected]
> > http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
> >
> >
> >
> _______________________________________________
> osg-submissions mailing list
> [email protected]
> http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
_______________________________________________
osg-submissions mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-submissions-openscenegraph.org
