ProceduRule: A Procedural Modeling Tool for Autodesk Maya

A Thesis Submitted to the Faculty of the Visual Effects Department in Partial Fulfillment of the Requirements for the

Degree of Master of Fine Arts in Visual Effects at

Savannah College of Art and Design

Joshua F. Houser

Atlanta, GA

© March 2017

Virginia Bowman, Committee Chair

John Rauh, Committee Member

Clarke Stallworth, Committee Member

TABLE OF CONTENTS

LIST OF FIGURES ……………………………………………………………………………………………………………………….. 1

THESIS ABSTRACT …………………………………………………………………………………………………………………….. 3

INTRODUCTION .………………………………………………………………………………………………………………………. 4

REVIEW OF PROCEDURAL MODELING USAGE .………………………………………………………………………….. 5

PROCEDURAL MODELING IN LIVE-ACTION WORKS ……………………………….…….…………………………….. 8

PROCEDURAL MODELING IN VIDEO GAMES AND TELEVISION ……………………………………………………… 10

REVIEW OF PROCEDURAL MODELING IN COMMERCIAL 3D APPLICATIONS ……………………………… 12

HOUDINI BY SIDE EFFECTS SOFTWARE ……………………………….…….…………………………………………… 13

CINEMA 4D BY MAXON ……………………………………………………………………………………………………… 15

3D STUDIO MAX BY AUTODESK ……………………………….…….……………………………………………………. 17

MAYA BY AUTODESK ………………………………………………………………………………………………………… 19

OVERVIEW OF THE PROCEDURULE AUTOMATION TOOL ………………………………………………………… 22

METHODS OF ASSET GENERATION ………………………………………………………………………………………. 23

DEVELOPING THE TOOL USING MEL …………………………………………………………………………………….. 26

DESIGN PHILOSOPHIES OF PROCEDURULE ……………………………………………………………………………… 28

I. BROAD APPLICABILITY ……………………………….…….…………………………………………………………….. 29

II. EASE OF USE AND INTUITIVE DESIGN ………………………………………………………………………………… 30

III. FLEXIBILITY AND USER CONTROL ……………………….…….……………………………………………………… 34

IV. EFFICIENCY AND EXPEDIENCY …………………………………………………………………………………………. 35

RESULTS OF USING PROCEDURULE ANIMATION TOOL ……………………….………………………………….. 37

CONCLUSION …………………………………………………………………………………………………………………………. 41

APPENDIX A: WRITTEN TUTORIAL …………………………………………………………………………………………… 43

APPENDIX B: USER TESTING FEEDBACK …………………………………………………………………………………… 57

WORKS CITED …………………………………………………………………………………………………………………………. 61

Houser 1

List of Figures

Figure 1: Procedurally-generated environment from The Good Dinosaur 5

Figure 2: Houdini playblast of The Good Dinosaur’s river simulation 6

Figure 3: Procedurally-generated environment from Big Hero 6 7

Figure 4: Procedurally-generated crowd from Big Hero 6 8

Figure 5: Procedurally-generated jungle of Pandora from Avatar 9

Figure 6: Limbo City from Inception 9

Figure 7: The world of Cyrodiil in The Elder Scrolls IV: Oblivion 10

Figure 8: One of many procedurally-generated planets in No Man’s Sky 11

Figure 9: Procedurally-created abstract geometry in Houdini 13

Figure 10: A race track created with the ProTrack plugin in Unity, integrated using

Houdini Engine

14

Figure 11: Sculpture created in Cinema 4D 15

Figure 12: Automated city generation in Cinema 4D using DEM Earth plugin 16

Figure 13: An exterior environment created using Forest Pack Pro in 3D Studio Max 17

Figure 14: Automated model of a woman using Railclone in 3D Studio Max 18

Figure 15: Environment created using Autodesk Maya 19

Figure 16: Automated foliage placement using XGen in Autodesk Maya 20

Figure 17: A scene being created using ProceduRule in Autodesk Maya 22

Figure 18: Generated objects appear only in the white sections of this checker pattern

using a Distribution Map rule.

24

Figure 19: Propagated objects appear around a NURBS curve between a specified inner

and outer radius using a Spline Generation rule.

25

Houser 2

Figure 20: A portion of the 3223 lines of MEL code that make up ProceduRule 27

Figure 21: The graphic user interface for ProceduRule 30

Figure 22: Maya’s Outliner (left) and Attribute Editor (right) 32

Figure 23: Trees placed with no randomization (above) and with randomized rotation

and scale (below)

34

Figure 24: Final beauty frame from visual component 37

Figure 25: The terrain mesh used for the village and forest generation, divided into two

separate meshes

38

Figure 26: The distribution map used to generate huts on the inner terrain, painted in

Autodesk Maya using the built-in Artisan toolset

39

Figure 27: Creating foliage along the stone walkways greatly improved their visual

appearance

40

Figure 28: A finalized shot of the village created using ProceduRule 42

Houser 3

Abstract

ProceduRule: A Procedural Modeling Tool for Autodesk Maya

Joshua F. Houser

March 2017

The creation of believable 3D environments remains one of the most time-consuming tasks for most 3D productions, especially those which require vast or densely-populated virtual sets.

Larger 3D studios overcome this challenge by designing proprietary procedural modeling tools that automate much of this process. Many smaller studios and freelance artists share similar goals but lack these resources. While most commercial 3D applications include some form of

procedural modeling tools or third-party plugins, many of these options only offer highly-specialized functionality or are otherwise poorly suited to the needs of these boutique studios.

Procedural tools are becoming necessary for 3D environment creation, and especially in Autodesk Maya there is a need for a versatile, intuitive, and cost-effective procedural modeling

solution marketed towards smaller studios and freelance artists.

Keywords: Procedural Modeling, Autodesk Maya, Environment Art, Automation,

Propagation, Recursion, MEL Scripting

Houser 4

Introduction

In the computer graphics industry, the creation of 3D environments remains one of the

most time-consuming tasks in the 3D pipeline. Advances in computing power often accelerate

tasks like virtual set creation, but these efficiencies are often combated by heightened

expectations for production scale and visual fidelity. One of many methods by which companies

keep abreast of these demands is by developing or acquiring advanced tools and software. In

the case of productions which require increasingly massive or densely-populated virtual sets,

procedural modeling tools automate and accelerate many tasks required by environment

artists. Virtual 3D locations are often used in live-action films, computer-generated features,

video games, television shows, and commercials; the benefits of implementing such tools apply

to each of these industries.

While procedural modeling tools offer advantages to a variety of developers, their usage

is still largely confined to expediting expensive productions made by high-end studios. Due to

the extended timeline and substantial financial resources associated with these ventures, the

most cost-effective investment for the studio is to develop specialized tools that can overcome

many challenges unique to these projects. Such companies often possess a team of software

engineers with the capability to author such tools, resulting in proprietary solutions that can be

inexpensively modified and reused for sequels or future projects. Unfortunately, smaller

companies and freelance artists must usually accomplish these environment creation goals

without access to proprietary software and without the same ability to create these tools. Even

though a few procedural modeling options have become available for use with commercial 3D

software, including the industry standard application Autodesk Maya, in many cases these

Houser 5

programs are highly specific in functionality and require extensive training to use proficiently.

Since existing procedural modeling tools are often proprietary or too specialized for the variety

of productions handled by many developers, there is a need for a versatile, intuitive, and cost-

effective procedural modeling solution for Autodesk Maya that is marketed towards smaller

studios and freelance artists.

Review of Procedural Modeling Usage

Fig. 1. Procedurally-generated environment from The Good Dinosaur (Parfitt).

Although procedural modeling tools are slowly beginning to integrate into the 3D

pipelines of smaller companies, they are already being used in great capacity to expedite the

production of large-scale Hollywood films. Pixar’s The Good Dinosaur necessitated an ambitious

280 sq. kilometer environment which was procedurally generated based on topographical data

from the United States Geological Survey of the state of Wyoming (McFarland). These data

were not only used to generate the terrain that would make up the backbone of the

environment, but also to inform separate procedural geometry tools that would automatically

Houser 6

populate the environment with rocks, grass, trees, and water (Seymour). Additional software

was used to quickly produce realistic, volumetric clouds based on information gathered by U.S.

government satellites (McFarland). In order to optimize the animation process for the

landscape’s many trees during the heavy storms that take place in the film, over 3500 tree

simulations were generated, cached, and propagated automatically based on the given scene’s

weather conditions (McFarland; Seymour). Perhaps most impressive was The Good Dinosaur’s

procedurally-generated river that featured prominently throughout the film. This key element

was built from prebaked, modular river fragments that could be reused and combined in order

to reduce fluid simulation cache sizes and to minimize render times (McFarland; Seymour). By

developing a robust pipeline that

leveraged these procedural modeling

techniques, Pixar was able to create

breathtaking landscapes rapidly and

efficiently. Without using procedural

modeling tools, this film would likely

have not been possible to produce

within a reasonable timeframe and

budget without making significant

compromises on either scope or art quality.

