Online Submission ID: 0174

Interactive Architectural Modeling with Procedural Extrusions

Figure 1: We present an interactive procedural modeling system that is able to model difficult architectural surfaces, such as roof construc-
tions. This figure shows procedural extrusions applied to 6000 floorplans from a GIS database of Atlanta.
FA
1 Abstract
2 We present an interactive procedural modeling system for the exte-
3 rior of architectural models. Our modeling system is based on pro-
4 cedural extrusions of building footprints. The main novelty of our
5 work is that we can model difficult architectural surfaces in a pro-
6 cedural framework, e.g. curved roofs, overhanging roofs, dormer
7 windows, interior dormer windows, roof constructions with verti-
8 cal walls, buttresses, chimneys, bay windows, columns, pilasters,
9 and alcoves. We present a user interface to interactively spec-
10 ify procedural extrusions, a sweep plane algorithm to compute a
11 two-manifold architectural surface, and applications to architectural
12 modeling.

13 1 Introduction
14 The main motivation for our work is to develop an interactive and
procedural modeling tool for complex architectural surfaces. We
KE
15

16 are interested in procedural and interactive modeling for three rea-

17 sons. First, procedural descriptions allow edits of architectural sur-
Figure 2: Procedural extrusions allow a plot footprint to be ex-
18 faces at multiple levels and previous edits will adapt to subsequent
truded to form the walls and roof of a house.
19 ones. For example, the scene in Fig. 1 can be edited by reshap-
20 ing the building footprints, and the model building, including the
21 complete roof construction, will change according to the new in-
22 put. Second, procedural modeling is the most efficient method to 41 We consider this part interesting because after analyzing examples,
23 generate larger urban environments. Finally, we want to combine 42 such as the one shown in Fig. 2, it is not clear how to model such a
24 interactive and procedural modeling, because a frequent obstacle 43 building, and what editing operations are even necessary to ensure
25 to using procedural tools is that it requires scripting. Eliminating 44 that a larger class of interesting architecture can be modeled. The
26 scripting will enable more users to use procedural modeling tools. 45 second part of our solution is a collection of algorithms to com-
46 pute procedural extrusions starting from initial building footprints.
27 We consider many complex architectural features, including over- 47 We propose a sweep plane algorithm to grow the architectural sur-
28 hanging roofs, dormer windows, interior dormer windows, roof 48 face upwards and to handle various events stemming from user ed-
29 constructions with vertical walls, buttresses, chimneys, bay win- 49 its or plane intersections. While the algorithms are inspired by the
30 dows, columns, pilasters, and alcoves. See Fig. 2 for an example 50 straight skeleton [AAAG95], the existing straight skeleton has nu-
31 showing some of these features. These complex architectural su- 51 merous restrictions on the input, such that almost all of the complex
32 faces have not been handled in procedural modeling before, and the 52 architectural surfaces listed above cannot be modeled.
33 main contribution of this paper is to introduce the first procedural
34 modeling solution that includes these surfaces. Previous work in
35 procedural modeling using shape grammars [MWH∗ 06b, LWW08] 53 2 Related Work
36 is able to model some architectural roof surfaces on a restricted set
37 of footprints, but not the more complex roofs on arbitrary footprints 54 In architecture, Stiny pioneered the idea of shape grammars [Sti75].
38 shown in this paper. 55 In computer graphics grammars were used as a design tool for ar-
56 chitecture by Wonka et al. [WWSR03], Müeller et al. [MWH∗ 06b],
39 The first part of our solution is to identify the most important ed- 57 Aliaga et al. [ARB07], and Lipp et al. [LWW08]. L-
40 its and to design a user interface to specify procedural extrusions. 58 systems [PL91] were also proposed for procedural modeling of

1
 Online Submission ID: 0174

98 changing profiles and discrete modifictions that are specified by the

99 user interface to create complex architecture.

Figure 4: The interactive interface, showing the schematic of a

Figure 3: These two examples show architectural surfaces over-
temple. The right window contains the output preview whilst the
layed with the footprints (green) and profiles (blue) that were spec-
left window contains the plan and the profile editors.
ified to model them. Plan-edits (orange) allow additional features
to be inserted. Overhangs are created with new profiles (red).
3.2 Plans and Profiles
FA
100

59 architecture [MPB05]. Merrel and Manocha [MM08] propose a 101 The UI consists of one window showing the floorplan, one window
60 more general approach that can create new models from an ex- 102 for profile curves, and a 3D preview window as shown in figure 4.
61 ample mesh. Given a man-made model as input, great results for
62 reshaping were achieved by Cabral et al. [CLDD09] and Gal et 103 A closed simple polygon defines the footprint of the house, and a
63 al. [GSMCO09]. The output of our proceudral extrusions could 104 set of polyline segments define a profile for each edge in the floor-
64 also be further processed to distribute brick patterns [LDG01] 105 plan. Users are able to edit both of these structures, while the solid
65 and in special cases maybe to perform PQ or conical remesh- 106 geometry is updated in the 3D preview window. Each plan edge is
66 ing [LPW∗ 06]. Appendix A, (Chapter 8) details other loosely re- 107 assigned a profile; A profile can be assigned to more than one plan
67 lated procedural extrusion techniques. Our methodology is also re- 108 edge.
68 lated to the work by Finkenzeller [Fin08] and Haveman [Hav05] 109 To present the user with easily understood behavior, the profiles
69 who also suggested to use extrusion operations similar to the 110 must be monotonic in the vertical direction. Because the underlying
70 straight skeleton for architectural modeling. The straight skeleton 111 procedural extrusions grow the architecture upwards, a downwards
71 was introduced by Aichholzer et al. [AAAG95, AA96] and the au- 112 facing profile segment is meaningless. The interface enforces this
72 thors commented how the straight skeleton computes a very plau- 113 constraint in the polyline editor. The concept we use is to break
73 sible roof construction over a polygon. Applications of the straight 114 non-monotone profiles into a sequence of upward growing profiles
74 skeleton to roof modeling were demonstrated by several authors, 115 through profile offset events, described next.
75 e.g. [LD03, Hav05, MWH∗ 06b]. Implementations for the straight
76 skeleton were proposed by Felkel and Obdrzalek [FO98] and Cac-
77 ciola [Cac04]. The idea of weights for the straight skeleton has been 116 3.3 Profile Offset Events
KE
78 briefly mentioned by Eppstein and Erickson [EE99], but the topic
79 was only developed for convex polygon decomposition [Aur08]. In 117 In an architectural setting, overhanging roof sections are often at the
80 conclusion, while we are inspired by a lot of great previous work, 118 same height on several sides of a house. To facilitate creating these
81 most previous work focused on interesting theory in computational 119 shared overhangs, we introduce profile offset events, figure 5. These
82 geometry. In constract, we propose actual algorithms for the com- 120 are shown to the user by a handle and associated two polylines in
83 putation and many extensions so that interesting roof surfaces can 121 the profile editing window. The polylines represent the gradients of
84 be modeled. 122 the inner and outer faces of the roof respectively. After they have
123 been added to one profile, the offset event is copied to all profiles.
85 Appendix A gives details of related geometric techniques. 124 The offset distance and associated roof gradients can then be edited
125 for each edge individually, or the offset removed from any given
126 edge. The challenge of the implementation is the procedural defini-
86 3 User Interface Description 127 tion. The edit has to remain valid even after the building footprint
128 is changed.
87 Our interface controls a sequence of extrusions that are particularly
88 suitable for creating manifold urban models. In this section we will
89 introduce the functionality of our user interface.
129 3.4 Anchors

