Writing a Book, Requesting Fact-Checking

There isn’t really a forum topic for this type of question so I chose as best I could.

As the topic suggests, I am writing a book and will have one chapter that describes the pros and cons of the COLLADA™ exchange format. I haven’t used COLLADA™ before and I would like to clear up some things as well as get opinions from people.

Firstly, is there an official SDK for loading and reading data from .DAE files? I originally thought OpenCOLLADA was such an SDK, but I lost that impression when I looked at the binary-download listings for OpenCOLLADA Tools which show OpenCOLLADA for 3ds Max, OpenCOLLADA for Maya, etc. If this is meant to just open and parse a .DAE file, why are there specific versions for 3ds Max® and Maya®?

Because COLLADA™ is in XML format it is easy to embed custom data. But how do you go about that? Because if you exported again from Maya® over the same .DAE file, wouldn’t custom data be lost and have to be re-added? Or do the exporter tools try to preserve this when saving over a .DAE file?

And finally an open-ended question: Compared to FBX®, what are the pros and cons of COLLADA™? One that I know in favor of COLLADA™ is embedded physics information. Are there more material types in COLLADA™, especially related to physically based rendering, or is it easy to add such things? FBX® has only 2 material types: Lambert and Phong.
Anything else?

Thank you,
L. Spiro


As I understand it, OpenCollada includes an SDK to read and write DAE files, not just plugins for Maya / Max. The Max and Maya thing is only because each application has it own plugin format I suppose, I don’t think there are app-specific differences in the opencollada code linked to those plugins though.

I suppose that custom data could be included using <extra></extra> tags here and there. The spec itself says that collada compliant tools should always preserve extra data even though they might not understand it. So if you open a DAE file with extra data and then save it right away, that extra information should be there after the save.

I don’t know much about FBX, but having an open spec can be seen as a pro for collada too. Unless you use Autodesk’s FBX SDK, I don’t know of any other way of reading / writing FBX files. I might be wrong though. My main gripe with collada, right now, is that being a standard means that there are many different implementations and a lot of them are directly broken. So, right now, making my app compatible with collada means handling a lot of bugs produced by other tools and that’s a royal pain.

Thank you for your input.

The most case I see happening is that people keep their models in .MB format, make changes to them, and export from Autodesk® Maya® over the same .DAE file. This would, I imagine, erase any custom data embedded in the file.
.FBX has the same problem though.

When you refer to many different implementations, to what are you referring? Exporters and other tools used to create .DAE files? How decent is OpenCOLLADA at reading .DAE files? Is it buggy? Missing any features?

Also are there features in OpenCOLLADA to do more than just load the scene and let you pick out the data you want? For example, can it simulate the scene at any time in an animation? Can it evaluate animation tracks for you?

L. Spiro

That’s a different case, your starting point isn’t a collada file. But if you open a collada file with extra data that your 3d authoring tool cannot understand (let’s say it’s info for your game engine toolchain or something), make modifications to said file and the you save it back as collada, the authoring tool should preserve that extra data. I say should because that might not be the case depending on the tool.

I cannot tell you about how good OpenCollada is for reading files since I’m writing my own importer. And yes, I was talking about exporters used to create DAE files. For example: SketchUp’s DAE exporter tends to export files so weirdly formatted that it won’t be able to successfully import them back! The same goes for Max, the default exporter isn’t very good and you can create scenes that will generate weird files (in one test I assigned different materials to each face of a single cube, the collada file showed 6 different cubes instead, one for each material). Using OpenCollada’s Max plugin I get much cleaner files though.

WTR to your other questions, I cannot say because I’m not really using OpenCollada besides the Max exporter.

The cons of collada? 1) very complicated format. 2) the specification is too vague in certain areas, which means exporters export data in different ways. The cons of FBX: no documentation - not an open format.
OpenCollada is quite buggy when dealing with skinned meshes - that’s it’s weak point. Also, development of the plugins is very slow (almost at a standstill).
Blender did manage to create there own FBX importer without using the SDK. I think they used a c header file from the SDK as documentation and reverse engineered the rest.