A GML shape grammar for semantically enriched 3D building models

13
Technical Section A GML shape grammar for semantically enriched 3D building models Bernhard Hohmann a , Sven Havemann a, , Ulrich Krispel a , Dieter Fellner a,b a Institute of Computer Graphics and Knowledge Visualization (CGV), Graz University of Technology, Inffeldgasse 16c/II, 8010 Graz, Austria b Fraunhofer IGD & Darmstadt University of Technology, Fraunhoferstrae 5, 64283 Darmstadt, Germany article info Keywords: Shape grammars Architectural buildings Shape modeling 3D-reconstruction Shape semantics Generative modeling abstract The creation of building and facility models is a tedious and complicated task. Existing CAD models are typically not well suited since they contain too much or not enough detail; the manual modeling approach does not scale; different views on the same model are needed, and different levels of detail and abstraction; and finally, conventional modeling tools are inappropriate for models with many internal parameter dependencies. As a solution to this problem we propose a combination of a procedural approach with shape grammars. The model is created in a top-down manner; high-level changeability and re-usability are much less of a problem; and it can be interactively evaluated to provide different views at runtime. We present some insights on the relation between imperative and declarative grammar descriptions, and show a detailed case study with facility surveillance as a practical application. & 2010 Elsevier Ltd. All rights reserved. 1. Introduction Three-dimensional building and facility models are becoming ever more important with the widespread availability of building information systems. They are the basis for home automation, sensor networks, technical supervision and inspection, building surveillance systems as well as all kinds of maintenance tasks in the context of building lifecycle management. A central problem is scalability: Especially for complex facilities, the creation of appropriate 3D models is an extremely tedious task. Conventional interactive modeling software a la 3D House Designer, or general purpose software such as Maya or 3D Studio Max is suitable only for comparably small facilities. For a surveillance project we needed a 3D model of a sufficiently complex facility, four university buildings (cf. Fig. 1). We made the first attempt for interactive reconstruction using Google SketchUp. The biggest problem we encountered was that errors early in the modeling process can practically not be corrected at all later on. If, e.g., the floor height must be changed, essentially the whole construction needs to be re-done. 1.1. Existing architectural software is inappropriate Another option we thought of was to use architectural software such as ArchiCAD, Autodesk Revit or Architectural Desktop. However, this software is targeted at construction rather than reconstruction, i.e., reverse engineering of buildings. But even these so-called ‘‘associative models’’ are low-level since almost all of the geometry is constructed manually. Only certain parameter associations are kept consistent automatically, i.e., when dimensions of the model are changed this is (somehow) propagated to sub-parts. Architectural software cannot easily be integrated into, e.g., a surveillance application. But when a building model is exported, it loses much of its semantics. The CAD export contains (too) detailed geometry of walls, doors, etc., but there is no geometry for rooms and corridors that are just empty space. But this space is just where people live and it is therefore the main unit for surveillance. One viable alternative might be exporting the CAD model to a format with rich semantics such as IFC International Alliance for Interoperability [2]. It is apparently the upcoming open exchange standard for building semantics, and it supports labels for rooms, corridors, etc. 1.2. Needed: procedures and complex parameter dependencies The focus of our work, however, was on creating a sustainable building model with a minimum of initial effort in terms of taking manual measurements. The model should allow replacing any- time later guessed values by accurate measurements taken with our laser range finder (Fig. 2). So the idea was to start with a Contents lists available at ScienceDirect journal homepage: www.elsevier.com/locate/cag Computers & Graphics 0097-8493/$ - see front matter & 2010 Elsevier Ltd. All rights reserved. doi:10.1016/j.cag.2010.05.007 Corresponding author. E-mail addresses: [email protected] (B. Hohmann), [email protected] (S. Havemann), [email protected] (U. Krispel), [email protected] (D. Fellner). URLS: http://www.cgv.tugraz.at/hohmann (B. Hohmann), http://www.cgv. tugraz.at/havemann (S. Havemann), http://www.cgv.tugraz.at/krispel (U. Krispel), http://www.cgv.tugraz.at/fellner, http://www.igd.fhg.de/igd-a0/staff/fellner (D. Fellner). Please cite this article as: Hohmann B, et al. A GML shape grammar for semantically enriched 3D building models. Computers and Graphics (2010), doi:10.1016/j.cag.2010.05.007 Computers & Graphics ] (]]]]) ]]]]]]

Transcript of A GML shape grammar for semantically enriched 3D building models

Computers & Graphics ] (]]]]) ]]]–]]]

Contents lists available at ScienceDirect

Computers & Graphics

0097-84

doi:10.1

� Corr

E-m

s.havem

d.fellne

URL

tugraz.a

http://w

(D. Felln

PleasGrap

journal homepage: www.elsevier.com/locate/cag

Technical Section

A GML shape grammar for semantically enriched 3D building models

Bernhard Hohmann a, Sven Havemann a,�, Ulrich Krispel a, Dieter Fellner a,b

a Institute of Computer Graphics and Knowledge Visualization (CGV), Graz University of Technology, Inffeldgasse 16c/II, 8010 Graz, Austriab Fraunhofer IGD & Darmstadt University of Technology, Fraunhoferstrae 5, 64283 Darmstadt, Germany

a r t i c l e i n f o

Keywords:

Shape grammars

Architectural buildings

Shape modeling

3D-reconstruction

Shape semantics

Generative modeling

93/$ - see front matter & 2010 Elsevier Ltd. A

016/j.cag.2010.05.007

esponding author.

ail addresses: [email protected] (B. H

[email protected] (S. Havemann), u.krispel@

[email protected] (D. Fellner).

S: http://www.cgv.tugraz.at/hohmann (B.

t/havemann (S. Havemann), http://www.cgv.

ww.cgv.tugraz.at/fellner, http://www.igd.fhg

er).

e cite this article as: Hohmann B, ehics (2010), doi:10.1016/j.cag.2010.

a b s t r a c t

The creation of building and facility models is a tedious and complicated task. Existing CAD models are

typically not well suited since they contain too much or not enough detail; the manual modeling

approach does not scale; different views on the same model are needed, and different levels of detail

and abstraction; and finally, conventional modeling tools are inappropriate for models with many

internal parameter dependencies. As a solution to this problem we propose a combination of a

procedural approach with shape grammars. The model is created in a top-down manner; high-level

changeability and re-usability are much less of a problem; and it can be interactively evaluated to

provide different views at runtime. We present some insights on the relation between imperative and

declarative grammar descriptions, and show a detailed case study with facility surveillance as a

practical application.

& 2010 Elsevier Ltd. All rights reserved.

1. Introduction

Three-dimensional building and facility models are becomingever more important with the widespread availability of buildinginformation systems. They are the basis for home automation,sensor networks, technical supervision and inspection, buildingsurveillance systems as well as all kinds of maintenance tasks inthe context of building lifecycle management. A central problem isscalability: Especially for complex facilities, the creation ofappropriate 3D models is an extremely tedious task. Conventionalinteractive modeling software a la 3D House Designer, or generalpurpose software such as Maya or 3D Studio Max is suitable onlyfor comparably small facilities.

For a surveillance project we needed a 3D model of asufficiently complex facility, four university buildings (cf. Fig. 1).We made the first attempt for interactive reconstruction usingGoogle SketchUp. The biggest problem we encountered was thaterrors early in the modeling process can practically not becorrected at all later on. If, e.g., the floor height must be changed,essentially the whole construction needs to be re-done.

ll rights reserved.

ohmann),