Fig. 2. Houdini playblast of The Good Dinosaur’s river

simulation (“Making of The Good Dinosaur”).

Houser 7

Fig. 3. Procedurally-generated environment from Big Hero 6 (Hall).

Another film that might not exist without extensive help from procedural modeling tools

is the 2014 Disney film Big Hero 6. The film is set in the sprawling city of San Fransokyo which

consists of approximately 83,000 algorithmically-generated buildings (Xiung). These buildings

were created by randomly selecting components from a series of hand-designed structures

(“hero” buildings) that were based on various districts in San Francisco (Driskill et al.). The

building interiors were automated by using a procedural window shader that generated unique

“activities and lighting” to make the city more believable (Driskill et al.). San Fransokyo was

filled with 260,000 trees and 215,000 street lights that were procedurally propagated

throughout the landscape (Driskill et al.), and the city itself was designed using real world data

provided by San Francisco’s county assessor’s office (“Denizen”). Furthermore, Disney was able

to extend the same principle workflow that constructed San Fransokyo’s buildings in order to

Houser 8

generate hundreds of thousands of fully-animated characters using a proprietary crowd

generation tool called Denizen (“Denizen”). In many ways, this character generator was part of

Disney’s environment creation pipeline as the city would have felt devoid of life without the

crowds of pedestrians it hosts. A procedural workflow has the ability to make foreboding

projects like Big Hero 6 and The Good Dinosaur feasible by allowing developers to meet growing

quality and scale expectations due to rapid increases in the production of repeated content.

Fig. 4. Procedurally-generated crowd from Big Hero 6 (“Marvel’s

Big Hero 6 (by Walt Disney Animation Studios)”).

Procedural Modeling in Live-Action Works

Live-action films are now utilizing procedural modeling tools to expedite their virtual set

creation as well. Avatar, one of the highest grossing films ever produced, took place in an

expansive 3D jungle filled with procedurally-generated foliage. One of the film’s VFX

supervisors, Eric Saindon, explains that their modeling department relied heavily on a

procedural workflow and that many “trees, plants, and ground covers” were developed

efficiently using automation tools and systems (Dunlop). Much of the forest was generated

using an algorithm that grew virtual trees based on realistic parameters such as the amount of

Houser 9

light each received when shadowed by surrounding terrain and other competing foliage

(Dunlop).

Another successful live-

action film that relied on

procedural modeling techniques

was Inception. The concept

behind the film’s enigmatic

Limbo City was based on the idea

of a large glacier that would crumble as the main character Cobb escaped his own subconscious

mind, and so the city’s architectural designed was centered around that premise (Desowitz). A

literal glacier was first modeled, and then proprietary scripts were developed that would

generate a city within that glacier using “increasingly complex rules that added street divisions

or varied the scale of the buildings or added damage, all determined by samples taken from the

glacial model” (Desowitz). As the

demand for visual effects in live-action

films increases, the development of

those CG elements must be

accelerated and automated

procedurally. With the extra

challenges involved when integrating

3D content into real camera footage, the efficiency of automation tools necessitates their

integration to the development pipeline of productions like Inception.

Fig. 5. Procedurally-generated jungle of Pandora from

Avatar (Geller).

Fig. 6. Limbo City from Inception (Desowitz).

Houser 10

Procedural Modeling in Video Games and Television

Fig. 7. The world of Cyrodiil in The Elder Scrolls IV: Oblivion (Rounsaville)

As the film industry began relying heavily on procedural modeling techniques, video

game developers also started to adopt the same time-saving tactics in their own projects. In the

fourth installment of the popular role-playing game series The Elder Scrolls, developer Bethesda

Softworks began utilizing procedural content tools to streamline the production of large-scale

environments for which the company is well known (“The Elder Scrolls IV: Oblivion Interview”).

In order to populate the large world of Cyrodiil in The Elder Scrolls IV: Oblivion, the company

designed a “region editor” that would allow artists to define a section of the world and

automatically populate it with rocks, trees, and various flora with which players could then

interact (Berry). Other titles created by Bethesda Softworks have used the same game engine

that was developed for this project, so this region editor was reused to hasten the production

of later works like Fallout 3 (Finch).

Houser 11

A more modern example of procedural generation in game design can be seen in the

title No Man’s Sky which is built entirely around the premise of automated environment

creation. The game boasts over 18 quintillion realistically-sized planets to explore, each with

completely randomized

content, creatures, and

characteristics

(Khatchadourian). The

company Hello Games

created this universe by

applying various

mathematical formulae to generate naturalistic terrain structures, to construct trees and

foliage algorithmically using L-systems, and to populate these worlds with procedurally-

generated fauna (Khatchadourian). Although the task of creating all of this interactive content

is daunting, procedural modeling makes it possible.

There is ample evidence of how the automation of asset and environment creation has

improved the 3D pipeline in large film and video game productions. These examples further

imply that other productions that utilize computer graphics, including television shows and

commercials, can also benefit from these same advantages. Programs such as The Walking

Dead, Marvel’s Agents of S.H.I.E.L.D., and Game of Thrones rely heavily on 3D computer

graphics, and commercial advertisements have begun featuring an increasing amount of 3D

content in the past decade. The significant differences between these production categories

and those of film and video game development include much tighter deadlines and often a

Fig. 8. One of many procedurally-generated planets in

No Man’s Sky (Phipps).

Houser 12

larger variety of digital content needs. Both of these distinctions make it difficult for studios to

commit time and resources toward creating complex tools that target specific needs for each

project. In contrast to productions such as The Good Dinosaur for which many specific tools

were created, applications like Bethesda Softworks’ region editor reveal how versatile

functionality can prove beneficial for multiple projects. The utilization of broader procedural

modeling tools would be more beneficial to commercial and television productions with these

time and budget constraints.

Review of Procedural Modeling in Commercial 3D Applications

In order to justify the development of an environment automation solution for smaller

studios and freelance artists that lack proprietary tools, one must assess the current procedural

modeling presence in commercial 3D applications. Many competing 3D content creation

programs are available to these artists, so this evaluation focuses specifically on four of the

most successful packages in the industry: Side Effects’s Houdini, Maxon’s Cinema 4D,

Autodesk’s 3DS Max, and Autodesk’s Maya. Many films, animations, shows, and commercials

are developed by utilizing one or more of these applications to create imagery that frequently

includes 3D environments. The proliferation of procedural environment creation techniques

within high-end studios indicates that such a workflow could be advantageous to smaller

developers if the appropriate tools exist for these 3D software. The development of

ProceduRule can thus be justified by examining the successes and shortcomings of the current

non-proprietary automation options in the industry.

Houser 13

Houdini by Side Effects Software

Fig. 9. Procedurally-created abstract geometry in Houdini (“SideFX Releases Houdini 15.5”)

The first of these 3D programs, Side Effects Software’s Houdini, is widely regarded as

the penultimate software for generating hyper-realistic particle effects, fluid dynamics, and fire

or smoke simulations (Boudon). All of this content, as well as its 3D modeling and shading tools,

are organized into a series of modular nodes. Although this is not uncommon among visual

effects software throughout the industry, Houdini is one of the only node-based 3D packages in

which the workflow involves manual manipulation of these procedural nodes and visual scripts

at all levels of production. This results in a highly technical workflow in which the artist typically

constructs an intricate system of modular code pieces which, if deliberately designed, can be

reused and may allow for the automation of a given task. Using this modular node workflow, a

studio that integrates Houdini heavily into its pipeline may not require additional procedural

modeling tools beyond what they themselves can design if given sufficient time and technical

Houser 14

prowess. For content creators who lack the research and development time or expertise to

craft these node structures, there are a handful of user examples online that may offer enough

functionality to meet some fundamental needs (“Orbolt Smart 3D Assets Store”). Developers

can also purchase robust and comprehensive automation tools that accomplish more specific

tasks. One such tool, the ProTrack plugin, is an example which creates procedural racetracks for

use within the Unity game engine (“ProTrack”).

Fig. 10. A race track created with the ProTrack plugin in Unity, integrated using Houdini Engine (“Houdini Indie and

Houdini Engine Indie Now Available on the Unity® Asset Store”)

Despite the advantages of Houdini, there are multiple reasons why the software may be

an unsuitable automation option for smaller studios and freelance artists. Studios who have

already structured their production process around Houdini have likely invested in creating

their own automation tools or have the technical talent available to do so. However, studios

that do not currently use this 3D package would most likely not find a major software transition

Houser 15

to Houdini justifiable. Since Houdini relies much more heavily on a node-based workflow than

most other commercial 3D software, many studios will be deterred by the expense associated

with transitioning artists to this new process. In addition, most content creators who seek to

accelerate their pipeline will benefit more from a preexisting, versatile tool that immediately

meets their needs rather than a major software package which allows for the creation of such

tools. Many publicly-available scripts for Houdini are overly specialized and typically cater to a

narrow subsection of users with specific production goals. In many ways, the versatility and

creative power of Houdini comes at the cost of intuitive workflow and rapid results for studios

who have not yet adopted the software into their pipeline.

