Winner of 10 E3 awards, HAWKEN is a Free-to-Play online FPS developed by Adhesive. Built using the Unreal Development Kit (UDK), it features giant robots fighting in a ruined city.
The video below shows a HAWKEN demo level that we showed at GDC 2013 and other events. We designed it from the ground up to be completely destructible and support multiplayer.
We used APEX Destruction to create buildings with walls that crumble, leaving thousands of GPU rigid bodies strewn about the level. Here’s a look at how we did it.
What is APEX Destruction?
APEX is a suite of products that we built on top of PhysX to make it easier for content creators to put physically simulated effects into games. APEX Destruction has two parts: authoring and runtime. The authoring can be done through the PhysXLab standalone tool or with our plugins for Max and Maya. For destruction, the artist imports level geometry, and then specifies how it should break. The APEX runtime then takes these files and uses PhysX to implement destruction in response to collisions.
There are two possible methods of doing destruction: pre-fractured and runtime. For this project we used pre-fractured destruction, we designed how the level geometry should fracture in the authoring tool. When destruction happens in the game, APEX swaps the un-destructed asset with the pre-fractured asset and then PhysX calculates the motion of the chunks. The pre-fracturing is done in a hierarchical manner. In each successive level of the hierarchy, the tool (or artist) splits each chunk into multiple smaller chunks. This gives the artist a lot of control with how the initial fracturing occurs at the coarse levels, and allows the player to break big chunks into smaller ones. This also provides an elegant way of dealing with Level of Detail (LOD) within the game, as well as scaling from low end platforms to machines that can run destruction on the GPU.
HAWKEN is a networked multiplayer game. What challenges does this bring?
One goal of this project was that destruction should affect game play. For example, we wanted to make it possible for you to blow a hole through a wall and then shoot through that hole at an opposing player.
This means that destruction had to be synchronized over the network. We had to make sure that all players would see the same shaped holes in the scenery, however the exact motion of the fractured debris was not critical to game play, so that did not need to be the same for all clients. As a result, we could make the debris more plentiful with higher detail for players with more powerful machines. This is where GPU acceleration becomes important.
So how does the destruction scale?
When a wall gets destructed, it breaks into chunks. The smaller and more numerous the chunks, the cooler it looks. As HAWKEN is a multiplayer game, many walls can be destructing at the same time. Without GPU computation, it is only possible to simulate a small number of chunks in each wall. With GPU acceleration, hundreds of chunks can be simulated.
Why can the GPU simulate more chunks?
Simulation is naturally parallel. Each chunk can be simulated on a separate thread with communication between threads when objects collide. CPUs can run tens of threads at once, but GPUs can run thousands of threads at once.
Since the GPU can do more chunks, does authoring GPU content cost more art time?
No. The tool chain can automatically produce higher levels of destruction detail, which can be controlled by the content creator. One method of authoring destruction is Voronoi fracture. The authoring tool cuts up objects according to placed points. They can be placed at random, making it easy to add more detail by adding more points. This means that it needn’t cost more to support higher resolution destruction on the GPU.
What was particularly hard about the HAWKEN demo?
Almost everything in the level is destructible. This is not typical of most games. If two adjacent walls are destructed, then the debris from one wall can add to the pile of debris from the other wall. Due to the parallelism of the GPU, the simulation handles the changing workload size gracefully. Still, care must be taken to ensure that the lighting and rendering in the game can scale similarly.
Many game engines are designed to display a few hundred dynamic objects. Debris may add tens of thousands of objects, so we had to make sure that the game renderer could handle this.
For this demo, we deliberately went over the top with the detail and quantity of destruction to showcase the technology. With a full game you have to design the destruction to maximize the visual appeal, while minimizing the simulation and rendering cost.
What is hard about doing rigid body dynamics on the GPU?
Some types of physics are easier to map to the GPU than others. For example, in a grid-based fluid simulator, the data can be laid out linearly, every thread needs to read about the same amount of data, and every thread does about the same amount of work. Yet the world we live in is very sparse, environments are huge, some areas have lots of solid matter, and others are just air. The distribution varies considerably. Also, destruction looks most impressive when you have a wide range of object sizes. This means that uniform grids don’t work, data has to be gathered from many different places in memory, threads process different amounts of data, and that takes various amounts of time. It is a complex problem to solve. Fortunately, PhysX GPU Rigid Bodies (GRB) takes care of all this for you.
How do developers get hold of APEX destruction?
To find out more about downloads, licensing and other issues, head over to the download page on developer zone.
Where do you see physics and simulation in five years’ time?
We see physics resolution scaling just like graphics resolution did. Remember when you played DOOM for the first time at 320*200? You probably had an idea of how much better it would have looked if it were higher resolution. Then resolution got better every year, until we got to where we are now, with screenshots that can look indistinguishable from reality.
Physics has the same evolution ahead. We’re still at the 320*200 stage, in the Hawken level the walls are breaking into chunks about the size of basketballs. Every year the chunks will get smaller, with more varied sizes and more geometric detail in the chunks. In five years, we’d like to have complete scalability, crushing big boulders down to specks of dust, but we’ll see…
To find out more
Head over to NVIDIA Developer Zone to find more information on APEX, PhysX and other technologies from the leader in visual computing