[Bf-committers] Collada importer/exporter kickout

[Peter Amstutz]

Hi Sergey,

When I looked last looked at OpenCollada, one critical issue preventing 
someone else from taking over maintenance is the fact that it relied 
heavily on autogenerated code, but the code generator and the input file 
are not included in the online repository.

The ColladaDOM reference implementation uses an awful code generator 
written in PHP, but at least it is available.

The nature of the Collada spec is that generating code from the schema 
is the only reasonable way to go, as permutation of tags and schema 
rules mean that trying to code it all by hand would cause you to grind 
your fingers down to little stubs by the time you were done.  I've 
successfully used JAXB to generate an API from the Collada 1.4 schema, 
but that is Java so that won't work for Blender.  There are presumably 
be similar tools for C++ and Python (although at least one Python 
XML->code generator I tried failed spectacularly with an out of memory 
error after running for ten minutes).

There are also a lot of permutations of data formats (especially how 
vertex data is stored) which entail troublesome and buggy data conversion.

To have better Collada support in general would ideally start with a 
standalone Collada library that handles not just the basic parsing, but 
provides a comprehensive implementation of the Collada database 
including data conversion facilities so that the client application can 
request or write data in any reasonable format and have the library 
figure out how to translate it to/from the underlying Collada file. 
This would also manage/link the cross references automatically so a 
rendering engine could, for example, access the data as a scene graph 
and not have to deal with the library structure.  This would benefit 
lots of 3D software, not just in Blender.

There would also needs to be a set of test cases, ideally both unit and 
regression tests so users can reliably know which features are 
supported.  Buggy support is worse (certainly more frustrating) than no 
support.  (*cough*armatures*cough*)  Finally, an importer/exporter needs 
to be tested against itself; there is nothing more embarrassing than an 
exporter that produces a file that the corresponding importer cannot 
read properly.

I don't know if this necessitates starting over, although if OpenCollada 
can't be maintained that seems like a pretty fatal problem.

(In general, I suspect Collada support in most software is half assed, 
because a comprehensive implementation is so so much work, and most of 
the time a developer of application "X" just needs to import/export file 
"Y" for  application "Z", so they only support that particular need and 
if it works for other files, good luck.)

To tie this up - talk is cheap, I don't have the time/resources to work 
on Collada support presently, so take this all with a grain of salt.

- Peter

On 1/4/2012 2:57 PM, Sergey Sharybin wrote:
> Hi,
>
> As everybody noticed current collada importer/exporter is very buggy which
> seems to make this format almost useless in Blender. And what's much worse
> -- we don't actually have developer who maintains this area.
>
> We discussed this already with Campbell and found that OpenCollada itself
> isn't actually maintaning -- there are only few commits in several months.
> Ofcourse it doesn't mean this library is useless and all bug from our
> tracker is related on that issues, but still.. Maybe the time have come to
> re-think this importer/exporter (investigate if it's possible to fix issues
> in clear way, check if design is good enough -- not sure, haven't touched
> this code deep myself)?
>
> Here's our proposal:
> - Move all collada-related issues into it's own tracker. Like it was done
> with BGE, it might help finding volunteer to fix them. Also, people will
> see that it's not actually core stuff and that it's community-supported.
> - Disable collada in release builds. It's not useable and only seems to be
> making artists disappointed.
>
> More optimistic targets would be find volunteer to pick up this stuff who
> will make it usable (maybe rewritting this stuff from scratch..)
>