cgv.tugraz.at (U. Krispel),

Hohmann), http://www.cgv.

tugraz.at/krispel (U. Krispel),

.de/igd-a0/staff/fellner

t al. A GML shape gramma05.007

1.1. Existing architectural software is inappropriate

Another option we thought of was to use architecturalsoftware such as ArchiCAD, Autodesk Revit or ArchitecturalDesktop. However, this software is targeted at construction ratherthan reconstruction, i.e., reverse engineering of buildings. Buteven these so-called ‘‘associative models’’ are low-level sincealmost all of the geometry is constructed manually. Only certainparameter associations are kept consistent automatically, i.e.,when dimensions of the model are changed this is (somehow)propagated to sub-parts. Architectural software cannot easily beintegrated into, e.g., a surveillance application. But when abuilding model is exported, it loses much of its semantics. TheCAD export contains (too) detailed geometry of walls, doors, etc.,but there is no geometry for rooms and corridors that are justempty space. But this space is just where people live and it istherefore the main unit for surveillance. One viable alternativemight be exporting the CAD model to a format with richsemantics such as IFC International Alliance for Interoperability[2]. It is apparently the upcoming open exchange standard forbuilding semantics, and it supports labels for rooms, corridors,etc.

1.2. Needed: procedures and complex parameter dependencies

The focus of our work, however, was on creating a sustainable

building model with a minimum of initial effort in terms of takingmanual measurements. The model should allow replacing any-time later guessed values by accurate measurements taken withour laser range finder (Fig. 2). So the idea was to start with a

r for semantically enriched 3D building models. Computers and

Fig. 1. (top) University facility: four buildings, three floors, 405 rooms. Photo: Bing Maps, Bird’s Eye view [1]. (bottom) Reconstruction attempt from photographs using

Google SketchUp, with obvious scalability problems.

Fig. 2. Leica Disto laser range finder with 1–2 mm precision over 60 m.

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]]2

model that may be geometrically inaccurate but is qualitatively

correct, meaning that all of the major building features (walls,doors, windows, etc.) are present. It should be possible togenerate them quickly by just instantiating parametrictemplates. High-level changeability was to be granted by theability to express any sort of parameter dependencies explicitly.For example, in our building a sequence of rooms along a corridorall have the same height and width, but the room length (alongthe corridor) can vary. So it needs to be possible to define themodel in such a way that only one parameter per room isrequired, namely its length, and only a single width value percorridor, which then each room refers to as its width parameter.

We found also more complex dependencies that require, e.g.,changing the reference frame when a measurement does notcorrespond directly to a parameter. There are surprisingly manypossible parametrizations of a shape as simple as a box: pmin,pmax; pmid, (rx, ry, rz); or just the midpoint of a bottom edge, andorientation and extents are inherited from higher levels. Thisexample shows that no limited number of pre-defined parame-trizations can ever be sufficient; instead it must be possible tore-parameterize the boxes whenever needed. A more involvedexample is given in Section 5.3.

Please cite this article as: Hohmann B, et al. A GML shape grammarGraphics (2010), doi:10.1016/j.cag.2010.05.007

1.3. Main contributions

fo

Simple but powerful split grammar formalism: Our GML shapegrammar toolkit develops considerable expressiveness out ofabout two dozen functions.

� Unified view on grammars and imperative modeling: Grammars

are typically perceived as declarative, but we use them withinan imperative paradigm. This permits us to overcome someinherent limitations.

� Practical reconstruction of a complex facility with interiors: The

original motivation was to rapidly create a complex facilitymodel that should still be sustainable.

� A solution to the problem of propagating reference frames: In

many cases measurements do not directly correspond tomodel parameters. We present a simple, general solution tothis problem.

2. Related work

Since ancient times complex architectural buildings weredesigned in a top-down, coarse-to-fine manner: The overallstructure is divided into sections and floors, which are furtherrefined into rooms, hallways, stairways, etc. A more formal viewon this process suggests a grammar-based approach, whichdirectly leads to the so-called shape grammars. They were firstintroduced by Stiny and Gips as early as 1972 [3]. Their verygeneral idea was to simply replace a shape (or part of a shape)that carries a label by one or more (usually smaller) shapescarrying other labels. This hierarchical replacement process isspecified by a finite set of shape grammar rules.

Many variations to this basic idea have been developed, fromnon-determinism over conditional rules to L-systems [4], e.g., for

r semantically enriched 3D building models. Computers and

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]] 3

plants. In architecture, shape grammars were a long time usedonly as theoretical research tool. New interest was triggered byWonka et al. in 2003 who introduced split grammars [5]. Theyformed the basis for the CGA Shape grammar system for theprocedural modeling of buildings from Muller et al. [6]. Splitgrammars are specialization of shape grammars. The main shapebuilding block is a box (a scope), which can be split into smallerboxes along any of the three principal axes.

Our system borrows the scope concept from CGA Shape, butinstead of a context-free grammar we use a formally equivalentbut more flexible procedural, function-based description: Insteadof replacing an object by a sequence of objects, we ‘‘replace’’ anoperation by a sequence of operations (Section 3.2.4). CGA Shapewas further developed into a commercial tool, the CityEngine [7],which marks the state of the art in shape grammars. However, itfocuses more on the randomized generation of large scale citymodels than on detailed buildings; the CityEngine does notconsider interiors at all. Another difference is that the CityEngineuses scopes mainly as non-terminal symbols, terminal rulesreplace scopes by pre-modeled parts loaded from a file. Oursystem leaves out this final replacement.

In the context of large scale city models, an important researchfocus is the reconstruction of detailed facades. The grammarapproach was very inspiring for solving inverse problems, aswitnessed by a number of recent contributions. CGA Shape wasused for image-based reconstruction of very regular, repetitivefacades, which can be automatically reconstructed even from asingle orthophoto [8]. The goal of our evolving system, however, isto reconstruct 80% of a whole city from massive input data [9].Koutsourakis et al. presented another single view reconstructionapproach for facades of a few different styles using orthophotosand Markov random fields (MRF) [10]. Xiao et al. proceed in asimilar fashion and obtain impressive results using structure frommotion [11]. Interestingly, however, they do not need anygrammars. Instead they make the strong assumption thatbuildings are composed of block geometry, which they obtainfrom partitioning an orthographic depth map into rectangularregions.

One fundamental problem of grammars is to deal withexceptions in a regular structure. Lipp et al. have introducedsemantic locators to allow selecting a column of windows even iffloors were split first [12]. With exact locators they also tackle thepersistency problem, i.e., how to remember local changes in asubtree if the tree above is interactively changed. They alsopresent an interactive system to create and edit a shape grammarfor building exteriors without manual coding, which is thedrawback of all scripting-based systems such as CGA Shape. Oursystem is also scripting-based, but we offer tools for semi-interactive inspection of the grammar evaluation. Our goal is aswell to create grammar descriptions (a grammar script) notthrough scripting as we did for this paper, but either interactivelyin 3D or completely automatically. Unlike Lipp et al., however, wedo not want to define only replacement rules, but also imperativeprocedures interactively—because replacement rules alone areapparently not sufficient.

