Hi Roger,

We seem to have jumped straight into a technical discussion on how this could be done with very little discussion on whether it should be done. I think we need to take a step back here. At the moment I am tending toward the view that we should spend effort on improving the current build system and documentation for the plugin. I have yet to see a good argument why we should do otherwise.

My problem with the COLLADA DOM is that it uses dependencies which we also use in our software, like boost and libxml2. That means if we're going to compile the OSG COLLADA plugin, then we need to compile the COLLADA libs against the same versions of boost and libxml2, and link those dynamically, or link them statically into both COLLADA and our software (which is a big payload for boost, it would be there twice and it's already BIG).

This means that using the COLLADA plugin is no longer just a case of building COLLADA and getting OSG's CMake to find it, we also need to make various changes in the COLLADA libs' build system to make it use the same boost and libxml2 libs, and those changes need to be made each time we update COLLADA. It's a drag.

I'm open to suggestions on how to alleviate this. I expect I'm not the only one in this situation, lots of people use boost in their software.

Having our own COLLADA reader would certainly make that part disappear. But I agree it might be opening a large can of worms. I'm not the best placed to decide if the tradeoff is worth it, but the reasons above are why we don't use the COLLADA plugin, and once again I expect there are others in the same boat.

J-S
--
______________________________________________________
Jean-Sebastien Guay    [email protected]
                               http://www.cm-labs.com/
                        http://whitestar02.webhop.org/
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Reply via email to