In the little free time I’ve have/had, I’m working on a Collada importer for my home engine. Its all going fairly well, have got to the stage where I can import meshes and materials (common and fx) into my home geometry optimiser library and spit out my engines compact binary format. Now I’m onto the trickier bit of hierachy and transforms, the approach I’ve been using (and sure most people do) is a transform consists of a single translation, rotation and scale per node (all of which may be animated). However Collada is using a different paradigm, each node can have a unlimited set of these SRT transforms (and a few other mainly for cameras) that have to be applied in order to create the final transform matrix.
At first I thought yuck as all the additional work but now starting to warm to the idea… The reason its starting to look neat, is that you can add any arbitarly complex motion without adding scene graph nodes and as I generally dislike scene graphs node architectures as much as possible thats cool… From an optimisation point of view, I can collapse any transform before an animated transform anyway which for static nodes means its exactly the same transform.
I think to make it work for run-time system, I’ll need my transform object to have a bit of auto-optimisation logic… just like my current one has a local and world matrix cached, ideally this object would evaluate the transforms and cache the results, only having to invalidate when the game or an animation changes one of the transforms… Tho I worry bout the size of things with that… One of the things I’ve learnt from doing the HS armies is memory for hierachy and animations can eat a lot of space… Course for what I’m doing its less of a problem, but it might also be pre-optimisation, assuming I have the standard local and world cache, the only extra cost its re-running thro the transforms when something changes… hmmmm
The other problem I see is one of usage, what does node->SetTranslation() mean? Are you simply adding a new transform or changing and existing one? I really haven’t yet got what that means, cos while multiple transforms per node may be neat I certainly don’t want to lose the nice easy interface the old system gives you for implementing the game design…
The other option is stick with a normal SRT node structure and convert Collada transforms into it, the problem is then I have to write an animation convertor, cos potentially I need to generate new curves unrelated to the original Collada one..