In fact there is a recent trend to combine grammar-basedapproaches with other modeling methodologies; grammarsbecome one tool among others. Larive et al. for instance createthe basic building geometry by extruding an arbitrarily shapedground polygon (as does the CityEngine). A simplified splitgrammar is used only for detailing the facade in a 2.5D fashionusing a simplified set of five rules: two repetition rules (grid/list),two position rules (extrude/border) and one terminal rule fortexturing [13].

But are context free grammars really sufficient for formalizingarchitecture? Already in 1965, Christopher Alexander noted in his

Please cite this article as: Hohmann B, et al. A GML shape grammaGraphics (2010), doi:10.1016/j.cag.2010.05.007

famous article that A city is not a tree [14]—and his argumentsequally apply to buildings. Most shape grammars are comple-mented by another language for scripting. Certain tasks (calcula-tions, conditionals, function calls) are easier to formulate asprocedures than as replacement operations. The relation betweendeclarative grammars and imperative scripting is not completelyclear; but combining them seems indispensable (see Section 4).

Complex classical facades exhibit structures that are difficultto generate by hierarchical replacement. Cornices and ledges ‘‘runaround’’ a building, connecting many different facade elements. Inthat case, a procedural approach is more suitable, as demon-strated by Finkenzeller [15]. His floor plan modules are composedof convex polygons, from which an outline is computed thatserves as path for extruding a profile that is also generatedprocedurally using Turtle graphics.

One goal of any procedural shape description—be theyimperative or declarative—is the search for the minimum

description length (MDL). Aliaga et al. for instance focus on thedetection of repetitive structures and patterns to automaticallygeneralize, e.g., an ABABABA pattern to (AB)*A in order to transferthe style of one building to another [16]. Ripperda et al. [17] usethe reversible jump Markov chain Monte Carlo method (rjMCMC) tofind the best description in the MDL sense. Consequently, theirgrammar also has a mirror operator (not present, e.g., in theCityEngine) because symmetries are very efficient in reducing thedescription length. Interestingly, they use a functional infixnotation for their grammar, showing that it is not necessary toformulate a (context free) grammar using replacement rules, butreplacement rules can generally be understood as function calls.This bridges the gap between imperative and declarativedescriptions, which we exploit for our (imperative) approach.

3. GML based shape grammar

This section introduces an efficient formalism for formulatingshape grammars using the Generative Modeling Language (GML)from Havemann [18]. It is an imperative programming language,but as a stack-based language it is particularly well suited asnotation for context-free grammars.

3.1. GML briefly explained

GML follows the stream of tokens concept, i.e., a GML programconsists of a sequence of tokens that are evaluated one afteranother. Tokens either contain data, which are put on the stack(the operand stack), or processing instructions (operators andfunction calls), which are executed. An operator pops its inputparameters from the stack, processes them, and pushes the resultback on the stack.

The add operator for instance pops two numbers (or vectors),adds them, and pushes their sum. The def operator performs avariable assignment. It pops a literal name (preceded by a slash)and a token from the stack and enters it in the current dictionary;it pushes no results. When an executable name (i.e., without aslash) is executed, the interpreter looks it up and executes thetoken found, which may be a function. Name lookup uses acentral dictionary stack; a dictionary is a list of (nameID,token)pairs, the topmost dictionary on the dictionary stack is thecurrent dictionary, into which the def operator also writes. Thisway the infix assignment x¼(1+2) � (5+6) can be expressed inGML as

=f faddg def

=x 1 2 f 5 6 f mul def

r for semantically enriched 3D building models. Computers and

1 5 scope2 −5 /X subdivide3 terminal−box4 terminal−void5 −3 /Y subdivide6 terminal−void7 terminal−box8 terminal−void9 terminal−void

10 terminal−box

Fig. 3. GML shape grammar code example 1: illustrates the successive subdivision

of a scope, using relative subdivide. The indentation is important to keep track of

the hierarchy level, which is not enforced automatically.

1 /A { terminal−box } def2 /B { set−material terminal−box } def3 /Frame { [ 0.05 −1 0.05 ] /Y split4 A5 [ 0.05 −1 0.05 ] /X split6 A7 12 B8 A9 A

10 } def

11 5 scope12 0.23 /X subdivide13 { Frame } repeat

Fig. 4. Grammar rules naturally correspond to GML functions. This example uses

an absolute subdivide; the split operator expects on the stack a scope, an array of

absolute ð40Þ and relative ðo0Þ distances, and a split direction.

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]]4

Arrays are created by the ] operator which searches on the stacktop-down for the first [ and creates an array from the tokens inbetween. Functions are created similarly but using { and }; sofunctions are just executable arrays. GML is a functional languagein the sense that functions are first level citizens and are oftencreated at runtime; however, it does not enforce any referentialintegrity. Instead, many operators do have side effects, i.e.,manipulate internal data structures. GML inherits this propertyfrom Adobe PostScript [19], to which it is syntactically almostidentical. The only language extensions are registers, and pathexpressions to navigate through dictionary hierarchies. And ofcourse, GML is for 3D rather than 2D, so it has no typesettingoperators but many operators for shape design. For moreinformation refer to the GML homepage [20] that also links tothe GML wiki with descriptions and examples for all operators.

3.2. The GML shape grammar

When evaluating a grammar, the replacement process pro-ceeds by successively applying replacement rules to a startsymbol. For deterministic context-free grammars, the replace-ment process forms a tree, which can in principle be traversed inany order. When interpreting the rules as functions, the call graphcorresponds to a depth-first evaluation. This is typically imple-mented using a stack that contains the unfinished calls (‘‘open

scopes’’). Since GML is stack-based, it is natural to push the openscopes in-order on a scope stack (which is separate from thenormal operand stack). The last pushed scope is the current scope,which is the next scope to be processed.

This section introduces the main functions of the shapegrammar toolkit. The next section will show how to apply themin a practical reconstruction.

3.2.1. The basic split operations

The shape grammar toolkit is a library of GML functions tocreate, modify, and terminate scopes (i.e., boxes). Fig. 3 shows afirst example. The scope function pops a material ID, creates anew scope with default position (origin) and unit size, and pushesit on the scope stack to become the current scope.

The subdivide function expects a number a and a split directiond (in positive or negative X, Y, or Z direction). It splits the currentscope s into a number of smaller scopes: In case a is positive, itproduces as many sub-scopes as possible that are not smallerthan a in direction d, and have the same extent as s in the otherdirections. In case a is negative, s is split into jaj equal parts (a isrounded to the nearest integer). In any case the sub-scopes are avolumetric partition of s (containment property).

Instead of subdividing it, the current scope can be mapped toempty space using terminal-void, or to a solid box using terminal-box; a third alternative is just to leave it open. In grammarterminology, terminal symbols are those to which no furtherreplacement rule applies. Consequently, the current scope ispopped from the scope stack, and the next open scope becomesthe current one.

The indentation in the code in Fig. 3 reflects the subdivisionhierarchy for a better overview. The indentation is essential forusers to keep track of the open scopes: Line 2 produces five openscopes, and after line 5, again five scopes are open (three wereconsumed, three are newly produced, another two remain). Notethat we have deliberately chosen not to introduce a closingstatement; deleting, e.g., line 6 will mess up the model. Althoughthis seems brittle, it is in practice surprisingly easy to debug, aswe can stop the grammar execution anywhere (see Section 3.4).So we decided not to use a closing statement which would makethe code safer but less elegant.

Please cite this article as: Hohmann B, et al. A GML shape grammarGraphics (2010), doi:10.1016/j.cag.2010.05.007

3.2.2. Defining grammar rules in GML

The replacement rules are in fact just ordinary GML functiondefinitions. From a formal point of view, this can be seen as asimple syntax conversion:

for semantically enr

T - P Q R

traditional notation for replacement rules T f P Q R g def GML notation for replacement rules =

Whenever the GML interpreter encounters during execution theexecutable name T, it looks it up and executes the object found, inthis case an executable array (i.e., the function). So executing T isexactly equivalent to executing P, then Q and R. In that sense, GMLhas a built-in replacement property.

Note that grammar rules, as normal functions, may operate notonly on the scope stack, but also on the operand stack. In theexample in Fig. 4, rule B first calls the set-material function thatexpects an integer as material ID on the operand stack to modifythe current scope; other possible scope modifications includetranslation, scaling, and extrusion. B ‘‘inherits’’ the signature ofset-material: As set-material expects an integer on the operandstack, so does B (line 7).

The split operator used in the Frame rule is the second wayof partitioning a scope into sub-scopes. It expects an arrayof numbers specifying the extents of the sub-scopes in thesplit direction. Positive numbers mean absolute sizes, whilenegative numbers mean relative sizes. Thus, [�1 �2] /X splitand [�2 �4] /X split both produce the identical two sub-scopes,the current scope being twice as large in X than the next-currentscope.

Lines 1–10 only define rules; lines 11–13 create the model. Asthe scope from line 11 has unit size, the subdivide of 0.23

iched 3D building models. Computers and

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]] 5

