BuildingEngine Node Guide - v3.5
BuildingEngine Node Guide - v3.5
node guide
skylineEngine is an urban procedural modeling system with a module-based
approach. Everything in skylineEngine is made of modules, some of them in
Python code, others as elegant Houdini Digital Assets (HDAs). This document
is a guide for the nodes in one of these modules, buildingEngine, created for
procedural description of buildings.
This house is the Raccolet House: We took the assets (doors, windows,
columns, etc) from the model from Daz3D (www.daz3d.com), and made a
fully procedural version of it!
1 - Introduction
The buildingEngine module, originally a stand-alone project called XMLShape,
aims at the development of a visual implementation of the paper [Mller06]:
P. Mller, P. Wonka, S. Haegler, A. Ulmer and L. Van Gool, Procedural
Modeling of Buildings, in Proceedings of ACM SIGGRAPH 2006 / ACM
Transactions on Graphics (TOG), ACM Press, Vol. 25, No. 3, pages 614623.
buildingEngine is written in a mixture of Python and Houdini Digital Assets. It is
intended as a procedural modelling and rendering tool.
2 - CGAShape
In this section we provide an overview of shape grammars (used for example in
architecture) and the problems that occur during visual editing, and our proposal
to solve them. Here, we loosely follow the notation introduced by Mller et al. in
the above-mentioned article, although the concepts work for other grammars as
well. The main concept of a shape grammar is based on a rulebase: starting
from an initial axiom shape (e.g. a building outline), rules are iteratively applied,
replacing shapes with other shapes. A rule has a labelled shape on the left
hand side, called predecessor, and one or multiple shapes and commands on
the right hand side, called successor. Commands are macros creating new
shapes or commands.
predecessor
SuccessorCommandA;
SuccessorCommandB;
Traditionally, four commands were introduced in that paper: Subdiv, that
performs a subdivision of the current shape into multiple shapes, Repeat that
performs a repeated subdivision of one shape multiple times, Component Split
(called Comp) creating new shapes on components (e.g. faces or edges) of the
current shape and Insert of pre-made assets replacing a current predecessor.
Traditionally, during a rule application, a hierarchy of shapes is generated
corresponding to a particular instance created by the grammar, by inserting rule
successor shapes as children of the rule predecessor shape [Mller06] [Lipp08].
This production process is executed until only terminal shapes are left. An
example rulebase is visualized in Figure 2(a). The figures follow the visual
notation introduced in [Lipp08]. One of the main potentials of shape grammars
lies in variations they can produce, as each created instance could look different.
Of course, these variations are available only when the designer explicitly
introduces them as parameters or specific selectors in the rulebase design
process. However, the rule-based nature of shape grammars introduces some
already identified (and important) shortcomings [Lipp08]: the dependency
between rules is not clearly visible, which makes it complex to understand their
direct effect on the model being created. This results in difficulties for
understanding and exchanging rulesets created by different artists. The main
reason for this is the disassociation between the graph of rules used and the
tree of products generated. On the other hand, tools that follow a node-based
display of operations like Autodesks Maya Hypergraph shader editor and
SideFXs Houdini are very popular among artists. These are tools that use a
very intuitive (and familiar) node-based visual streaming paradigm that is fully
oriented to operations: artists control the operations that are performed on the
data, which is equivalent to controlling the data itself.
(a)
(b)
Figure 2: (a) A visual representation of a simple rulebase which starts by
selecting two facades (L and F) from the input mass model, and applying a
common window pattern and a door (also shown in the Figure). The rules
themselves form a graph (b). We found this disassociation to be awkward and
error prone, being much simpler to write the rules directly at the graph.
Tip
Labels are not erased by the operations through the nodes, so you can track
labelled geometry all the way downstream. This way, if a face was labelled
faade, all its descendant nodes (floors, windows, balconies, door, ) will
also be labelled the same way. So, it is not uncommon to have a piece of
geometry having several labels attached to it: faade, firstFloor,
window
__floorsRepeat__4
__floorsRepeat__3
__floorsRepeat__2
__floorsRepeat__1
__floorsRepeat__0
__floorsRepeat__0
4 - Node Descriptions
Parameters
Filter
Product
Size
Center
Example Files
simpleBuilding
The CreateBase node is used twice to create the mass model of these twoblock building.
In the image you can see the two nodes wired to a Merge node (out of the
image) just for visualization purposes.
Parameters
filter
product
height
Example
Simple use of Extrude nodes
One possible way to go with this node is to generate a curve with a Houdini
Curve node, and then give it a group name with a Group node (In this case, we
used lot), and finally wire the result to the Extrude node, setting its filter to the
same name (again, lot).
Curve
Group Geometry
(Group Name = lot)
Extrude
(filter = lot)
10
Parameters
Input filter
Components
Enabled n
Selector n
back
left
right
11
Product n
Front Dir
top
bottom
side
all
Example Files
simpleBuilding
In this example, the two blocks created for the mass model are classified into 3
components with the following order:
1. front
2. side
3. top
This will result in the input geometry being divided in three sets, one for each
label. In the following figure we can see the result of such a partition of the input
geometry (the two-block mass model created with the CreateBase nodes)
font
side
top
12
side
front (empty!)
top
As we can see, the faces corresponding to the faade of our buildings are
selected as side, and there is no geometry associated with the front label!
However, the top group label is not changed, as all the changes we did are
with respect to normal vectors with main horizontal components.
13
Parameters
Input filter
Axis
Divisions
Enabled n
Approximate n
Value n
Product n
Example Files
simpleBuilding
Starting from the front faces identified with the Comp node, we had the
following situation for the front geometry, belonging with faade group:
Approximate
No
Yes
No
Value
3
1
2.5
15
As you can see, the middle division has a height that accommodates to the total
height of the input geometry.
Note
If a division in the Subdiv node is relative and all the others are not, the value
assigned to the split operation is irrelevant, as any geometry left from the
absolute cuts will be in this division.
16
(
(
)
)
$! floor L
Value
N =#
L
!"round Value
if Approximate = FALSE
if Approximate =TRUE
The different situations can be compared in the following image, where we have
set approximate divisions on the left and non-approximate divisions on the right.
As you can see, when approximate divisions are chosen, you can only specify
an approximate size, but all divisions will be equal. Instead, if divisions are not
approximate, all will be exactly the same size, but there can be some geometry
left that is much smaller than the specified size.
Parameters
filter
Product
Axis
Approximate
Value
17
Example Files
simpleBuilding
For example, if we take the middle geometry that comes from the Subdiv
node, as shown on the image,
18
Parameters
filter
Product
iAsset File
Translate
Rotate
Scale
Relative x
Relative y
Relative z
Example Files
simpleBuilding
At the following images we can see the Insert node in action:
19
Just if youre wondering what the relative values mean, compare the following
image with a relative geometry in the local z direction with the above one (with
an absolute size value):
20
Parameters
filter
Product
Texture Map
Scale
Example Files
simpleBuildingTextures
At the following images we can see the InsertTex node in action:
In this case the windows are just textures, not 3D geometry. This enormously
decreases the memory requirements of any building created with this engine,
21
22
Parameters
filter
Product
Asset Object
Translate
Rotate
Scale
Relative x
Relative y
Relative z
Example Files
simpleBuilding_InsertObj
It works exactly as the Insert node, but by taking its geometry from another
node in the scene instead of from a file in disk.
23
Parameters
filter
Product
Translate
Rotate
Scale
Example Files
...
24
Parameters
filter
product
height
direction
incl
Example Files
simpleBuilding
In the following figure we add one roof to each input geometry labelled as roof.
25
Parameters
filter
tag
Expression
Prod Selected
Prod Non-Sel
Example Files
simpleBuildingWithException
In the following figure we can see that we have used an exception node to
select a given window and make it different to the others. To do it, we selected
window as input filter to affect only elements with that specific tag. Now, in the
example we used the value __repeat1__0 for the tag, selecting the first
element that was the output of the repeat1 node. This node is the one that
26
27
Parameters
Filter
Direction
Dispersion
ProductSel
ProductNonSel
Front Dir
Example Files
...
28
Tip
This node simply works using the tags in the geometry. It basically is a
wrapper around Houdinis Delete node, but in buildingEngine style!
It is very useful for giving multiple tags a unique new tag (the tags are ORed).
Parameters
Input filter
Operation
Product
Delete non-selected
Example Files
...
29
Parameters
filter
Products
Condition n
HScript n
Product n
Else
Example Files
...
30
Parameters
filter
Products
Probability n
Product n
Example Files
...
31
Bibliography
[Mller06] P. Mller, P. Wonka, S. Haegler, A. Ulmer, and L. Van Gool.
Procedural modeling of buildings. ACM Trans. Graph., 25(3):614623, 2006.
[Lipp08] M. Lipp, P. Wonka, and M. Wimmer. Interactive visual editing of
grammars for procedural architecture. ACM Transactions on Graphics,
27(3):102:110, Aug. 2008.
[Patow11] G. Patow, User-Friendly Graph Editing for Procedural Buildings,
IEEE Computer Graphics and Applications, vol. 32, no. 2, Mar./Apr. 2012, pp.
66--75; doi:10.1109/MCG.2010.104.
32