A few years back it was looking like COLLADA was going to be quite a big thing, maybe at last a fairly standardized format for getting 3D assets from a DCC package into the tools pipeline of a game. And it looked like a good option for an indie developer that didn't want to lock themselves into a single 3D package by writing custom export plugins.

But I've not heard much about it recently. And Feeling Software, who had supported the format with their Max/Maya exporters and FCollada lib appear to have withdrawn any free versions of those tools.

Is COLLADA seeing much use these days? Are there any free/inexpensive libs/tools to assist in dealing with the format, or are people just reading the raw XML themselves?

Or is there a better option these days - say for an indie developer that wants to get models/animation from potentially Max, Maya, or Blender into their engine? - FBX? Something else?

Concerning the tools, my experience is that the popular solution to access .dae files is collada-dom. It only parses the xml and give you access to the tree structure. Originally developped by Sony, it is now an open-source project (and the reference implementation).

Recently, opencollada seems to get some attention, but I've never used it. It comes with plugins for 3DS, Maya, Blender, and an SDK.

COLLADA Refinery is a tool to process .dae files (eg, triangulate surfaces).

Concerning its adoption, most mainstream creation tools (3DS, Maya, Houdini, Blender, Sketchup) support it by default. However, it is possible to have bad results when importing an exported model between different softwares. You also have to be careful with the various concurrent versions that exist in the wild (1.3, 1.4, 1.4.1).

FWIW, the official twitter account for COLLADA often makes announcement of tools and applications that got COLLADA support. This can give an idea of the support in the industry.

In my experience, it's a good-enough way to exchange data between systems. From a gamedev point of view, I don't think it's a good out-of-the-box solution. It depends on what you do, but at this point, an importer that process the file (or the DOM) for your engine is likely to be necessary. I've also witnessed really slow importers, so for a game engine, I would go with a COLLADA converter, rather than an importer.

• People seem to miss the bit where it's not supposed to be a format that you load all your game models into your game with. It's a format that you can store and easily share between content creation tools. Your game was always supposed to have its own optimised format that you convert to, from collada. – jsimmons Aug 5 '10 at 1:26
• ...and as a format to share data between tools, it's a terrible idea except for the most trivial of datasets. Unless all of the 3D packages are going to render every COLLADA file the same, you don't get the cross-package benefits that were touted. – dash-tom-bang Aug 22 '10 at 9:39

COLLADA was over-complex in my opinion. Suffered from the designers trying to make it handle every conceivable combination of 3D asset; e.g. every possible vertex/index format and configuration.

Sounds great but in practice this placed a huge burden on any piece of software that needed to read the format.

It didn't help that every supposedly compatible tool had its own ideas about things like winding order, axis handedness etc. Trying to use it as an interchange format between DCCs plunged you into a world of miniature upside-down geometry, busted UVs, you name it.

What we need is a simple designed format that covers 90% of needs in a single, canonical way.

• Right now for the choices for game assets are .obj (if you don't mind not having animation and no compression), .x (if you're using DirectX) or some proprietary format. P.s. I would like to add a friend of mine is working on something called "OpenMDL" that is looking very promising indeed. – knight666 Jul 22 '10 at 10:25
• Indeed plus no standard libs and the ones that are available are buggy doesn't help. COLLADA is too bloated IMO and is trying to be all things to all people - that's not to knock the idea which is a laudable one – zebrabox Aug 3 '10 at 21:56

I think COLLADA would/could be much more useful if it actually had a standard and open implementation for reading and writing the format, in addition to the fairly scary XML definition.

Its power is also its failure - the ability to describe almost anything, and in a multitude of different ways, sounds great from the point of view of exporting but is a PITA to import and make sense of.

However if you persevere, you do get a format which represents pretty much anything you're likely to need, is supported by quite a few tools, and can be extended.

It's all too tempting to go with a simpler format, and then half-way through your development you'll realise you need some extra data, and there's no way of getting it.

Also, if this is for use in an internal production pipeline, rather than for general release, you can whittle down the definition and only support what actually comes out of the package(s) you're using, rather than trying to be overly general.

So yeah, it's flawed and complex, but it does work, and there aren't that many options out there.

• If you write an exporter and then later can't figure out how to export some new piece of data that you need, then you shouldn't be writing tools. Just sayin'. – dash-tom-bang Aug 22 '10 at 9:41

I know this topic is flagged as 'solved', but IMO you should look into FBX. Autodesk is using that format, and it's the exchange format of all the major 3D programs.