[Bf-committers] Collada importer/exporter kickout

Juan Linietsky reduzio at gmail.com
Sat Jan 7 23:34:29 CET 2012


I reply as a middleware and tool developer, not as blender developer. This
may not be the place, but I believe my concerns also cover what Blender is
doing. My problem with OpenCollada:

1) It's way too big, and most apps don't need to either import or export
most of the format. Take a look at my Python exporter, which does most of
the job and it takes much fewer lines than even an interface with
OpenCollada. It's a lot of code to add to a project/repo and enlarges the
binary unnecesarily.
2) A strong point for using a library such as OpenCollada is proper
validation of the incoming DAE files. However, in the real world, it's easy
to find sightly broken files that you would rather import anyway than being
format nazi and refuse the import. Being honest, not even OpenCollada
plugins for MAX and Maya open their own DAEs most of the time.
3) It's been a lot of years and I still can't understand why there is such
a good support for MAX and Maya, and zero Blender support. Aren't Khronos
and ithe companies it represents supposed to fund and/or encourage adoption
of their format, yet the most open of the 3D modellers does not support the
most open 3D format?
4) Collada is an open format, but most apps that support it export their
data in different but valid ways. An example of this is the export of
skeletons, the usage of the inverse bind transform, how named/vs unnamed
bones are used, etc. Most apps that wish to import Collada don't work
internally like Collada and already have to do an important effort to guess
what the DAE layout looks like. OpenCollada is just too "general purpose"
and does not help this situation. Back then, other implementations such as
FCollada provided several tools that aided in the guesswork or provided
data the way it was meant to, so at least you could save writing some code
or doing some guessing.
5) I don't think blender should have "yet another DAE importer/exporter",
but something custom tailored to it's needs. I already wrote several
Collada importers for middleware or propertary game engines and can attest
that most of the work is not really importing Collada itself (what
OpenCollada does), but guessing how the Collada file is laid out and how to
translate that to the way Blender works. Using a large library such as OC
only adds an unnecesary layer of complexity at the simpler part of a
problem.
6) Collada is a very outdated format at this point. There is no support for
constraints, material support is still really poor (still no official
support for normal mapping or displacement mapping, let alone any sort of
node-based materials), multiple texcoord support is broken because each app
exports it any way it wants, and many other issues. This could be solved
simply by going the FBX way and exporting blender-only extensions (besides
the standard stuff) in a DAE, describing the full blender material or
something, so importers can do the best at guessing, and save artist time
from having to reimplement materials all over again when importing. I'm not
sure how well can OC do this. Exporting custom properties is also really
useful.


Cheers

Juan Linietsky


More information about the Bf-committers mailing list