I know Collada importer / exporter is problematic (I wrote an importer for my engine and I know that everything in the Collada can be stored in N different ways).

- If you want to use the model in Second Life / Google Earth, you have to use Collada, if you want to use models in engines WebGL/Flash3D practically have to use Collada (is there any web engine with FBX importer?), Most game engines use Collada for importing data (support for FBX a few). FBX exporter also has bugs. Well, that FBX is in a blender, but it is not usually an option for people using Collada.

- If someone uses Collada it not for the base mesh + uv (then using *. obj) and for skeletal animation, lights, cameras and their animation (motion, color, light and their intensity), multiUV (uv for color, normalmap ... + uv for lightmap). And all this in current Collada exporter works well.

- No other exporter does not work here as well as Collada - ofc has bugs, but it has nothing what could replace the Collada in this task. In the future, Alembic can replace Collada, but not for several years.

IMO, better to leave Collada, until you will be able to replace it with success to other formats like Alembic (FBX is not popular in the software and you can not replace him Collada in most tasks).

On 7 Jan, 2012, at 12:30, Ton Roosendaal wrote:

as well (to khronos, opencollada team, etc). I don't want to blame it on the hard working devs here. We do have collada IO work at some level, and that has been proven useful in several cases. The job is just incredible hard to achieve.

exchange format would have done the job as good. Tried FBX?

the job already. It is probably a few days job for a py scripter.

feature work that's meant to be able to exchange (I+O) full shots or game environments, with character animation and so on. That's what Collada was designed for, and that's a target we can't support.

on

trunk.

which

in.

bugs