1. 70 9. SCHLUSSBEMERKUNGEN
Umgebung platziert, dann erfüllen die Kontrollmöglichkeiten durch die Regeln sicher die
Erwartungen eines Benutzers. Aber, wie oben schon erwähnt, zur Planung von realen Städten
eignet sich die Strassennetzwerke nur in der ersten Entwurfsphase.
Das grösste Problem bei der Entwicklung von Regeln ist, dass auf dem Gebiet der Städtepla-
nung wenig entsprechende Modelle existieren oder aber diese nicht allgemeingültig sind.
Deshalb mussten die Modelle, die die Zusammenhänge zwischen Strasse und Umgebung
abstrahieren, zuerst entwickelt werden. Da in der Literatur natürlich keine statistische Werte für
die Parameter dieser Modelle existieren, mussten diese hergeleitet werden.
9.1.2 Gebäudegenerierung
Die Shape Grammar wurde so entworfen, dass Gebäudeformen unabhängig von der Form des
zugehörigen Grundrisses beschrieben werden können. Es existiert ein guter Mix aus einge-
schränkten (relativen) Befehlen und unabhängigen (absoluten) Befehlen. Das Vokabular der
CityEngine Shape Grammar kann in drei Klassen aufgeteilt werden: Turtle-, Grundriss- und
Geometrie-Befehle. Obwohl dieses Vokabular der Shape Grammar sehr einfach gehalten
wurde, können erstaunlich viele bestehende Gebäude mit ihr beschrieben werden. L-Systeme
wurden zur Generierung der Shape Strings benutzt, weil diese sehr flexibel sind, da nach
Belieben Module hinzugefügt oder entfernt werden können.
Der Entscheid, Geometrien im Maya Ascii Format (.ma) abzuspeichern, erwies sich als
ungünstig. Obwohl dieses Format gleich wie das .obj-Format aufgebaut ist, dauert in Maya das
Laden einer .ma-Datei viel länger als das Laden einer.obj-Datei mit dem gleichen Inhalt.
9.1.3 Implementation
Die Kombination von C++ und Tcl/Tk erwies sich als gute Lösung: Die Implementation der
CityEngine Pipeline ist einfach organisiert, das resultierende Programm läuft stabil und schnell,
und das User Interface ist übersichtlich und intuitiv. Die modulare Struktur, welche in Imple-
mentation und User Interface verwendet wird, ermöglicht eine unkomplizierte Weiterentwick-
lung des Programms.
Das User Interface könnte im Bezug auf das Editieren der Regeln verbessert werden
(beispielsweise das Positionieren eines Gitters durch die Maus) und das Arbeiten mit der City-
Engine Shape Grammar müsste graphisch besser unterstützt werden (beispielsweise mit einem
Shape Grammar Modeler). Da sich die CityEngine in der Entwicklung befindet, sind die Para-
meter nicht fest im System implementiert und auch nicht allzu benutzerfreundlich im User
Interface angeordnet.
9.2 Ausblick
9.2.1 Strassenetzwerkerzeugung
Möchte man noch andere Arten von Städten erzeugen, müssten weitere Rules gefunden werden.
Will man beispielsweise kleinere Städte oder Vororte erzeugen, müsste dem erweiterten L-
System die Residential Rule hinzugefügt werden. Diese generiert Strassennetze mit einer ver-
zweigenden Struktur (siehe Abbildung 4.2) und die Verhaltensweise gleicht dem der Wurzeln
in Kapitel 2.7.
Anstatt die Resultate mehrerer Rules durch lineare Gewichtung zu vereinigen, könnte die
dominierende Rule durch Verhaltensmodelle (Inhibition, Level-Of-Interest) aus dem “Virtual-
Reality”-Bereich Action Selection bestimmt werden [2].

2. 9.2 AUSBLICK 71
Methoden der Verkehrsplanung und -analyse wie Transportsimulation könnten im L-System
bzw. in den Rules implementiert werden. Auf diese Weise könnten realistischere Strassen-
netzwerke erzeugt werden.
9.2.2 Gebäudegenerierung
Neben den schon erwähnten möglichen Erweiterungen der Shape Grammar (eine Extrusion mit
mehr Parametern), könnte der Shape Grammar eine neue Klasse von Befehlen hinzugefügt wer-
den: die Material-Befehle. Der Interpreter wüsste immer, ob es sich nun um eine Fassade, ein
Dach, einen Eingang oder eine Antenne handelt.
Um die Gebäude realistischer und besser kontrolliert zu generieren, könnte ein umgebungs-
sensitives L-System benutzt werden. Die dreidimensionale Umgebung beinhaltet beispiels-
weise Baugesetze wie das New Yorker Zoning Law, welches ab einer gewissen Höhe eine
gewisse Verjüngung der Gebäude verlangt (in [8]).
Eine total andere Methode der Generierung von Strings wäre folgende: Man definiere einen
String eines Gebäudes dessen Stil gefällt. Da die Shape Strings eine verzweigende Struktur
haben, könnte der String, der Genotyp, nun mutiert werden [28].
Da die Gebäudegeometrien mit Shape Grammar Elementen zusammengesetzt wurde, eignet
sich die Geometrie auch zur Darstellung in verschiedenen Level of Details. Abbildung 9.1 zeigt
verschiedene ‘Level of Detail’-Auflösungsstufen eines Gebäudes.
Abbildung 9.1: Level of Detail: Links die simpelste Darstellung (Bounding Box) für
Gebäude in weiter Entfernung zur Kamera. Nach rechts nimmt die
Komplexität der Geometrie zu, bzw. der Abstand zur Kamera ab.
Sehr schwierig zu rendern sind verglaste Fassaden, die nicht verspiegelt sind (z.B. Abend-
dämmerung und in den Büros sind die Lichter an), da man das Interieur des Gebäudes erkennen
kann. Benutzt man frontal aufgenommene Fotos als Texturen, fehlt die Tiefenwirkung. Deshalb
könnte ein Shader implementiert werden, der wie in Abbildung 9.2 frontale Interieuraufnahmen
zweidimensional verzerrt, indem der Mittelpunkt im Texturraum verschoben wird.
Abbildung 9.2: Warping Facades. Die Textur (linkes Bild) dieses ebenen Polygons
wurde durch Verschieben des Mittelpunkt verzerrt.

