Procedural modelling in Houdini based on Function Representation

<strong>Procedural</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
<strong>based</strong> on Function Representation
Master’s Thesis
Andy Abgottspon
August 2011 – National Centre for Computer Animation, Bournemouth University

Abstract
In modern computer graphics, objects are mostly represented by boundary representation
models like polygonal meshes. Such models only store <strong>in</strong>formation about an object’s boundary
and are relatively easy to render and often highly scalable. While this is sufficient for
a variety of applications like many types of computer animation and games, other uses require
<strong>in</strong>formation about volume rather than just surface. Function representation (FRep)
allows def<strong>in</strong><strong>in</strong>g objects as a set of geometric primitives with certa<strong>in</strong> operations and relations.
S<strong>in</strong>ce objects are def<strong>in</strong>ed as mathematic functions as opposed to a list of po<strong>in</strong>ts, models are
resolution <strong>in</strong>dependent and can be polygonised at any desired level of detail.
Build<strong>in</strong>g upon the current library developed at the NCCA and its Maya plug<strong>in</strong>, FRep <strong>modell<strong>in</strong>g</strong>
functionality has been <strong>in</strong>tegrated <strong>in</strong>to Houd<strong>in</strong>i and its node-<strong>based</strong> environment. The
library is developed <strong>in</strong> C++ us<strong>in</strong>g the Houd<strong>in</strong>i Development Kit (HDK) and comes as a set
of custom nodes.
i

Contents
Abstract
Table of Contents
List of Figures
Acknowledgements
i
ii
v
vi
1 Introduction 1
2 Previous work 2
2.1 Overview of representations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.2 The Function Representation (FRep) . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.1 Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2.2 Polygonisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 Technical background 5
3.1 FRep API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.1 Architectural overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1.2 Entities and nodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1.3 The FRep tree . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.4 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 Houd<strong>in</strong>i Development Kit (HDK) . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.1 Extend<strong>in</strong>g Houd<strong>in</strong>i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2.2 Operators and attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3 The SOP Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.4 Geometry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4 Design and implementation 14
4.1 System overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.2 Development environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Installation and setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.2 Makefiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.3 IDE Integration and debugg<strong>in</strong>g . . . . . . . . . . . . . . . . . . . . . . . 16
ii

4.3 Us<strong>in</strong>g the FRep API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.1 GCC compatibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.3.2 Custom <strong>in</strong>termediate layer . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i . . . . . . . . . . . . . . . . . 19
4.4.1 The <strong>modell<strong>in</strong>g</strong> workflow . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.4.2 Tree traversal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.4.3 Polygonisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.4.4 FRep Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
5 Results and analysis 29
5.1 Modell<strong>in</strong>g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Animation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Morph<strong>in</strong>g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.4 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
6 Conclusion 33
6.1 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.2 Future work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
References 35
iii

