Procedural Technology in Ghost Recon: Wildlands

Benoit Martinez and Vincent Delassus discussed the technical challenges of producing huge open world worlds and how new tools help solve them.

Benoit Martinez and Vincent Delassus discussed the technical challenges of producing huge open world worlds and how new tools help solve them. This article opens a series of reports, centered on showing various aspects of game content development, which could be automated with procedural technology. We thank Ubisoft and personally Benoit for helping us with this series. If you find the article useful, please share on Facebook and tweet. A lot of work went into this!

Introduction

Hello, I’m Benoit Martinez, I’m French and I was born in the mid 70ies. I’ve always been fascinated by games and eventually I managed to study 3d graphics. In 1999 I graduated from Supinfocom and joined a company in Paris named Darkworks. The team was amazing, there was a lot of enthusiasm and energy. I learned so much in many fileds there. Later on I joined Ubisoft Paris to work on Ghost Recon: Future Soldier. Then I started to work on Wildlands from the very beginning of the project.
I’m lead Artist and Technical Art Director.

I’m Vincent Delassus, 35 years old, I have worked at Ubisoft since I was 23.
First onPs2, and I’ve been involved in the development of the Ghost Recon brand since advanced warfighter 1. I’m an autodidact, and learned through various subjects on different positions: Artist, technical artist, technical art director, lead Artist etc. I’m Art director and Technical art director.

The Biggest Challenge

The huge open world definitely. Not only the terrain itself but all the diversity of 11 specifics biomes. Each with specific landscape, vegetation, rocks, building. Each biome being consistent in its relation to the world.

World Machine Houdini

We basically had to create all the pipeline and the tools from scratch, because it’s an open world, because it’s a lot about landscape and because terrain was very important. Initially we were using meshes, 1km2 terrain patches with LOD. Based on a World Machine height map we had a Houdini process to automate the tile creation and the LOD but this process was tricky to maintain with a lot of back and forth from Houdini to the editor and it was not flexible at all. No one except Benoit was using Houdini at the time and so he was the only one able to iterate. Obviously it was not possible to proceed like that in production and we decided to put a great focus on creating a custom terrain editor. The idea was to be able to sculpt directly in editor at any scale, being able to shape mountain or very small details. Initially the terrain height map resolution was 1pixel for 25cm, but sometime too much precision is just overkill. It’s was a very heavy set of data to maintain and so were the collision and navmesh. We ended up with a 50cm precision but since we have hardware tessellation on top of that, it’s way enough.

Houdini

The terrain is the very first step but then you have to fill it with content and potentially it could require a lot of talented artists to do the job. We didn’t want to increase the team size for many reasons. Because of the cost of course, but not only. A large team usually means a very hierarchical organization. We were a small team, we knew how to work together, we were very agile in our process and we wanted to preserve this. That’s why we decided to invest even more on Houdini as a platform to create tools.

When it comes to art production it’s all about how you balance 3 parameters: Team – Time – Tools.
Usually, you don’t control time, it’s a given data. In our case, we decided to push the tools instead of increasing the team size (number of artists). We never had more than 15 level artists in Paris to create all the assets and the world building. But no matter the tools or the strategy, it all was possible because the world building teams – Paris, Bucharest and Montpellier – were incredibly talented and focused.

Using Procedural Tools

We’ve been experimenting the procedural approach here and there since Ghost Recon: Future Soldier. The very first tool I made was just to help artists in placing wires. Artists were exporting a curve and from there we were able to tweak parameters, generate poles placement and wires in seconds.

Ghost Recon: Future Soldier – Very first Houdini tool

Then we pushed the logic further with terrain edition to terraform, carve road, add details and preserve UVs all along.

Ghost Recon: Future Soldier – Houdini Terrain tools

We quickly realize that not only the procedural approach was helping to get rid of tedious tasks but also that it was saving time. Artists were able to focus on quality, having more time to polish their level.
With Houdini, we’ve been able to redefine the tool creation process. Houdini’s learning curve is steep but not as much as you would think. They’re a lot of material available online and if you’re serious about it it’s only a matter of a couple of months before you can start to create your own tools. I used to be more on the artist side rather than the technical side, it all changed since the day I started to learn about Houdini. It totally redefined the way I approach art production.

Defining the Size

For a start we went to Bolivia for a couple of weeks, 4 teams all across the country. It was very important for us to study the architecture, the landscapes and the vegetation. We took something like 15000 photos and 15h of video. All along the production we relied on this database to create our tools and design the world, making sure that everything is consistent and authentic.

So far we didn’t communicate on the world size. We would like players to explore and be surprised without comparison nor expectation. We don’t think it’s a matter of size. It’s more about diversity and the level of detail you can reach. But still it’s the largest action adventure world ever made at Ubisoft, it literally takes hours to walk across the map.

We started to prototype using real world locations. In our first few tests we just took the elevation file and refined it in World Machine.

Results were good in terms of realism but it lacked diversity.

It was easy the get the data but we lacked good tools to edit and combine them. It’s very tricky to work with 16b or 32b grayscale in Photoshop, nor it was in any other app at the time, including World Machine. At the end we just did it from scratch in World Machine, using noise and erosions. It was not easy but we managed to have enough control to design the world as we wanted it to be. Nothing is random. Every river, every mountain is there for a reason.

We wanted the highest mountain to flow all the way down to the bottom jungle, all across the world. It was a massive simulation. It was not possible to compute such a big terrain at this resolution (64kx64) on one computer.

