Published on 3/9/2012
Animations. I've come to realize that this is a very important part of game development. Of course there are various different types of animations, and in this blog post I'm going to talk bit about hierarchical ridged body animation.
So what exactly does that constitute? Well firstly, I'm not even sure that it's the correct term - it's just what I think it's called. But basically it's animating objects that doesn't have skeletons. Skeletons and thus character animations through skin modifiers is a whole different sort of animation, and also on a whole different level of complexity. I dabbled a bit with that in the MiniLD submission "Mommy there's monsters". But for Stingray, here, today, I'm not doing that.
What I'm talking about mostly mechanical objects that have different parts, and each part can rotate/move to a certain extent, but is also subject on it's parent's rotation/movement. A good general example is robot arms used for vehicle manufacture and production line stuff. The upper arm is connected to a base, which can rotate around the vertical, turning it either left or right. The upper-arm itself is constrained by it's mounting point, and can only lift and lower. The lower arm has the same constraints, but is subject to the upper arm. And so on. This situation is prevelant in Stingray, specifically with the mounted mini-gun on the front of the chopper. It's mounted to the body where it can turn around. The gun itself can only be lifted or lowered. Together, the movements of the two parts allows the gun to be aimed almost anywhere.
Now, I realise that most middleware solutions (UDK, Unity etc) has implementations of this which is (probably) easy to use and setup. Since I'm not using any of those, I had to build a small system to handle that and to configure it quickly. So far it's not a very robust system, and I'm sure there are many situations which it won't be able to handle yet. But I'll expand it as I need to. For the moment, however, it's a simple implementation with a small config that does what I need it to do.
In the image you can see the two different pivot points. The mounting bit, which turns left or right, and then the gun which is linked up off-center from the mounting point. The gun's position is dependent on the left or right rotation of the mounting.
Each object that needs to be included in the hierarchy is listed in the XML, together with which type of animation (rotation or translation) and it's own constraints in terms of the three axis. In this example, the mounting can only rotate around the Y (green) axis, and the gun can only rotate around the X (red) axis. Optionally, each object can then be linked to a previously configured item in the list and the constraints of this link, the inherited movement, is also specified in terms of the axis. So the rotation of the mounting around the Y axis causes the gun to also rotate around the Y axis. The tricky part here is that the gun's pivot should be rotated relative to the mount's position, and not relative to the world origin, and you have to keep in mind which transformations is applied before or after the model transformations in the .X file. But like I said, it's pretty basic, but it's a solution that works for now and which has a very small footprint.