130 Several editing operations require us to robustly locate features on

90 3.1 Modeling With Profiles 131 the manifold. The features have to be placed so that they can still be
132 located after subsequent edits. This is called the persistence prob-
91 The inspiration for our work comes from simple roofs, that are de- 133 lem in editing procedural models ( [LWW08]), and we introduce
92 fined by a 2d polygonal plan and a gradient that defines the roof 134 anchors as a solution in our system. Similar to profile offset events
93 slope. Our idea is to extend this simple concept to construct a wide 135 the challenge is to procedurally locate edits without precluding fu-
94 variety of roofs by using different gradients on each edge, and entire 136 ture edits, e.g. changes to the building footprint or profiles.
95 structures by changing the gradient profile as we ascend, figure 1.
137 The user can place anchors by selecting a location in the 3D view, or
96 To construct our geometry we use a sweep plane that rises verti- 138 by selecting a point by on the floorplan edge and the corresponding
97 cally from the base of the building. This sweep plane combines the 139 profile polyline.

2
 Online Submission ID: 0174

162 by adding a rectangle exterior to the plan, and applying the appro-
163 priate profiles we can create buttresses, as in figure 22. If the input
164 plan has several repeated elements, such as bay windows or but-
165 tresses, plan-edits give a convenient tool for defining the shape and
166 profile application once, and repeating it a number of times around
167 the perimeter.

168 3.6 Positioning Procedural Details

169 Anchors can be used to mark the first and last element in a grid
170 of features, such as windows. Parameters can be set to control the
171 width of the repetitions, and when combined with relative anchors
172 allows features to be distributed on resizable façades. Variations
173 on this theme allow rows or columns of features to be located, for
174 example a line of dormer windows on a roof.
175 The location of anchors may also be used to specify the location for
Figure 5: Left: One profile offset (a,b) defining a shared start- 176 complex external features, such as windows and doors, described
ing height for two different gradients of roofs. Right: Sharing this 177 by arbitrary meshes. Each mesh element can be further parameter-
profile offset event allows the roof height to be parameterized. 178 ized by the location of several defining bones. These control bones
FA
179 deform their associated meshes using pre-defined weights. For ex-
180 ample moving the control bones at the top or bottom of a pillar will
140 We allow the user to select from two types of anchor - relative and 181 change its height.
141 absolute. A relative anchor’s position is taken to be a fraction of 182 Faces of the output model can be identified by adding tags to the
142 its length on the plan edge. As long as that plan-edge still exists at 183 profile segment. These are represented by small triangles in the
143 the specified height, the feature is instanced using the same fraction 184 user interface. Once the manifold is complete, the faces that were
144 taken on the length of the plan edge at the that height. An absolute 185 generated from the specified profile segment are processed in a par-
145 anchor is projected from its location on the input plan edge onto 186 ticular way, for example to add tiles to the roof.
146 a line defined by the current plan edge line-segment. If this point
147 is within the bounds of the line segment, it is used. Because a face
148 defined by a plan line segment may grow as it ascends, it is possible 187 3.7 Modeling Larger Environments
149 to position absolute anchors beyond the ends of the line segment.
188 We provide tools to model larger environments by example. We
189 implemented several feature extraction algorithms to automatically
150 3.5 Plan Edits 190 label edges of building footprints. Example labels are length ∈
191 short, medium, long and orientation ∈ street, side, back. The
151 Discrete edits to the plan at a certain height are know as plan-edits. 192 most important label is an angle computed by orienting the build-
152 These are located by an anchor specified by the user, and introduce 193 ing to the street and mapping the normal vectors of the footprint
153 new edges into the structure. Again the user is offered several tech- 194 edges to the unit sphere S2 . We assume that each footprint in the
154 niques with different advantages. Forced steps allow a portion of 195 environment is labeled with a building type by another procedu-
an edge to be replaced by arbitrary geometry, while natural steps ral algorithm. For each building type we can assign one or multiple
KE
155
196
156 offer a range of simple shapes that can be inserted. For reasons that 197 profiles to each edge type including a probability value if more than
157 are discussed later, forced steps are more powerful, but can break 198 one profile is assigned.
158 the manifold, while natural steps are guaranteed to create manifold
159 geometry.
199 4 Algorithm
200 In this section we give an overview of the algorithm to create the
201 procedural extrusions defined by the user interface. This algorithm
202 extrudes footprints according to a set of profiles. We begin with
203 an overview of the algorithm, before discussing the many possible
204 events that drive the extrusion algorithm, and finally giving details
205 of the computation.

206 4.1 Overview

