Bohemia Interactive

June 24, 2007 – Ondrej Spanel, Bohemia Interactive

About Bohemia Interactive

Bohemia Interactive is an independent game development company, with studios in Czech Republic and Australia, founded in 1999, that focuses on developing state of the art computer entertainment software and the research of advanced graphics, artificial intelligence and physical simulation technologies for real-time interactive environments. Company’s debut release, Operation Flashpoint, has won universal acclaim for its realism of simulating military conflict situations, even to the extent where the game’s technology has been adapted for real soldiers to use as a special combat training application Virtual Battlespace that’s used by various military organizations worldwide. Company has been awarded Best PC Game Developer of the year 2001 Award and Rookie Studio of the Year Award at GDC 2002. For more information about the company visit http://www.bohemia.net. Ondrej Spanel is lead programmer of Bohemia Interactive, responsible for game technology design and development.

Abstract

The satellite imagery processing turnabout time was significantly hampering our productivity when developing a world for the computer game ArmA. Incredibuild helped us to reduce this time by allowing us to spread the processing workload across multiple already available workstations in the company.

The Challenge

With ArmA we strived to create a game with very large and at the same time very detailed terrain. As the most flexible and most photo realistic approach we decided to use satellite imagery. For quality reasons, the satellite imagery resolution we wanted to represent was 1 m. Besides of satellite imagery we have another layer with the same resolution determining surface type at a given position. To create a game which is compellingly large for a gameplay including vehicles and aircraft, we wanted the terrain to be size 20 km x 20 km in size. The total size of the raw data was about 3 GB, and the time needed to process the data took about 8 hours, most of this spent doing texture compression. Such a long duration of the processing loop made editing terrain very hard, especially once we entered fine tuning and bug fixing stages later on in the project.

The Alternatives

At times we tried to manually split the work across multiple computers, an approach we found very inconvenient, as it required cooperation of other users and significantly increased the number of manual steps necessary to perform the conversion. We may have been able to get some improvement by upgrading hardware, but since CPU frequencies have hardly increased since 2004, the gain would have been relatively low, and the only way to achieve a dramatic change was through some kind of parallelization.

The Solution

The terrain processing consists of a “world builder”, a custom application which processes the principal world file (elevation data and other information) and requests processing of textures for individual terrain segments from a “texture converter” process. We already had the source image split to moderately sized individual images, and it was the image to texture conversion which was the most time consuming part of the process. This sort of task is well suited for Incredibuild, because there are no dependencies between the individual parts.

The major obstacle we had was to avoid the builder creating false dependencies by waiting for data unnecessarily, because the builder performed some trivial work on each texture once it had been converted. For Incredibuild’s distribution to work, we needed to be able to generate several texture conversion requests before waiting for any of them to complete. We did this by returning a texture placeholder instead of the real texture, and the placeholder was resolved to a real texture only once the conversion process for all textures in the world was complete.

Apart that, all we had to do was to add a _P_NOWAIT flag when invoking the converter, and to introduce a simple process count guard to avoid creating too many processes at one time to prevent Windows from exhausting its process related resources.

At this stage the builder was ready to be accelerated using Incredibuild’s Automatic Interception interface.

It may be interesting to note that without Incredibuild, this sort of architecture would have allowed distribution of the work across several processes running on the single machine. Basically what Incredibuild offers here is the seamless and transparent distribution of the processes across the network, and therefore increasing the speed-up factor from 2x with dual core machine to 10x or even more using multiple workstations.

The above implementation was achieved by one programmer in about three days.

Benefits

The terrain processing now takes about 40 minutes (compared to the original 8 hours), which makes the whole process much more convenient and straightforward. Moreover, seeing almost linear speedup based on the CPU power connected to the build farm, we are now confident that we will be able to process even larger terrain data in a reasonable time by adding a more workstations to the process, which is something we predict we will need in the future.

Summary

Using Incredibuild we were able to significantly reduce processing times for the terrain data used in ArmA, with a moderate amount of work needed on our side.