3. 72 9. SCHLUSSBEMERKUNGEN
9.3 Danksagungen
Ich möchte mich bei folgenden Personen bedanken: Mein Betreuer Yoav ‘Yogi’ Parish, der
immer an mich geglaubt hat und mir stets freundschaftlich mit Rat und Tat zur Seite stand; Pro-
fessor Markus Gross, dass ich die Diplomarbeit in seinem Institut durchführen durfte; meiner
Praktikumsfirma Eyetronics, dass ich mir dort das programmiertechnische Knowhow aneignen
konnte um ein gesamtes Framework aufzustellen; Daniel Von Büren für seine Tcl/Tk Tipps;
und Hanspeter Brunner und Christian Iten für die Mithilfe am Siggraph-Paper.

4. AImplementation
A.1 Programm-Design
Nachdem der Aufbau der Pipeline festgelegt war, wurde ein der Pipeline entsprechendes mod-
ulares Programmkonzept gewählt. Es entstanden fünf Module namens Base, LSystem, Streets,
Allotments und UI (siehe Abbildung A.1).
Abbildung A.1: Das Programmdesign der CityEngine.
Die ersten vier Module sind hauptsächlich in C++ programmiert und jedes bildet eine
Library. Im UI-Modul, das hauptsächlich in Tcl/Tk programmiert ist, befindet sich unter
anderem der Source-Code (Main.c++) für das Executable der CityEngine. Diese Routine ist ver-
antwortlich für die Kommunikation zwischen C++ und Tcl, welche über Wrapper vonstatten
geht und folgendermassen funktioniert: Jedes Modul hat eine Klasse namens Wrapper.c++, in
der die Wrapper definiert sind. Als Wrapper kann man eine Routine bezeichnen, die zwar in C++
definiert wurde, aber auch von Tcl aufgerufen werden kann. In Main.c++ wird nun ein Tcl/Tk
Interpreter gestartet, sämtliche Wrapper-Aufrufe beim neuen Interpreter registriert und Main.tcl
gestartet. Letzteres kontrolliert den Aufbau von dem User-Interface. Sind die Wrapper-Aufrufe
erst einmal registriert, können sie in Tcl wie jeder andere Tcl-Befehl verwendet werden
Die Organisation der Entwicklungsumgebung (im Ordner dev/) ist in Abbildung A.2 darges-
tellt. In diesem Ordner befindet sich die Datei Makefile, welche die Makefiles der einzelnen
Module aufruft (Kommandos: make all, make allclean, make base etc.) und ein Makefile-Tem-
plate das von den Makefiles der Module importiert wird. Im Ordner bin/ befindet sich das Exe-
cutable. Die Libraries der Module Base, LSystem, Streets und Allotments sind in lib/ zu finden.
73

5. 74 A. IMPLEMENTATION
Die beispielsweise vom Base-Modul erzeugten .o-Files werden in obj/base/ abgespeichert.
Jedes Modul hat eine eigene Verzeichnisstruktur, indem sich wiederum ein Makefile befindet.
In diesen Makefiles werden nur Variablen bestimmt und anschliessend wird Makefile_template
aufgerufen, das die Kompilierung und das Linken ausführt.
Abbildung A.2: Die Verzeichnisstruktur der Entwicklungsumgebung.
Die folgenden Abschnitte beschreiben kurz die wichtigsten Eigenschaften der verschiedenen
Module. Details zur Implementation findet man im dokumentierten Sourcecode.
A.2 Das Modul Base
Das Modul Base enthält Tools und Datenstrukturen, die jedes Modul benutzt: Die Graphen-
klasse, die Parameterverwaltung und das Image-Handling. Jedes der anderen Module linkt diese
diese Library (libbase.a) dazu.
Die Klasse Graph bestitzt Methoden zum Lesen und Speichern des Graphen (siehe B.3),
sowie Einfüge- und Löschoperationen für Punkte und Kanten. Für Kanten existiert eine Inter-
section-Abfrage und für Punkte ist eine Nearest-Neighbour-Abfrage implementiert. Die Punkte
und Kanten werden in Listen verwaltet, wobei die Liste der Kanten ungeordnet und die Liste
der Punkte nach x-Koordinate sortiert ist (d.h. Reduktion vom zweidimensionalen Raum in den
eindimensionalen Raum). Zusätzlich zur Punkteliste wird ein Bucketarray verwaltet. Ein
Bucket zeigt auf den ersten Punkt in dem entsprechenden Bereich (falls ein Punkt vorhanden
ist). Beispiel: Man sucht den Punkt mit Koordinate (5634,3012). Bei einer Bucketlänge von
beispielsweise 200 muss nun die Punkteliste ab dem Eintrag in Bucket[28] sequentiell durch-
sucht werden. Die Bucket-Methode ist in jeder Hinsicht ideal, da Punkte sowohl schnell
eingefügt, wie auch schnell gesucht werden können. Vor allem Range-Queries können gleich
schnell wie die einfache Suche durchgeführt werden, was nur bei sehr komplexen räumlichen
Datenstrukturen wie MX-Quadtrees oder Bit-Interleaving möglich wäre [17]. Da Kanten auf
ihre beiden Endpunkte zeigen und Punkte wiederum auf ihre Kanten, können auch Kanten über
die Punktdatenstruktur gesucht werden.
Die Klasse Parameter liest und speichert ein Parameterfile (siehe B.1), stellt Methoden zum
Abfragen und Ändern der Parameter zur Verfügung und liefert Tcl entsprechende Wrapper. In
C++ wie auch in Tcl können die Parameter mit dem Parameternamen, der im Parameterfile
angegeben ist, abgefragt werden. In Tcl sind die Parameter in einem eigenen Namespace
abgespeichert. Will ein Modul nun seine Parameter im User-Interface anzeigen, baut eine Rou-
tine im Parameter-Namespace das entsprechende Widget auf. Verändert man einen Eintrag,