207 We describe the input, the output, define the terminology, and give
Figure 6: Left: The plan (green line) and profiles profiles (blue 208 an outline of the algorithm.
lines) define the shape of the structure, while the anchors (orange) 209 Input: The input of the algorithm is a collection of simple poly-
locate the chimney feature. A step is inserted into building at the 210 gons (polygons without self intersections) with an arbitrary number
anchored location. Middle: The finished inverse dormer window. 211 of holes. A polygon is described by n polygon corners ci ∈ R3
Right: Alternative structure which adds in an additional rectangle 212 with 1 ≤ i ≤ n. All input corners are restricted to the same height
to the plan and corresponding profiles in the first stage to specify a 213 value, that is they lie in a plane parallel to the xy-plane. Each cor-
chimney. 214 ner ci is connected to its counterclockwise neighbor by a polygon
215 edge (p-edge) ei . Additionally, each p-edge is associated with an
160 As shown in figure 6 we can use discrete plan-edits to locate fea- 216 angle θi so that −π/2 ≤ θi ≤ π/2. Each p-edge ei together with
161 tures such as inverse dormer windows, or chimneys. Additionally 217 the associated angle θi define a skeleton-plane s-plane pi through

3
 Online Submission ID: 0174

218 the p-edge ei . See figure 7. Note that the order for inner loops 248 These can be basic topological changes or user driven events such
219 is reversed (clockwise) and that we can have an arbitrary nesting of 249 as offset or anchor events.
220 loops (another loop inside a hole). Without loss of generality we de-
221 scribe the algorithm for a single polygon, as multiple polygons can
222 just be interpreted as a single polygon with multiple disconnected
223 loops.

Figure 7: Our algorithm constructs a roof, shown on the right,

for an input polygon, shown on the left. The input is defined by the
FA
p-corner positions ci , the roof plane angles θi , and the corner con-
nectivity. The s-planes spi are derrived from the edges and angles. Figure 9: An example construction demonstrating basic events,
The s-edges correspond to edges in the output polygon that were and the area enclosed on the sweep plane after each event is pro-
not the input p-edges. cessed. In (1) three adjacent s-planes collide at an edge event. In
(3) we see a split event that divides the roof and inserts two corners
at the same location to create two loops of corners. Finally, (2)
224 Output: The output of the algorithm is a graph of skeleton-edges shows a vertex event where more than three s-planes collide at one
225 (s-edges) connecting the corners, which includes the input polygon point. The edges of the polygon are the output s-edges.
226 vertices and new corners stemming from intersection points. This
227 graph implicitly defines a watertight manifold in 3D, which we use
228 to model architecture. This output can then be post-processed to ap-
229 ply textures, add procedural geometry, and attach meshes at anchor
230 points.

Main begin
foreach corner ci in input do
InsertCornerInPriorityList( ci );
sweepZ = 0;
while !EventPriorityQueue.Empty() do
event = PriorityList.NextEvent();
if event.Height() ≥ sweepZ then
KE
sweepZ = event.Height();
HandleEvent(event);
PriorityList.Insert(event.newEvents);

end

Figure 8: Pseudo-code for the main dispatch loop. Figure 10: The data structure used to build the skeleton, shown
midway through the sweep

231 Outline: The algorithm is a sweep plane algorithm. At each sweep

232 height the geometry is defined by a polygon that is a 2D cross- 250 Data structures: The primary data structure records the polygon
233 section through the architectural manifold. 251 at the sweep plane. This structure is a doubly linked list of corners.
234 During the sweep we follow the movement of the corners of the 252 Each corner has a pointer to the next corner and the previous corner
235 polygon. Starting from the input polygon the edges of the polygon 253 (assuming counterclockwise order) and a pointer to its previous and
236 move upwards according to their slope and the corners move up- 254 next p-edges, figure 10. At the beginning of the algorithm the data
237 wards along the intersection line of the two adjacent s-planes. This 255 structure encodes the input. During the sweep the data structure is
238 movement and implicitly defined geometry is straightforward until 256 updated to define which corners and which portions of which edges
239 an event occurs. During events, modifications to the topology of the 257 define the bounds of the solid.
240 polygon occur, such as the creation of new corners or s-edges.
241 The algorithm, figure 8, is a loop that handles geometric events 258 A second important data structure is an event priority queue that
242 according to their height from the ground plane [FO98]. The re- 259 sorts events by ascending height. The strategy of our algorithm is
243 sulting architectural manifold consists of regions of the s-planes pi 260 to use a lazy evaluation of events. We fill the priority queue with
244 bounded by corners. 261 a large number of potential intersection events. Wherever three or
262 more of the unbounded s-planes intersect, there is a potential event.
245 The algorithm uses a sweep plane that starts from the plane contain- 263 As the sweep plane reaches a potential event, we evaluate it against
246 ing the input polygon and moves upwards in the z direction. Dur- 264 the boundaries of the involved s-planes, to decide if the event should
247 ing the sweep, a multitude of events are encountered and processed. 265 be processed.

4
 Online Submission ID: 0174

266 4.2 Description of Events 307 corners, at the height of the event. The offset-distance is specified
308 independently, or disabled entirely for each profile curve.
267 In this section we describe the events encountered as the sweep
268 plane ascends. 309 Anchor Events: As the sweep plane reaches the height of a profile
310 anchor we firstly identify any of the active edges on the sweep plane
269 Generalized Intersection Event: There are three events types, 311 that use this profile. From these edges the corresponding plan-
270 given by previous authors [FO98] [EE98], which occur to edges as 312 anchors are located and either the absolute or relative outer prod-
271 the sweep plane rises. Edge events occur as the length of a polygon 313 uct specifies the location of the anchor single location. Plan Edit
272 edge shrinks to zero. The faces defined by three consecutive (linked 314 Anchors: These modify a subset of the corners and edges on the
273 by corners) edges collide, (figure 9, 1). Split events take place when 315 sweep plane to represent new features such as chimneys, or dormer
274 two adjacent s-planes, and one non adjacent s-plane collide, (figure 316 windows. Mesh Anchors: These store the location of the anchors
275 9, 3). These split the contained area on the sweep plane into several 317 as an attachment point for geometry.
276 parts. Finally vertex events occur when more that three s-planes
277 collide at one point. 318 4.3 Generalized Intersection Event
FA
Figure 12: Left: Straight skeleton, middle: Straight Skeleton with
gradient changes, right: Procedural extrusions

