Feisty old XSI

· by Steve · Read in about 3 min · (554 Words)

I’ve been wrestling with XSI over the weekend trying to figure out how to do the last part of the pose animation support, and I’ve made far less progress than I’d hoped because I have been having problems figuring out how to extract the information I need. XSI’s API is actually quite pleasant to use, and I generally mess about in the embedded script to feel my way to the data I need, then write it properly in C++ for which the interface is anagolous, which is nice. However, the API is also quite generalised, with the terms ‘source’ and ‘parameter’ appearing on lots of different objects with subtley different meanings. It’s all very flexible and generalised, but it can be quite frustrating to find what you need sometimes.

I finally figured it out, but now it’s past midnight so I’ve just saved my script and will write up the C++ version another day. I’ve also just realised that I’ll have to alter the skeletal animation export, for which I’d used a sneaky cheat for supporting multiple animations which unfortunately won’t work any more when I add pose animation.

The reason is this: most exporters deal with multiple animations by simply splitting up the timeline - frames 0 to 29 are ‘Walk’, 30 to 59 are ‘Run’, etc. XSI has a pretty advanced animation system and I’d found that with skeletal animation you actually could get away with pulling the animations directly out of the available animation source list, rather than the real timeline (the ‘Mixer’ as XSI calls it) - this means you don’t have to deal in time chunks. Works quite nicely - except in order to sample IK into FK, I did end up having to automatically place things in the Mixer, play them back while sampling, then remove them again. Worked ok though.

The problem with pose animation is that there is no master animation source like this - the animation sources are just the poses; the animation itself is entirely composed in the mixer (because of course it’s all about mixing those different poses at different weights, at different times). Therefore I have to read the data from the mixer, and I also can’t afford to mess about with the contents of the mixer for my IK sampling since I could mess up the pose animation stored there.

No biggie; I’ll just have to revert to the old ‘time chunk’ method of dealing with multiple animations. Luckily because XSI’s animation system is very well structured, I can actually identify potential ‘break points’ in the total animation timeline and automatically populate the animation list anyway with what is probably mostly correct, so it won’t be too much manual work for the person exporting to figure out. It also has the added advantage of automatically dealing with combinations of skeletal and pose animation, and combining 2 or more sets of skeletal animation in the mixer to produce a more complex combined animation for export. IK sampling should work the same way. All in all it will be a bit of reworking and re-testing but the result will be worth it. It does mean XSI users will have to adjust to the new way too, but since the use of the mixer is probably intuitive anyway I doubt there will be problems.