Creating procedural game assets with Houdini

During development of the project “Collector”, while sculpting cave walls and stones by hand, I once again decided that I need to find more efficient – procedural way of building assets. As they say – proceduralism is the future.

In this series of posts, I will try to show my experiments and explain how to use Houdini to create automated pipelines for generating procedural game assets.

Natural formations — such as cliffs, stones, sand dunes, are hard to create manually. Sure, skilled artist can come up with workflows and sculpt an amazing rock, but it takes a lot of time and is not particularly creative task (At least after first couple pieces have been finished). Once you need a lot of them, it becomes hell. It is hard to keep consistency between all pieces — especially if you have to make a hundred different pieces of different shapes and sizes. Even bigger problem arises if there are some changes to art direction — for example, there is a decision to change all rocks to more sand-stone look. There could be a lot of reasons for changes, and as a result, poor artist would have to redo all hundred pieces by hand. Not only that, but maybe there are other assets that depend on these and should also be changed as a result. It is just insane — it takes a too much time and nobody would want to do that without drinking excessively.

Because of all this, you might want to start thinking about using some workflow based on procedural generation. For hero assets, we can still use a manual approach, but even in that case we could automate some of the process — for example doing main forms by hand, but generating fine details procedurally.

Almost all natural phenomena (landscapes, rocks, plants, clouds, water etc.) are good candidates for procedural generation, because contrary to man-made objects, natural objects are shaped by some common natural processes and laws (rules of physics etc.). Knowing these rules, we can try to approximate or emulate them in our procedural model. Once we establish this model, we can generate an infinite amount of variations – all completely consistent.

Sure, making completely procedural models and environments might look boring – we want to keep some level of manual control and ability to art direct some aspects – points of interest, shape things to our needs – for example gameplay of a game level. This is the part that human artists are good at. Also, it is the fun part – making high level decisions yourself, but leaving low level and repetitive stuff to the computer.

Initially, I was thinking just about automation of rock generation, but after a while, the project grew bigger. I saw that the procedural approach can help to to other things. My goal become to explore different ideas and techniques for building whole semi-procedural game asset pipeline – from 3d mesh generation, UV mspping to texturing, to automation and exporting to a game engine.  

Once you have a good procedural pipeline, it becomes very exciting to work – you can iterate easily. Try out different ideas and styles and easily regenerate all your assets. It can change whole game development dynamic to be reverse. While traditionally you do all the creative exploration in the beginning and then you just grind till the end. But in this way – you first put in more effort in creating procedural pipeline, and then you can do as much creative iterations and explorations as you like – almost till the end of development.

Houdini was a natural tool of choice for me, as it is simply the best tool – made specifically for creating procedural stuff. To those who don’t know what is Houdini – it is a completely different approach to doing 3D graphics. It’s node based – each operation is represented as a node in a graph and you can change any part of the graph at any time. You have full access to low level data and there is a powerful programming language built in (actually three languages). While you can do manual 3d modelling as in other 3d applications, the main strength of the Houdini lies in procedural approach to doing things. You can create fully procedural setups and even build pipelines.

The new PDG (Procedural dependency graph) system introduced in Houdini 17, is built for creating workflows and pipelines. You can run them parallelised on multiple machines or multi-thread on a multi core machine – super useful for chaining different operations and generating large amount of assets as fast as possible. It’s like rendering on a farm, but also for other things.

Initially, I was planning to use COPs (Compositing operators) in Houdini to do all my procedural texturing. It seemed like a nice idea to do everything in Houdini. While technically it worked and I could generate textures similarly as in Substance Designer, in reality COPs are very slow and therefore painful to work with (Especially when you want to work with 4k textures, iterate quickly and see your changes).

So after having some frustrating times with COPs, I decided to use Substance Designer and Substance Automation Toolkit, which I could integrate nicely using Houdini PDG network. This also seemed like a good idea because Substance has become an industry standard solution for procedural texturing.

I still use COPs, but just for baking all the necessary texture maps for Substance input. For this I use a modified version of an excellent Game Tools (now Sidefx Labs) baker. I added few features to the baker – such as Bent normal map calculation, Position pass spherical normalization and per channel file format selection.

At one moment I also decided to use RizomUV to do UV unwrapping for my rock models and it was very easy to integrate in my pipeline through PDG automation.

Best part is that these tools have become really affordable in recent years for individuals and small studios with the introduction of subscriptions and Indie versions:

subscription: 269$/year
Substance Toolkit: 20$/month  or 220$/year
RizomUV: 20$/month or 150$ to own.

Monthly subscriptions are fantastic if you need software only for a specific project.