A break from Ogre

In my last post I was writing about dynamic animation. I was researching the topic a bit and made a small plan on how to actually implement the technique. As it basically boils down to three steps – ragdoll without any muscles, ragdoll with joints and an ability to move the body parts with them, actual animation by defining the movements using these joints and muscles – I started with the first step, which is my own ragdoll class. However, after working with the subject for some time I got tired of it and decided it was time for something else. I often feel like having an overdose of some particular subject, where I have the feeling it’s for the best to give the problem some time and rather concentrate on something else.

So I will be returning to dynamic animation at some point, but for the past week or two I’ve been going for something completely different. Luckily I’m going for a soccer game, which means there are a lot of construction sites to work on. Basically the game is divided to two parts – the actual soccer game on the pitch, and everything around it including the managerial and organisatory things like creating and updating league tables, calculating the results of the matches not shown etc. So I decided to take a look at the latter side of my project for some time.

In my first post I was wondering about which programming language to use with my project. I can’t remember if I wrote anything about functional programming languages back then, but ever since I realised how handy they can be when working with lots of arrays or lists (such as league tables) and AI (both the player and the manager AI) I’ve been wondering about using a functional programming language in my project. The problem is, I don’t have any experience in programming with them and they seem to have a reputation of being not so easy to learn once you’ve gotten used to the imperative style.

The good thing is that I’m willing to learn from my project. That was why I also went for Ogre and ODE; I didn’t choose them thinking I’d master them in a week, instead I was willing to make the effort and learn them because they’re effective, even if they’re not the easiest libraries to use. And since my past programs with AI haven’t really ended up as I wanted, I wanted to take a look at the world of functional languages. I decided I’d take the time to try and learn Haskell, a lazy, purely functional programming language. While I won’t go to details in explaining what that means (you can go check it out at Wikipedia or Haskell website), the point is that the code written in Haskell is supposed to be shorter, easier to read and to maintain and contain less bugs… If you know how to program in Haskell. So I’ve been going through some tutorials on Haskell (and will be going through them for a long time from now on, I think) and I’m quite impressed with it.

In my next post I’ll hopefully be able to explain a bit about how to use Haskell and how it could be used in my project. (At the moment I’m still too shocked about the new way of thinking to comprehend how I could actually program something with the language.) While I think I have a long way ahead of me with Haskell, I also have a feeling I won’t regret it. After all, I’m already now seeing programming somehow in a whole new way, so that I even see programming in C from a whole new perspective, a perspective filled with pure functions, lists and pattern matching… That can’t be such a bad thing, right?

Physics, more physics, and animation

Time for a small blog entry again. I’ve been going through the Ogre tutorials and after feeling more confident with the whole graphics rendering I decided it was time for the next step: integrating physics with the graphics. Ogre lets (or, as the critics put it, forces) the developer choose a physics engine suitable for his needs. I checked Wikipedia and the Ogre Wiki for some available engines and came to the conclusion that I’d have to choose between Bullet and ODE (I’d rather avoid commercial and closed source engines). Being impressed with the ODE documentation and the list of ODE users, I decided for the latter.

There are wrappers between Ogre and physics engines that make the life of the developer easier. The problem with integrating the two types of engines is basically that both Ogre and the physics engines have their own formats or classes for basic mathematical elements such as vectors, degrees and matrices and the wrapper has to convert them. Moreover, things like the Ogre timing system, nodes and entities have to be integrated with the physics engine. Since OgreODE, the ODE wrapper for Ogre, does not quite describe its functionality with as much detail as ODE I thought for a moment about just skipping the wrapper and using ODE directly with Ogre, doing the aforementioned conversions by myself – but after seeing the work needed I decided to go for OgreODE after all. The source code should be enough documentation anyways… Right?

After messing around with OgreODE a bit and trying out a couple of tutorials it does seem to work pretty well after all. My first test scenes involved the typical boxes bouncing onto the floor and each other, but soon I wanted to go and try out some physics that would really be useful for my game project, namely rag dolls and dynamic (procedural) animation.

I’ll explain quickly what dynamic animation is. First of all, there’s a nice video showing the technique at Youtube (link), the original thread at Ogre forums can be found here. (But don’t click on the links if you’re arachnophobic…) Basically it means the movements are not preanimated but calculated physically instead, and the characters move their joints themselves by applying forces on them with their muscles. This may sound complicated, but in the end it’s just a rag doll with enough intelligence to move itself. They can, however, be hugely flexible and can do anything without making the player feel bored. In other words, a character can really interact with the surrounding world with its limbs, i.e. when a soccer player gets tackled he falls realistically based on the angle from where the tackle came instead of simply doing a preanimated sequence.

The flexibility that dynamic animation offers is not the only reason I want to implement it. As some well known developers have said, a good developer has to be lazy. Manually animating all the sequences that a dynamically animated character is capable of would be way too much work. On the other hand, if only x animation sequences were to be animated, like a few sequences for the kicking, jumping and tackling actions (which would already be a tremendous amount of work), it wouldn’t really be any easier nor less work to make that look realistic in a soccer game than with dynamic animation. If I teach the players to do the actions with their muscles instead of animating them, I save the work on animating the falling down sequences (I just let them fly over as they simply follow the laws of the physics) and instead of doing the animation the traditional way I have to define the forces, vectors and angles for moving the bones and the joints, therefore having a lot of mathematical work instead of artistic work (after all, I’m a programmer, not an artist, and when in doubt, stick with what you can, right?).

The only problem with the technique is that there isn’t really that much reference for me to look for. There are a lot of scientific papers written about it (just google for procedural animation) and some code as well, but since I haven’t (yet) found anything about it for Ogre or Ode, it seems like this will be my first test to see if I’ve learnt enough about the APIs to create a solution to a “real” problem. So in the next few days (weeks, months?) I’ll be going through the theory of procedural animation and try to come up with a way of combining the Ogre meshes with ODE joints and motors to create a real, dynamically animated character.