Monday, November 29, 2010


Ok, having added OgreXML support, and our own personal skeletal animation file format support, I decided to add COLLADA support to our skeletal animation system because art puke types are always talking about how great it is.

Now, COLLADA is a good idea that has been horribly HORRIBLY implemented. It is the very definition of needlessly complex and convoluted, the documentation is absolutely terrible, and to top it off, none of the exporters actually support the spec - only parts of it AND THEY SUPPORT IT DIFFERENTLY DEPENDING UPON THE TOOL USED. WTF? LOL.

Anyhow, I stumbled upon a real doozy this past week when supporting the 'library_animations' element. I came across a sample file with baked matrices (meaning that the rotations/translations/scales/et al. were all baked down into representation by a single matrix) that did something so bizarre I couldn't understand it for about 4 hours even though it was staring me in the face and even then I said "it can't be... It just can't be." Oh, but I was wrong, it was.

Apparently, COLLADA allows (and some exporters do this) animation data for a given set of keyframes to be exported not just as a giant clump of keyframes (all animations globbed together) but stored on an individual matrix element basis. I know, sound confusing/bizarre and you probably don't know what I mean by that so I will try to explain since I don't know a very concise way of explaining something that strikes me as so batsh*t crazy that I cannot fathom how some ultramaroon implemented this or though it was a good idea (maybe someone can enlighten me on this...)

What I mean is that even though COLLADA can already bizarrely store all animations lumped together as disassociated keyframes on a per bone basis (strange but I can understand why they might want to do this) storing a set of 16 floats per keyframe (representing a 4x4 matrix) - there is another format to the storage of this data that creates a child XML node FOR EVERY ELEMENT OF THAT 4X4 MATRIX AND STORES EACH KEYFRAMES VALUE FOR THAT PARTICULAR ELEMENT IN A FLOAT ARRAY.

If that still isn't clear (and probably wouldn't be for me because I'd be thinking - "no way, I'm not reading that correctly..." - I mean there's an actual XML element under:

     <animation id="MySkeleton_Root">
          <source id="MySkeleton_transform_0__0_-output">

If the file has, say, 600 keyframes of animation in it, there will be (no sh*t) 600 floats in a float array under that source ID that are meant to be stuff in 600 different 4x4 matrices in the position MyMatrix[0][0]...

It strikes me as absolutely crazy as a loon to see 16 entries under a given bone with each entry holding a huge float array representing an individual element of a 4x4 matrix. WTF?

Why, for the love of all things holy and good, would you not simply store the damn thing as a float array of 16 * 600 floats under a single element? The matrix is baked - you can't extrapolate the original DCC toolset translations and orientations (although you can pull translations and orientations out you have no idea whether they're the exact ones used by the tool to generate the matrix) so WTF?

Sorry, that was just the cherry on the cake of my dealings with COLLADA, the amazing file format that seems to be dying a slow death at the hands of Khronos (who I like, but man is this a weird thing they've got here.)

*** END OF RANT ***