COLLADA is a great standard for storing 3D scenes, but its flexibility may become a nightmare in some situations. While allowing multiple representations of the same data is a huge benefit for modelers since they can create a great variety of scenes, having to read and handle all of that data might become overwhelming for developers.
While I was importing joint animations, I realized that COLLADA files may specify samplers in several different ways. Is the file using baked matrices? Are samplers modifying only one transformation value per frame? What kind of interpolation is supposed to be used during the animation?
I ended up simplifying the process by constraining the importing process. For example, baked matrices must be used to indicate animations and only linear interpolation is supported. In the first case, input files may be slower to read, but the code to parse an animation is a lot simpler. In the later case, animations might not be displayed as the artist has defined, but that’s not an issue for moment since I’m not supporting skinning yet. Anyways, these constrains can be removed in the future as needed. The code for the COLLADA importer is now more extensible than before, although it still needs reworking in some sections.
So, after some time of coding I managed to read and store all animations for each joint in the skeleton. The next images show the skeleton in different positions:
Up to this point, I still need to define a way to handle animations once they are loaded since the current demo is only playing all animations one after the other in a loop. But before that, I’m going to finish this feature by implementing skinning support. I’m considering GPU skinning only since most platforms are able to do so. As usual, I’m going to leave the implementation open just in case that custom skinning if needed. Stay tunned.