CHALLENGE

Early 2021 I took a deep dive into procedural modeling in Sean McEwan’s “Procedural Modeling for Production in Houdini” course at CGMA. The course provided some really great assignments to work on, among which a cactus generator (see blog post) and the pagoda generator this study is building forward on. What bothered me, however, was that little or no attention was paid to the actual usability of the procedurally generated geometry for production, often resulting in an overly complex mesh without UVs that would be difficult for other departments to work with. Convinced by the idea that procedural modeling should be able to produce flexible, clean and efficient geometry that is easy to work with, I started this case study to find out how I could make this happen.

Based on experience and research, these are the requirements I felt my Japanese pagoda generator should be able to meet:

• single set of (very simple) construction curves and shapes forming an invisible but all-important building structure,

• the tool build must be broken down into independent sections and parts, each based on the construction shapes of the building structure,

• the model should be assembled from reusable parts by using point instancing to minimize duplicate geometry,

• there should be an option to generate a model with proper (and customizable) bevels to add realism when needed,

• good quality procedural UVs and a uniform (but also customizable) texel density throughout the entire pagoda,

• randomization system for both the 3D orientation during instancing and the UV mapping for each unique part to prevent texture repetition,

• a unique part library should be generated in the Content Browser upon baking a pagoda in Unreal, following standard naming conventions,

• an easy to read folder structure should be generated in the Outliner upon baking a pagoda in Unreal, following standard naming conventions,

• there should be options to enable Nanite for all generated parts, and to automatically assign Unreal materials to groups of generated parts,

• the user interface should be logical and intuitive for creating the maximum amount of Japanese pagoda variations with the minimum amount of controls,

• preset system that can store individual pagoda variations in separate files, which can be exchanged between Houdini and Unreal,

• there should be options to do the shaping of a new pagoda on a light weight or partial pagoda model to improve performance,

• all geometry should be generated procedurally (from scratch).

RESEARCH

I started the process of building this pagoda generator with researching and analyzing Japanese pagodas. I collected all information I could find about anatomy, structure, shape, patterns, variations and naming and organized the references into a reference board. I decided to limit the generator to two to five story wooden pagodas with square roofs, built on a stone foundation, with one to five optional decorative roofs. To limit the complexity of the first generator version even more, I decided early on to simplify the elaborate wooden support brackets under the roofs (called ‘kumimono’ in Japanese) and, to a lesser extent, some other decorations as well.

BUILDING STRUCTURE

After completing the reference board, I created a set of simple construction curves and shapes to build the tool on top of. This workflow prevents me from creating too much consecutive dependencies that will start to work against me at some point. Instead, for each element I can now fall back on the same (very basic) construction curves and shapes that are easy to control, and this also makes the node network a lot cleaner.

The construction shape of my Japanese pagoda is based on a repeatedly extruded single square polygon, forming side polygons that form the basis for walls, roofs, balconies and every other part of the pagoda. By grouping primitives with a similar purpose, specific tool sections know which part of the construction geometry to build on top of. And because this geometry is so simple, it was very easy to implement a control structure for defining the amount of floors, how many floors should have decorative (double) roofs, what the overall shape and dimension of the pagoda should be and whether balconies should be overhanging or internal. The image below shows how these simple construction shapes relate to the final pagoda models that are generated from them.

SECTIONS, PARTS AND INSTANCES

Once this easily customizable building structure was ready, I broke up the tool build into independent sections, each based on the simple construction shapes of the building structure. What this meant in practice is that I didn’t want any cross-links in the node network between different sections, even though sometimes ‘spaghetti networks’ could be the easiest way to quickly create geometry. Instead, I made each section (except the walls section) directly dependent on the building structure and the user interface parameters, making the whole generator much more flexible for future changes. The image below shows which sections the Japanese pagoda tool is divided into. When using the tool, it is also possible to focus on each of these sections individually using the “Isolate Section” dropdown menu, which speeds it up considerably.

Within each section unique parts are constructed procedurally, and target points are defined for instancing these parts multiple times to minimize duplicate geometry. Again, both part dimensions and point positions are directly dependent on the building structure and the user interface parameters. Because each part is constructed independently of any other part, it is very easy to make future changes without breaking anything else. In addition, this workflow also allows for manual adjustments to a part after baking in Unreal (described below), which will then be propagated to the instanced positions automatically.

DETAILS, BEVELS AND RESAMPLING

Initially, I constructed all individual pagoda parts from as little polygons as possible to get the desired shape, with the advantage of keeping the model lightweight. However, realistic renders require proper bevels instead of hard edges. So I’ve been experimenting with two options to create bevels: simple round bevels and creased bevels with subdivision, where the bevel size can be finetuned using bevel multipliers available by part type. As you can see in the image below simple round bevels are still quite lightweight, but for creased bevels with subdivision the polycount increases significantly, which is often not desirable for realtime applications. A side note on beveling: the advantage of working with relatively simple parts is that they are generally much easier to bevel properly, since for complex shapes it can be hard to create bevels with the correct topology, especially procedurally.

Since it might be better for some applications to have more control over the number of polygons for each part, I also implemented a resampling option that uses unique resampling settings per subsection. Custom resampling and beveling give the user the freedom to generate a model in the desired resolution. But because high resolution settings can slow the tool down significantly, these features can be enabled or disabled at any time by using the Quick Output Access buttons “Details” and “Resample” without affecting the overall appearance.

UV MAPPING AND RANDOMIZATION