produces four equally sized scopes of size 0.25. subdivide has theadditional property that it leaves the number of generated sub-scopes on the stack. This is handy for the GML operator repeatwhich expects an integer n and an object x (typically a function)on the stack, and executes x n times. Note, however, that x shouldnot leave any open scopes on the scope stack, therefore the Framerule terminates the scope.

3.2.3. Grammar comparison: GML vs. CityEngine

The CGA Shape grammar of the CityEngine [7] uses a differentsyntax but provides the same functionality. Fig. 5 shows theexample from Fig. 4 in CityEngine syntax. Relative distances aredenoted here using a tilde � , repetitions using the asterisk �.

3.2.4. A shape grammar for box frames

This example is a bit more complex and provides more insightto the replacement process (Fig. 6). Seven rules are defined, thenthe model is built in line 8 by applying rule C to the start scope.The image below the code suggests a decompositional view on therules in a top-down order: C is composed of E,D,E stacked on topof each other, D in turn is made of F, void, F, and so on. All in allthe replacement sequence in the example is as follows (discardingthe split directions), finally resulting in filled boxes and

1 A→ color(Turquoise)2 B→ color(Black)

3 Frame →4 split (y){ 0.05 : A5 | ˜1 : split (x){ 0.05 : A6 | ˜1 : B7 | 0.05 : A }8 | 0.05 : A }

9 StartScope →10 split (x){ { ˜0.23 : Frame }∗ }

Fig. 5. CityEngine code example. Illustrates how the GML shape grammar example

from Fig. 4 looks in CityEngine syntax.

1 /A { terminal−box } def2 /B { terminal−void } def3 /C { [ 0.1 −1 0.1 ] /X split E D E } def4 /D { [ 0.1 −1 0.1 ] /Y split F B F } def5 /E { [ 0.1 −1 0.1 ] /Y split G F G } def6 /F { [ 0.1 −1 0.1 ] /Z split A B A } def7 /G { [ 0.1 −1 0.1 ] /Z split A A A } def8 7 scope (2,1,1) scale C

Fig. 6. GML replacement rules: the modeling process can be understood both as

replacement (top-down decomposition) and as assembly (bottom-up). Note the

orientation of the coordinate axes.

Please cite this article as: Hohmann B, et al. A GML shape grammaGraphics (2010), doi:10.1016/j.cag.2010.05.007

empty space:

C - E D E

- G F G F B F G F G

- A A A A B A A A A

A B A B A B A

A A A A B A A A A

The process can also be understood bottom-up: G splits the scopein z-direction in two fixed sized outer parts and an inner part,which are then all replaced by a box (rule A). Rule F splits thesame way as G, but it deletes the inner part. Rule E combines Fand G very much like the Frame rule from Fig. 4. The onlydifference is that G explicitly splits off the corners of the frame,resulting in four more scopes than in Frame. Also note that rules Dand E split in Y-direction and rule C in X-direction.

Another important shape function, especially for architecture,is extrusion (extend tool in Table 1). One of the most obviousexamples is window sills, as they are sticking out of the mainplane of the facade. Without extrusion one would have to peel offa layer of the facade in every instance of the facade except thewindow sills (cf. Fig. 7). This is a fundamental problem of allapproaches based on recursive refinement.

Table 1The shape grammar infrastructure functions, contained in Shape-GrammarTools.

init -

finish -

materiallD:Int scope -

s:Scope scope-copy - t:Scope

pop-scope - c:Scope

s:Scope push-scope -

[s_i :Scope] append-scopes -

current-scope - c:Scope

offsetvec: P3 move -

factor: Num scale -

transvec: P3 translate -

d:Num / dir:Name extend -

width:Num / dir:Name split -

[ width_i:Num ] / dir:Name subdivide -

terminal-void -

terminal-box -

materiallD:Int set-material -

/key:Name value:(Any) label -

sd -

s:Scope / dir:Name d: Num reldist -

The /dir name can be one of /X, /Y, /Z, /NX, /NY, /NZ to denote positive and negative

scope axis directions. Note that the signature is only informal, for instance the type

Scope formally is a GML Dictstack object. Functions like terminal-box have no

effect on the operand stack because they operate on the scope stack.

Fig. 7. Windows with extruded sills. Without extrusion, it would be necessary to

split off a layer of the facade in every scope except for the window sills.

r for semantically enriched 3D building models. Computers and

1 usereg2 pop−scope !scope3 :scope begin4 materials mat get setcurrentmaterial

5 [ p000 p100 p110 p010 ] 3 poly2doubleface6 0 dz getY dz getX sub 5 vector3 extrude pop

7 / active 0 def

8 end

Fig. 9. Code of the terminal-box function that terminates the current scope. It

creates a double-sided quad and extrudes it to obtain a box.

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]]6

3.3. Some implementation details of the toolkit

The implementation of the scope and scope-copy functions isshown in Fig. 8. GML dictionaries can be used very much likeclasses in object-oriented programming. They can contain bothdata and functions and it is even possible to replace at runtimedata by functions; in that sense, dictionaries are dynamic classes.Each scope is represented by one dictionary and a dictstack object.The dictstack is a copy of its parent dictstack, and the newdictionary is appended to become its top (current). Likedictionaries, dictstack objects can be put on the central GMLdictionary stack using the begin operator. This makes itparticularly easy to propagate all sorts of semantic attributesthrough the grammar, as explained in detail in Section 5.4.

The implementation of the terminal-box function is shown inFig. 9. The pop-scope function pops the current scope from thescope stack and pushes it on the operand stack. After the box iscreated, the scope is set to inactive, as it was consumed by aterminal symbol.