6. A.3 DAS MODUL LSYSTEM 75
werden Events aufgerufen, die wiederum die entsprechenden Wrapper aufrufen, welche dafür
sorgen, dass die Parameterwerte in C++ und Tcl konsistent sind.
Die abstrakte Klasse Heightfield dient zum Lesen von 2D-Daten jeglicher Art. Die Klasse
ist abstrakt, da vor allem Digital Elevation Maps in diversen Formaten existieren. Bisher
können jedoch nur TIFF-Bilder gelesen werden. Von diesem Typ existieren im Modul Base
mehrere globale Variablen wie gPopulationDensityHF oder gElevationHF (diese werden in
jedem Modul immer wieder benötigt). Das Pendant in Tcl/Tk ist der Namespace ImageViewer,
welcher verantwortlich für das Anzeigen der Bilder im User-Interface ist (vollständig in Tk).
Da Tk keine TIFF-Bilder lesen kann, wurde das Img-Package von Jan Nijtmans benutzt.
A.3 Das Modul LSystem
Das Modul LSystem ist verantwortlich für die Strassennetzwerkgenerierung. Es beinhaltet den
Parser samt Wachstumsregeln und Diffusionssystem. Den Klassen dieses Moduls werden
Lookuptables für trigonometrische Funktionen zur Verfügung gestellt, da effizienter Code hier
sehr wichtig ist.
Die Klasse LSystem beinhaltet den Parser für das L-System, welcher die Wachstumsregeln
aufruft und, falls mehrere Wachstumsregeln aktiv sind, die Vorschläge in einem vereinigt
(Blending). Anschliessend wird der Environmentcheck (durch Klasse Environment) aus-
geführt. Danach wird die (eventuell) resultierende Strasse im Graphen eingefügt und im Diffu-
sionssystem findet ein Update statt. Die Ersetzungsregeln im L-System sind fest implementiert,
d.h. es können keine neuen Ersetzungsregeln eingebaut werden wie im L-System, das die
Gebäude erzeugt. Dies ist auch nicht nötig, da das Wachstumsverhalten komplett mit den
Wachstumsregeln kontrolliert werden kann.
Die abstrakte Klasse GrowingRule dient als Basisklasse für jede Wachstumsregel. Momen-
tan sind vier Wachstumsregeln implementiert. Diese Klasse stellt einerseits den abgeleiteten
Klassen relevante globale Parameter auf lokaler Basis zur Verfügung (schneller als über
Parameter-Klasse) und stellt andererseits sicher, dass neue Wachstumsregeln kompatibel sind.
Eine Wachstumsregel muss zwei Funktionen implementieren: road(…) und highway(…). Die
beiden Funktionen erhalten als Übergabewerte den aktuellen Turtlestatus und die letzte
eingefügte Strasse (Street resp. Highway). Dann erfolgt das eigentliche Wachstum, was in max-
imal 3 neuen Strassen resultiert. Die Klasse GrowingRule besitzt nun 3 Highway- und 3 Street-
Branches als Member. In diesen (public) Members werden die neuen Strassen abgespeichert
und können bis zum nächsten Aufruf von road(…) resp. highway(…) gelesen werden. Weiter
hat jede Wachstumsregel eine Parameter-Klasse und eine Heightfield-Klasse als Member.
In der Klasse Cells ist das Diffusionssystem implementiert. Das Diffusionssystem stellt
Funktionen für das Abfragen (benutzt von Wachstumsregeln) und Absaugen (benutzt vom
Parser) von Zellen zur Verfügung, wobei diese Funktionen auf der Finiten-Differenzen-
Methode basieren. Wenn Highways die Richtung der grössten Population suchen, tritt die radi-
ale Abfragefunktion in Kraft. Diese wurde sehr effizient programmiert, indem im Konstruktor
der Klasse angegeben werden kann, wieviele Strahlen zur Berechnung benutzt werden sollen,
und wie lang diese sein sollen. Noch im Konstruktor werden nun sämtliche Indexoffsets der
Zellen mitsamt den Gewichten (je weiter weg, desto kleiner) berechnet. Wird die Funktion nun
aufgerufen, findet bloss noch eine kleine Anzahl Multiplikationen und Additionen statt. Als
Resultat liefert diese Funktion ein Array von Floats, welche eine 360°-Sicht repräsentieren (die
Werte zwischen den Strahlen werden linear interpoliert). Zusätzlich können TIFF-Bilder
abgespeichert werden, welche den Zustand der Zellen visualisieren.

7. 76 A. IMPLEMENTATION
Die Klasse LSystemGraph ist eine Subklasse der Klasse Graph aus dem Modul Base und
besteht nur aus einer Funktionendefinition. Diese Funktion namens insertModuleInGraph(…)
(‘Module’ in L-System-Terminologie) stellt die Kommunikation zwischen L-System und
Graph dar. Sie wird aufgerufen sobald das L-System ein Strasse definitiv einfügen will. Danach
teilt der Graph (via Insertion-Module) dem L-System mit, ob das Einfügen erfolgreich war. Das
Zeichnen des Graphen führt ein Wrapper (in LSystemWrapper.c++) aus. Dazu wurde die X-Lib
benutzt, welche Linien schneller als Tk zeichnet.
Der einzige Tcl-Code in diesem Modul ist der Namespace RuleParameter. Dieser ist eine
leicht abgeänderte Version des Namespaces Parameter aus dem Modul Base. Letzterer konnte
nur ein Parameterfile verwalten, während RuleParameter mehrere Parametersets kontrollieren
kann (pro Wachstumsregel ein Ruleparameterfile).
A.4 Das Modul Streets
Das Modul Streets ist das kleinste Modul. Da dieses Modul für die Funktionalität des Strassen-
editors verantwortlich ist, besteht es bloss aus Wrapper-Definitionen und der Klasse
StreetGraph, welche eine Subklasse von Graph aus dem Modul Base ist. Die Klasse Street-
Graph erweitert die Graphenklasse um zwei Funktionen: smoothGraph(…) (siehe 4.4) und
saveAATIFF(…), welche den Graphen als TIFF-Bild abspeichert. Die Kanten der gezeichneten
Strassen werden dabei geglättet. Die Wrapper sind verantwortlich für Funktionsaufrufe wie
selectEdge(…), moveVertex(…), deleteEdge(…) oder drawGraph(…). Das Zeichnen des
Graphen erfolgt auf ähnliche Weise wie im Module LSystem, nur sind hier mehrere Darstellung-
sarten möglich und Selektion wird unterstützt.
A.5 Das Modul Allotments
Das Modul Allotments ist verantwortlich für die Konvertierung des Graphen in Polygone
(Blocks), deren Subdivision in kleinere Polygone (Grundstücke) und das Erzeugen und Ver-
walten von Gebäudegeometrie. Allen Klassen in diesem Modul stehen Polygon-Datenstruk-
turen (mit Funktionen) zur Verfügung. Die Punkte aller Polygone sind stets im
Gegenuhrzeigersinn angeordnet.
Die Klasse AllotmentGraph ist eine Subklasse der Graphenklasse aus dem Modul Base und
extrahiert aus dem Graphen die der Suchtiefe entsprechenden Polygone. D.h. alle Zyklen im
Graphen, die keinen anderen, kürzeren Zyklus enthalten, sind gesucht. Dazu wurde folgender
Algorithmus verwendet: In jedem Knoten des Graphen wird nacheinander eine rekursive Suche
nach Zyklen begrenzter Länge (Suchtiefe) durchgeführt. War die Suche erfolgreich, d.h. der
letzte Knoten entspricht wieder dem Ausgangsknoten, indem die Suche gestartet wurde, muss
der gefundene Zyklus überprüft werden:
• Wurde bereits ein kürzerer oder gleich langer Zyklus gefunden, der Teil des neuen Zyk-
lus ist, ist der neue Zyklus überflüssig und kann verworfen werden.
• Ist der neue Zyklus Teil eines bereits gefundenen längeren Zyklus, kann der alte Zyklus
verworfen werden.
• Befindet sich innerhalb des Zyklus ein Knoten, kann dieser verworfen werden.
Die Klasse PolygonContainer besteht aus einer Polygonliste und Funktionen zum Lesen und
Schreiben von Polygonfiles (siehe B.4 und B.5). Weiter werden in dieser Klasse auch MEL-
Dateien erzeugt (siehe B.8). Die Funktion cutEdges() verkleinert die Polygone, indem an jeder
Kante die halbe Strassenbreite subtrahiert wird. Konkave Polygone werden durch diesen Proz-
ess in konvexe Polygone verwandelt. Dies vereinfacht das Exportieren von Geometrie in 3D-

