Well, after implementing FBX import to my humble software, I’m now implementing COLLADA import. And since I wasted so much time with it, why not waste some more time talking a bit why COLLADA failed…
First, it’s a format with questionable complexity and choice of XML schema. It has also questionable choices in the schema itself. However, I don’t think any of this was the main reason for the failure. Any software has some level of these issues.
The main part of the failure is that neither the original authors, nor Khronos it seems understood that the single most important factor to succeed was to properly make the project open source. Yes, there are at least 3 open source implementations of COLLADA - OpenCOLLADA, COLLADA-DOM, FCOLLADA. IMO, all of these are bad.
Why open source is so important.
- because it’s a lot of work to get the importer/exporter framework right. Yes this is one big reason, but not the main one.
- because COLLADA is supposed to be an interchange format so all applications must ideally use the same framework. This should have been your main goal! COLLADA has an extension mechanism, and everybody complains about it. The problem is not that mechanism, the problem is that nobody will actually implement it for other software! You need one open source library, that is good enough so everybody is using it, and want to add any custom profiles directly there, so everybody else will get the same level of support.
Why the current libraries failed.
- FCOLLADA - abandoned long time ago
- COLLADA-DOM - abandoned. Has different headers for 1.4 and 1.5 profiles. Uses too much external libraries (like boost). Uses DOM which is not ideal.
- OpenCOLLADA - mainly targets export. Semi-abandoned. The import functionality is unfinished, it creates it’s own profiles. Who will read it? Even OpenCOLLADA itself doesn’t… It has just a callback - here is some data that we don’t know what do to with. Do you realize, this is the main problem, the library itself should handle these extension - this is the whole point to make things work in the same way everywhere. But the library currently doesn’t import even core things like animation clips, different effect profiles, asset descriptions, etc… It crashes on import errors, doesn’t have custom allocators, custom IO. The SAX implementation itself is questionable. It’s far from production quality. Except Blender, not sure who else is using it. Not Autodesk which have their own implementation… Not OpenSceneGraph which is using COLLADA-DOM…
Well, I don’t know the whole history, but this is the main issue - no feature complete single open source library that makes all software developers want to use it, and extend it. Ok, I understand there are at least two big issues here:
- most developers are lazy. They want things done for them
- most companies prefer to invest in their own closed source solutions. They also change focus, close divisions, etc. I don’t know why Sony abandoned this project or just don’t care to develop it publicly as open source. But this is a fact - no other big company will go and support it, at least to the extend it requires.
So, what is the solution - IMO - use more natural open source development, decentralize, but still provide some sort of funding and guidance. There are individual or small developers that will want to work on COLLADA, but doesn’t have the financing. I still think this will be much cheaper then getting a big company involved. There must be still someone there that actively manages the project and shows some constant progress, so people know the library is not dead and has vision for the feature. The main difficulty is how to manage proper direction of the implementation. There are already 3 big libraries, IMO we don’t need yet another one. Maybe get people involved to discuss which is the most promising one, which has the best direction, fix it and start using it as much as possible. Using different implementations everywhere is terrible specifically for COLLADA. It’s not just wasting huge effort, it’s failing to achieve the main goal - really rich interchange format.
Until this happens, I will do what the rest of the industry does - put COLLADA just to say they support it, and otherwise work mostly on their FBX implementation. For me, most promising is OpenCOLLADA, although I would probably fork it to make it a bit more usable. For example - it can create perfectly fine DOM, it’s just missing proper interface. Why this is not there? I will need also to make the SAX part more flexible. For example - I want to say - SAX parse only the meshes, for the rest I want DOM access. Or tell the library where to store the heavy source data, and access everything else in DOM fashion. The library currently loads complete objects. What happens if I want to load a scene with one huge mesh? It will basically load everything like DOM but with the terrible (for COLLADA) IWritter interface. Why it’s terrible - because COLLADA doesn’t enforce an order that is easy to load. I would prefer either a low level library that just gives me what was just parsed without allocating any memory on its own, or cleverly designed hybrid library which has very flexible way to offload memory allocations to the application, and provide easy DOM model.