Since GML as a stack-based language is well suited forevaluating context-free grammars, the GML shape grammartoolkit is indeed quite lean. The whole grammar infrastructureconsists of only around 20 functions (see Table 1) and fits in 11 kBof GML code. The functions that are not explained in detail herewill hopefully be clear from the context.

1 /scope {2 usereg !mat3 dict dictstack !scope

4 :scope begin

5 / self :scope def

6 /pt (0,0,0) def

7 /ex (1,0,0) def8 /ey (0,1,0) def9 /ez (0,0,1) def

10 /dx (0,1) def11 /dy (0,1) def12 /dz (0,1) def

13 /mat :mat def14 / active 1 def

15 end

16 scope−array :scope append17 :scope push−scope18 } def

19 /scope−copy {20 usereg !scope21 :scope dictstack−copy !newscope22 dict :newscope dictstack−begin

23 :newscope /self :newscope put24 :newscope /active 1 put25 :newscope26 } def

Fig. 8. The scope and scope-copy functions are the basis of the GML shape

grammar. A scope consists mainly of a coordinate frame and three intervals

(represented as 2D points). The !x and :x are the syntax to set and get named

registers (local variables). The begin operator simply pushes a dictionary (or

dictpath) on the dictionary stack, which is used for name lookup. The def operator

writes into the topmost dict on the GML dictionary stack. In case this is itself a

dictstack object, it writes into the topmost dictionary of the dictstack.

Fig. 10. Interactive code development. Code execution is halted by introducing a

stop function. The open scopes are shown in color (current scope is red). (For

interpretation of the references to color in this figure legend, the reader is referred

to the web version of this article.)

Please cite this article as: Hohmann B, et al. A GML shape grammarGraphics (2010), doi:10.1016/j.cag.2010.05.007

3.4. Code development in practice

A fundamental problem for all scripting-based proceduralmodeling approaches is that a text editor is not the ideal interfaceto 3D modeling. We deal with this problem by using aninteractive IDE with 3D window next to the code window. Byinserting a stop command, the recursive replacement is halted,and the open scopes on the scope stack are shown in differentcolors according to their stack position (see Fig. 10).

4. A unified higher-level view

GML is an imperative language whereas grammars are oftendescribed as belonging to the declarative paradigm. This subtledifference often leads to confusion on what exactly the differencein expressiveness is.

Formally, the rules of a grammar specify how one symbol isreplaced by other symbols (including the empty symbol). Shapegrammars, as originally described by Stiny in [3], are context-free.The general concept is that a ‘‘larger’’ shape is replaced by acollection of sub-shapes. When the shapes carry a symbol, thisprocess can be formally described as symbol replacement processwhere the geometric operations are, strictly speaking, side effects.The grammar itself has no side effect, i.e., the sub-triangles of aSierpinski triangle are completely independent and ignorant oftheir (geometric) neighbors.

Split grammars, most notably CGA Shape, are a special case ofshape grammars, in that the geometry representation is ann-dimensional rectangular box, a scope, that carries the symbol.The main replacement rules are split, subdivide (repeat), andcomponent split. CGA Shape actually breaks the grammar

for semantically enriched 3D building models. Computers and

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]] 7

formalism in that it deliberately introduces side effects: Ruleexecution can be influenced by geometric reasoning, e.g., todetermine whether the neighboring house is too close to insertwindows into a wall of a building. The classical rule replacementsyntax was extended to accommodate, e.g., for geometricconditions and statistical rule selection.

The GML shape grammar approaches the problem from adifferent side, as the grammar is in fact just an ordinary GMLprogram. The notation, e.g., in Fig. 6 and in Section 3.2.3 waschosen such that it resembles grammar rules. The truth, however,is that GML as a stack-based language is just ‘‘by coincidence’’well suited to express shape grammars that typically also use astack for evaluation; in this case, the execution stack of the GMLinterpreter. A GML shape grammar belongs to a specific class ofGML programs, namely that perform strict in-order processing ofthe symbols (scopes) on the scope stack. All introductoryexamples are of this type.

The great advantage is now that we can gradually introduceelements from more general GML programs to realize geometricqueries (Section 5.3) or re-ordering. Consider for example a wallrule that is supposed to leave a symbol for the window to beprocessed by a subsequent rule. Strict in-order processing wouldrequire defining a rule for the window before executing the wallrule. This is a problem (and a limitation of CGA Shape) whendifferent window styles are to be used (see Fig. 11).

1 /Void { terminal−void } def2 /Box { set−material terminal−box } def

3 /Window−A {4 0.1 0.5 5 Frame5 [ −2 −1 ] /Z split6 0.05 0.35 9 Frame Void7 0.05 0.15 9 Frame Void8 } def

9 /Window−B {10 0.1 0.5 5 Frame11 [ −1 −1 ] /X split12 0.05 0.15 9 Frame Void13 0.05 0.15 9 Frame Void14 } def

15 /Frame {16 usereg !material !depth !width

17 1 :depth 1 vector3 !dv

18 [ :width −1 :width ] /X split19 :dv scale :material Box20 [ :width −1 :width ] /Z split21 :dv scale :material Box22 pop−scope !center23 :dv |scale | :material Box24 :dv scale :material Box

25 :center push−scope26 } def

27 3 scope (0.8,0.3,2.2) scale Wall Window−A28 3 scope (0.8,0.3,2.2) scale (1,0,0) move Wall Window−B

Fig. 11. Re-ordering of symbol processing. The pop-scope function transfers a

scope from the scope stack to the normal GML operand stack, the push-scope

transfers it back. So the Frame rule can leave the frame center as open scope for

further processing, e.g., by other Frame rules. The Wall rule (not shown) proceeds

similarly. This way the center can be processed in different ways without changing

the Frame rule, or defining a Center rule beforehand. This is an important

advantage in rule modularization over usual shape grammars that evaluate strictly

in-order.

Please cite this article as: Hohmann B, et al. A GML shape grammaGraphics (2010), doi:10.1016/j.cag.2010.05.007

An inherent limitation of the GML shape grammar approach is,of course, that context-sensitive grammars are much simpler todescribe with rules like ABA - XYZYX. This is not so easy to mapto GML. However, it is currently an open question how ‘‘general’’GML shape grammars can be without breaking the grammar ideacompletely; and whether the expressiveness of context-sensitivegrammars can be reached conveniently. Interestingly, most shapegrammar languages are context-free.

5. Sample reconstruction

To demonstrate that our grammar formalism is also useful inpractice, a modern university building complex was chosen as ause case. The whole complex consists of four buildings which lookvery similar at first glance (cf. Fig. 1). Furthermore, mostconstructional elements are box-like shapes. Thus, it seemed tobe the perfect example to try out and demonstrate the advantagesof our shape grammar.

As we start the modeling process with one big volume, we firsthave to find the super structures which span over the wholecomplex. Then further regularities have to be identified. For thatpurpose we used the available inaccurate floorplans of thebuildings, e.g., Fig. 13(a). The first question is where to putthe major splits through the building. We chose to first split apartthe four buildings, and then partitioned them into segments.Fig. 13(b) shows the model of the whole facility consisting of fourconnected buildings. As can easily be seen on the floorplan, inFig. 13(a), the five bridges connecting the four buildings split thebuildings into six segments. These segments are denoted asA, . . . ,F. The smaller parts between them are the bridge segments.

