Proceduralmodellering af bymiljøer - Danmarks Tekniske Universitet

SPECIALE
Proceduralmodellering af
bymiljøer
Simon Tobiasen | DTU - Informatik
Vejleder: Niels Jørgen Christensen
26. maj 2010

Abstrakt
Dette projekt vil forsøge at belyse området for proceduralmodellering af bygninger og bymiljøer.
Proceduralmodellering bliver anvendt i stadigt bredere omfang inden for film og
computerspilindustrien. Begrebet dækker alle former for modellering af geometriske modeller til
brug i computergrafik ved hjælp af algoritmer.
På det seneste er det blevet muligt at genere bygninger og hele bymiljøer proceduralt. Dette skyldes
især anvendelsen af l-systemer og udviklingen af de såkaldte shape-grammaer. En shape-grammar er
en grammar, der ikke arbejder på strenge men på former (geometriske figurer), hvilket har vist sig
brugbart i forbindelse med analyse af arkitektoniske stilarter. I dette projekt har jeg implementeret
et system til proceduralmodellering af huse ved brug af shape-grammaer, og som udvidelse af dette
har jeg bidraget med en metode til effektiv modellering af huses tage, der kan fungere sammen med
de eksisterende metoder.
Min metode bygger på teorien bag polygonens straight-skeleton, der er en topologisk skeletinddeling
der kan bestemmes for alle polygoner. Ud fra brugerinput bygges en lagdeling af tagmodellen, og via
polygon-clipping opnås en yderst fleksibel og robust metode til proceduralmodellering af tage.
Abstract
This project will aim at making a thorough research in the field of procedural modeling of buildings
and urban environments. Procedural modeling is used increasingly in movies and computer games,
and it is a term that covers all sorts of algorithms, for modeling geometrical objects in computer
graphics.
Lately it has become possible to procedurally generate buildings and urban environments. This is
largely due to the utilization of l-systems and the development of the so called shape grammars. A
shape-grammar is a grammar which does not work with symbol strings, but operates directly on
shapes. These grammars have shown to be useful for analyzing architectural styles. In this project I
have implemented a system for procedural modeling of buildings using shape grammars, and my
contribution has been a method for efficient modeling of building roofs, that works well with the
existing methods.
My method extends on the polygonal straight skeleton, which is a topological skeleton subdivision
that can be applied to all polygons. From user input a layered roof model is constructed, and using
polygon clipping a highly flexible and robust method for procedural modeling of roofs is achieved.
2

Indhold
Abstrakt .......................................................................................................................................................2
Abstract .......................................................................................................................................................2
1 Fordord ................................................................................................................................................5
1.1 Anerkendelser .............................................................................................................................5
2 Indledning .......................................................................................................................................... 6
2.1 Formål ..........................................................................................................................................7
2.2 Afgrænsning ................................................................................................................................7
2.3 Overblik ...................................................................................................................................... 8
3 Baggrund ............................................................................................................................................ 9
3.1 Motivation .................................................................................................................................. 11
3.2 Erhvervelse af geometrisk data ................................................................................................. 14
3.3 Proceduralmodellering ............................................................................................................ 20
4 Litteraturstudie ................................................................................................................................ 29
4.1 Terminologi .............................................................................................................................. 29
4.2 Relateret arbejde ....................................................................................................................... 35
4.3 Teori .......................................................................................................................................... 68
5 Observationer, analyse og hypotese ................................................................................................ 78
6 Min metode ...................................................................................................................................... 82
6.1 Konstruktion ............................................................................................................................ 82
6.2 Implementering ........................................................................................................................ 97
7 Resultater ........................................................................................................................................ 106
7.1 L-systemer ............................................................................................................................... 106
7.2 Tage ........................................................................................................................................... 112
7.3 Modellering af bymiljøer .......................................................................................................... 131
8 Diskussion ....................................................................................................................................... 149
8.1 Overblik ................................................................................................................................... 149
8.2 Anvendelsesmuligheder .......................................................................................................... 152
8.3 Fremtidigt arbejde ....................................................................................................................155
9 Konklusion ...................................................................................................................................... 157
10 Bibliografi .................................................................................................................................... 158
Bilag 1: L-systemer ................................................................................................................................... 161
Fraktal- l-system (L-sys1.txt) ............................................................................................................... 161
3

Egetræ (Tree1.txt) ................................................................................................................................ 161
Fyrtræ 1 (Tree2.txt) .............................................................................................................................. 161
Bøgetræ (Tree3.txt) ............................................................................................................................. 162
Fyrtræ 2 (Tree4.txt) ............................................................................................................................ 162
Bilag 2: CGA-grammaer .......................................................................................................................... 163
Sears Tower (SearsTower.txt)............................................................................................................. 163
Petronas Towers (Petronas.txt) .......................................................................................................... 164
Kontorbygning (OfficeBuilding.txt)................................................................................................... 165
Villa (Mansion.txt) .............................................................................................................................. 168
4

Forord
Denne rapport dokumenterer gennemførelsen af et eksamensprojekt ved Danmarks Tekniske
Universitet, og er sidste krav for opnåelse af civilingeniørgraden.
Eksamensprojektet er blevet udarbejdet hos afdelingen for Computergrafik ved Institut for
Informatik og Matematisk Modellering, IMM, ved Danmarks Tekniske Universitet, DTU, under
vejledning af lektor Niels Jørgen Christensen.
Omfanget af dette projekt er svarende til 35 ECTS-point.
Anerkendelser
Først og fremmest vil jeg takke min vejleder Niels Jørgen Christensen for den kyndige vejledning, jeg
har modtaget, ikke blot i forbindelse med dette projekt, men gennem hele mit udannelsesforløb på
DTU. Det har altid været en lærerig fornøjelse, at deltage i kurser eller projekter med Niels Jørgen
som underviser og vejleder.
Dernæst vil jeg takke Bent Dalgaard Larsen for hans hjælp og vejledning i forbindelse med
struktureringen af denne rapport, og for inspirerende diskussioner under alle faser i projektet. Jeg vil
i denne forbindelse også takke min arbejdsgiver, Dalux, og Torben Dalgaard Larsen for at huse mig
under dele af projektforløbet.
Jeg vil derudover takke Mikkel Hempel for hans store hjælp og vejledning gennem mit studie, og
ikke mindst i forbindelse med dette projekt.
Erik Livermore skal have en særlig tak for samarbejdet under mit studie, og for at hjælpe mig med at
fjerne sprog- og stavefejl i denne rapport.
Til sidst vil jeg takke Anders Rong, Anders Scheel Nielsen, Henrik Münther, Carsten Kjær og Nick
Bruun for deres konstruktive kritik i forbindelse med projektet.
5

1 Indledning
Byer spiller i dag en stor rolle i computerspil og animationsfilm. De fleste mennesker bor og færdes
til dagligt i større byer, og det er kun naturligt, at dette afspejler sig i vores medier. Der er derfor et
større behov for realistiske gengivelser af bymiljøer, hvad enten disse er rekonstruktioner af virkelige
byer eller egentlige syntetiske byer. Problemet er, at bymiljøer ofte er overordentligt komplekse, og
indeholder hundrede eller tusindvis af bygninger, planter eller træer og andet inventar. Derfor er
emnet for dette projekt, efter min mening, et vigtigt forskningsområde.
Gennem tiden er der gjort en række forsøg på at løse dette problem ved hjælp af
proceduralmodellering.
I artiklen [Müller & Parish, Procedural Modeling of Cites, 2001], præsenteres en metode, der basere
sig på L-systemer, og udvider disse til at kunne modellere vejnet og bygninger. Vejnettene har vist
sig at være brugbare, men for bygningernes vedkommende har det vist sig, at arkitektur ikke
beskrives særligt godt med L-systemers, der er bedre egnet til at gengive modeller der er resultatet af
en fremvækst over tid. I [Greuter & Parker, Real-time procedural Generation of 'Pseudo Infinite'
Cities, 2003] beskrives et system der kan generer proceduralmodellerede bygninger meget hurtigt,
men uden tilstrækkelig geometrisk detaljering.
I [Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006] beskrives et system til proceduralmodellering
af bygninger, der er grammarbaseret. Metoden henter inspiration til sit brugsmønster i teorien om Lsystemer,
men anvender en afart af de såkaldte shape-grammaer. Systemet har vist sig at være bredt
anvendeligt, og resultaterne er af yderst høj kvalitet. Teknologien er forholdsvis ny, og der er stadig
en række problemstillinger, der bør adresseres. En af disse er, at metoden ikke håndterer tage på en
tilfredsstilende måde. Jeg vil i løbet af denne rapport redegøre for, hvorfor jeg mener, at tage er
centrale i en bygningsmodel, og hvorfor det derfor er relevant at beskæftige sig med dette område.
I [Aichholzer, Aurernhammer, Alberts, & Gärtner, 1995] introduceres begrebet straight-skeleton, der
er en skeletinddeling for polygoner udelukkende bestående af rette linjestykker. Det viser sig at
resultatet er velegnet til rejsning af tage. Ulempen ved brug af denne metode er, at den udelukkende
kan håndtere valmede 1 tage.
Hovedbidraget fra dette projekt er en metode, der på baggrund af simple inputparametre kan rejse et
tag fra en bygnings grundplan. Metoden bygger på teorien for straight-skeleton, er yderst fleksibel og
kan bl.a. håndtere alle typiske danske tagtyper. Jeg vil derudover redegøre for hvordan denne
metode, kan integreres med min implementering af metoden beskrevet i [Müller, Wonka, Haegler,
Ulmer, & Van Gool, 2006] og på den måde skabe en hidtil uset variation i proceduralgenererede
bymiljøer.
Projektet vil altså omhandle proceduralgenerering af bygninger, og især kompleksiteten ved
modellering af bygningers tage. Dette projekt vil desuden indbefatte en undersøgelse af den aktuelle
litteratur inden for det pågældende område. Metoden, der er fremstillet gennem dette projekt, vil
1 Tag der udelukkende har skrå sider. Se Tabel 1, side 31
6

ygge på eksisterende algoritmer, og forbedre disse på områder hvor de ikke giver tilfredsstillende
resultater.
1.1 Formål
Jeg vil nu opridse de mål, jeg vil arbejde imod, og som dette projekt i sidste ende skal bedømmes ud
fra.
Målet med dette projekt vil være, at undersøge området for proceduralmodellering af bymiljøer og
herefter, at udvikle en metode, der sætter arkitekter, designere, 3d-modellører og ingeniører i stand
til at modellere bymiljøer på baggrund af en bred vifte af inputdata med et minimum forbrug af tid.
Dette projekt vil hovedsageligt fokusere på modellering af huse, deres facader og specielt deres tage.
For tagenes vedkommende bør metoden kunne håndtere de mest almindelige danske tagtyper. En
mere udførlig gennemgang af de tage der er målgruppe for dette projekt, angives i Tabel 1 (side 30).
Derudover skal det være muligt at kombinere disse tagtyper, hvorved man kan modellere typer som
f.eks. et mansardtag med halvvalmet gavl.
Resultatet af metoden skal være bygninger der overholder parametriske begrænsninger så som
matrikelskel og bygningshøjde. Der lægges vægt på, at metoden er procedural, hvilket vil sige at
brugeren ikke har fuld kontrol over det endelige resultat. Derimod skal brugeren være i stand til at
modellere arketyper for huse eller facader, og derefter angive hvilke parametre der skal være
tilfældige.
Metoden bør være i stand til at tage input af varierende karakter. Jeg forestiller mig følgende
brugerscenarier:
Kort og matrikelstyrelsen (KMS) har opbygget en stor mængde GIS data over Danmark,
heriblandt grundplaner (polygoner) for hver eneste registrerede bygning i landet. Dette er
tilfældet for langt de fleste lande i verden. En arkitekt skal således være i stand til at hente
disse data dækkende et specificeret område, og via metoden ekstrudere bygningerne til 3dmodeller.
Det bør være muligt at angive specifik facade eller tagtype, hvis dette er ønskeligt.
Ved modellering af hele byer, skal en designer kunne skitsere vejnettet for byen, hvorefter
metoden sætter ham i stand til at fylde områderne mellem disse med bygninger.
I nogle tilfælde vil designeren have større kontrol over det endelige resultat. Derfor skal
denne være i stand til at forsyne systemet med en bygningsmodel (massemodel), og derefter
angive facade og tagtype.
1.2 Afgrænsning
Dette projekt vil ikke behandle aspekter omhandlende proceduralmodellering af byers vejnet. Her vil
jeg henvise til udmærkede resultater i [Chen, Esch, Wonka, Müller, & Zhang, 2008] og [Müller &
Parish, 2001].
En stor del af den forskning der foregår i dette område, omhandler rekonstruktion af arkitektur fra
billeddata. Målet for denne gren af forskningen er, at rekonstruere nøjagtige repræsentationer af
virkelige byer. Billedanalyse og vision vil ikke være en del af dette projekt.
7

1.3 Overblik
Denne rapport skal redegøre for arbejdet i forbindelse med dette eksamensprojekt.
I afsnit 2, Baggrund, vil jeg gå mere detalje med baggrunden for dette projekt, og derefter beskrive
min motivation for arbejdet.
I afsnit 3, Litteraturstudie, vil jeg give en fyldestgørende gennemgang af den litteratur der allerede
findes for området. Derudover vil jeg undersøge kommercielle systemer, der anvendes i industrien.
Endelig vil jeg gennemgå den relevante teori der vil blive anvendt i dette projekt.
I afsnit 4, Observationer, analyse og hypotese, vil jeg opridse og konkludere på min gennemgang af
det relaterede arbejde. Afsnittet skal tjene som bindeled mellem det relaterede arbejde og min egen
metode.
I afsnit 5, Metode, vil jeg præsentere den metode der er blevet udviklet i løbet af dette projekt, og
som er denne rapports bidrag. Jeg vil desuden gennemgå de implementeringsspecifikke
problemstillinger på et mere overordnet plan.
I afsnit 6, Resultater, vil jeg gennemgå resultaterne der er produceret med min metode. Disse vil,
grundet metodens karakter, hovedsageligt være kvalitative.
Endelig vil jeg i afsnit 7, Diskussion, diskutere mine resultater og redegøre for metodens anvendelse
og perspektiv.
Til rapporten medfølger en CD, der indeholder kildekode, eksekverbare filer for alle applikationer
produceret under dette projekt, alle artikler refereret i dette projekt og alle figurer og diagrammer
præsenteret i denne rapport. Desuden indeholder CD’en over 250 billeder, der enten er skærmdumps
fra applikationerne eller renderede billeder. Billederne dokumenterer mit arbejde og de resultater jeg
har opnået, og er ordnede i kronologisk rækkefølge. Et overblik over Cd’en findes i filen readme.txt i
roden af CD’en. Indholdet kan også findes på www.student.dtu.dk/~s042624/eksamensprojekt/.
Læseren af denne rapport forventes at have en grundlæggende forståelse for almindelig teori i
forbindelse med computergrafik, svarende til IMM-kursus 02561 (Computergrafik) og 02566
(Rendering). Derudover er det nødvendigt med grundlæggende viden vedrørende linear-algebra og
beregning på geometrisk data. Endelig er det en fordel hvis læseren har kendskab til 3d modellering
og animation, svarende til kursus 02565. Imidlertid vil mange detaljer i dette projekt blive beskrevet
mere udførligt for at inkludere en bredere læserskare.
8

2 Baggrund
3d computergrafik anvendes i stigende grad inden for film, TV, arkitektur, medicin, simulering,
design, byplanlægning, computerspil og virtual reality. Dette muliggøres især af den rivende
udvikling af særligt dedikeret accelererende hardware, og i mange tilfælde er visualisering af
kompleks data i 3d efterhånden helt uundværlig.
Begrebet computergrafik dækker metoder til visualisering af data ved alt andet end tekst og lyd.
Oftest indebærer visualisering en projektion af geometrisk data fra 3d til 2d. I realtidsrendering
rasteriseres herefter et billede i en punktrepræsentation svarende til skærmens opløsning.
Efterfølgende tildeles overfladen farve, hvilket indebærer en simulering af interaktionen mellem lys
og materiale, samt en mere eller mindre realistisk simulering af lysets udbredelse i den omgivne
scene hvori objektet befinder sig.
Figur 1: Forsimplet rendering-pipeline. Input er geometrisk data, der transformeres og projiceres til
skærmkoordinatsystemet, hvorefter billedet rasteriseres og shades.
Dette er de nødvendige skridt, men oftest indgår desuden bl.a. dybde-sortering/check, alphablending,
clipping og anti-aliasing-sampling. Den samlede proces kaldes ofte for en renderingpipeline,
og kan kort sammenfattes således: Ind sender man geometrisk data, og ud kommer et
syntetiseret skærmbillede. Dette er i hovedtræk det samme som ved f.eks. rendering med raytracing.
Kvaliteten af det producerede billede er afhængigt af dets endelige opløsning, materiale- og
lys-simuleringens kvalitet, grafikerens evner og geometriens kompleksitet. Dette projekt vil
omhandle generering og modellering af geometrisk data, frem for visualisering.
Udviklingen indenfor grafikhardware har i de seneste år givet programmører mulighed for at
projicere en større mængde geometri samt sample teksturer et højere antal gange per frame.
Samtidig har man bevæget mod en unified shader-arkitektur, hvor vertex og pixel-shadere afvikles på
de samme shader-processings-enheder. Computergrafik er stærkt paralleliserbart, hvilket har
betydet at grafikkortenes regnekraft er øget markant. For CPU’er taler man om en fordobling i
regnekraft hvert andet år. For grafikkort er denne trend tre gange så hurtig: En fordobling i GPU’ers
regnekraft for hver 8. måned [Hanrahan, 2005].
Den øgede regnekraft har naturligvis givet mulighed for mere detaljerede eller fotorealistiske
renderinger med en meget høj grad af realisme. I dag ser man ofte egentlige approksimationer af
global illumination i de mest moderne realtids-grafik-engines.
9

Figur 2: Udviklingen af detaljegrad i modeller fra Unreal engine 1(1998), Unreal engine 2 (2002) og Unreal engine 3
(2009). Udover tilføjelsen af forskellige effekter, såsom normal-maps, er antallet af polygoner i modellen vokset
dramatisk.
Umiddelbart er dette en positiv udvikling for brugere og udviklere af applikationer indeholdende
computergrafik. Problemet er dog, at i takt med at hardwaren gør det muligt at tegne stadig mere
imponerende miljøer, stiger forventningerne i samme takt hos brugerne. Hver ny spiludgivelse,
forventes at have højere grafisk kvalitet end de foregående. De seneste grafikkort fra Nvidia kan
projicere, rasterisere og shade 300 millioner trekanter i sekundet. Med 30 billeder i sekundet kan
scener således indeholde op til 10 millioner trekanter. Ved brug af level of detail, occlusion culling og
accelererings strukturer, er muligheden for detaljering derfor overvældende, og det er en stigende
udfordring at producere så omfattende scener af en rimelig kvalitet [Greuter & Stewart, 2004].
Den mest almindelige tilgang til denne udfordring er at ansætte flere grafikere. Problemet er, at
produktiviteten ikke nødvendigvist er proportionel med antallet af personer der arbejder på et givent
projekt [Kelly & McCabe, 2007]. Af økonomiske hensyn er denne løsning derfor ikke for alvor
holdbar. I dette projekt vil jeg således undersøge metoder, der kan hjælpe film og
computerspilsproducenter i denne proces.
10

2.1 Motivation
Da spillet Grand Theft Auto IV (Rockstar North) udkom i 2008 var det med sine
produktionsomkostninger på omkring 100 millioner $ (omtrent 550 millioner kr.) det dyreste
computerspil nogensinde produceret [Andreovich, 2008]. Pengene var tjent ind i løbet af den
følgende weekend, men spillet er et eksempel på en, for spiludviklere bekymrende udvikling.
Omkostningerne for at udvikle spil der kan markere sig i markedet er i eksplosiv vækst. Ifølge
[Takatsuki, 2007] er gennemsnittet for omkostninger (fraregnet marketing) til udvikling af et spil til
Playstation 3, 15 mio$. Det er mere end 10 gange så meget som for spil til Playstation 2, og 20 – 50
gange så meget som for Playstation 1. Til sammenligning kostede pacman (Namco) 100.000 $ at
udvikle i 1982.
mio $
16
14
12
10
8
6
4
2
0
Pacman Ps1 Ps2 Ps3
Figur 3: Udvikling i gennemsnitlige omkostninger for spilproduktion.
Når en sådan udvikling har kunne lade sig gøre og været rentabel, hænger det naturligvis sammen
med at omsætningen i spilindustrien samtidig er vokset markant. Her har spilindustrien for længst
overhalet filmindustrien i USA. Det skyldes i høj grad højere salgstal, men også en stigning i prisen
hos forbrugeren. En præmieretitel koster i USA omkring 60$, og i Danmark er det ikke usædvanligt
at se titler til 500-550 kr. Ifølge [Aberinkulas, 2009] er man her ved at nå smertegrænsen hos
forbrugeren.
En af konsekvenserne ved denne udvikling er, at profitmarginen for mange spil bliver stadig mindre.
En udgivelse er dermed forbundet med større risiko for investorer, hvilket fører til, at udviklerne er
mindre villige til at satse på radikalt nytænkende spil. Ofte lukrerer man på såkaldte franchises, som
alene på grund af navnet vil have høje salgstal (f.eks. Hitman 1, 2, 3 osv. fra danske IO interactive eller
Fifa spillene fra EA sports). Desuden er de høje omkostninger en alvorlig barriere, for nye udviklere
der ønsker at komme ind på markedet.
Forbes har analyseret spilbranchen og set på omkostningerne i forbindelse med spiludvikling til den
nye generation af konsoller [Rosmarin, 2006]:
11

Marketing; 11%
Konsolproducen
ter; 12%
Generelle
udgifter; 1%
Fabrikation og
distribution; 7% Lisens;
5%
Detailhandel;
20%
Overskud;
0,2%
Design og
visuelt indhold;
25%
Programmering
og software; 20%
Figur 4: Graf der viser hvordan pengene fordels når forbrugen har købt et computerspil. Kilde: Forbes
Design og modellering udgør klart den største post på budgettet. Mange spilproducenter har, i stedet
for at udvikle egen software, valgt at benytte 3.-partsprodukter (middleware), som f.eks. gameengines
eller fysik-engines, hvorved softwareposten bliver mere eller mindre fastlåst. Derfor er det
oplagt at forsøge at optimere produktionen af visuelt indhold. For at imødekomme publikums
forventninger, må film og spil-studier derfor forbedre deres værktøjer og metoder til fremstilling af
3d-modeller. Her er proceduralmodellering en oplagt kandidat [Wonka, Wimmer, Sillion, &
Ribarsky, 2003].
2.1.1 Tagmodellering
Når dette projekt især vil fokusere på modellering af tage, skyldes det en række observationer jeg har
gjort i forbindelse med mit arbejde hos Dalux. Ved flere lejligheder har vi haft brug for at modellere
tage ud fra meget simple parametre. Først og fremmest er tage en vigtig komponent for bygningens
arkitektoniske fremtoning. Derudover dækker taget ofte en meget stor del af bygningens
klimaskærm. Vil man f.eks. beregne boligens samlede varmetab, må man have en rimelig
approksimation af tagets geometri, da denne beregning er baseret på det samlede areal.
I web-applikationen energikoncept.dk, der blev udviklet af Dalux for SBS, i samarbejde med det
rådgivende ingeniørfirma Cowi, kan almindelige brugere modellere deres ejendom via meget simple
parametre. Først vælges en bygningstype, f.eks. længeejendom eller karré. Herefter vælges tagtype,
f.eks. saddeltag eller valmtag. For disse komponenter angives parametre såsom højde, bredder og
taghældning.
12

Figur 5: Brugerflade fra energikoncept.dk
Når vi kender bygningens form, f.eks. L-formet, kender vi implicit tagets topologi, og vi kan dermed
konstruere tagets geometri. Problemet er at hver kombination af tag og hustype kræver sin eget
dedikerede funktion. I energikoncept havde vi 3 hustyper og 3 tagtyper, hvilket resulterede i 9
kombinationsmuligheder. Hvis vi ønsker at tilføje en ny bygningstype, vokser antallet af
kombinationer svarende til antallet af tagtyper, og omvendt. Ydermere er der ofte en stor mængde
specialtilfælde der skal håndteres. F.eks. er gavlens placering i en L-bygning med saddeltag afhængig
af hvilken længe der er bredest (Figur 6). Lignende problemer ses i udpræget grad, jo mere
kompliceret tagformen er.
Figur 6: Problemet med placering af gavl i L-bygninger med længer af varienrende bredde.
13

For at holde os inden for en rimelig udviklingstid, har vi derfor hos Dalux valgt at indføre en række
begrænsninger på husenes udformning. F.eks. skal længerne i et L-formet hus altid være lige brede.
Løsningen er helt klart utilfredsstillende:
Kun et begrænset sæt bygningstyper er understøttet. Langt de færreste bygninger falder f.eks.
nøjagtigt under kategorierne i energikoncept (I, L og O).
Koden vokser voldsomt ved indførelse af nye typer.
Der indføres uhensigtsmæssige begrænsninger i frihedsgraderne for selv de mest basale
tagtyper.
Den optimale fremgangsmåde må være at finde en generisk tagmodel, der tager vilkårlige bygningers
grundplaner som input, og producerer et tags geometri ud fra få konceptuelt simple parametre.
2.2 Erhvervelse af geometrisk data
Inden for computergrafik er geometrisk modellering et lige så komplekst forskningsområde som
rendering af disse modeller [Rotenberg, 2005]. Producenter af film og computerspil har en række
forskellige muligheder for erhvervelser eller produktion af geometriske modeller. Disse metoder har
forskellige anvendelsesmuligheder inden for forskellige domæner, hvor de hver især har specielle
fordele, men de kompenserer samtidig også i nogen grad hinanden.
2.2.1 Interaktive modelleringsværktøjer
Brug af software der lader brugeren direkte bearbejde geometrisk data er måske den mest
ligefremme måde at producere geometrisk data. I denne forbindelse dækker området alt fra simple
vektortegneprogrammer, over mere avancerede så som autocad eller store 3d-modellerings-pakker
så som revit eller 3Ds-Max. Et af de simpleste og mest udbredte modelleringsværktøjer, de fleste har
stiftet bekendtskab med, er, Microsoft Word der indeholder et simpelt vektortegneprogram.
14

Figur 7: Brugerfladen fra Autodesk Revit Architecture. Ofte er modelleringsværktøjer meget komplekse og
overvældende for nybegyndere.
Udvalget af disse systemer er enormt, og variationen i kompleksitet og arbejdsgangen ved brug af
disse spænder vidt. I mange tilfælde er udgangspunktet en 2d skitsering, f.eks. på baggrund af et
fotografi, der evt. ekstruderes til 3d og forfines. Ofte editeres et mesh enten direkte, eller med
geometriske operationer og transformationer.
Fordelen ved modelleringsværktøjer er, at de giver designeren fuld kontrol over resultatet. Ulempen
er imidlertid, at de mere avancerede systemer efterhånden er meget omfattende og svære at mestre,
hvilket kræver lang uddannelse og øvelse. Desuden er interaktiv modellering meget tids- og
ressourcekrævende.
2.2.2 Scanning
En scanner kan være en laser-, ultralyds-, CT- eller MRI-scanner, der generer rå data i form af enten
punktsæt eller skalarfelter (voxels). Herefter genskabes enten geometrien ved marching cubes, eller
topologien ved mesh-rekonstruktion med f.eks. delaunay-triangulering.
Fordelen ved scanning er at man opnår en meget nøjagtig gengivelse af et fysisk objekt. Ofte er dette
en forudsætning i forbindelse med anvendelsen af modellen. Et eksempel er den danske virksomhed
3shape, der sælger scannere til tandlæger. Udstyret skanner afstøbninger af tænder, hvorefter
medfølgende software kan bruges til, at modellere proteser eller broer der passer nøjagtigt til
15

patientens eksisterende tandsæt. Herefter sendes tegningen til en fabrikant, der producerer protesen
efter 3d geometrien.
Ulempen er, at modellerne ofte er ikke-regulære, åbne og rigide, hvilket begrænser deres anvendelse
i f.eks. underholdningsindustrien. Desuden har modelløren ingen direkte kontrol over det endelige
resultat.
Figur 8: 3d laser-skanner. Objektet roteres på en pedistat i et mørkekammer.
2.2.3 Vision og billedanalyse
Ved stereofotogrammetri er det muligt at skabe 3d modeller fra dybdeinformationen i stereofotos.
Ved at tage billeder fra to forskellige positioner, kan man ud fra oplysninger om kameraets nøjagtige
position, orientering og fotogrammetriske egenskaber, beregne en stråle der starter i kameraets
fokuspunkt og fortsætter gennem billedplanet i en given pixel. Udpeger man det samme punkt i
hvert billede vil strålerne netop krydse hinanden ”under” disse punkter. Vil man kende punktets
virkelige position er det altså et spørgsmål om at finde skæringen mellem de to stråler. Udpegningen
af punkter kan automatiseres ved mønstergenkendelse, hvilket genererer et meget stort punktsæt.
Dette sæt kan trianguleres på samme måde som ved f.eks. skanning.
Metoden har traditionelt været anvendt til rekonstruktioner af terræn eller hele bymodeller.
Fordelen ved metoden er at man hurtigt, f.eks. ved hjælp af fly, kan generere meget store modeller.
Ulempen er, at man umiddelbart kun kan konstruere højdefelter (2d kort med højdedata), derudover
er præcisionen i metoden ofte utilfredsstillende. Dette kan dog forbedres med et højere antal
kameraer, men man er efterhånden gået over til egentlige laserskanninger fra fly, når man vil
producere højdekort.
16