319 Although the concept of the straight skeleton has existed for several
320 years, we found that there is no information about an actual algo-
Figure 11: Two Weighted Staight Skeletons for degenerate cases. 321 rithm to implement the weighted straight skeleton. Even though
At a and b, four planes collide at one point. Point c shows seven 322 the algorithm in this section is based on previous work in the un-
planes colliding from a variety of angles, including horizontally. 323 weighted case e.g. [Cac04] [FO98], our modifications result in sub-
324 stantial improvements in the speed and range of forms that can be
325 produced.
278 Unfortunately, we did not find this categorization of events help-
279 ful to designing a robust algorithm. In practice our architectural 326 We are the first to introduce an algorithm for extrusions using inde-
280 models give rise to a large number of degenerate events and the 327 pendently weighted edges. We also remove the monotonic restrici-
implementation is dominated by special event handling. Therefore ton on profiles of earlier work [Hav05] to allow overhanging roofs.
KE
281 328

282 it is surprising that previous work does not detail the implemen- 329 This results in a 3D instead of a 2D algorithm. We are also the first
283 tation of vertex events, the main difficulty in the implementation. 330 to recognise the difficulty of independendly weighted edges, that
284 Since edge and split events are special cases of a vertex event, we 331 is the existence of ambigous events (and we present a strategy to
285 introduce one general intersection event that consists of an arbitrary 332 resolve these events). The possibility of a 2D weighted skeleton is
286 number of planes intersecting at one point. See figure 11 and 13 for 333 discussed in previous work [EE98] [BEGV08], but no algorithm is
287 two examples. We introduce a new algorithm to resolve this gener- 334 given and the ambigous cases were not discovered.
288 alized intersection event that uses chains of p-edges involved in the
289 intersection. 335 Our second novelty is the introduction of a floating point algorithm
336 instead of an exact arithmetic one. Previous floating point imple-
290 Edge Direction Events: User generated profiles curves define 337 mentations were unreliable near degenerate collisions of four or
291 heights at which the edge direction will change. An edge direc- 338 more edges because they rely on split and edge events being cor-
292 tion event is specified by each vertex in a profile. Given that the 339 rectly ordered by height. When more than three faces meet at a
293 corresponding p-edge is still active, it is replaced by a new p-edge 340 point, the order of the events is chaotic due to floating point insta-
294 with a different gradient. 341 bilities. We introduce a novel event clustering algorithm to make
342 the floating point computations robust. The advantage of our algo-
295 Profile Offset Events: Profile offset events are generated by the
343 rithm is a much faster implementation speed, but we believe that
296 corresponding edits. Intuitively, the profile offset event results in
344 extending the exact arithmetic implementation would also be of in-
297 an addition to the polygon defining the cross-section at a speci-
345 terest.
298 fied height. The difficulty of specifying and handling profile offset
299 events comes from the procedural definition. While it is easy to 346 Robust Event Detection: One key to the success of the algorithm
300 specify changes to one specific polygon, subsequent edits may alter 347 is to use robust event detection and event clustering. There are two
301 the definition of the extrusion. We therefore need to specify a robust 348 robustness problems that we address at this stage of the algorithm.
302 procedure that can procedurally perform changes to a polygon with-
303 out creating awkward self-intersections. When the required height 349 First, in symmetrical inputs, like floor plans, it is very common for
304 is reached a new offset polygon is created for the area currently en- 350 more than three s-planes to meet at a point. To avoid degenerate
305 closed on the sweep plane, using a sub-application of procedural 351 output [EE99] in a floating point situation it is necessary to find
306 extrusions. This offset polygon is then added to the p-edges and 352 events whose intersection locations, inti , are close together and

5
 Online Submission ID: 0174

388 collision occurs on the surface, but find the corner that represents
389 that portion of the edge. At this point we note that due to earlier
390 events one p-edge may end up in two or more separate volumes as
391 the algorithm progresses. When we evaluate a chain of length one
392 we ask if the collision lies between the corner’s previous edge, and
393 the next corners following edge. To do this robustly we expand the
394 bounds given by the adjacent edges to detect a collision. A small
395 epsilon range δ1 expands the bounds and ensures that collisions oc-
396 cur reliably. On our inputs we find δ1 = 10−5 a sufficient margin.
Figure 13: Left: 5 roof-planes creating an intersection event.
Right: events can interfere with each other if they have the same 397 Second, we need to filter p-edges that are no longer part of the con-
height, in this case the four points share a roof ridge. 398 struction. If this filtering produces events with less than three par-
399 ticipating edges, they are ignored.
400 Intra-chain handling: In an intra-chain collision we remove all
353 treat these events as if they had a single intersection point. See 401 interior corners, leaving only the start and the end of the chain, as
354 figure 13, left, for an example. 402 shown in figure 15. S-edges are output between all removed corners
355 Second, even events that are far apart from each other can interfere 403 and the position of the collision. Unreferenced edges are removed.
356 if they are close to each other in height, figure 13, right. It is nec-
357 essary to detect and handle these events together for resolving the
FA
358 ambiguities that can occur (described in section 4.5).
359 Basic Event Clustering: After the initialization the we iteratively
360 processes (potential) events stored in the event priority queue. To
361 address the two previously mentioned robust event detection prob-
362 lems, we cluster the basic events in two directions. Each event that
363 we get from the event priority queue consists of all events whose
364 height, z, is within some δ2 threshold of the initial event. Second,
365 we cluster all the basic events according to their location after pro-
366 jection onto the xy plane. That means all events that are within a
367 cylinder of radius δ3 and height δ2 will be grouped into a cluster.
368 See figure 14 for an illustration of the clustering step. For our build-
369 ing footprints with size in meters we use double precision floating
370 point representations and values δ2 = 10−4 , δ3 = 10−6 . Figure 15: Intra-chain pointer modification.

404 Inter-chain handling: An inter-chain collision takes place be-

405 tween the last p-edge in the proceeding chain, and the first p-edge
406 in the following chain. As figure 16 illustrates we add one new cor-
407 ner at the location of the collision, linked between the proceeding
408 and following edges. Appendix 8.2 figure 30 details pseudo code
KE
409 for intra and inter-chain pointer manipulations.

