Hi Robert,
Boy you spot everything that come and goes :-)
:-)
Something that I found interesting about the quick XML parser code was that being done in C++ it was much more convenient to use than libxml2, when I ported Present3D across from being libxml2 based to osgDB/XmlParser based the code ended smaller and more readable.
Yeah, I once wrote a small C++ wrapper around libxml2 because I found it cumbersome to use, also based on nodes in a tree like yours and it made the user code much easier to read. I totally get what you're saying.
Conforming to "Specs" is an issue, but I don't think it need be a big issue for reading as you can either read the data problem or you can't. Writing out con-formant .dae will be hard to police though. I guess we could use Collada DOM to test out the files for conformance during development and maintenance.
I agree.
Getting COLLADA support out of the box would be great as right now everyone has to jump through hoops to get COLLADA support and this only reduces the number of end users that will be using COLLADA as an interchange format. So by being awkward to build and maintain builder code against the COLLADA DOM is harming it's cause as much as it is promoting it.
I agree. So, anybody have the time to do it? :-) 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