To observe the splitting process more clearly, the evaluation ofthe shape grammar was stopped at levels 2, 4, 6, 9, 11 of the 16cbuilding (Fig. 12). The building is first split into four segments,C, . . . ,F, which are separated by three bridge segments. Thesegments are split into north, open space, and south. These two

Fig. 12. The building 16c at different split levels L, i.e., the depth in the split

hierarchy. (a) L ¼ 2, (b) L ¼ 4, (c) L ¼ 6, (d) L ¼ 9, (e) L ¼ 11.

r for semantically enriched 3D building models. Computers and

Fig. 13. (a) Floorplan of the second floor of the four-building university complex, (b) model of the building complex.

Fig. 14. (a) The building 16c, (b) segment E, one of the four segments of 16c, (c) the second floor of the segment.

Fig. 15. The southern side of the floor shown in Fig. 14(c). In this exploded

illustration it is easy to see how this part is split into office and wall slices.

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]]8

consecutive splits yield the split level 2 in Fig. 12(a). Next thebuilding is split into floors. At level 4, bridges are extended,staircases are split off the office strips, some of the floors areinserted, and cavities are split off. At level 6, the cavities are set toempty, and office superstructures and most corridors are present.At level 9, all office scopes are replaced by Office. The boxes carrythe semantic information that a room is an office. Furthermore, allcorridors are split off the offices. At level 11 only windows anddoors are still missing. As the structure of these elements is morecomplex it takes until level 16 until the building is completelyevaluated (cf. Fig. 14(a)). Furthermore, segment E is depicted inFig. 14(b) and its second floor is shown in Fig. 14(c).

5.1. Modeling the use case

At first glance the segments look very similar and we expectedto use a lot of copy and paste. However, a closer look revealed thatalmost no segment, in or across any of the four buildings, is thesame as another. The structure within the segments, on the otherhand, is very regular. There is one strip of offices along the northand one strip along the south side of the segments (cf. Fig. 14(c)).In front of the offices there are corridors and between them there

Please cite this article as: Hohmann B, et al. A GML shape grammarGraphics (2010), doi:10.1016/j.cag.2010.05.007

is open space which facilitates cross floor communication. Onupper floors there are bridges spanning over this open space.

A floor is split into north, open space and south. The openspace is just floor on the ground floor and on upper floors it is splitinto open space and bridges. The north and south are split intooffice slices and walls (cf. Fig. 15). These slices are composed of acorridor, a wall and an office part. The wall part is the wallbetween the office and the corridor and is usually replaced by awall or a wall with a door. The corridor part is replaced by asimple corridor, a corridor with balustrade or a passageway. Theoffice part is again decomposed into room and outer wall, wherethe latter is split into windows and walls.

Except for the staircases, this corridor-wall-office-split, theCWO-split, is applied for every office-slice in the whole complex.This is possible because all the replacement rules are parametrizable.

for semantically enriched 3D building models. Computers and

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]] 9

The implementation of CWO-split (cf. Fig. 16) shows that insertingwindows in the outer wall of the office with the ruleE3DoubleWindow takes only four parameters. This is possiblebecause the windows are all of the same type and at the sameheight, only the margins from the office walls left and right of thewindow are varying. In the example, the lower and the upperwindows both have the same margin of 1 m from the left and0.5 m from the right. Another example in the code of CWO-split isthe E2Door rule. Its three parameters are the margin left, thewidth of the door, and the margin right. In the example a door ofwidth 1.0 m is placed in the middle of the wall, as the margins aredefined to be the same relative distance. This shows theimportance of parametrizable rules in shape grammars. Byabstracting slightly varying similar forms into a parametrizablerule, a very compact description of a complex scenery is possible.

Looking at the office strip in Fig. 15 it does not seem to be such agood idea to combine the corridors with the offices, because theballustrade is chopped into many parts. None of these splits is reallynecessary for positioning the bridges. It might have been better tocombine the corridors with the open space between the north andsouth parts. The reason why it was done that way is that someoffices are consuming the whole space of the CWO-split, includingthe corridor part. Thus, there is no corridor or ballustrade. Thisbrings up two important aspects of modeling buildings with shapegrammars. First, in many situations a decision has to be made whichway to split first. Relations between structures are often not obvious,and it takes some time to recognize them. This leads directly to thesecond aspect, namely refactoring. Although it might require mucheffort when realizing that a decision was wrong, it is worthwhile torefactor the code because the creation of further parts of the buildingbecomes much easier and faster.

5.2. Dealing with details

In most buildings one has to face irregularities. This appliesalso to the chosen university complex. When taking a closer lookat the floorplan in Fig. 13(a), one can see that the bridge segmentbetween segments C and D is discontinuous. In building 16c, it fitsthe scheme, however, it only connects to building 16 and iscontinued with an offset on the inside. Thus, the modeling of thispart had to be treated as an exception. Specifically, there isno bridge segment between segments C and D in building 16.

1 CWO−split2 E3Office3 Void4 1.0 0.5 1.0 0.5 E3DoubleWindow5 Office6 −1 1.0 −1 E2Door7 E1Corridor Void Void

Fig. 16. GML shape grammar code of the corridor-wall-office-split (CWO-split)

and the according model.

Fig. 17. Building segments, am

Please cite this article as: Hohmann B, et al. A GML shape grammaGraphics (2010), doi:10.1016/j.cag.2010.05.007

The parts of the bridge segment are simply included in segment D.This is the bridge inside building 16, the access corridors to thestaircase in the upper floors and the doors on the ground floor.

The staircases are another exceptional detail. First, one wouldlike to define the size of a step and then fit exactly as many stepsinto the staircase as needed to reach the next floor. Dynamicstaircases are necessary if staircases need to adapt themselves todifferent heights of floors. This is the key idea of proceduralmodeling. The problem is that the steps reach into the floor above,i.e., the containment property is violated. Thus, the scope of thestaircase is extruded to connect seamlessly to the floor assemblyof the floor above. Furthermore, the steps were split with anabsolute subdivide as well as the grating of the bridges outside.Besides that, only the split operator was used in the wholemodeling process.

The case of the cavities in the buildings, which serve as bikeparking, also had to be treated specifically. The problem was thatin the segments with cavities the floor is interrupted. Thus, thefloor assembly could not be split off before, but only after thecavity was split off.

Another interesting detail is the mirrored structure of thenorth and south parts in the buildings. As the described CWO-splitperformes a split in y-direction, it can only be applied on thesouth side. The problem could be solved by implementing asecond CWO-split in reversed order. However, this is not the onlyrule that depends on the Y-direction and is used on both sides.Thus, it is desirable to find a solution to be able to apply thesesplits on both sides. The problem was solved by defining a specialattribute yDir that is defined when splitting the segment intonorth, open space and south. For the north part it is defined as thenegative =Y direction and for the south part simply as =Y

direction. Splits that are applied to north and south parts of thebuildings now simply use yDir as split direction instead of =Y.

5.3. Solving a parameter dependency problem

There are cases where the top-down structure of the buildingleads to an inappropriate parametrization: Parameters, e.g.,distances, that are convenient to measure might not be para-meters of the model, which requires re-parametrization. This is infact a common fundamental problem of all procedural or even juststructured modeling approaches: A dependency between differ-ent levels, predecessors or branches in the evaluation tree is hardto resolve with depth-first traversal.