Figure 14: When an event is processed we simultaneously extract

all events within a height of δ2 . Then we cluster all events that are
within a cylinder of radius δ3 and height δ2 .

371 Chain construction: Our previous clustering step ensures that near
372 collisions are treated as occuring at the same location. Thereafter
373 we construct a list of chains containing corners from the set of p-
374 edges in the collision event as follows. A chain consists of currently
375 consectutive p-edges that are colliding. There may be several chains
376 involved in a collision. These are identified by the corners at the
377 start of each edge. The list of chains is ordered by their orientation Figure 16: Inter-chain pointer modification.
378 around the collision point at the clustered height. We process ad-
379 jacent pairs of edges, first within each chain, and then between the
410 Special cases: If only one cluster of face intersections occurs at
380 chains themselves.
411 a given height this algorithm is sufficient, however when several
381 Filtering invalid events: There are several ways an event has to be 412 events occur at one height we loose information from the corner
382 filtered. 413 data structure that we would otherwise use to determine if a col-
414 lision has occurred on a face. This is one of the purposes of the
383 First, there are events whose corresponding intersections do not oc- 415 height-clustering introduced in section 4.3.
384 cur on the surface of the architectural manifold. In a chain of two
385 or more corners, the edges share a s-edge that leads to the collision, 416 For this reason all chains at one height are found before any are
386 so both must be involved in a collision. However if there is only 417 modified. However a chain may have been separated from it’s in-
387 one edge, a chain of length one, we must not only ensure that the 418 tended collision by an earlier event at the same height. Before pro-

6
 Online Submission ID: 0174

419 cessing, each chain must then recover their new current set of cor-
420 ners.

421 4.4 Edge Direction and Profile Offset Events

Figure 18: An ambiguous situation that arises in the case of a

concave input polygon, 1. This may be resolved into two ways, 2,3.
Figure 17: The horizontal section desired (2) can be created by
an additional use of procedural extrusions to calculate the offset in
the given direction (3). After flattening (3) unchanged edges (red,
4) are removed.

422 To handle edge direction and profile offset events we stop the al-
gorithm before any given event and calculate the polygonal cross-
FA
423

424 section at the sweep plane. We then replace the relevant s-planes
425 with planes with the new angles, and restart the evaluation. An
426 edge’s profile may then be defined by runs of line segments. In pre-
427 vious work the runs are monotonic in the upwards direction, that is
428 they are limited to angles above the sweep plane.
429 The output is poorly defined as the angle of an edge approaches
430 horizontal, ±π/2, as two horizontal planes do not intersect to form
431 a roof edge. Additionally, as the angle approaches these limits we
432 are colliding near coplanar faces, causing numerical instability. We
433 propose a two step solution to calculate the bounds of a horizontal Figure 19: Two indentical bay windows that lead to the same am-
434 profile section. As figure 17 illustrates, we first increase the gra- biguous case. The one on the left is resolved using the volume min-
435 dients for numerical robustness, recursively start a procedural ex- imizing technique, the one on the right is volume maximizing
436 trusion, and then project this sub-application onto the sweep plane.
437 This produces the required horizontal, or near horizontal offset sur-
438 face. 466 Depending on the configuration as the edges approach parallel, the
439 In order to create the downwards moving faces seen on overhanging 467 result is quite different, and so the limiting case is of little help
440 roofs the user builds runs of profiles, monotonic in the direction the 468 when resolving these situations. Because of the utility of a robust
441 horizontal sweep plane travels, figure 5. Then, as the sweep plane 469 algorithm, this is an important situation to define. We resolve the
situation by selecting one roof-plane to replace the others in the
KE
470
442 approaches the start of each run, it can be inserted into the current
443 polygon. The difficulty of this computation is that we cannot spec- 471 corner data structure (appendix 8.2, 31). This is a reason for the
444 ify the location of the inserts in absolute coordinates, but only rela- 472 vertical clustering outlined earlier.
445 tive to the current polygon. We found that a recursive application of 473 It is interesting to note that most architectural roof structures en-
446 procedural extrusions in 2D is a very powerful and elegant solution 474 close the maxiumum volume in the ambiguous case. Alternately
447 to this problem. We found that the flexibility (weights per edge) 475 the minium case may be useful when estimating conservative off-
448 and geometric output is much better suited for our application than 476 sets. The other useful case is when we want to ensure that two edges
449 other morphological operations. We can compute the position of 477 with angles θ1 , θ2 , give a reflection when the direction of the edge
450 the edits by the 2D projection of another extrusion operation on the 478 is reversed, and the angles are negated.
451 current outline. As figure 5,a demonstrates it is necessary to define
452 additional runs in pairs as they define the boundaries of a volume
453 on the sweep plane. 479 4.6 Insertions into the polygon

480 We describe how plan-edits operate efficently, and detail two meth-
454 4.5 Ambiguities in Procedural Extrusions
481 ods to define them.
455 We show that the weighted straight skeleton in the concave case is 482 It can be noted that it is possible to halt the sweep plane between
456 ambiguous, and how different uses of procedural extrusions lead to 483 any two sets of height events during the algorithm and calculate the
457 different resolution strategies. 484 current cross-section polygon. Thus we can insert plan-edits into
485 the priority queue of height events, adding or removing edges as in
458 When two s-planes of parallel edges collide, they form a horizontal 486 figure 20 .
459 bisector. If the two corresponding p-edges have different directions
460 then this is a roof ridge and the algorithm proceeds as normal, as- 487 However doing this incurs a speed penalty as all intersections be-
461 sured that at the opposite end of the ridge the two roof ridges will 488 tween edges need to be recalculated. Here we note that it is simply
462 collide again. However if the directions are the same then we are 489 possible to insert edges into the data structure at a given height,
463 only able to obtain a degenerate bisector, figure 18. The ambigu- 490 and have adjoining corners reference the existing previous and next
464 ity arises in not knowing which direction along the intersection the 491 edges, as shown in figure 20. This has the advantage that only the
465 roof edge moves in at this point, as it has no gradient. 492 new corners and edges must have their intersections recalculated.

7
 Online Submission ID: 0174

Figure 20: Inserting a plan-edit into the polygon during execution.