We had to do some custom dev on the World Machine. We requested some additional dev to Stephen Schmitt, author of the World Machine. He added an additional variable exposition to the tile rendering system in order to use with a dedicated render farm written in c#.

We ended up piloting World Machine and threw a computation every 3 days across 80 computers.
As the tiles have limited access to each other for cost reasons, the other challenge was to have a consistent erosion across different machines. To solve this we pre render the big eroded land mass in one machine at a lower resolution, then distribute micro erosion and other costly details on the render farm using the Tile system. It fixes 90% of the tile joint. But the World Machine generation was still not 100% deterministic.

Our lead graphics engineer was prototyping a demo of the terrain to display on Xbox one, so he integrated the new tiles every time, and we started some reviewing on console at a very early stage of the project. That was pivotal in anticipating any cost issue.

We used Houdini for many different things.

Manipulate the terrain to add extra details, such as roads and rivers.
Placement rules for objects (decals, forest, settlement/buildings, etc.).
Create specific assets
Here is an example of a tool dedicated to help artists create a building.

It’s no designed to handle specific cases but to create the generic part, and for that purpose it works quite well. It helps secure Metrix (window and doors size, windows and floor height, etc.) and it takes care of the UVs. Some polygon strips are generated to help blend some dirt on walls/ground intersections. All the details (windows, doors, propsing) are then manually added.

For settlements we worked on a full procedural approach.

The idea was to help the artists, giving them enough control to achieve interesting patterns, diversity and good looking settlements. It saved them enough time to manually add details and meaning to each of them.

No matter how good procedural generation is, it’s not perfect and it sort of need artistic intervention. How did you work this out?

We totally agree. Something we learned is to not mention procedural too much, because everyone just assume that “procedural” is like a magic button you would press to get a boring and dull result. Here we are talking about tools to empower artists, to give them all the control they need to build a full world. Nothing is magic. For each specific tool we work very close with a dedicated artist. He’s the one who decides how the tool is going to be helpful, what he needs and how he wants it to work. The key is being be able to build at a large scale and to save time. Then with the time that was saved, we can focus on detailing and pushing the quality in a way no procedural process could do so. It’s also a balance between where we use procedural and where we don’t. In some cases we need a full manual control and we would build a location completely by hand without any tool. Somewhere else we may want to manually design the boss location inside a village. But then we can use a tool to create the village around it.

Procedural and manual don’t mix very well. When you start to build on top of procedural you have to lock it. If you don’t, you’ll lose all you manual tweaks at the next update. Of course we have some workarounds but it’s not trivial. In most cases my advice is either to wait and lock the procedural data before you proceed, or to define a manual area and procedurally build around it.

At the end it doesn’t matter what’s procedural and what’s not.

Managing a Huge Project with a Small Team

We had 4 Houdini artists (including Benoit). We learned a lot during the production. We ended up using Houdini much more than I expected.

Something we learned is building (a lot of) tools changes the pacing of you production

left: Regular production. Right: Tools development (plateau) and new content layers (steps).

A regular production goes linear. You have a team and from day 1 they create content and build level/world.

When you decide to focus on tools you go through some plateau phases. It’s not easy because sometimes you just don’t know how long it’s going to take. But when the tool is ready, in just a couple of days you can push a new layer of content. And at the end you can go much further than what would have been done with mere brute force.

It’s exactly what happened with terrain, rivers, roads, railways, forest, settlements, mines, etc. Each layer gave us the base for the next layer.

One day there’s nothing but landscape and a week after you’re driving on roads across the world.

Everyone in the Houdini team worked on some specific tools:

Guillaume worked on all the backend and made sure the Houdini pipeline was efficient and reliable. He worked especially on the distribution of jobs to the render farm.
Erwin worked on the roads and the settlements.
Twan worked of the building tool, rivers, fields, and tools for the sound designers and for the game logic.
Benoit tried to keep all of that tidy, driving the philosophy and the architecture and I worked on the vegetation, rocks, decals, and power lines.

The biggest mistake you could make when you start to work with Houdini to design environment is trying to create a meta tool. A unique tool to do everything or even just too much. You want to split the tools, one tool per task. That way it’s lighter to process and easier to maintain. The tricky part being to properly define inputs and outputs for each tool so they can work together by referencing each other.
For example the bridge tool can work as a standalone but it’s also used by the railway tool to automatically place a bridge where needed.

Advantages of Utilizing Houdini

Houdini is a tool box. No matter what you production is, no matter the scale of it, Houdini can help you. You can use it to automate tasks, to create content, to help artists (or sound designs and gameplay programmers). It’s flexible and it’s powerful.

Houdini on its own is valuable but I have to mention Houdini-Engine. Basically it is Houdini core API and you can integrate it in you host application. In our case we did integrate Houdini-Engine in our in-house editor. It means tech artists can create tools in Houdini and any artist can use the tools directly in the editor. It is extremity efficient as your art team is more autonomous. Here is an example of how fast it can create a ready to use tool:

Houdini helped us think bigger and out of the level art box. We’re very happy with what we achieved and it’s exciting to think that we’ll be able to build on top of that to go even further.

We don’t compare it with NMS (which is a great btw). Totally different games and different content. Our world is unique with many specific locations and landmarks. It’s totally handcrafted with the help of tools, and there’s no “magic” seeds.

It’s a world made by dedicated and very talented artists who supported a vision and were able to bring life and tell stories. No tool can compete with that.