8. A.6 DAS MODUL UI 77
Programme (diese haben oft Mühe mit konkaven Polygonen). Das Subdividieren der Polygone
wird wie in 5.1 beschrieben durchgeführt. Ist die Subdivision beendet und ein Grundstück
gefunden, werden dessen sämtliche Eigenschaften bestimmt. D.h. alle Attribute eines Gebäudes
wie Grundfläche, Höhe, Alter oder Funktion sind ab diesem Zeitpunkt festgelegt. Nur dem
Shapestring-Attribut ist noch kein String zugeordnet. Das Pythonscript LSystemControl.py
ruft nun für jedes Gebäude das L-System auf, das entsprechende Shapestrings generiert und
diese in einzelnen Dateien abspeichert. Mit Hilfe des Wrapperaufrufs attachStringToPoly-
gon(…) werden diese Files eingelesen und in den Polygonen als Shapestring-Attribut abgespe-
ichert. Ebenfalls in AllotmentsWrapper.c++ befindet sich ein Wrapper, der die Polygone im
User-Interface zeichnet. Auch hier wurde wieder die X-lib benutzt.
In der Klasse Geometry befindet sich der Parser, der die Shapestrings der Polygone interpre-
tiert. Die daraus resultierende Geometrie wird in Objekten mit je einer Liste für Vertices, Tex-
tures, Edges und Faces verwaltet. Der Zweck dieser Listen ist, dass die Geometrie in ein
bekanntes 3D-Format exportiert werden kann, weshalb auch die Beziehung zwischen den
Komponenten mit Indexeinträgen abgebildet werden (zur Beschreibung eines Meshes listen die
meisten Formate zuerst die Vertices auf und anschliessend werden deren Indexe weiterverwen-
det um Faces etc. zu definieren). Die Funktion exportGeometryToMaya(…) schreibt die Geom-
etrie im Maya Ascii Format in eine Datei (siehe B.9).
A.6 Das Modul UI
Bis auf das oben erwähnte Main.c++ ist das Modul UI vollständig in Tcl/Tk programmiert.
Main.tcl importiert zuerst das Img-Package und das BWidgets-Package. Letzteres stellt ver-
besserte Widgets zur Verfügung, ist aber komplett in Tcl/Tk programmiert. Anschliessend
werden globale Variablen wie Modulnamen definiert und das User Interface mit den Menuein-
trägen wird aufgebaut. Das User Interface selbst wurde ebenfalls modular entworfen, d.h. belie-
big viele Module können dem User-Interface hinzugefügt werden. Entscheidend ist die Liste
der Modulnamen. Jedem darin aufgeführten Modul wird ein Widget zur freien Verfügung bereit
gestellt.
Die drei Module LSystem, Streets und Allotments benötigen im Gegensatz zum Modul Base
ein User Interface. Die Definitionen dessen findet man in den Dateien LSystemUI.tcl, Street-
sUI.tcl und AllotmentsUI.tcl in diesem Modul. Jeder Namespace muss eine Prozedur namens
CreateMainFrame besitzen, die den Aufbau des von Main.tcl zur Verfügung gestellten Widgets
übernimmt. Jedes Modul kann Teile des Widgets dem ImageViewer zur Verfügung stellen.
Falls das Modul dann eine eigene Zeichenroutine benützen will, kann es diese beim ImageV-
iewer registrieren (drawStreetGraphWrapper ist beispielsweise die Zeichenroutine vom Modul
Streets). Die Gestaltung der Widgets der Module kann sich unterscheiden: Das L-System-
Modul hat beispielsweise einen multifunktionalen Timeslider, der im Allotments-Modul nicht
vorkommt.
Der Namespace FileTransfer ist verantwortlich für das Laden und Speichern sämtlicher
Daten. Je nach Dateityp führt er die entsprechenden Operationen aus. Wird ein Parameterfile
geladen, werden zuerst die Parameter in C++ gelesen, dann Tcl übergeben, welches darauf die
offenen Parameterfenster neu zeichnet. Anschliessend werden die in Tcl/Tk mit dem ImageV-
iewer-Namespace und in C++ mit der Heightfield-Klasse die Bilder geladen . Danach werden
die Ruleparameterfiles gelesen und wiederum ausgewertet (in Tcl/Tk Regel-Kontrollbild laden
und in C++ Instanz einer GrowingRule erzeugen). Die anderen Dateitransferoperationen bes-
chränken sich meist auf einen Wrapper-Aufruf und ein ImageViewer-Update.