The first panel shows the implicity defined polygon on the sweep
plane (blue), defined by the corners. The second panel shows the
plan-edit inserting new corners (yellow) and connecting edges into
the data structure. The final panel shows the result.
FA
Figure 21: Given an intricate polygon, calculating a robust pertu-
bation is challenging. Naive union operations (left, green) can often
expose unwanted edges (left, red). Our routine uses an application
of procedural extrusions to a small perturbation (b), with weights
on the new edges to control the dimensions (orange), guarenteeing Figure 22: From top,left: buttress, dormer windows, flying but-
the result is a simple-polygon (c & right). tress, bay windows, curved plan, eight faces meeting on a symmet-
rical footprint with a chimney, hipped roof, curved roof, a horizon-
tal overhang, an overhanging gable, standard gable and interior
dormer windows
493 Plan edges are added to the priority event list of section 4.1.
494 Our user interface offers the user two approaches to creating an edit
495 to insert into the plan. Inserting an arbitrary shape gives the most 519 not possible using just the straight skeleton or other existing proce-
496 possible varieties of geometric designs. However these forced steps dural modeling tools. We can also create buildings with horizontal
KE
520
497 offer no guarantees that the two shapes will not intersect and create 521 roof overhangs, such as figure 23. The small mesh in the fore-
498 a non-simple polygon as the geometry in undefined. The challenge 522 ground demonstrates the output of our procedural extrusions. We
499 comes again from the procedural nature of our approach and the 523 included the alcoves and columns to show how multiple polygons
500 fact that the edit has to work procedurally for different input poly- 524 can grow together and interact even though they begin without over-
501 gons. Natural steps offer a solution to this problem and again we 525 lap. This is only possible because we allow negative angles for the
502 can find an elegant way to compute them using a recursive appli- 526 roof planes.
503 cation of procedural extrusions, and projecting back into the sweep
504 plane. By calculating the polygon at a given height and amending a 527 Finally, we created a procedural model for town homes adjacent to
505 vanishingly small protrusion, a nested application of procedural ex- 528 a curved street (see figure 24). The street can be reshaped interac-
506 trusions can grow features that guarantee not to self-intersect, figure 529 tively, while the building models adapt to the new footprints.
507 21. This application of procedural extrusions is constructed by as-
508 signing a zero, or vertical angle to all edges not part of the feature, 530 5.2 Timings
509 and a positive gradient to those edges in the protrusion. The result
510 is taken at a given height and projected down to the sweep plane, 531 We implemented the proposed algorithm in Java and measured the
511 before being combined back into the original. By keeping a map of 532 running time of our algorithm on 64bit 2.6GHz Xeon. To create
512 the destinies of each edge it is possible to combine the new and old 533 a difficult example we used thresholding on a photograph and ex-
513 profile, while still only calculating collisions for the new edits. 534 tracted 24 edge loops for a total of 553 vertices. Note that the topol-
535 ogy is non-trivial as the edge loops are nested (see figure 25). We
536 assigned each edge one of three profiles. Our computation time is
514 5 Results 537 2.6 seconds. This is comparable to CGAL’s implementation com-
538 puting the straight skeleton on the same input. Note that CGAL
515 5.1 Modeling Results 539 does not support different profiles. We also conducted a test where
540 we approximated a circle with footprints of an increasing number
516 In this section we show several results of modeling with procedural 541 of edges. Here our algorithm quickly becomes 100 times faster,
517 extrusions. 542 because there are so many events happening at one point.
518 Figure 22 shows many typical architectural constructions that are 543 We created a procedural model on about 6000 footprints in Atlanta

8
 Online Submission ID: 0174

FA
Figure 23: Inset: using a complex footprint, horizontal sections
and plan-edits we are able to create pillars, covered parking and
alcoves respectively. Main: A procedural condo surrounded by pro-
cedural trees
Figure 24: A fully procedural model that renders a street from a
spline. In this case the street was generated by four points defining
the street’s curve. Seed points were grown using another applica-
tion of the skeleton to create the house footprints.

544 (see figure 1). The current model has three million polygons, 5 dif-
545 ferent building types, took 20 minutes modeling time, 10 minutes to
546 compute the procedural extrusions, and 15 minutes to render. Our
547 current limitation is that we were not able to find a rendering in-
548 frastructure to render a few hundred million polygons of a detailed
549 model. We therefore had to omit ornaments and some details of the
550 roof constructions from the designs.

551 5.3 Evaluation

552 We studied several commercial polygonal modeling tools for com-

553 puter graphics and architecture. Some of our insights are given in
554 the additional materials. To replicate the building in Fig. 2 took
KE
555 about seven times longer in Blender than using our system. How-
556 ever, our modeling system is more specialized than most commer-
557 cial polygonal modeling packages. The virtual model of Atlanta is Figure 25: Inset: A thresholded image. Right, Main: Procedural
558 unique and we argue that no existing approach can model a city of extrusions of the image’s outline, with different weights on every
559 comparable (roof) complexity in reasonable time. edge

560 6 Discussion 578 a formal guarantee that the implementation will work correctly on
579 all inputs. It is certainly possible to construct pathological input
561 We discuss differences to previous work and limitations. 580 cases. We hope to make progress in this direction in later work.
562 Interactive procedural modeling: We believe that the combina-
563 tion of interactive and procedural modeling is a significant boost 581 7 Conclusions
564 to artists productivity and a great complement to existing model-
565 ing tools. In some sense our work is complementary to previous 582 The main contribution of this paper is to introduce an interactive
566 work by Lipp et al. [LWW08]. Our approach to encoding proce- 583 procedural modeling tool for complex architectural surfaces. Pro-
567 dural models is very different from the previous shape grammar 584 cedural extrusions can model many complex architectural surfaces
568 approach [MWH∗ 06b, LWW08]. We believe that we are the first to 585 that could not be easily modeled with previous procedural model-
569 provide a solution for the procedural modeling of roofs, procedu- 586 ing tools. Examples are curved roofs, overhanging roofs, dormer
570 ral modeling from arbitrary building footprints, and other complex 587 windows, interior dormer windows, roof constructions with verti-
571 architectural surfaces. However, previous work is better suited for 588 cal walls, buttresses, chimneys, bay windows, columns, pilasters,
572 placing elements on facade planes and we see some potential in 589 and alcoves.
573 combining both approaches in future work.
574 Limitations: We share a limitation with the straight skeleton that 590 References
575 certain smaller edits to the footprint can result in bigger changes to
576 the roof surface. This might lead to an unexpected output. Addi- 591 A ICHHOLZER O., AURENHAMMER F.: Straight skeletons for gen-
577 tionally, the algorithms are difficult to implement. It is hard to give 592 eral polygonal figures in the plane. In Computing and Combina-