Cinema 4D by Maxon Computer

Fig. 11. Sculpture created in Cinema 4D (Herman)

Another popular 3D software package is Maxon’s Cinema 4D, a formidable digital

content creation program with a respectable reputation within the motion graphics industry.

Houser 16

One of the tools included with Maxon’s software package is MoGraph, a motion graphics

toolset that streamlines asset placement with a rudimentary level of procedural modeling

functionality (“Graphics on the Move”). MoGraph is specifically focused on the duplication and

animation of 3D primitives or simple geometry that can be “arranged linearly, radially, in a grid,

or onto existing geometry” (“Maxon Makes Mograph Moves”). Unfortunately, aside from the

inclusion of MoGraph, the environment automation options available for Cinema 4D

predominantly consists of highly-specialized tools. These include “DEM Earth”, a plugin that

generates specific

geometry based on satellite

imagery, “Vector Pro”

which can calculate 3D

geometry based on vector

line input, and “Voxygen”, a

tool that converts existing

assets into a collection of

small, cubic voxels (Everett). The reason that Cinema 4D only offers fundamental procedural

modeling capabilities may be because the software is frequently used to create intricate

animations using simple geometry, not to craft 3D environments. Although one might argue

that adding procedural modeling functionality would advantageously extend the program’s

utility, fewer studios would benefit from this addition than would those who use competing

content creation packages that cater to environment artists.

Fig. 12. Automated city generation in Cinema 4D using

DEM Earth plugin (Everett).

Houser 17

3D Studio Max by Autodesk

Fig. 13. An exterior environment created using Forest Pack Pro in 3D Studio Max (“Forest Pack”)

Few companies have experienced as much success in 3D software distribution as

Autodesk Inc., and one of their most popular applications is 3D Studio Max, also known as 3DS

Max. This software offers a wide selection of unique and progressive modeling functions, and

this advantage has led to its widespread adoption by video game developers who need to

create highly-optimized models quickly (Masters). Like in Houdini, the modeling workflow in

3DS Max can typically be considered non-destructive due to the implementation of its modifier

stack system. The modifier stack manages and compartmentalizes operations on an asset in

such a way that often allows these operators to be removed or reorganized from the stack

without corrupting the model. However, automation is limited with this methodology. Unlike

Houdini’s node-based workflow, each modifier stack in 3DS Max is associated with specific

assets and cannot be used to define a repeatable system or modular functionality. Even so, the

Houser 18

modifier stack allows for some limited automation on specific models as particular operations

can be duplicated across these objects in order to quickly repeat certain tasks.

Autodesk’s 3D Studio Max also benefits from third-party plugins that can add extensive

procedural modeling capabilities to the application. Two products in particular from iToo

Software, Forest Pack Pro and RailClone Pro, extend the program to include a variety of

environment automation options. Forest Pack Pro offers the ability to scatter plants throughout

a 3D scene using a variety of parameters including distribution mapping and object clustering

algorithms (“Forest Pack”). RailClone Pro is

designed around the principle of instancing

architectural objects throughout an

environment using mathematical parameters

and a node-based workflow reminiscent of the

tools built into Houdini (“RailClone”). Both

tools are excellent procedural modeling

additions that would help streamline

environment creation across any projects

involving foliage placement and

mathematically-precise structure design

respectively. Artists seeking this particular functionality while using 3DS Max would benefit

from these plugins, but these modules could have a more limited applicability to studios with a

procedural needs beyond flora generation or architectural visualization.

Fig. 14. Automated model of a woman using

Railclone in 3D Studio Max (“RailClone”)

Houser 19

Maya by Autodesk

Fig. 15. Environment created using Autodesk Maya (“Maya Tutorials”)

While the previous three applications offer a sufficient variety of procedural modeling

options, such functionality has only been integrated into Autodesk Maya in a limited capacity.

Maya includes powerful, specialized tools for every step in the 3D production pipeline and has

historically been considered the preferred, industry standard 3D application for visual effects,

