Master thesis pascal_mueller02
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Master thesis pascal_mueller02

on

  • 533 views

 

Statistics

Views

Total Views
533
Views on SlideShare
533
Embed Views
0

Actions

Likes
0
Downloads
6
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Master thesis pascal_mueller02 Document Transcript

  • 1. 16 2. LINDENMAYER-SYSTEME wurden eindrückliche Szenarios geschaffen (Abbildung 2.9). Natürlich wurden in diesen Beispielen auch stochastische Verhaltensweisen in die Simulationen miteinbezogen. Abbildung 2.9: (3D-)Umgebungssensitives L-System. Links: Ein Skelett aus Linien und Ellipsoiden definiert eine implitzite Oberfläche. Rechts: Inner- halb dieser Oberfläche gewachsene Pflanzenstruktur. Dieses Beispiel führt vor, dass man zuerst intensiv die Eigenschaften eines Objektes studieren muss, bevor man es mit einem L-System simuliert. Die entsprechenden Regeln zu finden kann ziemlich anspruchsvoll und aufwendig sein, wie die vielen Beispiele unter- schiedlichster Pflanzenarten aus Lindenmayers und Prusinkiewicz’ Arbeiten zeigen. 2.7 Open L-Systems Interaktion mit der Umgebung ist ein wichtiger Aspekt in der Entwicklung von Pflanzen. Während in umgebungssensitiven L-Systemen nur die Reaktion der Pflanze auf ihre Umgebung simuliert wird, sind Open L-Systems in der Lage, beidseitige Kommunikation zu modellieren. Das bedeuted, die Pflanze kann nun auch Änderungen in der Umgebung bewirken. Deshalb wurden die Query-Module zu Kommunikations-Modulen der Form ?E(x1, x2, ... , xn) erweitert. Die Parameter x1, x2, ... , xn senden und empfangen Information der Umgebung. Zusätzlich wird der Umgebung immer der Status der Turtle (Position und Orientierung) mitgeliefert, d.h. dies muss nun nicht mehr explizit angegeben werden. Je grösser das Gleichungssystem zur Definition eines L-Systems wird, desto unüber- sichtlicher wird dieses. Deshalb wurden weitere Konstrukte eingeführt: • Produktionen können Zuweisungsstatements für lokale Variablen beinhalten. Diese Zuweisungen sind in geschweiften Klammern und durch Semikolons getrennt. • Das L-System kann Arrays verarbeiten. Auf einzelne Felder kann auf die selbe Weise wie in der Programmiersprache C zugegriffen werden. • Die Liste der Produktionen ist geordnet. Im deterministischen Fall wird die erste pas- sende Funktion ausgeführt. Dabei werden die Produktionen, wenn nicht anders ange- geben, von oben nach unten geprüft. Im stochastischen Fall bleibt alles beim Alten. Das folgende, umfassende Open L-System modelliert das Wachstum einer Wurzel. Haupt- aufgabe einer Wurzel ist das Beschaffen von Nährstoffen für die Pflanze. Durch das Aufsaugen von Wasser wird aber lokal die Wasserkonzentration im Boden vermindert, was Wasser- bewegungen im Boden verursachen kann (von wasserreichen zu entleerten Regionen). Währenddessen wachsen die Spitzen der Wurzel mehr oder weniger dem Gradienten der
  • 2. 2.7 OPEN L-SYSTEMS 17 Wasserkonzentration entgegen, den sie durch ihre Aktivitäten verändert haben. Es finden also komplexe Interaktionen zwischen Wurzel und Boden statt. Das Modell beschränkt sich wieder auf 2D. Zuerst werden die Funktionen der Kommunikations-Module erklärt, dann das Umge- bungsmodell (der Boden) und anschliessend das Open L-System, das die Wurzel simuliert. Kommunikations-Spezifikation: Die Pflanze interagiert mit der Umgebung mit Kommuni- kations-Modulen der Form ?E(c, θ), die in den Spitzen des Wurzelsystems zu finden sind. Der Parameter c repräsentiert die gewünschte (optimale) Menge Wasser, die die Spitze aufnehmen möchte, und der Wert θ gewichtet den Einfluss des Gradienten auf die Richtung, in der die Wurzelspitze wachsen soll. Hat die Umgebung die eingegangenen Daten verarbeitet, sendet sie mit c die tatsächliche Wassermenge, die die Wurzelspitze erhalten kann, und θ ist nun ein Winkel und beschreibt die Wachstumsrichtung. Umgebungsmodell: Die Umgebung ist ein Feld C von Wasserkonzentrationen, repräsentiert durch ein Array mit jeweils der Menge Wasser pro Volumeneinheit. Die Wasser- bewegungen im Boden folgen den Gesetzen der Diffusion und werden mittels finiten Differenzen numerisch berechnet. Auf eine Anfrage einer Wurzelspitze mit Position (i, j) nach Wasser reagiert die Umgebung folgendermassen: Der neue Wert für c, also die Menge Wasser, die die Wurzelspitze erhalten kann, wird bestimmt, indem man die gewünschte (cin) mit der an dieser Stelle verfügbare Menge Wasser vergleicht Abbildung 2.10: und den kleineren Wert auswählt. Anschliessend wird die Definition von θout. Wasserkonzentration an der abgetasteten Position um diesen Wert dekrementiert. Der zweite Parameter θ des Kommunikations-Moduls, die Richtung, in welche die Wurzelspitze weiterwachsen soll, wird berechnet wie in Abildung 2.10 dargestellt: Der Vektor T ist eine lineare Kombination des Vektors H, welcher Position und Richtung der Turtle repräsentiert, und des mit θin gewichteten Vektors ∇C, des Gradienten der Wasserkonzentrationen. θout ist dann der Winkel zwischen den Vektoren T und H. Wurzelmodell: Das Open L-System benutzt Arrays, um so unterschiedliche Parameterwerte für die drei verschiedenen Verzweigungstiefen zu lesen. Diese Parameterwerte basieren auf Biologie-Arbeiten über Wurzeln. #define N 3 /* max. branching order + 1 */ Define: { array Req[N] = {0.1, 0.4, 0.05}, /* requested nutrient intake */ MinReq[N] = {0.01, 0.06, 0.01}, /* minimum nutrient intake */ ElRate[N] = {0.55, 0.25, 0.55}, /* maximum elongation rate */ MaxLen[N] = {200, 5, 0.8}, /* maximum branch length */ Sens[N] = {10, 0, 0}, /* sensitivity to gradient */ Dev[N] = {30, 75, 75}, /* deviation in heading */ Del[N-1] = {30, 60}, /* delay in branch growth */ BrAngle[N-1] = {90, 90}, /* branching angle */ BrSpace[N-1] = {1, 0.5}, /* distance between branches */ } ω : A(0,0,0) ?E(Req[0],Sens[0]) p1 : A(n,s,b) > ?E(c,θ) : (s > MaxLen[n]) || (c < MinReq[n]) → ε p2 : A(n,s,b) > ?E(c,θ) : (n ≥ N-1) || (b < BrSpace[n]) {h = c/Req[n]·ElRate[n];} → +(nran(θ,Dev[n])) F(h) A(n,s+b,b+h) ?E(Req[n],Sens[n])
  • 3. 18 2. LINDENMAYER-SYSTEME p3 : A(n,s,b) > ?E(c,θ) : (n < N-1) && (b ≥ BrSpace[n]) {h = c/Req[n]·ElRate[n];} → +(nran(θ,Dev[n])) B(n,0) F(h) /(180) A(n,s+h,h) ?E(Req[n],Sens[n]) p4 : B(n,t) : t < Del[n] → B(n,t+1) p5 : B(n,t) : t ≥ Del[n] → [ +(BrAngle[n]) A(n+1,0,0) ?E(Req[n+1],Sens[n+1]) ] p6 : ?E(c,θ) → ε Die Entwicklung startet mit einem Apex A, gefolgt von einem Kommunikations-Modul ?E. Die Parameter vom Apex repräsentieren die Verzweigungstiefe, die momentane Länge dieser Achse und die Distanz zum letzten Verzweigungspunkt. Im den folgenden Abschnitten werden die Produktionen p1 bis p3 illustriert, die das mögliche Schicksal eines Apex’ beschreiben. Überschreitet die Länge s einer Achse mit Verzweigungstiefe n den vordefinierten Maximumwert MaxLen[n], oder reicht die erhaltene Menge Wasser c nicht mehr aus (d.h. liegt unter dem Minimum MinReq[n]), stirbt der Apex ab und die Wurzelspitze wächst nicht mehr weiter (Produktion p1). Ist die Verzweigunstiefe n gleich der maximalen Verzweigungstiefe N-1, oder die Distanz b zur letzten Verzweigung kleiner als die Schwelle BrSpace[n], generiert der Apex ein neues Wurzelsegment F (Produktion p2). Die Länge h von F wird berechnet, indem man das Ver- längerungsinkrement ElRate[n] mit dem Verhältnis zwischen erhaltener (c) und gewünschter (Req[n]) Menge Wasser multipliziert. Zuvor wird die Turtle um den Winkel nran(q,Dev[n]) gedreht, wobei nran ein Zufallszahlengenerator mit Normalverteilung ist. Die Standardab- weichung Dev[n] simuliert andere Einflüsse auf die Wachstumsrichtung der Wurzelspitze, die in diesem Modell nicht berücksichtigt wurden. Ist die Verzweigunstiefe n kleiner als die maximalen Verzweigungstiefe N-1, und die Dis- tanz b zur letzten Verzweigung gleich oder grösser als der Schwellwert BrSpace[n], so tritt Produktion p3 in Kraft, welche eine neue Verzweigung B generiert. Alles weitere läuft wie in p2 ab. Produktion p4 modelliert die Verzögerung von Del[n] Ersetzungschritten. Danach wird eine neueVerzweigung mit Apex und Kommunikations-Modul eingefügt (p5). Die letzte Produktion p6 ist dafür zuständig, die (oben gebrauchten) Kommunikations-Module zu löschen. Abbildung 2.11: 2D-Modell einer Wurzel, die mit dem Wasser im Boden interagiert. Die Hintergrundfarben illustrieren die Wasserkonzentrationen (Blau: hoch, Schwarz: tief).
  • 4. 2.7 OPEN L-SYSTEMS 19 Das Resultat der Simulation ist in Bild 2.11 dargestellt. Die Spitze der Hauptachse (Ver- zweigungstiefe 0) folgt, mit kleinen, zufälligen Abweichungen, dem Gradienten der Wasserkonzentrationen. Die Äste der höheren Verzweigungsebenen sind auf den Gradienten nicht sensitiv und haben eine grössere Standardabweichung. Durch die Wasseraufnahme der Wurzelspitzen werden lokale Regionen völlig entleert und können auch nicht mehr durch Dif- fusion (aus wasserreichen Regionen) aufgefüllt werden. Als Folge dieser tiefen Wasser- konzentrationen stoppt das Wachstum einiger Wurzelverzweigungen, noch bevor diese ihre volle Länge erreicht haben. Bild 2.12 zeigt eine dreidimensionale Erweiterung des vorher- gehenden Modells. Das linke Bild illustriert den Kampf zweier Wurzel um Wasser, was auch der Grund ist, weshalb die beiden sich immer mehr von einander entfernen. Rechts wachsen die Wurzeln langsamer, der Einflussbereich von jedem Wurzelsystem ist kleiner und die Haupt- achsen sind näher zusammen. Diese 2 Wurzelsysteme interagieren miteinander und benützen zur Kommunikation die Umgebung bzw. den Boden als Medium. Abbildung 2.12: Dreidimensionale Version des Wurzel-Modells. Wasserkonzentra- tionen werden durch halb-transparente Iso-Oberflächen dargestellt.
  • 5. 20 2. LINDENMAYER-SYSTEME
  • 6. 3System Architektur Das CityEngine System ist die Implementation der in Abbildung 3.1 dargestellten Pipeline: Im ersten Schritt werden die Eingabebilder in die CityEngine eingelesen, und ein für diese Zwecke erweitertes L-System generiert daraus ein Strassennetzwerk. Dieses kann mit dem Strassen- editor nachträglich verändert werden. Dann werden die Räume zwischen den Strassen in Grundrisse (Allotments) unterteilt, auf welchen die Gebäude platziert werden. Im vierten Schritt werden durch ein zweites L-System den Gebäudegrundrissen entsprechende Shape Grammar Strings generiert. Im letzten Schritt werden die Strings, welche die Formen der Gebäude beschreiben, interpretiert und als texturierte Geometrie ausgegeben. Die Geometrie- daten der virtuellen Stadt können schliesslich mit einem 3D-Renderer visualisiert werden. Abbildung 3.1: Die Pipeline der CityEngine. Die eingerahmten Boxen repräsen- tieren die Daten, welche die Tools in den schwarzen Boxen als Input respektive Output haben. 21
  • 7. 22 3. SYSTEM ARCHITEKTUR Die Eingabedaten, welche aus Graustufenbildern und Parametern bestehen, sind verant- wortlich für das Verhalten des gesamten Systems, also für das Aussehen der resultierenden vir- tuellen Stadt. Die Eingabebilder können durch Zeichnen oder Scannen von topographischen und statistischen Karten (wie in [9]) erstellt werden. Die Inputs lassen sich in folgende Kate- gorien unterteilen: • Topographische Karten: Wasser/Land, Vegetation (Parks), Elevation • Soziostatistische Karten: Populationsdichte, Landnutzung, Alter • Kontrollbilder: Strassenmuster Die ersten beiden Eingabebilder, Wasser/Land und Vegetation, werden binär interpretiert. Die Landnutzungskarte unterscheidet zwischen Residential, Commercial oder Industrial. Den rest- lichen Bildern können Skalierungswerte und Offsets übergeben werden. Abbildung 3.2 (links oben) zeigt von jeder Kategorie ein Eingabebild. Die Eingabeparameter können aus statis- tischen Datensammlungen entnommen oder abgeleitet werden. In [16] finden sich beispiels- weise Angaben zur Anzahl Kreuzungen pro Fläche, woraus die durchschnittliche Strassenlänge berechnet werden kann, welche ein Parameter der CityEngine ist. Die Parameter können jeder- zeit interaktiv verändert werden, wodurch das Verhalten des Systems beeinflusst werden kann. Ein erweitertes L-System, dessen Verhalten hierarchisch kontrolliert werden kann, generiert die Strassennetzwerke. Auf einer globalen Ebene des L-Systems, kann das Strassenmuster bestimmt werden (durch die Rules und deren Kontrollbilder), und auf einer lokalen Ebene kann beispielsweise bestimmt werden, wieviele Strassen maximal in einer Kreuzung münden. Der L-System Mechanismus wurde so erweitert, dass das Einbinden beliebig vieler Strassenmuster oder das Ändern von Parametern keine Modifikation der Produktionsregeln erfordert. Eine zusätzliche Erweiterung zu bestehenden L-Systemen wurde entwickelt, um Zyklen und Intersektionen im generierten Strassennetzwerk zu erkennen (selbstsensitive L-Systeme). Die Populationsdichte einer Stadt wird beeinflusst durch den Bau von Strassen [10]. Die inverse Interpretation dieser Tatsache benutzt das L-System um die Strassen zu kreieren. Nach [10], ändern aber nicht alle Strassen die Population in ihrer lokalen Umgebung (Beispiel: eine Strasse die zwei Städte miteinander verbindet). Deshalb verwendet das L-System zwei Arten von Strassen: Highways und Streets. Diese unterscheiden sich durch Funktion und Verhalten. Die Highways verbinden Regionen mit hoher Populationsdichte global, indem sie das Eingabe- bild absuchen. Die Streets bedecken, abhängig von der Populationsdichte, die Flächen zwischen den Highways, so dass der Zugang zu den Highways stets sichergestellt ist. Diese beiden Stras- sentypen zusammen bilden das Strassennetzwerk der virutellen Stadt (Abbildung 3.2 links unten). Ist das Strassennetzwerk kreiert, werden die Zwischenräume mit einem geometrischen Par- zellierungsalgorithmus in Allotments unterteilt. Auf den Grundrissen werden stochastische, parametrische L-Systeme ausgeführt, die die entsprechenden Shape Grammar Strings gene- rieren. Mit der CityEngine Shape Grammar kann die Form der Gebäude beschrieben werden. Der Benutzer programmiert diese L-Systeme und überwacht deren Verteilung. Dadurch kann er den Stil der Bauten in der virtuellen Stadt spezifizieren. Die Programmierung der L-Systeme fällt leicht, da die CityEngine Shape Grammar für derartige L-Systeme entworfen wurde. Der 3D-Interpreter, welcher die Strings parst, erzeugt Polygon-Geometrien mit Textur- kooridnaten, welche sich entweder für prozedurale Shader eignen oder planares Mapping erlauben. Die Geometriedaten können anschliessend in Alias¦Wavefronts Maya eingelesen wer- den. In Maya können den Geometrien Shader zugewiesen, eine Umgebung kann integriert und die Stadt kann visualisiert werden (siehe Abbildung 3.2 rechts).
  • 8. 23 Abbildung 3.2: Mit der CityEngine generierte virtuelle Stadt. Links oben: Drei der Eingabebilder (Elevation, Populationsdichte und Rule Kontrollbild). Links unten: Generiertes Strassennetz. Rechts: Gerenderte Geometrie.
  • 9. 24 3. SYSTEM ARCHITEKTUR
  • 10. 4Erzeugung der Strassennetzwerke 4.1 Das erweiterte L-System Um ein Strassennetzwerk zu generieren, wird ein kompliziertes L-System Regelwerk mit einer grossen Zahl von Parametern und Konditionen benötigt. Die Anzahl der Produktionen steigt rasch, und falls man neue Regeln implementieren will, müssen viele der bestehenden Produ- ktionen neu angepasst werden. Je grösser das L-System wird, desto unübersichtlicher und unflexibler wird es. Das L-System der CityEngine hat deshalb bloss noch eine ausführende Rolle, das heisst, es übernimmt nur noch die Produktion der Module. Das Bestimmen der Parameter wird von externen Funktionen kontrolliert. Das L-System ist ideal geeignet, um diese externen Funktionen hierarchisch zu ordnen. Da das L-System nur ein Template generiert und die Parameter nicht durch das L-System bestimmt werden, sind fast keine konditionalen Produktionen nötig. Dadurch wiederum wird innerhalb der Module die Anzahl der Parameter, die für das L-System sichtbar sein müssen, reduziert. Es resultiert ein sehr übersichtliches L-System, das nur noch die für die Wachstums- steuerung nötigen Komponenten beinhaltet (im Sinne von Datenstrukturen). Das generische Template, welches immer drei Strassenverzweigungen erzeugt, wird Ideal Successor genannt. Die Erzeugung einer Strasse in diesem L-System durchläuft folgende Phasen (siehe auch Abbildung 4.1): 1. Initiert werden neue Strassen durch den Ideal Successor. Dessen drei Verzweigungen bestehen aus Modulen, die je eine Strasse symbolisieren. Den Parametern dieser Module werden keine Werte zugewiesen. 2. Die externe Funktion globalGoals wird aufgerufen. Diese bestimmt die Parameter- werte der in Punkt 1 erwähnten Module. Mit dieser Funktion kann das Verhalten einer Strasse bezüglich ihres Wachstums auf einer globalen Ebene kontrolliert werden. 3. Die externe Funktion localConstraints wird aufgerufen. Die in Punkt 2 vorge- schlagenen Parameter werden von dieser Funktion überprüft. Falls die Strasse nicht in die lokale Umgebungssituation passt, wird versucht, deren Parameter entsprechend zu justieren. Ist es aus umgebungsbedingten Gründen unmöglich eine Strasse im System einzufügen, wird sie von dieser Funktion verworfen. 25
  • 11. 26 4. ERZEUGUNG DER STRASSENNETZWERKE Abbildung 4.1: Die Erzeugung einer Strasse. Die Bestimmung der Parameterwerte folgt hierarchischen Funktionen. Die Funktion globalGoals bewirkt, dass die Strassen einem globalen Muster folgen, und die Funktion localConstraints implementiert den umgebungssensitiven Teil eines L-Systems. Durch diese beiden Funktionen wird das Verhalten des L-Systems vollständig kontrolliert. Deshalb kann die Funktionalität des L-Systems erweitert werden, ohne dass die Produktionen verändert werden müssen. Das Regelwerk des L-Systems, das die Strassennetzwerke erzeugt, sieht folgendermassen aus: ω: R(0,initialRuleAttr) ?I(initRoadAttr,UNASSIGNED) p1 : R(del,ruleAttr) < ?I(roadAttr,state) : del < 0 → ε p2 : ?I(roadAttr,state) : state == UNASSIGNED {localConstraints(roadAttr) adjusts the parameters for: state, roadAttr} → ?I(roadAttr, state) p3 : ?I(roadAttr,state) : state != UNASSIGNED → ε p4 : R(del, ruleAttr) : del < 0 → ε p5 : R(del, ruleAttr) > ?I(roadAttr,state) : state == SUCCEED {globalGoals(ruleAttr,roadAttr) creates the parameters for: pDel[0-2], pRuleAttr[0-2], pRoadAttr[0-2]} → +(roadAttr.angle) F(roadAttr.length) B(pDel[1],pRuleAttr[1],pRoadAttr[1]) B(pDel[2],pRuleAttr[2],pRoadAttr[2]) R(pDel[0],pRuleAttr[0]) ?I(pRoadAttr[0],UNASSIGNED) p6 : R(del, ruleAttr) > ?I(roadAttr, state) : state == FAILED → ε p7 : B(del, ruleAttr, roadAttr) : del > 0 → B(del-1,ruleAttr,roadAttr) p8 : B(del, ruleAttr, roadAttr) : del == 0 → [ R(del, ruleAttr) ?I(roadAttr,UNASSIGNED) ] p9 : B(del,ruleAttr,roadAttr) : del < 0 → ε Das Axiom ω initialisiert das System mit einem Rule Modul R, gefolgt von einem Insertion Query Modul ?I. Diese beiden Module treten im L-System immer zusammen auf und repräsen- tieren eine Strasse. Der Parameter del des Rule Moduls bestimmt, ob eine Strasse exisitiert (del ≥ 0) und ruleAttr ist eine Sammlung von Parametern, die den Rules zum Übergeben von Werten dienen. Reichen also für die Programmierung einer Rule die lokalen Informationen und die Strassenparameter nicht, kann ruleAttr ein neues Element hinzugefügt werden. Mit dem Insertion Modul können, unabhängig vom Rule Modul, die Local Constraints überprüft werden. Der Eintrag roadAttr, welcher wie ruleAttr eine Sammlung von Parameter ist, beschreibt eine
  • 12. 4.2 GLOBAL GOALS 27 Strasse mit Parametern wie Winkel, Länge, Typ etc. Der Parameter state dient als Kontroll- element. Die ersten drei Produktionen kontrollieren das Insertion Modul. Falls eine Strasse gar nicht existiert (Parameter del des im Kontext stehenden R Moduls kleiner als Null), tritt Produktion p1 in Kraft, und das zugehörige Insertion Module wird gelöscht. Produktion p2 ruft die local- Constraints Überprüfung auf. Diese benötigt als Eingabewert die Strassenparameter (roadAttr), welche überprüft, und falls nötig, geändert werden. Als Rückgabewert erhält man neben den (evtl. angepassten) Strassenparametern die Variable state. Wenn die Strasse erfolgreich in der Umgebung eingefügt werden konnte, wird state auf SUCCESS gestetzt, andernfalls auf- FAILED. Produktion p3 sorgt aus folgendem Grund dafür, dass ein Insertion Modul nur zwei Ersetzungsschritte lang existiert: wurde die localConstraints Überprüfung durchgeführt (d.h. state != UNASSIGNED), werden die Werte in Produktion p5 aus dem Kontext gelesen, und das Insertion Modul wird nicht mehr benötigt. Die Produktionen p4 - p6 behandeln das Rule Modul. Existiert eine Strasse nicht (del < 0), wird diese durch die Produktion p4 gelöscht. Produktion p5 repräsentiert das Template des L-Systems, das für das Wachstum verantwortlich ist. Das Template fügt die von den Local Con- straints überprüfte Strasse ein (da state den Wert SUCCESS hat) und erzeugt drei neue Strassen: zwei Verzweigungen und eine Strasse “geradeaus”. Die Parameter der neuen Strassen werden von globalGoals (also den Rules) bestimmt: Als Eingabewert werden die Parameter der erzeugten Strasse (roadAttr) und ruleAttr benötigt. Als Rückgabewert erhält man drei neue Strassen in Form von Arrays (pDel[0-2], pRuleAttr[0-2] und pRoadAttr[0-2]). Durch das Tem- plate werden diese drei Strassen (respektive deren Module) in jedem Fall eingefügt. Dies erklärt auch den Sinn der Produktionen p1 und p4, welche die Module löschen, falls die Funktion glo- balGoals gar keine Strasse vorgeschlagen hat (pDel[0] < 0). Produktion p6 löscht das R Modul, falls die localConstraints Überprüfung negativ ausfiel. Die letzten drei Produktionen kontrollieren das Branch Modul B. Dieses Modul verzögert den Start des Wachstums einer Verzweigung, indem der Parameter del heruntergezählt wird (Produktion p7). Ist del gleich Null, tritt Produktion p8 in Kraft. Diese Produktion initiert eine neue Verzweigung mit den im Branch Modul gespeicherten Parametern ruleAttr und roadAttr. Wie beim Rule Modul, wird auch hier der Parameter del (zusätzlich) zur Überprüfung der Exis- tenz einer Strasse verwendet (Produktion p9): falls del < 0 ist, wird die Verzweigung nicht ini- tiert. 4.2 Global Goals Die Funktion globalGoals setzt die Initialwerte der Strassenmodule, indem alle aktiven Rules aufgerufen werden. Die Vorschläge jeder Rule werden entsprechend den Gewichten der Rules in einem einzelnen Vorschlag vereinigt. Das Gewicht bzw. der Einfluss einer Rule wird über ihr Kontrollbild bestimmt. Mit einer Rule kann das Erscheinungsbild eines Strassennetzwerkes kontrolliert werden, indem sich die Strassen dem von der Rule implementierten Strassenmuster anpassen. Abbildung 4.2 zeigt mögliche Strassenmuster (aus [7]). Eine Rule schlägt maximal drei neue Strassen für das Template vor: Eine Strasse ungefähr geradeaus, eine Strasse ungefähr nach links und eine Strasse ungefähr nach rechts. 4.2.1 Western Rule In [10], kategorisiert Füsser Strassen in zwei Klassen: Hauptstrassen (Highways) und siedlungs- orientierte Nebenstrassen (Streets). Ausserdem vergleicht er das Auftreten von rasterartigen Mustern mit dem von radialen Mustern: Erstere treten vor allem in polyzentrischen Städten auf
  • 13. 28 4. ERZEUGUNG DER STRASSENNETZWERKE Abbildung 4.2: Eine Auswahl von möglichen Strassenmustern. und radiale Muster findet man eher in monozentrischen Städten. Highways können beide Arten von Mustern repräsentieren, Streets hingegen treten nur in raster- bzw. schachbrettförmigen Strassenmustern auf. Deshalb bestehen die Strassennetze solcher Städte aus verschiedensten, beliebig zueinander angeordneten Schachbrettmustern mit unterschiedlichen Häuserblock- flächen. Die Grenzen zwischen diesen Mustern bilden Highways, die die Gleichförmigkeit der Muster unterbrechen [16]. Die Western Rule erzeugt derartige Strassenmuster. Wie weiter oben bereits erwähnt, verbinden die Highways Zentren hoher Populationsdichte miteinander. Die Western Rule korrigiert den Winkel eines Highway so, dass dieser der gröss- ten Populationsdichte folgt. Die Western Rule bestimmt diese Richtung, indem innerhalb des benutzerdefinierten Bereiches Strahlen mit zufällig geänderten Winkeln die ideale Route suchen. Entlang dieser Strahlen wird die Populationsdichte abgetastet. Jeder Wert wird mit der inversen Distanz gewichtet und aufsummiert. Die Richtung mit der grössten Summe wird schlussendlich vom Highway eingeschlagen. Abbildung 4.3 illustriert den Vorgang. Findet eine reine Highway-Verzweigung statt, wird dieser ein Wert mitgegeben (ruleAttr.branchDistance), der die Distanz bis zur nächsten Verzweigungen darstellt (gleich wie im L-System für die Wur- zeln in 2.7). Der Benutzer definiert sämtliche Parameter wie Längen, Winkel oder Wahrschein- lichkeiten (alle mit Standardabweichung). Abbildung 4.3: Links: Ein Strahl sucht die Richtung der höchsten Population. Rechts: Ein generiertes Highwaynetzwerk, das die Populations- zentren miteinander verbindet. Im Gegensatz zu den Highways folgen Streets nicht der grössten Populationsdichte, sondern einem Schachbrettmuster. Dieses wird durch Highways initiert, die nach links oder rechts eine Street-Verzweigung produziert haben. Dabei wird die Länge der Street und die Blockfläche des Schachbrettmusters (ruleAttr.area) bestimmt und für das L-System wird eine Verzögerung bestimmt, damit die Highways zuerst ihre Gebiete erschliessen können. Durch eine Länge und die Fläche ist das Aussehen des Schachbrettmusters festgelegt, und, nachdem der Delay runt- ergezählt wurde, beginnt das Schachbrettmuster zu wachsen. Der Benutzer kann bestimmen, wie regelmässig dieses aussehen soll. Wird eine Street eingefügt, dekrementiert sie an dieser Stelle die Population in einem Diffusionssystem mittels finiten Differenzen (gleich wie im L-System für die Wurzeln in 2.7). Sobald Streets auf Zonen ohne Population stossen, stoppt das
  • 14. 4.2 GLOBAL GOALS 29 Wachstum. Alle oben erwähnten Parameter kann der User kontrollieren. Abbildung 4.4 zeigt links den Strassenplan von San Francisco, auf dem zwei aufeinandertreffende Schachbrett- muster dargestellt sind. Rechts in der Abbildung wird ein mit der Western Rule generiertes Strassennetz gezeigt. Abbildung 4.4: Western Rule. Links: Ein Strassennetzausschnitt von San Francisco. Rechts: Ein generiertes Strassennetz. 4.2.2 Grid Rule Über die mit der Western Rule erzeugten Schachbrettmuster der Streets hat der Benutzer wenig Kontrolle, zumindest was deren Orientierung betrifft. Deshalb wurde die Grid Rule implemen- tiert. Highways und Streets verhalten sich hier nur noch nach geometrischen Regeln. Der Benutzer hat Kontrolle über das Schachbrett, indem er Position, Orientierung und Strassen- längen mit Standardabweichungen eingeben kann. Sind diesen Parametern Werte zugewiesen, wird das Gitter vollständig initialisiert. Die Strassen wachsen auf ähnliche Weise wie in der Western Rule, nur gibt es keine Winkelabweichungen und die Strassenenden schnappen auf die Gitterpunkte ein. Abbildung 4.5 zeigt links das berühmte Strassennetz von Manhattan. Rechts in der Abbildung sieht man eine mit der Grid Rule generierte Rekonstruktion dieses Strassen- netzwerkes. Abbildung 4.5: Grid Rule. Links: Ein Strassennetzauschnitt von Manhattan (NYC). Rechts: Ein generiertes Strassennetz (auch von Manhattan). 4.2.3 Radial Rule Neben der Grid Rule existiert noch eine zweite geometrische Rule: die Radial Rule. Diese Rule erzeugt die in Abbildung 4.2 illustrierten radialen bzw. konzentrischen Strassenmuster. Solche
  • 15. 30 4. ERZEUGUNG DER STRASSENNETZWERKE Strassenmuster sind vor allem in europäischen Städten zu finden (Paris, Brüssel). Dieses Stras- senmuster hat ähnliche Charakteristika wie das der Western Rule. Auch hier werden die schach- brettartigen verteilten Streets von den Highways unterbrochen [10]. Aus diesem Grund verhalten sich die Streets in dieser Rule gleich wie diejenigen der Western Rule. Die Highways werden, je nachdem wie ihr Winkel zum Zentrum ist, entweder in tangentiale oder radiale Rich- tung gelenkt. Das Zentrum der Ringstrassen wird vom Benutzer definiert. Abbildung 4.6 zeigt links einen Strassenplan des Zentrums von Paris, rechts ein mit der Radial Rule erzeugtes Strassennetzwerk. Abbildung 4.6: Radial Rule. Links: Ein Strassennetzausschnitt von Paris. Rechts: Ein generiertes Strassennetz. 4.2.4 Topographical Rule Die Strassenmuster von europäischen Städten reflektieren oft deren Topographie, indem die grösseren Strassen den Höhenlinien folgen [16]. Diese Eigenschaft wird mit der Topographical Rule simuliert, die wie die beiden geometrischen Rules auf der Western Rule basiert. Die High- ways und die längeren Streets eines Schachbrettmusters folgen der geringsten Steigung. Kür- zere Streets eines Schachbrettmusters folgen der grössten Steigung, falls diese nicht zu steil ist. Ein weiterer Unterschied zu Western Rule besteht darin, dass Highways, wenn sie sich ver- zweigen, meistens nur eine anstatt zwei Verzweigungen generieren. Das topographische Ver- halten wird an einer Position erst aktiviert, wenn eine minimale Steigung im Gelände vorhanden ist (und das Kontrollbild aktiv ist). Ist die Steigung in diesem Punkt kleiner als der vom Benutzer definierte Schellwert, verhält sich die Topographical Rule gleich wie die Western Rule. Abbildung 4.7 zeigt links das Strassennetzwerk von Zürich (aus [16]), indem anhand der Strassen erkennt werden kann, wie das Gelände rechts neben dem Fluss aufsteigt. Rechts in Abbildung 4.7 ist Strassennetzwerk abgebildet, das nur mit der Topographical Rule erzeugt wurde. Man kann deutlich erkennen wie in den flacheren Regionen das Western Rule Verhalten aktiv war. 4.2.5 Blending Falls an einer Position mehrere Rules aktiv sind (Kontrollbildwert > 0), werden zuerst alle aktiven Rules einzeln ausgewertet. Die vorgeschlagenen Parameter der Rules werden anschlies- send entsprechend ihrem Kontrollbildwert gewichtet und aufsummiert. Der folgende Pseudocode illustriert das Blending der Rules:
  • 16. 4.2 GLOBAL GOALS 31 Abbildung 4.7: Topographical Rule. Links: Ein Strassennetzausschnitt von Zürich. Rechts: Ein auf das Gelände projiziertes generiertes Strassennetz. // 1. Which branches in template exist? foreach Branch w = 0 foreach Rule if rule.branch exists w += rule.w else w -= rule.w if w > 0 branch exists // 2. Is it a Highway or a Street? foreach Branch which exists wHighway = wStreet = 0 foreach Rule if rule.branch exists if rule.branch.type == “HIGHWAY” wHighway += rule.w else wStreet += rule.w if wHighway > wStreet branch.wSum = wHighway branch.type = “HIGHWAY” else branch.wSum = wStreet branch.type = “STREET” // 3. Blend the rules foreach Branch which exists branch.par = {0,..,0} foreach Rule if rule.branch exists && rule.branch.type == branch.type branch.par += rule.branch.par * rule.w / branch.wSum Im ersten Teil des Codes wird überprüft, welche der drei Branches, die das L-System Tem- plate zur Verfügung stellt, existieren (da eine Rule nicht immer alle drei Branches vorschlägt). Dies wird für jeden der drei Branches einzeln entschieden, indem das Gewicht (Kontrollbild-
  • 17. 32 4. ERZEUGUNG DER STRASSENNETZWERKE wert) jeder aktiven Rule aufsummiert resp. subtrahiert wird. Ist der resultierende Wert grösser als Null, existiert der Branch. Anschliessend wird für alle existierenden Branches überprüft, ob es sich um einen Highway oder um eine Street handelt. Dies funktioniert ähnlich wie oben, nur werden hier zwei Gesamt- gewichte mitgeführt, da diese im dritten Teil, dem Blending, wiederverwendet werden. Nachdem für jeden Branch bestimmt wurde, ob er existiert und welchen Strassentyp er hat, findet das Blending für jeden Branch statt (falls dieser existiert). Dabei haben nur noch die- jenigen Rules Einfluss, die einen Branch vorgeschlagen haben (rule.branch exists) und den entsprechenden Strassentyp unterstützen. Mit den im zweiten Teil berechneten Gesamtgewicht werden (pro Branch) die vorgeschlagenen Parameter einer Strasse wie Winkel, Länge, etc. linear geblendet. Abbildung 4.8 zeigt ein Blending der beiden geometrischen Regeln. Abbildung 4.8: Blending von Rules. Links oben das Kontrollbild der Grid-Rule, links unten das der Radial-Rule und rechts das resultierende Stras- sennetzwerk. 4.3 Local Constraints Die Strassenparameter, die die Funktion globalGoals vorgeschlagen hat, werden von der Funk- tion localConstraints entsprechend der lokalen Umgebung justiert. Wenn immer ein Spezialfall auftaucht, wenn beispielsweise eine Strasse auf Wasser trifft, wird dies durch den umgebungs- sensitiven Teil der Funktion erkannt, und falls möglich, werden die Parameter geändert. Anschliessend muss überprüft werden, ob die (evtl. justierte) Strasse auf eine Andere trifft und eine Kreuzung gebildet werden muss. Dazu wurden L-Systeme um die Fähigkeit erweitert, Intersektionen mit schon bestehenden Ästen zu erkennen. Es entstanden die selbstsensitiven L-Systeme. Die selbstsensitive Überprüfung, die immer nach der Umgebungssensitiven stat- tfindet, bestimmt die definitiven Parameter einer Strasse. Konnte die Strasse in die Umgebung eingefügt werden, wird dies via Parameter state des Insertion Moduls dem L-System mitgeteilt. 4.3.1 Umgebungssensitivität Nachdem von den Rules eine Strasse vorgeschlagen wurde, passt die umgebungssensitive Über- prüfung die Strasse der lokalen Umgebung an. Bei einer einzufügenden Strasse liegt der Stras- senbeginn immer auf Land. Liegt das Strassenende im Wasser, in einem Park oder einer anderen illegalen Zone, wird versucht, die Strasse, bzw. deren Parameter, zu justieren: • Die Länge der Strasse wird solange bis zu einem gewissen Faktor gekürzt, bis das Stras- senende in einer legalen Zone liegt.
  • 18. 4.3 LOCAL CONSTRAINTS 33 • Misslingt dies, wird versucht, den Winkel der Strasse (mit ihrer vorgeschlagenen Länge) solange bis zu einem Maximalwinkel zu verändern, bis das Strassenende in einer legalen Zone liegt. Diese Überprüfungen werden für Streets und Highways gleichermassen durchgeführt. Schlagen aber beide Versuche der Justierung fehl, werden die beiden Strassenarten unterschiedlich behandelt: Streets werden verworfen, indem der Parameter state des Insertion Moduls auf FAILED gesetzt wird, womit die localConstraints Überprüfung beendet ist. Highways ist es hingegen erlaubt, Wasser zu überqueren und so Brücken zu bauen, indem durch Längen- und Winkeländerungen das andere Ufer gesucht wird. Falls dies gelingt, wird der Highway mar- kiert. Für Streets ist die umgebungssensitve Adjustierung nun abgeschlossen und die Strasse muss nur noch im selbstsensitiven Teil auf Kreuzungen untersucht werden. Die ersten beiden Spalten von Abbildung 4.9 illustrieren die Überprüfung Da ein Highway oft einer Küste entlang verläuft [16], wird dieser, falls bisher keine Para- meteränderungen stattgefunden haben, zusätzlich überprüft: • Befindet sich vor dem Strassenende Wasser, wird der Winkel des Highways in Richtung Küste geändert (obwohl sich der Highway auf legalem Gebiet befindet). • War dies nicht der Fall und befindet sich neben dem Highway Wasser, wird der Winkel leicht in Richtung Wasser geändert (obwohl sich der Highway auf legalem Gebiet befin- det). Die erste Überprüfung verhindert oft, dass Highways in Sackgassen enden. Jetzt können auch die (evtl. justierten) Parameter eines Highways der selbstsensitiven Überprüfung übergeben werden. Die beiden rechten Spalten von Abbildung 4.9 zeigen die Adjustierung der Highways. Abbildung 4.9: Umgebungssensitives Einfügen von Strassen. Oberen Reihe: Von den Rules vorgeschlagene Strassen. Untere Reihe: Nach der Adjus- tierung. 4.3.2 Selbstsensitive L-Systeme Da L-Systeme ursprünglich zur Generierung von Pflanzen entwickelt wurden, können mit den bestehenden L-Systemen nur verzweigende Strukturen erzeugt werden. Transport- oder Kom- munikationssysteme haben aber die Eigenschaft, dass sie zusammenwachsen und geschlossene Zyklen bilden (in einem Verkehrssystem beispielsweise sind Sackgassen die Ausnahme [7]). Deshalb wurden die selbstsensitiven L-Systeme entwickelt (ein ähnlicher Lösungsansatz wurde für die prozedurale Generierung von Blutbahnen verwendet [19]): Eine neue Verzweigung kann auf ein Segment des schon bestehenden L-Systems treffen, die Kollision erkennen, sich “verbinden” und so einen Zyklus bilden. Dadurch ändert sich die Topologie von einer baum- artigen zu einer netzwerkartigen Struktur. Weil der Erzeugung vom Strassennetzwerk kein