9
 Online Submission ID: 0174

632 G AL R., S ORKINE O., M ITRA N., C OHEN -O R D.: iW IRES: An

633 analyze-and-edit approach to shape manipulation. ACM Trans-
634 actions on Graphics (proceedings of ACM SIGGRAPH) 28, 3
635 (2009), to appear.
636 H AVEMANN S.: Generative Mesh Modeling. PhD thesis, TU
637 Braunschweig, 2005.
638 L AYCOCK R. G., DAY A. M.: Automatically generating large
639 urban environments based on the footprint data of buildings. In
640 SM ’03: Proc. of the ACM symposium on Solid modeling and
641 applications (NY, USA, 2003), ACM Press, pp. 346–351.
642 L EGAKIS J., D ORSEY J., G ORTLER S. J.: Feature-based cellular
Figure 26: Using a creative set of profiles, a wide range of archite- 643 texturing for architectural models. In Proceedings of ACM SIG-
cural features can be created. By setting the input in a different 644 GRAPH 2001 (2001), Fiume E., (Ed.), ACM Press, pp. 309–316.
plane, various windows may be extruded.
645 L IU Y., P OTTMANN H., WALLNER J., YANG Y.-L., WANG W.:
646 Geometric modeling with conical meshes and developable sur-
647 faces. ACM Transactions on Graphics 25, 3 (2006), 681–689.
593 torics (1996), Springer-Verlag, pp. 117–126.
648 L IPP M., W ONKA P., W IMMER M.: Interactive visual editing
FA
594 A ICHHOLZER O., AURENHAMMER F., A LBERTS D., G AERTNER 649 of grammars for procedural architecture. ACM Transactions on
595 B.: A novel type of skeleton for polygons. Journal of Universal 650 Graphics 27, 3 (2008), 102:1–10. Article No. 102.
596 Computer Science 12, 12 (1995), 752–761. 651 M ERRELL P., M ANOCHA D.: Continuous model synthesis. In
597 A LIAGA D. G., ROSEN P. A., B EKINS D. R.: Style grammars for 652 SIGGRAPH Asia ’08: ACM SIGGRAPH Asia 2008 papers (New
598 interactive visualization of architecture. IEEE Transactions on 653 York, NY, USA, 2008), ACM, pp. 1–7.
599 Visualization and Computer Graphics 13, 4 (2007), 786–797. 654 M ARVIE J.-E., P ERRET J., B OUATOUCH K.: The FL-system:
655 a functional L-system for procedural geometric modeling. The
600 ATHERTON P. R.: A scan-line hidden surface removal procedure 656 Visual Computer 21, 5 (2005), 329–339.
601 for constructive solid geometry. SIGGRAPH Comput. Graph.
602 17, 3 (1983), 73–82. 657 M LLER P., W ONKA P., H AEGLER S., U LMER A., G OOL L. V.:
658 Procedural modeling of buildings. ACM Transactions on Graph-
603 AURENHAMMER F.: Weighted skeletons and fixed-share decom- 659 ics 25, 3 (2006), 614–623.
604 position. Comput. Geom. Theory Appl. 40, 2 (2008), 93–101.
660 M ÜLLER , W ONKA , H AEGLER , U LMER , G OOL V.: Procedural
605 BAREQUET G., E PPSTEIN D., G OODRICH M. T., VAXMAN 661 modeling of buildings. ACM Transactions on Graphics 25, 3
606 A.: Straight skeletons of three-dimensional polyhedra. CoRR 662 (2006), 614–623.
607 abs/0805.0022 (2008).
663 P RUSINKIEWICZ P., L INDENMAYER A.: The Algorithmic Beauty
608 B LUM H.: A transformation for extracting new descriptors of 664 of Plants. Springer Verlag, 1991.
609 shape. Models for the Perception of Speech and Visual Form
S UGIHARA K., H AYASHI Y.: Automatic generation of 3d building
KE
665
610 (1967), 362–380.
666 models with multiple roofs. Tsinghua Science and Technology
611 C ACCIOLA F.: A cgal implementation of the straight skeleton of 667 13, Supplement 1 (2008), 368 – 374.
612 a simple 2d polygon with holes. In 2nd CGAL User Workshop 668 S TINY G.: Pictorial and Formal Aspects of Shape and Shape
613 (2004). 669 Grammars. Birkhauser Verlag, Basel, 1975.
614 C ABRAL M., L EFEBVRE S., DACHSBACHER C., D RETTAKIS G.: 670 W ONKA P., W IMMER M., S ILLION F., R IBARSKY W.: Instant
615 Structure preserving reshape for textured architectural scenes. 671 architecture. ACM Transactions on Graphics 22, 3 (2003), 669–
616 Computer Graphics Forum (Proceedings of the Eurographics 672 677.
617 conference) (2009).
618 E PPSTEIN D., E RICKSON J.: Raising roofs, crashing cycles, and
619 playing pool: applications of a data structure for finding pairwise
620 interactions. In SCG ’98: Proceedings of the fourteenth annual
621 symposium on Computational geometry (New York, NY, USA,
622 1998), ACM, pp. 58–67.
623 E PPSTEIN D., E RICKSON J.: Raising roofs, crashing cycles, and
624 playing pool: applications of a data structure for finding pairwise
625 interactions. In Proceedings of the 14th Annual Symposium on
626 Computational Geometry (1999), ACM Press, pp. 58–67.
627 F INKENZELLER D.: Detailed building facades. IEEE Computer
628 Graphics & Applications 28, 3 (2008), 58–66.
629 F ELKEL P., O BDRZALEK S.: Straight skeleton implementation.
630 In Proceedings of Spring Conference on Computer Graphics
631 (1998), pp. 210–218.