9. 78 A. IMPLEMENTATION

10. BDateitypen
B.1 Parameterfile (.par)
Eine Parameterdatei beinhaltet alle Daten eines CityEngine-Projektes, wie UI-Einstellungen,
Dateipfade zu den entsprechenden Bildern, Dateipfade zu den Parameterdateien der L-System
Regeln (siehe nächsten Abschnitt) und Parameter jeglicher Art. Im Unterschied zu den anderen
Dateitypen beinhaltet eine Parameterdatei nicht nur die Werte der Parameter sondern auch
deren Definition und UI-Informationen. Das Format einer Zeile (entspricht einer Parameter-
definition) sieht folgendermassen aus, wobei in Klammern immer der Typ des jeweiligen Ein-
trags angegeben ist (B für Boolean, I für Integer, F für Float, C für Char und S für String):
Typ(C) Name(S) Wert(Typ) Standardwert(Typ) UI-Info(C)
Der erste Eintrag einer Zeile definiert den Typ des Parameters (B, I, F oder S). Das Zeichen ‘_’
im Parameternamen wird zur Anzeige im User Interface mit einem Leerzeichen ersetzt. Der
letzte Eintrag einer Zeile kontrolliert den Ort der Anzeige im User Interface: P für das Fenster
mit den Einstellungen; L, S oder A für den Parameterteil des jeweiligen Moduls oder H um den
Parameter nicht anzuzeigen (angewendet bei On/Off-Buttons, die über Menüs wesentlich
besser zu kontrollieren sind). Die Reihenfolge der Darstellung der Parameter im jeweiligen
Fenster entspricht der Reihenfolge ihrer Definition in der Parameterdatei. Ein Ausrufezeichen
zu Beginn der Zeile nach der letzten Parameterdefinition markiert das Ende der Datei.
B.2 Ruleparameterfile (.rp)
Die Parameterdatei einer Regel für das Strassennetzwerk generierende L-System hat dasselbe
Format wie eine Parameterdatei. Der Unterschied liegt einzig im Inhalt: Wie der Name schon
verrät, beinhaltet sie sämtliche Parameter zur individuellen Steuerung einer L-System-Regel.
Der Typ der Regel (Western, Grid, Radial, Topological) wird durch den Prefix im Dateinamen
bestimmt (zum Beispiel: Western.version2.rp). Die UI-Information wird hier nicht verwendet.
B.3 Graphfile (.gra)
Eine Graphendatei beschreibt ein (generiertes) Strassennetzwerk samt Strasseninformationen.
Eine Datei sieht folgendermassen aus:
79

11. 80 B. DATEITYPEN
#VERTICES: nbrOfVertices(I)
valence(I) x(F) y(F)
…
#EDGES: nbrOfEdges(I)
index1(I) index2(I) creationStep(I) nbrOfTracks(I) streetType(S)
…
Die Kopfzeile beschreibt die Anzahl der Punkte (respektive Kreuzungen) und auf den darauf
folgenden nbrOfVertices Zeilen sind die Daten der Punkte aufgelistet. Der Eintrag valence
beschreibt die Anzahl der sich in diesem Punkt treffenden Kanten (entspricht Strassen). Danach
folgt die Definition der Kanten (Anzahl: nbrOfEdges). Die ersten beiden Indexeinträge ver-
weisen auf die beiden Endpunkte der Kante und die letzten drei Einträge repräsentieren die
Attribute einer Strasse: creationStep beschreibt den Zeitpunkt der Generierung durch das
L-System, nbrOfTracks die Anzahl Spuren und streetType den Typ der Strasse (H für Highway,
S für Street und falls die Strasse eine Brücke ist: BH respektive BS).
B.4 Blockfile (.p)
Dieser Dateityp wird verwendet, um Blockdaten (Polygone) abzuspeichern und zu lesen. Eine
Datei dieses Typs beinhaltet die eigentliche Definition der Polygone und für jede Kante die
Strassenattribute (siehe Graphfile). Jede Zeile beschreibt ein Polygon und eine Null am Anfang
der letzten Zeile markiert das Ende der Datei. Das Format einer Zeile sieht folgendermassen
aus:
valence x1 y1 … xvalence yvalence streetAttr1 … streetAttrvalence
B.5 Lotfile (.p+)
Dieser Dateityp wird verwendet um Gebäudegrundstücke (Polygone) abzuspeichern und zu
lesen. Auch das gebäudegenerierende L-System liest diese Polygondatei um die Shapestrings
zu generieren. Die ersten Einträge einer Zeile sind dieselben wie im Blockfile und die restlichen
Einträge sind Parameter für das auf diesem Grundstück zu bauende Gebäude. Eine Null am
Anfang der letzten Zeile markiert das Ende der Datei. Eine Zeile hat folgende Einträge:
valence,x1,y1,…,xvalence ,yvalence ,streetAttr1,…,streetAttrvalence ,
elevation(F),height(F),length(F),width(F),shapeType(C),
creationStep(I),zoneID(I),blockID(I),houseID(I),
buildingType(C),objectID(I),age(I),floorHeight(F),windowWidth(F)
Der Eintrag elevation entspricht der Höhe über Meer (minimale Y-Koordinate aller Punkte), die
nächsten drei Einträge stellen die Bounding Box dar und shapeType den Typ des Polygons (R
für Rechtecke und I für alle anderen Formen). Die weiteren Attribute und ihre Bedeutung:
• creationStep: maximaler creationStep aller Kanten von dem Polygon.
• zoneID: Identifikationsnummer der rechteckigen Zone, in der sich das Polygon befindet.
• blockID: Identifikationsnummer des Blockes, in dem sich das Polygon befindet.
• houseID: eindeutige Hausnummer.
• buildingType: R für Residential, C für Commercial und I für Industrial (dieser Wert wird
für das Gebäude-L-System und die prozeduralen Shader benötigt).
• objectID: Identifikationsnummer für das Geometrieobjekt, zu dem dieses Gebäude hin-
zugefügt werden soll (werden prozedurale Shader verwendet, so ist diese Identifikations-
nummer irrelevant, da nur je ein Objekt erzeugt wird).

