Procedural Optimization With Houdini: Overview

What is proceduralism? How can non-destructiveness and randomization help companies save time on repetitive tasks and generate new art in no time? We've invited Adolfo Reveron, a Houdini procedural artist and 3D teacher with a background of engineering, movie making and gamedev, to discuss a topic that scares a lot of people. We've talked about procedural content creation and learning Houdini.

In this first part of our talk (don't miss the second one next week with a case study), the artist broke down a couple of simple examples to explain what procedural content generation means, how small studios can benefit from using Houdini, and explain reasons for repetitiveness. Modeling a steering wheel sounds like a simple task, right? Actually, there are several ways to approach this task, and today we're going to talk about how you can use Houdini to save time and set up all kinds of crazy designs in a matter of minutes.

Intro

My name is Adolfo Reveron and I am a 38-year-old Houdini Procedural Artist in Valencia, Spain.

My journey started as it usually does: with a crisis. After 8+ years as an engineer, I felt totally burnt, tired, stressed. I reached the point of waking up at night, heart beating, for no apparent reason. My body was telegraphing to me I needed a change.

One day I decided to make the first move and follow that voice which always told me to go chasing some kind of artistic path. Since I always loved to draw and computers, I decided to do some research about that 3D matter: the only thing I knew was it was required to make movies. Once I bumped into 3D, around 2008, it became my passion instantly, and I decided to quit my job and never look back.

Years passed, and I ran the 3D-hero journey: started modeling, liked authoring textures, moved into shaders, dived into lighting, tried effects. These were the areas that interested me most, but also tried rigging, animating, and compositing, almost everything at my reach: I felt like I needed to try everything to figure out what I liked most.

I had the chance of working in an animated short film in 2012, then some freelance and finally a movie, which was released surprisingly late in Netflix.

Then I jumped into the video game industry, working for an AAA outsourcing studio. There I started creating assets and environments for titles like Hitman or Call of Duty WWII. Four years ago, I realized creating amazing open worlds and ultra-detailed assets the traditional ways was unsustainable: the amount of manual work needed is insane. Nowadays, the workflow requires being organic, inviting to explore, being able to address big workloads in a non-destructive fashion. That’s where my love story with Houdini began.

How Did You Start Learning Houdini?

I was introduced to Houdini by one of the VFX guys I met in one of the productions and felt totally outstood by the visuals it created. However, I never felt passionate about VFX but about creating environments and assets, so wondered what Houdini had to offer regarding those topics. I found really interesting stuff related to procedural modeling and content creation through HDAs (stands for Houdini Digital asset, a tailored tool created by a procedural artist), but this material was created by a few artists spread around the globe, not a big community yet.

Despite its relatively small presence within 3D sites and platforms at that time, I realized that, regarding procedural modeling, a beast was about to be unleashed: the possibilities of 3D modeling and content generation through digital assets are incredible, and this is something misread by many companies and artists yet, both animation and game dev.

Advanced procedural content creation is non-destructive. It gives the ability to address huge workloads and cab be seamlessly integrated within a pipeline. In other words, it provides a way of solving problems of scale and deals with workloads in a flexible way, which are essentially too great in numbers to do by hand or the things that might require accuracy and lots of iterations. It is especially useful for both outputting finished art and also for dealing with repetitive, big technical tasks so that allows 3D users to focus on art rather than low productivity tasks.

Procedural Modeling and Digital Assets

Many people already heard of proceduralism and the keywords associated with it, like 'non-destructive', 'randomization', 'many variations', and such, but I realized most of them don’t understand completely how can this benefit their work on a daily basis. I noticed I needed to create artwork procedurally for them to actually see it, like creating a movie-ready full cathedral in no time, or game-ready bridges inside of Unreal. Any of these examples becomes extremely time-consuming, expensive, and stiff projects if addressed in traditional ways. It is like, "see this bridge a 3-member team spent a week to be created - fingers crossed for the art director not to change his mind-like?" With THIS tool, a single artist can make any design at will in minutes.

'Procedural modeling' is an empty term if you don't add any further explanation, it might mean a lot or nothing at all. You might say you are modeling procedurally within 3ds Max because you can stack modifiers one on top of each other. The same goes for Maya, Blender, and other packages that support some kind of modifier stack or history. Any experienced 3D artist will tell you this leads to inconsistency sooner or later, though, and you need to collapse the effects eventually. So we can't take this as true procedural modeling.

Once in Houdini land, you might model anything as if you were using any other 3DD package: extruding, merging vertices, adding loops, and such. Houdini will keep track of each operation you make and will add a node for it. You’ll have a complete track of what you did, like a full history diagram, which will let you go back to any point, but, believe me, this will lead to a terrifying network like this:

In my opinion, this is not the way of using Houdini for procedural modeling. It might do the job for a small asset, maybe a medium one, but do not do it for a big asset like a vehicle or you’ll have to deal with such a graph.

So what’s the way to go regarding procedural modeling and asset generation with Houdini, you might ask. Well, you can rely on creating procedures rather than assets. For instance, what if we created a procedure to create tires rather than actually model a tire? But wait... this sounds like a tool to me…

Exactly! You can promote procedures to a tool, with the benefit that can be stacked along with other tools and reused again and again. It’s up to a procedural artist to define what this tool requires as input and what it will generate as output...which can be fed again as input for another tool.

This approach relies on the principle of layering: you can stack simple operations (tools) to achieve a complex result.

An example of creating a tool to make tires rather than modeling a tire:

What if we tried combining this tire tool...with let’s say a bike-tool? Well, why not? Here some renders of a fully procedural bike-generator I’m developing, no manual tweak involved. To create it, I just played a bit with the sliders and pressed render.

How Can You Boost Production Pipelines?

You can either go for integration or for isolated procedures. If your studio picks the red pill, aiming for integration, it will achieve great productivity results with just a Houdini procedural artist. It leads to establishing a pool of tools shared across a studio, where artists will load these tools to the platform of their choice (3ds Max, Maya, Unreal, Unity, Cinema4D) to do what they need to do or ask for it in case this tool doesn't exist yet. It might be a tool for the procedural creation of highly detailed ready-to-render rocks in seconds inside of Maya (therefore skipping manual sculpt in Zbrush).

Or you can create nice game-ready levels inside of Unreal.

However, I also found that it's not a good practice to promote every task to a tool as this leads to overplanning. 

If your company chose the isolated option instead, you can do all the magic inside of Houdini and just export assets in a universal format that is required (.obj, .fbx, .abc, etc).

The benefit, compared to addressing the task through traditional methods, is that you can assume bigger workloads, like creating a castle in no time, in a non-destructive fashion (iterable, organic, and open to changes).

It might help a number of departments and save time on tasks, just to name some:


• Modeling: props, vehicles, weapons, characters

• Level design and generation, worldbuilding, dressing, scattering

• Terrain and landscapes
• Concept, lookdev, visual development

• Scan processing, AI training, etc.

To sum up, in my experience, you can get the best if you bear in mind a flexible approach where you mix the use of tools and the manual work as you progress. Is it gonna be shared across the whole studio? Then you'd better create a robust, user-friendly tool. Or is it a single-use setup to create a specific building like Eiffel Tower? Go use a mix of tools and manual work. Every project is different and the design guidelines heavily affect an approach to pick - finding the proper balance for that particular project is the key.

How Can Small and Medium-sized Studios Benefit?

SideFx, the company behind Houdini, is making big efforts to spread the use of the software across studios. They offer a ton of resources to learn it and also an incredibly cheap license for indie studios, which includes the full software and also a plugin to bridge Houdini with third-party tools (3ds Max, Maya, Cinme4D, Unity, Unreal) called 'Houdini Engine'. Of course, it has restrictions regarding what companies are eligible (<100k$/year) and the number of indie licenses per company (more info here). I found the indie license to be more than enough for small and medium companies. It's easy to install and set up.

The hardest part is not tech-wise but mindset-wise, in my opinion. I found a surprisingly strong resistance from both artists and managers to implement Houdini, despite its clear benefits. There are several reasons that explain it, but to put it in a simplistic way, I think it is caused by the following:

• Fear of change: people tend to stick to what they know. They know how to solve stuff and this means confidence, regardless if there is a more optimal way to go.
• There are also tech restrictions: you might implement Houdini if you (or your employer) work for a studio that embraces it.

Houdini is hard to master compared to other tools. You can get crazy nice visuals in minutes with little experience, sure, but you’ll probably struggle if you are commanded to match a specific visual target or concept, whilst following technical requirements like polycount and UVs. 
It is worth mentioning that it is harder to procedurally create assets, environments, or tools for the videogame industry because you need to be confident with AAA requirements beforehand, and then implement this knowledge through Houdini.

Bear in mind that anything you create for a game must run in real-time, which involves lots of tricks and restrictions regarding optimization to display nice results. Other industries like cinema, motion graphics, animation in general don't have that many restrictions.

• Finally, most artists and managers, even 3D veterans, still think of Houdini as a VFX software only.

How Can You Avoid Repetitiveness When Creating Assets Procedurally?

The first thing I do when creating an asset or a tool is going away from a PC. I grab a pencil and a notepad and spend a few minutes trying to do a brief list stating what the main features are of what I am about to create. In other words, what is the simplest way of describing it? The bare minimum? 
If I were creating a car, it would be a stretched cube, something like small kids usually draw. If adding another layer, it would probably be adding four cylinders beneath the prism. This is enough for us to link this image (or 3D model) to the common idea of a car. The next layer would involve adding the steering wheel and mirrors, and so on.

Once I defined those key descriptive elements, I ask myself: how would I be modeling a steering wheel if modeled traditionally? Well, there are always many different approaches to achieve the same thing. You can start from a torus shape which will provide you control over radius and thickness but...what if you build a wheel from a profile extruded along a curve? It will provide you with a completely different range of control.

Here's an example of a cool design:

The more you practice, the more you get used to Houdini possibilities. As I was writing, I just thought of another approach: creating a 360º open circle with first and last points not welded. Then grouping these first and last points procedurally. Finally, soft-transform them.

You wouldn’t be able to create this wheel variation using the initial torus approach. So it is about training the eye to aim for an option that trades better, in the ideal situation it offers a lot of possibilities whilst keeping things simple. 
It might look like a convoluted process with a lot of thinking involved, but you do it instantly once you get used to it.

Therefore, the key factor to avoid repetition is not dependent on the techniques Houdini has to offer but on the thinking involved when a procedural artist designed a tool or node network setup.

You can always keep building on top of this, adding layers of details, like instancing some bolts on the surface. But hey...what if we create a tool that creates a new bolt variation every time we run it, rather than instancing the same bolt again and again?

Optimizing Production

Each tool addresses a different topic, which might throw very different results depending on its complexity.

For instance, a tool to procedurally generate bolts might save a handful of minutes compared to traditional modeling. If you need to create 10 bolt variations x 10 min/each, let's assume it might save 100 mins for getting 10 different high-poly models (with Houdini you get an instant variation with every tweak of the 'seed' controller). So efficiency is awesome.

If you aim for a more complex example, let's say creating a city, with finished roads and buildings, out of OSM data, the efficiency is amazing. You get a huge level done in minutes, compared to hundreds of hours of a team of environment artists.

Note: OSM stands for Open Source Maps if I am correct. You can download something like 'street info' that can be loaded in Houdini.

Similar examples like creating an ultra-detailed train track out of a spline or a Roman coliseum out of a cylinder are equally outstanding.

However, there is no magic involved and it's got limitations: a tool is a procedure and as such, its strengths and weaknesses involve it relying on rules. For instance: if you create a tool that expects finished columns to be instanced, you MUST feed it with columns, nothing else, otherwise you'll get unexpected results.
It makes sense, and It is logical: you wouldn't fill a car's tank with water, but petrol. 

We all agree on that, however, there is no mercy with tools sometimes, and It is pretty common to show It to someone and have a comment like: 'uh! This train track tool is not able to output 10m wide tracks, it's a waste of time'. People expect tools to solve all possible situations, but it doesn't work like that.
You wouldn't use a hammer to make a hole in the wall, you'd use a drill.

To sum up, the more complex a tool is, the more stuff might solve automatically and more time It will save, hundreds or thousands of hours, but if you force It too much, asking for something too different to its original purpose, you might need a new tool.

Adolfo Reveron, a Houdini Procedural Artist

Interview conducted by Arti Sergeev

That's all for the first part of our talk. Make sure to come back next week for a case study. We'll be discussing how you can use Houdini to build modular levels in Houdini. One more thing: don't forget to visit Adolfo's awesome website with tons of tricks on procedural content creation.