Our solution to this problem is to propagate not a value, but afunction along the evaluation tree: The function performs the re-parametrization lazily, i.e., only when it is needed. The function isevaluated in the local coordinate frame, but it may carry areference to a different coordinate frame; so it can establish a linkbetween both frames.

A concrete instance of this problem is depicted in Fig. 19: Theroom rule requires a position for the door as the distance from thewall of the room (blue arrows in the middle). Since it was not

bient occlusion rendering.

r for semantically enriched 3D building models. Computers and

Fig. 18. The semantically enriched four-building university complex. The blue wireframe boxes are offices, the turquoise boxes are corridors, yellow parts are staircases,

whereas red parts are entrance areas. (For interpretation of the references to color in this figure legend, the reader is referred to the web version of this article.)

Fig. 19. Re-parametrization problem for the door positions. The room widths are given, the door position is needed with respect to a wall of the room, but it is measured

with respect to the origin of the section. Solved using lazy evaluation.

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]]10

possible to enter every room, the position of the door was measuredinstead from the beginning of the corridor segment (sectionboundary), as indicated by the black arrows on the bottom. Thesolution to the problem was to store the corridor scope in a variablewhen it is available, and to re-use it when it is needed. So assume adoor was measured 18.208 m from the sector origin:

=my-corridor current-scope def

y (Definition of many rooms in betweeny)CWO-split

E

PleGra

3Office

Void

1:0 0:5 1:0 0:5 E3DoubleWindow

Office

m

y�corridor =X 18:208 reldist 1:0�1 E2Door

E

1Corridor Void Void

Fortunately, the solution is simple to use, but in fact it is a bittricky. The reldist function pops a scope, a direction and ameasurement with respect to this scope, and it generates afunction, which is pushed on the stack. The function is giveninstead of a number to E2Door. So the execution of reldist has theeffect that E2Door is called as follows:

f my-corridor=X 18:208 reldist-internal g 1:0�1 E2Door

The E2Door rule passes all three input directly on to the splitfunction, i.e., it executes the following split:

½ f my-corridor=X 18:208 reldist-internal g 1:0�1 � =X split

The split function performs an exec on its input values instead ofusing them directly. Typically, these values are numbers that execjust pushes back on the stack. But if a value is a function, execevaluates it. The effect of reldist-internal is to add the measure-ment to the signed distance of the scope origins, resulting in thedesired transformed measurement:

usereg !dist !dir !scope

: dir =X eq f

:

scope begin p000 getX end

p000 getX sub : dist add

g if

y (similar if-clauses for the other directionsy)

ase cite this article as: Hohmann B, et al. A GML shape grammarphics (2010), doi:10.1016/j.cag.2010.05.007

This solves the problem that the measurement can be done when

the wall scope has become the current scope. The solution uses

lazy evaluation, which is elegantly accomplished using a gener-

ated function.

5.4. Semantic enrichment

The fact that each scope contains a whole dictstack allows forinteresting semantic applications. The dictstack of a typical scopein Table 2. Recall that the scope-copy function from Fig. 8 createsan empty new dictionary and pushes to it a copy of the parentdictstack. Since scope-copy is used in any split or subdivide, thedictstack of a scope contains the whole refinement history. Namelookup in a dictstack works in such a way that new entries‘‘shadow’’ old entries, but the old entries are still present (andaccessible), again shown in Table 2. The green box is not aterminal but an intermediate symbol. In fact, all 35k scopescreated during the refinement are contained in one large scope-array that can, e.g., be filtered (Fig. 20):

scope-array fbegin segmentID =E eq compute-volume 10:0 gt and end

g filter f 0.1 2 highlight-scope g forall

The filter operator expects an array and a function to execute oneach element that pushes 0 or 1 like for if. The compute-volume

function simply multiplies the extents in all directions. So usingthese few lines of code, all scopes in segment E are highlightedthat are greater than (gt) 10 m3. Similarly, all scopes that are of aspecific type can be filtered and highlighted:

scope-array fbegin elementType=E2Door eq end

g filter f 0:05 3 highlight-scope g forall

This was accomplished by adding to each rule one code line thatdefines as =elementType the name of the rule. In this case, also allsub-scopes of the actual door are highlighted, since they inheritthat label. It is, of course, also possible to distinguish between adoor scope and a descendant of a door.

It should be noted that since all scopes are preserved, it is alsopossible to attach labels to scopes that are subsequently mapped

for semantically enriched 3D building models. Computers and

Table 2Dictionary stack of the green scope.

/dy (4.85,6.3)/self (Dictstack:20078,20078)/level 7/elementType /E1Wall/dx (82.51,82.81)/self (Dictstack:20002,20002)/level 6/elementType /ELevel/dz (0.35,3.5)/self (Dictstack:19999,19999)/level 5/dx (78.1,82.81)/self (Dictstack:19996,19996)/level 4/dz (0,3.5)/self (Dictstack:19824,19824)/level 3/dy (0,6.3)/self (Dictstack:18848,18848)/level 2/dx (78.1,93.23)/self (Dictstack:9419,9419)/level 1/building /Inffeldgasse-16c/segmentID /C/ex (1,0,0)/ey (0,1,0)/ez (0,0,1)/dx (0,93.23)/dy (0,15.6)/dz (0,11.1)/mat 16/self (Dictstack:9412,9412)/pt (0,0,0)/level 0/elementType /None/segmentID /None

Since name lookup proceeds from top to bottom, /dy defined in level 9 overwrites the

earlier values. Annotations added at any level are still available as the dictstack

contains the whole refinement history. The resulting /segmentID is

/C (overridden in level 1), /elementType is /E1Wall (set in level 7). The green box is

split another two times, its white descendant is a terminal box on level 9.

Fig. 20. Semantic filtering to highlight all scopes in segment E with a volume larger tha

the references to color in this figure legend, the reader is referred to the web version

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]] 11

Please cite this article as: Hohmann B, et al. A GML shape grammaGraphics (2010), doi:10.1016/j.cag.2010.05.007

to terminal-void, i.e., to empty space. Furthermore, this structurecan be directly mapped to a hierarchical spatial data structure forfast point containment queries.

6. Conclusion and future work

The reconstruction of this particular university complex was ofcourse a very specific use case, but it still teaches us fundamentaltechniques applicable in most cases. The first lesson is that it isabsolutely vital to identify super-structures and to subsequentlydivide the building into manageable smaller parts. Then guidingsplit planes need to be chosen according to structures withinthese parts, such as subsection divisions, e.g., fire walls or bearingwalls. These guiding structures also need to be chosen in such away that measurements can be taken conveniently, otherwise toomany re-parametrizations are necessary.

Only after a good vertical division into sectors it is found thatthe building should be split into its floors. The room subdivision isvery individual. In general it appears to be necessary to recognizeregularities, and to try to abstract them into parametrizable rules.However, over-generalization can be a problem as well: we choseto have several types of door-wall combinations instead of asingle one with a huge number of parameters.

It should be noted that with increasing complexity, refactoringbecomes ever more important when modeling with shapegrammars to obtain a semantically meaningful structure. Themodeling process exhibits great similarities to a software designprocess. Our experience was that creating the first sector of the

Fig. 21. The corridor skeleton of the building complex.

