This is a story about Collada, its current status and what we possibly can do in the future.

Where we are

The current implementation of the Blender Collada module is based on the OpenCollada C++ Library. OpenCollada’s goal is to fully implement the Collada standard. This library has been developed slowly over the years with a significant drop of activities in the years 2011-2014. Since then it slowly gained speed again, see the OpenCollada Contributor Chart.

The initial reason for why the OpenCollada library was chosen for Blender is somewhat shady, but the 3 main reasons seem to be:

It was available when Blender 2.5 was born
It provided an Import part and an Export part “out of the box”
There was someone who got it to work with Blender in a GSOC project

How it is implemented

Blender normally uses Python based Addons for implementing Data Importers and Exporters. But the OpenCollada Library is a C++ Library and it does not come with a Python API. Because of that the Collada Module is also written in C++ and it is fully integrated into the Blender main Program itself.

So what we call the Collada Importer/Exporter is a set of C++ Classes sitting in between the Blender Program and the OpenCollada Library, mediating data between the 2.

What’s wrong with it?

There are a couple of downsides with the Collada Module as we have it today. First thing is that on the Blender side many very basic functions are used which make it hard to follow what is actually happening and why things have been done as they are done. There is about zero documentation about why parts of the code are implemented as they are (in short form: Odd stuff )

On the other side the OpenCollada library seems to be used in some weird way. I am still not sure why the Blender interface is doing so much on its own, why the imported files are always read twice, why so many things are done in the module where i suspect the OpenCollada library has it already solved for us.

So here is the list:

The Module must be maintained by C++ People
The Maintenance is awkward due to self made Code Complexity (too much c++ inside)
The Library adds about 35 MByte to the Blender Distribution
The Importer and the Exporter have never been fully developed

What we can do about it

I see 3 basic options how we could possibly improve:

Full Rewrite

After fiddling with this module for about 3 years i finally feel confident enough to try a full rewrite. The idea is to reorganize the module such that it becomes easier to maintain and easier to improve. And at the same time make it easier to replace the current OpenCollada Library by something new (also based on C and C++) for example for a …

Hybrid Approach

We make use of the rather complete feature set of the OpenCollada Library (or a more recent replacement if such exists) on one side, but also add a Python API to it so that we get the advantages of having a Python Addon which can possibly be maintained by more people.

Full Replace

We can remove the Module and create a full replacement in Python. In fact for the Exporter side there are already a couple of alternatives available. However as far as i can tell none of the python based alternatives seems capable to fully replace what we have by now.

For the Importer side all i can tell so far is: This is where most of the trouble seems to be located. Collada is complex and very flexible. Trying to create a full featured importer based on Python might be a huge task.

What we will do about it

In the very first place we will attempt to simplify what we have and reorganize the library with the Hybrid approach in mind but without actually implementing any Python API. I think the best we can do here is to add 2 organizational layers between the importer/exporter and their counterparts (Blender and the Library).

IO – Shield is the only passway that we will allow to get stuff out of Blender or into Blender. This can be a very thin API (if needed at all) based on the Blender RNA module.
Compatibility Cloack is the only passway that we will allow to get stuff from Collada or to export stuff to Collada.

The cool thing about this approach is that we can put all Blender dependencies into the IO-Shield while we can put library dependent stuff into the compatibility Cloak. When we later decide to step out of the C world then we can convert the IO Shield into a Python API and then go crazy with our Python Addon.

Actually the IO-Shield might even serve as generic API for Importers and Exporters as the general questions about how to feed data to Blender or pull data from Blender should remain more or less the same for all formats… no?

What we could need from you

In first place we ask for your opinion about this approach. Is it feasible, can it be improved, are there alternative approaches worthwhile to look at?
But we also want to know in which ways Collada is actually used. All i know so far is that those who use it make heavy use of it.
I also know there are other groups out there in the wilderness of the internet who can not live with our Current implementation for one or the other reason. It would be helpful to get detailed information in which way the current implementation does not work (including demos how it fails).

Why i am doing this?

I think that Collada is an open standard and Blender should support this standard in the best way it can be done. I also believe that we can get most out of this by embracing existing stuff like OpenCollada or possibly other existing libraries (c or python) and help to improve what exists and not to get into “This stuff is odd, i can do better then that, take mine its awesome” attitudes.

And besides all of the above i just want to learn how its done. If anybody feels like they can actually take the lead here please step in. I would be more than happy with that. Until this happens i will do my best to keep this going and make it a successful learning experience