12. B.6 BUILDINGRULEFILE (.LSYS) 81
• age: Erbauungsjahr des Gebäudes.
• floorHeight: Stockwerkhöhe (für L-System und nicht-prozeduralen Shader);
• windowWidth: Fensterabschnittsbreite (für L-System und nicht-prozeduralen Shader).
B.6 Buildingrulefile (.lsys)
Die Regelwerke für das L-System, das die CityEngine Shape Grammar Strings erzeugt, werden
in diesem Dateityp verfasst. Da dieser auf XML basiert und sich streng an die L-System-Syntax
hält, ist dessen Anwendung leicht nachvollziehbar und bedarf keiner weiteren Erklärung.
B.7 Shapestringfile (.str)
Diese Dateien werden vom Gebäudegenerierenden L-System erzeugt und jede Datei beinhaltet
einen CityEngine Shape Grammar String, der die Form eines Gebäudes beschreibt. Der Datein-
ame beinhaltet die eindeutige Gebäudenummer (houseID), wodurch jedem Gebäude die
entsprechende Shapestringdatei zugeordnet werden kann. Die Shape Grammar ist in Kapitel 6
beschrieben.
B.8 MEL Code (.mel)
Dieser einfache MEL (Maya Embedded Language) Code ist vor allem zu Testzwecken
geeignet, um Polygone in Maya zu betrachten. Der Code liest Polygone (MEL-Befehl: create-
Facet) jeglicher Art (Blocks und Lots) und anschliessend werden diese Polygone extrudiert
(MEL-Befehl: extrude), wobei keine Texturinformationen hinzugefügt werden.
B.9 Maya Ascii (.ma)
Maya Szenen können als Binary oder Ascii Files abgespeichert werden. Letztere bestehen aus
einem reduzierten Set von MEL-Kommandos, mit denen Geometrie direkt in Maya eingelesen
werden kann (ähnlich wie zum Beispiel das .obj Format). Die CityEngine kann drei Arten von
Maya Ascii Dateien schreiben:
1. Untexturierte Extrusionen: Der Unterschied zum erzeugten MEL-Code ist, dass
dieses Format wesentlich schneller in Maya eingelesen ist und nur ein Objekt erzeugt,
was viele Transform-Nodes erspart und die resultiernde Maya-Szene um einiges
schneller macht.
2. Gebäude für prozedurale Shader: Es wird pro Shader (Residential, Commercial und
Industrial) ein Objekt generiert. Jedem Face werden Attribute wie Gebäudenummer,
Alter oder Fassadengrösse zugeordnet, welche von den prozeduralen Shadern gelesen
werden können. Die Texturkoordinaten der Faces können in Maya normalisiert wer-
den.
3. Gebäude für nicht-prozedurale Shader: Für jeden Gebäudetyp (objectID) existieren
zwei Shader: ein Fassadenshader und ein Dachshader. Es wird also pro Fassaden-
Shader ein Objekt und pro Dachshader ein Objekt generiert. Fassadenshader sind fol-
gendermassen aufgebaut: Ein Fensterabschnitt mit Höhe floorHeight und Breite win-
dowWidth entspricht im Texturraum U von 0 bis 1 und V von 0 bis 1. In Maya
bedeutet dies nun nicht, dass alle Fenster gleich aussehen müssen, denn es gibt die
Möglichkeit Shader über mehrere Fensterabschnitte zu definieren (Coverage-Para-
meter von 2DTexturePlacement). Die Texturkoordinaten der Dachobjekte können in
Maya normalisiert werden.

13. 82 B. DATEITYPEN

14. CReferenzen
[1] C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King and S. Angel.
A Pattern Language. Oxford University Press, New York, 1977.
[2] B. M. Blumberg and T. A. Galyean. Multi-Level Direction of Autonomous Creatures for
Real-Time Virtual Environments. In SIGGRAPH Conference Proceedings, pages 47-54,
August 1995.
[3] E. Catmull and J. Clark. Recursively generated B-spline surfaces on arbitrary topological
meshes. Computer Aided Design, 10(6):350-355, 1978.
[4] D. Davis, W. Ribarsky, T.Y. Jiang, N. Faust and S. Ho. Real-Time Visualization of scal-
ably large collections of heterogeneous objects. IEEE Visualization ‘99, pp. 437-440,
October 1999.
[5] X. Decoret, G. Schauffler, F. Sillion and J. Dorsey. Multi-layered impostors for acceler-
ated rendering. Eurographics 18(3), 1999.
[6] O. Deussen, P. Hanrahan, B. Lintermann, R. Mêch, M. Pharr and P. Prusinkiewicz. Real-
istic modeling and rendering of plant ecosystems. In SIGGRAPH 98 Conference Proceed-
ings, pages 275-286, August 1998.
[7] K. Dietrich, M. Rotach, E. Boppart. Strassenprojektierung. Zurich 1993.
[8] H. Ferris. The Metropolis of Tomorrow. I.Washburn, New York, 1929.
[9] C. Focas (ed.) The Four World Cities Transport Study. London Research Centre, The Sta-
tionery Office, London 1998.
[10] K. Fuesser. Stadt, Strasse & Verkehr (City, Roads and Traffic), Vieweg Verlag, 1997.
[11] T. Fujii, K. Imamura, T. Yasuda, S. Yokoi and J. Torikawi. A virtual scene simulation
system for city planning. Computer Graphics International, 1995.
[12] D. Zorin, P. Schröder. Subdivision for Modeling and Animation. Siggraph Course Notes,
ACM SIGGRAPH, Course 36, 1998.
[13] O. Henricsson, A. Streilein and A. Gruen. Automated 3-D reconstruction of buildings and
visualization of city models. Bonn. Oct. 1996.
83

