Creating Terrain for Floating Islands Using Houdini

Presentation

My name is Youmna Sahab, and I graduated this year from Rubika, France, with my master's degree in Game Art and Management. I'm specializing in Houdini and technical art.

I was introduced to Houdini at Rubika and chose to further my knowledge of the software because I knew that procedural workflows would mean saving a lot of time on large productions, as well as improving efficiency on repetitive tasks, so I started doing my own projects. At first, I mostly learned Houdini autonomously, so I can safely say that if you're interested in starting to learn Houdini, there are a lot of resources out there and a nice community.

Personally, my knowledge really flourished in my internship at Periscope Game, where I worked with a team supervised by Vadim Samusenko and learned more about pipelines and programming. At the moment, I'm working at Ubisoft Paris as a technical artist assistant.

Today we're going back a few months in time, in the context of my master's project, Wandering Clouds: a solo exploration and platform game that we had to finish in June 2023.

The Context of the Tool

In January 2023, my team and I found ourselves restarting our project from scratch. It was a tough choice to make, but it was for the better.

We realized that even after rescoping, we would not be able to finish the game, especially the level art, in the time we had left (6 months). We started discussing some solutions to ease the level art pass, one of which being a platforming kit that the level designers would use for their blackouts, on top of which we would add foliage and other props. That solution meant having a sharper and less organic environment, as well as having to follow the metrics of the controller which, at the time, was undergoing a lot of change. It was a stressful situation, and we couldn’t afford to lose time. We had to go for a more flexible approach that would be fitting for everyone in the team.

The Idea

When creating a tool, the most important thing to know is what geometry input you can have, as well as what result you want to output, but most importantly, what parameters you want control over.

To automate a process, I usually try to see how things are done manually, then try to optimize some repetitive parts of the pipeline, by making it more flexible, or a tad more automatic. In this situation the idea for the tool and its inner workings came from a test made in the period of rush: Clément Pétiard, the Environment Artist I worked with, took the initiative to use the level designer’s blockout and terraform it in ZBrush, then vertex paint it in Unreal Engine to test the visuals we were looking for: it was extremely useful because we could test the artistic direction as well as understand where we had the freedom to operate, as artists, and where the level design had more importance.

Unfortunately, this process was destructible, meaning that all the terraforming work, asset placing, vertex color, etc. were bound to be lost if any changes occurred in the level design. It was also not game-friendly in the long run. I proposed to create a more “iteration friendly” approach, by taking 7 days of my schedule to prototype a tool that would do exactly that and give a more optimized level art, using the terrain and layers of Unreal Engine. If the results weren’t satisfying, we would fall back onto the platform kit and rescope the level design depending on the time we had.

The Creation Process

As per usual, when creating a tool I like to see how everybody works so that it suits their needs without disrupting their habits too much.

• Level designers wanted to easily convert their blockout meshes into terrain, especially for the large islands, and to efficiently give a “natural look” to the non-gameplay parts of the islands
• On the level/environment art side, we also wanted some control over this “natural look” as well as create some materials semi-procedurally ( dirt, grass, transparency) and be able to scatter some foliage, as a bonus.
• We also wanted to be optimized in polygon counts and have Unreal terrain’s collision work with our floating islands

First Tests, Always a Mess

On the first day, I started by looking for some tutorials and how Unreal’s terrain worked. Then I created one big tool that would do the conversion from mesh to terrain, add noise depending on a selected area as well as create the layers for textures.

As planned, there was more than one problem while testing this tool. The precision of the projection was not enough for a platform game and needed tweaking. The users would come across many bugs, would it be the inconsistency of the layers, the player collision not disappearing in holes, and ironically the tool encouraged a very destructible pipeline. There were too many things to take into consideration while using it and that made it unstable, a very nice first version indeed.

What’s good about this first test, is that we knew exactly what hadn’t worked, and could easily find a solution to it.

The Pipeline

After a small yet effective talk with Mathieu Van Cappellen, one of the level designers, I quickly realized the solution to our problems was to simply divide the tool into different Houdini Digital Assets. That would allow users to focus on each step of the terrain creation, taking care of what they wanted to work on, instead of troubling themselves with potential future bugs.

This division gave full liberty for the users to tweak what needed to be tweaked in between each step. Plus, what’s nice about dividing a tool, is that you can iterate and add things without disturbing anyone’s work

Presentation of Tools

First I created the tool for a level designer, which is the most straightforward tool, it just uses the HeightField Project geometry node to add the block’s shape onto a high-resolution terrain. For that, the HDA should be placed under the islands. I used a technique demonstrated in Simon Verstraete’s tutorial on creating post-apocalyptic ruins.

Then I created a second tool that takes the landscape and on a defined area would add “more artsy noise” and convincing erosion. Later, I added the option to define the area of effect on the other tools. In a larger production, this tool would have had a lot of presets of noises, so that we wouldn’t have to choose the parameters each time. In this project, realism and exact replica weren’t the priority, and noises were used as a base for later terraforming, so a mix of HeightField Noise and HeightField Erode did the work.

After that pass, we would check with everyone if the terrain was in its “final shape”. If so, we would use this third tool to quickly specify the material, creating different masks (depending on angle, position, and height) by using the HeightField Mask by Feature geometry node and would create specific layers for cliffs and mud and grass etc., and of course, transparency. Those layers would be used as masks in the terrain shader that I was working on in parallel.

We had some problems with the collisions in Unreal that would still be activated in the transparent part of the terrain, except if painted it out manually. I added a fourth tool to tackle this problem so we could use our own collision instead of using Unreal’s default.

This tool would import the terrain to Houdini and convert it to polygons while selecting the transparent areas, using that layer’s information to delete the invisible parts of the terrain. We could then perform easy operations, like reducing the geometry’s polygon number to simplify the collision’s shape, and even subtract some inputted geometries from the collision if needed, to make a hole, for example.

The tool for foliage scattering was not finished by the end of the week, and we had also decided that foliage would look better if we placed it manually with Unreal Engine, since we could work on composition. For smaller foliage, like grass, we decided to scatter them by using a foliage type that would spawn only on certain layers: that was made in the Unreal’s shader.

To fix the number of polygons of each terrain, we had to do a semi-manual pass, importing the terrain in Houdini and resampling it, and finally, manually deleting the parts of the terrain that were loaded, yet invisible. After that, nothing on the terrain, except the materials, could be edited, it was truly the final step.

The Results & "Idiot-Proofing"

Of course, since it’s a user-aimed tool, I worked on making it user-friendly. Using the tool pushed me to make it better slowly but surely: I added some “idiot-proofing” in my parameters, as well as automated some inputs, and created a better environment for testing, by giving the possibility to select the areas to be edited for example, so that the tool wouldn’t “break everything we’ve done”.

This set of tools might not be a Giant Tool, that creates an entire environment in one click, it’s not a fully automatic tool, and I don’t think that it should be. In situations like that, where there is little time and a lot of creativity, it was just what we needed, a support tool, to help gain time, without replacing anyone in the team. I’m very proud of it, in a short time it went from a fragile workaround to a solid pipeline for a small team and helped us gain hours of work.

Thank You!

Special thanks to the Wandering Cloud team who trusted me in this stressful period, Environment Artist Clement Petiard, Level Designer Mathieu Van Cappellen, and Character Designer Nicolas Tognetti, who are awesome at giving feedback and being here to help when I encountered problems.

Youmna Sahab, Technical Artist Assistant