En afart af metoden kan ses i Microsofts Photosynth, hvor uøvede kan uploade en stak fotos. Herefter
vil programmet generere en punktsky uden at kende kameraets position eller orientering. Denne
punktsky anvendes til præcist at placere billeder i forhold til hinanden, og derved skabe en særlig
tredimensionel oplevelse.
Figur 9: Brugerflade fra microsoft fotosynth.
2.2.4 Proceduralgenerering af indhold til film og spil
I computerspillenes ungdom blev proceduralgenerering anvendt for, at overkomme et af datidens
store problemer: Computeres meget begrænsede hukommelse. Meget simple algoritmer blev
anvendt til f.eks. at generere spillets baner i real-tid (”on-the-fly”). Dermed kunne man tilbyde langt
større baner end man ellers havde mulighed for. Pseudotilfældige tal blev ofte anvendt, og en
kompleks model kunne dermed repræsenteres ved et enkelt seed til en tilfældig-tal-generator.
Proceduralgenereret indhold i et spil er, alt der ikke er prægenereret af en designer eller modellør. I
den bredest tænkelige forstand kan man f.eks. betragte fysiksimulering som procedural genereret
indhold, da det erstatter prægenererede animationer eller scripts. På samme måde finder man ofte
proceduralgenererede animationer, hvilket kan være alt fra rag-dolls, bone-animation, karakterer der
er i stand til at rejse sig fra akavede positioner og animation af alle former for bevægelser, såsom at
kunne gå, flyve, køre bil osv. (som set i spillet Spore fra EA games).
Brug af stokastiske algoritmer spiller desuden ofte en rolle for selve gameplayet, især for spil der
omhandler udforskning af ukendte miljøer, hvor spiloplevelsen er afhængig af, at man ikke kender
vejen til mål på forhånd. Dermed er hver gennemspilning af et spil eller en enkelt bane unik fra gang
17

til gang. Et eksempel på dette er spillet Diablo fra 1997, hvor en underjordisk labyrint genereres
tilfældigt, og missioner (quests) vælges stokastisk fra en pulje af mulige opgaver. En simpel version af
denne type algoritmer der roterer og tilfældigt placerer tiles, kan ses hos [Lang, 2010].
Figur 10: Tilfældigt generert dungeon, bestående af 3x3 tiles.
I filmindustrien har man i mange år benyttet computergrafik til at skabe effekter og scener af enhver
art. Man bruger normalt offline-rendering hvilket stiller højere krav til detaljegraden, hvorfor
modellører ofte ”snyder”, og indsætter den samme model flere steder i en scene. I virkeligheden
findes der ikke to nøjagtigt ens objekter. I et supermarked vil to dåser tomater f.eks. have forskellige
typer skrammer eller misfarvninger i større eller mindre grad. Sammen med den sterile materialerendering
der ofte anvendes i computergrafik, virker miljøerne derfor alt for perfekte, og dermed
ikke virkelighedstro. Filmen Tron var en af de første til at bruge computergrafik i udpræget grad. Ken
Perlin, der arbejdede på filmen nævner, at han selv var utilfreds med filmens ”maskinagtige”
udseende (hvilket inspirerede ham til hans berømte noise-algoritme) [Perlin, 1999]. Derfor benytter
filmindustrien i dag proceduralmodellering til at lave ”uperfekte” modeller.
18

Figur 11: Billede fra filmen Tron fra 1982.
I mange tilfælde er regulariteten for ens objekter tydelig (Figur 12). Selv når objekterne placeres
tilfældigt, med varierende farvenuancer, virker scenen ensartet og kedelig. Dette kan være direkte
ødelæggende for ”virkelighedsopfattelsen” (eller suspension of disbelief) i mange spil. Her er det ikke
længere et spørgsmål om farve eller nuance, men om selve strukturen af objektet. Denne effekt er
meget lig opfattelsen af teksturer der ”tiler”. I moderne film og computerspil forventer publikum
højere kvalitet, og derfor benytter man f.eks. L-systemer til at proceduralmodellere hele skove, hvor
hvert eneste træ er unikt. I dette projekt vil variationen af proceduralmodellerede objekter være et
centralt begreb, der også vil blive taget i betragtning når metoder til proceduralmodellering vurderes
i afsnit 6 (Resultater).
19

amplitude er defineret ud fra udfaldsrummet for de tilfældige tal. Bølgelængden er afstanden mellem
punkterne, eller rettere skaleringen af feltet.
Figur 13: 1D noise, interpoleret mellem punkter af tilfældige tal.
For at opnå en mere interessant funktion kan man addere forskellige noise-funktioner med
forskellige amplituder og bølgelængder. Dette sker i en iterativ proces der gradvist mindsker både
amplitude og bølgelængde, hvor hver iteration kaldes en oktav. Den samlede funktion kaldes ofte
turbulens [Bourke, 2000].
+
Bølgelængde
+
=
+
Figur 14: Summering af oktaver af noise for et 2D højdekort.
Amplitude
Noise har mange anvendelser, bl.a. til procedurale teksturer, rendering af skyer, røg og ildeffekter,
terrængenerering, volumetriske teksturer og rendering af f.eks. touchsstreger.
+…
21

Figur 15: Terragen er et program der genererer landskab, vand og skyer, næsten udelukkende ved brug af noise.
2.3.2 Fraktaler
En uformel definition på et fraktal er, et irregulært geometrisk objekt, der udviser selvsimilaritet i et
uendeligt antal underinddelinger. Dvs. en figur, hvor man kan blive ved med at zoome ind, og stadig
genfinde den samme overordnede form. Fraktaler genkendes overalt i naturen, f.eks. i: skyer,
snefnug, bjergkæder, lyn, kystlinjer og i planter.
”When each piece of a shape is geometrically similar to the whole, both the shape and the cascade
that generate it are called self-similar.”
-Benoît B. Mandelbrot
Computere er velegnede til syntetisering af fraktaler, og f.eks. begrebet rekursivitet afspejler i nogen
grad fraktalers selv-similaritet. Derfor er det oplagt at benytte fraktaler til at modellere de
ovenstående fænomener. Man vil sjældent bruge egentlige fraktaler med uendelig detaljering i
proceduralmodellering, men ideer og koncepter kan anvendes og giver gode resultater. Figuren i en
fraktal kan være irregulær og tilfældig. En kystlinje set i et satellitfoto vil f.eks. virke ujævn og takket.
Når vi zoomer ind vil detaljegraden øges, men vi vil fortsat finde ujævnheder magen til dem vi så før.
22

Figur 16: Venstre: Computergenereret udgave af Koch’s snefnug-fraktal. Højre: En krydsning mellem broccoli og
blomkål, udviser forbløffende fraktale strukturer.
2.3.3 Generative metoder
For generativ modellering er målet at opbygge et fælles format, der beskriver tredimensionelle
objekter, ikke ved deres geometri såsom punkter, kanter og sider, men ved det sæt af operationer
hvorved de er produceret. Disse operationer kan f.eks. være simple transformationer, deformationer,
extruderinger, sweep-operationer og boolske operationer. Operationerne gemmes i et hierarki, der
på den måde beskriver et objekt. Grundelementerne er ofte geometriske primitiver såsom kasser,
kugler eller pyramider.
En fordel ved generativ modellering er, at man kan komprimere meget store modeller til meget små
filer. Filstørrelsen følger ikke nødvendigvis kompleksiteten i modellen. Et eksempel er modelleringen
af en katedral med over 7 millioner trekanter, der kun fylder 18 kb generativ kode [Havermann,
2005].
23

Figur 17: Katerdral med 7 millioner trekanter, kan komprimeres til 18 kb via GML.
2.3.4 Grammar-baserede metoder
En formel grammar består af et sæt symboler (alfabetet), og et sæt produktionsregler (produktioner)
der kan omskrive strenge formet af symboler i alfabetet. En grammar siges at definere et sprog, og
reglerne bestemmer hvilke ord (strenge) der kan genereres i sproget. En grammar fortæller intet om
betydningen af ordene der kan formes, kun deres sammensætning.
En grammar der indeholder symbolerne a, b og S kan f.eks. have følgende form.
1. S -> aSb
2. S -> ba
Hver produktion er nummereret. Før pilen angives forgængeren, og efter angives strengen der skal
erstatte denne. Regel 1 sige dermed at S skal erstattes med aSb. Hvis vi starter med startsymbolet S,
kan vi f.eks. vælge regel 1, hvilket vil give os strengen aSb. Herefter kan vi igen erstatte det nye S via
en af produktionsreglerne osv.. Denne proces fortsætter indtil strengen ikke længere indeholder et S
(i dette tilfælde når vi har valgt regel 2). Længden af den endelige streng er derfor afhængig af
hvornår regel 2 vælges, og sættet af mulige strenge er derfor uendeligt:
{ba, abab, aababb aaababbb, …}
S er i dette tilfælde en non-terminal, der per konvention skrives med versal, og a og b er terminaler,
der skrives med små bogstaver. Den resulterende streng efter afledning af en regel kaldes under
tiden for den aktuelle konfiguration.
Ofte bruges en grammar, når man vil definere (eller rettere genkende) f.eks. et computersprog,
strukturen af kommunikationsbeskeder eller et filformat. Aristid Lindenmayer viste hvordan
24

Figur 19: Eksempel på stokastisk parametrisk L-system.
L-systemer er et meget bredt område, og der findes utallige variationer over syntaksen, f.eks.
kontekstsensitive og åbne L-systemer.
28

3 Litteraturstudie
Dette afsnit er resultatet af mit litteraturstudie. Observationer og metoder beskrevet her, vil blive
anvendt i det videre arbejde med min egen metode. Jeg vil indledningsvis introducere de begreber
der er almindelige i forbindelse med dette område. Dernæst vil jeg beskrive artikler, specifikt
omhandlende det forudgående arbejde i forbindelse med proceduralmodellering af bymiljøer og
modellering af tage. Endeligt vil jeg gennemgå den teori, der vil blive anvendt i mit videre arbejde.
3.1 Terminologi
Dette projekt fokuserer specielt på bygninger, bygningsdele og arkitektur, desuden anvendes
algoritmer, metoder og teori fra geometriens verden. I dette afsnit vil jeg derfor gennemgå centrale
termer fra disse områder.
3.1.1 Tagtyper
Tage er centrale for dette projekt, derfor følger her benævnelser, for de mest almindelige tagformer i
den vestlige verden. Begreberne er løse og varierer i litteraturen. Jeg har derfor sammenfattet en
mere omfattende oversigt, så misforståelser undgås. Jeg har desuden forsøgt at oversætte mellem
engelsk og dansk, da min prototype vil være på engelsk. Jeg vil for følgende referere til [lsas, 2010]
[bobvila, 2010] [husrådgivning, 2010]
Fladt tag / Flat roof
Det flade tag er det simplest tænkelige tag, og er per definition
parallelt med grundplanet. Et egentligt fladt tag ses sjældent, da
det ikke leder vand væk, hvormed der kan opstå vandskader.
Derfor har taget ofte en meget svag hældning eller afrunding.
Saddeltag / Gable roof
Et saddeltag har gavle i endesiderne. For et rektangulært hus er der
som oftest tale om de to korteste sider. Et saddeltag er defineret
ved at have lodrette gavle.
Valmet tag / Hip roof
Et valmet tag er et tag hvor alle gavle har en hældning, oftest den
samme som resten af taget. Denne tagtype er solid og mere
modstandsdygtig mod kraftig vind end f.eks. saddeltaget.
Halvvalm / Half hip
En halvvalm er en gavl der starter lodret som et saddeltag og
knækker til en valm i toppen. En gavl af denne type kan også
benævnes efter, hvor knækket sidder. En gavl der afkortes med 1/3
kaldes således ”1/3 dels valm” [husrådgivning, 2010]. Tagetagen er
ofte beboet, og taget kombinerer således fordelene ved valmtage
og saddeltage.
29

Hollandsk gavl / Dutch gable
En hollandsk gavl (eller nedsænket gavl) er omvendt i forhold til
en halvvalm, idet den starter som en valm, men knækker til en
lodret gavl i toppen. Det ses ofte, at de resterende tagflader
knækker til en lavere hældning ved gavlens knæk.
Pyramidetag /Pyramid roof
Pyramiden er et kendt geometrisk objekt, men for tages
vedkommende er der tale om en underkategori af den valmede
tagtype, med uniform taghældning anvendt på en kvadratisk
grundplan.
Mansardtag / Mansard roof (Gambrel)
Mansardtaget har sit navn fra arkitekten François Mansard, der
ofte anvendte det i sine byggerier. Taget består af en nederste del
med en meget høj, næsten lodret, hældning, der brækker til en
meget lav hældning. Den nederste del huser ofte en beboelig kvist,
og under kvistvinduerne har taget ofte en opskalk eller afrunding.
På engelsk skelner man ofte mellem et mansardtag og en gembrel,
hvor gambrel har lodrette gavle, og masardtaget har en næsten flad
øverste del. Gambrel har ingen dansk oversættelse (bortset fra det
uformelle ”bedstemor-and-tag”).
Pulttag / Shed
Denne tagtype anvendes ofte for meget smalle bygninger. Ofte
sammenbygges to pulttage, det ene højere end det andet, hvormed
man har mulighed for placering af vinduer over det ene tag.
Tabel 1: Oversigt over tagtyper
30

3.1.2 Tagets dele
For taget er der en række fagudtryk der vil blive benyttet i rapporten. Her vil jeg referere til
[husrådgivning, 2010]
Tagrygning / kip Kvist Skotrende Grat
Tagkant /
vindskede
Tagkant / tagfod /
tagskæg
Figur 20: Tagets dele
[denstoredanske, 2009]
Rygningen er den øverste kant på taget, og er ofte dækket af et konisk eller vinklet dække. En
tagkant er alle kanter, der ikke er sammenføjninger mellem tagflader. Ved gavle er der ofte en planke
der skærmer undertaget for vind. Denne kaldes en vindskede. De nederste kanter kaldes også for
tagfod, og et udhæng betegnes tagskæg. Konvekse kanter kaldes grat, og konkave kanter kaldes
skotrender. En kvist benævnes ofte ved dens tagtype. I tilfældet i Figur 20 er der tale om en
saddelkvist.
Den nederste del af taget (f.eks. de to nederste rækker tagsten) har ofte en lavere hældning end
resten af taget. Denne detalje kaldes opskalk, og har som regel udelukkende æstetisk betydning
[denstoredanske, 2009].
31

Figur 21: Opskalk
3.1.3 Polygonen
Polygonen er et grundbegreb i geometrien. En polygon i planet består af et sæt punkter, der er
forbundet af et sæt kanter. I denne rapport vil vi kalde et punkt i en polygon for en vertex (spids).
For en polygon gælder det altid, at hver vertex er forbundet til nøjagtigt to forskellige andre punkter
gennem en kant. Dermed er en polygon altid en lukket figur, og der er altid nøjagtigt én vertex for
hver kant. Det simpleste polygon er en trekant, og polygoner kan navngives efter antallet af kanter.
En refleks-vertex (konkav vertex) er en vertex, hvis indre vinkel er større end π. I det modsatte
tilfælde kaldes punktet under tiden en konveks vertex.
Kant
Vertex
Refleks-vertex
Polygonens indre
Figur 22: Konkavt sekskantet polygon.
Polygonens ydre
3.1.3.1 Klassificering af polygoner
Udover navngivning ved antallet af kanter klassificeres polygoner i følgende grupper:
32

Konvekst polygon
For hvert punkt i polygonens indre, kan alle andre punkter i
polygonen nås med en ret linje, uden at krydse polygonens
ydre kant. Polygonen indeholder derfor udelukkende
konvekse punkter.
Regulært polygon
Alle kanter og alle vinkler er ens. Disse polygoner er altid
konvekse.
Ikke-konveks
Der findes mindst to punkter i polygonens indre, der ikke
nås med en ret linje, uden at krydse polygonens ydre kant.
Polygonen indeholder mindst én refleks-vertex.
Simpel polygon
Polygonens kant krydser ikke sig selv.
Konkav
En ikke-konveks simpel polygon.
Stjerne-formet
Der findes mindst ét punkt i polygonens indre, hvorfra alle
andre punkter kan nås.
33

Monoton
En polygon siges at være monoton med hensyn til en akse L,
hvis enhver linje ortogonal til L, skærer polygonens ydre kant
højst to gange.
Tabel 2: Klassificering af polygoner
34

punkter i S. Diagrammet markerer skillelinjer i planet hvor afstanden til de nærmeste naboer er ens
(Figur 24).
Figur 24: Eksempel på voronoidiagram. Punkterne er inputsættet og de stiplede linjer er partitionslinjerne for
planet.
Et voronoidiagram for et punktsæt kan betragtes som en graf, og vil udelukkende bestå af rette
linjer. Hvis man introducerer andre former, f.eks. kanter og polylinjer, vil diagrammet indeholde
kurver. Medial-aksen mellem et punkt og en kant er f.eks. en parabel:
Figur 25: Medial-aksen mellem punkt og kant
Ved skeltonisering af polygoner med medial-akser opstår der således kurvede kanter ved reflexpunkter:
36

Figur 26: Medial-skelet af konkavt polygon. Bemærk den kurvede kant i medial-grafen ved polygonens refleksvertex.
Denne opstår som medial mellem det pågældende punkt og de overfor liggende kanter.
Mange grafiske systemer har problemer med at håndtere kurvede kanter, og derfor har man i denne
artikel søgt en metode, der udelukkende producerer grafer med rette kanter. I [Aichholzer &
Aurenhammer, 1996] har man generaliseret metoden til, at håndtere plane retlinede grafer frem for
udelukkende plane retlinede polygoner. Jeg vil udelukkende betragte straight-skeleton for polygoner.
Input til metoden er et sæt kanter G, der sammen udgør et polygon. I voronoidiagrammet har alle
punkter samme euklidiske afstand til to eller flere figurer i G. Dette er ikke tilfældet for et straightskeleton.
Hvis man betragter bølgefronter der bevæger sig med samme hastighed fra alle kanter i G,
vinkelret på kanten, vil man opdage at skæringerne mellem disse bølgefronter følger
vinkelhalveringslinjerne mellem de indbyrdes kanter i G (Figur 27).
37

Figur 27: Eksempel på bølgefront-udbredelsen ved et simpelt polygon. De stiplede linjer er bølgefronter ved
forskellige intervaller. De prikkede linjer er vinkelhalveringslinjerne i polygonet.
Som det fremgår af Figur 27 følger punkterne i en bølgefronts-polygon vinkelhalveringslinjerne, og
længden af kanterne i en bølgefront vil enten øges eller mindskes under udbredelsen. Dette
fortsætter, så længe bølgefronterne ikke ændrer deres indbyrdes topologi. En ændring sker i to
tilfælde (events):
1) Edge event. En bølgefront kollapser til et punkt.
2) Split event. En bølgefront deles når en vinkelhalveringslinje rammer den, og det
tilbageværende areal deles i to.
Figur 28: Venstre: Edge-event. Højre: Split-event.
Som følge af en event, er der opstået et nyt forskudt polygon, og dermed et nyt sæt bølgefronter.
Metoden forsætter derefter på samme måde med de nye fronter. Et straight-skeleton S(G) for en graf
G kan således defineres som stykker af vinkelhalveringslinjer der spores langs alle bølgekanter
38

gennem denne process. Stykkerne af vinkelhalveringslinjer kaldes arcs, og deres endepunkter, som
ikke er en del af den oprindelige figur G, kaldes knuder. Hver knude er et resultat af enten en spiltevent
eller en edge-event. S(G) er unik og entydig for et polygon G.
Figur 29: Straight-skeleton med bølgefronter, for de indadgående vinkelhalveringslinjer i et simpelt polygon.
I artiklen præsenteres en algoritme der gennem udbredelsen af bølgefronterne, opretholder en
triangulering af den del af planet det endnu ikke er nået af en bølgefront. Trianguleringen
indeholder udelukkende punkter fra de aktuelle bølgekanter, og opdateres ved hhv. en split-event og
edge-event.
Polygonen i Figur 26 har følgende straight-skeleton:
Figur 30: Venstre: Straight-skeleton for et konkavt polygon. Højre tagmodel rejst fra samme straight-skeleton.
Ligesom voronoidiagrammet kan et straight-skeleton vægtes, ved at lade bølgefronter udbrede sig
med forskellige hastigheder. I artiklen foreslås det derfor, at metoden kan benyttes til rejsning af
39

tage, over bygningers grundplan. Hvis tidspunktet (t) for en knudes event noteres, kan dette
efterfølgende bruges som punktets højde i den tredje dimension (Figur 23). En bemærkelsesværdig
egenskab ved et tag, rejst fra et straight-skeleton er, at uanset hvor en regndråbe måtte lande på
taget, vil den altid falde nedad mod den kant i G, der definerer den pågældende flade. En tømrer vil
på samme måde forsøge at bygge et tag, der leder vandet væk, så det ikke samler sig i fordybninger.
Derfor er netop et straight-skeleton, særligt velvalgt som tag-modellering-metode.
3.2.2 Automatically Generating Roof Models from Building Footprints
[Laycock & Day, 2003]
I denne artikel beskrives en metode til at rejse tage på bygninger ud fra deres grundplans-polygon.
Metoden er især rettet mod rekonstruktion af byer udelukkende fra GIS-data, ved en simpel
ekstrudering af grundplanet. Problemet er i den forbindelse, at tagenes geometriske kompleksitet
tidligere har gjort automatisering umulig.
Metoden tager udgangspunkt i grundplanets
straight-skeleton. Ved at finde den projicerede
afstand fra hvert punkt i skelettet til deres
oprindelige (nærmeste) kanter i bygningens
grundplan, kan man ud fra en
hældningsparameter (f.eks. 45°) finde punktets
højde, og på den måde rejse et tag fra et straightskeleton
(Figur 31). Samme fremgangsmåde
foreslås af [Bélanger, 2000] og [Aichholzer,
Aurernhammer, Alberts, & Gärtner, 1995]. Dette
forudsætter uniform hældning, og muliggøre
dermed kun valmede tage. I artiklen beskrives
derfor en metode til detektering af gavlpolygoner i
det valmede tag (simple trekantede polygoner, der
er fremkommet som følge af en edge-event). Disse
polygoner rejses til lodret, hvorved et saddeltag kan
konstrueres. Mansardtaget kan findes ved at
skrumpe grundplanet med en given længde, og
Figur 31: Rejsning af tag fra bygningens
grundplan
derefter bygge et straight-skeleton fra det oprindelige polygon, sammen med det skrumpede.
Artiklen bemærker, at mange virkelige tage er sammensatte, f.eks. som følge af tilbygninger, og der
beskrives en metode til inddeling af bygningens grundplan i underområder, der hver især tildeles en
40

tagmodel, og som endeligt flettes sammen til et samlet tag. Metoden virker kun for retvinklede
bygninger, og starter med at splitte bygningen lodret og vandret ved hvert refleks-punkt. For hver
rette linje i skelettet (rygning), indsamles de lokale underinddelinger der ligger inden for rygningens
bounding-box. Der fortages til sidst en set-difference på felterne, hvorved underinddelingernes
integritet sikres.
3.2.3 Towards fully automatic generation of city models
[Brenner, 2000]
Figur 32: Tages kompleksitet. (a) Grundplaner og deres valide tage. (b) Antallet af skæringspunkter. (c) Punkter
der ligger inden for grundplanet. (d) Skæringspunkter tilbage efter discrete relaxation. (e) Antallet af skridt i
søgning med discrete relaxation. (f) Antal skridt I signing uden discrete relaxation.
I mange konkrete tilfælde har man udover GIS-data desuden luftfotos og scanningsdata, til rådighed
når man vil rekonstruere en by. I denne artikel beskrives en metode, der kombinerer scanningsdata
og GIS-data til at opnå resultater, der ellers ikke er mulige udelukkende ved brug af én type data.
Artiklen er i denne sammenhæng relevant, da den bygger på en generalisering af begrebet straightskeleton.
Man kan i stedet for at betragte vinkelhalveringslinjer i polygonen, forestille sig et
hældende plan for hver kant i polygonen, hvor kanten ligger i planet, der skråner ind i polygonen
(altså tagfladernes planer). Ved skæring mellem to af disse planer findes en kant, og ved skæring
mellem tre eller flere planer findes en vertex. Hvis vi forbinder disse punkter med hinanden via de
fundene kanter på alle tænkelige måder, finder vi et sæt grafer. Antallet af resulterende grafer er
afhængigt af grundplanets kompleksitet, men en stor del af de disse er ikke valide tage. De
resterende er valide og én af graferne er polygonens straight-skeleton.
Som det fremgår af Figur 32, kan kompleksiteten hurtigt blive meget stor. Derfor reduceres antallet
af valide punkter ved en såkaldte discrete relaxation, hvor hvert punkt mærkes (efter om de er
konkave eller konvekse) og iterativt evalueres, opdateres og eventuelt forkastes.
En vigtig betragtning i denne artikel er, at selvom vi kender grundplanet og hældninger tilknyttet
hver kant i dette, er der flere løsninger på tag-problemet udover polygonens straght-skeleton.
Metoden giver ingen bud på hvordan mere komplicerede tage, såsom mansard-taget kan modelleres.
Anvendelsen af scanningsdata ligger desuden uden for mit eget projekts rækkevidde.
41

