Procedural building

Original author: Kirill Tokarev
  • Transfer

Eyvind Fiksdal (Øyvind Fiksdal) shared the details of the procedural process of creating a house and landscape in Houdini and talked about the benefits of this approach.


My name is Eivind Fiksdal , I am a Norwegian artist who used to work mostly with traditional art. Closer to the age of thirty, I decided to concentrate fully on 3D and entered two-year 3D courses and animation. After some time I got a job at one of the largest advertising agencies in Norway.

Jobs in the advertising industry opened all the doors, but working for one company did not give me opportunities to implement, so I became a freelancer. After two years of freelancing, my former colleague and I decided to unite and create a company called Trollskog.

Procedural approach to the project

I was always intrigued by the procedural nature of Houdini , but at the artistic level, and not just the standard use of the program. After reviewing a huge number of tutorials and presentations, I began to master the power hidden inside the program.

When working with fully procedural resources in Houdini or any other software, there are very few opportunities to make artistic strokes - you can only change the seed and hope that you get something interesting. When you work under the direction of an art director, you can easily give background assets to randomization, but creating heroes assets or a manually created village can be an unbearable task for most of us.

Even when working with traditional modeling and sculpting, creating an entire village will be a large-scale task, especially editing an asset after it is completed.

My concept was based on the idea of ​​manually creating simple low-poly assets, as well as creating the same set of procedural tools that read geometry and create a finished model with all the details, textures and modifications. With the traditional approach, such work would take several days.

It is also worth noting that I did this project about a year ago in order to expand my knowledge in Houdini, work with VEX and see if it is possible to use Houdini in the production pipeline.

Building a house: a procedural conveyor

The procedure that generates the finished house from a low poly base is assembled from a series of modules. When talking about modules Houdini, often mean a chain of nodes that perform a specific task. For example, the first module reads low-poly geometry and recognizes roofs, walls, doors, and windows. Several modules are branched off from it, performing secondary operations. For example, the roof is then sent to the next module, which finds the roof ridge and checks if it can detect the spire. Then the data is sent to a new module that creates a tile, then another one to create moss, then to create grass, and so on.

In the finished model there are practically no pre-created assets. Instead, it generates them from the underlying surface. This is the concept of the project. As in the example of the video, walls are created on the basis of only simple low-poly geometry.

The process begins with the import of a single mesh, as shown in the first video. From it, as I said above, the model procedurally recognizes the roof, walls, windows and doors. They are then transferred to the main creation phase. The input model is also used to generate ivy, which not only grows over the surface, but also measures the volume of the model to avoid too much or too little vegetation.

Each of these elements reads the path of the input file and it is passed as an attribute, so the finished model is written as a native Houdini file. That is, after choosing a model to create a finished model, just a click of the mouse is enough for me.

Procedural approach combined with manual work

When using a fully procedural pipeline without manually created input data, you can get both organic and random looking results, but the process will be very complex and unpredictable. But by combining both approaches, we will simplify the work and will have greater control over the final result.

Of course, some aspects need to be left to chance, for example, creating randomized scale values, turning or positioning of objects, and using noise patterns to simulate stone surfaces and other things, but for such a reliable workhorse as Houdini, these are simple operations.

Making materials

As is clear from the video about creating walls, a large proportion of these materials are not textures, but geometry. The remaining materials are created using color data from meshes, as well as curvature measurements and other tricks done with attributes. Most of the really used textures are very simple textures created via COP (built-in composer Houdini).

Before importing, a UV scan of the low-poly model was performed, and this data was used in the modeling process, for example, when creating a roof tile. Although I do not use them in the final product, they can be used to bake the textures that will be used in the low-poly version, but there are more optimal ways to create a game model, which we will return to later.

For the final model, the UV scan is mainly procedurally performed using game development tools, and other parts, such as beams and doorways, are expanded by stretching along curves that have UV coordinates.

Landscape creation

The terrain is generated by reading the lower floor of the imported model, the final geometry is created using VDB by mixing various noises.

After completing the landscape, we can measure all sorts of topological properties: occlusion, curvature, angle of inclination, and so on. They determine the location of the grass, its height and the location of flowers or trees.

For the sake of variability, materials are created by combining images and color data.

The plants and grass themselves are instances that are created procedurally by combining nodes and VEX. Then they turn into proxy Redshift, instances of which are created depending on the attributes of the landscape.

Is the project ready and in use in the game?

Such a system is both applicable and not applicable to the production of games. For it to be applicable, it needs to be subjected to another set of operations, but it will be a fairly simple and straightforward task. Models are too high-poly for use in games, but if you transform a high-poly model into a VDB object to ensure its tightness, and then use the tools to reduce the number of polygons, then everything else can be baked into textures.

I think that today procedurally generated architecture is quite often used in games, but I have not yet seen cases where simple hand-crafted models would be taken and then all parts based on them would be generated. Perhaps in the future this will occur more often.

I would add my own limited knowledge of Houdini to the bottlenecks of the project. I started this project to study the program, and I had no idea what I wanted to come to. In retrospect, I can say that with the knowledge I now have, I would have much different things in this and other projects. Another bottleneck is RAM - to work in Houdini, and especially when processing VDB, you need a lot of RAM.

Øyvind Fiksdal , 3D-artist.

Interview taken by Cyril Tokarev

Also popular now: