[Bf-committers] Collada importer/exporter kickout

[spatial]

> Is anyone using collada successfully for interchange character
> animations between content creation applications?
> (not export to game engine but actually move mesh+rig data between
> apps for further editing).

Ok an example:
Its currently the only way to import LW scenes in a reliable way into 
blender,  the only problem I do face is a different camera orientation 
axis wich can be solved by exporting the camera motion mapped on a null 
object with a non animated camera parented to  it.  (ANd reroriented in 
blender)

As for importing additional vertex deformations inside blender, I do 
usually rely on an additional mdd file , to avoid the problems from the 
beginning,  wich is, from my perspective, a common strategy.
(And btw a reason I do use the existing mdd modifier patch, since it 
allows a non destructive workflow between both applications...)

I also used it to import some daz characters.

> again, would be nice to hear some example, even anecdotal as to what
> isn't working in FBX (assume you mean exporter since we don't have a
> stable importer).
Nope _I am_ talking about the importer. FBX export is great.. this is 
really well done . And yes, its defintively a lot more reliable than dae.
But the original idea discussed here was about kicking both.

> FBX was written for Kaydara Motionbuilder, which I used as a
> reference,
Ok, could be, but I think you get the point:
You do have an application wich you can use as a reference, wich collada 
actually hasn't.  If I do send you an fbx wich seems to be correct and 
it doesn't show up correctly in motionbuilder, you can actually blame me 
or my program... or better, even find a solution to satisfy me without 
breaking the big scheme.
As for a dae, you can'tt nothing to rely on such a thing.


> Otherwise having overly specific blender/collada format runs the risk
> of nobody adopting it and looses a lot of blender developer time.
Yes, but thats a general issue developers of all applications trying to implement dae
currently have to face. Point is, they can't even use market share or popularity as an actual
guideline, since this is actually well covered by... yes fbx.
So the only logical alternative they do have, is trying to cope with as many as possible dialects
as possible, and as a result, creating a new one: We got the Houdini dae,
the Autodesk dae, the c4d dae.. and so on.

So this isn't that much about getting actually more mantime into the exporter/importer or
into opencollada but first more about getting Khronos making a public statement that
"application X is 90% conformal to dae. (Stating wich parts aren't)".

There a several reasons why I do think blender is an ideal candidate for it :

a) all collada devs can access it
b) it contains a broad range of the dae features.
c) changes are documented,
d) unconformal behaviours can be identified and corrected.

On the other hand, this _is_ very ambitious. So a different program might be
really a better option.