15. 84 C. REFERENZEN
[14] B. Hillier. Space is the Machine: A Configurational Theory of Architecture. Cambridge
University Press, Cambridge, UK, 1997.
[15] B. Hillier, A. Penn, J. Hanson, Grajewski and J. Xu. Natural Movement: or, Configura-
tion and Attraction in Urban Pedestrian Movement. Environment and Planning B, Vol.
20, pp. 29-66, 1993.
[16] A.B. Jacobs. Great Streets.The MIT Press, Cambridge Massachusetts. 1993.
[17] H. Samet. The Design and Analysis of Spatial Data Structure. Addison-Wesley, Reading,
MA, 1990.
[18] R. Mêch and P. Prusinkiewicz. Visual models of plants interacting with their environ-
ment. In SIGGRAPH 96 Conference Proceedings, pages 397-410, August 1996.
[19] V. Meier. Realistic Visualization of Abdominal Organs and its Application in Laparo-
scopic Surgery Simulation. Disseration, ETH Zurich, 1999.
[20] W.J. Mitchell. Computer-Aided Architectural Design. Van Nostrand Reinhold, New
York, 1977.
[21] F.K. Musgrave, C.E. Kolb and R.S. Mace. The Synthesis and Rendering of Eroded Fractal
Terrains, In SIGGRAPH 89 Proceedings, pp. 41-50, July 1990.
[22] Peponis J., Zimring C. and Choi Y. K. Finding the Building in Wayfinding. In Environ-
ment and Behavior, Vol. 22, pp. 555-590., 1990.
[23] K. Perlin. An Image Synthesizer. Computer Graphics (SIGGRAPH 85 Proceedings),
19(3): 287-296, 1985.
[24] P. Prusinkiewicz and A. Lindenmayer. The algorithmic beauty of plants, Springer, 1990.
[25] P. Prusinkiewicz, M. James and R. Mêch. Synthetic Topiary. In SIGGRAPH 94 Confer-
ence Proceedings, pages 351-358, July 1994.
[26] W.T.Reeves and R.Blau. Approximate and probabilistic algorithms for shading and ren-
dering structured particle systems. Computer Graphics (SIGGRAPH 85 Proceedings),
19(3): 313-322, 1985.
[27] S. M. Rubin and T. Whitted. A 3-dimensional representation for fast rendering of complex
scenes. Computer Graphics 14(3), pages 110-116, 1980.
[28] K. Sims. Evolving Virtual Creatures. Computer Graphics (SIGGRAPH 94 Proceedings),
1994.
[29] G. Stiny. Pictorial and Formal Aspects of Shapes and Shape Grammars. Birkhauser,
Basel, Switzerland, 1975.
[30] M. Wegener. Operational Urban Models: State of the Art. In Dortmunder Beitrage zur
Raumplanung No. 84, University of Dortmund, 1998.
[31] G. Schmitt. Architectura et Machina. Vieweg Verlag, Wiesbaden, 1993.
[32] R. Woodbury. Layouts, Solids, Grammar Interpreters and Fire Stations. In: CAAD
Futures ‘93, Pittsburgh, 1993.
[33] I. Sutherland. Sketchpad, A Man-Machine Graphical Communication System. In: Pro-
ceedings 1963 Spring Joint Computer Conference AFIPS, Vol. 23, 1963.

16. DSiggraph 2001 Paper
85

17. Procedural Modeling of Cities
Yoav I H Parish Pascal Müller
parish@imes.mavt.ethz.ch pascal@centralpictures.com
ETH Zürich, Switzerland Central Pictures, Switzerland
ABSTRACT Some of these systems include: the simulation of erosion [23],
particle based forests [28] and cloud modeling [25].
Modeling a city poses a number of problems to computer graph- Grammar-based generation of models (especially L-systems) are
ics. Every urban area has a transportation network that follows employed in computer graphics mainly to create plant geometry
population and environmental influences, and often a superim- [26]. L-systems have evolved into very sophisticated and power-
posed pattern plan. The buildings appearances follow historical, ful tools [20, 27] and have been extensively used in the modeling
aesthetic and statutory rules. To create a virtual city, a roadmap of plant ecosystems described in [8].
has to be designed and a large number of buildings need to be
generated. We propose a system using a procedural approach 1.1 Related Work in Urban Modeling
based on L-systems to model cities. From various image maps
One approach to modeling existing cities is the use of aerial
given as input, such as land-water boundaries and population
imagery to extract the buildings and streets thereof, using com-
density, our system generates a system of highways and streets,
puter vision methods. There are various research projects that
divides the land into lots, and creates the appropriate geometry
rely on this approach, e.g. [15]. This method can be used to
for the buildings on the respective allotments. For the creation of
rebuild cities, but is not designed to create new models without
a city street map, L-systems have been extended with methods
photographic input data.
that allow the consideration of global goals and local constraints
and reduce the complexity of the production rules. An L-system The existing research work concerning the visualization of cities
that generates geometry and a texturing system based on texture [6, 7, 13, 29] focuses on techniques for data management, fast
elements and procedural methods compose the buildings. real-time visualization and memory-usage optimization.
CR categories: F.4.2 [Mathematical Logic and Formal Lan- In [1], Alexander et al. describe a pattern language, which con-
guages]: Grammars and Other Rewriting Systems: Parallel sists of over 250 relevant patterns for the successful construction
Rewriting Systems, I.3.7 [Computer Graphics]: Three-Dimen- of cities, buildings and houses. They range from very general
sional Graphics and Realism, I.6.3 [Simulation and Modeling]: patterns like “Ring Roads” to very specific ones like “Paving
Applications with cracks between the stones”. Since these patterns are not
formalized, they cannot be used in the automatic creation pro-
Keywords: L-system, software design, developmental mod-
cess of an urban environment.
els, modeling, urban development, architecture
Space Syntax has been developed by Hillier [16]. Space syntax
1 INTRODUCTION can be viewed as a set of theories analyzing the complexity of
large-scale spaces, such as cities. It tries to explain human
Modeling and visualization of man-made systems such as large behaviors and activities from a spatial point of view and has
cities is a great challenge for computer graphics. Cities are sys- been used in the analysis of city pedestrian flows [17] or way-
tems of high functional and visual complexity. They reflect the finding processes [24]. This approach is analytical and relies on
historical, cultural, economic and social changes over time in the availability of city-maps. In the field of architectural interac-
every aspect in which they are seen. Examining pictures of a tive design one approach might be mentioned: the shape gram-
large-scale city such as New York reveals a fantastic diversity of mar developed by Stiny [31]. This method uses production rules,
street patterns, buildings, forms and textures. The modeling and but instead of operating on strings, a shape grammar defines
visualization of large-area cities using computers has become rules directly on shapes. Shape grammars have been used to gen-
feasible with the large memory, processing and graphics power erate two-dimensional patterns and in interactive design applica-
of todays hardware. The potential applications for a procedural tions.
creation range from research and educational purposes such as
urban planning and creation of virtual environments to simula- 1.2 Our approach
tion. Especially the entertainment market such as the movie and We present a system called CityEngine which is capable of
game industry have a high demand for the quick creation of modeling a complete city using a comparatively small set of sta-
complex environments in their applications. tistical and geographical input data and is highly controllable by
Visual modeling of large, complex systems has a long tradition the user. To our knowledge, there is no such system available,
in computer graphics. Most of these approaches address the although one very similar project outline is presented under [34].
appearance of natural phenomena. Much of the appeal of such In [5], a method for generating urban models is presented by
renderings lies in the possibility to depict the complexity of refinement of existing geometry. However, in this approach a
large-scale systems, which are composed of simpler elements. basic model of the city buildings has to be created manually.
Other systems [4, 32] rely on aerial pictures as the main input
for building and road placement. Our CityEngine creates
urban environments from scratch, based on a hierarchical set of
comprehensible rules that can be extended depending on the
users needs.
In [33], Wegener splits the urban model into subsystems. He
Permission to make digital or hard copies of all or part of this work for states that the subsystems networks, land use and housing are
personal or classroom use is granted without fee provided that copies
are not made or distributed for profit or commercial advantage and that
among the slowest changing elements in an urban environment.
copies bear this notice and the full citation on the first page. To copy Therefore, in our system CityEngine, the creation of the city
otherwise, to republish, to post on servers or to redistribute to lists, is reduced to generating a traffic network and buildings. Land
requires prior specific permission and/or a fee. use data is provided by the user in form of image-maps. When
studying maps and aerial photographs of large cities, it is obvi-
ACM SIGGRAPH 2001, 12-17 August 2001, Los Angeles, CA, USA ous that the streets follow some sort of pattern on different
© 2001 ACM 1-58113-374-X/01/08...$5.00
301