n 10 m3 (cyan), and all scopes of door type /E2Door (yellow). (For interpretation of

of this article.)

r for semantically enriched 3D building models. Computers and

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]]12

first building took almost two weeks, until after several rounds ofrefactoring we had a convenient set of rules. Completing the firstbuilding took another week, but then the process got considerablyfaster. Creating the fourth building, 16a, took merely just one day.

Fig. 23. A surveillance application. Video streams from surveillance cameras are analy

projected into the 3D model, detected persons are highlighted using billboards and au

Fig. 22. Assigning a different height to the university complex creates a skyscr

Please cite this article as: Hohmann B, et al. A GML shape grammarGraphics (2010), doi:10.1016/j.cag.2010.05.007

Generating view through semantic enrichment: We found a greatadvantage of the procedural approach is the possibility ofsemantic enrichment of the geometry. We had several requeststo generate specific views of the building, which we could in most

zed using a person detector. Both the video streams and the detection results are

xiliary geometry.

aper by repeating the first floors as often as it fits in the building volume.

for semantically enriched 3D building models. Computers and

B. Hohmann et al. / Computers & Graphics ] (]]]]) ]]]–]]] 13

cases realize by adding attributes to the scopes and filtering outthe appropriate entities. The whole building complex is composedof 14 104 boxes, and all in all 35 215 scopes are produced duringgrammar evaluation. Since we keep all the scopes, we can on thefly highlight different parts of the model, as shown in Figs. 12, 14and 17. Furthermore, by varying terminal rules we coulddistinguish offices, corridors, entrances, bridges, and staircasesfrom walls. The different parts can easily be filtered out andhighlighted. In particular, we have full information also about theempty spaces (cf. Figs. 21, 18).

Generalizability can be difficult to obtain: We have done someexperiments to generate variants of the building, to explore thedesign space. It is quite obvious that the building follows ageneralizable pattern; however, most of our randomly generatedvariants such as the skyscraper in Fig. 22 did exhibit certain flaws.This indicates that we have not yet identified rules that wouldguarantee that only valid buildings can be generated. Apparentlythere are some important functional relations that our rules donot cover.

Drawbacks of box geometry: One of the obvious drawbacks ofour approach is that the building is composed only of uncon-nected boxes. This makes surface-based operations difficult, e.g.,to collect all faces that make up a corridor wall, or to compute allsurfaces visible in a particular room; this would be much easierwith a connected mesh. However, we found that this was in factnot much of an issue so far. Another more serious limitation isthat it is really a mess to realize anything non-rectangular withboxes, e.g., the staircase railings. Although our blocks are alwaysrectangular, we can realize, to some degree, also non-rectangularfloor layouts with angles that are not only right angles. Scopeshave a local coordinate system which could be used for rotations.However, we have not used this feature so far.

Facility surveillance application: As stated in the Introduction,the initial motivation for creating a 3D model of the facility was asurveillance project. We have indeed successfully managed toproject live images from surveillance cameras into the model,including cut-out billboards from a vision-based person tracker.We found that it is much easier to get a coherent picture of thesurveillance situation when the information is not shown inindividual camera images, but in a coherent 3D space (see Fig. 23).

6.1. Future work

The most important research question is how to generalize thegrammar system to obtain a solution that is applicable also to lessrectangularly structured buildings. We see great potential in theoverall approach since there is apparently a great need forsustainable detailed models complex facilities. But we definitelyhave to abandon the pure box-based approach and must integratemore flexible geometric primitives, which we would still like toprocess in our procedural grammar-like fashion that has provenrobust and efficient.

The second focus will be on research for more interactive waysof authoring than by scripting, which is too indirect. To abandon

Please cite this article as: Hohmann B, et al. A GML shape grammaGraphics (2010), doi:10.1016/j.cag.2010.05.007

all scripting seems unrealistic, though, since code refactoring isapparently absolutely vital when the models become verycomplex. Suitable metaphors for ‘‘interactive refactoring’’ cur-rently seem to be inaccessible.

And finally, since the Disto has a Bluetooth interface we wouldlike to explore the possibility of porting the software to a mobileplatform to take measurements on site, and to enter them directlyinto the right position in the code.

Appendix A. Supplementary data

Supplementary data associated with this article can be foundin the online version at doi:10.1016/j.cag.2010.05.007.

References

[1] Microsoft, Bing Maps. URL: /http://www.bing.com/mapsS, 2010.[2] International Alliance for Interoperability. Industry Foundation Classes. URL:

/http://www.ifcwiki.org/S, 2010.[3] Stiny G, Gips J. Shape grammars and the generative specification of painting

and sculpture. In: The best computer papers of 1971. Auerbach; 1972.p. 125–35.

[4] Prusinkiewicz P, Lindenmayer A. The algorithmic beauty of plants. Springer-Verlag; 1990.

[5] Wonka P, Wimmer M, Sillion F, Ribarsky W. Instant architecture. In:Proceedings of the SIGGRAPH 2003, 2003. p. 669–77.

[6] Muller P, Wonka P, Haegler S, Ulmer A, Gool LV. Procedural modeling ofbuildings. In: ACM SIGGRAPH, vol. 25, 2006. p. 614–23.

[7] Procedural Inc. CityEngine. URL: /http://www.procedural.com/S, 2009.[8] Muller P, Zeng G, Wonka P, Gool LV. Image-based procedural modeling of

facades. In: ACM SIGGRAPH, vol. 26, 2007. p. 85.[9] Hohmann B, Krispel U, Havemann S, Fellner D. 2009. Cityfit—high-quality

urban reconstructions by fitting shape grammars to images and derivedtextured point clouds. In: 3D-ARCH09.

[10] Koutsourakis P, Simon L, Teboul O, Tziritas G, Paragios N. Single viewreconstruction using shape grammars for urban environments. In: ICCV09,2009.

[11] Xiao J, Fang T, Zhao P, Lhuillier M, Quan L. Image-based street-side citymodeling. In: SIGGRAPH Asia 09. New York, NY, USA: ACM; 2009. p. 1–12.

[12] Lipp M, Wonka P, Wimmer M. Interactive visual editing of grammars forprocedural architecture. In: Proceedings of the ACM SIGGRAPH 2008,vol. 2008. p. 1–10.

[13] Larive M, Gaildrat V. Wall grammar for building generation. In: GRAPHITE2006, 2006. p. 429–37.

[14] Alexander C. A city is not a tree. In: Architectural Forum 122 (1) (part 1), (2)(part 2), 1965. p. 58–61, 58–62.

[15] Finkenzeller D. Detailed building facades. IEEE Computer Graphics andApplications 2008;28(3):58–66.

[16] Aliaga D, Rosen A, Bekins D. Style grammars for interactive visualization ofarchitecture. In: IEEE transactions on visualization and computer graphics,2007. p. 786–97.

[17] Ripperda N, Berenner C. Application of a formal grammar to facadereconstruction in semiautomatic and automatic environments. In: AGILE09,2009.

[18] Havemann S. Generative mesh modeling. PhD thesis, Technical UniversityBraunschweig; 2005.

[19] Adobe Inc. PostScript language reference manual, 3rd ed. Addison-Wesley;1999.

[20] CGV TU Graz. GML Homepage. /http://www.generative-modeling.orgS,2009.

r for semantically enriched 3D building models. Computers and