During the “Procedural Modeling for Production in Houdini” course at CGMA, I was really surprised to learn that UVs are often ignored by procedural artists (according to Sean’s experience). I knew procedural UVs can be hard to get right, but I imagined that the option to generate good UVs for complex models like this pagoda could be a big quality improvement. Additionally, my experiences with world building in Unreal Engine have learnt me that maintaining a consistent texel density (the amount of texture resolution on a mesh) is a very important requirement in realtime 3D. So, I was determined to implement both.

Fortunately, I had already broken down the Japanese pagoda model into relatively simple parts that are much easier to generate good UVs for as well. While for some parts the SideFX Labs AutoUV node did a pretty good job, for most parts procedurally creating a group with good UV seams gave better and more predictable result in the UV Flatten node. The basic rule I use for all texture UVs is that any edge 90 degrees or sharper should be a UV seam (but not every UV seam needs to be a hard edge).

To limit the complexity of the first generator version, I decided to stick with this single texture UV channel (uv1) and an optional lightmap UV channel (uv2, for non-Nanite geometry in Unreal, mapped with different rules). This only supports a single material layer per part though. Therefore, when you would like to add dust or other unique details, it could be beneficial to add a second texture UV channel (uv3) with atlas UVs per group of parts nicely layed out without any overlap. Atlas textures could then be used for masking in other tileable textures on top (like dust), but they can be much lower in resolution because they’re only used for the masks. The way the tool is set up now, makes it pretty straightforward to add improvements like this.

ControlLing the OUTPUT IN UNREAL

With most of the model completed, the next step was to control the output in Unreal Engine. Fortunately, the release of Houdini Engine for Unreal version 2 opened up a range of possibilities to realize my goal to organize the HDA output in Unreal in such a way that makes it easy to work with and manually improve upon when necessary.

First, an HDA can now generate a unique part library in the Content Browser upon baking in Unreal. In this part library unique parts are separated out as Static Meshes by packing them in Houdini. They are named according to standard naming conventions, built with the correct build settings, have Nanite enabled when desired, and may have an Unreal material assigned where needed, just by sending along some special attributes. The result is exactly how you would set it up manually, making it possible for an art department to build forward on a procedurally generated model. For example, you can now take an individual part and bring it into ZBrush for detailing and then replace it with the new version in Unreal. Or replace the material assignment for just one part. Any adjustments will be propagated to all instances in the assembly automatically.

Second, an HDA can now generate an easy to read folder structure in the Outliner upon baking in Unreal. In this folder structure all folders and Instanced Static Mesh actors have clear names according to standard naming conventions and they point to the unique parts library created in the Content Browser, just by sending along a bunch of special attributes. The baked result could then be converted into a Packed Level Actor (Blueprint) containing the entire assembly in a single actor. This makes it possible to use a specific design over and over again in your scene at little extra cost.

USER INTERFACE

To build a user interface, I always start right away by creating control parameters in a CTRLS node (null). This forces me to design the tool with logical controls in mind, makes visualizing dependencies in the node graph very easy and it also makes it very easy to promote these control parameters as soon as I want to turn the tool into an HDA.

PRESETS

A complex model like this Japanese pagoda requires a lot of control parameters to be able to create useful variations. That's why I quickly became to realize that a good preset system would be indispensable for a tool like this. And since Houdini’s preset features are rather limited for custom HDA’s, I decided to setup my own preset system by using Python scripts to read/write parameter values from/to a json-file.

In order for the preset system to work, the control parameter ‘Preset Directory’ has to be defined in the UI first. This gives the system the info where to look, and causes the ‘Load Preset’ drop down menu to list all presets already available. Selecting one of these options will trigger the read script to read and convert the contents of the json-preset file, and replace all control parameters in the UI with new values. For saving, you also have to set the ‘Preset Name’ parameter. Upon clicking the ‘Save Preset’ button, the write script will run through all parameters in the HDA, but skip over the ones that are marked for exclusion. The script will then convert the parameters into a json-format and write them away to a json-file in the preset directory, after which it becomes available in the ‘Load Preset’ dropdown menu as well.

The advantage of a json file based preset system like this is that the HDA in Unreal can point to and read the same preset directory, making it possible to prepare your models in Houdini, which is still a lot faster than in Unreal. In addition, the preset files are very small and can easily be shared with another artist. Below (and on the top of this page) is an impression of the eight built-in presets that demonstrate the variety of 3D models that can be generated with the Japanese Pagoda Generator. With these presets you can quickly find the desired type and size of pagoda, so that you can realize your own pagoda design faster.

CLOsing words

It was a lot of fun and very rewarding working on this Japanese Pagoda Generator and I am very proud of how it turned out, completing every item on my requirements list. Procedural modeling is incredibly powerful! And, I'm happy to conclude that it can produce flexible, clean and efficient geometry that is easy to work with!

But what would I do differently next time? One thing I should have considered even more from the start is performance. I implemented several options to speed up the tool while working on a new pagoda design, resulting in cook times between a few seconds and a few minutes (depending on the complexity of the build). But using Compile Blocks, for example, could have given the generator that extra boost to make it significantly faster (possibly at least 50-80%). However, since I came to this conclusion quite late in the process, the limitations in implementing it created so much extra work that I decided to save it for another time.

Another thing I didn’t look into is the procedural generation of the textures and materials themselves. It would be an interesting topic for a future study to find out if and how this can be integrated into the tool, so a fully textured and shaded pagoda asset could be generated with a single HDA (in both Houdini and Unreal).