18. scales. Roads are the transportation medium for the urban popu- • Geographical Maps
lation distributed over the area. L-systems have been used in a - Elevation maps
similar application [20], support branching very well and have - Land/water/vegetation maps
the advantage of database amplification [30]; this suggests their • Sociostatistical maps
potential use to generate convincing large-scale road patterns. - Population density
We have adapted the model of L-systems to enable the creation - Zone maps (residential, commercial or mixed zones)
of large cities, based on the data that has been collected in [11] - Street patterns (control behavior of streets)
on four huge cities around the world, i.e. New York, Paris, Tokyo - Height maps (maximal house height)
and London.
Control of the various parameters within the particular tools can
Although we simplified the underlying model of the virtual city, be changed by the user interactively or by providing parameter
the main design goal for the system is easy extensibility. We files. For example, statistical measures such as the approximate
want to be able to add new subsystems, such as different trans- area size of a block or the average number of intersections per
portation networks (underground, train) and alternative land square mile, such as in [18] can be used to change the resulting
uses. To achieve this, we extended the L-system with a higher- street map. In figure 2 the top pictures are examples of a geo-
level mechanism that makes the addition of new rules very easy. graphical image showing land-water boundaries and another
1.3 Overview image depicting the distribution of the population over the area.
In Chapter 2 we describe the concept and the pipeline of the
CityEngine system, and the methods used therein. In Chapter
3 the idea of extended L-systems, which allow the implementa-
tion of global goals and local constraints is introduced. We dem-
onstrate the use of this extended concept on the creation of the
roadmap. Chapter 4 gives a brief overview of the generation of
allotments and buildings and explains our proposed mechanism
to simplify the texturing of facades. Finally, the results we
achieved are shown and discussed in Chapter 5.
2 SYSTEM ARCHITECTURE
The CityEngine system consists of several different tools
which form the pipeline that is shown in figure 1. In a first step,
the input data is fed to the road-generation system, using an
extended L-system described in 3.4. The areas between the roads
are then subdivided to define the allotments the buildings are Figure 2: Left column: Water, elevation and population density
placed on. In a third step, by applying another L-system, the maps of an imaginary virtual city of 20 miles diameter. Right:
buildings are generated as a string representation of boolean One possible roadmap generated from this input data.
operations on simple solid shapes. Finally, a parser interprets all
the results for the visualization software. The visualization soft- Two different L-systems are invoked for the creation of the com-
ware should be able to process polygonal geometry and texture plete city, one for street, the other for building generation. The
maps. This is the case for practically any 3D renderer. Addition- population density of a city is influenced by the creation of
ally, most scanline renderers support procedural textures, so the streets. Through streets, people are transported by the system to
proposed mechanism to generate facades of buildings can be the next highway [12]. We reflect this by using an approach sim-
incorporated into the pipeline. ilar to the Open L-system model [20] when creating streets. The
L-system mechanism has been modified in such a way that vari-
Geographical
ous different road patterns can be visualized using the same pro-
Sociostatistical duction rules.
Image Maps
According to [12], not all roads change the population density of
Roadmap creation their immediate local surroundings, e.g. roads connecting two
Extended L-System cities. We therefore chose to consider two types of roads: high-
Roadmap
Division into lots
Graph ways and streets. They differ in their purpose and behavior:
Subdivision Highways connect areas with highly concentrated population
Allotments
Polygons Facade elements globally, by scanning the population density input map for
Building generation Image Maps peaks. Streets cover the areas between highways according to
L-System Buildings local population density, giving all neighborhoods transportation
Strings Texture Engine
Geometry Grid creation access to the nearest highway. Together, these two classes form
Parser Geometry Shaders the road map of the virtual city.
Polygons Procedural Once the road map is generated, the land is divided into smaller
Renderer areas surrounded by streets. These areas can be geometrically
subdivided to define the allotments for the individual buildings.
Output
Images The buildings themselves are generated by a stochastic, paramet-
ric L-system. In our system the buildings are composed by
Figure 1: The pipeline of the city creation tool. The dark boxes extruding and transforming an arbitrary outline.
list the results and data structures of the indiviual tools in the For the final visualization in the renderer facade textures are gen-
white rectangles. erated using a semi-procedural approach. Every facade is tiled
Most of the input data to build up the virtual city is represented into superimposed and nested grid structures. The grid cells
by 2D image maps which control the behavior of the system. resulting from this subdivision can then be assigned textures or
Those images can be easily generated either by drawing them or procedural textures.
by scanning from statistical and geographical maps, as found in
[11]. The data can be categorized into two general classes:
302