Tuesday, August 30, 2005

TrueAxis as a new physics engine

Lately, I have been working on new physics engine to replace a rather outdated ODE physics engine. ODE did a good job of starting the project, but its limitations have started to bog down the performance of the game.

What are those limitations? The main ones are inability to handle a lot of sleeping objects. That is, let's say we have 1000 boxes laying around the scene, while we control a tank moving around. A decent engine will be able to quickly parse out which objects need to be tested against, but in ODE collision detection is not optimized, so the product is poor performance. This is important, since I do expect all scenes to be like that: lots of sleeping objects. The second reason is instability: sometime ago I had to tweak things nicely to have more or less stable environment. But still I am running the simulation at 100 times per second, just to keep things from bouncing too much, yet it is still visible in demos. This is not only annoying but also eats up CPU.

Why TrueAxis? I had several requirements when choosing an engine. First of all, it has to be stable and perform well. Most engines other than ODE already do that (although not always for free). Second, it must support Linux. It is really hard to give up ability to develop under Linux. ;-) This cuts options down to two engines: Newton and TrueAxis. Now, this choice was easy since two engines seem to have gained a certain personality: Newton with correct physics (but slower?) and TrueAxis with handling of fast moving objects (but less correct?). My choice was a better performance for a price of less precise simulation and with an option of using super fast objects for missiles.

Any programmer out where will think: "Gee, moving to a different API, good luck on migrating your project." Luckily, I have foreseen this, and so used an abstract physics layer: OPAL. This way all I need to do is write a plugin for OPAL, without changing a single line of code in Ukrainian Rumble. Well, maybe some parameters would need to be changed around but that is handled in XML configuration files.

So, for the past 3 weeks I have been working on this plugin. It is not really hard but is time consuming. OPAL provides a lot of features, and I do use a lot of those features, so even though I implementing only stuff that I need, it will still take a bit. But I am getting close to a certain milestone: just a few things left to do.

Thursday, August 11, 2005

Clean up stage.

After having added particle effects for any broken joint, and thus any destructive event, I have distributed the link to the latest demo around Internet to get some feedback. Maybe people are just nice, but the comments were generally positive. What is more important is that I have received a number of suggestions about the direction of the effects and features that I should push in. Many thanks to those folks.

One of those ideas have led to think of a way to overcome GPU bus bottleneck. Here is what it was: GPUs have been developed and optimized to handle large chunks of mesh, however, it does hot handle well, large number of meshes. 10000 triangle in one mesh is MUCH better than 10000 meshes with one triangle. Here's a link that describe this in more depth.

Why is this important to URumble? Because the physical simulation is bound to have many independent objects, thus meshes. So, this is has to be dealt with somehow. Luckily, the framework allowed an easy implementation of the idea. Tanks in the recent demo are represented as a complex object consisting out of a dozen independent objects. Here is what happens now: once a tank goes to sleep (all its bodies stop moving around) its meshes are build into static mesh, and this new mesh replaces old separated meshes. The only downside is extra memory usage, and slow downs when builds large meshes.

Overall, the approach brought a huge performance boost, sometimes it doubles the frame rate! At the moment I am considering bringing this method to a large scale, when the entire parts of the scene will be built into static meshes. This will require some special division of the environment, possibly via use of octrees.

Other than that, a lot of time has been spent into cleaning up the framework and its interfaces, which led to creation of a few minor tools. More are scheduled to come as they approach a certain level of usability.