shiny toys

Hiren's already gone over the topic of long overdue posts, so let's just leave it at that.

My old lab has packed up and buggered off to Bris-vegas, and I handed in my PhD thesis to my supervisor for final review last December. At this stage, I'm still waiting for his comments so I can hand the damn thing in. Argh.

Right now, I'm contracting for the fine folks at Emotiv systems (yes, that's the same company Briony is at). Due to contractual obligations, I can't go into a whole heap of detail about what I do - the basic summary is that I'm a working as a research engineer, putting some advanced physics into interactive games.

And I get to play with shiny toys. Oh, so many shiny, shiny toys :) I've quickly expanded my repertoire of toolkits to include some game engines - notably Torque and Unreal Engine 3. Yes, that Unreal Engine 3.

And what an engine it is. The above clip (high-resolution version here - worth getting) is purported to have been rendered in real-time, in-game. Having mucked about with the engine, I can fully believe it. Visual realism in games is still improving at a cracking pace.

The way I see it, whether we are immersed in a game or not is now even more than ever in the hands of artists and asset creators. As the number of simulation variables increases - lighting & texturing, physics, character expression - the closer game engines get to something like we see in film and TV, requiring immense attention to detail. At the root then, this detail then only can come from artists and people who have the skill and technique to understand what the engine still can't do and work around it.

A recently added simulation variable is the burgeoning presence of physics in games. It's getting to a stage now where rigid-body physics toolkits are easily accessible to developers of all levels, and this is passed on to level designers and artists who are provided with 'studios' in which to setup and test their physics-enabled models.

In most cases, the physics is run as a 'ghost' environment, which mirrors what is rendered on screen but is not necessarily 100% in sync with it. Changes from user input are passed to the physics 'world', which works out how objects react based on this input, and the results are passed on to the graphics subsystem for rendering. This synchronisation problem can lead to all sorts of issues (see below).

Which brings me to my next toy :)

I've been lucky enough to get my hands on a physX hardware physics accelerator from Ageia, and works as hardware back-end for the Ageia physics API. It's simulation of cloth and fluids truly is impressive. They've even made their API, and a software emulation of the hardware (formerly called Novodex), freely available for for non-commercial use, which has me standing on my chair and cheering.

However, it's grunt lies with rigid-body dynamics, and, as such, I have to say I was a little disappointed. I've run lots of Ageia-accelerated simulations now, and directly compared the software to hardware simulations. The key thing that physX added was not speed, but scale. Even then, it didn't scale as well as I would have hoped.

This isn't a new problem. The (well publicised) demo of the upcoming 'Cell Factor', a showcase for physX technology, can quite happily run without physX acceleration and still be quite playable. In software mode, you miss out on some of the fluid and cloth effects, but it still looks quite shiny (especially with the HDR bloom).

 Is it just a driver or software issue, or is it a deep architectural problem with the hardware? My guess is that it's a combination of both. As I mentioned previously, the physics world is run in parallel to what is rendered on screen, so synchronisation between these two becomes a critical issue. Game designers have to be careful to ensure that user interaction doesn't drive the physics system into doing something it isn't supposed to * (see notes on interpolation here), and my hunch is that this problem is coupled with a lot of lag created transferring the locations and transforms of the objects from the physics card, via the CPU, to the objects on the graphics card.

From reading the API, I also wasn't able to work out if it was possible to extend the hardware capabilities to run simulations for volumetric objects via mass-spring simulations (or something similar). This is pretty disappointing, as my own (admittedly biased) take on physics is that soft-body dynamics are the next big step in real-time physical simulation.

There seems to be some sort of evil bottleneck, and other users seem to have found the same issue. We'll have to wait and see if future driver revisions will fix this up, or if it truly is a hardware architecture problem.

I won't go into GPU-based physics as an alternative right now - this post is probably already a bit too bloated ;)

 * Note that Ageia have taken some steps to eliminate this particular problem via their continuous collision detection system.(back)