3.2.4 Real-time Procedural Generation of `Pseudo Infnite' Cities
[Greuter & Parker, 2003]
Figur 33 Bymodel syntetiseret i realtid
Greuter og Parker fremlægger i denne artikel en metode til syntese af uendeligt store byer i realtid,
især rettet mod computerspil. Argumentet er, at begrænsninger i spillerens bevægelsesfrihed ofte
virker unaturlige og ødelæggende for spiloplevelsen [Greuter & Stewart, 2004].
Grafikkort renderer udelukkende geometri, der ligger inden for et view-frustum. Hvis scenen
inddeles i kvadrater kan man nøjes med at opretholde geometri der er synligt i et givet øjeblik. Hver
gang et kvadrat indtræder i view-frustum, genberegnes den pågældende bygning ud fra pseudotilfældige
tal. Seeded til de tilfældige tal udledes af bygningens position, hvormed der opnås
konsistens i scenen.
Bygningerne består af lag af grundplaner. Disse grundplaner består af sammensatte polygoner, og
ekstruderes med tilfældig længde til bygningsmasser. Processen er iterativ, og starter ved den øverste
etage. Den foregående grundplan bruges som input til den næste iteration, hvor et nyt tilfældigt
polygon sammenlægges med den eksisterende figur (Figur 34). Herefter findes uv-koordinater til
facaderne, så det passer med et helt antal vinduer (hvor ét vinduesfag har uv-koordinater mellem 0
og 1).
En bemærkelsesværdig fordel ved metoden er at den letter presset på båndbredden mellem CPU og
harddisk, da geometrien produceres ”just-in-time”. Dette er i mange tilfælde et betydeligt argument
for proceduralmodellering.
42

Figur 34 Iterativ afledning af bygning
3.2.5 Citygen: An Interactive System for Procedural City Generation
[Kelly & McCabe, 2007]
Figur 35: Proceduralmodelleret by.
43

Denne artikel beskriver et system til proceduralmodellering af bymiljøer inklusiv deres vejnet. Målet
har været at bygge en algoritme der kan afvikles i realtid, hvilket muliggøre en interaktiv
modelleringsproces. Genereringsprocessen inddeles i følgende 3 skridt:
1. Overordnede vejnet / hovedveje genereres.
2. Underordnede vejnet / sideveje genereres.
3. Bygninger genereres.
Vejnettet er repræsenteret ved en adjacency-graf, hvor hver knude er et vejkryds, og hver kant en vej.
Brugeren forsyner systemet med knuderne og topologien til hovedvejene. Hovedvejene inddeler
landet i celler, der uddrages fra grafen via en Minimum Cycle Basis (MCB) algoritme. Når en celle er
fundet, bliver den udfyldt med sideveje der bestemmes med udgangspunkt i forskellige
grundmønstre. Der kan tilføjes støj for at give varians eller mere naturlige mønstre.
Generering af bygninger foregår i tre underskridt:
1. Celler for sidevejene findes (også via MCB).
2. Cellerne underinddeles til parceller.
3. Bygninger ekstruderes og teksturerers.
Bygningerne ekstruderes direkte fra parcellens grundplan. Afhængigt af zonetype vil grundplanet
blive skrumpet, hvorved der er plads til haver og grønne områder. Ved ekstrudering opstår der et
massivt objekt, der altid har fladt tag. For at angive facadedetaljer til objektet, teksturerers det med
facadetekstur og normal-map.
Figur 36: Ekstruderet massiv bygning med facadetekstur.
3.2.6 Rapid modeling of complex building façades
[Finkenzeller & Schmitt, 2006]
44

Figur 37: Modellering af bygning, udelukkende baseret på information tilknyttet grundplanet for hver etage.
Denne artikel omhandler modellering af bygninger, med særligt fokus på deres facader. Forfatterne
beskriver et system der skal lette arbejdsbyrden for designere under modellering af bygninger
markant. Der lægges vægt på, at designeren skal have kontrol over hver del af det endelige produkt, i
den udstrækning han måtte ønske det.
Metoden tager udgangspunkt i det faktum, at de fleste bygninger kan opfattes som en stak af etager
med hver deres ydre facade. En etage er repræsenteret ved en konveks polygon (grundplan), der igen
kan være sammensat af flere underpolygoner kaldet floor plan module (fpm). Hver kant i et fpm er
behæftet med information om dens facade. Designprocessen består således i, at designeren forsyner
systemet med en grundplan, indeholdende facadeinformation, for hver etage. Hver kant kan nu
ekstruderes til en væg og erstattes med geometri. I det konkrete system repræsenteres geometrien i
et LOGO lignende sprog, hvorved det kan tilpasse sig forskellige skaleringer.
Metoden gør desuden brug af det faktum at hver etage minder om den foregående. Designeren
behøver derfor udelukkende angive eksplicitte ændringer fra en lavere etage til den næste. Disse
ændringer kan f.eks. være fjernelse eller tilføjelse af en fpm eller ændring i facadetypen. Systemet
sørger selv for, at uændret information siver videre fra etage til etage.
Resultatet er en træstruktur der repræsenterer bygningen: Bygningen består af et sæt etager, der
hver består af et sæt fpm’er, der hver består af et sæt kanter og så videre. For den øverste etage
indeholder hver fpm, information om tagtypen. Disse tage rejses, og samles endeligt til et komplet
tag.
3.2.7 Procedural modeling of cities
[Müller & Parish, Procedural Modeling of Cites, 2001]
45

Figur 38: Bymiljø proceduralmodelleret med L-system.
I denne artikel beskrives et system til modellering af bymiljøer i deres helhed, altså også inklusiv
vejnettet. Systemet består overordnet af to dele: Første del genererer, med udgangspunkt i kortdata,
et vejnet i form af en graf. Anden del skaber bygninger ud fra de parceller, der udgøres af vejnettets
underinddeling af landet. Begge dele baserer sig på L-systemer, hvor vejnettet umiddelbart bærer
mest lighed med den traditionelle anvendelse af L-systemer, da der her er tale om en slags forgrenet
vækst.
Systemets overordnede struktur, kan sammenfattes i følgende figur:
46

3.2.7.1 Modellering af vejnet
Systemet til generering af vejnet, tager som input geografisk data i form af billeder. Dette kan f.eks.
være kort der bestemmer:
Parker, hav og områder hvor
veje ikke forekommer.
Terrænhøjde.
Zoner med forskellige
vejmønstre.
Befolkningstæthed.
Input:
Geografisk billeddata
Generering af vejnet
Udvidet L-system
Inddeling i parceller
Subdivision
Generering af bygninger
L-system
Generering af geometri
L-system parser
Vejnet
Graf
Parceller
Polygoner
Bygninger
Streng
Geometri
Polygoner
Figur 39 Overblik over city-engine systemet. Hver fase producerer et output, der anvendes
som input til den næste fase. Det endelige output er en geometrisk model af en hel by,
komplet med veje og bygninger.
Modelleringsprocessen består således i at grafikeren designer kortdata, der herefter bliver sendt til
systemet. Grafikerens kontrol over den endelige model består i det nævnte kortdata, samt en række
globale parametre.
Systemet baserer sig grundlæggende på et L-system. Ifølge artiklens forfattere er et problem ved
grammarbaserede metoder, at det sjældent er muligt at indføre nye begrænsninger, uden at det får
konsekvenser for hele sættet af produktionsregler. Man taler om en kombinatorisk eksplosion, hvor
antallet af produktionsregler og deres kompleksitet vokser eksponentielt. For at undgå sådanne
vanskeligheder, har man i dette system valgt at bygge et generisk L-system. Systemet lader de
betydeligste parameterfelter stå tomme, og genererer dermed en såkaldt ideel efterfølger til den
foregående konfiguration. I stedet for at prøve at modificere parametrene i selve
Output
Figur 40 Eksempler på input kort.
47

produktionsreglerne eksporteres dette til eksterne funktioner. På den måde, kan antallet af
produktionsregler holdes på kun 9, og man opnår derved et mere koncist og overskueligt system.
Evalueringen af parametrene opdeles i to på hinanden følgende trin: Indledningsvis rettes
parametrene, så de følger globale tendenser. Efterfølgende rettes vejene ind efter lokale forhold. De
globale tendenser kan f.eks. være, at vejene bevæger sig mod områder med høj befolkningstæthed,
eller bevæger sig i særlige mønstre såsom ringveje eller gittermønstre. De lokale begrænsninger kan
f.eks. være det eksisterende vejnet. I en by er den blinde vej et særsyn. Derfor må l-systemet være
selv-sensitivt. Dette opnås med såkaldt åbent l-system [Prusinkiewicz & Mech, 1996].
Figur 41: Resultatet af første fase er en grafrepræsentation af et syntetiseret vejnet.
3.2.7.2 Modellering af bygninger
Fra vejnettet uddrages parcellerne der udgøres af området mellem vejene (med least interior angle
metoden). Parcellerne inddeles herefter i mindre byggegrunde, der hver især bebygges med en
proceduralmodelleret bygning.
Modelleringen af bygningernes geometri varetages af et slags L-system, indeholdende
terminalsymboler der fortolkes som ekstrudering, skalering, translation, og statiske geometriske
objekter såsom tage og antenner. Dette er meget lig en såkaldt shape-grammar [Stiny, 1982].
Desuden er der, som i almindelige L-systemer, særlige push og pop symboler, hvorved man kan
modellere forgreninger. Fremgangsmåden er som følger: som input kommer en bygnings grundplan
der kan have arbitrær form. Denne ekstruderes i en højde, der bestemmes ud fra zone-data i et
inputkort, til et massivt volumen, der bestemmer bygningens begrænsninger. Herefter er det muligt
at fortage operationer på denne form, hvorved bygningens geometriske detaljer kan modelleres. Lsystemets
aksiom er så at sige bygningens grundplan.
48

Figur 42: Proceduralmodellering af bygning med udgangspunkt i bygningens bounding-volumen (venstre).
Herefter forfines bygningen gradvist via underinddeling af de enkelte figurer.
Man kan lade figurerne undergå forskellige transformationer, og lade tilfældige tal bestemme hvilke,
hvorved metoden bliver stokastisk. Fordelen er at bygningerne bliver parametriske, og f.eks. altid
passer til en specifik byggegrund. Som det fremgår af Figur 42 forfines bygningen ved hver iteration,
hvorved man har et naturligt LOD hierarki.
Facaderne modelleres via proceduralmodellerede teksturer. I artiklen nævnes følgende observationer
vedr. facader:
Facader består ofte af flere kombinerede eller indlejrede gitterstrukturer, hvor cellerne
indeholder f.eks. døre eller vinduer.
Enkelte celler kan have indflydelse på positionen af omgivne celler, f.eks. har vinduer over en
dør ofte en afvigende størrelse.
Irregulariteter i gitterstrukturen påvirker ofte hele kolonner eller rækker.
I artiklen foreslås en semi-automatisk metode til modellering af facader, der baserer sig på indlejrede
gitter strukturer. En 2-dimensionel gitterstruktur findes ved at kombinere to 1-dimensionelle pulsfunktioner
(der enten er 0 eller 1). Et punkt (s,t) i teksturen er aktivt hvis en logisk funktion mellem
de to puls-funktioner evaluerer til 1. Herefter kan farven i punktet evalueres, hvilket kan indebære
evaluering af yderligere indlejrede gitre. Ved at lade pulsfunktionerne være skalerbare bliver hele
facaden skalerbar, hvormed en høj facade f.eks. tildeles flere etager.
Figur 43: Venstre: Kombinationen af to pulsfunktioner skaber et 2-dimensionelt gitter. Højre: Sammenlægning af
flere lag af gitre.
49

3.2.8 Instant architecture
[Wonka, Wimmer, Sillion, & Ribarsky, 2003]
Figur 44: Fuldautomatisk proceduralmodelleret bymiljø
I denne artikel præsenteres en metode til fuldautomatisk proceduralmodellering af bygningers
facader. Metoden er særligt velegnet til rekonstruktion af virkelige byer, men kan også bruges til
syntetisering af virtuelle. Metoden er inspireret af den foregående artikel, men forfatteren påpeger at
bygninger er fundamentalt forskellige fra planters struktur. En bygning formes ikke af en
vækstproces, der afspejles i L-systemers parallelle natur, men af en proces af underinddelinger. En
bygning er sammensat af en række facader, hver facade består af en række etager, hver etage består
af en række vinduesgrupper osv..
I stedet for at tage udgangspunkt i teorien om L-systemer anvendes de såkaldte shape-grammaer
[Stiny, 1982]. En shape-grammar opererer ikke på strenge men direkte på former. En form kan f.eks.
være en trekant, og en produktion kan f.eks. omskrive en trekant til to firkanter. En regel kan
desuden translatere, rotere eller skalere en form. Teorien omkring shape-grammar blev først anvendt
af arkitekter til at analysere og skabe nye arkitektoniske designs. Ofte benytter man ikke former
direkte i sin grammar, men parametriske symbolrepræsentationer.
50

Figur 45: Shape grammars anvendt til analyse og rekonstruktion af Le Corbusier’s cruciform bygninger.
Artiklen beskriver et system kaldet split-grammar, der varetager modellering af hele bygningen,
inklusiv dens 3d-struktur. Kernen i systemet er evnen til at splitte former i to eller flere mindre
former. Forskellen fra at splitte i stedet for at transformere en form er, at de efterfølgende former
tilsammen fylder det samme som den foregående. Grammaren bliver på den måde kontekst-sensitiv,
da den er afhængig af figurens oprindelige størrelse. I forbindelse med et split, arbejder systemet
udelukkende med kasseformer. Ved fortolkningen af grammarens terminaler, kan disse kasser
erstattes med hvilken som helst figur.
Figur 46: Eksempel på anvendelse af split grammar til generering af facade.
51

Systemet indeholder 240 forskellige produktionsregler, der skal kunne beskrive en stor variation i
stilarter. Modelleringen foregår ved at input, enten i form af GIS-data, såsom bygningens grundplan,
eller en startform gives til systemet. Parametre tilknyttet inputtet angiver overordnede
designmønstre, f.eks. hvilken arkitektonisk stilart der skal anvendes. Herefter anvendes relevante
produktionsregler på stokastisk vis (de fleste regler sorteres fra på baggrund af stilart eller
parametre).
Artiklens forfattere argumenterer for at en fuldstændig tilfældig afledning af regler vil ende i kaos,
især med et regelsæt på 240 regler (Figur 47). Der introduceres derfor en ekstra meget simpel
kontrol-grammar, der sørger for, at overordnede designvalg er konsistente gennem hele
modelleringsprocessen. Kontrol-grammaren designes specifikt til den enkelte bygning. Samtidig
sørger et parametertilpasningssystem for, at konsistensen i afledningen sikres. Kandidatregler
udvælges på baggrund af kontrol-grammaren, og parametertilpasningssystemet sørger herefter for at
frasortere uegnede regler.
Figur 47: Kaotisk facade som følge af ukontrollerede valg af produktionsregler.
3.2.9 Procedural modeling of buildings
[Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006]
52

Figur 48: Proceduralmodelleret rekonstruktion af den arkeologiske by Pompeii. Genererert på baggrund af GISdata.
Denne artikel beskriver et system, kaldet CGA shape grammar, der baserer sig på Instant
Architechture. Artiklens forfattere påpeger en række begrænsninger ved de tidligere metoder:
I [Müller & Parish, 2001] er det muligt at modellere simple bygninger ved at placere og rotere
primitive volumetriske modeller såsom kasser. Til gengæld er metoden ikke egnet til at
generere geometriske detaljer i facaderne, af tilstrækkelig høj kvalitet.
I [Wonka, Wimmer, Sillion, & Ribarsky, 2003] er det muligt at generere facader af
overordentlig høj kvalitet. Derimod er metoden uegnet til håndtering arbitrære bygninger
med komplekse volumetriske modeller. Desuden er det et krav at bygningsmodellerne ikke
må indeholde overlappene facade eller på anden måde degenereret geometri.
Målet med systemet i denne artikel er, at kombinere de bedste egenskaber ved de to ovenstående
metoder. En overordnet betragtning er, at et hus består af en massemodel, der er beklædt med en
facade. Metoden skal altså håndtere transitionen fra, at arbejde med massemodellen til at arbejde
med facaden, sømløst.
Artiklen arbejder med begrebet massemodel (mass model), der er den volumetriske grundmodel for
et hus. Massemodellen er bygningens basale form, når man ser bort fra alle facadedetaljer såsom
vinduer, døre, gesimser, søjler eller lignende, og består ofte af en komposition af primitive
volumetriske figurer. Følgende figur viser variation i massemodellen, mens facaderne er holdt ens:
53

Figur 49: Variation over massemodellen med fastholdt facade.
Med det beskrevne system har en designer mulighed for at modellere en arketype af et hus, f.eks. en
typisk kontorbygning. Herefter angives tilfældighedsparametre der giver instanser af husene
variation. I meget homogene kvarterer, f.eks. et typisk dansk parcelhuskvarter, vil man nu kunne
fylde alle matrikler med lignende huse. For kvarterer med højere variation bør designeren modellere
flere arketyper, alle med forskellige stilarter og arkitektoniske perioder. Dette er meget lig
arbejdsmønstret for l-systemer, hvor forskellige træsorter modelleres med forskellige l-systemer.
Figur 50: Massemodel af bygningen er modelleret ved placering og rotation af simple geometriske figurer,
hvorved facader overlapper hinanden. Dette ses tydeligt ved vinduer der er begravede bag andre facader
(venstre). Højre: Facade der er korrigeret for overlap.
Metoden baserer sig, ligesom instant architecture, på shape-grammaer. Denne variant kaldes af
artiklens forfattere for CGA shape grammar (Computer Graphics Architecture). Definitionen af en
form (shape) er udvidet til at indeholde en symbolrepræsentation (navn) der identificerer figuren i
grammaren, figurens geometri og en orienteret boundingbox (scope) der bestemmer figurers
position, størrelse og orientering.
54

Notationen for en produktionsregel har følgende form:
id: predecessor : cond -> successor : prob
Id’et identificerer produktionen, predecessor er en ikke-terminal figur i grammarens alfabet og cond
er produktionens betingelse, der er et boolsk udtryk, der skal evaluere sandt før produktionen kan
anvendes. En predecessor vil som følge af at anvende en produktionsregel blive erstattet af et eller
flere elementer listet i successor. Reglen vælges blandt andre gyldige regler med sandsynligheden
prob.
For denne metode er der ikke tale om en egentlig erstatning af figurer med nye under
omskrivningsprocessen. Derimod sættes predecessor-figurer til inactive efter afledningen med den
pågældende produktion. Dermed opbygges en afledningstræ af figurer, hvor de afledte figurer er
børn af predecessor. Denne fremgangsmåde kan udnyttes til at skabe automatiske level of detail
niveauer. For at give modelløren bedre kontrol, er det muligt at prioritere reglerne i forhold til
hinanden (med priority kommandoen), hvorved regler af højere prioritet altid vil blive anvendt først.
Som i parametriske L-systemer er CGA en parametrisk grammar. I følgende eksempel erstattes
facaden, med navnet fac og parameteren h, med 3 etager med navnet floor og parameteren h/3:
1: fac(height) ->
floor(height/3)floor(height /3)floor(height /3)
Et scope er som udgangspunkt et koordinatsystem, hvori figurens geometri er defineret. Et punkt P
repræsenterer koordinatsystemets origo, tre akser X, Y og Z repræsenterer koordinatsystemets
rotation og en størrelsesvektor S angiver systemets skalering. En figurs geometri er derfor defineret i
et model-koordinatsystem i intervallet 0 til 1.
55

Figur 51: Scope er koordinatsystemet hvori en figurs geometri er defineret.
Ligesom i l-systemer kan der fortages operationer på et scope under evalueringen af
produktionsregler. Disse operationer er definerede ved en række kommandoer: T(tx, ty, tz) er en
translationsvektor der adderes til scopets position P. Rx(vinkel), Ry(vinkel) og Rz(vinkel) roterer hhv.
X, Y eller Z-aksen i koordinatsystemet med den angivne vinkel. S(sx, sy, sz) sætter scopets størrelse til
den angivne vektor. Derudover er der som i L-systemer en push og pop kommando (’[’ og ’]’), der
hhv. gemmer og henter et scope fra en stak. Endelig indføres en kommando I(objId), der indsætter
en model (f.eks. en model af et vindue) med navnet objId i scopets koordinatsystem. Disse
kommandoer forårsager ikke nye former eller elementer i konfigurationen, men ændrer kun former i
den konkrete produktionsregel, og kaldes derfor for makroer.
Med de ovennævnte makroer kan massemodellen modelleres direkte i grammaren. F.eks. erstatter
følgende produktionsregel et symbol A med massemodellen i Figur 52.
1: A -> [T(0, 0, 6) S(8, 10, 18) I(”cube”)]
T(6, 0, 0) S(7, 13, 18) I(”cube”)
T(0, 0, 16) S(8, 15, 8) I(”cylinder”)
56

Figur 52: Massemodel der består af to kasser og en cylinder. Bemærk hvordan kasser og cylinder genneskære
hinanden.
Ligesom i Instant Architecture har CGA en splitkommando (en makro). Hvis man f.eks. vil splitte en
9 meter høj facade langs y-aksen i tre etager, hver med en højde på 3 meter, bruges kommandoen på
følgende måde:
1: fac : Scope.y == 9 ->
Subdiv(”y”, 3, 3, 3){floor | floor | floor}
Figur 53: Resultat som følge af split på facade.
Først angives aksen man ønsker at splitte langs, derefter følger angivelsen af størrelsen for hvert
split-segment. Der kan angives ligeså mange splits man måtte ønske, når størrelsen blot summerer
til længden af den pågældende akse i scopet. Krølleparenteserne indeholder en række af symboler
separeret med ’|’, der angiver navnet på figuren i de afledte splitsegmenter. Antallet af segmenter i
kommandoen skal svare til antallet af figurer i krølleparenteserne. I dette tilfælde vil produktionen
57

kun blive anvendt på facader med højden 9. Dette kontrolleres ved at undersøge figurens
dimensioner i y-aksen i produktionsreglens betingelse.
Artiklens svar på problemet med overgangen fra massemodellering til facademodellering består i et
såkaldt komponentsplit. Ved hjælp af den følgende kommando kan vi splitte et objekt i en række
figurer af lavere dimesion:
1: a -> Comp(type){ A | B | … | Z }
Typen (type) indikerer hvilket element vi ønsker at splitte figuren i. Hvis vi f.eks. anvender
kommandoen på en 3-dimensionel figur kan dette være enten ”face”, ”edge” eller ”vertex”, svarende til
figurer i hhv. 2, 1 eller 0 dimensioner. Den konkrete definition af et objekt af lavere dimension, er en
figur hvis scope har størrelsen 0 i en eller flere akser. Det er i den forbindelse værd at bemærke, at vi
kan gå tilbage til tre dimensioner igen, ved at sætte størrelsen til en værdi højere end 0, og på den
måde ekstrudere objekter f.eks. et udhæng i en facade der ekstruderes fra facadeplanet ud i en 3dimensionel
figur. Figur 54 viser resultatet som følge af følgende komponentspilt, der opløser en 3dimensionel
figure i dens flader:
1: a-> Comp(”faces”){fac}
Figur 54: Effekten af en komponentsplit i sider for en 3-dimensionel figur.
Efter dette split kan vi nu arbejde videre med figurens facader i form af figurer, der i dette tilfælde
hedder fac.
Da vi nu arbejder på arbitrære masse-modeller, kan vi ikke vide noget på forhånd om facadens
størrelse. Kommandoen i Figur 53, er f.eks. udelukkende anvendelig på en facade der er nøjagtigt 9
meter høj. Artiklens forfattere indfører derfor en repeat-kommando. F.eks:
1: floor -> Repeat(”X”, 2) {B}
58

Figur 55: Resultat som følge af repeat-split på facade.
Den pågældende etage vil dermed blive inddelt et antal blokke (hver med navnet B), svarende til
størrelsen af x-aksen i figurens scope delt med 2. Hvis bloklængden ikke går op i figurens længde vil
antallet af blokke blive rundet af til nærmeste hele tal.
Endelig indføres en relativ parameter, markeret ved et tal efterfulgt af er ’r’. En relativ parameter
antager en relativ størrelse i forhold til figurens dimension og andre absolutte parametre:
1: floor -> Subdiv(”X”, 2, 1r, 1r, 2){ A | B | B | A}
I det ovenstående eksempel inddeles etagen i 4 blokke: to A blokke der har en fast størrelse på 2
meter og 2 B blokke der deler det resterende areal ligeligt.
Det er muligt at kombinere split og repeat kommandoer og dermed opnå en meget fleksible
modelleringer. Det følgende eksempel skal illustrere, hvordan en facademodellering kan bevare sin
struktur under varierende dimensioner:
1: floor ->
Subdiv(”X”, 3, 1r, 3){ A | Repeat(”X”, 2) { B } | A}
59

Figur 56: Eksempel på facadessplit på facader med forskellige dimensioner.
I det ovenstående eksempel anvendes produktionen på en facade på 8m og en på 13m. Facaderne
deles indledningsvist i 3 stykker, hvor start og slut begge er 3m bredde A-blokke. Det midterste
stykke indeholder et indlejret repeatsplit, der inddeler stykket i så mange B-blokke der er plads til.
Alle A-blokke er 3m, mens B-blokkene varierer i størrelse. I eksemplet til venstre er B-blokken
nøjagtigt 2m, da dette er hvad der er til overs fra A-blokkene. I eksemplet til højre er der 7m til overs
fra A-blokkene. Dette giver 7/2 = 3,5 blokke, hvilket oprundes til 4 blokke af hver 1,75 m.
Med split og repeat- kommandoerne kan vi nu modellere en facade. Det følgende er en meget simpel
modellering af facaden i Figur 58:
1: fac -> Subdiv(”y”, 4, 1r) { ground | floors }
2: floors -> Repeat(”y”, 3) { floor }
3: floor -> Repeat(”x”, 2) { win }
4: ground -> I(”groundFloor.obj”)
5: win -> I(”winBlock.obj”)
Figur 57: Grammar til specifikation af simpel facade.
60

Figur 58: Facades struktur i grove træk. Af hensyn til overskueligheden er win figurerne kun medtagede for den
ene etage.
I det ovenstående tilfælde er underetagen 4 meter høj, de resterende etager er hver ca. 3 meter høje
og vinduesblokkene er 2 meter brede. Input er en facadefigur (et rektangel), med navnet fac, der kan
være arbitrært stor. For at opnå et rimeligt resultat bør den dog mindst være højere end 4, hvilket
burde kontrolleres med et boolsk tjek i den første produktionsregel. Regel 1 splitter facaden i en
underetage og en blok der fylder resten af facaden (floors). Regel 2 inddeler denne i så mange etager
der er plads til, og regel 3 inddeler etagerne i så mange vinduesgrupper der er plads til. Endelig
erstattes geometrien i hhv. ground og win med mere detaljeret geometri (regel 4 og 5).
For at korrigere problemet skitseret i Figur 50, indføres en occlusion-query-test, hvorved man i selve
grammaren kan tage højde for eventuelle overlapninger. Følgende eksempel gives i artiklen:
1: tile : Shape.occ(”nonparent”) == ”none” -> window
2: tile : Shape.occ(”nonparent”) == ”part” -> wall
3: tile : Shape.occ(”nonparent”) == ”full” -> ε
Figur 59: Eksempel på typisk brug af occlusion-forespørgsler i CGA.
Hvis figuren ikke overlappes indsættes en vinduesfigur, hvis den er delvist overlappet indsættes en
vægfigur og hvis den er fuldt overlappet indsættes den tomme figur (ε). Parameteren (”nonparent”)
er beregnet til at begrænse testen. F.eks. vil en figurs forgængerfigurer i afledningstræet ofte
overlappe, hvilket undgås ved at udelukke disse. Derudover kan der via grammaren indsættes snaplinjer
der kan opfanges af omgivelserne, hvorved en mere konsistent indretning af facadens struktur
opnås.
61

Modelleringen af tage håndteres på forskellige måder, afhængigt af modelleringsopgavens karakter.
For bygninger der modelleres ved kombination af geometriske grundfigurer, indeholder systemet en
række basale parametriske tagformer, meget lig tagene i enegikoncept (afsnit 2.1.1). I de tilfælde hvor
inputtet er facader, ekstruderet fra en bygnings grundplan (f.eks. GIS-data), bygges en valmet
tagform baseret på et straight-skeleton.
Figur 60: Udvalget af grundtagformer i CGA.
Artiklen giver en lang række konkrete modelleringseksempler, der elegant løses med metoden. I
Figur 48 ses byen Pompeii, der via GIS-data-input blev modelleret ud fra 190 CGA produktionsregler.
Metoden er anvendelig til et stort udvalg af varierende stilarter, og er anvendt i flere kommercielle
og open-source produkter.
Figur 61: Modelleringseksempler.
62

3.2.10 Procedural Modeling of Structurally-Sound Masonry Buildings
[Whiting, Ochsendorf, & Durand, 2009]
Figur 62: Stenkirke, modelleret under hensyntagen til statiske og strukturelle begrænsninger.
Denne artikel præsenterer et system, der bygger videre på arbejdet i [Müller, Wonka, Haegler,
Ulmer, & Van Gool, 2006]. Forfatterne argumenterer for, at bygninger der ikke er strukturelt stabile
eller korrekt proportionerede, vil have en synlig særpræget og urealistisk fremtoning. Derudover
spiller den fysiske interaktion mellem virtuelle miljøer og brugeren en stadig større rolle i de fleste
applikationer. Dertil har man brug for bygninger der er realistisk modellerede ud fra en fysisk
betragtning, hvorved de under en given påvirkning kollapser på virkelighedstro måder.
Systemet tager et sæt produktionsregler af samme form som i [Müller, Wonka, Haegler, Ulmer, &
Van Gool, 2006], hvori en række frie parametre er markerede. Som udgangspunkt modelleres
herefter en bygning, bestående af geometriske primitiver. Udover de basale, såsom kasser eller
cylindere som i CGA, er sættet af primitiver udvidet med søjler, buer, kupler o.l. Primitiverne er alle
underinddelt i byggeblokke, af en passende størrelse.
Den proceduralmodellerede bygning analyseres herefter ved, at betragte på kontaktfladerne mellem
byggeblokkene, og beregne udvekslingen af kræfter mellem disse. En byggeblok er i ligevægt, hvis
summen af kræfterne er 0. Hvis alle byggeblokke er i ligevægt er bygningen i ligevægt, og vi er
færdige.
63

Hvis bygningen ikke er i ligevægt, beregnes et tal for hvor tæt den er på ligevægt, et nyt sæt frie
parametre findes hvorefter processen starter forfra. De frie parametre vælges med henblik på en
ikke-lineær optimering i parameterrummet. Efter to iterationer har vi, på baggrund af
ligevægtstallet, en gradient i parameterrummet, og ved at bevæge os langs denne, nærmer vi os ved
hver iteration en optimal konstruktion. De frie parametre kan f.eks. være bygningshøjde,
vægtykkelse, søjletykkelse eller vinduesbredde, og beregningen bliver mere nøjagtig jo finere
granularitet hvormed byggeblokkene er underinddelt.
Artiklens forfattere lægger vægt på, at denne type modellering kun er praktisk mulig netop i
proceduralmodellering. Det er f.eks. de færreste spil-grafikere, der har indsigt i bygningers statiske
forhold eller en intuitiv fornemmelse for bæredygtige proportioner i f.eks. en stenkirke.
3.2.11 Interactive Visual Editing of Grammars for Procedural Architecture
[Lipp, Wonka, & Wimmer, 2008]
Figur 63: Visuel editering af shape-grammars i realtid.
Denne artikel præsenterer et system, der som den forrige artikel også bygger videre på metoden
præsenteret i [Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006]. Et af problemerne med metoden
er, at den kræver tekstbaseret editering, samtidigt med, at brugergruppen hovedsageligt er designere
og grafikere. Tekstbaseret modellering er ofte en uoverkommelig barriere for folk uden baggrund i
datalogi. Et andet problem ved modellering med grammaer er, at designeren kun har kontrol over
meget overordnede designparametre. For
proceduralmodellering er der altid tale
om en afvejning mellem udtryksfuldhed
og detaljeret kontrol. Ofte vil der opstå
uhensigtsmæssige designs, der er
problematiske for grafikeren at håndtere
uden, at introducere et væld af nye
produktionsregler i grammaren, hvilket i
sidste ende gør modelleringsprocessen
uoverskuelig. Denne artikel introducerer
et system, der har til formål, at
kombinere styrken ved grammaer med
traditionelle modelleringsmetoder.
Figur 64: Venstre: Et afledt figurhierarki, der svarer til facaden
til højre. Af hensyn til læsbarheden vises kun den anden etage i
figurhierarkiet.
64

Ved modellering med shape-grammaer opbygges en træstruktur; et slags hierarki af figurer (Figur
64). Dette hierarki har figurer eller kommandoer som knuder, der hver har forskellige parametre, der
enten er tilfældigt valgte eller bestemt af produktionsregler. Ofte ønsker en designer f.eks., at ændre
et bestemt vindues bredde eller højde. En måde at gøre dette på er, at angive de specifikke parametre
for vinduets endeknude i træstrukturen. Problemet er, at hvis grammaen ændres og hierarkiet
afledes på ny, vil denne ændring være tabt, hvilket er et problem for brugbarheden af systemet.
Desuden ønsker designere ofte mulighed for at vælge f.eks. hele rækker eller kolonner af vinduer i en
facade.
Forfatterne introducerer et system til identifikation af enkelte figurer, ud fra deres unikke position i
hierarkiet. Indledningsvis fortages en søgning fra en endeknude til grammaens aksiom (rod). Hver
forgrening fra en knude nummereres afhængigt af rækkefølgen, og dermed bygges en tupel, der
angiver den nøjagtige vej fra aksiomet til den enkelte figur. På den måde kan en figur altid findes
også efter, at hierarkiet er blevet afledt på ny, og en eventuel ændring kan dermed bibeholdes.
Brugeren har mulighed for at markere enkelte split eller repeat-kommandoer (f.eks. med etage eller
kolonne), hvormed tupelen også kan indeholde semantisk information. Et valg af en etage eller en
kolonne kan dermed ske ved at finde figurer der har den ønskede semantiske information.
Systemet har desuden en visuel editor af produktionsregler, hvorved en hel bygning kan konstrueres,
uden tekstbaseret editering. Metoden er tilstrækkeligt hurtigt til, at muliggøre interaktiv editering.
3.2.12 Kommercielt software
Udover de i dette afsnit beskrevne metoder, findes der både kommercielt og open-source software
der er relevant i denne sammenhæng.
3.2.12.1 Autodesk Revit
Revit er et CAD program fra Autodesk. Revit benytter det såkaldte BIM paradigme, der står for
Building Information Modeling. BIM modellering indebærer ofte generering og forvaltning af
bygningsdata gennem hele bygningens livscyklus. I stedet for at arbejde med rå geometrisk
stregdata, arbejder man i BIM med begreber såsom vægge, vinduer, døre, tage og elektriske
installationer, der tilsammen udgør en komplet bygning. Desuden kan en BIM model holde styr på
bygningselementernes indbyrdes forhold, f.eks. et sæt vægge der sammen danner et rum.
Revit er interessant i denne sammenhæng, da man har mulighed for at modellere tage via en metode
der baserer sig på teorien om polygonens straight-skeleton. Brugeren kan udpege et antal
sammenhængende vægge, sætte hældningsparametre på disse og få systemet til at beregne taget.
Man kan modellere saddeltage ved at sætte gavlene til ikke at have en hældning. Mere komplicerede
tage, f.eks. mansardtaget eller den hollandske gavl kan modelleres som to tage, hvor det nedre er
beskåret og det øvre ekstruderes fra det polygon der opstår i skæringsplanet (Figur 65).
65

Figur 65: Modellering af hollandsk gavl i Revit. Den nedre del består af et valmet tag og den øvre består af et
saddeltag.
3.2.12.2 Procedural inc og speedtree
To gode eksempler på anvendelse af proceduralmodellering i industrien er CityEngine fra Procedural
inc. og SpeedTree fra Interactive Data Visualization, Inc..
SpeedTree er et modelleringsværktøj der specifikt er rettet mod proceduralmodellering af planter og
plantedele. Systemet er baseret på l-systemer, men brugeren arbejder i et CAD lignende miljø.
Systemet kommer med over 200 forskellige plantearter, der kan proceduralmodelleres ud fra et stort
antal parametre, f.eks. alder, vindpåvirkning eller omgivende geometri. Systemet kan herefter bygge
et vilkårligt antal forskellige træer baseret på den modellerede plante.
Derudover medfølger kode til realtidsvisualisering af planterne. Det er muligt at simulere
vindpåvirkning i realtid, og systemet vil automatisk generere LOD modeller og transitioner mellem
disse. Den medfølgende kode kan anvendes til at generere modellerne ved opstart af spillet, hvilket
kan medvirke til hurtigere opstartstider.
Systemet har haft stor succes og er efterhånden anvendt i et anseeligt antal spiltitler. En række
game-engines bl.a. UnrealEngine, har inkorporeret SpeedTree direkte i deres modelleringsværktøj.
Desuden findes systemet som plugin til 3Ds Max.
CityEngine minder om SpeedTree, borset fra at systemet er rettet mod proceduralmodellering af hele
byer. Procedural inc er et såkaldt spin-off fra ETH Zürich (det tekniske universitet i Zürich),
grundlagt af bl.a. Pascal Müller, medforfatter til en række artikler præsenteret i dette afsnit.
Systemet er tiltænkt brug i byplanlægning, arkitektur, spiludvikling, film-industrien og arkæologi.
Systemet har følgende funktioner:
Proceduralmodellering af vejnet.
Import af eksisterende vejnet (f.eks. fra OpenStreetMap).
Automatisk underinddeling af celler fra vejnettet til parceller, der efterfølgende er
udgangspunkt for modellering af bygninger.
Proceduralmodellering af parametriske bygninger via CGA shape-grammar. (Benytter
metoden beskrevet i afsnit 3.2.9)
Import af GIS data, der kan bruges som aksiom i CGA shape grammar.
En by-wizard, der kan skabe hele bymiljøer på et øjeblik, ud fra et prædefineret bibliotek af
template-bygninger.
66

Figur 66: Brugerflade fra Procedural inc's CityEngine.
Systemet har været tilgængeligt siden 2008, og er derfor ikke helt så udbredt som SpeedTree.
Systemet kan eksportere direkte til de største game-engines, og er anvendt af en række store
spiludviklingsstudier.
En bemærkelsesværdig tilføjelse i forhold til artiklen [Müller, Wonka, Haegler, Ulmer, & Van Gool,
2006], er måden hvorpå tage håndteres. I den nyeste version af systemet fra 2010, er det nu muligt at
anvende såkaldte parametriske tage, der inkluderer valmet tag, saddeltag, pyramidetag og pulttag.
Ifølge vejledningen på systemets hjemmeside 2 , ser syntaksen for parametriske tage således ud:
Lot --> extrude(10) Mass
Mass --> comp(f) { top: Top | all: X }
Top --> roofHip(30, 2) Roof
I dette tilfælde er der tale om et valmet tag med en hældning på 30 o og med udhæng på 2. Resultatet
af den ovenstående grammar ser således ud:
2 http://www.procedural.com/
67

Figur 67: Parametrisk tag genereret via CityEngine.
Det er klart at systemet anvender et straight-skeleton på den foregående figurs fodaftryk. De afledte
tagflader er hver især en figur, der efterfølgende indsættes i grammaren med navnet Roof, hvorved
systemet kan arbejde videre med disse, og evt. indsætte vinduer eller kviste.
3.3 Teori
I det forrige afsnit har jeg gennemgået den litteratur, jeg finder relevant for dette projekt. I de
beskrevne artikler er der anvendt generelle metoder fra hele området for computergrafik. I dette
afsnit vil jeg derfor gennemgå den teori, der vil blive anvendt til udvikling og implementering af min
metode.
Nogle af metoderne beskrevet i afsnit 3.2 (Relateret arbejde), kan opfattes som teoretisk
baggrundsviden, men jeg har valgt at introducere dem tidligere, da de er nødvendige for forståelsen
af de efterfølgende metoder. Her tænker jeg specielt på afsnittene 3.2.1 (A Novel Type of Skeleton for
Polygons) og 3.2.9 (Procedural modeling of buildings ). Samtidig vil jeg i metodeafsnittet gå i dybden
med noget af den, i den forbindelse relevante, teori. Dette afsnit vil derfor være forholdsvis
kortfattet.
3.3.1 Den geometriske værktøjskasse
Dette projekt omhandler beregning på geometrisk data, og jeg vil derfor gøre brug af den brede vifte
af beregningsmetoder der er almindeligt kendte indenfor dette område. Denne viden har jeg tilegnet
mig gennem min udannelse på DTU, og den danner grundlag for den værktøjskasse af metoder jeg
har anvendt til, at løse de udfordringer jeg har behandlet i dette projekt. Jeg vil for metoderne i dette
afsnit referere til [Akenine-Möller, Haines, & Hoffmann, 2008] og [Bærentzen, Anton, Gravesen, &
Aanæs, 2006].
3.3.1.1 Polygonen
Jeg har tidligere diskuteret polygonen og definitionen af denne. Her følger en mere anvendelses
orienteret beskrivelse.
68

Fra Jordan Curve Teoremet kan det udledes, at hver stråle startende i et punkt i polygonens indre i en
arbitrær retning vil krydse polygonens kant et ulige antal gange. Modsat gælder det at en stråle fra
ethvert punkt udenfor polygonen i en arbitrær retning vil krydse polygonen 0 eller et lige antal
gange.
Når vi betragter et konkret punkt kan vi vælge en retning, f.eks. vandret, og teste for antallet af
krydsninger med polygonen. For selvkrydsende polygoner kan denne fremgangsmåde resultere i
flertydigheder:
Figur 70: Lige-ulige test for selvkrydsende polygon.
Hvorvidt dette resultat er korrekt, afhænger af situationen. I forbindelse med dette projekt spiller
det ingen rolle, da jeg ikke skal tage højde for selvkrydsende polygoner.
3.3.1.2 Det geometriske plan
Et plan er entydigt defineret ved en normal-vektor (n) og en afstand langs denne vektors akse fra
koordinatsystemets origo til planets skæring med aksen (d).
71

Et punkt betegnes som udenfor med hensyn til et plan hvis afstanden projiceret på planets normal er
længere en planets d-parameter.
Figur 73: Klipping af et polygon med hensyn til et plan.
Algoritmen er hurtig og robust og jeg vil anvende den ved flere lejligheder i mit projekt, men den
virker ikke for klipping af et arbitrært ikke-konvekst polygon mod et andet ikke-konvekst polygon,
kun mod et andet konvekst polygon. I det følgende afsnit vil jeg bl.a. kort skitsere en sub-optimal
men konceptuelt simpel og robust algoritme til generel polygonklipping.
3.3.1.3 Polygonmesh
Et polygonmesh er et sæt sammenhængende polygoner, der definerer et polyeder i 3d. Ofte defineres
et mesh af et sæt punkter og et sæt indekserede flader der angiver topologien mellem punkterne. Et
polygon kan f.eks. være en tagmodel i computergrafik:
74

Figur 74: Et polygonmesh formet som et tag.
I dette projekt vil jeg benytte mig af egentlige ikke-konvekse polygoner, men ofte er der tale om
enten et trekants eller firkantsmesh.
En mere fleksibel repræsentation af et mesh er den såkaldte half-edge datastruktur [Mantyla, 1988].
Hvor hver kant i meshet repræsenteres af et par af modsatrettede kanter (half-edge). Strukturen i
dette mesh kan visualiseres således:
Figur 75: Mesh bestående af to trekanter og dets half-edge datastruktur. En half-edge er repræsenteret ved
Hver kant kender punktet hvorfra den udspringer (start), punktet hvor den ender (end), sin
modsatte kant (opp) og den flade den tilhører (face). I Figur 75 er det tydeligt hvilken flade hver kant
tilhører, og generelt er de i positiv omløbsretning for deres flade. Derudover har alle kanterne en
75

pointer til den næste kant i deres flade (next). Endelig har en vertex en pointer til én af de udgående
kanter (edge), og en flade har en pointer til én af sine kanter (edge).
Det elegante ved datastrukturen er, at kanter i et almindeligt mesh ikke er retningsinvariante,
hvilket i denne struktur håndteres ved eksplicit at opretholde to retningsbestemte kanter. Kanten
der deles mellem de to flader i Figur 75, ville i den simple datastruktur have forkert retning i forhold
til omløbsretningen for én af fladerne. Den opmærksomme læser vil bemærke, at meshet i Figur 75
har en tredje flade, nemlig den der udgøres af de udvendige kanter der løber i negativ
omløbsretning. Disse kanter har en null-pointer til deres flade. Jeg vil senere vise hvordan dette
fænomen kan udnyttes.
Strukturen gør det let at fortage følgende søgninger:
Alle kanter i en flade: Flade edge next next .
Alle punkter i en flade: Samme som for kanter, men kanternes start vertex returneres.
Alle kanter for en vertex: Vertex edge opp next opp next ...
Alle flader forbundet til en vertex: Samme som for kanter, hvor fladen for hver kant noteres.
I det videre arbejde får vi brug for at kunne bestemme alle polygoner der er indeholdt i en hob af
kanter i et plan. Vi skal altså kunne bygge et half-edge mesh, uden indledningsvis at kende til
datasættets flader. Jeg benytter mig af følgende fremgangsmåde:
1. Først finder jeg alle sammenfaldende punkter. For at tage højde for numerisk upræcision
vælger jeg sammenfaldende punkter inden for en meget lille ε-radius (typisk 0,00001).
2. Herefter deler jeg kanter, der hvor de indbyrdes skærer hinanden, og opretter en ny vertex
forbundet til alle fire kanter.
3. Alle duplikerende kanter, eller kanter der forbinder et punkt med sig selv, fjernes.
4. Jeg har nu en simpel grafstruktur, uden krydsende kanter, duplikerede kanter eller kanter der
forbinder knuder med sig selv.
5. Jeg kan nu følge kanter til polygoner ved at vælge den mindste indre vinkel (least interior
angle), hver gang jeg når en vertex. Dette fortsætter indtil jeg har besøgt alle kanter i begge
retninger.
6. Jeg har nu et sæt polygoner, og jeg kan vælge at bygge et half-edge mesh af disse eller blot
returnere dem.
Den mindste indre vinkel beregnes ved at gennemløbe alle udgående kanter for en vertex, beregner
deres vinkel i forhold til den indkommende kant og vælge den mindste:
76

Figur 76: Mindste indre vinkel for en indkommende kant.
Hver resulterende polygon må kontrolleres for omløbsretning, og netop én polygon vil være negativ.
Denne er netop polygonen der markerer grafens ydre grænse (samme polygon, som det der opnås
ved et såkaldt boundary walk). Jeg vil ved flere lejligheder have brug for evnen til netop at finde
denne polygon.
De ovenstående betragtninger kan ydermere benyttes til en generel polygonklippings-mekanisme i
2d. Polygonklipping kan betragtes som en sæt-operation på polygoners punktsæt. Inputtet til
algoritmen er en liste af polygoner, hvor målet er at finde f.eks. foreningsmængde af disse.
Fremgangsmåden er som følger:
1. Opløs sættet af polygoner i en simpel graf.
2. Find alle indeholdte polygoner i denne graf.
3. Find et punkt i hver af polygonernes indre (f.eks. via æseløre fremgangsmåden).
4. Benyt dette punkt som test for hvilke polygoner i inputsættet der indeholder
resultatpolygonen, og frasorter de der ikke opfylder sæt-operation.
Alle resulterende polygoner sættes sammen ved at finde resultatets ydre grænse (boundary-walk).
77

4 Observationer, analyse og hypotese
I dette afsnit vil jeg give et overblik over resultaterne af mit litteraturstudie, og samtidig uddrage de
centrale hovedpunkter.
Proceduralmodellering af bymiljøer er et område i rivende udvikling, og resultaterne er efterhånden
af så høj kvalitet, at industrien har fået øjnene op for fordelene ved teknologien.
Meget overordnet kan man sige, at de forskellige metoder forsøger at finde en balance mellem
designerens kontrol og effektivitet. Groft sagt, jo mere kontrol en designer vil have over
modelleringsprocessen, jo mere tid tager det. Kontrol koster altså tid, og tid koster penge og
ressourcer, der kunne være brugt mere produktivt. Dette varierer naturligvis meget fra metode til
metode. Nogle er bedre til at finde den rette balance, og nogle udnytter grafikerens tid bedre end
andre. Jeg vurderer at en metode, der fungerer fuldstændig automatisk, kun er anvendelige i meget
begrænsede tilfælde. CityEngine’s wizard er et eksempel på en metode der er fuldautomatisk. Det er
svært at forestille sig en designer, der vil lade sig diktere fuldstændigt af et modelleringsværktøj.
Menneskelig intervention i modelleringsprocessen er derfor ikke et problem i denne sammenhæng,
så længe produktiviteten er forholdsvis høj. I sidste ende vejer kvaliteten af det endelige resultat
højere.
Alle artikler om proceduralmodellering af
bygninger, bygger på en eller anden form for
regularitet af den arkitektur der kan
udtrykkes. Her er der tale om de forventninger
man har til de værktøjer der gør brug af
proceduralmodellering. Alle metoderne
forsøger at opstille enten eksplicitte eller
implicitte regler for en bygnings struktur. I
mange tilfælde er der ligefrem tale om et
hierarki: En bygning består af en række
bygningsdele, der har en række facader, der
består af en række etager, der igen har en
række vinduer osv.. Operahuset i Sydney er et
eksempel på en bygning der i grove træk
falder fuldstændigt uden for denne definition. Dette
er dog et helt særligt specialtilfælde. For langt de
Figur 77: Utzons operahus, Sydneys
karakteristiske vartegn.
fleste bygninger kan man umiddelbart definere begreber såsom facade og etage. Det gælder altså om
at finde fællesnævnere der dækker begrebet arkitektur så bredt som muligt, men stadig kan
defineres af simple koncise regler. De resterende specielle bygninger er vartegn (landmarks), hvor vi
må acceptere, at der findes manuelle værktøjer der er bedre egnede, f.eks. i tilfældet for operahuset i
Sydney.
Jeg vurderer, at et rimeligt kvalitetskrav må være, at de genererede bygninger har høj geometrisk
detaljeringsgrad. Bymiljøer i moderne computerspil er ofte detaljeret ned til f.eks. vindueskarme
eller gesimser. Metoden bør derfor kunne modellere facadens geometri, og ikke bare beklæde
78

facaden med en tekstur. Det afhænger selvfølgelig af modellens tiltænke anvendelse, og derfor bør
metoden automatisk kunne bygge modeller i forskellige levels-of-detail. Af denne grund er
metoderne i [Greuter & Parker, 2003] og [Kelly & McCabe, 2007] udelukkede som udgangspunkt for
mit videre arbejde. Det er muligt at de kan anvendes i særlige sammenhænge, men i det generelle
tilfælde er metoderne forældede. Det er ikke længere tilstrækkeligt blot at teksturere facaderne, også
selvom der anvendes normal-maps.
En række metoder behandler modellering af vejnet. Disse er som sagt ikke i fokus for dette projekt,
men metoden bør naturligtvis kunne spille sammen med genererede vejnet eller eksisterende GIS
data, hvilket i øvrigt er tilfældet for alle metoder gennemgået i afsnit 3.2.
I [Wonka, Wimmer, Sillion, & Ribarsky, 2003] påpeges et problem ved grammaer, anvendt til
modellering af facader: Hvis man ikke er påpasselig udvikler stokastiske systemer sig kaotisk. I
artiklen forslås en kontrol-grammar, der skal varetage designvalg gældende for hele bygningen. Der
er igen tale om en afvejning mellem metodens udtryksfuldhed (evnen til at generere variation) og
designerens kontrol. Det må konkluderes, at en metode skal have mulighed for kontrol og styring af
globale designvalg for en bygning, hvad enten disse valg også er et produkt af stokastisk proces
(f.eks. en stokastisk kontrol-grammar), eller udtryk for et direkte valg fra brugeren.
En række artikler bygger på arbejdet i [Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006]. Artiklen
præsenterer særdeles flotte resultater, og har fundet anvendelse i industrien. Ved at give udførlige
eksempler for en række almindelige bygningstyper, demonstrerer artiklen hvordan konkrete
problemstillinger kan løses. Metoden er fleksibel, og kan tage en bred vifte af inputdata, der gør den
kompatibel med systemer der modellerer vejnet. Dermed er det i sidste ende muligt at generere hele
bymiljøer. Metoden gør det desuden muligt for designeren, at bestemme hvilke dele der skal
varetages af grammaren, og hvilke dele der skal håndteres af traditionelle modelleringsværktøjer.
Dette muliggøres ved hjælp af import og indsættelse af modeller såsom vinduer direkte i systemet
(via I-kommandoen).
Artiklens forfattere påpeger at modellering af bygningens massemodel og facader er to vidt
forskellige processer, der hidtil ikke har kunnet kombineres i en samlet løsning. Via komponentsplittet
gives en meget elegant anvisning på hvordan denne overgang kan håndteres.
Artiklens forfattere har testet systemet på en grafiker, der var i stand til at modellere en by på relativt
kort tid. Problemet er, at grafikere der ikke har erfaring med programmering, vil have svært ved at
anvende et grammarbaseret system uden grundig vejledning og efterfølgende øvelse. I [Lipp, Wonka,
& Wimmer, 2008] gives et eksempel på en brugerflade der bygges ovenpå CGA, hvormed brugeren
ikke skal tage stilling til den bagvedliggende grammar.
Efter min mening er endnu et af problemerne ved CGA, som det er præsenteret i artiklen [Müller,
Wonka, Haegler, Ulmer, & Van Gool, 2006]: Tage håndteres meget dårligt. I den nyeste version af
CGA-implementeringen i CityEngine kan man benytte parametriske tage, men udvalget af tagtyper
er stadig meget begrænset. I modsætning til resten af bygningen, der kan modelleres som en
komposition af geometriske figurer, er tage en sammenhængende figur der ikke kan repræsenteres
som en samling særskilte objekter. Derfor er simple occlusion-query-test’s ikke tilstrækkelige. I Figur
79

78 ses et tag modelleret med CGA, der tydeligvis er sammensat af simple mindre tage. Samtidig er
tage ofte meget komplekse geometriske objekter, hvilket gør manuel modellering kostbar.
Figur 78: Resultat præsenteret i [Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006]. Det ses tydeligt at taget blot
er en komposition af meget simple tage, rejst fra kasse-figurer.
I mit videre arbejde har jeg, til trods for de nævnte mangler, valgt at tage udgangspunkt i CGA.
Metoden opfylder mange af de krav, der er nævnt i afsnit 1.1, og en række artikler demonstrerer
hvordan det er muligt at bygge videre på resultaterne, f.eks. ved en overbygning med en grafisk
brugerflade. Det er i metoden desuden muligt at arbejde med facader og deres geometri, og der
sættes ingen grænse for hvor detaljeret en designer kan modellere sine bygninger. Hvis det er ønsket,
er det muligt at arbejde helt ned til enkelte mursten. Dette gør, at metoden også vil kunne bruges i
fremtiden, hvor kravene til modellernes detaljering må forventes at være konstant stigende.
For tagenes vedkommende er det en udbredt opfattelse i litteraturen, at et simpelt straight-skeleton
ikke er tilstrækkeligt til at repræsentere de varierende tagtyper man møder i virkelige huse. I
[Aichholzer & Aurenhammer, 1996] sammenfattes problemet meget godt:
"Even when the slopes of the roof faces are prescribed, a roof is a highly ambiguous object."
Det er klart at et tag ikke er entydigt defineret ved hældningen givet for hver tagflade. Her er der tale
om arkitekters frie kreativitet, der ikke kan forudsiges af en computer. Pointen er blot, at metoden
ikke bør være et universelt modelleringsværktøj for alle tænkelige tage. På baggrund af eksemplet
med operahuset i Sydney, er det rimeligt at sige, at hvis vi kan modellere en meget stor andel af de
mest almindelige tage, vil de resterende særtilfælde kunne håndteres manuelt, ved brug af værktøjer
der er bedre egnede til generel mesh-editering.
Det er også klart, at f.eks. mansardtaget ikke kan modelleres på baggrund af en hældning specificeret
for hver kant i grundplanet. Her er der behov for mere information fra brugeren. Jeg vurderer at det
er muligt at udbygge metoden til rejsning af tage med et straight-skeleton til, at håndtere samtlige
tage i Tabel 1. I mit videre arbejde vil jeg derfor tage udgangspunkt i artiklerne for straight-skeleton
metoden.
80

Med baggrund i de ovenstående observationer har jeg formuleret følgende hypoteser, der vil ligge til
grund for metoden præsenteret i denne rapport.
Nuværende systemer til proceduralmodellering af bygninger er uegnede til effektiv
modellering af tage.
Det må være muligt at udvikle en model der bygger på et straight-skeleton, men samtidig kan
modellere alle de tagtyper der er nævnt i Tabel 1.
Det må være muligt at inddrage en sådan metode direkte i CGA, og derved opnå en mere
fleksibel mekanisme til ekstrudering af tage.
81

5 Metode
I dette afsnit vil jeg præsentere mit bidrag til teknologien. Mit bidrag er den metode, der er blevet
udviklet i forbindelse med dette projekt. Jeg vil herefter referere til denne metode som min metode.
Metoden er blevet til som resultat af min analyse af den eksisterende litteratur, og baserer sig på
forudgående arbejde, særligt det der præsenteres i [Müller, Wonka, Haegler, Ulmer, & Van Gool,
2006]. Min foreslåede metode har til formål at lette arbejdet med modellering af tage for designere i
forbindelse med proceduralmodellering af bymiljøer.
Indledningsvist vil jeg give en overordnet beskrivelse af metoden, og efterfølgende gå i dybden med
de mest relevante implementeringsspecifikke detaljer.
5.1 Konstruktion
Den eksisterende metode skelner mellem massemodel og facade, hvor taget hører under
massemodellen. Jeg vil udvide denne betragtning til overordnet at skelne mellem følgende
komponenter i et hus: Massemodel, facade og tag. I forhold til tidligere er massemodellen reduceret,
så den nu ikke længere indeholder taget. Dette er, som jeg vil demonstrere senere, praktisk, og
samtidig konceptuelt let forståeligt i forbindelse med modelleringsprocessen. Først bygges en
massemodel, der efterfølgende beklædes med en facade, og endeligt rejses husets tag.
+
Massemodel Facader Tag
+
82

Figur 79: I modellen inddeles et hus i følgende komponenter: Massemodel, facade og tag.
5.1.1 Rejsning af tage
Udgangspunktet for min metode er det lagdelte straight-skeleton, der vil blive præsenteret i dette
afsnit. Oprindelsen til ideen kommer fra måden tage håndteres i Revit Architechture: Et tag kan
rejses ved at angive hældningen for alle kanter i grundplanet, hvilket jeg formoder muliggøres ved et
vægtet straight-skeleton. Brugeren kan herefter skære toppen af det rejste tag, hvorved der i
skæringen mellem taget og planet opstår et polygon (Figur 80).
83

Figur 80: I skæringen mellem plan og tag opstår et polygon.
Fra dette polygon kan et nyt tag rejses, med nye parametre, hvormed det er muligt at frembringe en
lang række forskellige tagtyper. Dette er således en slags lagdelt modellering. Da min metode skal
fungere automatisk i forbindelse med proceduralmodellering, er det selvfølgelig ikke praktisk muligt,
at brugeren manuelt skal opsætte klippeplaner, og angive nye hældningsparametre. Målet er, i grove
træk at automatisere lagdelingen, samt finde en måde hvorved en algoritme simpelt kan angive
parametre til en sådan model.
Vi starter med at betragte et straight-skeleton. I [Brenner, 2000] finder vi en helt central observation:
I stedet for at arbejde med vinkelhalveringslinjer i en 2-dimensionel flade, kan vi betragte disse som
skæringer mellem uendelige planer i 3 dimensioner. I stedet for at vi forestiller os bølgefronter der
har udspring i kanterne i polygonet, kan vi forstille os et såkaldt sweep-plan, der bevæger sig opad fra
oprindelsespolygonens plan. Figur 80 afbilleder et sweep-plan i en given højde over udgangsplanet.
Analogisk til den traditionelle algoritme kan man følge hjørnerne i skæringspolygonen mens sweepplanen
bevæger sig opad, og spore kanterne til et straight-skeleton. Det er klart at man ikke kan
evaluere alle tænkelige positioner af sweep-planen, men man kan nøjes med kun at evaluere i eventpunkter.
Et event-punkt opstår i den 3-dimensionelle analogi, ganske enkelt, der hvor 3 eller flere
planer skærer hinanden. Til sidst kan vi foretage en søgning, og udlede alle flader i det endelige tag.
Event-punkterne bliver alle til vertices i tagmodellen.
84

Med min baggrund i computergrafik foreslår jeg, at man betragter et straight-skeleton i 3d som et
clipping-problem. I afsnit 3.3.1 så vi hvordan et polygon kan klippes (skæres) mht. til en plan.
Derimod er skæring af et polygon mht. et andet polygon en kompliceret affære, både i 2d og 3d. I
stedet er det muligt at skære et polygon med et andet polygons udspændte plan, og altså anvende
metoden fra afsnit 3.3.1. Alle polygoner der udgør de endelige tagflader er plane, hvorved en sådan
skærings-operation altid er mulig.
Figur 81: Skæring af to polygoner i 3d ved hinandens udspændte planer.
For et konvekst grundplan er det muligt at rejse et valmet tag, ved at definere et uendeligt stort
kvadratisk polygon for hver tagflade, og efterfølgende klippe disse med alle andre tagfladeplaner
samt til sidst grundplanet. Vi kan naturligvis ikke forstille os en konkret implementering hvori det er
muligt at arbejde med uendeligt store polygoner. Derfor må vi nøjes med relativt store polygoner (jeg
vil senere diskutere konsekvensen af dette valg).
I modsætning til konvekse grundplaner er det for ikke-konvekse grundplaner muligt, at der i nogle
tilfælde opstå ikke-konvekse tagflader, hvilket kan ses i eksemplet fra Figur 30:
Figur 82: Den røde tagflade er ikke-konveks, og gennemskæres af det blå polygons plan netop langs den blå
stiplede skæringslinje.
85

Ved at klippe en konveks polygon med andre planer er det umuligt at frembringe en ikke-konveks
polygon. I eksemplet i Figur 82 vil det blå polygons plan gennemskære det røde polygon, hvorved
den yderste del af tagfladen (den del der ligger på den positive side af den blå tagflades plan) vil
mangle. I det generelle tilfælde er det således ikke korrekt at klippe alle polygoner med alle andre
polygoners plan. For at overkomme problemet med konvekse tagflader kan de deles i mindre
stykker. Her kan vi igen benytte analogien til den almindelige fremgangsmåde for straight-skeleton,
og betragte et sweep-plan der gennemløber et antal event-punkter fra grundplanet og opad. I
eksemplet fra Figur 82 er der fire event-punkter (punkter hvor 3 eller flere kanter skærer hinanden).
Hvis man betragter deres højder, kommer de i par af to, og sweep-planet vil derfor gennemløbe 3
positioner (inklusiv grundplanen):
Figur 83: Taget i Figur 82 set fra siden. De røde linjer markerer de positioner, sweep-planet gennemløber.
Fra teorien om straight-skeleton ved vi, at de yderste knuder i skelettet altid er knuderne fra
grundplanet. Kanterne forbundet til disse er samtidig altid vinkelhalveringslinjen mellem to nabokanter
i grundplanet. Metoden starter derfor med at skære tagfladerne med planerne fra de to
nabotagflader i grundplanet. Skæringsplanet orienteres ved at betragte krydsproduktet mellem
tagfladernes normal. Dermed kan både refleks-punkter og konvekse punkter i grundplanet
håndteres. Herefter skæres polygonerne med sweep-planet i det første event-punkt, og vi har nu de
nederste dele af tagfladerne. Skæringen mellem sweep-planet og tagfladerne danner et nyt polygon,
hvorfra metoden fortsætter på samme måde. Dette gentages indtil skærings polygonen har arealet 0,
hvormed taget er rejst. Bemærk at skæring med et arbitrært plan, der er parallel med grundplanen,
kan resultere i flere nye adskilte polygoner. Denne situation opstår ved split-events.
1 2 3
86

4 5 6
Figur 84: 1) Et meget stort polygon konstrueres for hver kant i grundplanen. 2) Polygonen beskæres med de to
naboplaner. 3) Polygonen beskæres med sweep-planen for det første event-punkt. 4) Det same gøres for de
resterende kanter i grundplanet, hvorved et nyt polygon opstå. 5) Metoden gentages for det nye polygon. 6) De
forskellige lag samles til hele tagflader.
Figur 85: Algoritmen visualiseret i 3d.
Fordelen ved denne fremgangsmåde er, at vi ikke behøver en efterfølgende udledning af
polygonerne, da disse er en del af selve datastrukturen. Derudover er den konceptuelt simpel, og
behøver ingen avancerede datastruktur, og endelig passer metoden perfekt til de videre udvidelser
der vil blive beskrevet i de følgende afsnit.
I det første skridt konstruerer man et meget stort polygon, hvilket betyder, at metoden indfører
begrænsning i størrelsen af tage (afhængigt af hvor stort dette polygon er). Jeg vil argumentere for, at
denne begrænsning findes i forvejen som resultat af begrænset numerisk præcision. Ved alt for store
straight-skeletons bliver præcisionen meget lav, og man risikerer fejl. Det kan diskuteres om en
metode baseret på plan-skæring opretholder en højere numerisk præcision. Algoritmen er derimod
utroligt robust mod eventuel upræcision, hvilket er endnu en stor fordel ved metoden.
87

5.1.2 Lagdelt tagmodel
Den ovenfor beskrevne metode håndterer vægtede tagflader (tagflader med individuel hældning),
ved at konstruere udgangspolygonen med varierende hældning. Metoden kan endda håndtere
enkelte tagflader med en hældning over 90 o , altså sider der skråner udad i forhold til grundplanen.
Et saddeltag kan f.eks. konstrueres ved at sætte hældningen på gavlene til 90 o , men vi kan stadig ikke
konstruere f.eks. et mansardtag.
For at løse dette foreslår jeg en lagdelt tagmodel baseret på straight-skeleton (SSLRM Straight
Skeleton Based Layered Roof Model). Man kan betragte siderne i et mansardtag som en todelt
tagflade der består af en nedre del med en høj hældning, der knækker til en tagflade med en lavere
hældning. En opstalt af en sådan side ser ud som følger:
Højde = 4; Vinkel = 30 o
Højde = 0; Vinkel = 70 o
Figur 86: Eksempel på opstalt for en side i et mansardtag. Nederste del starter i 0, og har en vinkel på 70 o . Øverste
del starter i højden 4, og har en vinkel på 30 o .
I stedet for at tilknytte en hældning til en kant i grundplanet foreslår jeg at man knytter en opstalt,
hvorved det er muligt at beskrive knæk der måtte optræde i tagsiden. En opstalt er således en liste af
knæk, der beskriver højden for knækket, samt den efterfølgende vinkel.
88

Figur 87: Mansardtag, konstrueret af gavle med lodrette hældninger, og sider med knæk.
En implementering af denne metode starter med at finde alle højderne for knæk i den pågældende
model, sorterer disse og eliminerer redundans (flere stop i samme højde). Én fremgangsmåde er, at
bygge det fulde straight-skeleton for den nederste sektion af taget. Herefter skæres taget i højden af
det første knæk, hvorved et nyt polygon opstår, og hvorfra vi kan gentage processen. Det er klart at
denne fremgangsmåde minder meget om processen for konstruktion af skelettet ved skæring, der
beskrives i afsnit 5.1.1. Det er således også muligt at kombinere disse ved, først at finde alle eventpunkter
til et straight-skeleton, og derefter kombinere disse med alle knæk i samlingen af opstalter.
Dette giver en samling af anvendelige skærings-planer, hvorfra den laveste, der stadig er højere end
sweep-planen vælges.
Når hver ny sektion af taget bygges, spørges der hos hver opstalt for at finde hældningen til den
pågældende tagside i den specifikke højde. Derfor føres opstalten videre fra kanterne i én sweepposiotion
til de resulterende kanter i den næste.
Følgende figur illustrerer alle sektioner af et mansardtag med halvvalmede gavle:
89

Figur 88: Illustration af sektioner i et mansardtag med halvvalmede gavle. Bemærk at der både er skæringsplaner
ved event-punkter samt ved knæk i tagfladen.
5.1.3 Parametriske tage
Det foregående afsnit beskriver en metode der kan bruges til at modellere en overordentlig stor
variation af forskellige tagtyper. Målet er nu, at passe denne model ind i CGA-shape-grammar–
systemet. Dette gøres ved at repræsentere tagene ved den simplest tænkelige parameterisering.
Det første problem vi støder på i denne forbindelse er, at alle sider skal tildeles en opstalt, hvilket er
uegnet til brug i en grammar. Der er ganske enkelt for mange input-parametre at tage stilling til, og
en procedural-metode kan derfor let resultere i kaos. Desuden er det for en brugers vedkommende
upraktisk at skulle angive så stor en mængde inputdata.
Med den nye metode beskrevet i forrige afsnit kan vi let beskrive disse tage med meget få parametre.
Eksemplet i Figur 86 indeholder et knæk, og kan beskrives ved en tagside der starter i højden 0 med
en hældning på 70 o , der knækker i højden 4 med en efterfølgende hældning på 30 o . Disse parametre
kan samles i et simpelt sæt, der entydigt definerer tagsiden, f.eks:
mansardtag = {0, 70 o , 4, 30 o }
En simpel gavl i et saddeltag kan beskrives ved følgende parametre:
saddelgavl = {0, 90 o }
90

Hvis vi betragter virkelige tage opdager vi, at langt de fleste almindelige tagtyper består gavle og
almindelige sider. Jeg foreslår derfor, at udvide metoden med en overbygning, der forsimpler
beskrivelsen af tage, til kun at bestå af en gavltype og en tagsidetype.
For at beskrive et tag behøver systemet derfor følgende input parametre: Et sæt kanter i grundplanet,
gavlene i grundplanet, en beskrivelse af tagsiderne og en beskrivelse af gavlene. Et brugerscenarie
kan dermed se ud som følger: Brugeren skitserer grundplanerne, udpeger gavlene og vælger mellem
forskellige side og gavltyper og endelig sætter hældning og knæk for disse typer.
Figur 89: Kompleks bygning udelukkende modelleret som gavle (venstre: saddelgavl) og almindelige sider
(højre: opskalk).
Det er selvfølgelig klart, at dette er en indskrænkning af udtryksfuldheden af systemet. En bruger må
begrænse sig til at tænke på et tag som bestående af sider og gavle. Jeg vil argumentere for at langt
de fleste tage i rimelig grad kan beskrives på denne måde. Det kan diskuteres om der er behov for 2,
3 eller evt. flere sidetyper. Pointen er overordnet, at vi er nødt til at begrænse frihedsgraderne for
inputdata for samtidig, at begrænse mængden af beslutninger der er nødvendige fra brugeren eller
en procedural-algoritme.
Når inputtet er et resultat af en procedural metode, kan vi ikke forvente bygningsformer der passer
ind i den nye model for tagmodellering. Et eksempel på et typisk problem for metoder der tager
grundplanet som input, er placering af gavle i et simpelt L-formet hus. For denne hustype kan vi
umiddelbart forestille os tre forskellige måder at konstruere gavlene:
91

Figur 90: Eksempler på tre forskellige gavlkonfigurationer for et l-formet hus. Som udgangspunkt er enderne af
længerne gavle. Den 3. gavl er derimod flertydig: Øverst til venstre: Den smalle længe har midtergavlen. Øverst
til højre: Der er kun gavle i enderne. Nederst: Den bredde længe har midtergavlen.
Da den øst - vestgående længe er bredest, forventer vi intuitivt, at denne må have en gavl i hver ende
(Nederste eksempel i Figur 1). Problemet er: Hvordan udtrykkes dette udelukkende ved hjælp af
kanterne i grundplanet?
For det første skal den yderste venstre kant i eksemplet fra Figur 90 deles i to, da en tagflade ikke
samtidig kan være lodret og hældende. Således kan vi angive følgende kanter som gavle:
92

Figur 91: Angivelse af gavle (røde kanter) i et l-formet huse.
Dermed har vi angivet gavlene i huset, men dette forårsager problemer for udledningen af et
straight-skeleton. Problemet er, at de to splittede kanter er parallelle. I en traditionel algoritme for
beregning af en skelet-graf, vil man blot kollapse de to parallelle linjer, og altså ignorere det nye
punkt i polygonen (den røde knude i Figur 91). Problemet er at de to kanter, hver i sær indeholder
information, der er vigtig for den endelige definition af taget.
Hvis vi forsøger at føde de to parallelle nabokanter til polygon-klippe-algoritmen vil den fejle. De
udledte planer er ikke parallelle, men skæringen mellem dem vil være parallel med kanten i
grundplanet, og dermed ubrugelig. Vi er derfor nødt til at håndtere parallelle nabokanter i
grundplanen.
Når vi betragter taget i Figur 92, opdager vi at det røde område vil blive klippet ud, som følge af
skæring mellem polygonen fra den røde linje, og planet for den gule tagflade (i det nederste segment
af tagfladen).
93

Figur 92: Saddeltag på l-format bygning. Det røde område vil blive klippet fra pga. det gule polygon.
Løsningen på problemet er følgende: Hver gang vi støder på parallelle nabokanter i grundplanet,
indsætter vi et plan (en meget stor polygon) mellem disse, der samtidig er vinkelret på begge
tagfladernes planer. Det gælder nu om at vælge hældningen for dette plan intelligent. Mit forslag er
at vælge den laveste af de to hældninger, og orientere denne så den hælder ind i planen med den
højeste hældning. Hvis begge hældninger er lige store sættes den nye plan til lodret.
I eksemplet i Figur 92 vælges altså hældningen fra den skrånende tagflade, der hælder ind i den
lodrette side, hvorved det ønskede resultat opnås.
Processen, med at finde parallelle kanter og indsætte hjælpeplaner, gentages for hver position i
sweep-planet, hvilket giver en yderst robust, effektiv og fleksibel algoritme.
Anvendelsesmulighederne vil blive nærmere belyst i resultatafsnittet.
5.1.4 Parametriske tage i CGA
Det sidste problem jeg vil behandle er, hvordan vi får tagmodellen ind i CGA-shape-grammarsystemet?
Sproget i dette system har en sammenhængende syntaks, og vi ønsker at bevare
konsistensen, samtidig med, at vi indfører den nye metode til håndtering af tage.
Én måde at rejse tage på proceduralmodellerede huse er ved, at tilføje dem ved en postproces, der
tager bygningens massemodel som input. Fra massemodellen kan bygningens grundplan udledes, og
algoritmen kan starte. Problemet ved en postproces er, at taget dermed ikke længere indgår som en
del af grammaren. Det er således ikke muligt at tilføje detaljer i tagfladerne, som f.eks. kviste,
skorstene, tagsten eller tagvinduer. Ligesom det for facadernes vedkommende er uacceptabelt ikke
at kunne modellere detaljeret geometri, gælder det samme for tagflader.
Ved at beskrive tage parametrisk er det enkelt at modellere dem i en grammar. Dette kunne f.eks.
være via en makro:
Roof(”mansard”, 70, 3, 30)
94

Her angives et mansardtag med indledende hældning på 70 o , og en øvre sektion med en hældning på
30 o , der starter i højden 3. Dette passer godt ind i det allerede eksisterende system, men vi kan
hurtigt identificere en række problemer. Første problem er, at vi mangler at forsyne algoritmen med
grundplanet. I den ovenstående makro kan man forestille sig, at grundplanet udledes fra den figur
makroen anvendes på. Der er to problemer ved denne fremgangsmåde: For det første indeholder
figurerne, vi hidtil har anvendt, ingen specifikation af gavle. For det andet består et hus ofte af en
komposition af flere figurer, der sammen udgør en samlet massemodel. Den ovenstående makro vil
kun være i stand til at bygge et tag til hver enkelt af disse figurer, og dermed ikke en samlet tagmodel
for hele huset. Dette er det samme problem, som beskrevet i Figur 78 på side 80.
Min løsning er, at dele tagmodelleringen i to separate skridt. Først finder vi alle kanter i grundplanet.
Derefter rejser vi taget på baggrund af disse kanter. Til at finde kanterne indfører vi et nyt argument
til komponentsplittet, der returnerer alle kanter i grundplanet:
Comp("footprint", 0, 1) {roofEdge}
Parameteren ”footprint” fortæller makroen, at vi ønsker at finde husets grundplan. De efterfølgende
parametre indikerer en vektor der udpeger gavlene i denne grundplan. Resultatet er en række figurer
af en særlig kant-type, der indeholder et flag der markerer, hvorvidt de er gavle eller ej. I dette
tilfælde navngives grundplanskanterne ”roofEdge”.
Udpegningen af gavle foregår i figurens scope-koordinatsystem. Alle kanter der er nøjagtigt vinkelret
på gavl-vektoren markeres som gavle:
Figur 93: Vektoren angiver gavlene (de røde kanter).
I stedet for at lade tag-makroen operere på forgængerfiguren, tilføjes en ny parameter der fortæller
hvilke kanter i konfigurationen der indgår i tagets grundplan:
Roof(”roofEdge”, ”mansard”, 70, 3, 30)
Roof-kommandoen indsamler alle kanter i samme højde med navnet roofEdge, og anvender disse.
Det er muligt at sikre, at alle kanter er udledt, før man kalder Roof-kommandoen ved, at give
produktionen lavere prioritet. Dermed vil en typisk modellering af et tag se ud som følger:
95

Priority: 1
...
top -> roof Comp("footprint", 0, 1) {roofEdge};
Priority: 2
roof -> Roof(”roofEdge”, ”mansard”, 70, 3, 30)
{roofFace | gable};
...
Et typisk brugerscenarie indebærer en massemodel bestående af flere separate figurer, f.eks. et hus
med dets forskellige vinger. Hvis vi ønsker at bygge et samlet tag har vi brug for kanterne fra alle
husets grundplaner. Hvis disse figurer overlapper hinanden har vi situationen afbilledet i Figur 94
(til venstre). Dette input vil ikke umiddelbart kunne anvendes i tagmodellen. For at korrigere
inputdata fortager jeg en sæt-union på alle grundplanernes polygoner. Jeg sørger samtidig for, at
gavle har højere prioritet end ikke-gavle i de tilfælde hvor to eller flere kanter er parallelle og
overlapper hinanden. Dette giver resultatet i Figur 94 til højre. Den opmærksomme læser vil
bemærke, at dette resultat er magen til udgangspunktet Figur 91.
Figur 94: Der fortages en sæt-union på massemodellens overlappende grundplaner (union af to polygoner).
I grammaren er der to skridt i afledningen af et tag (Comp og Roof), hvilket reflekterer modellen
meget elegant, da den netop behøver to typer inputdata. Efter min mening passer denne
fremgangsmåde meget fint ind i det eksisterende CGA. Desuden benytter vi os af makroer og et
udvidet komponentsplit, hvilket ikke bryder med de sædvanlige dogmer i modellering med shapegrammaer.
96

5.2 Implementering
I dette afsnit vil jeg gå mere i dybden med de implementeringsspecifikke detaljer, i forbindelse med
den metode der er blevet udviklet igennem dette projektforløb. Da kildekoden til prototyperne er
meget omfattende vil jeg, af hensyn til læseren, beskrive systemerne i overordnede træk. For flere
detaljer vil jeg henvise til kildekoden der kan findes på den medfølgende CD, eller på adressen:
http://www.student.dtu.dk/~s042624/eksamensprojekt/Source%20code/. En vejledning til afvikling
af programmerne findes ligeledes på CD’en eller på adressen:
http://www.student.dtu.dk/~s042624/eksamensprojekt/.
Prototypen består af 4 forskellige applikationer, der alle er udviklet i .Net og c#. Baggrunden for
dette valg er udelukkende baseret på, at produktiviteten for mit vedkommende er højere i dette
framework og, at jeg samtidig har mulighed for at benytte mig af det udmærkede katalog af
værktøjer der medfølger. Grafikken er for 3d-applikationernes vedkommende udviklet i Microsofts
XNA 3.1, der er et grafik bibliotek, der åbner DirectX (9) til .Net-platformen og samtidig tilbyder en
række værktøjer henvendt til 3d-grafikprogrammører. For 2d-applikationernes vedkommende er
grafikken udviklet i Microsoft WPF (Windows Precentation Foundation), der er afløseren for
winForms.
Prototypen består af følgende applikationer:
LSystem3_1: Denne applikation er en
træmodel-generator, der skal
demonstrere min implementering af Lsystemerne.
Systemet hedder 3_1 for at
differentiere den fra en tidligere version,
der blev udviklet til XNA 2.0. Som
argument tager applikationen en
reference til en fil indeholdende lsystemet,
samt et tal der indikerer
alderen på de producerede træer.
Applikationen kompilerer l-systemet, og
udleder 5 forskellige træmodeller, der
visualiseres og gemmes i en fil (tree.obj)
af typen .obj.
97

RoofBuilder: Denne applikation skal
demonstrere fleksibiliteten af min
tagmodelleringsmetode. Brugeren kan,
via en simpel brugerflade, skitsere et
grundplan, angive gavle og vælge
gavltype og tagsidetype. I denne
prototype er det muligt at vælge
mellem: Flad gavl, valmet gavl,
halvvalmet gavl, hollandsk gavl,
saddeltag, mansardtag og opskalket tag.
Endeligt er det muligt for brugeren at
angive parametrene til de respektive
tagtyper.
CGA+: Denne applikation er en
bygningsmodelgenerator, der skal
demonstrere min implementering af
CGA. Jeg har tilføjet ’+’ i min udgave af
systemet for at indikere, at dette er en
forbedret version af det oprindelige CGA
(med den forbedrede
tagmodelleringsmetode). Som argument
tager applikationen en reference til en
fil indeholdende en CGA-grammar.
Systemet kompilerer denne fil, og
producerer en bygnings-model, der
visualiseres og gemmes i en fil
(model.obj) af typen .obj. Hvis det er
ønskeligt kan applikationen også tage
en reference til en fil indeholdende GISdata,
hvormed det er muligt at genere
bygningerne til en hel by.
98

GISDrawer: I denne applikation er det
muligt at skitsere og redigere GIS-data
der kan læses af CGA+ -applikationen.
Fra denne applikation er det muligt at
starte CGA+, og evaluere sin GIS-data.
Derudover har programmet et property
systemet, der sørger for, at de relevante
parametre bliver sat i shapegrammaren.
5.2.1 XNAUtil
De ovennævnte applikationer gør alle brug af en række hjælpefunktioner, som derfor er samlet i et
fælles assembly: XNAUtil.
Først og fremmest indeholder hjælpebiblioteket en række matematiske hjælpeklasser, der ikke
findes i XNA’s linear-algebra-bibliotek: BoundingBox2D, der er en simpel axis-aligned-boundingbox i
2d, og klasserne Edge2D og Edge3D, der er simple kanter med et start og slutpunkt i hhv. 2d og 3d.
XNA har et forholdsvis veludviklet bibliotek til lineær algebra med 32 bits float præcision. I mit
arbejde med især tagmodelleringsmetoden har det vist sig, at 32 bit ikke er tilstrækkeligt til at opnå
en acceptabel robusthed. Derfor har jeg måtte rekonstruere en betydelig del af XNA’s lineær algebrabibliotek
med 64 bit’s (double) præcision. Hjælpeklasserne findes under PrecisionLinAlg i XNAUtil
og indbefatter: Matrix4D, PlaneD, RayD, Vector2D og Vector3D. Navngivningen følger de tilsvarende
metoder i XNA, men med et ’D’, der indikerer double-præcision. Klasserne indeholder i vidt omfang
de samme metoder, som deres analoge klasser i XNA.
I dette projekt har jeg gjort brug af en række algoritmer til at finde skæringen mellem forskellige
geometriske objekter. Disse algoritmer er samlet i klassen IntersectionAlgorithms i XNAUtil, og disse
inkluderer:
Linje-linje skæring, mellem to uendeligt lange linjer (LineLineIntersection).
Stråle-plan skæring (RayPlaneIntersection).
Stråle-polygon skæring (RayPolygonIntersection)
Test for sammenfald mellem punkt og polygon i 2d (PointPolygonIntersection).
Afstand mellem punkt og linje, samt afstanden langs linjen til punktets projektion på linjen
(PointLineIntersection).
Skæringspunkt mellem 3 planer (ThreePlaneIntersection).
Test for separerende akse mellem polygoner i 2d (SeperatingAxis2D)
For algoritmer hvor det har været nødvendigt er de implementeret i både 32 og 64 bits præcision.
Derudover indeholder XNAUtil et hjælpebibliotek til geometriske beregninger, der bl.a. indeholder
funktionerne beskrevet i afsnit 3.3.1 (Den geometriske værktøjskasse).
99

For de ovennævnte applikationer har jeg haft behov for at kunne rendere den producerede 3dgeometri.
Derfor inkluderer XNAUtil et simpelt render-system (render-engine), der er bygget op
omkring en scene-graf til beskrivelse af scenen. Denne graf består af en række knuder, der kan
indeholde en liste af model-objekter (Renderable), en liste af attributter (f.eks. lyskilder eller
materialer) og en liste af efterfølgende knuder. Hver knude har desuden en transformation, hvilket
også gælder for alle modeller.
Figur 95: Eksempel på scenegraf.
Render-systemet tilbyder følgende værktøjer og effekter:
Rendering af modeller med teksturering og per-pixel belysning.
Rendering, med eller uden wire-frame.
Rendering af bill-boards med sortering via en simpel 2-pass metode.
Attenuering af alfa-værdi for bill-bords, når disse renderes parallelt med kameraet. Denne
effekt er særligt velegnet til rendering af grene på træer, da man tydeligt opfatter artefakterne
ved parallel rendering.
Materiale-system.
100

Punkt og retningslyskilder.
Skygger via shadow-map algoritmen.
Screen-space ambient occlusion.
Kameraføring med track-ball.
2D-renderng af linjer, cirkler og streger med brede, afrundede hjørner og affasede hjørner.
Systemet er bygget op omkring en række HLSL-effekter (High Level Shader Language), dog kan disse
udskiftes fuldstændigt i tilfælde med særlige behov. Dette er muligt, da systemet søger efter
semantiske tags i effektfilerne, hvorved det er i stand til at identificere HLSL-effektens parametre.
Figur 96: Eksempel på rendering med bill-boards, skygge og ambient occlusion.
5.2.2 Coco / r
Både i tilfældene for min implementering af L-systemer og CGA-shape-grammaer, har jeg brug for at
bygge parsere der kan afkode syntaksen. Det er ikke umiddelbart en triviel opgave at bygge en parser
til et relativt komplekst sprog som f.eks. L-systemer. Til at bygge parsere og compilere findes der
heldigvis en række stærke hjælpeværktøjer, såsom f.eks. yacc/lex. Jeg har valgt at benytte compilergeneratoren
Coco/r. Begrundelsen for dette valg er, at værktøjet bl.a. understøtter c#, det er
forholdsvis simpel og overskueligt og manualer og vejledninger er let tilgængelige og velskrevne
[Mössenböck, 2006]. Jeg vil i den forbindelse nævne, at jeg ikke selv har store erfaringer med
compilerværktøjer, og derfor spiller det sidste argument en væsentlig rolle i mit valg.
101

Coco/r blev oprindeligt udviklet af en gruppe på Johannes Kepler Universitetet i Linz, og er en
compilergenerator der tager en beskrivelse af et sprog i form af en EBNF-grammar (Extended Backus-
Naur Form), og producerer en compiler til dette sprog. Compileren er en såkaldt recursive-descent
compiler, der har en metode for hver produktionsregel i sprogdefinitionen, hvorfra den rekursivt kan
kalde andre funktioner der repræsenterer andre produktionsregler. Dette begrænser compileren,
men gør den også attraktiv for uerfarne programmører, der skal løse mere begrænsede
problemstillinger. Kompileren tager desuden en manifestfil, hvor det er muligt at angive konstanter
og inkludere hjælpemetoder. Manifestet bliver brugt som skabelon for den endelige parser.
Sprogbeskrivelsen er delt i to hoveddele: En scanner-specifikation og en parser-specifikation.
Scannerens opgave er at inddele inputfilen i tokens, der benyttes af parseren. Scanneren definerer et
antal tegn-sæt, og et antal tokens. En token kan angives via et regular-expression, som f.eks.:
Identifier = letter {letter | digit}.
I Coco/r betyder ’{}’ en gentagelse af alle symboler mellem klammerne 0 eller flere gange. Parseren
består i hovedtræk af et antal produktionsregler, der beskriver den syntaktiske struktur af de ikketerminale
symboler i sproget. Følgende eksempel definerer erklæringen af en talkonstant:
ConstantDeclaration =
(
"number" identifier "=" number
)
Parseren arbejder fra venstre mod højre i produktionsreglen (LL-parser), og for hver identificeret
element er det muligt at definere en semantisk handling (et stykke c#-kode, der vil blive sat ind i
parseren). Jeg bruger de semantiske handlinger til at opbygge en data-repræsentation af det
kompilerede system i c#.
I begge mine systemer har jeg brug for, at kunne parse algebraiske og boolske udtryk. Følgende
grammar vil identificere et almindeligt algebraisk udtryk, svarende til dem vi finder i f.eks. c#
[Crenshaw, 1988]:
Expression = Term { addop Term }
Term = SignedFactor { mulop Factor }
SignedFactor = [ addop ] Factor
Factor = number | variable | ”(” Expression ”)”
I denne forbindelse indeholder addopp symbolerne ’-’ og ’+’, og mulopp indeholder ’*’ og ’/’.
Boolske udtryk har en tilsvarende form. Med grammaren er det muligt at opbygge et evalueringstræ,
der kan benyttes, hver gang udtrykket skal evalueres. Af hensyn til systemets ydeevne har jeg valgt at
benytte .Net’s runtime-compiler, der kan tage et stykke kode i tekstform, kompilere det og afvikle det
mens systemet kører. Jeg har dermed mulighed for at kompilere de algebraiske udtryk og afvikle dem
direkte i .Net’s runtime-miljø.
5.2.3 Datastruktur for CGA+
Jeg har defineret CGA som sprog via Coco/r, men uden en datastruktur til at bygge det parsede
system ind i, er vi lige vidt. Datastrukturen for CGA består af en række produktionsregler, der med
udgangspunkt i en inputfigur, producerer en række resulterende figurer. Systemet itererer over alle
102

figurer i den aktuelle konfiguration, og vælger passende regler til aktive figurer, hvorved flere figurer
tilføjes konfigurationen. Dette er meget tilsvarende fremgangsmåden for L-systemer bortset fra, at vi
i dette system udvælger aktive figurer en ad gangen, og lader afledningsprocessen løbe, indtil der
ikke er flere aktive figurer i konfigurationen. Man kan sammenligne L-systemer med en bredde-først
afledning, mens CGA er en dybde-først afledning.
Figur 97: Overblik over systemets overordnede design.
En såkaldt makro i CGA foretager operationer på figurer, der resulterer i en eller flere afledte figurer.
En Comp-kommando splitter f.eks. en figur i figurer af lavere dimension (f.eks. en kasse der splittes i
flader, kanter eller punkter). Samtidig kan figurer være af forskellige typer (f.eks. kasser, kugler eller
cylindre). Dette håndteres i datastrukturen, ved at alle systemer implementerer et fælles interface,
med metoder der reflekterer alle makroer i CGA. Dette kan f.eks. være metoder der bl.a. returnerer
alle flader eller sideflader og en metode der splitter figuren langs en given akse. Det implementerede
system er som sagt en prototype og ikke alle metoder beskrevet i interfacet er implementet i alle
figur-typer.
Jeg har i dette projekt specielt fokuseret på evnen til at kunne ekstrudere et grundplan til en massiv
figur. Derfor har jeg implementeret en figur der defineres af et polygon, der kan ekstruderes til en
højde angivet af figurens scope-højde. Hver kant bliver i grundplanet til en (firkantet) flade i det
massive polygon, og top og bund afsluttes af en figur svarende til grundplanet.
103

Figur 98: Femkantet grundplan ekstruderet til massiv figur (defineret indenfor figurens scope).
I min definition af sproget for CGA har jeg muliggjort erklæringen af talvariable og
tilfældighedsvariable. En talvariabel svarer til almindelige double-variable i andre
programmeringssprog, og erklæringen har følgende syntaks:
number n = 2.1;
En tilfældighedsvariabel returnerer et tilfældigt tal inden for et angivet udfaldsrum, hver gang den
evalueres. En sådan variabel med et udfaldsrum der f.eks. går mellem 0 og 1, kan erklæres som følger:
random r = [0, 1];
Tilfældighedsvariable er meget anvendelige både i L-systemer og CGA, hvis vi ønsker at indføre
variation i vores genererede modeller.
Variablene kan opfattes som globale parametre der definerer globale design-mål for den enkelte
genererede model. Dette kan f.eks. være parametre såsom bygningshøjde, vinduers bredde, antal af
etager eller taghældning. Der kan også være tale om mere abstrakte begreber, såsom facadetype og
tagtype.
I min implementering har jeg fortaget mindre justeringer i forhold til oplæget fra [Müller, Wonka,
Haegler, Ulmer, & Van Gool, 2006]. Specielt er syntaksen for relative parametre ændret fra at et tal
efterfulgt af et ’r’, til at være et tal indledt med en stjerne. Relativparameteren med vægten 1 vil f.eks.
være *1.
Når det gælder fordeling af ansvarsområde, vil jeg differentiere imellem grammar og applikation.
Applikationen er programmet der huser grammar-compileren og angiver variablene til grammaren.
104

Grammaren definerer produktionsregler og anvender parametrene til at modellere bygninger og
arkitektur. Jeg kan derfor, på applikationsniveau, trække lod om tagtype, facadetype og sætte globale
design-parametre med stokastiske værdier, inden afledningsprocessen for produktionsreglerne
begynder. Dermed bliver disse parametre gældende for hele bygningen, og vi undgår kaotiske
modeller. Når CGA-grammaren er færdigevalueret, kan jeg på applikationsniveau læse alle figurer,
og sende disse til mit rederingssystem. I den forbindelse kan jeg anvende figurenes navne, som
markør for figurens materiale. F.eks. kan et vindue indeholde underfigurer med navnene glass og
frame, der kan matches med passende materialer.
105

6 Resultater
I dette afsnit vil jeg præsentere de resultater jeg har opnået i løbet af dette projekt. Projektet
spænder vidt, men jeg vil i dette afsnit hovedsagelig fokusere på modellering af tage og bymiljøer, og
især på de dele der repræsenterer bidraget fra dette projekt.
Jeg vil redegøre for, at målene fra afsnit 1.1 er blevet opfyldt. Vurderingen af resultaterne vil
hovedsageligt være kvalitativ, da resultatet ikke i væsentlig grad bør måles i metodens hastighed,
men snarere det overordnede visuelle indtryk. Derfor vil der især blive lagt vægt på billedmateriale
som formidler af projektets resultater.
For grafikeren, der er slutbrugeren, er det vigtigt at han/hun har mulighed for at arbejde videre med
modellerne i et af de mange eksisterende modelleringsværktøjer. Jeg har derfor inkluderet
eksportfunktioner i mine prototyper, hvorved jeg har mulighed for at vurdere resultaterne i disse
modelleringsværktøjer. For at bedømme hvordan modellerne virkelig tager sig ud, er det vigtigt at de
er renderet med de rette materialer. Derfor har jeg til mange af resultatbillederne i det følgende
afsnit anvendt blender, der er et gratis open-source modelleringsværktøj, som også inkluderer en raytracer
til syntetisering af billeder af høj kvalitet. Ved hvert billede vil det være angivet, hvorvidt det
er renderet ved ray-tracing eller med min egen realtids-render-engine.
For at teste min implementering af CGA systemet, vil jeg i enkelte tilfælde angive tidsmålinger for
genereringsprocessen. Disse er alle målt på en laptop med en Intel Core 2 Duo 2.4 GHz CPU, og er et
gennemsnit af 10 forskellige målinger. Det skal nævnes at testen i mange tilfælde er gjort på
stokastiske grammaer hvor antallet af polygoner kan variere forholdsvis meget, og hvor de enkelte
målinger derfor også varierer meget.
6.1 L-systemer
Formålet med at bygge en L-systems parser var hovedsageligt, at jeg dermed kunne øve mig i parserværktøjet
på et område, jeg kendte rimeligt godt. Det til trods mener jeg, at resultaterne er blevet
forholdsvis gode, og de proceduralgenerede træer har været velegnede som inventar i sammenhæng
med de genererede bymiljøer.
Som udgangspunkt er det muligt at skrive l-systemer i kodefiler i en syntaks, der næsten nøjagtigt
svarer til syntaksen i [Lindenmayer & Prusinkiewicz, 1996]. I bilag 1 medfølger eksempler for
produktionsreglerne for 4 forskellige trætyper. Til fortolkning af L-systemer har jeg først og
fremmest implementeret muligheden for parametriske L-systemer, samt de basale symboler, så som
’F’, ’Size’, ’Push’, ’Pop’, ’Roll’, ’Pitch’ og ’Yaw’. Jeg har desuden implementet en fortolker af L-systemer,
der som udgangspunkt producerer kegleformede segmenter. Dette giver mulighed for at modellere
forgrenede fraktaler:
106

Figur 99: Forgreningsfraktal, genereret via et l-system. Bemærk hvordan rotation i stammen ikke medfører
huller i modellen.
Af mere avancerede symboler kan nævnes min implementering af parametrisk tropisme (’T’),
tilfældig retning (’R’), fastholdt forgrening i forhold til tyngdekraften (’level’) og endelig muligheden
for varierede udformninger af stammer. Disse egenskaber giver mulighed for modellering af følgende
træstruktur:
107

Figur 100: Modellering af træ via et l-system.
Bemærk hvordan stammen ikke er regulært cylinderformet, og hvordan grenene vrider sig.
Tropismen starter positive (de yderste led af grenene) hvor grenen søger opad mod lyset, men
reduceres til negativ efterhånden som længden og vægten af grene tynger dem ned. Dette fænomen
kan opserveres i mange virkelige træer:
Figur 101: Grene på dette træ søger tydeligvist opad, mens tyngdekraften trækker de længste nedad.
108

For at gøre træerne mere håndterbare i forbindelse med rendering, har jeg valgt ikke at generere
hvert eneste blad, men indsætte billboards af hele kviste:
Figur 102: Træer med billboards som løv.
Et af de vigtigste elementer i rendering af trækroner er skygge-effekten indbyrdes mellem bladene. I
Figur 102 ses, hvordan dette giver kronerne volumen.
For stammerne har jeg genereret teksturkoordinater, der gentager sig i et spejlende mønster langs
stammen og grenene:
109

Figur 103: Venstre: Teksturkoordinater langs stammen (rød = x-akse, grøn = y-akse). Højre: træ med tekstureret
stamme.
For at kunne tegne hele skove har jeg desuden brugt L-systemet til at modellere yderligere to
træsorter, et løvtræ og et nåletræ, med mere simpel geometri. Under mit arbejde, fandt jeg at
kileformede billboards var særdeles velegnede som kvist-modeller:
110

Figur 104: Mindre skov af tilfældigt genererede træer. Bemærk hvordan screen space ambient occlusion har en
flot effekt netop for træerne.
Jeg har endelig inkluderet en eksportfunktion, hvorved jeg kan visualisere træerne ved hjælp af f.eks.
blender:
111

Figur 105: Det endelige resultat for mine L-systems genererede træer, renderet i blender, med skygge og ”korrekt”
ambient occlusion.
6.2 Tage
For tagenes vedkommende har jeg især fokuseret på, at gøre metoden robust, hvorved den skal
kunne klare så varieret indputdata som muligt, uden at producere fejl. Først og fremmest vil jeg
demonstrere, at alle tagtyper, listet i Tabel 1, kan modelleres gennem min metode. I det følgende vil
112

jeg samtidig angive inputdata fra prototypen, hvorved det er muligt at genskabe resultaterne. I det
følgende vises derfor grundplanet for alle tagmodeller, hvor gavlene er markeret med orange.
Til at beskrive tagenes opstalter vil jeg benytte sæt-notationen der blev introduceret i afsnit 5.1.3.
6.2.1 Typiske tage
Først og fremmest vil jeg gennemgå de tage, der er nævnt i Tabel 1. Det har fra min side været et
eksplicit ønske, at netop disse tagtyper skal kunne modelleres ved brug af metoden.
6.2.1.1 Flad tag
Det flade tag er det klart simpleste af alle tage, men for min tagmodel kan dette ikke umiddelbart
modelleres. Det flade tag er netop ikke defineret ved en skelet struktur. Dog er det muligt at
konstruere et tilnærmelsesvist fladt tag, via 3 lodrette sider og en side med meget lav hældning. Her
er det værd at bemærke, at virkelige flade tage, også kun er tilnærmelsesvist flade, da vand ellers ikke
vil kunne løbe fra.
Gavl={0m, 90 o }
Side={0m, 0.00001 o }
Figur 106: Modellering af flad tag.
6.2.1.2 Saddeltag
Saddeltaget kan modelleres ved to gavle og to almindelige sider:
Gavl={0m, 90 o }
Side={0m, 45 o }
113

Figur 107: Modellering af saddeltag.
6.2.1.3 Valmet tag
Det valmede tag kan enten modelleres som et tag uden gavle, eller et tag med gavle, der har samme
hældning som resten af siderne:
Gavl={0m, 45 o }
Side={0m, 45 o }
Figur 108: Modellering af valmet tag.
6.2.1.4 Halvvalme
I det halvvalmede tag, udskiftes gavlene fra saddeltaget med halvvalmede gavle (inkluderet som
parametertype i prototypen):
Gavl={0m, 90 o , 2m, 45 o }
Side={0m, 45 o }
114

Figur 109: Modellering af halvvalmet tag.
6.2.1.5 Hollandsk gavl
Den hollandske gavl modelleres på samme måde som det halvvalmede tag, blot med omvendt
parameterrækkefølge i gavlene (det hældende segment kommer før det lodrette):
Gavl={0m, 45 o , 2.5m, 90 o }
Side={0m, 45 o }
Figur 110: Modellering af hollandsk gavl.
6.2.1.6 Pyramide
Pyramiden modelleres med et kvadratisk grundplan, der har uniformt hældende tagflader:
Side={0m, 45 o }
115

Figur 111: Modellering af pyramidetag.
6.2.1.7 Mansardtag
Mansardtaget modelleres i grundplanet som saddeltaget, men med mansardsider (inkluderet som
parametertype i prototypen):
Gavl={0m, 90 o }
Side={0m, 75 o , 2m, 45 o }
Figur 112: Modellering af mansardtag.
6.2.1.8 Pulttag
Pulttaget kan modelleres med tre lodrette gavle og én hældende gavl:
Gavl={0m, 90 o }
Side={0m, 45 o }
116

Figur 113: Modellering af pulttag.
6.2.1.9 Opskalk
Et tag med opskalk modelleres som et mansardtag, blot med omvendt parameterrækkefølge i
siderne.
Gavl={0m, 90 o }
Side={0m, 30 o , 0.5m, 45 o }
Figur 114: Modellering af tag med opskalk.
6.2.2 Kombinationer
Jeg har nu vist at metoden kan håndtere de mest almindelige tagtyper (angivet i Tabel 1), der for de
flestes vedkommende er bygget ind i prototypen ved en særlig opstalt. Metoden er dog først rigtigt
generisk, når det er muligt at kombinere forskellige tage. Her følger en række eksempler på
kombinationer af de ovenstående typer. Alle er de modellerede over det samme grundplan:
117

Figur 115: T-formet grundplan med 3 endegavle.
Gavl={0m, 90 o , 3m, 45 o }
Side={0m, 75 o , 2.5m, 45 o }
Figur 116: Mansardtag med halvvalm.
118

Gavl={0m, 45 o , 2m, 90 o }
Side={0m, 75 o , 2m, 45 o }
Figur 117: Mansardtag med hollandsk gavl.
Gavl={0m, 90 o , 3m, 45 o }
Side={0m, 30 o , 0.5m, 45 o }
Figur 118: Halvvalmet tag med opskalk.
119

Gavl={0m, 45 o }
Side={0m, 30 o , 0.5m, 45 o }
Figur 119: Valmet tag med opskalk i siderne.
6.2.3 Komplekse grundplaner
Den vigtigste egenskab ved tag-modelleringsmetoden er, at den kan tage alle former for input.
Derfor er den blevet testet grundigt, med meget varierede grundplaner.
Først og fremmest har det været et mål at bygge en modelleringsmetode, der kan håndtere parallelle
nabosider i grundplanet, som samtidigt har forskellige opstalter. Det følgende er et typisk eksempel
på brugen af denne effekt:
120

Figur 120: L-formet hus med halvvalmede gavle. Bemærk overgangen mellem gavl og tagside.
Ydermere er det vigtigt for anvendelsen af metoden, at den er i stand til at håndtere grundplaner, der
ikke falder under de regulære kategorier, såsom I-, L-, T- eller U-formede huse. De følgende huse vil
derfor alle være umulige at modellere med metoder, der gør brug af data for tagets topologi, mens
min metode klarer dem lige så let som alle andre tagtyper. Alle bygningerne er hver især eksempler
på tage, ingen andre metoder kan håndtere direkte:
Figur 121: Mansardtag med 6 halvvalmede gavle.
Figur 122: Tag med parallelle gavle, hvis kant i grundplanen indeholder reflekspunkt.
121

Figur 123: Tag med gavle der ender i hinandens reflekspunkter.
Figur 124: Tag med grundplan der indeholder udbygning. Siderne i udbygningen er alle halvvalmede gavle,
hvorved den fremstår som hævet i niveau.
122

Figur 125: Eksempel på bygning med parallelle lodrette gavle, der har omvendte normaler.
De foregående huse har alle været kasseformede, dvs. udelukkende med 90 o vinkler. For nogle huse
er dette ikke tilfældet. Metoden håndterer alle former for huse med arbitrære vinkler i grundplanet.
Følgende eksempel skal demonstrere metodens robusthed mod et stort antal ikke-vinkelrette kanter:
123

Figur 126: Bygning uden 90 o vinkler i grundplanen.
6.2.4 Robusthed
Indtil nu har vi hovedsageligt kigget på robusthed overfor forskellige typer grundplaner. Derudover
er det afgørende at metoden er robust mod varierende hældningsparametre.
Hvis vi igen betragter det L-formede hus med halvvalmede gavle:
124

Figur 127: Tag med halvvalmede gavle. Alle hældninger er 45 o .
I dette tilfælde er alle taghældninger 45 o . Hvis vi reducerer hældningen kun for tagfladen i valmen,
vil afstanden fra valmens toppunkt til sammenføjningen mellem lægerne blive mindre:
Figur 128: Tag med halvvalmet gavl. Taghældning er 45 o , og hældningen i valmen er 33 o .
125

Hvis vi reducerer hældningen yderligere vil valmens toppunkt og sammenføjningen på et tidspunkt
mødes:
Figur 129: Tag med halvvalmet gavl. Taghældningen er 45 o , og hældningen i valmen er 26,5 o .
Spørgsmålet er nu, hvad der sker når vi reducerer hældningen yderligere. Vil metoden bryde samme,
eller vil den forsøge at finde en eller anden form for løsning:
126

Figur 130: Tag med halvvalmet gavl. Taghældningen er 45 o , og hældningen i valmen er 20 o .
Som det fremgår bryder metoden ikke sammen, men foreslår en løsning. Forløbet i tagenden starter
med, at gavlen har en hældning, der er større end dens parallelle side. På et tidspunkt krydser
valmen sidens plan igen, og i det nye niveau har vi igen to parallelle kanter, men denne gang er
gavlens hældning lavere end sidens. Derfor indsættes en ny tagflade, der nu hælder ind i længen.
Det er klart at denne adfærd, kan være uforudseelig fra en brugers synspunkt. Pointen er at systemet,
trods alt ikke bryder ned. Dette kan være meget fordelagtigt, i de mange tilstande man må forudse
en designer eller en procedural algoritme forventes at udsætte systemet for, især hvis det anvendes
til modellering af hele bymiljøer med tusindvis af forskellige bygninger.
Robustheden kan observeres idet, geometrien i det ovenstående tilfælde er relativt kompleks, og det
er samtidigt langt fra blot et simpelt straight-skeleton.
6.2.5 Fri modellering
Indtil nu har vi for tagenes vedkommende udelukkende anvendt den parametriske model der er
anvendt i prototypen, og hvor modelløren udelukkende kan angive gavle og sider. Denne
fremgangsmåde er tiltænkt proceduralmodelleringsmetoder, og meget simple skitseringer af tage.
Den opmærksomme læser har muligvis lagt mærke til, at de foregående afbildninger af tage, alle har
inkluderet bygningens facader. Disse er i prototypen alle en del af selve opstalten i siderne. Metoden
kan således generaliseres til hele bygningen, og ikke blot taget.
Hvis vi ser bort fra forsimplingen, der indebærer begrænsning til blot to forskellige typer tagsider, er
det muligt at modellere mere varierede tagformer og bygninger. I den følgende test har jeg forsøgt at
modellere en kirke i sin helhed, ved brug af tre forskellige opstalter:
127

Figur 131: Opstaltsskiteser for kirke. Venstre: Opstalt for siderne i skibet. Midt: Opstalt for kirketårnet. Højre:
Opstalt for gavl i sideskibet.
Disse opstalter kan arrangeres på følgende grundplan:
Figur 132: Grundplanen for en kirke. Blå sider: Tårn. Gule sider: Skibets sider. Grå sider: Sideskibets galve.
Dette resulterer i følgende bygning:
128

Figur 133: Eksempel på modellering af en kirke indklusiv vægge og tårn, udelukkende ved brug af den lagdelte
tagmodel.
6.2.6 Begrænsninger
Metoden for tagmodellering har enkelte begrænsninger, der her vil blive belyst.
Det første problem vedrører den måde, hvorpå metoden håndterer valget af planer der skal
indsættes i tilfælde af parallelle kanter i grundplanet. Dette er baseret på et kvalificeret gæt, og i
nogle tilfælde er dette mindre hensigtsmæssigt:
129

Figur 134: L-formet hus med hollandske gavle.
I den ovenstående figur ses et l-formet hus, med hollandske gavle. I dette tilfælde er midtergavlen
nærmest kameraet meget bredere end de resterende gavle. Dette skyldes de to parallelle kanter i
grundplanet, der vil have ens hældning ved tagfoden. Derfor vil der mellem disse blive indsat et
lodret plan, hvorved gavlen ikke, som man måtte forvente, snævres ind mod den øverste del af taget.
En anden uhensigtsmæssighed opstår når to umiddelbare afsnit af et hus deler en fælles kant:
Figur 135: Saddeltag på to parallelle længer af et hus.
Et straigh skeleton har som sagt den egenskab, at uanset hvor på taget en regndråbe måtte lande, vil
den altid efterfølgende falde nedad, uden at samle sig i render der er parallelle med grundplanet eller
130

fordybninger, hvorfra der kun er opadgående flader. Der vil derfor aldrig kunne dannes en horisontal
kant mellem de to længer i Figur 135, og derfor ser vi den akavede forhøjning i midten af taget. Det er
klar at metoden ikke, uden hjælp kan skelne mellem situationen i Figur 135 og den i Figur 136, hvor
forhøjningen virker mere berettiget. Topologien for grundplanerne i de to situationer er netop ens.
Figur 136: Hus med saddeltag.
Forslag til løsning af disse problemer, vil blive skitseret i 7.3.
I dette afsnit har jeg gennemgået et meget begrænset udsnit af de forskellige typer tage, der kan
håndteres af metoden. På den medfølgende cd, er der en mere omfattende samling af billeder, der
demonstrere modellering flere tagtyper.
6.3 Modellering af bymiljøer
I løbet af dette projekt har jeg implementeret de væsentligste dele af CGA shape grammar som det er
præsenteret i [Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006]. Jeg vil i dette afsnit præsentere
eksempler på modellering med dette system, samt redegøre for hvordan indførelsen af min
parametriske tagmodel forbedrer dette system.
Jeg har ligesom for l-systemerne fulgt anvisningerne til CGA-sprogets syntaks, næsten nøjagtigt som
den er beskrevet i [Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006]. Dermed er det muligt at
beskrive bygninger i en tekstfil, og føde denne til systemet, der kompilerer den og genererer
bygningerne ud fra parametre, givet enten indirekte eller direkte gennem erklæringer i tekstfilen. I
dette afsnit vil jeg ikke anføre hele grammaer, men kun give eksempelbider. I bilag 2 medfølger alle
gammaerne diskuteret i dette afsnit, i deres fulde omfang.
131

6.3.1 Massemodellering
Modellering af bygninger i CGA starter med en regelbaseret beskrivelse af massemodellen. At
beskrive en bygnings sammensatte struktur via produktionsregler kræver en vis indsigt og øvelse (og
naturligvis en vis portion kreativitet). Derfor vil jeg her give eksempler på hvordan systemets store
udtryksfuldhed kan udnyttes.
Figur 137: Petronas tvillingetårnene i Kuala Lumpur i Malaysia. Et af verdens højeste bygningsværker.
Det første eksempel er en beskrivelse af Petronas Towers, der er et tvilling-højhusbyggeri i Malaysia,
og er blandt verdens højeste bygninger. Eksemplet er beskrevet i [Müller, 2006], og er her udtrykt
gennem i min implementering af systemet.
Hvis man betragter grundplanet for disse tårne, opdager vi en bemærkelsesværdig geometrisk
struktur:
132

Grundplanet består af to kvadrater, hvor det ene er roteret med 45 o i forhold til det andet. Ved alle
skæringer mellem kvadraterne er der indsat en cirkel. Dette grundplan er let beskrevet via simple
produktionsregler, og kan ekstruderes til et segment i Petronas tårnene. Herefter kan en rekursiv
proces bygge de overliggende og stadigt indsnævrede segmenter, der tilsammen udgør hele
bygningen. Resultatet ses her:
Figur 138: Petronas Towers modelleret via min implementering af CGA (renderet i blender).
Hvert af tårnene indeholder 140.000 polygoner og genereringen tog ca. 115 millisekunder. Da tårnene
er proceduralgenererede via produktionsregler, kan de reguleres af parametre. I dette tilfælde kan
modellen styres via højden og de indbyrdes proportioner og indsnævringer mellem sektionerne:
133

Figur 139: Variationer over Petronas Towers ved brug af tre forskellige parametre. (renderet i blender)
Bemærk at højden ikke blot er en skalering, men også har indflydelse antallet af etager, antallet af
sektioner og de indbyrdes proportioner imellem disse.
Det ovenstående eksempel demonstrerer variation opnået ved hjælp af parametre. For træer
genereret med L-systemer er det muligt også, at opnå strukturel variation (stokastiske L-systemr).
Strukturel variation kan også bygges ind i CGA-grammaer. I det følgende eksempel vil jeg give et
eksempel på modellering af en proceduralgenereret bygning, med en vis grad af stokastisk strukturel
variation.
I artiklen der introducerer CGA, er der særligt fokus på modellering af typiske moderne højhuse
(sandsynligvis pga. problemerne med modellering af tage i f.eks. villaer). I det følgende eksempel har
jeg taget udgangspunkt i Sears Tower, der er en skyskraber i Chicago:
134

Figur 140: Sears Tower i Chicago i USA.
Inspirationen til modelleringen har jeg fundet i følgende skitse over bygningens grundlæggende
arkitektur:
Figur 141: Skitse der beskriver grundplanen i Sears Tower i forskellige etagehøjder.
Som det fremgår, er bygningen inddelt i 9 kvadratiske søjler. Disse søjler har forskellige højder, men
generelt er hjørnesøjlerne lavere end de andre. Nu er spørgsmålet, hvordan beskrives dette forhold i
en CGA-grammar? Min idé er at inddele bygningen i en midtersøjle og parvist forbundene ydersøjler:
135

Figur 142: Inddeling af grundplanen i Sears Tower i søjler: 1 centersøjle (5), 4 hjørnesøjler (1, 3, 7 og 9) samt fire
sidesøjler (2, 4, 6 og 8). Sider og hjørner er forbundene parvis (1 – 4, 2 – 3, 7 – 8 og 6 – 9).
Vi kan nu vælge højderne af søjlerne stokastisk, og samtidig indføre en simpel begrænsning der
bestemmer, at en hjørnesøjle altid er kortere end dens tilknyttede sidesøjle. Dette giver følgende
resultat:
Figur 143: Sears Tower, modelleret via min implementering af CGA (renderet i blender).
Som det fremgår, kan sidesøjlerne være lige så høje eller lavere end midtersøjlen. Dette giver en
opadstræbende struktur med midtersøjlen som et naturligt topspir. Tårnet indeholder 627 polygoner
(facaden er i dette tilfælde blot tekstureret) og genereringen tager ca. 45 millisekunder. Udover
136

muligheden for parametrisk variation, er der for denne bygnings vedkommende også mulighed for
strukturel variation:
Figur 144: Parametriske og strukturelle variationer over Sears Tower (renderet i blender).
Bemærk hvordan søjlerne kan have indbyrdes forskellige højderelationer og, at forskellige sidesøjler
når hele vejen til toppen, samtidig med at bygningen beholder sin overordnede arkitektoniske
udformning.
6.3.2 Anvendelse af GIS data
For at kunne rendere hele bymiljøer er der behov for at kunne håndtere GIS-data, hvad end dette
måtte være data for eksisterende byer, syntetiseret data eller modelleret data. I forbindelse med min
prototype har jeg derfor bygget et simpelt system, hvori det er muligt for brugeren at importere et
kort, skitsere parcellerne og angive parametre til disse:
137

Figur 145: Skærm-dump fra GIS-applikation.
Herefter kan dette data trækkes ind i CGA-systemet der modellere en bygning for hver parcel med
udgangspunkt i de angivende parametre:
Figur 146: Bymiljø modelleret i CGA og visualiseret i min reder-engine.
138

De ovenstående bygninger er modelleret med samme fremgangsmåde, som den der præsenteres i
[Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006]. Grammaren består af kun 5 produktionsregler.
Processen starter ved at ekstrudere parcellen til en massiv figur. Parcellen kan være et arbitrært
polygon. Herefter underinddeles figuren, hvorved der kan skabes sidefløje og dermed I, L og U
formede bygninger.
6.3.3 Facademodellering
Det forrige eksempel er ikke videre tiltalende idet facaderne mangler. Til modelleringen af
højhusbyggerier har jeg 4 forskellige grundfacadetyper, der vælges stokastisk for hver bygning:
Figur 147: De 4 forskellige grundfacadetyper.
For hver af facaderne er der en række parametre der styrer facadens udformning. Det følgende
eksempel viser effekten ændring af vinduesbredde og mellemrummet mellem vinduer for den
samme grundtype:
Figur 148: Samme grundfacade med forskellige vinduesbredder.
Som det fremgår virker facaderne væsentligt forskellige, til trods for at de grundlæggende er ens. Ved
at vælge facadetypen stokastisk, samtidig med at vi også vælger facadeparametrene stokastisk, er det
muligt at opnå en meget høj grad af variation i bymiljøet. Hundredvis af bygninger kan genereres
uden, at byen virker ensformig. Denne variation ville ikke være mulig uden kombinationen af
parametre og udvalget af facader. De følgende billeder viser byen i Figur 146, men denne gang med
stokastiske facader:
139

Figur 149: Proceduralmodelleret bymiljø. (renderet i blender)
140

Figur 150: Proceduralmodelleret bymiljø. (renderet i blender)
Byen indeholder over 855.000 polygoner og genereringen tog ca. 8 sekunder. Tagene har typiske
moderne installationer der er formet af bygningens øverste polygoner, der er indsnævrede ved en
indsnævrings funktion og efterfølgende ekstruderet til en stokastisk valgt højde. I det følgende
billede kan detaljegraden observeres fra gadeplan:
141

Figur 151: Proceduralmodelleret bymiljø, set fra gadeplan. (rederet i blender)
I det ovenstående tilfælde er GIS-dataen tegnet ovenpå et eksisterende vejnet fra det centrale San
Francisco. Det er naturligvis også muligt at benytte ikke-eksisterende eller syntetiserede vejnet, og i
det følgende eksempel har jeg f.eks. anvendt DTU’s logo som udgangspunkt:
142

Figur 152: Gis data, tegnet med udgangspunkt i DTU's logo.
143

Figur 153: Bymodel genereret over DTU's logo.
Scenen indeholder ca. 1 million polygoner, og genereringen tog omkrng 15 sekunder.
I min implementering mangler jeg at tage højde for occlusion samtidig med, at jeg ikke kan foretage
snapping til betydende linjer i bygningens struktur [Müller, Wonka, Haegler, Ulmer, & Van Gool,
2006] (se også side 61). I de ovenstående billeder er dette problem knapt synligt, og da der her blot er
tale om en prototype, påvirker det efter min mening ikke indtrykket af systemets overordnede
potentiale.
I de næste eksempler vil jeg gå mere i dybden med detaljeringen af de enkelte elementer i facaden.
6.3.4 Den lagdelte tagmodel i CGA
Mit hovedbidrag til metoden er indførelsen af den parametriske lagdelte tagmodel i CGA shapegrammar.
Jeg vil nu præsentere resultaterne for dette arbejde.
For højhusbyggerier er de parametriske tage sjældent relevante, men for enfamiliehuse er tagene
altafgørende. Jeg har derfor valgt at bygge en grammar for en typisk større villa eller palæ. I dette
tilfælde er husene altid enten 1 eller 2 etager, og består af et større centerstykke, hvorfra der er
mulighed for mindre længer i hvert hjørne. Jeg har forsøgt, at inkorporere en større grad af
detaljering i facadernes arkitektur, hvilket indkluderer: hjørnesøjler, sokkel, gesims,
dannebrogsvinduer, trappe for døren, altan og vindue over døren. For alle detaljers vedkommende
gælder det, at de er en del af grammaren og dermed parametriske:
144

Figur 154: Proceduralmodelleret villa. (rederet i blender)
Huset indeholder ca. 20.000 polygoner, genereringen tog 470 millisekunder og grammaren
indeholder 33 produktionsregler og kan findes i fuld udgave i bilag 2.
I grammaren vælges der stokastisk mellem 5 forskellige tage: Mansardtag med 80 og 20 graders
hældning (øvre og nedre), saddeltag med stokastisk hældning mellem 10 og 50 grader, valmet tag
med 30 graders hældning, valmet tag med 40 graders hældning og til sidst 1 /3-valm i 45 grader.
Dette opnås ved følgende stokastiske produktionsregel:
p31: roofTier -> Roof("roofEdge", "mansard", 80, 30, 2, "halfHip", 2, 45)
{roof | gable} : 0.25;
p31: roofTier -> Roof("roofEdge", "sloped", rSlope, "gable")
{roof | gable} : 0.25;
p31: roofTier -> Roof("roofEdge", "sloped", 30, "hip", 30)
{roof | gable} : 0.125;
p31: roofTier -> Roof("roofEdge", "sloped", 40, "hip", 40)
{roof | gable} : 0.125;
p31: roofTier -> Roof("roofEdge", "sloped", 45, "halfHip", *0.66, 45)
{roof | gable} : 0.25;
Hvert af tilfældende vælges med hhv. 25%, 25%, 12,5%, 12,5% og 25% chance. Bemærk hvordan den
sidste tagtype opnår en proportionel valm ved at benytte relativ syntaksen (’*’), kendt fra splitmakroen.
145

Her følger et udvalg af nogle af de forskellige hustyper der er mulige med grammaren:
Figur 155: Udvalg af proceduralgenererede villaer. (renderet i blender)
Det er muligt at bringe husene ind i deres rette omgivelser ved at benytte de træer jeg har genereret
via L-systemerne:
Figur 156: Villahus med omgivende have (rederet i blender).
146

I det ovenstående billede er huset og træerne proceduralmodellerede, mens vejene, verandaen,
stakittet og havens komposition er modelleret manuelt.
En vigtig observation for tagenes vedkommende er, at de medvirker til at øge variationen imellem
husene. For kontorbygningernes vedkommende måtte jeg modellere 4 forskellige facadetyper, og
variere disse med stokastiske parametre. For villaerne kan jeg blot skifte tagtyper, og husene får et
markant anderledes arkitektonisk præg. Det følgende eksempel skal illustrere variationen i den
samme grammar, men med stokastisk valgte tagtyper, og varierende facadematerialer. Alle andre
parametre er ens (f.eks. vinduesbredde, vindueshøjde og etagehøjder):
Figur 157: Variation i tage medvirker til overordnet variation i billedet (renderet i blender).
Medvirken til øget mulighed for variation er en af de helt store fordele ved en metode, der kan
håndtere mere end blot valmet tag og saddeltag. Hver af scenerne ovenfor indeholder mellem 70 og
80 tusinde polygoner.
Til trods for den høje detaljegrad forventer jeg ikke, at en grafiker vil være fuldt tilfreds med
resultatet i alle tilfælde. Derfor er det afgørende, at der er mulighed for efterfølgende at forskønne
147

modellen i et traditionelt modelleringsværktøj. I det følgende eksempel har jeg selv forsøgt mig som
modellør:
Figur 158: Proceduralmodelleret bygning, der efterfølgende er redigeret i blender (også renderet i blender).
Her har jeg, udover modellering af haven, indsat potteplanter, møbler og en skorsten med røg. Vasen
og bænken er fra turbosquid 3 . Derudover har jeg givet taget en tekstur samt et normal-map, hvis
position er baserede på uv-koordinater beregnet i min implementering af CGA.
Jeg vil til slut oplyse om en kendt fejl i systemet. Fejlen opstår når en bygnings grundplan bringes fra
CGA-systemet over i tagmodelleringssystemet. I min implementering af CGA arbejder jeg i 32-bits
præcision, mens jeg arbejder i 64-bits præcision under tagmodelleringen. Denne lavere præcision
kan i nogle tilfælde føre til fejlagtigt konstruerede tage. Problemet kan og bør løses ved at anvende
64-bits præcision gennem hele systemet.
3 http://www.turbosquid.com/
148

7 Diskussion
I dette afsnit vil jeg gennemgå mine resultater og diskutere deres betydning og perspektiver.
7.1 Overblik
Jeg har i dette projekt implementeret et system der kan parse og evaluere CGA-shape-grammaer. Mit
bidrag har først og fremmest været en model for fleksibel modellering af tage. Metoden tager
udgangspunkt i et straight skeleton for bygningens grundplan, og bygger en model ved at klippe
tagfladernes polygoner indbyrdes. Hver tagflade lagdeles, hvilket muliggør meget varierede tagtyper.
Metoden kan parametriseres ud fra en simplificeret betragtning over de mest almindelige tagtyper,
ved at antage at taget er bygget op af gavle og tagsider. Dermed har jeg været i stand til at indføre
tagene i CGA, i en simpel og koncis syntaks.
Det har været af afgørende vigtighed for mig, at det, for både L-systemer og CGA-grammaer, er
muligt for brugeren at benytte sig af en notation der er meget lig den der er givet i hhv.
[Lindenmayer & Prusinkiewicz, 1996] og [Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006]. Jeg har
set eksempler på systemer hvor grammarene skrives direkte i almindelige programmeringssprog eller
i XML-filer. Det er selvfølgelig implementeringsmæssigt nemmere, men det besværliggør brugen af
systemet, og gør udforskningen og afprøvning af systemernes muligheder langsommelig og
vanskelig.
I mine systemer har man en klar og koncis syntaks, der gør arbejdet med grammaerne meget mere
intuitiv og ligetil. Hvis man har arbejdet med grammaer tidligere, vil man have let ved at tage disse
systemer i anvendelse. For en brugers synspunkt er det en fordel, at kunne udtrykke sig direkte i
grammaren og ikke indirekte gennem andre ubeslægtede programmeringssprog.
Et vigtigt formål med dette projekt har været at finde en metode der er i stand til at modellere de
mest almindelige tage. Specifikt har det været et mål at modellere tagene nævnt i Tabel 1. Med
henvisning til resultatafsnittet mener jeg, at man med rimelighed kan sige at dette mål er nået. Jeg
vil, igen med reference til resultatafsnittet, ydermere argumentere for, at metoden går videre end
dette, da den er yderst fleksibel og frem for alt generisk i forhold til inputparametre. Man kan altså
føde et arbitrært grundplan til algoritmen, og få systemets kvalificerede gæt på hvordan en given
tagtype vil være udformet.
I afsnit 4 (Observationer, analyse og hypotese) gav jeg en grundig diskussion af den eksisterende
litteratur og de eksisterende metoder. Konklusionen var, at systemer baseret på shape-grammaer er
klart overlegene. I forhold til de andre metoder er shape-grammaer og især CGA-grammaren mere
strukturerede når det gælder definering af bygningers ensartede konstruktion og deres indbyrdes
sammenlignelighed, hvilket jeg vil tilskrive metodens arkitektoniske ophav. Jeg forudser, at shapegrammaer
på sigt vil blive anvendt til modellering af bygninger, i samme omfang som f.eks. Lsystemer
i dag bliver anvendt til modellering af planter og træer.
Modelleringen af kirken der blev gennemgået i resultatafsnittet (side 129) viser metodens
fleksibilitet, og samtidig også i høj grad dens robusthed. Umiddelbart kunne man forledes til at tro,
at tagmodelleringsmetoden dermed kan benyttes til generel modellering af bygninger (altså ikke
bare tage). Dette må dog frarådes, da det for langt de færreste bygninger ikke er en triviel opgave at
149

specificere det overordnede udseende, udelukkende ud fra grundplanet. Empire State Building i New
York har f.eks. et kvadratisk grundplan, hvorfra det er umuligt at beskrive alle detaljer for hele
bygningens struktur. Det ovenstående eksempel på modellering af en kirke skal udelukkende tjene
som bevis for metodens alsidighed.
Når man vurderer den visuelle fremtoning af mine resultater, må man tage i betragtning, at jeg ikke
er grafiker eller modellør. Når det er sagt, vil jeg gerne fremhæve netop den side af systemet. CGAsystemets
evne til modellering af detaljerede facader, beskrivelse af vigtige overordnede design mål
og proportionering af facadeelementer er uovertruffen.
I eksemplet med modellering af et bymiljø, på baggrund af DTU’s logo, blev der skabt en model med
over 1 million polygoner. Man kan diskutere om detaljegraden, i dette tilfælde 1 million polygoner for
et helt bymiljø, lever op til dagens krav til computergrafiske scener. Jeg er på ingen måde grafiker, og
mine evner for modelleringsopgaver er således begrænsede. Derfor vil jeg argumentere for, at
systemet i hænderne på en grafiker vil kunne præstere meget bedre resultater. Systemet gør netop
ikke en amatør til grafiker, men hjælper grafikeren til højere produktivitet. I den forbindelse vil jeg
henvise til hjemmesiden for City Engine 4 , der præsenterer overordentligt flotte resultater med et
system magen til dette.
En anden grund til den forholdsvis begrænsede detaljegrad er, at jeg har undladt at implementere en
importfunktion i mit system. Nogle opgaver, f.eks. vinduer, egner sig bedre til traditionelle
modelleringsværktøjer. Hvis det var muligt at importere højdetaljerede vinduesmodeller direkte ind i
grammaren, der herefter kunne placere disse på facaden, ville en meget høj detaljeringsgrad lettere
kunne opnås.
4 http://www.procedural.com
150

Figur 159: Villa modelleret med CGA-shape-grammar.
Jeg har fået en række positive kommentarer fra kollegaer og grafikere i forbindelse med mit arbejde.
Især grafikerne er dog bekymrede over den noget statisk udseende scene for højhusene. Jeg vil i
nogen grad give dem ret, og det er klart at resultatet ikke kan anvendes direkte i en eventuel
produktion. Dertil er kvaliteten for lav. Pointen er igen, at jeg ikke er modellør eller grafiker, og i
hænderne på en dygtig modellør er jeg overbevist om, at resultaterne kan forbedres drastisk.
Derudover er der intet i vejen for, at bruge modellen som udgangspunkt for videre arbejde i et
modelleringssystem. Noget så simpelt som variation af f.eks. facadefarven for de forskellige
bygninger vil formodentlig gøre underværker, og samtidig fjerne noget af det statiske præg over
scenen.
Jeg har i dette projekt ikke foretaget undersøgelser af metodens effektivitet som grafisk værktøj. En
sådan test ville indebære oplæring af en grafiker, og derefter analyse af dennes arbejde med
metoden. Her vil jeg referere til en lignende undersøgelse i [Müller, Wonka, Haegler, Ulmer, & Van
Gool, 2006]. Jeg vil dog bemærke, at det har været muligt for undertegnede at producere forholdsvis
komplekse, og efter min mening rimeligt overbevisende modeller. Modeller, der pga. deres omfang
og detaljeringsgrad, ville være umulige for mig at producere inden for en fornuftig tidsramme med
almindelige modelleringsværktøjer. Samtidig vil jeg hævde, at det faktum, at kun 4 forskellige
grundfacadetyper, var tilstrækkeligt til at opnå et forholdsvis varieret bymiljø, peger på en høj
effektivitet.
151

En vigtig pointe i forbindelse med proceduralmodellering er evnen til at skabe variation i scenen.
Igennem denne rapport har jeg argumenteret for at tage har stor indflydelse på en bygnings
overordnede arkitektoniske udtryk. Dette er selvfølgelig en subjektiv vurdering, men jeg mener, at
jeg med baggrund i resultaterne præsenteret i afsnit 6.3.4 kan begrunde denne påstand.
Konklusionen må derfor være, at indførelsen af parametriske tage har givet bedre muligheder for
variation af bygningerne, hvilket er et uvurderligt værktøj for grafikere.
I min parametriske tagmodel har jeg valgt at arbejde med to forskellige sidetyper: gavl og almindelig
side. Dette valg har været baseret på den naturlige analogi til den almindelige differentiering mellem
gavle og sider. Det er lettere for uøvede, at forholde sig til hvordan netop taget og gavlene er
udformet, i stedet for et urelateret antal sidetyper deriblandt gavlen. Problemet er, at dette er en
begrænsning af udtryksfuldheden for tagmodellen. Det er klart at brugeren ikke bør tage stilling til
alle tagfladerne individuelt, men det bør overvejes om tallet 2 er det mest optimale antal. I eksemplet
med kirken demonstrerede jeg hvordan det er muligt at modellere meget avancerede tagtyper, ved
brug af 3 forskellige opstalter. Efterhånden som jeg har fået mere erfaring med systemet hælder jeg
til at tallet 3 nok er mere passende.
Dette projekt dækker bredt, og den samlede mængde af kildekode er derfor tilsvarende omfattende.
Især implementeringen af CGA-systemet har indebåret en betydelig arbejdsindsats. Dette skyldes i
nogen grad systemets karakter og spændvidde, men det peger samtidigt også på teknologiens
modenhed. Dette afspejles således i det faktum, at industrien har taget den kommercielle
implementering af CityEngine i brug.
7.2 Anvendelsesmuligheder
For at kunne bedømme anvendelsesmulighederne af min metode, må man se den i sammenhæng
med CGA systemet. Mit bidrag skal i den forbindelse anskues som en enkel men vigtig forbedring af
den allerede eksisterende metode.
7.2.1 Brugerscenarie
Den primære brugergruppe for proceduralmodellering af bygninger, er grafikere.
Grafikeren starter med at modellere vinduer, døre og andre detaljeobjekter i almindelige
modelleringsværktøjer. Her er der tale om en afvejning mellem, hvorvidt man ønsker
parameteriserede eller blot skalerbare detaljer. I nogle situationer er det måske ønskeligt, at
modellere f.eks. vinduer i selve grammaren hvorved bl.a. antallet af vinduesfag kan gøres afhængig af
vinduets bredde. I andre situationer, hvor man f.eks. ved at vinduerne alle har samme størrelse, kan
man benytte modelleringsværktøjer og dermed opnå detaljer der ikke er mulige gennem grammaer.
Modelløren kan nu skrive grammaer for det antal forskellige arketyper af bygninger, han måtte finde
passende. Processen består i at modellere bygningens form, beklæde den med facader og til sidst
vælge tagformen. Herefter angives hvilke parametre der skal være genstand for tilfældighed, samt
udfaldsrummet for disse. Her er det nødvendigt at være påpasselig, så man ikke risikerer
uhensigtsmæssigheder i grænsetilfælde. Selve modelleringsprocessen involverer opsætning af regler
for bygningens udformning, hvilket igen bygger på en analyse af bygningens design.
152

Efterfølgende designes et vejnet sammen med GIS-data for de enkelte matrikler, og parametre for de
enkelte bygninger angives. Dette fødes til systemet, der genererer modellen. Denne model kan til
sidst hentes ind i et modelleringsværktøj, og forfines i mere eller mindre grad via traditionelle
metoder.
Jeg har indtil nu ikke diskuteret hvordan kviste og tagvinduer håndteres i systemet. Det er generelt
ikke muligt at beskrive kviste ud fra husets grundplan. Som sagt eksisterer tagfladerne i grammaren
efter tagets konstruktion, og det er derfor muligt at arbejde videre med tagfladen på samme måde
som med alle andre facader. Derfor må kviste betragtes som komponenter i tagfladen, meget lig
måden vinduer i håndteres i facader.
7.2.2 Perspektiv
Som sagt forventer jeg at proceduralmodellering af bymiljøer vil spille en stor rolle i industrien
fremover. Der findes allerede en kommerciel implementering af CGA (City Engine 5 ), der især finder
anvendelse i spilindustrien. For mange computerspil spiller byen en meget vigtig rolle, og det er
forbundet med store omkostninger for spiludviklere at realisere disse byer.
I baggrundsafsnittet belyste jeg hvordan udviklingen i omkostninger for udvikling af visuelt indhold,
spiller en stadigt større rolle i budgetterne for computerspil. Derfor er produkter såsom det
ovennævnte attraktive. Man kan betragte det som et mere effektivt værktøj til produktion af
bymodeller set i forhold til traditionelle modelleringsværktøjer. Det er på den måde muligt at
mindske omkostningerne for udvikling af spil, eller hæve detaljegraden i bymodellen yderligere. Jeg
vil mene at uanset spilindustriens økonomiske tilstand, vil det altid være oplagt for producenter at
foretage effektiviseringer i arbejdsgangene.
På længere sigt kan man forestille sig proceduralmodellering af bymiljøer anvendt til stokastisk
generering af spil-verdner. Dette kan være som del af uendeligt store miljøer, eller som
udgangspunkt for et element af opdagelse i ukendte verdner der forlænger spiloplevelsen hos
slutbrugeren. Der kan på samme måde også være tale om proceduralmodellering som et egentligt
gameplay-element, som det er set i spillet spore fra EA-games. I den forbindelse kan man f.eks.
forestille sig systemet anvendt i en SimCity lignende simulator. Her kan proceduralmodellering
hjælpe med til, at undgå nøjagtigt ens bygninger der indsættes flere steder i samme by, eller afhjælpe
begrænsninger der kun giver mulighed for retvinklede parceller.
Udover spilindustrien kan man forestille sig, at filmindustrien vil kunne få gavn af metoden. Her er
kvalitetskravene noget højere, og teknologien skal sandsynligvis forbedres og modnes før man for
alvor vil se metoden blive taget i anvendelse.
Jeg forestiller mig også at byggebranchen og bygningsadministratorer vil kunne anvende værktøjer
der er baserede på metoden. Her tænker jeg især på visualisering af GIS-data. Hvis man f.eks. vil
vurdere en projekteret bygnings visuelle indvirkning på omgivelserne, bruger man ofte
computergererede bymiljøer. Her er der for det meste tale om geometri, der er ekstruderet direkte
fra GIS-data. I nogle tilfælde er facaderne beklædt med facadetekstur.
5 http://www.procedural.com/
153

Figur 160: Visualisering af GIS-data fra Århus. Bemærk hvordan nogle facader er beklædt med tekstur, mens
andre er “nøgne”.
Arbejdet med at indsamle facade-fotos, og rette dem til på figuren kan være omfattende, især hvis
der lægges vægt på kvaliteten. I mange tilfælde vil man med fordel kunne benytte
proceduralgenererede facader på disse bygninger. Her kunne man bygge et sæt af typiske
facadetyper, der passer i de konkrete omgivelser, og anvende disse på de enkelte bygninger. Det vil
naturligvis ikke blive en nøjagtig gengivelse, men for en stor del af bygningsmassen, vil det ikke
spille en afgørende rolle.
7.2.3 Anvendelse af tagmodellen
For selve tagmodellen er der udsigt til en mulig snarlig anvendelse i systemer til beregning af
varmetabet for bygninger. Her er brugergruppen helt almindelige privatpersoner, og der lægges
således vægt på brugervenlighed. Man kan derfor ikke forvente at folk skal modellere deres hjem i 3d
via de sædvanlige modelleringsmetoder, og det er netop i den forbindelse at tagmodellen bliver
relevant.
Ideen er at brugeren først indtaster sin adresse. Herefter kan vi slå bygningen op i Kort og
Matrikelstyrelsens database, hvorfra det er muligt at hente grundplanet som geometrisk polygon.
Det er samtidig muligt at finde information om højden og antallet af etager i bygningen, og det er
derfor ligetil at ekstrudere bygningen og få dens massemodel. Herefter bliver brugeren præsenteret
for en række tagtyper. Brugeren vælger den der passer bedst, og angiver tagets parametre (såsom
hældninger). Det eneste der mangler er at brugeren angiver materialetype og indsætter vinduer og
døre. Herefter har man en komplet klimaskærm, hvormed systemet kan fortage varmeberegninger
og give anbefalinger.
Uden en generisk tagmodel har man ikke mulighed for at anvende bygninger fra en GIS-database, da
disse kan have alle slags ukurante former.
154

7.2.4 Proceduralgenerering
Anvendelsen af proceduralgenerering i industrien bliver stadig mere udbredt. Ikke bare træer og
huse, men også f.eks. animationer, personer, ansigter eller ansigtsmimik. Generelt kan man sige, at
proceduralgenerering kan anvendes på alle områder, hvor de individuelle modeller deler
overordnede træk med hinanden. Træk der kan kodificeres i enten implicitte eller eksplicitte regler.
Den urolige grafiker vil måske spørge sig selv: ”bliver jeg nu erstattet af maskiner?”. Hertil er svaret
klart nej. Det er stadig grafikeren der har den overordnede vision for det grafiske udtryk.
Proceduralmodellering er blot et værktøj for grafikeren, hvormed denne kan udtrykke sin vision.
Man kan måske også spørge, vil højere effektivitet føre til fyringer blandt grafikere? Er ingeniørerne
ude på at gøre grafikerne arbejdsløse? I dette tilfælde er svaret selvfølgelig op til de ledende
spiludviklere, men spilmarkedet er i den grad et konkurrencepræget marked, og der bliver især
konkurreret på imponerende grafik. Derfor vil frigjorte ressourcer sandsynligvis blive anvendt andre
steder i produktionen af det grafiske indhold, eller måske på en større mangfoldighed af udgivelser.
7.3 Fremtidigt arbejde
Den foreløbige implementering er blot en prototype. Især brugerfladen er præget af at være en
testbænk for selve udviklingen. Derudover mangler jeg en at implementere en række funktioner fra
CGA, heriblandt occlusion-forespørgsler og indsættelse snapping-linjer (hhv. fjernelse af usynlige
facadeelementer og indsættelse af snapping-linjer, der kan insereres af andre regler (se side 61)). Jeg
har måttet udelade disse dele, da jeg har prioriteret implementeringen af min egen metode i
systemet. Arbejdet i [Müller, Wonka, Haegler, Ulmer, & Van Gool, 2006] og implementeringen i
CityEngine er resultatet af flere års arbejde i forskningsgrupper og i kommercielt øjemed.
Virksomheden bag har fuldtidsudviklere, der arbejder på at forfine systemet. Dette kan jeg ikke
umiddelbart hamle op med, og derfor har jeg valgt, kun at implementere de mest basale funktioner i
systemet. Prototypen skal således blot muliggøre min implementering af tagmodelleringsmetoden,
og demonstrere hvordan denne kan anvendes.
Hvis dette system skal bringes i anvendelse er det nødvendigt med en grafisk brugerflade. Til trods
for at jeg benytter mig af en grammar syntaks, kan man ikke forvente at ikke-programmeringskyndige
vil kunne gøre brug af dette. Man kan groft sagt sige at der er tale om et slags scriptingsprog,
og indlæringskurven er i det perspektiv lig alle andre scripting-sprog [Müller, Wonka,
Haegler, Ulmer, & Van Gool, 2006]. Derfor er det nødvendigt med en visuel editering af grammaer.
Her er det oplagt at skele til arbejdet i [Lipp, Wonka, & Wimmer, 2008].
En oplagt kandidat til forbedring af systemet er, at kigge på måden gavle vælges. I alle de
brugerscenarier jeg kan forestille mig, ville det være en fordel hvis systemet selv kunne foreslå
placeringen af gavle. En idé er, at vælge alle flader der i et straight-skeleton er opstået som følge af en
edge-event. Disse flader vil altid være trekantssammenføjninger. Problemet er, at f.eks. en simpel Lformet
bygning kun vil have to gavle, mens man ville forvente at denne har 3 gavle. Jeg foreslår i
stedet en fremgangsmåde der er meget lig den beskrevet i [Laycock & Day, 2003]. Her findes alle
kanter der udgør en rygning i tagmodellen. Disse benyttes som udgangspunkt for at finde en region,
hvor alle kanter i grundplanet der er mere elle mindre vinkelret på rygningen angives som gavle.
155

Et problem der blev identificeret i resultatafsnittet (6.2.6), omhandler hvordan indsættelse af
hjælpeplaner håndteres. I min implementering har jeg opsat 3 forskellige kriterier for valg af
hjælpeplan. Som udgangspunkt er der intet i vejen for at indføre flere kriterier. I den konkrete
problemstilling kan en løsning være at foretage en mere global søgning i grundplanet, hvorved man
vil opdage andre kanter der eventuelt skærer punktet, og hvorfra det nye hjælpeplan kan deduceres.
Arbejdet med stokastiske systemer kan i nogle tilfælde skabe problemer, da man har svært ved at
genskabe specifikke modeller. Derfor bør det være muligt for en designer at låse visse af de
stokastiske parametre igennem arbejdsprocessen. Dette underbygger en arbejdsproces hvori det er
muligt at prøve sig frem med forskellige designs.
156

8 Konklusion
I dette projekt er der blevet implementeret en metode til proceduralmodellering af bygninger og
bymiljøer. Metoden er baseret på de såkaldte shape-grammaer, og giver mulighed for modellering af
huses massemodel, deres facader og deres tage. Metoden kan tage en simpel form for GIS-data,
hvorved hele bymiljøer kan modelleres.
Mit bidrag er en metode til modellering af tage, der baserer sig på polygoners straight-skeleton.
Metoden tager som input et sæt af opstalter, der beskriver tagets enkelte sider, og benytter husets
grundplan til at opbygge en lagdelt tagmodel. Metoden kan anvendes i sig selv, eller bruges i
forbindelse med proceduralmodellering via shape-grammaer. Dertil har jeg udviklet en shapegrammar
syntaks, hvori det er muligt at beskrive det ønskede tag.
Igennem denne rapport har jeg redegjort for at tage er en betydelig del af en bygnings arkitektoniske
fremtoning og dens klimaskærm. Tage er altså vigtige, og hidtidige metoder til
proceduralmodellering har været utilfredsstillende. Jeg mener derfor, at min metode er relevant og
betydningsfuld. Modellering af tage har efter min mening været et egentligt problem for de
eksisterende systemer.
I resultatafsnittet har jeg redegjort for, at metoden er robust og fleksibel. Det er muligt at modellere
et stort udvalg af varierende tagtyper. Oven på den fleksible tagmodelleringsmetode har jeg bygget
en forsimplet parametermodel der indskrænker udtryksfuldheden, men samtidig gør metoden
simplere at arbejde med. Dette er afgørende for anvendeligheden i forbindelse med
proceduralmodellering. Den forsimplede parametermodel medvirker desuden til, at gøre systemet
lettere tilgængelig for brugere, hvilket bevirker at selve tagmodelleringsmetoden har en bredere vifte
af anvendelsesmuligheder, hvilket jeg har belyst i diskussionsafsnittet.
Jeg vil i denne forbindelse særligt fremhæve tagmodelleringmetodens robusthed og fleksibilitet.
Hvis systemet skal bringes i anvendelse af en bredere brugerskare, forligger der en del arbejde. Først
og fremmest skal systemet bringes fra en tilstand af prototype til et produktionsklart system.
Derefter skal en række centrale elementer fra CGA, der indledningsvist er blevet udeladt,
implementeres, og på længere sigt bør systemet give mulighed for visuel editering af regler.
157

9 Bibliografi
Bemærk at de fleste artikler i denne oversigt kan findes i pdf-format på den medfølgende CD, eller på
adressen: http://www.student.dtu.dk/~s042624/eksamensprojekt/Papers/.
1) Aberinkulas. (3. 8 2009). The Fall and Rise of Game Development Costs. Hentede 19. 2 2010 fra
Gamespot: http://www.gamespot.com/users/Aberinkulas/show_blog_entry.php?topic_id=m-
100-25709882
2) Aichholzer, O., & Aurenhammer, F. (1996). Straight skeleton for General Polygonal Figures in
the Plane.
3) Aichholzer, O., Aurernhammer, F., Alberts, D., & Gärtner, B. (28. 12 1995). A Novel Type of
Skeleton for polygons. Journal of Universal Computer Science vol 1, no. 12 , s. 752-761.
4) Akenine-Möller, T., Haines, E., & Hoffmann, N. (2008). Real-Time Rendering, Third Edition.
Wellesley Massachusetts: A K Peters, Ltd.
5) Andreovich, M. (30. 4 2008). gameindustry.biz. Hentede 19. 2 2010 fra GTA IV: Most
expensive game ever developed?: http://www.gamesindustry.biz/articles/gta-iv-mostexpensive-game-ever-developed
6) Bélanger, D. (2000). Hentede 9. 2 2010 fra Designing Roofs of Buildings:
http://www.sable.mcgill.ca/~dbelan2/roofs/roofs.html#ss
7) bobvila. (2010). Roof Terms and Terminology. Hentede 5. 2 2010 fra bobvila.com:
http://www.bobvila.com/HowTo_Library/Roof_Terms_and_Terminology-Miscellaneous-
A1936.html
8) Bourke, P. (1 2000). Perlin Noise And Turbulence. Hentede 17. 2 2010 fra
http://local.wasp.uwa.edu.au/~pbourke/texture_colour/perlin/
9) Brenner, C. (2000). Towards fully automatic generation of city models. IAPRS, Vol XXXIII,
Amsterdam , s. 85-92.
10) Bærentzen, J. A., Anton, F., Gravesen, J., & Aanæs, H. (2006). Computational Geometry
Processing. Lyngby: Danmarks Tekniske Universitet (DTU).
11) Chen, G., Esch, G., Wonka, P., Müller, P., & Zhang, E. (2008). Interactive Procedural Street
Modeling. Proceedings of SIGGRAPH 2008.
12) Cohn, D. (2. 7 2008). New NVIDIA Quadro FX Series Workstation Graphics Cards Deliver HPC
for Less. Hentede 13. 2 2010 fra Desktop Engineering:
http://www.deskeng.com/articles/aaajxm.htm
13) Crenshaw, J. W. (31. 8 1988). Let's build a compiler! Hentede 21. 4 2010 fra Compilers:
http://compilers.iecc.com/crenshaw/tutor6.txt
158

14) denstoredanske. (02. 02 2009). Den store danske encyklopædi. Hentede 9. 2 2010 fra skalk:
http://www.denstoredanske.dk/Kunst_og_kultur/Arkitektur/Bygningsdele/skalk
15) Finkenzeller, D., & Schmitt, A. (2006). Rapid modeling of complex building façades. Institut
für Betriebs- und Dialogsysteme, Universität Karlsruhe (TH), Germany.
16) Forrest, A. (2003). Future trends in computer graphics: how much is enought? Journal of
Computer Sceience and Technology , s. 531-537.
17) Greuter, S., & Parker, J. (2003). Real-time procedural Generation of 'Pseudo Infinite' Cities.
Graphite 2003, (s. 87-ff). RMIT University, Melbourne, Australien.
18) Greuter, S., & Stewart, N. (2004). Beyond the horizon: Computer-generated, Threedimensional,
Infinite Virtual Worlds without Repetition in Real-time. Image Text and Sound
Conference. RMIT University, Melbourne, Australien.
19) Hanrahan, P. (2005). Why is graphics hardware so fast? Proceedings of the tenth ACM
SIGPLAN symposium on Principles and practice of parallel programming (s. 1-1). Chicago, IL,
USA: ACM.
20) Havermann, S. (2005). Generative Mesh Modeling. Braunschweig: Technischen Universität,
Braunschweig.
21) husrådgivning. (2010). husrådgivning.dk. Hentede 5. 2 2010 fra
http://www.husrådgivning.dk/?download=Det%20hedder%20husets%20dele.pdf
22) Kelly, G., & McCabe, H. (2007). Citygen: An interactive System for Procedural City
Generation.
23) Lang, R. (2010). Dyson's Random Morph Map. Hentede 18. 2 2010 fra 1km1kt:
http://www.1km1kt.net/geomorph/
24) Laycock, R. G., & Day, A. M. (2003). Automatically Generating roof Models from Building
Footprint. University of East Anglia, Norwich.
25) Lindenmayer, A., & Prusinkiewicz, P. (1996). The Algorithmic Beauty of Plants. Springer
Verlag.
26) Lipp, M., Wonka, P., & Wimmer, M. (2008). Interactive Visual Editing of Grammars for
Procedural Architecture. ACM SIGGRAPH, (s. 1-10, vol 27).
27) lsas. (2010). Vælg tagformen til dit hus. Hentede 5. 2 2010 fra Løve Savværk:
http://www.lsas.dk/02_bestil-tagspaer/tagformer.html
28) Mantyla, M. (1988). Introduction to Solid Modeling. NY, USA: WH Freeman & Co. New York.
29) Müller, P. (2. 11 2006). Procedural Reconstruction of Archaeological Sites. Hentede 24. 3 2010
fra Pascals Müllers wiki: http://www.vision.ee.ethz.ch/~pmueller/wiki/Courses/VAST2006
159

30) Müller, P., & Parish, Y. I. (2001). Procedural Modeling of Cites. Proceedings of ACM
SIGGRAPH, (s. 301-308).
31) Müller, P., Wonka, P., Haegler, S., Ulmer, A., & Van Gool, L. (2006). Procedural Modeling of
Buildings. Proceedings of ACM SIGGRAPH, (s. 614-623, vol 25).
32) Mössenböck, H. (2006). The Compiler Generator Coco/r User Manual. Johannes Kepler
University, Linz.
33) Perlin, K. (9. 12 1999). Making Noise. Hentede 18. 2 2010 fra noisemashine:
http://www.noisemachine.com/talk1/
34) Procedural, i. (u.d.). CityEngine Help roofHip. Hentede 6. 3 2010 fra CityEngine:
http://www.procedural.com:8080/help/index.jsp?topic=/com.procedural.cityengine.help/ht
ml/toc.html
35) Procedural, I. (u.d.). Front page. Hentede 30. 3 2010 fra Procedural inv:
http://www.procedural.com/
36) Prusinkiewicz, P., & Mech, R. (1996). Visual Models of Plants Interacting with Their
Environment. Proceedings of the 23rd Annual Conference on Computer Graphics, (s. 397 - 410).
37) Rosmarin, R. (12. 19 2006). Forbes. Hentede 19. 2 2010 fra Why Gears Of War Costs $60:
http://www.forbes.com/2006/12/19/ps3-xbox360-costs-techcx_rr_game06_1219expensivegames.html
38) Rotenberg, S. (2005). Procedural Modeling. Hentede 17. 2 2010 fra
http://graphics.ucsd.edu/courses/cse167_f05/CSE167_18.ppt
39) Stiny, G. (1982). Spatial relations and grammars.
40) Takatsuki, Y. (27. 12 2007). BBC News. Hentede 19. 2 2010 fra Cost headache for game
developers: http://news.bbc.co.uk/2/hi/business/7151961.stm
41) Whiting, E., Ochsendorf, J., & Durand, F. (2009). Procedural Modeling of Structurally-Sound
Masonry Buildings. Proceedings of SIGGRAPH Asia, Article: 112 .
42) Wonka, P., Wimmer, M., Sillion, F., & Ribarsky, W. (2003). Instant Architechture.
Proceedings ACM SIGGRAPH, (s. 669-677).
160

Bilag 1: L-systemer
Fraktal- l-system (L-sys1.txt)
/*Axiom*/
F(3) B(3, 1);
/*Production*/
p2: B(x, y) -> Size(y)Roll(0.2)Pitch(0.2)F(x * 2) Push() C(x * 0.9, y * 0.88)
Pop() Push() D(x * 0.9, y * 0.88) Pop() B(x*0.95, y*0.95);
p3: C(x, y) -> Size(y)Yaw(0.2)Pitch(0.2)F(x)C(x*0.9, y*0.88);
p3: D(x, y) -> Size(y)Yaw(0.2)Pitch(-0.2)F(x)D(x*0.9, y*0.88);
Egetræ (Tree1.txt)
number trunkLengthReduction = 0.9;
number trunkSizeReduction = 0.92;
/*Axiom*/
Size(1.7)F(0)Trunk(1.8, 1.4);
/*Production*/
p1: Trunk(x, y) -> Size(y) R(0.05, 0.05, 0.05) F(x) Roll(1.916) T(0.21)
Trunk(x * trunkLengthReduction, y * trunkSizeReduction) : 0.2;
p2: Trunk(x, y) -> Size(y) R(0.05, 0.05, 0.05) F(x) Push() Pitch(-0.6)
Branch(x * 0.44, y * 0.54) Pop() Pitch(0.00) Roll(1.916)
Trunk(x * trunkLengthReduction, y * trunkSizeReduction) : 0.5;
p3: Trunk(x, y) -> Size(y) R(0.05, 0.05, 0.05) F(x)
Push() Pitch(-0.5) Branch(x * 0.35, y * 0.35) Pop()
Push() Pitch(0.4) Branch(x * 0.35, y * 0.35) Pop()
Pitch(0.00) Roll(1.916)
Trunk(x * trunkLengthReduction, y * trunkSizeReduction) : 0.3;
p4: Branch(x, y) -> Size(y) T(0.2) R(0.2, 0.2, 0.2) F(x)
Branch(x * 0.94, y * 0.94) : 0.9;
p5: Branch(x, y) -> Size(y) T(0.2) R(0.2, 0.2, 0.2) F(x) Push() Level() Yaw(0.7)
Branch(x * 0.85, y * 0.4) Pop() Branch(x * 0.94, y * 0.94) : 0.03;
p6: Branch(x, y) -> Size(y) T(0.2) R(0.2, 0.2, 0.2) F(x) Push() Level()
Yaw(-0.7) Branch(x * 0.85, y * 0.4) Pop()
Branch(x * 0.94, y * 0.94) : 0.03;
p5: Branch(x, y) -> Size(y) T(0.2) R(0.2, 0.2, 0.2) F(x) Push() Level() Yaw(0.7)
Branch(x * 0.85, y * 0.4) O(1) Pop()
Branch(x * 0.94, y * 0.94) : 0.02;
p6: Branch(x, y) -> Size(y) T(0.2) R(0.2, 0.2, 0.2) F(x)
Push() Level() Yaw(-0.7) Branch(x * 0.85, y * 0.4) O(1) Pop()
Branch(x * 0.94, y * 0.94) : 0.02;
p7: T(x) : x -0.07 -> T(x - 0.01);
Fyrtræ 1 (Tree2.txt)
number numDerivations = 20;
number lr = 1.119; /* elongation rate */
number sr = 1.14; /* width increase rate */
/*Axiom*/
Size(0.039)F(0)Trunk(0.2, 0.035);
161

*Production*/
p1: Trunk(x, y) -> Size(y) Roll(1.916) F(x) R(0.02, 0.02, 0.02)
Trunk(x, y) : 0.01;
p1: Trunk(x, y) -> Size(y) Roll(1.916) F(x) R(0.02, 0.02, 0.02)
Push() Pitch(1.2) Size(y * 0.001) F(x * 0.5) Pitch(-0.4) O(0.7) Pop()
Trunk(x, y) : 0.99;
p2: F(x) -> F(x * lr);
p3: Size(x) -> Size(x * sr);
p5: O(x) -> O(x * 1.08);
Bøgetræ (Tree3.txt)
number numDerivations = 10;
number r1 = 0.9; /* contraction ratio for the trunk */
number r2 = 0.66; /* contraction ratio for the branches */
number a0 = 0.7853; /* branching angle for the trunk */
number a2 = 0.7853; /* brnaching angle for the lateral axes */
number d = 2.3998; /* divergence angle */
number wr = 0.707; /* width decrease angle */
/*Axiom*/
A(1.5, 0.2);
p1: A(l, w) -> Size(w) R(0.1, 0.1, 0.1) T(0.1) F(l)
Push() Pitch(a0) B(l * r2, w * wr * 0.5) O(0.5) Pop()
Roll(d) A(l * r1, w * wr);
p2: B(l, w) -> Size(w) R(0.2, 0.2, 0.2) F(l * 0.5) T(0.1)
Push() Yaw(-a2) Level() R(0.1, 0.1, 0.2) CC(l, w, 0) O(0.7) Pop()
C(l * r1, w * wr);
p3: C(l, w) -> Size(w) R(0.2, 0.2, 0.2) F(l * 0.5) T(0.1)
Push() Yaw(a2) Level() R(0.1, 0.1, 0.2) BC(l, w, 0) O(0.7) Pop()
B(l * r1, w * wr);
p4: CC(l, w) -> C(l, w) : 0.4;
p5: BC(l, w) -> B(l, w) : 0.4;
p6: O(x) -> O(x * 1.1);
Fyrtræ 2 (Tree4.txt)
number numDerivations = 20;
number r1 = 0.9; /* contraction ratio for the trunk */
number r2 = 0.66; /* contraction ratio for the branches */
number a0 = 1.5707; /* branching angle for the trunk */
number a2 = 0.7853; /* brnaching angle for the lateral axes */
number d = 2.3998; /* divergence angle */
number wr = 0.707; /* width decrease angle */
/*Axiom*/
A(0.9, 0.2);
p1: A(l, w) -> Size(w) R(0.1, 0.1, 0.1) T(0.1) F(l)
Push() Pitch(a0) B(l * r2, w * wr * 0.5) O(0.5) Pop()
Roll(d) A(l * r1, w * wr);
p2: B(l, w) -> Size(w) R(0.2, 0.2, 0.2) F(l * 0.5) T(-0.05)
Push() Yaw(-a2) Level() R(0.1, 0.1, 0.2) CC(l, w, 0) O(0.7) Pop()
C(l * r1, w * wr);
p3: C(l, w) -> Size(w) R(0.2, 0.2, 0.2) F(l * 0.5) T(-0.05)
Push() Yaw(a2) Level() R(0.1, 0.1, 0.2) BC(l, w, 0) O(0.7) Pop()
162

B(l * r1, w * wr);
p4: CC(l, w) -> C(l, w) : 0.03;
p5: BC(l, w) -> B(l, w) : 0.03;
p6: O(x) -> O(x * 1.02);
Bilag 2: CGA-grammaer
Sears Tower (SearsTower.txt)
HEADER:
//Common
number floorHeight = 0.5; //Number variable declared
number buildingHeight = 25;
number pi = 3.1415926;
//Facade
number marginWidth = 0.1;
random r = [0.5, 1.0]; //Random variable declared
random r2 = [0.3, 0.6]; //Random variable declared
random r3 = [0.6, 0.8]; //Random variable declared
DECLARATION:
PRIORITY 1:
p1: Sears -> S(Scope.Sx, buildingHeight, Scope.Sz)
Push() T((-Scope.Sx / 3.0) * 0.5, 0, (-Scope.Sz / 3.0) * 0.5)
S(Scope.Sx / 3.0, Scope.Sy, Scope.Sz / 3.0) column antenna Pop()
Push() pillars Pop()
Push() Ry(pi*0.5) pillars Pop()
Push() Ry(pi) pillars Pop()
Push() Ry(pi * 1.5) pillars Pop();
p2: pillars -> T((-Scope.Sx / 3.0) * 1.5, 0, (-Scope.Sx / 3.0) * 1.5)
S((Scope.Sx / 3.0) * 2, Scope.Sy, Scope.Sx / 3.0) sidePillar;
p2: sidePillar -> Push() T(Scope.Sx / 2, 0, 0)
S(Scope.Sx / 2, Scope.Sy, Scope.Sz) column antenna Pop()
Push() S(Scope.Sx / 2, Scope.Sy * r2, Scope.Sz) column Pop() : 0.15;
p2: sidePillar -> S(Scope.Sx, Scope.Sy * r3, Scope.Sz)
Push() T(Scope.Sx / 2, 0, 0) S(Scope.Sx / 2, Scope.Sy, Scope.Sz)
column Pop()
Push() S(Scope.Sx / 2, Scope.Sy * r2, Scope.Sz) column Pop() : 0.85;
p4: antenna -> Push() T(Scope.Sx * 0.5, Scope.Sy, Scope.Sz * 0.5)
S(0.2, Scope.Sy * 0.15, 0.2) I("cylinder") Pop();
PRIORITY 2:
p4: column -> Comp("sidefaces") {facade} Comp("topface") {roofMat};
// Facade
p6: facade -> Subdiv("Z", marginWidth, *1, marginWidth)
163

{gray | windowGroup | gray};
p7: windowGroup -> Subdiv("X", marginWidth, *1, marginWidth)
{gray | glassMat | gray};
Petronas Towers (Petronas.txt)
HEADER:
number floorHeight = 0.5;
number buildingHeight = 35;
number heightFallOff = 0.5;
number widthFallOff = 0.6;
number pi = 3.1415926;
number squareHalf = 0.89;
number cylinderSize = 0.2617993877991; //Diameter = pi / 16
random r = [0.5, 1.0];
random r2 = [0.3, 0.6];
random r3 = [0.6, 0.8];
DECLARATION:
PRIORITY 1:
p1: Petronas -> S(Scope.Sx, buildingHeight, Scope.Sz) section row;
p2: row : Scope.Sy > 3 * floorHeight -> T(0, Scope.Sy, 0)
S(Scope.Sx - widthFallOff,
heightFallOff * Scope.Sy,
Scope.Sz - widthFallOff)
section row;
p3: row : Scope.Sy < 3 * floorHeight -> antenna;
p2: section ->
Push() T(-Scope.Sx * 0.5, 0, -Scope.Sz * 0.5)
petronasSuperStructure Pop()
Push() Ry(pi * 0.25) T(-Scope.Sx * 0.5, 0, -Scope.Sz * 0.5)
petronasSuperStructure Pop()
Push() Ry(pi * 0.125) buldge Pop()
Push() Ry(pi * 0.375) buldge Pop()
Push() Ry(pi * 0.625) buldge Pop()
Push() Ry(pi * 0.875) buldge Pop();
p3: buldge ->
Push() T(Scope.Sx * 0.5, 0, Scope.Sz * 0.5)
T(-Scope.Sx * squareHalf, 0, -Scope.Sz * squareHalf)
petronasCylinder Pop()
Push() T(-Scope.Sx * 0.5, 0, -Scope.Sz * 0.5)
T(Scope.Sx * squareHalf, 0, Scope.Sz * squareHalf)
petronasCylinder Pop();
PRIORITY 2:
p4: petronasSuperStructure -> Subdiv("Y", *1, floorHeight)
{ Repeat("Y", 2 * floorHeight) {
164

I("cube") Subdiv("Y", floorHeight, floorHeight) {gray | glassMat} }
| gray};
p5: petronasCylinder ->
Push() S(Scope.Sx * cylinderSize, Scope.Sy, Scope.Sz * cylinderSize)
I("cylinder") cylinder Pop();
p5: cylinder -> Subdiv("Y", *1, floorHeight)
{ Repeat("Y", 2 * floorHeight)
{ Subdiv("Y", floorHeight, floorHeight)
{ T(0, Scope.Sy * 0.5, 0) gray | T(0, Scope.Sy * 0.5, 0) glassMat}
} | T(0, Scope.Sy * 0.5, 0) gray };
p4: antenna -> T(0, Scope.Sy, 0) ball
T(-0.1, 0, -0.1) S(0.2, buildingHeight * 0.3, 0.2) I("cylinder");
p7: ball -> Push() T(-Scope.Sx * 0.0, Scope.Sx * 0.0, -Scope.Sx * 0.0)
S(Scope.Sx * 0.5, Scope.Sz * 0.5, Scope.Sx * 0.5)
I("sphere") gray Pop();
Kontorbygning (OfficeBuilding.txt)
HEADER:
number floorHeight = 1;
number windowHeight = 0.8;
number windowWidth = 0.2;
number sectionMultiplier = 2;
number windowGroupWidth = 2.4;
number doorWidth = 1;
number glassWidth = 0.6;
number frameSize = 0.02;
number roofInset = 0.1;
number overhang = 0.2;
number underhangSize = 0.1;
string facadeType = "type3";
random r1 = [0.25, 0.6];
random r2 = [0.3, 0.9];
random r3 = [0.6, 1.0];
random r4 = [0.2, 0.9];
random r5 = [0.5, 0.7];
random r6 = [0.2, 0.7];
random r7 = [0.1, 0.2];
number buildingHeight = 80;
DECLARATION:
PRIORITY 1:
p1 : lot -> S(*1, buildingHeight * r5, *1)
Subdiv("Z", Scope.Sz * r1, *1)
{ Comp("sidefaces") {facades} Comp("topface") {roof} | sidewings};
p2 : sidewings -> Subdiv("X", Scope.Sx * r2, *1) {sidewing | epsilon}
165

Subdiv("X", *1, Scope.Sx * r2) {epsilon | sidewing};
p3 : sidewing -> Subdiv("Z", Scope.Sz * r3, *1){ Comp("sidefaces") {facades}
Comp("topface") {roof} | epsilon} : 0.5;
p4 : sidewing -> S(*1, Scope.Sy * r4, *1)
Subdiv("Z", Scope.Sz * r3, *1)
{ Comp("sidefaces") {facades} Comp("topface") {roof} | epsilon}
: 0.3;
p5 : sidewing -> epsilon : 0.2;
//Shuffle facade
p6 : facades : facadeType == "type1" -> facades1;
p6 : facades : facadeType == "type2" -> facades2;
p6 : facades : facadeType == "type3" -> facades3;
p6 : facades : facadeType == "type4" -> facades4;
//----------------------Facade 1 ------------------------------------
//Facade
p7 : facades1 : Scope.Sz > floorHeight * 3 ->
Subdiv("Z", floorHeight * 1.3, *1, floorHeight * 1.3)
{baseFloor | mid | topFloor};
p7 : facades1 : Scope.Sz > floorHeight -> baseFloor;
p7 : facades1 -> facade;
//Facade elements
p8 : mid : Scope.Sz > floorHeight -> Repeat("X", windowGroupWidth)
{Repeat("Z", floorHeight){ windowGroup }};
p8 : mid -> facade;
p9 : windowGroup -> Subdiv("X", *1, Scope.Sx * windowWidth, *1)
{facade | Subdiv("Z", *0.8, Scope.Sz * windowHeight, *1)
{facade | win | facade} | facade};
p10 : doorGroup -> Subdiv("X", *1, Scope.Sx * 0.8, *1) {facade | door | facade};
p11 : baseFloor : Scope.Sx > doorWidth * 2 ->
Subdiv("Z", floorHeight * 1.1, *1){ Subdiv("X", *1, doorWidth, *1)
{innerFrame | doorGroup | innerFrame} | facade} : 0.4;
p11 : baseFloor : Scope.Sx > doorWidth * 2 ->
Subdiv("Z", floorHeight * 1.1, *1){ Subdiv("X", doorWidth, *1, *1)
{doorGroup | innerFrame | innerFrame} | facade} : 0.2;
p11 : baseFloor : Scope.Sx > doorWidth * 2 ->
Subdiv("Z", floorHeight * 1.1, *1){ Subdiv("X", *1, *1, doorWidth)
{innerFrame | innerFrame | doorGroup} | facade} : 0.2;
p11 : baseFloor -> Subdiv("Z", floorHeight * 1.1, *1){ innerFrame | facade};
p12 : topFloor -> Repeat("X", windowGroupWidth * 2)
{ Subdiv("X", *1, Scope.Sx * (windowWidth + (1 - windowWidth) * 0.5),
*1) {facade | Subdiv("Z", *0.8, Scope.Sz * windowHeight, *1) {facade
| win | facade} | facade} };
//----------------------Facade 2 ------------------------------------
p13 : facades2 : Scope.Sz > 2 * floorHeight ->
166

Subdiv("Z", floorHeight * 1.3, *1) {baseFloor2 | mid2};
p13 : facades2 -> baseFloor2;
p14 : mid2 -> Repeat("Z", floorHeight) {floor2};
p15 : floor2 -> Subdiv("Z", underhangSize, *1) {underhangFacade | innerFrame};
p16 : underhangFacade -> T(-underhangSize, 0, 0)
S(Scope.Sx + 2 * underhangSize, underhangSize, Scope.Sz) gray;
p17: baseFloor2 : Scope.Sx > floorHeight * 2 ->
Subdiv("X", (Scope.Sx - floorHeight) * r6, floorHeight, *1)
{innerFrame | Subdiv("Z", floorHeight, *1)
{door | innerFrame} | innerFrame};
p17: baseFloor2 -> innerFrame;
//----------------------Facade 3 ------------------------------------
p18 : facades3 : Scope.Sz > 2 * floorHeight ->
Subdiv("Z", floorHeight * 1.3, *1) {baseFloor3 | mid3};
p18 : facades3 -> baseFloor3;
p19 : mid3 : Scope.Sx > floorHeight ->
Subdiv("X", 0.5 * floorHeight, *1, floorHeight * 0.5)
{facade | midColumn | facade};
p19 : mid3 -> midColumn;
p20 : midColumn : Scope.Sz > floorHeight -> Subdiv("Z", *1, floorHeight * 0.5)
{ Repeat("Z", floorHeight){ winSection } | facade};
p20 : midColumn -> winSection;
p21 : winSection -> Repeat("X", sectionMultiplier * windowWidth) {windowGroup3};
p22 : windowGroup3 -> Subdiv("X", *1, Scope.Sx * windowWidth, *1)
{facade | Subdiv("Z", Scope.Sz * windowHeight, *1) { win | facade} |
facade};
p23: baseFloor3 -> Subdiv("X", floorHeight * 0.5, *1, floorHeight * 0.5)
{facade | winSection | facade};
//------------------------Facaade 4---------------------------------
p24 : facades4 : Scope.Sz > 2 * floorHeight ->
Subdiv("Z", floorHeight * 1.3, *1) {baseFloor3 | mid4};
p24 : facades4 -> baseFloor3;
p25 : mid4 : Scope.Sx > floorHeight ->
Subdiv("X", 0.5 * floorHeight, *1, floorHeight * 0.5)
{facade | midColumn4 | facade};
p25 : mid4 -> midColumn4;
p26 : midColumn4 : Scope.Sz > floorHeight ->
Subdiv("Z", *1, floorHeight * 0.5)
{ Repeat("Z", floorHeight) { windowGroup4 } | facade};
p26 : midColumn4 -> windowGroup4;
p27 : windowGroup4 -> Subdiv("Z", Scope.Sz * windowHeight, *1) { win | facade};
//-------------------- Detail objects ------------------------------
//Window
p28 : win -> T(0, -frameSize * 2, 0) Push()
S(Scope.Sx, frameSize * 2, Scope.Sz) Comp("sidefaces") {facade} Pop()
167

Subdiv("Z", frameSize, *1) {underhang | innerFrame};
p29 : innerFrame -> Repeat("X", glassWidth)
{ Subdiv("X", frameSize, *1, frameSize)
{ windowFrame | Subdiv("Z", frameSize, *1, frameSize)
{windowFrame | glass | windowFrame} | windowFrame}};
p30 : windowFrame -> S(Scope.Sx, frameSize, Scope.Sz) darkGray;
p31 : underhang -> S(Scope.Sx, frameSize * 4, Scope.Sz) darkGray;
//Door
p32 : door -> T(0, -Scope.Sx * 0.02, 0) Push()
S(Scope.Sx, Scope.Sx * 0.02, Scope.Sz) Comp("sidefaces") {facade}
Pop() darkGray;
//Roof
p33 : roof -> darkGray T(Scope.Sx * r6, 0, Scope.Sz * r6)
S(Scope.Sx * r1 * 0.4, 0.5 * r1, Scope.Sz * r1 * 0.4) darkGray : 0.5;
p33 : roof -> darkGray Inset(roofInset)
{ S(Scope.Sx, 1 * r1, Scope.Sz) darkGray } : 1;
Villa (Mansion.txt)
HEADER:
random r1 = [0.2, 0.4];
random r2 = [0.1, 0.3];
random rr = [0.2, 0.4];
randomi rSlope = [10, 50];
number baseHeight = 0.6;
number baseWidth = 0.1;
number cornice = 0.15;
number floorSplit = 0.05;
number frontOutset = 3.5;
random rOutset = [2, 5];
number floorHeight = 3.5;
number numFloors = 2;
number sideColumnWidth = 0.4;
number sideColumnHeight = 0.6;
//Window + doors
number frameSize = 0.07;
number subFrameSize = 0.05;
number windowWidth = 1.5;
number doorWidth = 1;
number doorHeight = 2;
number windowHeight = 1.5;
number groupSpan = 0.8;
number stepHeight = 0.15;
number stepWidth = 0.2;
number bottomFloorRatio = 1.12;
number fenceWidth = 0.1;
number fenceHeight = 0.5;
168

number buildingHeight = 30;
number pi = 3.141592653589;
boolean hasSideColumn = true;
DECLARATION:
PRIORITY 1:
p1 : lot -> S(Scope.Sx, 0, Scope.Sz) Subdiv("Z", Scope.Sz * rr, *1,
Scope.Sz * rr) {frontYard | mid | backYard};
p2 : mid -> S(*1, numFloors * floorHeight, *1) Subdiv("X", Scope.Sx * r2, *1,
Scope.Sz * r2) {garden | house T(0, Scope.Sy + 0, 0) Inset(-cornice)
{ Comp("footprint", 0, 1) {roofEdge} } roofTier | garden} ;
p3 : house -> Comp("sidefaces", 0) {front} Comp("sidefaces", 2) {back}
Comp("sidefaces", 1) {side} Comp("sidefaces", 3) {side} ;
p4: front -> Subdiv("X", *1, Scope.Sx * r1, *1)
{windowFacade | outset | windowFacade} : 0.2;
p4: front -> Subdiv("X", *1, Scope.Sx * r1, *1)
{outset | windowFacade | outset} : 0.2;
p4: front -> Subdiv("X", Scope.Sx * r1, *1) {outset | windowFacade } : 0.2;
p4: front -> Subdiv("X", *1, Scope.Sx * r1) {windowFacade | outset} : 0.2;
p4: front -> /*gray T(0, 4, 0)*/ windowFacade;
p5 : back -> Subdiv("X", *1, Scope.Sx * r1) {windowFacade | balcony} : 0.4;
p5 : back -> Subdiv("X", Scope.Sx * r1, *1) {balcony | windowFacade} : 0.4;
p5 : back -> windowFacade;
p6: side -> windowFacade;
p7 : outset -> S(Scope.Sx, Scope.Sz, frontOutset) Rx(pi * 0.5)
T(0, 0, -frontOutset) Comp("sidefacesEx", 1) {windowFacade}
Comp("topface", 1) { outsetRoof };
p8 : outsetDoor -> S(Scope.Sx, frontOutset, Scope.Sz) Comp("faces") {gray}
Comp("sidefaces", 1) { outsetRoof };
p9: balcony : Scope.Sz > floorHeight * bottomFloorRatio + cornice / 3 +
baseHeight ->
Subdiv("Z",
floorHeight * bottomFloorRatio + cornice / 3 + baseHeight, *1)
{ S(Scope.Sx, Scope.Sz, rOutset) Rx(pi * 0.5)
T(0, 0, -Scope.Sz) Comp("sidefaces") {windowFacade} Comp("topface")
{balconyRoof} | balconyDoor} : 0.8;
p9: balcony -> S(Scope.Sx, Scope.Sz, rOutset) Rx(pi * 0.5) T(0, 0, -Scope.Sz)
Comp("sidefacesEx", 1) {windowFacade}
Comp("topface") { outsetRoof } : 1;
p10: balconyDoor -> Subdiv("Z", *1, cornice) {balconyDoorTile | cornice};
p11: balconyRoof -> gray Subdiv("X", fenceWidth, *1, fenceWidth)
{ fence | Subdiv("Z", fenceWidth, *1)
{ Ry(-pi * 0.5) S(Scope.Sz, Scope.Sy, Scope.Sx + fenceWidth)
T(0, 0, -Scope.Sz) fence | eps} | fence};
169

p12: fence -> Repeat("Z", 1){ Push() S(fenceWidth, fenceHeight, fenceWidth) gray
Pop() T(Scope.Sx * 0.5, 0, 0) S(0, fenceHeight, Scope.Sz) gray };
p13: outsetRoof -> Inset(-cornice){ Comp("footprint", 1, 0) {roofEdge}};
p14: windowFacade : Scope.Sx > sideColumnWidth * 2 ->
Subdiv("Z", baseHeight, *1, cornice)
{base | Subdiv("X", sideColumnWidth, *1, sideColumnWidth)
{gray column | windowTiles | gray Rz(pi)
T(-Scope.Sx, -floorSplit, 0) column} |cornice};
p14: windowFacade -> Subdiv("Z", baseHeight, *1, cornice)
{base | gray column |cornice};
p15: windowTiles : Scope.Sz > floorHeight * bottomFloorRatio + cornice ->
Subdiv("Z", floorHeight * bottomFloorRatio, *1)
{doorWinGroup | topFloor};
p15: windowTiles -> doorWinGroup; //BottomFloor
p16: column : hasSideColumn -> Repeat("Z", sideColumnHeight)
{ T(-floorSplit + 0.001, 0, 0) Push()
S(Scope.Sx + 2 * floorSplit, floorSplit, Scope.Sz * 0.5 - 0.01)
whiteMat Pop() T(0, 0, Scope.Sz * 0.5)
S(Scope.Sx * 0.5 + 2 * floorSplit, floorSplit, Scope.Sz * 0.5 - 0.01)
whiteMat };
p17 : topFloor -> Subdiv("Z", floorSplit, *1){floorSplit | windowGroup};
p18: base -> S(Scope.Sx + 2 * baseWidth, baseWidth, Scope.Sz)
T(-baseWidth + 0.001, 0, 0) whiteMat
S(Scope.Sx + 2 * baseWidth, 2 * baseWidth, Scope.Sz * 0.3333)
T(-baseWidth + 0.001, 0, 0) whiteMat;
p19 : floorSplit -> T(-floorSplit + 0.001, 0, 0)
S(Scope.Sx + 2 * floorSplit, floorSplit, Scope.Sz) whiteMat;
p20 : cornice -> Subdiv("Z", *0.3333, *0.3333, *0.3333)
{ S(Scope.Sx + cornice * 0.6666, cornice *0.3333, Scope.Sz)
T(-cornice * 0.3333 + 0.001, 0, 0) whiteMat |
S(Scope.Sx + cornice * 1.3333, cornice * 0.6666, Scope.Sz)
T(-cornice * 0.6666 + 0.001, 0, 0) Repeat("X", cornice * 2)
{Subdiv("X", *1, *1) {whiteMat |
S(Scope.Sx, cornice * 0.3333, Scope.Sz) whiteMat}} |
S(Scope.Sx + cornice * 2, cornice, Scope.Sz)
T(-cornice + 0.001, 0, 0) whiteMat};
p21: doorWinGroup : Scope.Sx > doorWidth + groupSpan ->
Subdiv("X", *1, doorWidth + groupSpan, *1)
{windowGroup | doorTile | windowGroup} : 0.25;
p121: doorWinGroup -> windowGroup;
p22: windowGroup : Scope.Sx > windowWidth + groupSpan ->
Repeat("X", groupSpan + windowWidth){ winTile };
p22: windowGroup -> gray;
p23: winTile -> Subdiv("X", *1, windowWidth, *1)
170

{ gray | Subdiv("Z", *1, Scope.Sz * 0.6, *1){gray | win | gray} |
gray };
p24: doorTile -> Subdiv("X", *1, doorWidth, *1)
{gray | Subdiv("Z", doorHeight, 0.1,
(Scope.Sz * 0.8 - doorHeight - 0.1), *1){ stair door | gray |win |
gray} | gray };
p25: balconyDoorTile -> Subdiv("X", *1, doorWidth, *1)
{gray | Subdiv("Z", doorHeight, 0.1,
(Scope.Sz * 0.8 - doorHeight - 0.1), *1)
{ door | gray |win | gray} | gray };
/*-----------Window 1 Crosswin ---------*/
p26: win -> T(0, -frameSize, 0) Subdiv("Z", frameSize, *1, frameSize)
{ S(Scope.Sx, frameSize * 3, Scope.Sz) gray |
Subdiv("X", frameSize, *1, frameSize)
{S(Scope.Sx, frameSize * 2, Scope.Sz) gray | crossWin |
S(Scope.Sx, frameSize * 2, Scope.Sz) gray} |
S(Scope.Sx, frameSize * 2, Scope.Sz) gray};
p27: crossWin -> Subdiv("Z", *2, *1) { Subdiv("X", *1, *1)
{subFrame | subFrame} | Subdiv("X", *1, *1){subFrame | subFrame} };
p28: subFrame -> Subdiv("X", subFrameSize, *1, subFrameSize)
{S(Scope.Sx, subFrameSize, Scope.Sz) gray |
Subdiv("Z", subFrameSize, *1, subFrameSize)
{S(Scope.Sx, subFrameSize, Scope.Sz) gray | glassMat |
S(Scope.Sx, subFrameSize, Scope.Sz) gray} |
S(Scope.Sx, subFrameSize, Scope.Sz) gray};
/*-----------Door ---------*/
p29: stair : Scope.PWy > stepHeight - 0.0001 ->
T(-stepWidth, 0, -stepHeight)
S(Scope.Sx + stepWidth * 2, Scope.Sy + stepWidth, stepHeight)
gray stair;
p30: door -> T(0, -frameSize, 0) Subdiv("Z", frameSize, *1, frameSize)
{S(Scope.Sx, frameSize * 3, Scope.Sz) gray |
Subdiv("X", frameSize, *1, frameSize)
{S(Scope.Sx, frameSize * 2, Scope.Sz) gray | brownMat |
S(Scope.Sx, frameSize * 2, Scope.Sz) gray} |
S(Scope.Sx, frameSize * 2, Scope.Sz) gray};
/*------------- Roof ----------------*/
PRIORITY 2:
p31: roofTier -> Roof("roofEdge", "mansard", 80, 30, 2, "halfHip", 2, 45)
{roof | gable} : 0.25;
p31: roofTier -> Roof("roofEdge", "sloped", rSlope, "gable")
{roof | gable} : 0.25;
p31: roofTier -> Roof("roofEdge", "sloped", 30, "hip", 30)
{roof | gable} : 0.125;
p31: roofTier -> Roof("roofEdge", "sloped", 40, "hip", 40)
{roof | gable} : 0.125;
p31: roofTier -> Roof("roofEdge", "sloped", 45, "halfHip", *0.66, 45)
{roof | gable};
p31: roofTier -> Roof("roofEdge", "sloped", 40, "hip", 40) {roof | gable} : 1;
p32: roof -> T(0, -cornice * 0.5, -0.0001)
171

S(Scope.Sx, cornice * 0.5, Scope.Sz) roofMat;
p33: gable -> T(0, -cornice * 0.5, 0) gray;
172