List of Figures
2.1 Example of a boundary representation: triangle mesh model . . . . . . . . . . 2
2.2 Set-theoretic operations <strong>based</strong> on R-functions: (a) Union and (b) Intersection
(Kravtsov 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Shape and position of 3D blend is controlled by the bound<strong>in</strong>g ellipsoid. (Pasko
et al. 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.4 The leftmost and rightmost images demonstrate the <strong>in</strong>itial and f<strong>in</strong>al triangle
surfaces, before and after optimisation. The two middle images show <strong>in</strong>termediate
stages. (Ohtake et al. 2002) . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 Full structure of the <strong>modell<strong>in</strong>g</strong> environment and basic tools for FRep <strong>modell<strong>in</strong>g</strong>
(Kravtsov 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 The FRep entity UML-diagram (Kravtsov 2011) . . . . . . . . . . . . . . . . . 7
3.3 FRep tree <strong>in</strong> Houd<strong>in</strong>i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.4 A Model-View-Controller diagram: The general design pattern (Kravtsov 2011) 9
3.5 Houd<strong>in</strong>i’s node <strong>based</strong> system . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.6 Basic class diagram for custom Houd<strong>in</strong>i nodes (adapted from SideFX (2011a)) 11
3.7 Provid<strong>in</strong>g guide geometry (blue lattice) <strong>in</strong> a custom node . . . . . . . . . . . . 12
3.8 Geometry Structure <strong>in</strong> Houd<strong>in</strong>i (SideFX 2011b) . . . . . . . . . . . . . . . . . 13
4.1 Class diagram of custom Houd<strong>in</strong>i nodes . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Us<strong>in</strong>g custom build steps <strong>in</strong> QtCreator to compile and bundle the Houd<strong>in</strong>i
library from with<strong>in</strong> the IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
4.3 Debugg<strong>in</strong>g us<strong>in</strong>g QtCreator . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4.4 The <strong>in</strong>teraction with the FRep API (Kravtsov 2011) . . . . . . . . . . . . . . 19
4.5 Us<strong>in</strong>g built-<strong>in</strong> primitive types as guide geometry . . . . . . . . . . . . . . . . . 20
4.6 Transform node for scale, translation and rotation . . . . . . . . . . . . . . . . 20
4.7 Polygonisation us<strong>in</strong>g analytic normals and a subdivision level of 3 . . . . . . . 23
4.8 Example of a CSG node used to perform a subtract operation . . . . . . . . . 24
4.9 Example of the blend node <strong>in</strong> use with different blend values: 1 10 1, 1 50 50,
1 1 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.10 Bounded blend<strong>in</strong>g us<strong>in</strong>g three spheres . . . . . . . . . . . . . . . . . . . . . . . 25
4.11 Example of the taper node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.12 Examples of bend, twist and deform po<strong>in</strong>t operations . . . . . . . . . . . . . . 26
iv

4.13 Sphere sweep node us<strong>in</strong>g a standard Houd<strong>in</strong>i curve as <strong>in</strong>put . . . . . . . . . . 26
4.14 Offset node us<strong>in</strong>g different offset values: -0.5 (left), 0 (middle), 0.5 (right) . . . 27
4.15 Metamorphosis from a cone to a torus . . . . . . . . . . . . . . . . . . . . . . . 27
4.16 Instancer node output <strong>based</strong> on torus . . . . . . . . . . . . . . . . . . . . . . . 28
4.17 More complex example of the <strong>in</strong>stancer node. . . . . . . . . . . . . . . . . . . 28
5.1 Screw model with its correspond<strong>in</strong>g node network and optimisation for sharp
features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2 Pengu<strong>in</strong> FRep model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3 Truck show<strong>in</strong>g keyframe animation . . . . . . . . . . . . . . . . . . . . . . . . 30
5.4 Animation graph of the truck animation . . . . . . . . . . . . . . . . . . . . . 31
5.5 Metamorphosis of simple 3D character to a screw . . . . . . . . . . . . . . . . 31
6.1 A set of application and platform specific translators (Kravtsov 2011) . . . . . 34
v

Acknowledgements
I would like to express my gratitude towards the course leader Jon Macey for his support
and <strong>in</strong>puts throughout the academic year and this project.
I thank Denis Kravtsov for provid<strong>in</strong>g me with the idea and base for this project, as well as
for his patient and k<strong>in</strong>d support.
Also, thanks to Turlif Vilbrandt from Uformia AS and Prof.
valuable feedback and <strong>in</strong>terest <strong>in</strong> the project.
Alexander Pasko for their
vi

Chapter 1
Introduction
In the visual effects and games <strong>in</strong>dustry, the predom<strong>in</strong>ant <strong>modell<strong>in</strong>g</strong> techniques are us<strong>in</strong>g
polygonal meshes. While these offer various benefits and are well <strong>in</strong>tegrated <strong>in</strong>to current
pipel<strong>in</strong>es, they only represent surfaces and have a given amount of detail. As a consequence,
<strong>in</strong>formation about an object <strong>in</strong>ternal structure cannot be stored and <strong>modell<strong>in</strong>g</strong> of heterogeneous
real-world objects is difficult. In other fields like CAD and 3D pr<strong>in</strong>t<strong>in</strong>g, the tradeoffs
cannot be circumvented without effort and alternative representations are needed.
One alternative is to use “Function representation <strong>in</strong> geometric <strong>modell<strong>in</strong>g</strong>” as suggested by
Pasko et al. (1995). The so-called FRep allows the def<strong>in</strong>ition of objects, operations and
relations as a mathematical function as opposed to po<strong>in</strong>t data and meshes. A lot of research
<strong>in</strong> this field has been done at the NCCA. The FRep API (Kravtsov 2011) was taken as base
for this project.
This thesis documents the design and implementation of a custom plug<strong>in</strong> for Houd<strong>in</strong>i that
was written <strong>in</strong> C++ us<strong>in</strong>g the Houd<strong>in</strong>i Development Kit (HDK). Houd<strong>in</strong>i is a high-end 3D
animation package developed by Side Effects Software and used heavily <strong>in</strong> the VFX <strong>in</strong>dustry.
Due to its node-<strong>based</strong> architecture, it is very suitable for procedural <strong>modell<strong>in</strong>g</strong>. Moreover,
many of the concepts <strong>in</strong> the FRep API, like for example the tree and node structure, translate
and <strong>in</strong>tegrate very well <strong>in</strong>to the software.
Chapter 2 gives an overview of the topic and related research. In Chapter 3, the relevant
concepts of the APIs used, namely the exist<strong>in</strong>g FRep API and the Houd<strong>in</strong>i Development Kit,
are <strong>in</strong>troduced. Chapter 4 documents the conceptual design of the plug<strong>in</strong> and further details
particular to the development environment and workflow. Furthermore, the <strong>modell<strong>in</strong>g</strong> process
and key algorithms are expla<strong>in</strong>ed. Chapter 5 presents results and gives an idea over potential
applications. The results are evaluated <strong>in</strong> Chapter 6 where future work and improvements
are discussed.
1

Chapter 2
Previous work
There are different ways of represent<strong>in</strong>g objects digitally. This chapter gives a brief overview
of various representations and discusses the fundamental research relevant for this project.
2.1 Overview of representations
The most dom<strong>in</strong>ant way of represent<strong>in</strong>g objects <strong>in</strong> modern computer graphics are boundary
representation models, also known as BRep. Such models do not store any <strong>in</strong>formation about
objects’ <strong>in</strong>ner properties. Figure 2.1 shows a triangle mesh, a popular type of a boundary
representation model. In film and games, most efforts are spent on creat<strong>in</strong>g visually pleas<strong>in</strong>g
results rather than accurate models of reality. Therefore, boundary representation are often
sufficient and even preferred because they offer a rich set of operations and are comparatively
easy to render.
Figure 2.1: Example of a boundary representation: triangle mesh model
2

2.2 The Function Representation (FRep)
For other purposes, volumetric representations allow us to store the object’s <strong>in</strong>ternal structure
rather than only a limited surface <strong>in</strong>formation. This is especially important when <strong>modell<strong>in</strong>g</strong>
real-life heterogeneous objects. There are a number of volumetric representations <strong>in</strong>clud<strong>in</strong>g
voxel representation, implicit surfaces and FReps.
2.2 The Function Representation (FRep)
The Function Representation (FRep) comb<strong>in</strong>es different models such as algebraic surfaces,
skeleton <strong>based</strong> “implicit” surfaces, CSG (Constructive Solid Geometry), sweeps, volumetric
objects, parametric models and procedural models. The representation def<strong>in</strong>es a geometric
object by a s<strong>in</strong>gle real cont<strong>in</strong>uous function of po<strong>in</strong>t coord<strong>in</strong>ates as F (X) ≥ 0 (Pasko 2011).
This also lets us represent models <strong>in</strong>dependent from resolution.
A constructive tree def<strong>in</strong>es functions and provides a visual overview of operations and parameters.
Leaf nodes are primitives like a box, sphere, torus, etc. Non-leaf nodes conta<strong>in</strong>
operations and relations. This functionality was implemented and made accessible via an
FRep API.
2.2.1 Operations
Besides Constructive Solid Geometry (CSG) <strong>based</strong> on R-function (see Figure 2.2), there is
also a number of blend<strong>in</strong>g operators offered by the FRep API.
Figure 2.2: Set-theoretic operations <strong>based</strong> on R-functions: (a) Union and (b) Intersection
(Kravtsov 2011)
3

2.2 The Function Representation (FRep)
In addition to regular blend<strong>in</strong>g, bounded blend<strong>in</strong>g allows for the generation of smooth transitions
between two or more surfaces. It also gives local control over how and where the
transitions happen us<strong>in</strong>g a bound<strong>in</strong>g solid (see Figure 2.3).
Figure 2.3: Shape and position of 3D blend is controlled by the bound<strong>in</strong>g ellipsoid. (Pasko
et al. 2005)
2.2.2 Polygonisation
The FRep API comes with its own polygoniser. The basic algorithm is <strong>based</strong> on march<strong>in</strong>g
cubes which can lack accuracy when polygonis<strong>in</strong>g implicit surfaces with sharp features.
However, the API also implements another approach called “Dynamic Mesh Optimization
for Polygonized Implicit Surfaces with Sharp Features” as <strong>in</strong>troduced by Ohtake et al. (2002)
(see Figure 2.4).
Figure 2.4: The leftmost and rightmost images demonstrate the <strong>in</strong>itial and f<strong>in</strong>al triangle
surfaces, before and after optimisation. The two middle images show <strong>in</strong>termediate stages.
(Ohtake et al. 2002)
4

Chapter 3
Technical background
Work<strong>in</strong>g with 3rd party code and frameworks can be challeng<strong>in</strong>g. Along with the technical
details, a fair understand<strong>in</strong>g of the overall environment is required to make the right design
decisions later. This chapter gives an overview of the FRep API and the key HDK concepts
relevant to this project.
3.1 FRep API
This project is us<strong>in</strong>g the FRep API developed by (Kravtsov 2011). He describes the communication
between API and applications as follows:
“The ma<strong>in</strong> and most common way of communication between the FRep API
and higher-level applications us<strong>in</strong>g FReps is through the parameters of the FRep
entities and through the creation of complex FRep trees conta<strong>in</strong><strong>in</strong>g the aforementioned
entities.” (Kravtsov 2011)
3.1.1 Architectural overview
The FRep API itself makes use of a number of libraries and underly<strong>in</strong>g APIs. Figure 3.1
shows the API <strong>in</strong> the context and <strong>in</strong> relation to the <strong>in</strong>termediate layer. The plug<strong>in</strong> developed
acts as <strong>in</strong>termediate layer between the external application (Houd<strong>in</strong>i) and the API.
5

3.1 FRep API
Figure 3.1: Full structure of the <strong>modell<strong>in</strong>g</strong> environment and basic tools for FRep <strong>modell<strong>in</strong>g</strong>
(Kravtsov 2011)
3.1.2 Entities and nodes
FReps are represented us<strong>in</strong>g FRep entities <strong>in</strong>side the API. Some classes are templated (these
are named with the suffix _T) and can therefore operate on data of multiple types. Figure 3.2
gives an overview of the classes def<strong>in</strong><strong>in</strong>g the FRep entities and nodes which are then used to
build FRep trees.
Some nodes and their children are extensively used <strong>in</strong> the plug<strong>in</strong>:
• ENTITY_T is represent<strong>in</strong>g an FRep entity with its parameters (see PARAMS_TYPE and
PARAMETER_TYPE), bounds, etc. It is also the base class for primitives like BOX_ENTITY_T
and SPHERE_ENTITY_T.
6

3.1 FRep API
• ID_TYPE is an attribute of the entity class and used to identify an entity’s type such as
FREP_SPHERE_ID or FREP_BOX_ID.
• ENTITY_NODE_T can be created from an ENTITY_T and conta<strong>in</strong> additional <strong>in</strong>formation
like parent and child nodes. This is used for FRep tree and traversal.
• ENTITY_FACTORY_T is a factory class generat<strong>in</strong>g entities.
Figure 3.2: The FRep entity UML-diagram (Kravtsov 2011)
3.1.3 The FRep tree
The next step is to create the nodes and entities shown <strong>in</strong> Section 3.1.2 and establish relationships
between them. Nodes can represent both primitives and operations and comb<strong>in</strong><strong>in</strong>g
them to form an FRep tree can help us build<strong>in</strong>g complex models.
Figure 3.3 shows an example of such a tree as represented with<strong>in</strong> Houd<strong>in</strong>i. To expla<strong>in</strong> the
details of the tree evaluation with<strong>in</strong> the API would go beyond the scope of this project. It
is however important to understand that FRep nodes relate to one another and that child
nodes can be added to any node. The <strong>in</strong>termediate layer has its own tree traversal algorithm
to gather the required data as expla<strong>in</strong>ed <strong>in</strong> Section 4.4.2.
7

3.1 FRep API
Figure 3.3: FRep tree <strong>in</strong> Houd<strong>in</strong>i
3.1.4 Usage
There are a number of ways to <strong>in</strong>teract with FRep models. Models can be created and
manipulated directly us<strong>in</strong>g a variety of programm<strong>in</strong>g languages. This could be a high-level
programm<strong>in</strong>g language like C++, a script<strong>in</strong>g language like Python or a simple but specialized
high-level programm<strong>in</strong>g language like “HyperFun” (Adzhiev et al. 1999) or “HyperJazz”
(Adzhiev et al. 1996). Each of these methods have different effects on performance and code
ma<strong>in</strong>ta<strong>in</strong>ability.
Another way is to allow the user to manipulate FRep models via a graphical user <strong>in</strong>terface.
The “Model-View-Controller” design pattern (Gamma et al. 1995) describes this sort of
<strong>in</strong>teraction as shown <strong>in</strong> Figure 3.4. In this scenario, the controller of our <strong>in</strong>termediate layer
would be responsible for pass<strong>in</strong>g on the <strong>in</strong>formation of the view to the FRep API and therefore
sync<strong>in</strong>g the user <strong>in</strong>terface with the <strong>in</strong>ternal models. Further details on the implementation
of the <strong>in</strong>termediate layer are discussed <strong>in</strong> Section 4.3.2.
8

3.2 Houd<strong>in</strong>i Development Kit (HDK)
Figure 3.4: A Model-View-Controller diagram: The general design pattern (Kravtsov 2011)
3.2 Houd<strong>in</strong>i Development Kit (HDK)
3.2.1 Extend<strong>in</strong>g Houd<strong>in</strong>i
There are several ways to extend Houd<strong>in</strong>i’s capabilities. For one, the node-<strong>based</strong> architecture
allows bundl<strong>in</strong>g any sort of nodes <strong>in</strong>to so-called Houd<strong>in</strong>i Digital Assets (HDA) that can be
equipped with attributes and controls. They are also capable of us<strong>in</strong>g <strong>in</strong>puts and outputt<strong>in</strong>g
data.
VEX is an <strong>in</strong>terpreted language with<strong>in</strong> Houd<strong>in</strong>i. It is fairly easy to use and offers a set of
functions to allow modification of po<strong>in</strong>t attributes. While this makes it very scalable and
optimised for multi-thread<strong>in</strong>g, VEX is unable to create or destroy geometry.
In order to create custom expressions, commands or operators like SOPs, COPs, DOPs, etc.,
the Houd<strong>in</strong>i Development Kit is required. The HDK is a set of C++ libraries used by the
creators of Houd<strong>in</strong>i themselves to create nodes and <strong>in</strong>terfaces. It is the SDK Houd<strong>in</strong>i itself is
built with.
Alternatively, the Houd<strong>in</strong>i Object Model (HOM) can be used to create SOPs us<strong>in</strong>g the Python
script<strong>in</strong>g language. Compared to the HDK, it offers <strong>in</strong>creased flexibility, but can also be slower
due to the overhead <strong>in</strong>troduced by Python.
For this project, both the HDK and HOM have been evaluated. The Python API provides
a module named <strong>in</strong>l<strong>in</strong>ecpp (SideFX 2011c) enabl<strong>in</strong>g the programmer to write functions <strong>in</strong>
C++. However, due to the many <strong>in</strong>teractions between the Houd<strong>in</strong>i component and the FRep
API, this method seemed to be too limited. Another reason to choose the HDK was better
extendability for future work and possibly more complex optimisations.
9

3.2 Houd<strong>in</strong>i Development Kit (HDK)
3.2.2 Operators and attributes
Houd<strong>in</strong>i is organised <strong>in</strong>to a hierarchy of nodes. There are several levels, start<strong>in</strong>g at the
“directory” levels, <strong>in</strong>ternally called Networks, like obj, shop, ch, out and others. Operations
and objects related to geometry are found <strong>in</strong> Surface operators (SOPs) with<strong>in</strong> the Object
Manager (path /obj). Figure 3.5 shows a set of <strong>in</strong>terconnected nodes with<strong>in</strong> a geometry
object (/obj/geo3).
Figure 3.5: Houd<strong>in</strong>i’s node <strong>based</strong> system
Internally, all nodes are subclasses of OP_Node. As stated <strong>in</strong> the HDK documentation (SideFX
2011a), custom nodes do not <strong>in</strong>herit from this base node directly. Instead, node types are
grouped <strong>in</strong>to different network types like SOP_Node for surface operators as shown <strong>in</strong> Figure
3.6. Custom nodes like FRep_Node create an operator def<strong>in</strong><strong>in</strong>g properties like node name,
attributes and the allowed number of <strong>in</strong>puts.
Furthermore, custom nodes def<strong>in</strong>e a list of PRM_Template items for every attribute. This
def<strong>in</strong>ition conta<strong>in</strong>s the type, attribute name, UI name, default value(s) and range. Examples
of often used attributes are dropdown lists, toggles, labels or numeric <strong>in</strong>put fields like float
and <strong>in</strong>t.
10

3.2 Houd<strong>in</strong>i Development Kit (HDK)
Figure 3.6: Basic class diagram for custom Houd<strong>in</strong>i nodes (adapted from SideFX (2011a))
3.2.3 The SOP Node
SOP nodes are dist<strong>in</strong>guished between generators and filters. Generators do not require any
<strong>in</strong>put, <strong>in</strong>stead they generate geometry purely <strong>based</strong> on their parameters. Filters on the
other hand alter geometry and apply a set of operations to it. In the case of this project,
nodes always except at least one <strong>in</strong>put. Even the FRep node itself that outputs the mesh
after polygonisation is retriev<strong>in</strong>g his attributes from connected nodes dur<strong>in</strong>g traversal (see
Section 4.4.2).
As shown <strong>in</strong> the previous section, the first step <strong>in</strong> creat<strong>in</strong>g a custom SOP is to sub-class
SOP_Node, register the operator and start def<strong>in</strong><strong>in</strong>g attributes. The method which conta<strong>in</strong>s
the actual code to manipulate the geometry is called cookMySop and is called automatically
as soon as the node is evaluated or refreshed.
Another useful concept which helps users understand what the SOP is work<strong>in</strong>g with, is the
option of add<strong>in</strong>g guide geometry. This geometry is not part of the operator and is only
displayed as guid<strong>in</strong>g <strong>in</strong>formation, as used to display the bound<strong>in</strong>g box of the polygonisation
(see Figure 3.7).
11

3.2 Houd<strong>in</strong>i Development Kit (HDK)
Figure 3.7: Provid<strong>in</strong>g guide geometry (blue lattice) <strong>in</strong> a custom node
3.2.4 Geometry
The ma<strong>in</strong> geometry libraries <strong>in</strong> Houd<strong>in</strong>i are GB, GD, GEO and GU. It is beyond the scope of
this thesis to expla<strong>in</strong> all of these <strong>in</strong> detail, but here a brief overview: GB is the geometry base
class on which GD (for 2D geometry) and GEO (for 3D geometry) are <strong>based</strong> on. GU is a library
sub-classed off the GEO library conta<strong>in</strong><strong>in</strong>g higher level tools and classes like GU_Detail.
For 3D geometry, the detail class is used as a conta<strong>in</strong>er for po<strong>in</strong>ts, primitives and attributes.
A GEO_Po<strong>in</strong>t represents a po<strong>in</strong>t <strong>in</strong> space; multiple po<strong>in</strong>ts can form a primitive, <strong>in</strong> which case
a GEO_Vertex object is created to store the reference to the po<strong>in</strong>t (see Figure 3.8). For this
project, meshes are all triangulated, so each primitive consists of 3 vertices.
12

3.2 Houd<strong>in</strong>i Development Kit (HDK)
Figure 3.8: Geometry Structure <strong>in</strong> Houd<strong>in</strong>i (SideFX 2011b)
13

Chapter 4
Design and implementation
To design a system well requires knowledge of all components and appropriate use of the
tools at disposal. After all, design is not just what someth<strong>in</strong>g looks like, it is how it works.
Many design decisions made throughout the project were <strong>based</strong> on best practises and examples
from Houd<strong>in</strong>i and its HDK. The ma<strong>in</strong> goal was to <strong>in</strong>tegrate FRep <strong>modell<strong>in</strong>g</strong> capabilities
<strong>in</strong>to a environment familiar to exist<strong>in</strong>g Houd<strong>in</strong>i users rather than <strong>in</strong>vent<strong>in</strong>g complicated new
workflows.
4.1 System overview
General nam<strong>in</strong>g conventions and cod<strong>in</strong>g standards have been respected and kept consistent
with the Maya plug<strong>in</strong> and FRep library itself, wherever possible and not conflict<strong>in</strong>g with
HDK’s cod<strong>in</strong>g guidel<strong>in</strong>es.
There are three ma<strong>in</strong> QtCreator projects:
• QtRep: The port of the FRep API from W<strong>in</strong>dows to Mac OS X (see Section 4.3.1 on
GCC compatibility). The output is a dynamic library libQtRep.dylib on Mac OS.
On W<strong>in</strong>dows, this would correspond to a .dll, on L<strong>in</strong>ux to a .so file.
• frep-houd<strong>in</strong>i: The <strong>in</strong>termediate layer (see Section 3.1.1), mak<strong>in</strong>g use of libQtRep.
dylib and conta<strong>in</strong><strong>in</strong>g all custom FRep nodes for Houd<strong>in</strong>i.
• houd<strong>in</strong>i-test: A standalone test project that uses libQtRep.dylib and allows to make
calls to the FRep API. This is useful for test<strong>in</strong>g and debugg<strong>in</strong>g the <strong>in</strong>teraction with the
FRep library.
14

4.1 System overview
The core of the <strong>in</strong>termediate layer consists of a set of custom Houd<strong>in</strong>i nodes (see Figure 4.1).
They all <strong>in</strong>herit from FRep_Node which forms the base for primitives and operations. At the
same time FRep_Node is responsible for travers<strong>in</strong>g the nodes (see Section 4.4.2), build<strong>in</strong>g the
FRep tree and outputt<strong>in</strong>g the mesh (see Section 4.4.3).
SOP_Node
FRep_Node
- m_templateList[] : PRM_Template
- m_variables[] : CH_LocalVariable
- m_attrNames[] : PRM_Name
+ myConstructor(i_net : OP_Network, i_name : const char, i_op : OP_Operator) : OP_ERROR
+ getId() : unsigned <strong>in</strong>t
+ fillParameters(i_entity : ENTITY_BASE_T*, i_now : double, i_srcNode = NULL : OP_Node) : BOOL
+ fillParametersTransform(i_entity : ENTITY_BASE_T, i_now : double, i_thisNode : OP_Node) : BOOL
+ cookMySop(i_context : OP_Context&) : OP_ERROR
+ cookMyGuide1(i_context : OP_Context&) : OP_ERROR
- gather(i_now : double) : OP_ERROR
- generateMesh(i_node : ENTITY_NODE_T*, i_now : double) : OP_ERROR
- retrieveChildren(i_node : OP_Node, i_now : double) : ENTITY_NODE_T*
Box_Node CSG_Node Bend_Node Metamorph_Node
Sphere_Node
Blend_Node
Twist_Node
Instancer_Node
Torus_Node
Bounded_Blend_Node
Taper_Node
Sphere_Sweep_Node
Cone_Node
Deform_Po<strong>in</strong>t_Node
Cyl<strong>in</strong>der_Node
Figure 4.1: Class diagram of custom Houd<strong>in</strong>i nodes
15

4.2 Development environment
4.2 Development environment
4.2.1 Installation and setup
The Houd<strong>in</strong>i Development Kit (HDK) is part of Houd<strong>in</strong>i and <strong>in</strong>stalled under $HFS/toolkit.
All required header files, makefiles and samples are available <strong>in</strong> Houd<strong>in</strong>i Master as well as
the free Apprentice version. This project was developed us<strong>in</strong>g QtCreator <strong>in</strong> order to allow
deployment to other platforms. The operat<strong>in</strong>g system used dur<strong>in</strong>g development was Mac OS
X 10.7.
After the <strong>in</strong>stallation, the $HFS environment variable po<strong>in</strong>ts to the <strong>in</strong>stallation directory,
which is typically /Library/Frameworks/Houd<strong>in</strong>i.framework/Resources on a Mac.
4.2.2 Makefiles
There are several ways of compil<strong>in</strong>g HDK code. Us<strong>in</strong>g the hcustom command-l<strong>in</strong>e tool is very
convenient and useful for test<strong>in</strong>g, but also limited to a s<strong>in</strong>gle C++ source file and therefore
not appropriate for the library. The alternative is us<strong>in</strong>g Makefiles which are shipped with
the HDK and provide sample Makefiles for L<strong>in</strong>ux and W<strong>in</strong>dows.
For the Mac, Schmidt (2011) provides a makefile which was used as a base. Additionally,
runn<strong>in</strong>g hcustom -e My_Node.cpp outputs the compiler and l<strong>in</strong>ker commands executed by
hcustom and offers an <strong>in</strong>sight <strong>in</strong>to the way plug<strong>in</strong>s are compiled and bundled. This is particularly
helpful when compil<strong>in</strong>g from console or for debugg<strong>in</strong>g compiler and l<strong>in</strong>ker flags.
4.2.3 IDE Integration and debugg<strong>in</strong>g
It is worth mention<strong>in</strong>g a number of best practices that have been discovered throughout the
development, especially s<strong>in</strong>ce effective workflows on different platforms us<strong>in</strong>g various IDEs
are scarcely documented.
Unfortunately, Houd<strong>in</strong>i’s plug<strong>in</strong> architecture does not (officially) support load<strong>in</strong>g and reload<strong>in</strong>g
of plug<strong>in</strong>s. Instead, they are loaded upon startup which requires Houd<strong>in</strong>i to be closed and
reopened every time a change to a library is made. Dur<strong>in</strong>g the development of the project,
the follow<strong>in</strong>g workflow has proven to be most effective:
1. Apply changes to the code and build project from with<strong>in</strong> QtCreator. Us<strong>in</strong>g custom
build steps as shown <strong>in</strong> Figure 4.2, make <strong>in</strong>stall can be run from with<strong>in</strong> the IDE us<strong>in</strong>g
the standard shortcut. Note that one can also add a custom build step for make clean
to rebuild the project entirely.
16

4.2 Development environment
2. Start Houd<strong>in</strong>i from Term<strong>in</strong>al. This could also be done automatically via a custom build
step. However, the term<strong>in</strong>al w<strong>in</strong>dow is at the same time used for logs and therefore
useful to display.
3. Optional: The debugger can then be attached to the runn<strong>in</strong>g application with<strong>in</strong> QtCreator
via the menu Debug => Start Debugg<strong>in</strong>g => Attach to Runn<strong>in</strong>g External Application...
(see Figure 4.3).
Figure 4.2: Us<strong>in</strong>g custom build steps <strong>in</strong> QtCreator to compile and bundle the Houd<strong>in</strong>i
library from with<strong>in</strong> the IDE
17

4.3 Us<strong>in</strong>g the FRep API
Figure 4.3: Debugg<strong>in</strong>g us<strong>in</strong>g QtCreator
4.3 Us<strong>in</strong>g the FRep API
4.3.1 GCC compatibility
Various adjustments to the exist<strong>in</strong>g FRep library (see Section 3.1) were required for it to be
used <strong>in</strong> the HDK plug<strong>in</strong>. A dynamic library was built and the code, orig<strong>in</strong>ally developed on
W<strong>in</strong>dows us<strong>in</strong>g Visual Studio’s compiler, was made GCC compatible.
This very time-consum<strong>in</strong>g task was at the same time necessary groundwork. Hav<strong>in</strong>g a
standard-compliant code base then allows for cross-platform development. The orig<strong>in</strong>al library
heavily relies on templates and some notations needed to be adjusted <strong>in</strong> order to work
with the usually more strict GCC. Although be<strong>in</strong>g platform-<strong>in</strong>dependent for the most part,
some platform-specific code <strong>in</strong> the FRep library had to be ported as well.
4.3.2 Custom <strong>in</strong>termediate layer
The set of Houd<strong>in</strong>i operators create a custom <strong>in</strong>termediate layer, allow<strong>in</strong>g communication
between FRep API and Houd<strong>in</strong>i (see Figure 4.4). These patterns were adapted from the exist<strong>in</strong>g
plug<strong>in</strong> for Autodesk Maya (Kravtsov 2011). Furthermore, exist<strong>in</strong>g nam<strong>in</strong>g conventions
were kept and pre-exist<strong>in</strong>g standards respected to ensure portability and ma<strong>in</strong>ta<strong>in</strong>ability.
18

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
Figure 4.4: The <strong>in</strong>teraction with the FRep API (Kravtsov 2011)
4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
4.4.1 The <strong>modell<strong>in</strong>g</strong> workflow
Modell<strong>in</strong>g us<strong>in</strong>g FRep nodes is very similar to the traditional approach of procedural <strong>modell<strong>in</strong>g</strong>
<strong>in</strong> Houd<strong>in</strong>i. FRep nodes can be classified as primitives and operations. In order to
keep the workflow as natural as possible without forc<strong>in</strong>g users to adapt to new nodes, FRep
Houd<strong>in</strong>i’s built <strong>in</strong> primitives Box, Sphere, Torus, Cone and Tube (called Cyl<strong>in</strong>der <strong>in</strong> the FRep
API) can be used.
Mak<strong>in</strong>g use of Houd<strong>in</strong>i’s native primitive nodes also enables us to reuse guide geometry and
handles. Figure 4.5 shows a basic example of an ord<strong>in</strong>ary box and sphere be<strong>in</strong>g fed <strong>in</strong>to
an FRep blend node. The FRep node at the end of the tree (frep_node6) is needed for
polygonisation and outputt<strong>in</strong>g the mesh.
In addition to the already mentioned primitive types, the <strong>in</strong>termediate layer (or to be more
precise, the traversal algorithm described <strong>in</strong> Section 4.4.2) is also aware of the Transform
SOP which can be employed for scal<strong>in</strong>g, translat<strong>in</strong>g and rotat<strong>in</strong>g (see Figure 4.6).
19

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
Figure 4.5: Us<strong>in</strong>g built-<strong>in</strong> primitive types as guide geometry
Figure 4.6: Transform node for scale, translation and rotation
4.4.2 Tree traversal
Gather<strong>in</strong>g the necessary <strong>in</strong>formation to build the FRep tree works differently <strong>in</strong> Maya and
Houd<strong>in</strong>i. In Maya, the architecture requires every node to be <strong>in</strong>dependent, so all the attributes
need to be passed and kept up to date. In Houd<strong>in</strong>i, this is slightly easier to <strong>in</strong>tegrate and
one node can be used to gather all its <strong>in</strong>put nodes recursively and build the tree from that.
This node at the end of the tree (<strong>in</strong> Houd<strong>in</strong>i typically at the bottom) is represented by the
20

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
FRep_Node class. The traversal of the nodes is controlled by one s<strong>in</strong>gle, recursive function
called retrieveChildren. Not only is this function responsible for travers<strong>in</strong>g all child nodes,
it also creates the correspond<strong>in</strong>g FRep entities and nodes as well as fills them with the
parameters provided by the user <strong>in</strong> Houd<strong>in</strong>i.
The function is run with the (only) child of the FRep_Node as <strong>in</strong>put and returns a full FRep
tree consist<strong>in</strong>g of FRep nodes and their children. The algorithm (see Algorithm 1) can be
structured <strong>in</strong> five phases:
1. Variables like factory and returnNode are <strong>in</strong>itialised. Also, further flags to <strong>in</strong>dicate
the type of the current node are def<strong>in</strong>ed.
2. A new frepNode <strong>in</strong>stance is created. This is achieved either by cast<strong>in</strong>g the current
node, if it is an actual FRep node, or by manually creat<strong>in</strong>g it <strong>in</strong> case the current node
is one of Houd<strong>in</strong>i’s built-<strong>in</strong> primitives (Sphere, Box, Torus, Cone, etc.). Additionally, a
new FRep entity of the correspond<strong>in</strong>g type is created. The node hold<strong>in</strong>g that entity is
also marked to be returned.
3. The FRep API offers a transform entity which can be appended to a node to perform
operations. In case we are us<strong>in</strong>g an FRep node that can be transformed or even
Houd<strong>in</strong>i’s own transform SOP, create the necessary FRep entity. Then, create the correspond<strong>in</strong>g
node and add it as child of the orig<strong>in</strong>al node. In this manner, an “<strong>in</strong>visible”
FRep transform is added right after the node it transforms.
4. In the last step, the algorithms determ<strong>in</strong>es what to return. If the current node is an
FRep object (either by be<strong>in</strong>g one of the FRep nodes or one of Houd<strong>in</strong>i’s primitives
represent<strong>in</strong>g one), fill the entity and run this whole procedure for every child of this
node. Alternatively, if this is just an ord<strong>in</strong>ary node that should be ignored by this
system, run retrieveChildren on its <strong>in</strong>put (child). If the node is irrelevant to the
FRep system and has no <strong>in</strong>puts, return NULL.
21

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
Function: retrieveChildren(thisNode)
// Phase 1: Initialisation
factory ← Create factory
returnNode ← Node to be returned (<strong>in</strong>itially NULL)
isFRepNode ← Is the node one of our own FRep nodes?
isHoud<strong>in</strong>iGeoNode ← Is Houd<strong>in</strong>i geometry node like Sphere, Box, Torus, etc.?
isTransformNode ← Is Houd<strong>in</strong>i transform node?
// Phase 2: Create FRep node and entities
if isFRepNode or isHoud<strong>in</strong>iGeoNode then
if isFRepNode then
frepNode ← cast thisNode as FRep_Node
else if isHoud<strong>in</strong>iGeoNode? then
frepNode ← create FRep node for Houd<strong>in</strong>i native primitive
end
newEntity ← create entity of frepNode.getTypeId() via factory
newFrepNode ← create node <strong>based</strong> on newEntity
returnNode ← newFrepNode
end
// Phase 3: Add transform node
if isFRepNode or isTransformNode then
transformEntity ← create entity with the transforms of thisNode
transformNode ← create node <strong>based</strong> on transformEntity
transformNode.addChild(newFrepNode)
returnNode ← transformNode
end
// Phase 4: Fill parameters and run on child nodes (if any)
if isFRepNode or isHoud<strong>in</strong>iGeoNode then
frepNode.fillParameters()
foreach child <strong>in</strong> <strong>in</strong>putNodes do
childNode ← retrieveChildren(child)
if Child is FRep node then newFrepNode.addChild(childNode)
end
return returnNode
else if thisNode has <strong>in</strong>put then
return retrieveChildren(<strong>in</strong>put)
else
return NULL
end
Algorithm 1: Recursive node traversal function
22

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
4.4.3 Polygonisation
As mentioned <strong>in</strong> Section 4.4.1 about the FRep <strong>modell<strong>in</strong>g</strong> workflow, an frep_node is added
to the end of the network. This node has two ma<strong>in</strong> tasks. The first is travers<strong>in</strong>g all nodes
<strong>in</strong> order to gather all parameters and build the FRep tree as described <strong>in</strong> Section 4.4.2. The
second task of the node is to pass the tree to the polygoniser of the FRep API and then
assign the generated mesh data to Houd<strong>in</strong>i’s geometry structures.
The polygoniser has a number of attributes that can be manipulated via the user <strong>in</strong>terface.
The bound<strong>in</strong>g box, grid resolution and surface generation method can be def<strong>in</strong>ed. An example
of the analytic method is shown <strong>in</strong> Figure 4.7.
Figure 4.7: Polygonisation us<strong>in</strong>g analytic normals and a subdivision level of 3
Assign<strong>in</strong>g the data received from the polygoniser is fairly straight-forward, keep<strong>in</strong>g the <strong>in</strong>ternal
structure of Houd<strong>in</strong>i’s geometry architecture (see Section 3.2.4) <strong>in</strong> m<strong>in</strong>d.
4.4.4 FRep Operations
Blend<strong>in</strong>g
There is a variety of operations possible. For conventional boolean <strong>modell<strong>in</strong>g</strong>, the CSG node
can be used for union, <strong>in</strong>tersection and subtraction operations (see Figure 4.8). The Blend
node is similar to the CSG node but provides more user control, offer<strong>in</strong>g three parameters to
control the blend<strong>in</strong>g and achieve various results as shown <strong>in</strong> Figure 4.9. This concept is taken
even further us<strong>in</strong>g bounded blend nodes, allow<strong>in</strong>g local control of blend<strong>in</strong>g (see Figure 4.10).
23

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
Figure 4.8: Example of a CSG node used to perform a subtract operation
Figure 4.9: Example of the blend node <strong>in</strong> use with different blend values: 1 10 1, 1 50 50,
1 1 10
24

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
Figure 4.10: Bounded blend<strong>in</strong>g us<strong>in</strong>g three spheres
Taper, Bend, twist and deform po<strong>in</strong>t
Other operators allow relatively complex operations with very little effort. All operations
shown <strong>in</strong> Figure 4.11 and Figure 4.12 are entirely <strong>based</strong> on a simple box primitive. Each of
the meshes is therefore produced us<strong>in</strong>g three nodes only: box node, FRep operation (taper,
bend, twist or deform po<strong>in</strong>t) and the FRep base node for polygonisation.
Figure 4.11: Example of the taper node
25

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
Figure 4.12: Examples of bend, twist and deform po<strong>in</strong>t operations
Sphere sweep
The Sphere sweep node (see Figure 4.13) allows “draw<strong>in</strong>g” three-dimensional l<strong>in</strong>es by provid<strong>in</strong>g
a standard Houd<strong>in</strong>i curve as <strong>in</strong>put and specify<strong>in</strong>g a radius <strong>in</strong>side the sweep node.
Figure 4.13: Sphere sweep node us<strong>in</strong>g a standard Houd<strong>in</strong>i curve as <strong>in</strong>put
Offset
Figure 4.14 shows the offset node which allows to extract a mesh <strong>in</strong>side (Offset value < 1) or
outside the orig<strong>in</strong>al surface (Offset value > 1).
26

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
Figure 4.14: Offset node us<strong>in</strong>g different offset values: -0.5 (left), 0 (middle), 0.5 (right)
Metamorphosis
Probably one of the best examples of the benefits of FRep is when morph<strong>in</strong>g two objects
with completely different topologies. Figure 4.15 shows an example of such an operation <strong>in</strong>
five steps from alpha = 0 to alpha = 1.
Figure 4.15: Metamorphosis from a cone to a torus
Instancer
The <strong>in</strong>stancer node can output <strong>based</strong> on any sort of <strong>in</strong>put geometry. In the example <strong>in</strong>
Figure 4.16, a torus is used to create a grid-like structure. Figure 4.17 shows a more complex
example us<strong>in</strong>g two torus objects for the <strong>in</strong>stancer. The result then gets <strong>in</strong>tersected with a
bigger torus.
27

4.4 <strong>Procedural</strong> function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> <strong>in</strong> Houd<strong>in</strong>i
Figure 4.16: Instancer node output <strong>based</strong> on torus
Figure 4.17: More complex example of the <strong>in</strong>stancer node.
28

Chapter 5
Results and analysis
Like traditional polygon <strong>modell<strong>in</strong>g</strong>, FRep <strong>modell<strong>in</strong>g</strong> offers the same vastness of possibilities.
Virtually anyth<strong>in</strong>g can be created, any attribute of an object can be controlled and changed
over time. This chapter tries to provide an idea of what is possible by show<strong>in</strong>g some examples,
but also outl<strong>in</strong><strong>in</strong>g some of the limitations of the current system.
5.1 Modell<strong>in</strong>g
To demonstrate some of the <strong>modell<strong>in</strong>g</strong> capabilities, a real-world object (see Figure 5.1) and a
simple character (see Figure 5.2) have been created. As shown <strong>in</strong> the example of the screw,
such an object can be created with very few nodes.
Figure 5.1: Screw model with its correspond<strong>in</strong>g node network and optimisation for sharp
features
29

5.2 Animation
Figure 5.2: Pengu<strong>in</strong> FRep model
5.2 Animation
Just like every other node attribute <strong>in</strong> Houd<strong>in</strong>i, FRep attributes can be animated us<strong>in</strong>g
keyframes. In Figure 5.3, a truck was modelled and its backdoor rotated over time around
a pivot po<strong>in</strong>t. The keyframe animation can be controlled further us<strong>in</strong>g the animation graph
(see Figure 5.4).
Figure 5.3: Truck show<strong>in</strong>g keyframe animation
30

5.3 Morph<strong>in</strong>g
Figure 5.4: Animation graph of the truck animation
5.3 Morph<strong>in</strong>g
The fact that objects are mathematical functions allows us to <strong>in</strong>terpolate between these
functions. For the user, all that is needed is to connect two objects us<strong>in</strong>g a metamorphosis
node. Figure 5.5 shows an example of metamorphosis of two objects with different topologies.
Figure 5.5: Metamorphosis of simple 3D character to a screw
31

5.4 Limitations
5.4 Limitations
All of the functionality the FRep API offers is still not <strong>in</strong>tegrated at this stage. However,
the project has been designed with extendability <strong>in</strong> m<strong>in</strong>d. There is a list of known issues and
limitations to the current system:
• The node type is currently determ<strong>in</strong>ed by compar<strong>in</strong>g node names (e.g. frep_bend).
Therefore, if the node is renamed, the tree traversal algorithm ceases to recognise it.
However, suffixes can still be added (i.e. frep_bend_arm will work). To solve this,
nodes would have to be identified by their class type which would be one of the first
issues to fix <strong>in</strong> a potential future version.
• The polygonisation can not be canceled us<strong>in</strong>g the escape key like it is good practice <strong>in</strong>
Houd<strong>in</strong>i. This has to do with the fact that Houd<strong>in</strong>i’s <strong>in</strong>terrupt has to be placed with<strong>in</strong>
the loop of a critical operation. S<strong>in</strong>ce the polygonisation is part of the FRep API, this
is not possible.
• When animat<strong>in</strong>g FRep attributes, like alpha <strong>in</strong> the metamorph node, the nodes are
not refreshed. The current work around is to set two keyframes to an attribute of any
other Houd<strong>in</strong>i native node <strong>in</strong> the network (even if it is not chang<strong>in</strong>g values). The reason
might lie <strong>in</strong> the evaluation of animatable attributes <strong>in</strong> custom nodes, but needs further
<strong>in</strong>vestigation.
• There can only be one FRep base node per network, so it is not possible to feed a f<strong>in</strong>al
FRep node back <strong>in</strong>to another one. This behaviour is correct, but an appropriate error
message should be displayed.
• Bypass<strong>in</strong>g a node currently has no effect on the system. The solution would be to
query this flag for every node dur<strong>in</strong>g tree traversal and simply ignore bypassed nodes
(cont<strong>in</strong>ue the execution of the recursive function).
Some open questions rema<strong>in</strong> <strong>in</strong> terms of deploy<strong>in</strong>g the project to other platforms. One of
the downsides of us<strong>in</strong>g the HDK rather than Python, is the requirement for the plug<strong>in</strong> to be
recompiled on every platform us<strong>in</strong>g the same compiler Houd<strong>in</strong>i was compiled with.
32

Chapter 6
Conclusion
Bas<strong>in</strong>g a project on an external library (which had to be ported first), while at the same time
tackl<strong>in</strong>g a complex SDK like the Houd<strong>in</strong>i Development Kit was certa<strong>in</strong>ly an ambitious goal. In
retrospect, the objective of br<strong>in</strong>g<strong>in</strong>g FRep <strong>modell<strong>in</strong>g</strong> capabilities to Houd<strong>in</strong>i while respect<strong>in</strong>g
exist<strong>in</strong>g guidel<strong>in</strong>es and UI paradigms, was achieved. Particularly the degree of <strong>in</strong>tegration
<strong>in</strong>to the Houd<strong>in</strong>i environment is very promis<strong>in</strong>g for future projects and applications.
The FRep API offers a vast set of features. Some nodes and features could not be <strong>in</strong>tegrated
given the short duration of this project. There is also a list of known issues and limitations
to the system, as discussed <strong>in</strong> Section 5.4. Choos<strong>in</strong>g the HDK over Python was the right
decision and, apart from hav<strong>in</strong>g performance benefits, offer<strong>in</strong>g a clean and solid foundation
for future development.
6.1 Applications
The technology can have applications <strong>in</strong> <strong>in</strong>dustries like film and games, especially as computers
get faster and more accurate representations of the real-world are desired. Furthermore,
be<strong>in</strong>g able to blend and morph objects regardless of topology is challeng<strong>in</strong>g us<strong>in</strong>g current
methods.
S<strong>in</strong>ce FReps are resolution-<strong>in</strong>dependent, they are ideal for use <strong>in</strong> digital manufactur<strong>in</strong>g and
3D pr<strong>in</strong>t<strong>in</strong>g. Additional nodes could be developed to allow export from Houd<strong>in</strong>i to various
file formats like STL.
33

6.2 Future work
6.2 Future work
In addition to address<strong>in</strong>g known issues (see Section 5.4), there are various nodes <strong>in</strong> the
FRep API that rema<strong>in</strong> to be implemented. Other limitations are connected to the nature of
function-<strong>based</strong> <strong>modell<strong>in</strong>g</strong> itself. For example, it can be very difficult for a user to imag<strong>in</strong>e the
<strong>in</strong>fluence of each of the attributes <strong>in</strong> a blend operation. Develop<strong>in</strong>g new tools and techniques
to allow more <strong>in</strong>tuitive FRep <strong>modell<strong>in</strong>g</strong> and teach<strong>in</strong>g artists to use these appropriately is
another area for further research.
Houd<strong>in</strong>i has its own iso surface node to polygonise implicit functions. It might be <strong>in</strong>terest<strong>in</strong>g
to <strong>in</strong>vestigate potential performance benefits when <strong>in</strong>tegrat<strong>in</strong>g Houd<strong>in</strong>i’s polygoniser <strong>in</strong>to the
current system. On the other hand, optimisations to the polygonsier like the support for
sharp features would go miss<strong>in</strong>g.
Performance is still an issue, especially as models become more complex and higher resolutions
are applied. To leverage multiple CPU cores or the GPU, additional efforts are needed, as
shown with the CUDA <strong>in</strong>tegration <strong>in</strong> the Maya plug<strong>in</strong> (Kravtsov 2011).
As further packages are targeted, the <strong>in</strong>tegration process <strong>in</strong>to other <strong>modell<strong>in</strong>g</strong> systems can
be automated us<strong>in</strong>g a set of translators <strong>in</strong> order to avoid manual labour-<strong>in</strong>tensive work as
shown <strong>in</strong> Figure 6.1.
Figure 6.1: A set of application and platform specific translators (Kravtsov 2011)
34

REFERENCES
References
Adzhiev, V., Pasko, A., and Sarkisov, A. (1996), Hyperjazz project: development of
geometric <strong>modell<strong>in</strong>g</strong> systems with <strong>in</strong>herent symbolic <strong>in</strong>teractivity. In CSG 96 (W<strong>in</strong>chester,
UK, 17-19 April 1996), Information Geometers, 183198.
Adzhiev, V., Cartwright, R., Fausett, E., Ossipov, A., Pasko, A., and
Savchenko, V. (1999), Hyperfun project: a framework for collaborative multidimensional
f-rep model<strong>in</strong>g. Available from: http://hyperfun.org/HF_paper.pdf [Accessed 10 August
2011].
Gamma, E., Helm, R., Johnson, R., and Vlissides, J. (1995), Design patterns: elements
of reusable object-oriented software.
Kravtsov, D. (2011), Hybrid <strong>modell<strong>in</strong>g</strong> of time-variant heterogeneous objects. PhD Thesis.
Ohtake, Y., Belyaev, A., and Pasko, A. (2002), Dynamic mesh optimization
for polygonized implicit surfaces with sharp features. Available from:
http://hyperfun.org/TVC02obp.pdf [Accessed 5 August 2011].
Pasko, A. (2011), What is frep? Available from:
http://hyperfun.org/wiki/doku.php?id=frep:what [Accessed 5 August 2011].
Pasko, A., Adzhiev, V., Sour<strong>in</strong>, A., and Savchenko, V. (1995), Function representation
<strong>in</strong> geometric model<strong>in</strong>g: concepts, implementation and applications. Available from:
http://hyperfun.org/TVC95.pdf [Accessed 5 August 2011].
Pasko, G., Pasko, A., and Kunii, T. (2005), Bounded blend<strong>in</strong>g for function-<strong>based</strong> shape
model<strong>in</strong>g. Available from: http://www.hyperfun.org/BoundBlend_CGApref<strong>in</strong>al.pdf [Accessed
5 August 2011].
Schmidt, S. H. (2011), Hdk - houd<strong>in</strong>i makefile for mac. Available from:
http://www.subsites.org/484.0.html [Accessed 1 August 2011].
SideFX (2011)a, Houd<strong>in</strong>i development kit – architectural overview. Available from:
http://www.sidefx.com/docs/hdk11.0/hdk_opbasics_architecture.html [Accessed 1 August
2011].
SideFX (2011)b, Houd<strong>in</strong>i development kit – geometry <strong>in</strong>troduction. Available
from: http://www.sidefx.com/docs/hdk11.0/hdk_geometry_<strong>in</strong>tro.html [Accessed 1 August
2011].
SideFX (2011)c, Extend<strong>in</strong>g the hou module us<strong>in</strong>g c++. Available from:
http://www.sidefx.com/docs/houd<strong>in</strong>i11.0/hom/extend<strong>in</strong>gwithcpp [Accessed 3 August
2011].
35