video game, and television production (Wood; Bojc; "5 Reasons Why 3D Animators Should

Know Autodesk Maya"). Despite its widespread adoption across many artistic industries,

environment creation and 3D modeling in Maya typically involves a destructive workflow with

limited automation functionality. The software does utilize a simplified modifier stack and

organizes its content into a series of nodes, but this functionality typically cannot be leveraged

to accelerate 3D modeling or asset placement. The software also includes a Paint Effects toolset

Houser 20

that allows the user to hand-paint premade foliage geometry provided by Autodesk into a

scene, and Autodesk’s official plugin Maya Bonus Tools includes a Paint Geometry tool that

allows for custom geometry propagation. However, these tools only propagate one kind of

mesh at a time, require geometry to be manually placed by the user using the Artisan toolset,

and offer limited randomization options that cannot be easily altered after geometry has been

placed. Despite being one of the most commonly-utilized applications in 3D production,

Autodesk Maya is still not adequately equipped for procedural environment creation with these

tools alone.

Fig. 16. Automated foliage placement using XGen in Autodesk Maya (“Maya Tutorials”)

In recent years, more plugins have been developed to introduce fundamental

procedural modeling functionality into Maya. One such plugin, XGen, was originally created by

Disney and has since been integrated into recent versions of Maya by Autodesk. With this

plugin, objects are placed on geometry by using special locators called “guides” as proxies or by

Houser 21

painting distribution maps onto the base geometry (“XGen Geometry Instancer”). While the

tool specializes in procedural hair generation and animation, it can instead be manipulated into

placing assets of any kind across a given terrain mesh using distribution maps (Perry).

Unfortunately, all assets assigned to a distribution map populate at the same density as one

another and are spaced uniformly across the assigned surface. This can become problematic

when one wants vary the density of one asset over another, and attempting to distribute each

asset individually leads to further problems as XGen also does not detect and prevent object

collision. These limitations can result in unnatural or overly systematic mesh placement as well

as overlapping assets. One benefit of XGen is that object placement and scale can be

customized using a series of mathematical expressions based on MEL, Maya’s built-in scripting

language (“Vary geometry size”). This approach requires an artist who is comfortable with

scripting since there is no graphic user interface alternative for this functionality. Other

limitations for this plugin include a lack of compatibility with Maya’s Viewport 2.0 (the default

viewport), its inability to spread NURBS surfaces across a given terrain mesh or to spread any

assets along a NURBS terrain, and limited ability to manipulate individual assets once they have

been procedurally placed. Although XGen enhances Maya’s automation capabilities, its

cumbersome implementation limits its utility and causes the plugin to pale in comparison to

alternatives in other 3D applications.

There are additional automation plugins for Maya that can be downloaded in order to

achieve some specific procedural endeavors. One of these toolsets, SOuP, attempts to duplicate

Houdini nodes and functionality within Maya (Estela). While this plugin is not immediately

useful as a procedural modeling toolset, it does transfer some of the benefits of Houdini’s

Houser 22

node-based workflow into Maya. Another plugin, XFrog, is a robust procedural modeling tool

that specifically allows users to create a host of trees and flowers dynamically (“XFrog 5.5 for

Maya”). Although specialized in nature, this tool offers a powerful amount of control when

creating complex 3D foliage including individual control over each branch and leaf upon

generation.

Overview of the ProceduRule Automation Tool

Fig. 17. A scene being created using ProceduRule in Autodesk Maya

Given the utility that a multi-purpose procedural modeling tool could provide for

smaller studios and individual artists, I have created an environment automation tool for

Autodesk Maya called ProceduRule. This tool was developed for Maya due to the software’s

leading reputation across multiple different industries and the existing limits of the software’s

current procedural modeling offerings. This new tool allows the user to propagate 3D models

Houser 23

throughout a virtual scene by associating them with a series of “rules” that control how they

are duplicated and placed. Each of these rules consist of a few required components: a user-

defined selection of 3D assets, a surface onto which these models will be procedurally

generated (aka the “terrain”), a guide that determines where the asset will be duplicated across

the terrain, and a series of user settings that randomize instance transformation. The tool

supports two types of “rules” that determine what kind of data will be used to guide asset

placement along a given terrain. Once the user has defined these “rules”, assets can then be

quickly generated and distributed across one or more terrain geometry with a single button

press. Meshes created by ProceduRule are automatically organized in a hierarchy that groups

instances of the same base mesh together and assembles all of these groups into a parent node

associated with the user-defined ruleset that generated them. The tool also ensures that

objects do not collide with one another when placed throughout the scene using efficient

collision detection methods. After generation, the transformation settings for each rule can be

altered and quickly reapplied to the procedurally-generated content until the desired look is

achieved.

Methods of Asset Generation

ProceduRule generates assets along terrain using two distinct rule types; each places

geometry throughout a scene using different kinds of data as input. The first of these is the

Distribution Map rule which utilizes a black and white image as its guide when determining

where assets should be placed. This image can be created within Maya using the built-in 3D

Paint Tool or by using a variety of pre-existing texturing nodes to construct an appropriate data

graphic. In addition, the image can be created using any additional image generation or

Houser 24

manipulation software outside of Maya and can be imported as a 2D texture file. When a black

and white texture or a channel from a color graphic is assigned to a Distribution Map rule, the

image is mapped to the terrain object and is used to determine valid locations in which an asset

can be instanced during the generation process.

When using a distribution map to propagate geometry along a terrain mesh, the

terrain’s UV coordinates determine the locations along its surface on which instanced assets

may be placed. If the

distribution map is white

at that UV position, the

asset can be duplicated

there. A darker section of

the map indicates a

location that is more

likely to remain empty after generating assets, and a black section of the map denotes areas of

the terrain on which assets may not be placed at all. Theoretically, this functionality could be

extended to allow variables within the 3D environment to be read as distribution maps. Some

example of this behavior would be to propagate fallen leaves only on the top of a terrain mesh

using a Y-axis texture operation or to place mushrooms in areas that receive less light by

generating a graphic based on the terrain’s surface luminance. This would further extend the

high degree of control Distribution maps provide when populating a scene.

The second rule type in ProceduRule is the Spline Generation rule which restricts asset

placement to a specified region along or near a given spline curve. Using either a NURBS or

Fig. 18. Generated objects appear only in the white sections of this checker

pattern using a Distribution Map rule.

Houser 25

Bezier curve as the guide, users can define a path around which a supplied list of assets can be

propagated. In its simplest form, this rule allows these assets to be placed randomly along a line

on the terrain mesh and could be useful when placing a row of leaf clusters along a tree branch

or when placing rocks in a winding river. The user can optionally define an outer radius around

the spline within which

assets may be duplicated,

making the objects’

placement appear more

natural and randomized.

An inner radius around

the spline can additionally be defined to limit asset placement to the region between the inner

and outer constraints. For example, the inner radius can be used to quickly place shrubs around

a river but not in the river or to place debris along the edges of a room or hallway while leaving

the center cleared away. If the radii values are increased enough, a guide spline’s influence

becomes less obvious and the placement of assets appears more natural and random.

Although ProceduRule currently offers two rules for controlling asset generation, a

theoretical third functionality could allow for a combination of the two methods. The

implementation of a Hierarchal Recursion system would enable rules to be associated with

each other in a parent-child relationship, combining the benefits of each rule to form more

versatile and specific rules. This hierarchy structure could additionally generate assets that, in

turn, could become the terrain for secondary rules that recursively generate their own objects.

For example, a user could create individual tree trunk, branch, and leaf assets. By assigning one

Fig. 19. Propagated objects appear around a NURBS curve between a

specified inner and outer radius using a Spline Generation rule.

Houser 26

rule to place the tree trunks on a terrain, a second rule to place branches on the trunks, and a

third rule to place leaves on the branches, one could theoretically create a randomized forest

from only a few simple assets. Challenges with implementing this functionality would include

maintaining reasonable asset generation times when utilizing multiple recursion levels as well

as ensuring that understanding and navigating this hierarchal interface was self-explanatory.

Developing the tool using MEL

ProceduRule was coded within Maya’s Script Editor using its built-in Maya Embedded

Language (MEL). This decision was made in order to expedite development and debugging time

as Autodesk offers additional documentation and support for MEL scripting. Perhaps the most

useful reference material can be found within Maya itself via the Script Editor’s command

echoing functionality. As a user works in Maya, the Script Editor continuously outputs a log of

MEL commands that mirror the user’s mouse and keyboard inputs. This feedback allows a

programmer to quickly expand his or her repertoire of functions by incorporating any user

action with which he or she is familiar. When combined with Maya’s ability to automatically

direct the user toward documentation for any command, developing with MEL in the Script

Editor minimized research time greatly and allowed for faster code iteration.

An alternative approach to creating a tool for Autodesk Maya would have been to script

using Python. Maya supports three different Python wrappers, and each comes with its own set

of advantages and disadvantages. The first of these, maya.cmds, allows the user to directly call

most MEL commands using Python. This results in a language with a cumbersome hybrid syntax

that is reminiscent of neither MEL nor Python and that does not include all MEL commands

(“PyMEL for Maya”). Furthermore, maya.cmds functions are not echoed in the Script Editor and

Houser 27

do not consistently outperform the code execution speeds of any other coding options within

Maya (Szczepanczyk). However, all of these wrappers include the inherent functionality of

Python which can be a major benefit for certain scripting projects.

Fig. 20. A portion of the 3223 lines of MEL code that make up ProceduRule.

PyMel is an alternative that remains more faithful to Python syntactically while focusing

on legibility and development ease. PyMel tends to evaluate quickly when performing basic

operations but takes much longer whenever it creates instances of predefined PyMel classes

(Szczepanczyk). Since this instancing occurs when executing many functions, PyMel can often

run more slowly overall than either MEL or maya.cmds. The advantages of PyMel are most

apparent in its object-oriented design and its organized syntax, both of which make it the

Houser 28

simplest Python wrapper to utilize. This is in direct contrast with MEL (and, by extension,

maya.cmds) which operates largely as a procedural language that executes linearly and reuses

predefined blocks of code known as “procedures” (“PyMEL for Maya”). Object-oriented

programming allows PyMel to perform similar tasks with fewer lines of code, making it the

most organized and readable option.

The remaining Python wrapper is OpenMaya, the C++ API commonly used to develop

plugins and high-performance extensions of the Maya software. While this wrapper evaluates

and executes much faster than any of the preceding options, such speed comes at the cost of

development time. OpenMaya is a low-level, technical language that typically requires

significantly more code to develop the same functionality that certain MEL commands

encapsulate in a single line. Like maya.cmds, OpenMaya attempts to blend Python with another

coding language and thus results in an unwieldy syntax which can further complicate the

development process (“PyMEL for Maya”). This alternative, like the other Python wrappers,

offers less built-in support and documentation than MEL. OpenMaya is excellent for the most

technical of projects but also takes the longest and is the most difficult to use effectively.

Design Philosophies of ProceduRule

The development of ProceduRule is focused on accomplishing a series of four design

philosophies: the tool must be broadly applicable to many projects, must be easy to use and

intuitive, must be flexible and offer plenty of user control, and must efficiently accelerate the

environment creation process. Each of these basic intentions fulfill a key justification for the

tool’s development and use. These principles were derived from the advantages of using

Houser 29

procedural modeling software particularly as they apply to smaller studios and freelance artists

using Autodesk Maya. Both the successful qualities of automation tools in other 3D packages as

well as from the missing features of existing commercial automation software inspired these

fundamental goals.

I. Broad Applicability

The first of these design goals is to develop a tool that is versatile and could be helpful in

a variety of projects. Such a tool must be useful in a general sense for any production that

requires large environments, repeated assets, or smaller elements that need to be placed on a

larger model. This is partially motivated by the tool’s target audience since studios much

smaller than Pixar or Disney would not have the resources to create or acquire a separate tool

for each of their endeavors. In order to meet the needs of this audience, a utility like

ProceduRule must prove genuinely useful across a vast array of projects. In order to accomplish

this goal, the tool is designed to work with polygonal models as they are the most commonly

used and distributed asset type for many types or projects. The parametric nature of

ProceduRule ensures that it will work with any mesh or group of meshes the user chooses; the

distribution map rule is especially versatile by similarly operating on any supplied texture. The

tool would be made even more broadly useful if hierarchal recursion were implemented. This

advanced feature would greatly expand the possibilities of the existing rule types and would

potentially allow the tool to be used as an automated asset creation utility.

Houser 30

II. Ease of Use and Intuitive Design

Fig. 21. The graphic user interface for ProceduRule.

The second design philosophy around which ProceduRule was developed is ease of use

and intuitive design. In order to accomplish this mission, the user interface (UI) for ProceduRule

was inspired by the existing Maya interface. ProceduRule’s user interface is divided into two

vertically-oriented panels that share similar designs, functionality, and placement with two

Houser 31

commonly-used dialog boxes of Maya: the Rule List (similar to Maya’s Outliner) and the Settings

Panel (similar to Maya’s Attribute Editor). By mirroring the original software’s design principles,

the same advantages that have helped make Maya’s UI reliable and useable can be applied to

ProceduRule. The tool has been carefully constructed to promote convenience and flexibility in

the same ways that Maya accomplishes those goals.

The Rule List on the left side of the ProceduRule window displays all of the user-created

rules as well as the geometry which has been assigned to those rules. This pane is chiefly

responsible for managing which assets are to be added to or removed from the created rules.

The relative density of each asset, a value that represent the proportional relationship of each

asset to the others, can also be set here. For example, if all assets have a density value of 1,

increasing the value of an asset to 3 will make it spawn three times more often than its peers.

Users can also lock certain rules or assets here to prevent changing them when updating user

settings or re-generating rules. Each rule in the list is color-coded by type and, when selected in

the Rule List, populates the Settings Panel with its customizable attributes. The Settings Panel

on the right side of the ProceduRule window displays various rule-specific settings including the

name of the rule, its assigned terrain, the overall number of objects the rule should attempt to

generate, and which distribution map or spline to use as a guide for the given rule. In addition

to these settings, this panel also includes a collapsible menu with a series of transformation

parameters which can be used to randomize each automatically-generated asset’s position,

rotation, or scale.

Given the wide array of functions that ProceduRule presents to the user, designing the

tool’s user interface with human factors in mind is imperative. Many guidelines for organizing

Houser 32

human-computer interaction can be applied for multiple different software projects; often the

same or similar doctrines aid in designing websites, operating systems, or other software

applications (Shneiderman and Plaisant). One of these guidelines states that the execution of

tasks with similar conditions should be standardized in order to promote user familiarity and

efficiency (Shneiderman and Plaisant; United States of America). The commonalities between

ProceduRule’s two panes and Maya’s Outliner and Attribute Editor allow users to intuit the

tool’s functionality with minimal explicit instruction based on existing Maya experience. The

creation and modification of both types of rules share organizational similarities as well since

many of the variables for both rule sets are identical.

Another common interface standard suggests that content should be labeled

descriptively and should only be presented if they assist the operator (Shneiderman and

Plaisant). When ProceduRule is first opened, the two panes are initially almost empty and only

show options to create

rules. Once a rule is

created, additional

decisions become visible

only as they become

relevant to the user: the

settings panel dynamically

populates with adjustable variables only after those variables become relevant to a newly-

created rule. These settings are labeled with succinct and clear headers and are organized into

groups and subgroups that can be collapsed to simplify the input on which the user must focus.

Fig. 22. Maya’s Outliner (left) and Attribute Editor (right).

Houser 33

These same practices have been implemented in Maya’s Outliner and Attribute Editor in a

similar fashion. Additionally, ProceduRule provides support and optimization recommendations

in the form of prompt windows that appear only when the user encounters such situations. This

limits the need for extensive documentation by only informing the user if the information is

pertinent.

A third major human factors guideline states that a tool’s design should be “relevant,

sufficient, but not excessive, to allow [the user] to make decisions and perform the intended

actions.” (United States of America) NASA emphasizes this guideline with the assertion that

“too little or too much information decreases efficiency or makes task completion impossible.”

Two of the original Maya interface designers, George Fitzmaurice and Bill Buxton, embodied

this guideline with their philosophy for the program’s UI design: “to reduce complexity while

augmenting the ability of users to get their work done.” While ProceduRule offers a lot of

versatile functionality, it manages to do so with a relatively limited number of user variables.

The tool further accomplishes this goal of simplicity through a well-organized and consistently-

labelled interface that compartmentalizes complex functions into smaller groups and sub-

groups of settings. By streamlining the presentation of its advanced features, the user is not

overwhelmed with options yet maintains the same creative capacity. In addition, ProceduRule

automates certain technical tasks in order to streamline the creative process. Examples of this

behavior include the tool automatically converting Bezier curves to NURBS curves for spline-

based rule compatibility, initially supplying the most common default values for the randomizer

settings, robustly detecting color attributes for distribution map analysis from a wide range of

Houser 34

possible output formats (outColor, outAlpha, output, outValue, etc.), and seamlessly handling

the propagation of groups and parented shape node hierarchies.

III. Flexibility and User Control

The third design philosophy of ProceduRule is to offer a significant amount of user

control over the end result so that artists may more easily achieve believable, natural-looking

results. Much of this goal is

achieved by allowing the users a

high degree of flexibility when

creating distribution maps or when

defining a region around a spline.

The ability to adjust the relative

density of the assets assigned to

each rule offers increased control

over the resulting output.

Furthermore, both the choice to

instance assets instead of

duplicating them and the option to

disable or increase the accuracy of

the collision detection gives artists an extra degree of control over the tool’s overall efficiency

and output quality. The artist can additionally decide whether objects in a rule should maintain

its orientation no matter how sloped the terrain beneath them appears to be (operating like

trees or buildings on a hill) or should conform to the terrain angle (like rocks or cars on a hill).

Fig. 23. Trees placed with no randomization (above) and with

randomized rotation and scale (below).

Houser 35

Another control was created to randomize each asset’s local Y position offset after they have

been placed. This is particularly useful when placing trees or other stem-based plants, but it can

also be an effective means of scattering airborne or underwater assets within a certain height

range above or below a surface. Lastly, the rotation and scale of every generated asset can be

randomized between custom minimum and maximum ranges along each axis, and those values

can be snapped incrementally based on the user’s preference (for example, rotated only along

45 degree angles or scaled in whole number increments). Each of these variables equip the

artist with powerful control over the appearance of his or her procedural generation.

IV. Efficiency and Expediency

The fourth and final design goal for ProceduRule was to ensure that the tool could

produce results within a reasonable time frame and allowed for rapid iterations. The most time-

consuming step in ProceduRule’s asset generation process is the collision detection pass in

which assets that overlap another are removed, and to accomplish the efficiency goal this

process had to be adequately optimized. During collision detection, the space into which

generated assets are organized is partitioned into smaller sub-sections and organized into a

quadtree data structure. Doing this allows an asset’s collision check to only assess assets that

are in close enough proximity to itself to share its region of the quadtree while automatically

assuming that assets outside of its own quadtree section are too far away to physically collide

with it. This operation occurs dynamically and recursively based on the asset density in each

quadtree section until there are few enough assets in each to justify an expensive collision

check (Wang and Wang). The user has direct control over the collision detection process as

well. Each rule’s collision method can be set to per-poly collision for maximum accuracy, can be

Houser 36

switched to a much faster bounding box check if simplistic collision yields adequate results, or

can be disabled altogether if desired. These many optimizations contribute to the tool’s

expedient runtime when propagating assets throughout an environment.

In addition to generation efficiencies, certain ProceduRule functions were specifically

designed for the user’s convenience to accelerate the generation pipeline. The ability to lock

rules and assets in the Rule List allows users to make fast adjustments to specific objects while

maintaining desired results for other ProceduRule elements. In order to prevent slowdown

from user errors, much care has been put into ensuring that asset generation is placed into

Maya’s undo history and that unnecessary calculations are excluded from this process to

ensure that undo operations execute quickly. If an artist needs to maintain object placement

but tweak other parameters like scale or rotation, a rule can be updated instead of regenerated

in order to apply new setting values without deleting and replacing any assets. These features

are designed to increase artist efficiency and to ensure results are generated quickly.

Houser 37

Results of using ProceduRule Automation Tool

Fig. 24. Final beauty frame from visual component

In order to test the efficacy of ProceduRule, the tool was used to create a test

environment. The goal was to make a small village nestled among rolling hills that were covered

with trees and shrubs. In this environment, the buildings would be linked together by stone

pathways, and there would be a river lined with bushes nearby. The environment would

normally be time-consuming to produce due to the tedium of achieving the desired foliage

density, variety, and placement by hand. A useful procedural modeling tool should significantly

expedite such a process and should handle placing a wide variety of assets while ensuring that

they do not collide unrealistically. In order to construct the environment, six tree assets, six

varieties of shrub, and three versions of the hut were created ahead of time. The hills, stone

pathways, and river would be added without ProceduRule, but the placement of the other

assets was executed using the tool.

Houser 38

One large, subdivided plane was sculpted within Maya to create the rolling hills which

would act as the foundation for the environment. That plane was split into two meshes: the

inner terrain that would hold much of the important content (the huts, the river, etc.) and the

outer terrain that surrounded this main area and contained mostly trees and shrubs. Dividing

this plane was an optional

decision that allowed for slightly

more organization regarding

which assets spawned where. As

an additional bonus, this

approach optimized the surface

area that ProceduRule needed to process when placing each set of assets. The distribution map

for the huts was painted using Maya’s Artisan toolset; this texture defined the regions of the

inner terrain where the buildings could be placed. Generating the huts only took a few seconds

and could be repeated quickly with brief adjustments to the distribution map until the desired

results were achieved. ProceduRule chose from the three hut varieties with which it was

supplied based on the relative density controls set by the user. Each hut’s rotation and scale

were automatically randomized by the tool and required only minor manual adjustment

afterwards.

The generation of trees and shrubs calculated more slowly, but using ProceduRule for

this process still saved time and allowed for enhanced visual flexibility and scene organization.

Three individual asset groups were generated to create this foliage: the trees and bushes on the

outer terrain, the trees and bushes on the inner terrain, and the shrubs that would generate

Fig. 25. The terrain mesh used for the village and forest

generation, divided into two separate meshes.

Houser 39

along the river. The first two of these groups were driven by distribution map rules while the

latter was placed using a spline-based rule. The fluid simulation for the river itself was

calculated and rendered in Houdini and would serve as a visual cue for the appearance of the

bushes. In Maya, a NURBS curve was drawn over the river bed and, using the inner and outer

radius controls, the shrubs were easily placed just beyond the area that the fluid touched.

Controlling both the number of assets that ProceduRule generated and the relative proportion

of each kind of asset was handled using the tool’s density settings. Additionally, the collision

accuracy was reduced for some assets in order to generate them more quickly when a large

volume of meshes was needed. Automating the placement of the two largest tree groups took

roughly thirty minutes each due

to the high complexity of the

meshes, the number spawned,

and the need for collision

checking. Over 700 assets and

more than eight million polygons

were placed in those rules. After the assets were generated, ProceduRule’s hierarchical object

grouping proved beneficial later when selecting objects to assign to render layers and when

creating matte passes for each type of foliage.

After connecting many of the huts to one another by creating stone pathways between

them, an unforeseen issue arose: these paths intersected with the ground in a way that created

a hard, undesirable visual line. To solve this problem, the NURBS curves that were used to

model the original paths were repurposed for new spline-based ProceduRule rules. These rules

Fig. 26. The distribution map used to generate huts on the inner

terrain, painted in Autodesk Maya using the built-in Artisan toolset.

Houser 40

were responsible for placing small bushes and shrubs along the border of each path to cover up

this jarring edge. ProceduRule generated 2,830 assets (a total of more than 4.56 million

polygons) along nine paths with collision checking disabled and spent approximately 2-5

minutes per path. Minor positional and rotational tweaks were made manually for hero assets

in order to get the desired look for certain shots, but approximately 95% of those assets

required no additional adjustments. One of the shrubs needed to be slightly altered after

ProceduRule had made hundreds of duplicates throughout the scene. The tool’s optional

instancing functionality allowed tweaks to the original model’s geometry to automatically

propagate to the thousands of duplicated shrubs.

Fig. 27. Creating foliage along the stone walkways greatly improved their visual appearance.

While the use of ProceduRule made creating this environment a much easier and faster

task than was otherwise possible, the experience was not without its limitations. Firstly, when

high-polygon models were propagated in large numbers with collision detection enabled, the

overall calculation time grew significantly. ProceduRule especially slowed down when

Houser 41

duplicating object groups under these conditions, but the tool created warnings that suggested

combining the group into a single model to prevent the additional slowdown. The time spent

generating assets was still far less than the time it would take to complete the same process

without an automation tool, and the artist could still work on other tasks outside of Maya while

ProceduRule was processing, but the delay highlighted the cost of ProceduRule’s collision

detection algorithm. Secondly, at no fault of the automation script, Maya slowed down

considerably when selecting or operating on large numbers of objects. This problem became

worse when render layers were introduced as the scene had to be reprocessed by Maya each

time a render layer was selected, causing prohibitively long wait times in certain cases. By

combining objects that were generated by ProceduRule into a single model, this problem could

be mitigated at the cost of losing post-generation ProceduRule functionality on the given

assets.

Overall, the use of ProceduRule resulted in the desired environment being created much

more quickly than one could without using the tool. The tool’s organization, flexibility, and fast

iteration times allowed the software to be useful both for creating the majority of the

environment as well as troubleshooting unexpected issues.

Conclusion

Based on its design goals, robust functionality, and ability to speed up the 3D

environment creation workflow, ProceduRule demonstrates that thoughtfully-crafted

automation tools can successfully fulfill the needs of smaller studios and freelance artists who

lack the resources of larger studios. These utilities enable the creation of massive, densely-

Houser 42

populated worlds in reasonable timeframes which can mean the difference between whether a

project is viable or impossible. By expanding the possibilities of what can be accomplished by

smaller studios or within tighter schedules, the capabilities of the computer graphics industry

expand as well, especially in commercial or broadcast environments where time constraints can

dramatically limit a project’s scope or quality. ProceduRule helps demonstrate the efficiency of

working with procedurally-generated content and how automation tools enable 3D studios and

artists across all vocations to expand beyond their current creative boundaries.

Fig. 28. A finalized shot of the village created using ProceduRule.

Houser 43

Appendix A: Written Tutorial

I. Introduction

ProceduRule is a procedural modeling tool that specializes in propagating polygonal

meshes across large environments. This is accomplished by creating rules, selecting a terrain

object, assigning geometry to be generated via those rules, and then adjusting transformation

parameters as needed. In this tutorial, you will learn how to navigate the user interface, how to

create and use the Distribution Map rule type, and how to create and use the Spline Generation

rule type. Before covering this material, a list of important terminology must be defined:

Rule: A set of guidelines which define how assets are created by ProceduRule. Rules

have a type (Distribution Map or Spline Generation) and contain various user settings

(collision detection, random transformation, etc.) that control how the rule places

assets.

Asset: Any element that is part of a digital media composition. In this tutorial, “asset”

will refer to any polygonal mesh in a 3D scene. In ProceduRule, these are assigned to

rules, and duplicates or instances of these assets are generated along terrain objects.

Terrain Object: A single polygonal mesh on which the duplicates or instances will be

generated.

Distribution Map: A texture in Maya that determines where duplicates or instances are

allowed to generate. This refers to either a black-and-white texture or a single channel

from a color texture. On distribution maps, a black (or zero) value corresponds to areas

Houser 44

where assets cannot generate, and a white (or one) value corresponds to areas where

assets can generate.

Spline: A NURBS curve or Bezier curve within Maya. These are used in “Spline

Generation” rules to define where assets may be placed.

Duplicate: An object within Maya that was created by copying another object’s shape

and transformation data. Once a duplicate object has been created, it is completely

independent from its source object. In ProceduRule, these objects will always be copies

of polygonal meshes that the tool has generated when “Use Instancing” is disabled.

Instance: An object within Maya with unique transformation data that shares another

object’s shape data. An instance is dependent on the geometry of its source (or parent)

object, and all changes made to the geometric structure of the parent will also affect the

children objects. In ProceduRule, these objects will always be copies of polygonal

meshes that the tool has generated when “Use Instancing” is enabled.

Generate: The act of creating copies of the geometry associated with one or more rules.

The generation process assumes that duplicates or instances previously associated with

each rule will automatically be deleted and replaced with the new assets that are being

generated. “Generating a rule” refers to generating all assets associated with that rule.

Update: To reapply new, randomly-generated transformation settings to the objects

within one or more rules without actually generating new objects.

Lock: To disable generation or updates for specific rules or certain assets in these rules.

Total Object Density: The maximum number of duplicates or instances that a rule can

create.

Houser 45

Relative Density: The priority of one asset compared to all others in a given rule. Assets

with higher priorities have a higher chance of appearing when a rule is generated.

II. Navigating the User Interface of ProceduRule

Below is a breakdown of the various elements that comprise the UI of ProceduRule:

Houser 46

1. Rule List: The left half of the ProceduRule interface. This displays the rules that have

been created in this Maya scene file as well as each asset that has been assigned to

those rules (which are displayed in a list below each rule). This pane is used to assign or

remove assets to rules, to select rules to be edited in the Settings Panel, to adjust the

relative density of a rule’s assets, and to lock or unlock rules or assets.

2. Settings Panel: The right half of the ProceduRule interface. This displays the various

parameters that define how a rule behaves. This pane is used to assign terrain objects to

rules, assign distribution maps or splines to rules, set a rule’s total object density, adjust

collision checking and instancing settings, and alter randomized transformation settings.

3. Rule: A user-created rule. If clicked, this makes that rule active by bringing its settings up

in the Settings Panel.

4. New Rule Buttons: These, when clicked, create a new rule of the given type. If an asset is

selected when a rule is created, this is automatically assigned as the rule’s Terrain

Object.

5. Add Selected To Rule Button: If an asset is selected when this button is clicked, it will be

assigned to the currently active rule.

6. Lock Rule / Lock Asset Button: These, when clicked, lock or unlock the rule or asset

which sits along the same horizontal row as the button. As long as a rule is locked, it is

assumed that all of its assets are locked as well.

7. Remove Rule Button / Remove Asset Button: If this is next to a rule, this deletes the

rule. If this is next to an asset, it removes it from the associated rule.

Houser 47

8. Relative Density Box: Displays the relative density of the associated asset within its

parent rule. If clicked, the user can edit these values directly. When the rule is

generated, the value for each relative density compares to the others as a ratio, roughly

determining the proportion of each kind of asset that will be generated for that rule.

9. Rule Name Box: Allows the user to change the name of the active rule in the Rule List for

organizational purposes.

10. Terrain Object Buttons: These allow you to define a rule’s terrain object. The “New”

button sets the terrain object to be whichever polygonal mesh is currently selected. The

“X” button removes the current terrain object from this rule.

11. Distribution Map or Spline Settings: Allows the user to assign a distribution map or

spline to the active rule. This setting looks different depending on the currently-selected

rule; the distribution map version is shown in the above image.

a. If this is a Distribution Map rule, the user must type the name of the texture

node within Maya and press ENTER to set the distribution map. The user can

then either choose which channel of the texture to use or can click the “X”

button to empty this value.

b. If this is a Spline Generation rule, the user assigns a new Spline to the rule by

selecting a NURBS or Bezier curve and clicking the associated “New” button in

the Settings Panel.

12. Total Object Density Box and Slider: Allows the user to set the rule’s total object density

(the maximum number of duplicates or instances that the rule can generate).

Houser 48

13. Rotate to Match Terrain Normal: If this box is checked, propagated geometry will be

rotated to conform to the curvature of the terrain object, pointing in the direction of its

surface normal. If this box is unchecked, propagated geometry will be oriented with a

default rotation of 0 in all three axes (not including the effects of randomizer settings).

14. Use Instancing: Enabling this option creates instances instead of duplicates when

generating rules.

15. Collision Check Method Dropdown Menu: This allows the user to select from one of

three collision checking methods. Collision checking in ProceduRule removes inter-

penetrating assets within the same rule to ensure that objects do not collide with each

other. The three methods are:

a. Disabled: No collision checking occurs.

b. Bounding Box: If objects’ bounding boxes overlap, then the objects are colliding

with one another. This method is relatively fast but can be less accurate.

c. Per-Poly Collision: If one object has faces that overlap with another object, then

the objects are colliding. This method is relatively slow but is very accurate.

16. Translate Randomizer Settings: These settings alter the vertical placement of objects

generated by this rule. The user can randomize a world-space offset (an additional Y

translation that ignores the object’s rotation) and/or a local-space offset (an additional Y

translation that moves the object “upward” based on the object’s rotation).

17. Rotate Randomizer Settings: These settings alter the rotation of objects generated by

this rule along the X, Y, or Z axes.

Houser 49

18. Scale Randomizer Settings: These settings alter the scale of objects generated by this

rule. The user can adjust the scale both uniformly and along the X, Y, or Z axes.

19. Enable Randomizer Checkboxes: Each row of randomizer settings does nothing unless

this checkbox is enabled for the associated row.

20. Min, Max, and Increment Values: These boxes determine how an enabled randomizer

setting operates. When enabled, a random value between the Min and Max numbers

will be selected for each duplicate or instance associated with the active rule. If the

Increment value is greater than 0, then all selected values will be divisible by the

provided value (ex.: an asset may be set to only rotate in 90-degree increments).

21. Refresh Button: If the Rule List no longer accurately reflects what is currently within the

opened Maya scene, clicking this button will update the Rule List to match the scene.

This can happen if a terrain object is deleted from the scene, if assets or rules are

deleted manually by the user, or if a new scene is opened while ProceduRule is open.

22. Empty Unlocked Rules Button: If clicked, this deletes all duplicates or instances in all

currently unlocked rules. This does not affect duplicates or instances whose parent

assets are locked.

23. Generate Button: If clicked, deletes all duplicates or instances in all currently unlocked

rules and generates new ones according to the latest user settings for each rule.

24. Update Button: If clicked, applies new randomized transformation settings to the

duplicates and instances within one or more rules without actually generating new

objects.

25. Cancel Button: Closes ProceduRule.

Houser 50

III. Populating an Environment Using Distribution Map Rules

The Distribution Map rule type places objects based on a supplied Maya texture. This

can be a 2D texture node, a texture painted within Maya using the 3D Paint tool, or an external

image file that has been imported into Maya using a File node. Below is a step-by-step tutorial

on how to create, set up, and successfully generate objects using a Distribution Map rule.

Step 1: Create a new Distribution Map rule using the button in the Settings Panel.

Step 2: Assign your terrain to the rule (select it and clicking “New” in the Settings Panel).

Houser 51

Step 3: Add the assets you want to procedurally generate to the rule by selecting them

and pressing the “+” sign by the rule or by pressing “Add Selected to Rule” in the

Settings Panel.

Step 4: Create your distribution map and assign it to the rule. An easy way to create a

distribution map is by painting one using the 3D Paint Tool built into Maya.

This tool can be found in the “Rendering” menu set under “Texturing”.

Houser 52

a

To assign this texture to your new rule, type the name of the associated Maya texture

node in the Settings Panel and press ENTER.

Click on “Assign/Edit Textures” in the

3D Paint Tool settings to create a

new 3D Paint Tool texture, then

specify its size and format. To save

your changes, click “Save Textures”.

Houser 53

Sometimes it is helpful to apply this texture to a material and assign it to the Terrain

Object as additional visual confirmation. You can find the names of all of the current

scene’s texture nodes in Maya’s Hypershade editor.

Step 5: Set the remaining parameters in the Settings panel to suit your needs. Be sure to

define the Total Object Density and your desired Collision Check Method. Altering the

other variables are optional but may improve the visual quality of the tool’s output.

Step 6: Click “Generate”, and wait for your geometry to appear. Congratulations, you

have successfully created and used a Distribution Map rule!

Houser 54

IV. Populating an Environment Using Spline Generation Rules

The Spline Generation rule type places objects based on a supplied NURBS or Bezier

curve. This spline is placed above the terrain, and assets are procedurally generated at points

on the terrain which are beneath and in close proximity to it. The surface area in which assets

are allowed to appear can be expanded and constricted using two additional settings: the outer

radius and inner radius. The outer radius expands the area around the spline in which objects

can be created. The inner radius specifies an area beneath the spline in which objects must not

appear. In order to use the inner radius, an outer radius must be specified and must be larger

than the inner radius. Below is a step-by-step tutorial on how to create, set up, and successfully

generate objects using a Spline Generation rule.

Step 1: Create a new Spline Generation rule using the button in the Settings Panel.

Houser 55

Step 2: Assign your terrain to the rule (select it and clicking “New” in the Settings Panel).

Step 3: Add the assets you want to procedurally generate to the rule by selecting them

and pressing the “+” sign by the rule or by pressing “Add Selected to Rule” in the

Settings Panel.

Houser 56

Step 4: Create your spline and assign it to the rule. An easy way to create a spline is by

drawing a NURBS curve using Maya’s CV, EP, or Bezier curve tools (Create > Curve tools).

Step 5: Set the remaining parameters in the Settings panel to suit your needs. Be sure to

define the Outer Radius and Inner Radius as needed, and don’t forget to set both the

Total Object Density and your desired Collision Check Method. Altering the other

variables are optional but may improve the visual quality of the tool’s output.

Step 6: Click “Generate”, and wait for your geometry to appear. Congratulations, you

have successfully created and used a Spline Generation rule!

Houser 57

Appendix B: User Testing Feedback

Upon the completion of ProceduRule, the tool was tested by several 3D artists currently

working in the computer graphics industry. These testings sessions came with minimal

explanation beyond the purpose behind and the general functionality of the tool. The testing

period lasted approximately 30-60 minutes per user. Users worked within a simple scene of

primitives and were afterward shown an example of the tool being applied to create the village

scene described above. The criteria that determined which users could authoritatively

comment on the quality and utility of the tool included:

Two years minimum experience working in the industry,

Experience with Autodesk Maya,

Experience with proprietary and commercial industry tools for use in 3D packages, and

Occupations that could necessitate the use of a procedural modeling tool.

The commentary of these artists include their impressions upon using the tool as well as their

suggestions for improvement should the tool be further developed beyond the scope of this

thesis.

Warren Drones

Position: Technical Artist at Trick 3D

Relevant Experience: Environment and 3D modeling experience; Maya experience;

programming and scripting experience

Houser 58

Would this tool be useful in production? “Yes, it would be very useful for set dressing,

particularly adding debris to scenes. It would be especially useful for spreading assets

across more intricate 3D terrain.”

Would this tool save time overall? “Yes, for sure. It would especially save time when working

with large scenes or a large number of different objects.”

Is the tool easy for you to understand and use? “Yes. I found it pretty straightforward and

figured everything out rather easily.”

Is the graphic user interface well organized? “Overall, yes.”

Appreciates that it’s organized on a single page instead of across multiple windows or

tabs. Especially appreciates how the Rule List functions as a “built-in mini outliner.”

Likes the consistency and clarity of the color-coded information within the UI.

The inclusion of (and speed of) “Undo” functionality is “much appreciated.”

Wants additional descriptive text for the randomizer settings.

Would want a thumbnail preview of the currently-selected distribution map or the

ability to browse for existing textures in Maya using ProceduRule.

Do you think assets should continue to be placed based on their pivot point in ProceduRule?

“Absolutely. That makes the most sense, and I would be surprised if it didn’t.”

Erica Penk

Position: Pipeline Technical Director at Trick 3D; previously Effects Technical Assistant at Turner

Studios.

Relevant Experience: Industry standard tool creation for 3D pipeline; Maya experience

Would this tool be useful in production? “Yes, certainly.”

Houser 59

Would this tool save time overall? “Yes, assuming it does not take long to create the

distribution maps or splines associated with the tool’s rules.”

Is the tool easy for you to understand and use? “I am able to figure out the majority of the tool

with ease.”

Especially found the pop-up window feedback that provided more information,

especially when the user attempted to propagate asset groups (optimization warning

that suggests collapsing the group into a single mesh).

Expressed some confusion about how the Refresh button worked.

Elements of the graphic user interface could use tooltips.

Is the graphic user interface well organized?

Wants the lock layer buttons to use an image instead of an “L”.

Felt that the Settings panel was “a bit cramped” and should be organized as more of a

collapsible hierarchy than it currently is.

Wishes that “Generate” and “Update” were labelled differently.

Felt that indentations should be used to clarify hierarchy in Rule List pane if possible.

Do you think assets should continue to be placed based on their pivot point in ProceduRule?

“I wouldn’t assume that it would use the pivot point. Maybe it should be made explicitly

clear in the tool that’s how it places them.”

Tim Spanjer

Position: Senior 3D Artist at Trick 3D; previously Lead Environment Artist at Meggit Training

Systems.

Houser 60

Relevant Experience: Environment and 3D modeling experience; Maya experience; 3DS Max

experience with Forest Pack Pro

Would this tool be useful in production? “Of course it would be, unless something like this

already exists and works better.”

Would this tool save time overall? “Definitely.”

Is the tool easy for you to understand and use? “Yeah, once I figured out what everything did it

was easy.”

Was not 100% clear what a “rule” was in ProceduRule, was fine with that terminology

being used but wanted it made clear in the tool somehow.

Wanted tooltips for various elements of the graphic user interface.

Is the graphic user interface well organized? “Yes, but I have a couple additional suggestions.”

Found the “Add To List” button a bit confusing since the Rule List also has “+” buttons

which accomplish the same thing.

Wishes that the “New” button for assigning a new terrain or spline object said “Grab

Selected” instead.

Believes that the “Collision Check” options should include a checkbox to enable/disable

instead of a “Disabled” option.

Do you think assets should continue to be placed based on their pivot point in ProceduRule?

“I’m very glad it uses the pivot point. That would definitely be my expectation.”

Houser 61

Works Cited

"5 Reasons Why 3D Animators Should Know Autodesk Maya." Animation Mentor. Next

Education LLC., 2014. Web. 15 Sept. 2016.

Berry, Noah. "A Brief History of Cyrodiil." The Elder Scrolls Codex. Bethesda Softworks, 2007.

Web. 28 Feb. 2016.

Bojc, Ashley. "Maya vs 3DS Max vs Cinema 4D." Triplet 3D. N.p., 04 Dec. 2014. Web. 15 Sept.

2016.

Boudon, Grant. "Which 3D Software Application Should I Learn?" DigitalTutors Blog. PluralSight

Media, 26 Nov. 2013. Web. 07 Mar. 2016.

"Denizen: How Disney Populated San Fransokyo with Citizens ... and Animators." Stitch

Kingdom. N.p., 17 Oct. 2014. Web. 23 Feb. 2016.

Desowitz, Bill. "VFX from 'Inception'" VFXWorld. Animation World Network, 21 July 2010. Web.

28 Feb. 2016.

Driskill, Hank, et al. "Building San Fransokyo: Creating the World of Disney’s Big Hero 6."

SIGGRAPH 2015. Los Angeles Convention Center, Los Angeles, CA. 10 August 2015.

Conference Presentation.

Dunlop, Renee. "Avatar." The CGSociety. N.p., 14 Jan. 2010. Web. 28 Feb. 2016.

Estela, Matt. "Soup." Tokeru.com. CGWiki, June 2015. Web. 22 Sept. 2016.

Everett, Paul. "Great Plugins for Cinema 4D." CinemaPlugins. N.p., 2014. Web. 06 Mar. 2016.

Finch, Dave. "Creating Regions for Custom Worldspaces in Fallout 3." Truancyfactory. N.p., 4

Nov. 2011. Web. 28 Feb. 2016.

Houser 62

Fitzmaurice, George and Bill Buxton. "Compatibility and Interaction Style in Computer

Graphics." Computer Graphics, vol. 32, no. 4, 1998. 64–69. 18 Sept. 2016.

"Forest Pack - Plugins for 3DS Max." Itoo Software. N.p., n.d. Web. 09 Mar. 2016.

Geller, Brooke. “Virtual Reality Is Coming To ‘The Lion King’ Live Action Remake!” Movie Pilot. 2

Dec. 2016. Web. 22 Jan. 2017.

"Graphics on the Move." MAXON. N.p., n.d. Web. 06 Mar. 2016.

Hall, Gina. "How John Lasseter’s Pixar Culture Led to ‘Big Hero 6’ Breakthrough for Disney."

TheWrap. TheWrap, 07 Nov. 2014. Web. 22 Jan. 2017.

Herman, Joe. “Why Joe Herman likes MAXON’s CINEMA 4D R18.” NYC Production & Post News.

NYC Production & Post News, 15 Aug. 2016. Web. 24 Jan. 2017.

“Houdini Indie and Houdini Engine Indie Now Available on the Unity® Asset Store.” CGSociety.

The CGSociety, 03 Oct. 2014. Web. 24 Jan. 2017.

Khatchadourian, Raffi. "World Without End." The New Yorker. Condé Nast, 18 Mar. 2015. Web.

28 Feb. 2016.

“Making of The Good Dinosaur.” CG Record. CG Daily News, Dec. 2015. Web. 22 Jan. 2017.

“Marvel’s big hero 6 (by Walt Disney animation studios).” Channel Awesome Community

Forums. Channel Awesome, 3 Sept. 2014. Web. 22 Jan. 2017.

Masters, Mark. "Which 3D Software Should I Choose for Asset Creation?" DigitalTutors Blog.

Pluralsight Media, 27 Jan. 2015. Web. 09 Mar. 2016.

"Maxon Makes Mograph Moves." Computer Graphics World 29.5 (2006): 37-38. OmniFile Full

Text Mega (H.W. Wilson). Web. 12 Mar. 2016

“Maya Tutorials.” CG Area. 2017. Web. 24 Jan. 2017.

Houser 63

McFarland, Kevin M. "Design FX: How Pixar Built The Good Dinosaur’s Hyper-Realistic World."

Wired.com. Conde Nast Digital, 4 Dec. 2015. Web. 23 Feb. 2016.

"Orbolt Smart 3D Assets Store." Orbolt. Side Effects Software, n.d. Web. 06 Mar. 2016.

Parfitt, Dave. "Disney Pixar's "The Good Dinosaur" Evokes Wyoming's Grand Teton National

Park." The Huffington Post. TheHuffingtonPost.com, Inc., 16 Nov. 2015. Web. 22 Jan.

2017.

Perry, Todd Sheridan. "Autodesk Maya 2014." Animation 27.10 (2013): 72-74. OmniFile Full

Text Mega (H.W. Wilson). Web. 12 Mar. 2016.

Phipps, Brett. “No Man’s Sky Review.” Trusted Reviews. Time, Inc., 1 Dec. 2016. Web. 24 Jan.

2017.

"ProTrack." IndiePro. Ozone Interactive, n.d. Web. 06 Mar. 2016.

"PyMEL for Maya." Autodesk Knowledge Network. Autodesk, 2009. Web. 19 Jan. 2017.

"RailClone - Plugins for 3DS Max." Itoo Software. N.p., n.d. Web. 09 Mar. 2016.

Rounsaville, Hailey. “Saddle up: Oblivion is now backwards compatible.” Kill Screen. Kill Screen

Media, Inc., 2 Dec. 2016. Web. 24 Jan. 2017.

Seymour, Michael. "Making the World of Pixar’s The Good Dinosaur." Fxguide. N.p., 4 Dec.

2015. Web. 23 Feb. 2016.

Shneiderman, Ben, and Catherine Plaisant. "Guidelines, Principles, and Theories." Designing the

User Interface: Strategies for Effective Human-Computer Interaction. 4th ed. Reading,

MA: Addison-Wesley, 1992. 60-81. Print.

“SideFX Releases Houdini 15.5.” SideFX, Side Effects Software, 19 May 2016. Web. 24 Jan. 2017.

Houser 64

Szczepanczyk, Radek 'ElDonaldo'. "Performance Comparison: MEL vs PyMel vs OpenMaya vs

Maya.cmds vs C++." Cautiously Optimistic. Blogspot, 17 Aug. 2012. Web. 19 Jan. 2017.

"The Elder Scrolls IV: Oblivion Interview." RPGamer. CraveOnline Media, n.d. Web. 28 Feb.

2016.

United States of America. National Aeronautics and Space Administration (NASA). NASA Space

Flight Human-System Standard, vol. 2, rev. A, 10 Jan. 2011. 132-64. Web. 19 Jan. 2017.

"Vary geometry size and shape using an expression." Autodesk Knowledge Network. Autodesk

Inc., 10 Feb. 2016. Web. 12 Mar. 2016.

Wang, Karen and Lisa Wang. "Vintage Instagram: QuadTrees." Programming Abstractions.

Stanford University, n.d. Web. 25 Sept. 2016.

Wood, Aylish. "Behind the Scenes: A Study of Autodesk Maya. " Animation: An Interdisciplinary

Journal 9.3 (2014): 317-332. SAGE Publications. Web. 15 Sept. 2016.

"XFrog 5.5 for Maya." Xfrog Official Website. N.p., 2016. Web. 24 Sept. 2016.

"XGen Geometry Instancer." Autodesk Knowledge Network. Autodesk Inc., 10 Feb. 2016. Web.

12 Mar. 2016.

Xiung, Chong Jinn. "No Small Feat to Create a Big Hero." The Star Online. Star Media Group

Berhad, 30 Dec. 2014. Web. 23 Feb. 2016.