10
 Online Submission ID: 0174

673 8 Appendix A - Comparable Techniques 699 or different gradients on different edges. However by modifying
700 the algorithm to allow different weights on each edge, figure 12:
674 Extruding a profile along a path, figure 27 simply positions a num- 701 right, the weighted straight skeleton is able to directly specify the
675 ber of profile instances at different points on a path and creates a 702 gradients on a per-edge basis.The straight skeleton defines a profile
676 surface between each adjacent pair. This is a modeling primitive 703 per edge rather than per corner in the case of extrude and loft tools.
677 extensively used in 3D modeling packages. Extrusion provides a
678 simple method for the construction of rooflines, however because 704 Another popular method for geometry creation is the union of sev-
679 the profiles are unable to modify themselves in response to the re- 705 eral polygon solids to create a mass model of the output geometry.
680 mainder of the profiles the are not suitable for creating complex 706 The mathematics of this approach is introduced by CSG [Ath83],
681 architecture, an example is show in figure 27. 707 and has been used by several system since to create urban model-
708 ing tools. Sugihara and Hayashi [SH08] create roofs on orthagonal
709 geometry by unioning roofs after rectangular decomposition. This
710 concept is extended by CGA-Shape [MWH∗ 06a] by the use of a
711 visibility approach to determine which parts of the exterior walls
712 are visible. The combination of simple primitives is not capable of
713 expressing buildings with arbitrary floor plans, although it is possi-
714 ble to guarantee manifold results, and as such these techniques are
715 the most popular in commercial procedural products.

716 8.1 Appendix B - Anchors

FA
Figure 27: The extrude tool in Blender is capable of creating pleas-
ing architecture from a profile and plan (pink), but has no guaran-
tees as to interior (green) or exterior (orange) intersections.

682 A modificaiton to the extrusion algorithm allows different profiles

683 to be used at each point on the plan, figure 28. This 3D loft tool
684 allows more artist interaction, such that when the geometry does
685 intersect it can be manually edited. As when extruding, there are no
686 guarantees that the result will be a manifold, and the manual editing
687 can be quite involved for complex geometries.
KE
Figure 29: The evalution of the outer product of the absolute plan
anchor (a) and the profile anchor (b) gives the feature-location (c).
Note that c may not lie within the bounds of the manifold as it is an
Figure 28: The loft tool is a more advanced version of the extrude absolute anchor.
tool, Left: the unmodified profiles (red) form intersecting geome-
try similar to the extrude tool. Right: by manually modifying the
individual profiles, the intersections can be resolved by an artist. 717 The challenge of the anchors’ placement is to move the anchors
718 after subsequent edits. The manifold of the structure may not reach
719 any given point in space because, for example, the anticipated s-
688 The medial axis skeleton [Blu67] defines a skeleton shape for a 720 plane may have been removed by previous events. Therefore, to
689 given input polygon, every point on the skeleton is interior to the 721 position each of the above features in a manner robust to plan and
690 polygon and equidistant to the two nearest boundary edges. We can 722 profile edits, the user positions a pair of two dimensional anchors,
691 consider the medial axis in 3D, and note that it hasn’t become a 723 figure 29. One lies in the plane of the plan and the other in the plane
692 popular polygon modeling tool as it introduces curved edges into 724 of a profile. If the plan edge still exists at the height defined by the
693 the mesh. 725 profile point, the feature is instanced at that height at the calculated
694 The straight skeleton gives the same results as the medial axis for 726 location on the manifold.
695 convex shapes. It returns a skeleton of only straight edges in the
696 concave case, which is an advantage in a polygonal environment. 727 8.2 Appendix C - Pseudocode
697 The unweighed straight skeleton assigns an single angle for every
698 edge, so is unable to represent changing gradients on each edge

11
 Online Submission ID: 0174

HandleEvent( EventCluster ec ) begin

RemoveAllInactiveEdgesFromCluster( ec );
chainList = BuildEdgeChains( ec );
if chainList.countEdges() < 3 then
return;
foreach chain chainj in chainList do
foreach consecutivePairOfCorners ck , cl in chainj do
AddSkeletonEdge(ec.location, cl );
cl .inactive = true;
foreach consecutive chainj , chaink in chainList do
c1 = firstCornerOfLastEdgeOf chainj ;
c2 = firstCornerOfSecondEdgeOf chaink ;
cnew = createNewCorner( ec.location );
cnew.PrevEdge = c1.NextEdge;
cnew.NextEdge = c2.NextEdge;
InsertCornerBetween( cnew, c1, c2 );
FindEventsForNewCorners();
FindRemoveUnusedEdges();
end
FA
Figure 30: Algorithm for the generalized intersection event.

Resolve begin
ListOfCorner chains = ChainsOfAmbiguousBisectors();
foreach g in chains do
SetOfCorner f = FindHighestPriorityFirstCorners(g);
Boolean inside = ! ( f contains (FirstIn(g)) );
foreach ci in g do
if ci member of f then
if !inside then
inside = false;
AddSkeletonEdge (ci , Raise (ci ));

else
if inside then
inside = false;
AddSkeletonEdge (ci , Raise (ci ));
AddSkeletonEdge(Raise(ci ),Raise
(ci .nextCorner));
KE
Corner f irst = Raise(FirstIn(g));
Corner last = Raise (LastIn(g).nextCorner);
InsertCornerBefore(g, f irst);
InsertCornerAfter(g, last);
RemoveCorners(g);
f irst.nextEdge = FindOneEdge(f );
last.prevEdge = FindOneEdge(f );
f irst.nextCorner = last;
last.previousCorner = f irst;
end
FindHighestPriorityEdges begin g
if VolumeMaximizing then
return members of g with largest angle;
else if VolumeMinimizing then
return members of g with smallest angle;
end
Raise begin Corner ci
if cache contains ci then
return cache.get(ci );
raised = new Corner ( Collide ( sweepplane, ci .previousEdge,
ci .nextEdge ) );
return raised;
end

Figure 31: Pseudo-code for the resolving the ambiguous case. Cal-
culates a geometrically consistent solution to the ambiguity given
a chain of corners that start edges which become coincident and
adjacent at a the sweep plane’s height.

12