Datalogi 0GB K-opgaven: DIKU Flight Simulator 2004

Datalogi 0GB K-opgaven: DIKU Flight Simulator 2004
Svend Ezaki Tofte, Andres Eskjær og Troels Parbst
13. maj 2003
2

Indhold
1 Sammenfatning 5
2 Problemorienteret analyse 5
2.1 Programdomæne . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Modellens koncepter . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1.2 Figurene og deres udregninger . . . . . . . . . . . . . . . . . . . . . . 6
2.1.3 Forbehold ved udregningerne . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Mulige fejl for systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3 Krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.1 Krav til inddata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.2 Krav til uddata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.3 Øvrige krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3 Objektorienteret design 10
3.1 Foranalyse til det objektorienterede design . . . . . . . . . . . . . . . . . . . . 11
3.2 Dokumentation af det objektorienterede design . . . . . . . . . . . . . . . . . 11
3.3 Analyse og diskussion af det objektorienterede design . . . . . . . . . . . . . . 12
3.3.1 Generel struktur, Model-View-Controller . . . . . . . . . . . . . . . . . 12
3.3.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.3 View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.4 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.3.5 Konklusion p˚a objektorienteret design . . . . . . . . . . . . . . . . . . 14
3.3.6 Cyklisk process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.7 Det objektorienteret design af domænet . . . . . . . . . . . . . . . . . 14
3.3.8 Figur design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4 Programmeringsovervejelser 15
4.1 Programstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.2 Programkørsel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
4.2.1 Køretid for hovedalgoritmen . . . . . . . . . . . . . . . . . . . . . . . . 19
5 Brugervejledning 19
5.1 Anvendelse af tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
6 Programbeskrivelse 21
6.1 Kamera . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7 Afprøvning 23
7.1 Obligatoriske billeder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2 Matematisk udregning af nuance . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.3 Krav til opstilling i 3 dimensioner . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.4 XML krav . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.5 Konklusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3

A UML diagrammer 36
A.1 Usecase diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
A.2 Klassediagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
A.3 Sekvensdiagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
A.4 Sekvensdiagram for Scene . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
B CRC Kort 40
C XML specifikation 54
C.1 Krav til tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
D Afprøvningsdata 56
D.1 Obligatoriske billeder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
D.2 Data til matematisk udregning af nuance . . . . . . . . . . . . . . . . . . . . 59
D.3 Data til opstilling i 3 dimensioner . . . . . . . . . . . . . . . . . . . . . . . . . 60
D.3.1 Test 3a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
D.3.2 Test 3b . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
D.3.3 Test 3c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
D.3.4 Test 3d . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
D.3.5 Test 3e . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
D.3.6 Test 3f . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
D.3.7 Test 3g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
D.3.8 Test 3h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
D.3.9 Test 3i . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
E Kildekode 73
E.1 Figur.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
E.2 FlySimulator.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
E.3 Kamera.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
E.4 KameraVinkler.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
E.5 Kanvas.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
E.6 Kugle.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
E.7 Mesh.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
E.8 Plan.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
E.9 Punkt.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
E.10 Scene.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
E.11 Sol.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
E.12 Stoerrelsesfejl.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
E.13 Trekant.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
E.14 Vektor.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
E.15 XMLParseError.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
E.16 XMLParser.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
4

1 Sammenfatning
Denne rapport er en besvarelse af Dat0Gb k-opgaven 2003, ”DIKU FlySimulator 2004”, skrevet
af Andres Eskjær, Troels Parbst og Svend Ezaki Tofte.
Opgaven gik ud p˚a at lave en flysimulator. Kun dele af en flysimulering skulle dog implementeres,
mere specifikt skulle programmet kunne tegne et billede, af hvad piloterne s˚a ud af
deres vindue. Billedet skulle tegnes ved en teknik kaldet str˚alesporing.
Opgaveformuleringen og analysen har lagt grund for hvilken matematik, som er blevet
implementeret i programmet. Udover teorien har analysen klarlagt de potentielle faldgrubber
ved teorien, i en eventuel implementation.
Design fasen har ledt frem til et godt objektorienteret design, som følger design mønstret
Model-View-Controller. Dette isolere problemdomænet i et centralt omr˚ade, mens view abstrahere
fra metoder og egenskaber i domænet, og blot afbildeder domænet.
Programmet er blevet opstillet s˚aledes at problemstillinger bliver h˚andteret p˚a en ensartet
m˚ade. Programmet er blevet opstillet uden at kompromitere korrektheden af de udregninger
som programmet skal lave. Dette er yderligere bekræftet ved en udtømmende afprøvning,
s˚aledes at programmet kalkulere den rigtige farve, og at domænets problemstillinger behandles
korrekt.
Programmet som er blevet skrevet, er den minimale løsning, per opgave formuleringen.
Dette, koblet sammen med seperationen af designet, i model og view, gør at vi anser opgaven
for løst tilfredsstillende.
2 Problemorienteret analyse
Denne analyse vil dække en tolkning af opgaveteksten, kritiske punkter ved opgaven og vores
beslutninger ved løsning af denne. Den vil præcisere krav til ind- og uddata, samt en
række mere eller mindre formelle krav til programmets præstationer. Afsnittene er opdelt i
programdomæne, forbehold ved udregningerne for til sidst at forklare kravene til programmet.
Generelt omhandler opgaven str˚alesporing til grafisk anvendelse. Str˚alesporing er en teknik,
der ved udnyttelse af rumgeometriske begreber, kan udregne et billede af et fiktivt rum,
der indeholder matematisk formulerede figure, s˚asom kugler, planer, osv.. Billedets vinkel i
forhold til det fiktive rum og pixel opløsning bestemmes af et ”kamera”, som ligeledes er
matematisk formuleret. Programmet skal alts˚a kunne generere s˚adanne billeder, ud fra en
formulering af et fiktivt rum, beskrevet vha. udvalgte matematisk beskrevede figurer.
2.1 Programdomæne
Str˚alesporing er et forsøg p˚a, at generere 3-dimensionelle afbildninger, som man kender dem
fra et almindeligt kamera, men afbilleder faktisk kun rumgeometriske begreber under basale
visuelle forholdregler. Derfor er det en naturlig del for forst˚aelsen, af udregningeprocessen - og
dermed en kraftig indvirken p˚a letheden af programmets skabelse - at beskrive og repræsentere
programmet i rumgeometriske termer. Forklaringerne i denne rapport vil ligeledes udtrykke
sig i disse termer. En opsummering af de generelle termer kan ses p˚a [2] bilag B.
P˚a trods af beslutningen om at repræsentere programmet rumgeometrisk, s˚a er en direkte
oversættelse dog ikke mulig - p˚a grund af matematikkens uendeligheder og datamatens begrænsninger
- og desuden s˚a er det ogs˚a kun en delmængde af rumgeometrien, det er relavant
at beskrive for programmet. Dvs. at det der inddrages fra rumgeometrien kun er de væsentlige
5

dele af begreberne, som skal reduceres til monotone beregninger, s˚aledes at en datamat har
grundlag for at kunne anvende modellen.
Det skal her præciseres, at det program vi ønsker at skabe, udelukkende skal fungere som
en implementation af modellen, dvs. kunne udregne et billede ud fra formulering af et fiktivt
rum fra - i dette tilfælde - en XML fil. Programmet skal ikke prøve at finde fornuft i en givet
rum, eller p˚a nogen m˚ade forsøge at h˚andtere en mulig brugerfejl.
2.1.1 Modellens koncepter
Opgaven[2] fra afsnit 3.2 til 3.4 beskriver hvordan samspillet mellem øjepunktet, filmen og
scenen fungere p˚a et generelt nivuau.
Vi følger retningslinjerne fra [4], og opbygger vores model som deri formuleret.
2.1.2 Figurene og deres udregninger
De rumgeometriske grundformer som udvælges til programmet er planer, kugler, trekanter og
en særlig form ”mesh”, som er en samling af trekanter.
Kravet for at programmet kan h˚andtere en figur og dermed udregne dens fremtræden p˚a
billedet er, at der for figurens vedkommende, kan fremstilles en matematisk formulering af,
hvor figuren befinder sig i rummet. I praksis betyder det, at der skal fremstilles en formel
til udregning af skæringspunkt, mellem den linje som forlænges ud igennem filmen fra øjet,
og figuren. Kan en s˚adan formel fremstilles for en figur, eller samling af figurer, s˚a er det for
systemet ikke nødvendigt at vide mere om figuren, n˚ar den skal lokaliseres i rummet. Det
giver systemet en fleksibilitet overfor indførelsen af nye figurer.
For grundformernes vedkommende s˚a har kuglen og planet simple ligninger, til udregning
af skæringspunkter mellem dem, og en linje jf. opgaven[2] afsnit 3.6.1 og 3.6.2. Trekanten kan
delvist udnytte at planet bliver defineret i programmet og anvende noget af dens funktionalitet,
men skal yderligere beregne om skæringspunktet ligger inde i trekanten, hvilket sker jf.
[2] afsnit 3.6.4.
Den lidt specielle figur mesh, er af XML’en specificeret som en samling af trekanter, og
det giver god mening at udnytte det i programmet. Dvs. at udregningsmetoderne for mesh’et
er de samme som for trekanten.
En anden ting programmet skal vide om figurene, er hvordan en nuance udregnes i et
givent skæringspunkt. Nuancer udregnes jf opgaven[2] afsnit 3.5, men det skal tilføjes at vi
vælger, at der for hver figur kun skal kunne tildeles en reflektionskoefficient, som er gældende
for alle dens grundfarver.
Der udregnes kun lys fra en enkelt punktformig lyskilde, og andre faktorer som f.eks.
reflektionslys fra andre figurer eller flere lyskilder bliver ikke medtaget i udregningerne. Derfor
behøves en nuance for en figur kun at udregnes, hvis den ikke bliver overskygget af en anden
figur fra scenen. Vi vælger at den farve der tildeles punkter i billedet, hvor det gælder at
linjen som forlænges ud igennem filmen som ikke rammer nogen figure, eller som rammer en
figur som ligger i skygge af en anden figur, bliver helt sorte.
2.1.3 Forbehold ved udregningerne
I forsøget p˚a at overføre rumgeometrien til datamat anvendelse, opst˚ar der en række problemer
i forbindelse med udregningerne.
6

Ciffertab Som et typisk problem i forholdet mellem matematiske modeller og datamater, s˚a
opst˚ar der et problem i forbindelse med ciffertab. Dette vil med ret stor sandsynlighed medføre
nogle problemer ved sammenligning af punkter, da disse jo blot er tal. Beregningsmæssigt
vil det nemlig være usandsynligt at to forskellige beregninger af samme skæringspunkt f˚ar
de samme talværdier. Derfor kan datamatens talsammenligningen ikke anvendes, uden der
indføres noget ’albuerum’ i systemet.
Kameraet Skæringspunkterne mellem linien udspændt af øjet og et punkt i filmen, og en
figur i scenen, skal ligge foran filmen, hvis de skal kunne ses.
En væsentligt ting her er ogs˚a hvordan kameraet skal opfører sig. Alts˚a om det udelukkende
skal opfattes matematisk, repræsenteret som et punkt og to vektorer, eller p˚a en mere
virkelighedstro m˚ade. Vi vælger at programmet skal opfatte kameraet som et normalt kamera,
og at figurere derfor ikke kan optræde imellen øjet og filmen.
Hvis der er placeret figure mellem øje og film, s˚a vil de dele af figurerne, som skærer ind
i filmen, bare blive ignoreret, og ikke fremtræde p˚a billedet. Ligger en kugle f.eks. placeret
midt i filmen, s˚a vil kun den ene side af den kunne ses p˚a billedet.
Forholdet mellem kameraet og lyskilden En vigtig ting at bemærke ved dette er, at
lyskilden ikke tager højde for hvad kameraet ser. Alts˚a vil en udregning af et skæringspunkt
mellem lyskilden og den kugle som ligger midt i filmen, blive gennemført, uden at tage stilling
til om kameraet kan se det eller ej.
En konsekvens af dette valg kan ses, hvis man ser p˚a den før omtalte kugle. Denne kugle
vil blive ramt af linjen fra øjet i to punkter. Det første punkt vil blive vurderet til at være
ugyldigt, da det ligger placeret inde i filmen. Det andet punkt, p˚a den anden side af kuglen,
vil derimod være gyldigt, da det ligger udenfor filmen.
Næste skridt er at finde ud af om lyskilden skærer dette punkt som det første p˚a sin linie
imod det punkt som øjet skar.
Antages der at lyskilden er placeret bag øjet, s˚a vil det første skæringspunkt mellem
lyskilden og skæringspunktet som øjet fandt for gyldigt, ikke være det samme, da lyskilden
godtager skæringspunktet fra første gang den skar kuglen.
Resultatet af beregningen er, at de punkter hvor kuglen skær filmen, bliver sorte. Se
figur 1.
Nuanceberegning Et tredje problem opst˚ar ved udregning af nuancer. Den ligning vi
anvender til udregning af lysintensitet ([2] side 7 nederst), er afhængig af vinklen mellem en
figurs normalvektor og den vektor som findes mellem lyskilden og det skæringspunkt, hvor
figuren er ramt. Er vinklen over 90 ◦ , s˚a er lysintensiteten 0%, og farven alts˚a sort.
For at denne udregning skal give mening i forhold til kameraet, og alts˚a den nuance som
ender p˚a billedet, s˚a er figurens normalvektor nødt til at pege imod øjet. Ud af dette fremg˚ar
tydeligt, at der til ethvert punkt er knyttet en normalvektor, men at denne kan inverteres
uden at det giver en matematisk forskel.
Det er vigtigt at bemærke dette, da en monoton beregning af en normalvektor for f.eks.
et plan, ikke tager højde for hvor et opdigtet punkt, som et ”øje”befinder sig.
Desuden, s˚a kan den normalvektor som et kamera har brug for, være den modsatte af
den som et andet kamera har brug for. Derfor er det nødvendigt at tage højde for dette ved
7

sol
skæringspunkt mellem
lyskilde og kugle
øje
film
kugle
Fremtræden på billedet
skæringspunkt mellem
øje og kugle.
Figur 1: Forbehold ved sol placeret uden for kugle
hver nuanceberegning. For grundformernes vedkommende, s˚a er det ved dem alle, at dette
forbehold skal tages.
Det er oplagt at planet skal tage højde for dette, da dens normalvektor udregnes som
krydsproduktet mellem de to vektorer som indg˚ar i planet, og at trekanten og mesh’et ligeledes
skal tage højde for det, da de anvender funktionalitet fra planet.
Kuglen skal dog ogs˚a tage højde for dette, da vi har valgt at der ikke m˚a forekomme figurer
mellem øjet og filmen. Derfor s˚a kan der, som forklaret ovenst˚aende, forekomme situationer,
hvor at det første skæringspunkt mellem øjet og kuglen, ikke bliver betragtet som gyldigt,
men at det andet skæringspunkt er gyldigt.
Det ændre den sædvanlige normalvektorberegning for en kugle, da man nu risikere at
m˚aske skulle invertere normalvektoren, inden beregningerne fortsættes.
Denne beslutning giver kuglen nogle særlige egenskaber hvis der sker et særligt samspil
mellem den og lyskilden.
Som før nævnt, s˚a tager lyskilden ikke højde for hvor filmen er placeret. Derfor s˚a bliver
effekten af, at en kugle ligger placeret midt i filmen, at alle punkter hvor kuglen skærer ind i
filmen, hvor man alts˚a s˚a at sige ser ind i kuglen, bliver sorte, hvis alts˚a lyskilden er placeret
udenfor kuglen.
Er lyskilden derimod placeret inde i kuglen, s˚a vil der p˚a billedet fremkomme indesiden af
kuglen. Alts˚a bliver de første skæringspunkter mellem øjet og kuglen ignoreret af kameraet,
og farverne fra de næste skæringspunkter udregnes.
I alle disse skæringspunkter bliver den nuance som udregnes ikke sort, da lyskilden nu
befinder sig inde i kuglen, og derfor registerer alle de skæringspunkter som kameraet har
fundet som gyldige. Se figur 2 for grafisk opstilling af problemet.
2.2 Mulige fejl for systemet
Da vi ønsker at skabe et program, som kun kan udregne et billede ud fra nogle givne data, s˚a
vil en tænkelig fejl, f.eks. at kameraet peger væk fra scenen, ikke blive betegnet som en fejl
af programmet. Det vil være op til brugeren af programmet, at sikre sig at der er mening i
scenens opbygning og kameravinklerne.
Fejl som skal opfanges af programmet, er kun fejl som forhindre beregning af uddata, og
kan opdeles i to grupper.
8

sol
film
øjets og lyskildens
skæringspunkt med
kuglen
normalvektor
øje Fremtræden på billedet
Figur 2: Forbehold ved sol placeret indeni kuglen
Parser/Fil fejl er en gruppe fejl som eksistere, pga. opgavens krav om at inddata skal formuleres
i XML. Det er essentielt for programmet, at de data som bliver parset fra XML’en, er
korrekte. Konstatere parseren fejl eller mangler i disse, s˚a stoppes beregningerne. En nærmere
præcision af inddata bliver beskrevet senere.
Fejl under programkørsel er fejl som fremkommer under udregning af uddata. Konstatere
programmet en s˚adan fejl, stoppes beregningerne, da uddata vil blive forkert.
2.3 Krav
Her formuleres kort kravene til, hvordan inddata skal formuleres, hvordan uddata bliver formuleret,
hvilke krav vi mener programmet skal opfylde, og hvilke egenskaber vi mener programmet
skal have.
2.3.1 Krav til inddata
XML’en skal opfylde kravene som w3.org specificere i [5]. w3.org betegner den XML som
programmet kræver som Wellformed, hvilket vil sige at den opfylder den formelle standard
for formulering syntaktisk korrekt XML.
Generelt for vores parser s˚a gælder det, at n˚ar parseren g˚ar ind i et tag, s˚a vil den søge
efter de typer tags som den er defineret til at lede efter i det specifikke tag, og intet andet.
Skal den f.eks. under et særligt tag bruge 4 tags af typen , da vil den undersøge alle de
tags af typen som findes i første niveau af undertræet, og melde fejl hvis antallet af
de eftersøgte tags er enten mere eller mindre end det p˚akrævede. Befinder der sig andre tags
i undertræet end dem som er p˚akrævet, vil disse blive ignoreret. En detaljeret gennemgang
af hvilke tags der er p˚akræves for at køre programmet, og hvad de enkelte tags kræver af
undertags og attributter er specificeret i C.
2.3.2 Krav til uddata
[2] kræver at uddata sker i et billedformat ved navn .ppm, og i forbindelse med denne opgave
sker det vha. en java klasse, Kanvas, som er stillet til r˚adighed. Vi har valgt at anvende Kanvas
klassen, uden modifikationer.
9

2.3.3 Øvrige krav
De krav, ud over de formelle, som vi ser god mening at stille til programmet, er som før nævnt,
at der ikke skal vises noget mellem øjet og filmen. Dette krav er begrundet som et perceptuelt
krav, der skal hjælpe brugeren af programmet til at forst˚a kameraets rolle i modellen. Ved
at forbyde at der findes nogen figurer mellem øjet og filmen, vil kameraet virke mere som et
kamera fra virkeligheden, og være nemmere at arbejde med.
Vi ønsker ligeledes at programmet tager højde for alle de ting, som er beskrevet i afsnittet
omkring forbehold ved udregningerne.
Ud over disse specifikke ting, der ønsker vi ogs˚a at programmet p˚a længere sigt skal være
programmeringsmæssigt velovervejet, s˚aledes at der bliver god mulighed for at genbruge funktionalitet
s˚a mange steder som muligt, og at programmet bliver fleksibelt overfor ændringer
og udvidelser.
Som en mindre ting ønsker vi ogs˚a, at der overfor brugeren bliver fremstillet en mindre
brugerflade, s˚aledes at der kan ses hvor langt programmet er kommet i beregning af billedet.
Der følger nu en liste af de formelle krav programmet skal opfylde:
• Programmet skal skrives i programmeringssproget Java.
• Indlæse inddata fra en fil, skrevet i XML.
• Udskrive uddata til en fil, i ppm format, til en antal filer, beskrevet i XML’en.
• Have en sceneopbygning best˚aende af et kamera, grundformerne beskrevet tidligere, og
en punktformig lyskilde.
• Programmet skal kunne køres p˚a DIKU’s EDB-system.
3 Objektorienteret design
Dette afsnit vil dokumentere og diskutere det objektorienterede design som vi er kommet
frem til. Først vil vi formulere nogle objektorienterede ideer, som vi ønsker vores design skal
reflektere. Sidenhen vil designet, som det er fremkommet efter designfasen blive opsummeret,
med henvisninger til bilagende hvor de passende diagrammer kan findes. Til sidst vil vi, med
afsnittets egentlige form˚al, gennemg˚a og diskutere det design, som vi er kommet frem til.
Inden afsnittet g˚ar igang, kan det være fordelagtigt, at definere visse begreber, som ellers
kan have en flydende betydning.
Design bruges her om det færdige objektorienterede design, som det er fremkommet efter
analysen.
Systemet/Programmet er en færdig implementation af designet, med alle dets nødvendige
delkomponenter.
Domæne bruges her i sammenhæng til at benævne et systems kerneomr˚ade. I vores opgave
er domænet rumgeometri. Dog er det vigtigt at ligge mærke til at i et program, kan der godt
forekomme flere andre, deldomæner. Et domæne kunne f.eks. være brugerflade, eller ind og
uddata h˚andtering.
10

Modellen er en implementation af domænet, med de metoder og egenskaber som vi har
fundet nødvendige at inkludere fra domænet.
Repræsentationer bruges omkring konkrete klasser som repræsentere elementer i domænet.
Kunne f.eks. være en klasse som repræsentere kuglen. Kan ligeledes bruge omkring matematiske
koncepter, som punkter, osv.
3.1 Foranalyse til det objektorienterede design
Inden vi g˚ar igang med at finde designet, ønsker vi at formulere en række objektorienterede
ideer, som vi ønsker programmet skal afspejle. Form˚alet med at fastsætte disse er, at give
m˚ader til at anskue design fasen, ud over dem, som er angivet i ”Using UML”[6], og i Eric’s
OOD ”kogebog”[1]. Dette vil forh˚abentlig give et endnu mere gennemført design, end ellers.
Identificering af domænet i designet Vi ønsker at identificerer, de centrale klasser, som
er vigtige for domænets virkem˚ade og egenskaber.
Alle systemer definere, ud over det domæne som systemet arbejder i, nogle understøttelses
klasser/kode. Typisk eksempel er fx. main indgangs punktet i et Java program. Det er vigtigt
at identificere de klasser, som ikke er en del af problemdomænet.
Design mønstre Vi ønsker at finde - hvor det er fordelagtigt - tydelige anvendelser af
design mønstre. Især dem, som er blevet gennemg˚aet i pensum, og dem som vil hjælpe med
adskillelse af domæne klasser, og understøttelses klasser.
Sammenhold mellem design og virkelighed S˚a vidt muligt, skal designet afspejle en
realitisk model, som var den fundet i virkeligheden. Dette for at lette forst˚aelse af vores
design. Dette kan hjælpe med forst˚aelsen for b˚ade bruger (f.eks. visuel tekstbehandling i
Microsoft Word), og med forst˚aelsen for eventuelle programmører, som senere skal opdatere
programmet.
Givet vil ikke alt i designet, kunne føres over fra virkeligheden. Det er f.eks. tydeligt, at
et matematisk koncept som en vektor, ikke har en tilsvarende fysisk tilstedeværelse i virkeligheden.
Her ønsker vi at følge de matematiske koncepter, og modelere domænet passende,
s˚a det er logisk for domæneeksperter.
3.2 Dokumentation af det objektorienterede design
Usecase I bilag A.1 findes et diagram over den ene usecase, som programmet skal kunne
h˚andtere. Denne ene usecase kaldes for Lav Billed.
Klassediagram Bilag A.2 viser et diagram over klassernes generelle associationer og generaliseringer.
Ligedes viser diagrammet navigation, af associationerne. Det er vigtigt at lægge
mærke til at flere klasser er udeladt, for overskuelighedens skyld. F.eks. s˚a kender XMLParser
klassen til alle klasser (med undtagelse af Kanvas og Stoerrelsesfejl). Ligeledes er Vektor
og Punkt klassen udeladt, da disse primært bruges til at overføre informationer mellem klasserne,
og de bruges derfor i mange af klasserne. Ligeledes er kun de essentielle attributter og
metoder medtaget.
11

Sekvens diagram for systemet I bilag A.3, ses et diagram over en program kørsel. Her
vil der blive givet noget supplerende tekst til selve diagrammet.
FlySimulator starter en XMLParser op, som instansiere KameraVinkler og Scene objekterne.
For hvert Kamera objekt, som KameraVinkler indeholder, vil den kalde det Kameras
klik metode. Kamera vil for hver pixel i sit billed, spørge Scene om farven i dette punkt.
Sekvensdiagram for Scene I bilag A.4 kan man se et sekvensdiagram over en kørsel med
Scene. Scene undersøger, om vektoren, som der bliver spurgt om, rammer noget, hvis ikke,
returnere Scene. Hvis en punkt rammes, undersøger Scene om solen’s str˚aler ogs˚a rammer
dette punkt som det første. Hvis de ikke gør, skygger en figur for solen, og Scene returnere.
Hvis solen falder p˚a punktet, skal farven i punktet udregnes. Scene spørger den p˚agældende
Figur om farven. I henhold til opgaveformuleringen, henter Figur sin normalvektor i dette
plan, og udregner og returnerer farven.
3.3 Analyse og diskussion af det objektorienterede design
Dette afsnit vil argumentere for, og diskutere det objektorienterede design, som det blev
fremlagt i forrige afsnit.
3.3.1 Generel struktur, Model-View-Controller
Tager man udgangspunkt i et tænkt eksempel for en programkørsel, vil der kunne tydes
tre forskellige dele af processen. En indlæsende del, hvor inddata indføres i systemet, og en
beregnende del, hvor selve str˚alesporingen foreg˚ar, og til sidst en afbildende del hvor et billed
præsenteres. Ud af dette ses der, at design mønstret Model-View-Controller med fordel kan
implementeres.
Vi vil i det følgende, gennemg˚a hver del af dette design mønster, som det er implementeret i
vores design. Til sidst forklarer vi, hvorledes dette design opfylder, flere af de ønsker vi stillede
i foranalysen til det objektorieterede design.
Kamera
Figur 3: MVC modellens centrale elementer
XMLParser
Scene
12
Extern inddata
Præsentation
Model/domæne

3.3.2 Model
Modellen er helt klart det centrale i programmet. Modellen er den del af vores system, som
implementere problemdomænets egenskaber og metoder. I klasser, er der her tale om Scene,
Figur, og de forskellige klasser som nedarver fra figur. Ud over selve de klasser, som omhandler
repræsentation af elementer i Scene, findes der to hjælpeklasser, Vektor og Punkt, som skal
bruges til at lette arbejdet i problemdomænet, ved at have ansvar for mere generelle metoder
ang˚aende vektorudregning.
Data Modellens metoder, og hvorledes data internt i modellen kan tilg˚as, afgører hvilke
slags views som er mulige at præsentere af modellen. Scene har kun en public metode, nemlig
nuance. Det er tydeligt, at hvis man betrageter str˚alesporing som systemets domæne,
begrænser man naturligvis mulige views. Men givet opgavens formulering
De faciliteter, som er nævnt i afsnit 4, angiver en minimal løsning. Det er denne
minimale løsning som skal konstrueres.
virker det som helt rimeligt at begrænse modellens tilgængelige data, p˚a denne m˚ade.
3.3.3 View
View delen af designet, er klassen Kamera. James Rumbaugh [3] opsummere meget præcist,
hvilket forhold view har til modellen
... views must know about [model] data (but not [model] operations).
Kamera klassen tager et billed af en Scene, som den modtager som parameter i sin metode
klik. For en nærmere beskrivelse af hvordan billedet tages (str˚alespores), henvises til
programmeringsovervejelserne.
Præsentation Viewet st˚ar for at visualiserere, eller p˚a anden m˚ade præsentere de data som
eksistere i den p˚agælgende model, hvortil viewet er tilknyttet. I vores designstruktur, eksistere
denne relation kun i den tid, det tager for billedet at tage sit billede. Dette forsimpler Kamera
klassen væsentligt, idet der ikke er nogen dynamiske forhold, at tage højde for. Kamera er
ogs˚a den klasse, som sørger for at uddata udskrives, omend selve udskrivningen sker i Kanvas
klassen.
3.3.4 Controller
Controller er den del af systemet, som er meget implementations specifik. Netop fordi Controlleren
h˚andterer inddata, f.eks. i form af en grafisk brugerflade, eller som til denne opgave,
i form af parsning af XML inddata.
Controller manifesteres i vores design, som klassen XMLParser.
Da Controlleren er implementationsafhænging, og ud over dette er meget specifik for
processen, er det en god ide, at lægge denne i toppen af et associationsdiagram, s˚aledes at
XMLParser afhænger af alt, men intet afhænger af XMLParser.
Denne konstruktion vil tillade at man let udskifter hvordan man bruger et program,
uden at det ville p˚avirke programmets domæneomr˚ade. Man kunne fx. ogs˚a forestille sig
at Controlleren var en grafisk brugerflade, hvor brugeren kunne specificere sin Scene som
brugeren ønskede.
13

3.3.5 Konklusion p˚a objektorienteret design
Det er helt klart at designet af systemet, er lykkedes godt. Problemdomænet er isoleret grundigt
i Scene, præsentation af data i Scene afbildes i klassen Kamera, mens det understøttende
kode, XMLParser og anden ind- og uddata, ligges øverst.
I vores design virker det logisk, at Scene formulere lyset (farven, set fra et punkt), mens
Kamera blot er passiv, og bare kigger i en retning, og optager det den ser. Kamera har ingen
indflydelse p˚a hvorledes billedet ser ud, præcis som i virkelig situation.
Det er dog vigtigt at sige, at dette kun er tilfældet, fordi vores Scene kun deler en type
af data. Hvis den tillod mere, kunne man sagtens forestille sig mere avancerede views.
3.3.6 Cyklisk process
Som en konsekvens af det objektorienterede design, kan programmet tydeligvis opbygges og
videreudvikles i en cyklisk process. Ved at begrænse os til at Scene deler en slags data,
forsimples meget af designet, og konstruktion af visse klasser gøres lettere (og/eller mindre).
Yderligere er det nemt at forestille sig, at man i første omgang definerer de basale klasser,
fx. Scene, og bygger der p˚a. Kamera derefter, og efterh˚anden tilføjer implementationer af figur
typer.
3.3.7 Det objektorienteret design af domænet
Det er ogs˚a interssant at kigge p˚a hvorledes objekterne i selve programmets problem domæne
forholder sig til hinanden.
Figur Figur er den superklasse, som alle andre repræsentationer af elementer i domænet
nedarver fra. Ideen med at Figur er superklassen er, at den definere alle de metoder, som er
nødvendige, for at lave de nødvendige udregninger. Som f.eks. skæringspunkt, farve (skygge),
osv. Det er de individuelle klasser (Kugle, Plan, Trekant), som st˚ar for implementationen af
den specifikke rumgeometriske udregning for den type figure.
Scene Scene er der hvor ansvaret for at styre hele den process, der ligger i at skulle lave
str˚alesporing. Den st˚ar ikke for selve genereringen af de korrekte data, men skal videresende,
eller udvælge de rigtige data.
Ved at ligge generering af data i klassen Figur kan Scene sørge for at modtage de korrekte
data, uden at skulle kende noget til de enkelte figureres specifikke implementation.
Vektor og Punkt Ideen med at indfører Vektor og Punkt klasser til repræsentation af
vektor og punkt information er fordi, de essentielt set internt kun opbevarer tre tal (i et
tre dimensionelt rum). Men istedet for at have disse tal i systemet som et tal array, hvor
betydningen kan være flertydig, alt efter sted og formel. S˚a kan der ikke være tvivl om hvad
inddata er, n˚ar der kommer en Vektor ind, modsat et Punkt.
3.3.8 Figur design
Et sidste aspekt af designet som vi mener er værd at kigge p˚a, er den m˚ade hvormed figurene
forholder sig internt mellem hinanden, og agreggere eller nedarver funktionalitet. Dette ses
iøvrigt tydeligt i bilag A.2.
14

Figur Klassen Figur er superklassen, som alle repræsentationer af elementer i domænet,
nedarver fra. Figur er en abstrakt klasse, som ikke kan instansieres. For at Scene vil arbejde
med en repræsentation af en type element i domænet, skal denne nedarve fra Figur (med
undtagelse af Punkt og Vektor).
Figur definere to abstrakte metoder findNormalvektor og skaeringspunkt. Klassen
definere ogs˚a en sidste konkret metode, nuance. Denne opdeling er kommet, fordi n˚ar først
en klasse har fundet det ramte punkt (hvis et s˚adant findes), og har udregnet normalvektoren
for dette punkt, s˚a er m˚aden hvor p˚a farven for dette punkt udregnes fælles for alle figurer.
Plan Plan klassen repræsentere et uendeligt plan i modellen.
Trekant Trekant klassen konstruere internt et plan, nemlig det plan, som trekantens tre
hjørner udspænder. Ideen med at aggregere en Plan i Trekant er at lave en hurtig udregning,
om en synslinie, overhovedet skære det samme plan, som trekanten ligger i.
Hvis en synslinie skærer det samme plan, som trekanten ligger i, s˚a kan man g˚a videre, og
se om det skæringspunkt, ligger inde i trekanten.
Mesh Mesh klassen, repræsentere et net af trekanter. Og dette er den faktiske repræsentation
af figuren, som internt vil have et array af klassen Trekant. I samme stil som Scene skal Mesh
blot holde styr p˚a sine Trekant medlemmer, og sende de rigtige data, tilbage til Scene.
Kugle Kugle klassen er lidt selvst˚aende, da den ikke deler funktionalitet med nogen anden
klassen, den nedarver blot fra Figur.
4 Programmeringsovervejelser
Dette afsnit vil diskutere, hvorledes implementationen af det objektorienterede design er mulig
i Java, og hvordan kritiske punkter omkring dette behandles. Slutteligt vil køretider for
programmet blive diskuteret.
4.1 Programstruktur
Da vores objektorienterede design er specificeret helt ned til detaljen af, hvilke klasser der
skal kunne hvad, og hvilken m˚ade metodekaldene sker p˚a kryds og tværs af klasserne, s˚a
vil denne diskussion forholde sig til, hvorvidt det er muligt at sammensætte programmet p˚a
denne m˚ade.
Overordnet Designet er ret ligetil at implementere, i Java. Der er intet ønske om at anvende
funktionalitet som ikke eksistere i Java, og Java vil ikke lægge nogen begrænsninger p˚a idéerne
bag designet.
Det funktionalitetsgenbrug som er ønsket i designet er fuldt ud muligt at implementere,
og ved steder - s˚asom at skabe nye figure - kan den ønskede fleksibilitet i designet faciliteres.
15

Datatyper Ser vi først p˚a de datastrukturer som ønskes anvendt, s˚a finder vi at de eneste
to egentlige datatyper som findes er Vektor og Punkt. Ved datatyper i denne forbindelse
forst˚as ”traditionelle”datatyper, ligesom f.eks. en talliste, som anvendes mellem programmets
klasser til overlevering af information, og ikke som funktionel programkode.
Efter programstart er den eneste nødvendige information, som klasserne imellem har brug
for at udveksle, er punkter og vektorer, ud over de sædvanlige Java definerede primitiver og
datatyper.
Databehandling Ser man p˚a det samspil som skal findes mellem klasserne, er et kritisk
punkt samspillet mellem Kamera og Scene, hvori det betragtes Scenes kald til dens objekter
af klassen Figur.
I Scene beregnes skæringspunkterne i selve figurerne, hvilket gør at ansvaret, med at finde
ud af hvilken formel der skal bruges til en specifik figur, bliver overladt til figuren.
Ligeledes overlades udregningen af normalvektoren til figurerne, hvilket ogs˚a gør at ansvaret
er overdraget til figurerne, som ogs˚a er de eneste som kan udføre udregningen.
Med disse to metoder defineret abstrakte, og dermed overladt til de klasser om nedarver
fra Figur, bliver den enkelte figur genereliseret og Scene kan h˚andtere dem ens, ligegyldigt
hvilken klasse der har nedarvet fra Figur.
Overordnet kunne man ogs˚a stille spørgsm˚al, om hvorvidt vektorregningen er p˚alidelig
til udregninger imellem klasserne i praksis. Det eneste problem som kan opst˚a ved dette -
bortset fra generelle systemfejl som overløb - er ved sammenligning af punkter. Analysen er
dog opmærksom p˚a dette.
4.2 Programkørsel
Her sker en gennemgang af hovedalgoritmen i programmet, med belysning af systemorienterede
løsninger p˚a de problemer, som blev behandlet i analysen.
Hovedalgoritmen er som følger:
• For hvert Kamera i Kameravinklers Kamera[] gøres følgende:
– For hver Vektor i Kameras Vektor[][] udregnes der hvilken nuance denne Vektor
skal give i billedet.
1. Beregn skæringspunkter mellem den linje udspændt af hver Vektor og oeje,
og s˚a alle figure i Scenes Figur[], og opbevare den figur og det skæringspunkt
som er tættest p˚a øjet. Ramte linjen overhovedet ingen figure returneres farven
sort, ellers næste trin.
2. Beregn skæringspunkter mellem den linje udspændt af solen og skæringspunktet
fra før, og alle figurer i Scenes Figur[]. Undersøg om det første skæringspunkt
p˚a linjen er det samme som det punkt der blev fundet i den tidligere
beregning. Er det ikke det samme punkt returneres farven sort, ellers næste
trin.
3. Find nuancen for det skæringspunkt p˚a den figur som blev ramt i første trin.
Placer denne nuance i billedet p˚a samme koordinat som vektoren har i Kameras
Vektor[][].
– Alle de fundne nuancer anbringes i Kanvas og udskrives til ppm format.
16

Fælles for alle af disse skridt er, at der for hver af dem er tilknyttet, et eller flere af de
problemer, som blev belyst i den problemorienterede analyse.
1. skridt N˚ar skæringspunkterne udregnes, skal vores valg om, at der ikke m˚a forekomme
noget mellem øjet og filmen tages i betragtning.
For hver af de Vektor objekter som findes i Kameras Vektor[][] og oeje udregnes der
hvilken værdi der skal indsættes i parameterfremstillingen for linjen (alts˚a t’s værdi i ligningen
(xs, ys, zs) = (xp, yp, zp) + (xv, yv, zv) · t), for at rammer hvert skæringspunkt p˚a linjen.
Da hver Vektor sammenlagt med oeje giver et punkt i filmen, er det oplagt at bestemme,
om et punkt kan ses af Kamera eller ej, ud fra værdien af t.
Derfor gælder der for udregningen af skæringspunkter, at t’s værdi skal være t > 1, 0. P˚a
denne m˚ade bliver der samtidig sørget for at skæringspunktet ikke ligger ligger før filmen eller
bag øjet. Se figur 4.2.
t < 0
Figur 4: t’s værdier relative til vektorens længde
pilotøje
0

Derfor er det nødvendigt at nedskalere Vektor’en mellem lyskilden og skæringspunktet
fra 1. skridt til længde 1, inden beregningerne fortsættes.
Ud af de t’er som kommer ud af beregningen, vælges det p t som er tættest p˚a 0, hvor
der gælder at t > 1.0. Det skæringspunkt som betragets som først ramt, er det punkt som
resulteres ved indsættelse af det mindste t i parameterfremstillingen.
Sammenligningen mellem de to punkter sker nu ved at fremstille et Vektor objekt med
disse punkter, og vurdere længden af dette.
Vi har valgt at længden 0.000001 betegner om to punkter i modellen er de samme. Denne
værdi er valgt ud fra emperiske undersøgelser med bla. den obligatoriske scene. Værdien er
p˚a ingen m˚ade nogen universel værdi, da den kun vurdere punkterne i forhold til scenen.
Beskriver en bruger alts˚a en scene med meget sm˚a tal, vil denne værdi m˚aske bevirke at
linjerne i billedet bliver uskarpe, da afstandene mellem figurer i rummet, kan være s˚a sm˚a i
forhold til værdien, at de bliver fejlvurderet. Alts˚a at to punkter der burde være forskellige,
bliver vurderet til at være de samme.
Ligeledes kan man forestille sig den omvendte effekt, ved operationer med meget store
talværdier. Alts˚a at et punkt bliver vurderet til at være to forskellige punkter.
En logisk fejl kan ogs˚a ske i dette skridt, i tilfælde af at solen ikke rammer noget punkt
overhovedet. Dette er en klar logisk fejl, da Vektor objektet jo som bekendt er skabt ud fra
et skæringspunkt mellem lyskilde og figur. Der kastes derfor en undtagelse da det anses som
en uoprettelig fejl, der vil give forkert uddata. Undtagelsen kan kun opst˚a ved at en figur er
placeret mindre en afstand 1 fra lyskilden, fordi solens vektor skaleres ned til 1.
3. skridt Ved nuanceberegning var det som sagt vigtigt, at figurens normalvektor peger
imod øjet for at formlen p˚a - [2] side 7 nederst - giver mening. Derfor undersøges, før en
normalvektor udvælges, hvilken vej den skal vende. Det gøres ved at sammenligne længden
p˚a to vektorer, som skabes mellem øjepunktet og normalvektoren set ud fra skæringspunktet,
og en vektor ligeledes skabt bortset fra at normalvektoren er inverteret. Den normalvektor
som returneres er den som indgik i den vektor, hvis længde var kortest. Se figur 4.2.
pilotøje
Figur 5: Udvælgelse af normalvektor
film
18
plan
normalvektor
inverteret normalvektor

4.2.1 Køretid for hovedalgoritmen
En køretid for algoritmen er svær at fastsl˚a præcist. Der er mange faktore som spiller ind,
helt ned til hvordan figurerne er placeret i scenen. F.eks. s˚a vil en scene, hvor alle figurerne er
placeret bag kameraet, have en køretid som er væsentlig hurtigere, end hvis alle figurerne var
placeret foran kameraet s˚a alle deres nuancer skulle udregnes. Antallet af beregning er derfor
svært at fastsl˚a.
En generelisering af køretiden, kunne basere sig p˚a de variabler i programmet som er
faste. Disse variabler er højden og bredden (h og b) som ønskes i uddata, da disse definere
hvor mange pixels der skal udregnes nuancer for. herudover er der antallet af figurer (n), og
slutteligt antallet af billeder/kameravinkler ønsket fra scenen k.
Den hurtigeste køretid som programmet kan opn˚ar er defineret til at være:
O (h1 · b1) + (h2 · b2) + . . . + (hk · bk) · n
Dette udledes af, at der for hver pixel i hvert billede, skal laves et gennemløb af alle figurer
i scenen. Som det ses s˚a er der kun en beregning for hver figur, og det betyder, at dette er
situationen, hvor ingen figurer i hele billedet, i alle billederne, er blevet ramt.
I værste tilfælde ville køretiden se s˚aledes ud:
O (h1 · b1) + (h2 · b2) + . . . + (hk · bk)
· n 2
Til forskel fra den hurtigeste køretid, s˚a indeholder denne et ekstra gennemløb, hvor der for
hvert skæringspunkt udregnes om lyskilden rammer punktet, ved et gennemløb af alle figurer.
5 Brugervejledning
Indlæsning Programmet køres med filen FlySimulator, som valgfrit kan tage kun en XMLfil
som argument. Hvis programmet ikke f˚ar et argument, prøver den at ˚abne en standardfil
ved navn lufthavn2.xml. Et kald af programmet vil se ud s˚aledes:
>java FlySimulator LaGuardia.xml
Argumentfilen skal ligge i samme mappe og den skal være i valid XML format, hvilket uddybes
herunder.
Uddata vil best˚a af et/flere billede(r) i .ppm filformat med samme navn som pilotsyns
id(er) angivet i XML, dette uddybes nedenunder.
Eksempel Nedenfor er et simpelt eksempel. Det indeholder de figurer som programmet kan
tegne:
19

5.1 Anvendelse af tags
Scene Inddata best˚ar først af en s˚akaldt tag, der beskriver hvilken XML-udgave vi bruger
og hvilket tegnsæt. Dernæst kommer -taggen, inden i dette beskrives selve scenen.
Generelt gælder det at XML-tags, der indeholder andre XML-tags, skrives p˚a formen
... evt andre tags...
Tags, der ikke indeholder andre tags, kan skrives som

pilotsyn Denne tag beskriver en øjenposition og retning. I selve -taggen angives
ogs˚a højden og bredden i pixels af det billede der skal udskrives. Der defineres ogs˚a 4 punkter
i . Det er pilotoeje der er øjepunktet, der ses fra. cockpitvindue stedpunkt er
det punkt fra hvilket udspændes. cockpitvindue lodret er den vektor, der svarer til biledets
lodrette retning. cockpitvindue_vandret er den vektor, der svarer til billedets vandrette
retning.
Alle disse punkter defineres vha. -taggen, og gives deres navn vha id-attributten,
dette vil ogs˚a blive navnet p˚a billedet. De tre koordinater skal betragtes som kommatal.
Der kan være arbitrært mange pilotsyn i en scene, og der genereres et billede for hvert
pilotsyn.
sol Denne tag beskriver solens position og farve. Positionen beskrives vha -taggen,
og er givet navnet position. Farven beskrives i -taggen, hvor r-attributten angiver
mængden af rødt, g-attributten mængden af grøn og b-attributten mængden af bl˚a. Alle tre
værdier løber mellem 0 og 255. Disse tal kan kun være heltallige.
kugle Denne tag beskriver en kugle i scenen. Den har et centrum, der angivet som et punkt
med navn centrum. Kuglen har ogs˚a farve, som angivet som beskrevet ovenfor. Kuglen har
ogs˚a en radius. Den angivet med -taggen der har attributten r der giver radius af
kuglen. Radius kan angives i kommatal.
mesh Denne tag beskriver et trekantsgitter. I hvert mesh angives først en punktliste over de
punkter, der indg˚ar i trekantsgitteret. Dernæst kommer en liste af trekanter hvor der i hver
trekant gives tre indeks ind i punktlisten som svarer til de punkter trekanten udspændes af.
Et mesh har ogs˚a farve, som angives som beskrevt ovenfor.
Punktlisten angives som en -tag inden i hvilken punkterne st˚ar defineret fortløbende.
har attributten antal punkter, der angiver hvor mange punkter der er i punktlisten.
Hvert punkt er givet et id, der svarer til hvilket nummer det er i punktlisten.
Trekantslisten angives som en -tag inden i hvilken punkterne st˚ar defineret
fortløbende. har en attribut antal trekanter, der angiver hvor mange punkter
der er i trekantslisten. En har attributter p1, p2 og p3, som angiver de tre
indeks(heltal) i punktlisten, hvor trekantens punkter kan findes.
plan Denne tag beskriver planer. Her menes der alts˚a planer med uendelige stor udstrækning.
En plan er givet ved et stedpunkt(dvs et punkt hvorfra planen udspændes) og to retningsvektorer,
som udspænder planen. Planen har ligesom de andre figurer en farve.
6 Programbeskrivelse
Programmet er skrevet til at blive oversat med Java version 1.4.0, og blive afviklet med samme
virtual machine.
Langt de fleste dele af programmet er nogenlunde simple, og indlysende. Hvor passende,
er der kommenteret. Vi henviser yderligere til de forskellige UML diagrammer i bilaget, for
en forst˚aelse af programstrukturen.
Idet følgende vil der komme en kort beskrivelse af de dele af programmet, som kan drage
nytte af en forklaring.
21

6.1 Kamera
Kamera klassen opbygger internt et gitter i attributten gitter. Her følger en forklaring af
hvordan dette gitter opfyldes med Vektor objekter. Gitteret fyldes, fra toppen, venstre mod
højre. P˚a figur 6 kan man se et eksempel p˚a hvorledes vektorene dannes. Læg dog mærke til
at i vores tilfælde peger l op, og v mod højre (i forhold til øjet), dette behøver naturligvis
ikke være tilfældet, men det letter forst˚aelsen.
Figur 6: En opstilling i Kamera klassen, for et billed med opløsning p˚a 6x6 pixels
pilotøje
step_l
l = cockpitvindue_lodret
s = cockpitvindue_stedpunkt
step_v
b = 6
v = cockpitvindue_vandret
Den primære ide er, først at beskrive gitterpunktet som et Punkt objekt. Herefter bruges
pilotoeje som punkt, og en vektor beskrives mellem gitterpunktet, og pilotøjet. Det er denne
vektor, som der skal str˚alespores ud af, og den gemmes i gitter arrayet.
step v og step l Disse to vektorer, beskriver det hop, som gitteret skal lave, hver gang
man ændre række eller søjle. Alle punkter i gitteret kan beskrives ud fra en kombination af
n ∗ step l + m ∗ step v. Da man kun skal lave n − 1 hop for at være n forskellige steder, derfor
subtraheres h og b begge med 1, n˚ar step l og step v skal udregnes.
For-løkken i Kamera klassen, gør følgende. Først bygges den lodrette vektor op, med koden
Vektor.skaler(step_l,h-(i+1)), dette tager step l, h-(i+1) gange. i er iteration nedover
rækkerne. Ved første gennemløb vil dette da give den fulde højde (l). Til denne lodrette
vektor ligges Vektor.skaler(step_v,i2), hvilket giver den vandrette vektor, i2 gange. i2
er iteration henover kollonnerne. Dette giver da en vektor, som g˚ar fra s til det gitter punkt
vi er n˚aet til. Vi laver s om til en vektor, og ligger den sammen med vektoren som gik fra s
til gitterpunktet. Denne vektor laves da om til et punkt.
22
h = 6

Herefter er det nemt at lave en vektor, som g˚ar fra p (pilotøje) til gitterpunktet med linien
gitter[i][i2] = Vektor.lavVektor(p,gitterPunkt).
Hvis en længde af billedet er en pixel, da sættes den p˚agældende step vektor ogs˚a til nul.
Dette betyder, at hvis man beder om et billed 1 højt, s˚a kommer vektorerne til at g˚a gennem
punkter, p˚a ligger ud af den akse, som v udspænder (se evt figur 6).
7 Afprøvning
Tankegangen bag denne afprøvningen er at dokumentere at vores program implementere en
simpel flysimulator vha. en str˚alesporer, og finde eventuelle fejl i vores program. Afprøvningen
er ekstern, alts˚a skal programmet betragtes som en ”blackbox”, forst˚aet p˚a den m˚ade, at vi kun
kan give inddata og analysere uddata, men ikke se hvordan programmet opfører sig internt.
Vi vil følgende liste alle krav til programmet, inddelt i ækvivalensklasser. Ækvivalensklasserne
deles op i emner. Dvs. en ækvivalensklasse har referencen eks. 2.b eller 1.a.
1. Krav fra opgaveformuleringen[2] og den problemorienterede analyse 2.
(a) Indlæse en fil i XML format.
(b) Opbygge scene udfra XML fil.
(c) Have kugler, trekanter og planer som grundformer
(d) Generere et farvebillede for hver flyposition.
(e) Lade lysstr˚ale komme fra en punktformig lyskilde.
(f) Gemme de genererede billeder i et filsystem.
(g) Genererer sekvensen af billeder der er beskrevet i bilag C i opgaveformuleringen.
2. Programmet skal vha teorien fra opgaveformuleringens [2] returnere de rigtige farve i
billedet.
(a) Programmet skal returnere den rigtige nuance for et givet punkt. Programmet skal
give samme resultat som de matematiske formler fra opgaveformuleringen[2]
3. Krav til opstilling i 3 dimensioner.
(a) Hvis en figur er placeret bagved øjet, skal den ikke med i billedet, men solen skal
tage den med i beregning af skygger.
(b) Hvis en figur omgiver øjepunktet, men ikke n˚ar ud forbi filmen, skal den ikke med
i billedet, men solen skal tage den med i beregning af skygger.
(c) Hvis en figur skærer filmen, skal det af figuren som befinder sig mellem øjet og
filmen ikke med i billedet, men solen skal stadig tage højde for det omr˚ade.
(d) Hvis en figur omslutter b˚ade øjet og filmen, skal det synlige omr˚ade af figuren kun
med hvis solen skinner p˚a det.
(e) Programmet skal kunne h˚andtere en scene uden nogle figurer.
(f) Programmet skal kunne h˚andtere at et plan ligger parallelt med synsretningen.
(g) Hvis solen skinner p˚a bagsiden af en figur, skal figuren være sort.
(h) Programmet skal kunne h˚andtere ekstreme talværdier, s˚asom 10 ∗ 10 16 .
23

(i) En sol skal kunne være inden i en figur, som skærer i filmen.
4. Krav til XML (vil blive uddybet i afsnit 7.4)
(a) Punkt
(b) Farve
(c) Placering af tags
(d) Rod tag
(e) Pilotsyn
(f) Sol
(g) Kugle
(h) Plan
(i) Trekant
(j) Mesh
Herunder vil de ovenst˚aende emner og deres individuelle ækvivalensklasser blive uddybet
og afprøvet.
7.1 Obligatoriske billeder
Da kravene i dette afsnit ikke er særlig specifikke vil vi betragte dem som opfyldt hvis programmet
kan udføre nedenst˚aende. Disse krav ligger ogs˚a til grund for at vi ikke vil afprøve
grænsetilfælde i dette afsnit.
Krav
1. Indlæse en fil i XML format.
2. Opbygge scene udfra XML fil.
3. Have kugler, trekanter og planer som grundformer
4. Generere et farvebillede for hver flyposition.
5. Lade lysstr˚ale komme fra en punktformig lyskilde.
6. Gemme de genererede billeder i et filsystem.
7. Generere sekvensen af billeder der er beskrevet i bilag C i opgaveformuleringen.
Inddata Som inddata vælges den obligatoriske XML fil.
Uddata Der forventes 3 billeder nøjagtig som XML beskriver dem. Se figur 7, 8 og 9
Resultat Kravene er opfyldt, programmet genererer billederne nøjagtig som de skal.
24

7.2 Matematisk udregning af nuance
Krav Programmet skal udregne nuancen korrekt per den matematiske model. Da udregningen
er ens for alle figurer og de tre forskellige grundfarver er en afprøvning nok til at afgøre
om kravet er opfyldt for alle figurer og farver. Vi vil dog opstille 4 forsøg for at n˚a nogle
grænsetilfælde i vinklen mellem solen og normalvektoren. Ens for alle 4 afprøvninger, benyttes
der et plan med farven (255,0,0) alts˚a helt rød. Udregningerne benytter denne formel:
solx∗
SolRGB ∗ fk ∗
nuance =
Nx+ soly∗ Ny+ solz∗ Nz
√ √
( solx) 2 +( soly) 2 +( solz) 2∗ ( Nx) 2 +( Ny) 2 +( Nz) 2
∗ F igurRGB
255
M˚aden vi har testet p˚a er at opstille en XML scene hvor billedet bliver nøjagtig 1x1 pixel
og hvor vi har kunne kontrollere vinklerne præcist. Programmets udregnede nuance er bestemt
gennem en farveanalyse(tegneprogram) af det genererede billede, vi har ikke inkluderet
uddata(1x1 pixel billederne) da dette ville være nytteløst.
Vinkel 0
• Inddata Vinklen mellem solen og normalvektoren vil her være 0 grader. Inddata kan
ses i bilag D.2
• Forventet Uddata
255 ∗ 1.0
Forventet farve (255,0,0)
• √
Vinkel 45
√ 0∗0+0∗0+−1∗−1 √
02 +02 +−12∗ 02 +02 +−12 255
∗ 255 = 255
• Inddata Vinklen mellem solen og normalvektoren vil her være 45 grader. Inddata kan
ses i bilag D.2
• Forventet Uddata
255 ∗ 1.0
Forventet farve (180,0,0)
• √
Vinkel 90
√ 0∗0+0∗1+−1∗−1 √
02 +02 +−12∗ 02 +12 +−12 255
∗ 255 = 180
• Inddata Vinklen mellem solen og normalvektoren vil her være 90 grader.
• Forventet Uddata Dette vil ikke være muligt da denne scene kræver at solvektoren
ligger parallel med planet og de vil derfor ikke skærer hinanden.
25

Vinkel 180
• Inddata Vinklen mellem solen og normalvektoren vil her være 180 grader.
• Forventet Uddata Dette vil ikke være muligt i virkeligheden.
7.3 Krav til opstilling i 3 dimensioner
Dette afsnit handler om kravene til hvordan figurer opfører sig n˚ar vi flytter rundt p˚a dem
i rummet. Det er umuligt at teste alle tilfælde da der er uendelig mange, og vi har allerede
vist et udsnit af de trivielle tilfælde i afprøvningen af den obligatoriske scene. Vi vil derfor
i dette afsnit prøve at ramme nogle grænser som ikke er berørt i den obligatoriske scene, og
som vi har opstillet krav til vores program skulle kunne h˚andtere. Disse grænser handler især
om hvad der sker n˚ar figurer kommer tættere p˚a filmen og øjet.
Vores uddata kan være problematisk at tolke, da det best˚ar af en 3-dimensionel scene som
konverteres til 2 dimensionel gr˚atonegengivelse, for at kunne printes. Derfor vil vi teste en
ækvivalensklasser af gangen, da uddata meget hurtigt kan blive uoverskueligt. Vi vil beskrive
kravet som testes, angive de karakteristiske egenskaber ved inddata og henvise til hvor de
kan findes, angive det forventede uddata og hvor det kan findes, og sidst angive om kravet er
opfyldt. Inddata er i XML format og er inkluderet i bilag D. Uddata er de XML beskrevede
scener i form af gr˚atonebilleder, som ogs˚a er inkluderet i bilag D. Vi har valgt at beskrive
disse afprøvninger i form af afsnit fremfor skemaer, da der medfølger en del forklarende tekst,
som ikke ville være hensigtsmæssig at placere i skemaer.
Test af ækvivalensklasse 3a
• Krav Hvis en figur er placeret bagved øjet, skal den ikke med i billedet, men solen skal
tage den med i beregning af skygger.
• Inddata En kugle der ligger bagved øjet og en kugle der ligger foran øjet, og et hvidt
plan. Inddata se bilag D.3.1.
• Forventet Uddata En skygge fra kuglen der ligger bagved øjet p˚a planet og p˚a en del
af kuglen der ligger foran øjet. Se figur 10
• Resultat Man kan se p˚a figur D.3.1 at kravet om at en kugle bag øjet skal kunne give
skygge men ikke selv være med p˚a billedet.
Test af ækvivalensklasse 3b
• Krav Hvis en figur omgiver øjepunktet, men ikke n˚ar ud forbi filmen, skal den ikke med
i billedet, men solen skal tage den med i beregning af skygger.
• Inddata En kugle(1) rundt om øjet som ikke n˚ar ud til filmen, og en kugle(2) foran
filmen. Inddata se bilag D.3.2.
26

• Forventet Uddata En skygge af kulge(1) p˚a planet. Kugle(2) skal være synlig med
skygge p˚a planet. Se figur 11
• Resultat Kravet er opfyldt, kuglen rundt om øjet er ikke med p˚a billedet, men afgiver
skygge.
Test af ækvivalensklasse 3c
• Krav Hvis en figur skærer filmen skal det af figuren som befinder sig mellem øjet og
filmen ikke med i billedet, men solen skal stadig tage højde for det omr˚ade.
• Inddata Kugle der skærer filmen med mindre en halvdelen bag. Inddata se bilag D.3.3.
• Forventet Uddata Kugle skal have et rundt sort omr˚ade, det skal være sort fordi solen
ikke kan skinne ind i kuglen da den rammer kuglen p˚a den del der er bag filmen. Se
bilag 12
• Resultat Kravet er opfyldt. Solen kan ikke skinne ind i kuglen ergo bliver det inde i
kuglen sort.
Test af ækvivalensklasse 3d
• Krav Hvis en figur omslutter b˚ade øjet og filmen, skal det synlige omr˚ade af figuren
med hvis solen skinner p˚a det.
• Inddata En kugle som omslutter øje, film og sol. En kugle foran filmen inden i den
omsluttende kugle. Inddata se bilag D.3.4.
• Forventet Uddata Skal kunne se indersiden af den store kugle. Den lille kugle skal ses
og skal kaste skygge p˚a indersiden af den store kugle. Se figur 13
• Resultat Kravet er opfyldt. Man kan se indersiden af kuglen som omslutter øjet og
filmen, da solen er inden i figuren.
Test af ækvivalensklasse 3e
• Krav Programmet skal kunne h˚andtere en scene uden nogle figurer.
• Inddata En scene uden nogle figurer. Inddata se bilag D.3.5.
• Forventet Uddata Et helt sort billede. Se figur 14
• Resultat Kravet er opfyldt, billedet bliver helt sort.
Test af ækvivalensklasse 3f
• Krav Programmet skal kunne h˚andtere, at et plan ligger parallelt med synsretningen.
• Inddata 3 planer sat op som et hjørne af et rum. En kugle til at give noget perspektiv.
Og et plan som ligger parallelt med synretningen. Inddata se bilag D.3.6.
• Forventet Uddata Hjørnet af et rum, med en kugle. Men uden spor af planet som
ligger parallelt med synsretningen. Se figur 15
• Resultat Kravet er opfyldt, der er intet spor af det parallele plan.
27

Test af ækvivalensklasse 3g
• Krav Hvis solen skinner p˚a bagsiden af en figur, i forhold til øjet, skal figuren være
sort.
• Inddata 2 kugler foran filmen, den ene næsten bagved den anden i forhold til øjet, og
en sol mellem kuglerne. Inddata se bilag D.3.7.
• Forventet Uddata Kuglen længst væk skal være synlig og skygge p˚a planet, kuglen
tættest p˚a skal være sort da solen ikke skinner p˚a den. Se figur 16
• Resultat Kravet er opfyldt, kuglen tættest p˚a er sort da solen skinner p˚a bagsiden.
Test af ækvivalensklasse 3h
• Krav Programmet skal kunne h˚andtere ekstreme talværdier, defineret ved starten af
afprøvningen, som input værdier.
• Inddata Et plan som er angivet med en ekstrem talværdi. Og en kugle til at give
perspektiv. Inddata se bilag D.3.8.
• Forventet Uddata En kugle der skygger p˚a et plan bagved. Se figur 17
• Resultat Kravet er opfyldt, programmet kan godt h˚andtere store tal. Denne afprøvning
har dog afsløret at udregningerne i programmet kan fejle, da det ses at planet er flimret.
Test af ækvivalensklasse 3i
• Krav En sol skal kunne være inden i en figur, som skærer i filmen.
• Inddata En stor kugle som skærer filmen med to sm˚a kugler inden i, og solen ligger i
den store cirkels centrum. Inddata se bilag D.3.9.
• Forventet Uddata Den skærende kugle skal have samme farve overalt indeni. De to
sm˚a kugler skal give skygge p˚a indersiden af den store kugle. Se figur 18
• Resultat Kravet er opfyldt.
7.4 XML krav
Vi vil her opstille nogle ækvivalensklasser for de krav vi har sat til XML’en. Vores program
skal efter hensigten stoppe og give en fejlmeddelelse hvis XML ikke er syntaktisk korrekt.
Beskeden skal s˚a vidt mulig angive hvilken type tag fejlen er fundet i, men er desværre ikke
istand til at angive hvor det tag befinder sig. Denne opbygning gør det ikke muligt at teste
for mere end et krav ad gangen. Vi vil i disse test forsøge at give programmet forkert inddata
f˚ar at se om det giver de passende fejlbeskeder. Vi vil tage den obligatoriske scene som bevis
for at vores program kan læse syntaktisk korrekt XML.
Til afprøvningerne vil vi bruge en template til inddata, dette skyldes at inddata vil ligne
denne template, med undtagelse i de linier hvor vi indsætter fejldata. Forskellen fra templaten
vil blive listet med linienummer i de følgende testafsnit under inddata. Der vil følge
en beskrivelse af egenskaberne ved inddata. Uddata vil best˚a af korte fejlbeskeder, disse vil
28

ogs˚a blive listet i afsnittet sammen med hvad vi forventede af uddata. Der vil være et √ hvis
afprøvningen forløb som forventet, hvis ikke vil det blive uddybet. N˚ar et tag er blevet testet,
vil det ikke blive testet igen, hvis det g˚ar igen under et andet tag.
Templaten er s˚aledes:
l1
l2
l3
l4
l5
l6
l7
l8
l9
l10
l11
l12
l13
l14
l15
l16
l17
l18
l19
l20
l21
l22
l23
l24
l25
l26
l27
l28
l29
l30
l31
l32
l33
l34
l35
l36
l37
Følgende test er stillet op denne m˚ade:
Krav specifikation
Karakteristiske egenskaber ved inddata.
29

Specifikke inddata, startende med det linienummer hvor data passer ind i templaten.
Forventet uddata og resultat
Uddata
Linien ”krav”kan godt indeholde flere krav og test af disse vil følge under med et lille mellemrum.
Krav: Punkt skal angives med x,y,z attributter med værdier angivet i tal (n/.n/n.n/n.)
Der mangler en attribut
l16
Forventer en fejlbesked om manglende attribut. √
XML fejl: ’s x/y/z attributter var ikke i korrekt format
X’s attribut bliver angivet i forkert format
l25
Forventer en fejlbesked om forkert format √
XML fejl: ’s x/y/z attributter var ikke i korrekt format
Krav: Farve skal angives med attributerne r,g,b og de skal angives i heltalsformat med værdier
0-255
Farves attribut r er kaldt t
l10
Forventer fejlbesked om farves attributter ikke er i rigtig format √
XML fejl: ’s r/g/b attributter var ikke i korrekt format
Farves r attribut er sat til værdi uden for grænsen
l10
Forventer en fejlbesked om værdi uden for grænse √
XML fejl: ’s r/g/b attributter var uden for 0-255
Krav: Rod tagget skal hedde scene
Vi har omdøbt scene tagget
l2 ¡rodsteward¿
l137 ¡/rodsteward¿
Forventer en fejlbesked om forkert XML format √
XML fejl: Rod-element skal være af type
30

Krav: Der skal være mindst et pilotsyn tag
Vi har fjernet pilotsyn tagget
l3
l4
l5
l6
l7
Vi forventer en fejlbesked om at der mangler et pilotsyn tag √
XML fejl: Der kræves mindst et pilotsyn.
Krav: Der m˚a kun være en sol i top niveau
Der er placeret en sol mere i top niveau
l38
l39
l40
l41
Der forventes en fejlbesked om der er for mange sole √
XML fejl: For mange
Krav: Programmet skal kunne acceptere 3 slags figurer. Kugle, mesh og plan.
Templaten indeholder alle 3 slags figurer. S˚a der er ikke nogle ændringer ved inddata Vi
forventer at programmet forløber uden problemer √
% af figur.ppm faerdig
0%-----------------------------------50%-----------------------------------100%
###############################################################################
Krav: Kugle skal have centrum (i punktformat), radius tag (med r attribut, som skal angives
positivt) og farve tag (farveformat)
Kugle tag mangler centrum
l35
Forventer fejlbesked om at der er for f˚a/mange punkt tag(centrum) √
XML fejl: For f˚a/mange
Kugle mangler farve tag
l34
31

Forventer fejlbesked om at der er for f˚a/mange farve tag. √
XML fejl: For f˚a/mange
Kugle mangler radius tag
l33
Forventer fejlbesked om for lidt/mange radius tag √
XML fejl: For f˚a/mange
Radius angivet som negativ værdi
l33
Der forventes fejlbesked om at radius er angivet forkert √
XML fejl: ’s r attribut i forkert format
Krav: Plan skal have 3 punkter. Punkterne skal have id ”stedpunkt”, ”retningsvektor1”og
”retningsvektor2”. Punktet, og de to vektorer, skal definere et plan.
Forkert id angivet
l15
Forventer fejlbesked om forkert id √
XML fejl: Forkert id attribut i
Angiver kun 2 punkt attributter
l15
Forventer en fejlbesked om for lidt/f˚a punkt attributter √
XML fejl: tillader kun 3 x
De 2 punkter ligger p˚a linie
l15
l16
l17
Forventer fejlbesked om at plan ikke definerer plan √
XML fejl: Vektorer og punktet i definere ikke et plan
To punkter ligger p˚a samme sted
l15
l16
l17
Forventer fejlbesked om at plan ikke definerer et plan √
XML fejl: Vektorer og punktet i definere ikke et plan
Krav: Mesh skal have ”punkter”tag som definerer "antal_punkter" vis værdi skal være
positivt heltal, dette antal skal passe overens med antallet af punkter. ”punkt”skal have id
32

med værdi 0 til antal punkt. Mesh skal have gyldig farve tag
Mesh mangler ”punkter”tagget
l21
Forventer fejlbesked om at punkter tagget mangler √
XML fejl: for f˚a/mange
Antallet af punkter stemmer ikke overens.
l21
Forventer fejlbesked om forkert antal punkter √
XML fejl: Ikke samstemmende antal punkter i
Antallet angivet i bogstaver
l21
Forventer fejlbesked om at antallet er angivet i forkert format √
XML fejl: ’s antal_punkter i forkert format
Ugyldig id værdi
l22
Forventer fejlbesked om at id er angivet forkert √
XML fejl: mangler id attribut,eller i forkert format
Mangler farve tag
l20
Forventer fejlbesked om manglende farve tag √
XML fejl: For mange/f˚a
Krav: Mesh’s Trekanter tag har følgende krav
• Skal have en attribut ”antal trekanter”, vis værdi er angivet i positive heltal.
• Skal have liges˚a mange ”trekant”tags som ”antal trekanter”angiver.
• ”trekant”skal have p1/p2/p3 attributter, disse skal have gyldige referencer til et punkt
id.
Mangler ”antal trekanter”attributten
l27
Forventer fejlbesked om at ”antal trekanter”mangler √
XML fejl: mangler antal_trekanter attribut
Antallet af ”trekanter”stemmer ikke overens med hvad angivet i ”antal trekanter”
l27
Forventer fejlbesked om at antallet ikke stemmer overens √
XML fejl: Ikke samstemmende antal trekanter i
33

Mangler en p1 attribut
l128
Forventer om fejlbesked om at en p? attribut mangler √
XML fejl: ’s p1/p2/p3 attribut mangler/forkert format
p1 refererer til ugyldig id
l128
Forventer fejlbesked om forkert reference/format √
XML fejl: ’s p1/p2/p3 attribut mangler/forkert format
Krav: Pilotsyn skal definere sine hoejde/bredde attributter, disse skal være positive heltal
med mindsteværdien 1. Desuden skal det have et unikt id. Pilotsyn skal definere 4 punkt
tag med følgende id, ”pilotoeje”, ”cockpitvindue stedpunkt”, ”cockpitvindue lodret”og ”cockpitvindue
vandret”. De tre sidste punkt tags skal definere et plan.
Pilotsyn definerer ikke hoejde
l3
Forventer fejlbesked om at hoejde ikke er angivet √
XML fejl: ’s hoejde/bredde ikke i korrekt format
Pilotsyn definerer hoejde med ugyldig værdi
l3
Forventer fejlbesked om at hoejde er angivt med forkert værdi √
XML fejl: ’s hoejde/bredde skal være positive
Pilotoeje har ikke unikt id
37
38
39
40
41
42
43
Forventer fejlbesked om at id ikke er unikt √
XML fejl: mangler unik id attribut
Pilotoeje definere ikke pilotoeje
l4
Forventer fejlbesked om at pilotsyn mangler √
XML fejl: Mangler i .
Krav: Sol m˚a kun indeholde et farve tag og et punkt tag
Sol indeholder 2 farve tags
l10.5
34

Forventer fejlbesked om for mange farve tags √
XML fejl: For mange/f˚a
Sol indeholder ikke noget punkt tag
l11
Forventer fejlbesked om mangel p˚a punkt tag √
XML fejl: For f˚a/mange
7.5 Konklusion
Afprøvningen viste hvad vi ogs˚a havde forventet og omtalt i afsnit 2, at n˚ar talværdier bliver
ekstremt store kan der være fejl i udregningen af nuancen. Derudover blev der fundet et par
stavefejl, men ellers forløb afprøvningen problemfrit. Ergo er alle vores krav opfyldt.
35

A UML diagrammer
A.1 Usecase diagram
Bruger Lav Billed
36
FlySimulator

A.2 Klassediagram
Kanvas
-kanvas : Color[][]
+setPixel()
+skrivPPM()
Kugle
1
KameraVinkler
-kamera : Kamera[]
+tagSerie(in Scene)
Kamera
-film : Kanvas
+klik(in Scene)
1..*
Figur er abstrakt, metoden
nuance er fælles for alle
klasserne her, mens de to
andre, er abstrakt defineret.
Plan
1
KameraVinkler bruger ikke
direkte Scene, men giver
den videre til Kamera
indeholder
37
Trekant
-figur : Figur[]
-sol : Sol
Scene
+nuance(in Punkt, in Vektor) : Color
1
0..*
Figur
+skaeringspunkt(in Vektor, in Punkt)
+nuance(in skæringspunkt : Punkt, in øje : Punkt, in Sol) : Color
+findNormalvektor(in Vektor, in Punkt)
0..*
1
Sol
-farve : Color
-punkt : Punkt
Mesh
-trekanter : Trekant[]

A.3 Sekvensdiagram
FlySimulator
new XMLParser(filsti:String)
s := hentScene()
KameraVinkler := hentKameraVinkler()
tagSerie(s)
XMLParser
XMLParser skaber Kamera
og Scene objektet, derfor
findes de først, når
XMLParser startes op
KameraVinkler Kamera
Scene
k = Kamera[]
er en attribut til
KameraVinkler
38
*[i := 0...k.length] klik(s)
h = højde af billed
b = bredde af billed
Er attributter
til Kamera
*[i:= 1...h, i:= 1...b] nuance(p,v) : Color
Color
Kanvas.skrivPPM
Udskrivning til PPM filformat
sker i klassen Kanvas, dette
er dog udeladt for simplicitet

A.4 Sekvensdiagram for Scene
Kamera Scene
nuance(Punkt øje, Vektor v) : Color
Hvis p er null, dvs, der ikke
blev fundet noget skææringspunkt,
returnere Scene
Ellers ses om der ligger noget
imellem Sol.position og p (skygge)
Hvis ikke, udregnes farven for p
* [i := 0...figur.length] p := skæringspunkt(Punkt øje, Vektor v)
[p == null] [p != null] s := lavVektor(Sol.position,p)
* [i := 0...figur.length] sk := skæringspunkt(Sol.position,s)
[sk != p] [sk==p] nuance(p,v,Sol) : Color
Farve udregning sker kun for
den figur som blev ramt.
Scene holder en reference
til denne figur.
39
Figur Vektor
findNormalvektor(p,v)

B CRC Kort
Denne section har de forskellige CRC kort som vi har lavet under udviklings processen.
Figur CRC kort
Figur
At levere de matematisk funktioner
og udregninger, som i forbindelse med
str˚alesporing, vil være ens for alle repræsentationer
af elementer i domænet
40
Vektor, enkelte nedarvede klasse (fx.
Kugle)

FlySimulator CRC kort
FlySimulator
At sørger for at argumentet til programmet
er korrekt, dvs. at der findes et filnavn,
som vi kan bruge som input
At sørger for at kaldet til XMLParser
sker, s˚aledes at Scene og KameraVinkler
bliver lavet
At sørger for at KameraVinkler starter
med at tegne billederne
41
XMLParser
KameraVinkler

Kamera CRC kort
Kamera
At opbygge de str˚aler, som der skal spores
Sørger for at de opbyggede vektorer bliver
str˚alesporet
Sørger for at de farver, som bliver
str˚aletsporet, bliver overgivet til Kanvas
klassen
42
Vektor
Scene
Kanvas

KameraVinkler CRC kort
Kamera
At holde styr p˚a alle de Kamera som er
blevet givet som input
At disse modtager et Scene objekt, og
give det videre til Kamera
43

Kanvas CRC kort
Kamera
At sørger for at udskrive et konkret billed,
i PPM format
44

Kugle CRC kort
Kugle
At sørger for at levere den nødvendige
kode, for at kunne udregne normal vektoreren
for denne type figur
Sørger for at man kan finde et skæringspunkt
i denne type figur
45
Vektor, Punkt
Vektor, Punkt

Plan CRC kort
Plan
At sørger for at levere den nødvendige
kode, for at kunne udregne normal vektoreren
for denne type figur
Sørger for at man kan finde et skæringspunkt
i denne type figur
46
Vektor, Punkt
Vektor, Punkt

Trekant CRC kort
Trekant
Sørger for at levere en normalvektor for Plan, Vektor, Punkt
trekanten.
Sørger for at kunne finde skæringspunkt Vektor, Punkt
47

Mesh CRC kort
Mesh
Sørger for at kunne levere en normalvektor
for et punkt p˚a meshet
Sørger for at man kan finde et skærings
punkt, givet en vektor og et punkt
48
Trekant, Vektor, Punkt
Trekant, Vektor, Punkt

Punkt CRC kort
Punkt
At opbevarer information omkring et
punkt
49

Scene CRC kort
Scene
At sørger for at holde styr p˚a sine figurer,
og solen
At kunne finde farven, for et punkt, givet
en vektor, og et punkt
50
Figur, Vektor, Punkt

Sol CRC kort
Sol
At opbevarer information omkring solen.
Stedpunkt og farve
51
Punkt, Color

Vektor CRC kort
Vektor
At opbevarer information omkring en
vektor
At levere de matematiske funktioner,
som omhandler vektor udregning
52

XMLParser CRC kort
XMLParser
At sørger for at instantiere de
ovenst˚aende elementer
At sørger for at inddata er korrekt. At
punkter til trekant fx. definere en trekant,
og at cockpitvindue definere et
plan
Vektor, Punkt
At fortælle om fejl XMLParseError
53

C XML specifikation
XML Specifikation
Tag Undertag Attributter
x,y,z og evt. id="navn"
r,g,b
r
p1,p2,p3
antal punkter="x"
...x
antal trekanter="x"
...x
id="navn"
id="xxx"
id="xxx"
id="xxx"
C.1 Krav til tags
Disse specifikationer er taget fra opgaveformuleringen[2]
Scene Inddata best˚ar først af en s˚akaldt tag, der beskriver hvilken XML-udgave vi bruger
og hvilket tegnsæt. Dernæst kommer -taggen, den starter med og ender med
, indenfor disse to beskrives selve scenen.
Generelt gælder det at XML-tags, der indeholder andre XML-tags, skrives p˚a formen
... andre tags....
Tags, der ikke indeholder andre tags, kan skrives som

Alle disse punkter defineres vha. -taggen, og gives deres navn vha id-attributten,
dette vil ogs˚a blive navnet p˚a billedet. De tre koordinater skal betragtes som kommatal.
Der kan være arbitrært mange pilotsyn i en scene, og der genereres et billede for hvert
pilotsyn.
sol Denne tag beskriver solens position og farve. Positionen beskrives vha -taggen,
og er givet navnet position. Farven beskrives i -taggen, hvor r-attributten angiver
mængden af rødt, g-attributten mængden af grøn og b-attributten mængden af bl˚a. Alle tre
værdier løber mellem 0 og 255. Disse tal kan kun være heltallige.
kugle Denne tag beskriver en kugle i scenen. Den har et centrum, der angivet som et punkt
med navn centrum. Kuglen har ogs˚a farve, som angivet som beskrevet ovenfor. Kulgen har
ogs˚a en radius. Den angivet med -taggen der har attributten r der giver radius af
kuglen. Radius skal angives i kommatal.
mesh Denne tag beskriver et trekantsgitter. I hvert mesh angives først en punktliste over de
punkter, der indg˚ar i trekantsgitteret. Dernæst kommer en liste af trekanter hvor der i hver
trekant gives tre indeks ind i punktlisten som svarer til de punkter trekanten udspændes af.
Et mesh har ogs˚a farve, som angives som beskrevt ovenfor.
Punktlisten angives som en -tag inden i hvilken punkterne st˚ar defineret fortløbende.
har attributten antal punkter, der angiver hvor mange punkter der er i punktlisten.
Hvert punkt er givet et id, der svarer til hvilket nummer det er i punktlisten.
Trekantslisten angives som en -tag inden i hvilken punkterne st˚ar defineret
fortløbende. har en attribut antal trekanter, der angiver hvor mange punkter
der er i trekantslisten. En har attributter pi, p2 og p3, som angiver de tre
indeks(heltal) i punktlisten, hvor trekantens punkter kan findes.
plan Denne tag beskriver planer. Her menes der alts˚a planer med uendelige stor udstrækning.
En plan er givet ved et stedpunkt(dvs et punkt hvorfra planen udspændes) og to retningsvektorer,
som udspænder planen. Planen har ligesom de andre figurer en farve.
55

D Afprøvningsdata
D.1 Obligatoriske billeder
Figur 7: Obligatoriske billede syn1
56

Figur 8: Obligatoriske billede syn2
57

Figur 9: Obligatoriske billede syn3
58

D.2 Data til matematisk udregning af nuance
Vinkel 0
Vinkel 45
59

D.3 Data til opstilling i 3 dimensioner
D.3.1 Test 3a
Inddata
Uddata
D.3.2 Test 3b
Inddata
60

Figur 10: Test 3a
61

Uddata
D.3.3 Test 3c
Inddata
Uddata
62

D.3.4 Test 3d
Inddata
Figur 11: Test 3b
63

Figur 12: Test 3c
64

Uddata
D.3.5 Test 3e
Inddata
Figur 13: Test 3d
65

Uddata
D.3.6 Test 3f
Inddata
Figur 14: Test 3e
66

Uddata
D.3.7 Test 3g
Inddata
67

Figur 15: Test 3f
68

Uddata
D.3.8 Test 3h
Inddata
Figur 16: Test 3g
69

Uddata
D.3.9 Test 3i
Inddata
70

Figur 17: Test 3h
71

Uddata
Figur 18: Test 3i
72

E Kildekode
E.1 Figur.java
0 import java . awt . Color ;
1
2 abstract public class Figur{
3 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
4 Figur . java
5
6 Figur ( Color farve , double r e f l e k t i o n s k o e f f i c i e n t )
7
8 Constructor t i l o p r e t t e l s e en Figur , hvor f a r v e er farven p˚a f i g u r e n og
9 r e f l e k t i o n s k o f f i c i e n t er r e f l e k t i o n s k o e f f i c i e n t e n f o r a l l e g r u n d f a r v e r .
10
11 a b s t r a c t Vektor findNormanvektor ( Punkt skaeringspunkt , Punkt o e j e )
12
13 r e t u r n e r e normalvektoren i f o r h o l d a f f i g u r e n , som a l t i d peger imod kameraet ,
14 hvor s k a e r i n g s p u n k t er det s k æ r i n g s p u n k t e t mellem den a k t u e l l e g i t t e r v e k t o r
15 og ø j e t f r a kameraet , og o e j e er ø j t f r a kameraet .
16
17 a b s t r a c t Punkt s k a e r i n g s p u n k t ( Vektor g i t t e r v e k t o r , Punkt o e j e )
18
19 r e t u r n e r e s k æ r i n g s p u n k t e t mellem f i g u r e n og den l i n j e som den a k t u e l l e
20 g i t t e r v e k t o r og ø j e t f r a kameraet udgør .
21
22 Color nuance ( Punkt skaeringspunkt , Punkt oeje , Sol s o l )
23
24 r e t u r n e r e e t Color o b j e k t som i n d e h o l d e r den f a r v e som f i g u r e n har i
25 skaeringspunkt , hvor o e j e er ø j e t f r a kameraet og s o l er s o l e n f r a Scene .
26
27 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
28
29 // F i e l d s
30 protected f i n a l Color f a r v e ;
31 protected f i n a l double r e f l e k t i o n s k o e f f i c i e n t ;
32 public static double r e f l e k t i o n s k o e f f i c i e n t D e f a u l t = 1 ;
33
34 // Constructors
35 Figur ( Color farve , double r e f l e k t i o n s k o e f f i c i e n t ){
36 this . f a r v e = f a r v e ;
37 this . r e f l e k t i o n s k o e f f i c i e n t = r e f l e k t i o n s k o e f f i c i e n t ;
38 }
39 // Methods
40 abstract public Vektor findNormalvektor ( Punkt skaeringspunkt , Punkt o e j e ) ;
41 abstract public Punkt skaeringspunkt ( Vektor g i t t e r v e k t o r , Punkt o e j e ) ;
42
43 public Color nuance ( Punkt skaeringspunkt , Punkt oeje , Sol s o l ){
44 // f i n d e r normalvektoren t i l f i g u r e n .
45 Vektor normalvektor = findNormalvektor ( skaeringspunkt , o e j e ) ;
46
47 // v e k t o r mellem s k a e r i n g s p u n k t og l y s k i l d e
48 Vektor p T i l S o l = Vektor . lavVektor ( skaeringspunkt , s o l . p o s i t i o n ) ;
73

49
50 // Cos ( v i n k e l ) mellem normalvektor og p T i l S o l
51 double cosVinkel = Vektor . skalarprodukt ( pTilSol , normalvektor ) /
52 ( Vektor . laengde ( p T i l S o l ) ∗ Vektor . laengde ( normalvektor ) ) ;
53
54 // er cosVinkel < 0 , s˚a er punktet ramt b a g f r a i f o r h o l d t i l ø j e t og
55 // der er d e r f o r i skygge .
56 i f ( cosVinkel < 0){
57 return Color . black ;
58 }
59
60 // udregner l y s i n t e n s i t e t e n f o r hver f a r v e v æ r d i udfra formlen
61 // f r a o p g a v e t e k s t e n s i d e 7 , n e d e r s t .
62 double l y s i n t e n s i t e t R = ( s o l . f a r v e . getRed ( ) / 2 5 5 ) ∗
63 r e f l e k t i o n s k o e f f i c i e n t ∗ cosVinkel ;
64
65 double l y s i n t e n s i t e t G = ( s o l . f a r v e . getGreen ( ) / 2 5 5 ) ∗
66 r e f l e k t i o n s k o e f f i c i e n t ∗ cosVinkel ;
67
68 double l y s i n t e n s i t e t B = ( s o l . f a r v e . getBlue ( ) / 2 5 5 ) ∗
69 r e f l e k t i o n s k o e f f i c i e n t ∗ cosVinkel ;
70
71 // udregner grundfarverne i punktet .
72 int R = ( int ) ( f a r v e . getRed ( ) ∗ l y s i n t e n s i t e t R ) ;
73 int G = ( int ) ( f a r v e . getGreen ( ) ∗ l y s i n t e n s i t e t G ) ;
74 int B = ( int ) ( f a r v e . getBlue ( ) ∗ l y s i n t e n s i t e t B ) ;
75
76 // r e t u r n e r e nuancen i punktet .
77 return new Color (R, G, B) ;
78 }
79 }
74

E.2 FlySimulator.java
0 import java . i o . IOException ;
1
2 public class FlySimulator {
3 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
4 FlySimulator . java
5
6 s t a t i c void main ( S t r i n g args [ ] )
7
8 Indgangs punkt .
9
10 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
11 public static void main ( S t r i n g [ ] a ) {
12 S t r i n g x m l f i l = null ;
13 i f ( a . length > 1) {
14 System . out . p r i n t l n ( ”\ tFor mange argumenter \n\n” +
15 ”\ tKorrekt brug : \ n” +
16 ”\ t j a v a FlySimulator xmlFilNavn \n\n” +
17 ”\ txmlFilNavn er s t i e n p˚a XML input f i l e n , ”+
18 ” angives i n t e t \n\targument , bruges ”+
19 ”\” lufthavn2 . xml \” som input f i l . ”
20 ) ;
21 System . e x i t ( 0 ) ;
22 } else i f ( a . length == 1) {
23 x m l f i l = a [ 0 ] ;
24 } else {
25 x m l f i l = ” lufthavn2 . xml” ;
26 }
27 try {
28 XMLParser p = new XMLParser( x m l f i l ) ;
29 Scene scene = p . hentScene ( ) ;
30 KameraVinkler kamera = p . hentKameraVinkler ( ) ;
31 kamera . t a g S e r i e ( scene ) ;
32 } catch ( XMLParseError exn ) {
33 System . out . p r i n t l n ( ”XML f e j l : ” + exn . getMessage ( ) ) ;
34 } catch ( IOException exn ) {
35 System . out . p r i n t l n ( ” F i l f e j l : ” + exn . getMessage ( ) ) ;
36 } catch ( RuntimeException exn ) {
37 // kan b l i v e k a s t e t f r a scene , s k u l l e dog i k k e ske
38 System . out . p r i n t l n ( ” Programfejl : ” + exn . getMessage ( ) ) ;
39 }
40 }
41 }
75

E.3 Kamera.java
0 import java . awt . Color ;
1 import java . i o . IOException ;
2
3 public class Kamera {
4 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
5 Kamera . java
6
7 Kamera ( Punkt p , Punkt s , Vektor l , Vektor v , i n t h , i n t b , S t r i n g f i l )
8
9 Constructor t i l o p r e t t e l s e a f e t kamera . p er øjepunkt . Filmen dannes
10 ud f r a Vektor l , v , s ( l o d r e t , vandret , s t e d p u n k t ) . h x b = højde x bredde
11 f i l er navnet , p˚a f i l e n , som det e n d e l i g e b i l l e d gemmes i .
12
13 void k l i k ( Scene scene )
14
15 Tager b i l l e d , og gemmer i f i l .
16
17 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
18
19 // f i e l d s
20 private Punkt p ; // punkt , ø j e
21 private Punkt s ; // s t e d p u n k t
22 private Vektor l ; // l o d r e t v e k t o r
23 private Vektor v ; // vandret v e k t o r
24 private int h ; // højde a f b i l l e d
25 private int b ; // bredde a f b i l l e d
26 private S t r i n g f i l ; // f i l n a v n som der s k a l gemmes ned i
27
28 // d i s s e bruges t i l at holde s t y r p˚a procent baren
29 private int antalPunkterBehandlet ;
30 private double procentAfPunkter ;
31 private int konsolBredde = 79;
32 private int konsolIndex = 0 ;
33 private int k o n s o l S i d s t = 0 ;
34
35 private Kanvas f i l m ; // h o l d e r f o r b i l l e d e
36
37 // g i t t e r som i n d e h o l d e r a l l e v e k t o r e r der s k a l spores
38 private Vektor [ ] [ ] g i t t e r ;
39 private Vektor s t e p l ; // s k r i d t hen a f l o d r e t vektoren , f o r hver p i x e l
40 private Vektor s t e p v ; // s k r i d t hen a f vandret vektoren , f o r hver p i x e l
41
42 // constructor , kun en c o n s t r u c t o r t i l Kamera
43 public Kamera( Punkt p , Punkt s , Vektor l , Vektor v ,
44 int h , int b , S t r i n g f i l ) {
45
46 this . p = p ;
47 this . s = s ;
48 this . l = l ;
49 this . v = v ;
50 this . h = h ;
76

51 this . b = b ;
52 this . f i l = f i l ;
53
54 antalPunkterBehandlet = 0 ;
55 procentAfPunkter = 1 0 0 . 0 / ( h ∗ b ) ;
56
57 g i t t e r = new Vektor [ h ] [ b ] ;
58 f i l m = new Kanvas (h , b , Color . black ) ;
59
60 // h v i s b/h er ligmed en , s k a l der t a g e s nogle s æ r l i g e f o r h o l d ,
61 // s˚a l e d e s at g i t t e r punkterne kommer t i l at l i g g e r i g t i g t .
62 i f ( h == 1){
63 s t e p l = new Vektor ( 0 , 0 , 0 ) ;
64 } else {
65 h−−;
66 s t e p l = new Vektor ( l . x / ( h ) , l . y / h , l . z / ( h ) ) ;
67 h++;
68 }
69
70 i f ( b == 1) {
71 s t e p v = new Vektor ( 0 , 0 , 0 ) ;
72 } else {
73 b−−;
74 s t e p v = new Vektor ( v . x / ( b ) , v . y / b , v . z / ( b ) ) ;
75 b++;
76 }
77
78 // se e v t . program b e s k r i v e l s e f o r y d e r l i g e r e d e t a l j e r .
79 for ( int i = 0 ; i < h ; i ++){
80 /∗ i n d r e r l ø k k e s t a r t ∗/
81 for ( int i 2 = 0 ; i 2 < b ; i 2++){
82 Punkt gitterPunkt = Vektor . t i l P u n k t (
83 Vektor . adder (
84 Vektor . lavVektor ( s ) ,
85 Vektor . adder (
86 Vektor . s k a l e r ( s t e p l , h−( i +1)) ,
87 Vektor . s k a l e r ( step v , i 2 )
88 )
89 )
90 ) ;
91 g i t t e r [ i ] [ i 2 ] = Vektor . lavVektor (p , gitterPunkt ) ;
92 }
93 /∗ i n d r e r l ø k k e s l u t ∗/
94 }
95 }
96
97 private void updaterBar ( ) {
98 int konsolNu = ( int ) Math . round ( 0 . 7 9 ∗
99 ( procentAfPunkter ∗ antalPunkterBehandlet ) ) ;
100
101 int k o n s o l D i f f = Math . abs ( k o n s o l S i d s t − konsolNu ) ;
102
103 while (−− k o n s o l D i f f > −1) {
77

104 System . out . p r i n t ( ”#” ) ;
105 }
106 k o n s o l S i d s t = konsolNu ;
107 }
108
109 public void k l i k ( Scene scene ) {
110 System . out . p r i n t l n ( ”% a f ” + f i l + ” . ppm f a e r d i g ” ) ;
111 System . out . p r i n t l n ( ”0%−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−50”+
112 ”%−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−−100%” ) ;
113
114 for ( int i = 0 ; i < h ; i ++) {
115 for ( int j = 0 ; j < b ; j ++) {
116 Color c = scene . nuance (p , g i t t e r [ i ] [ j ] ) ;
117 f i l m . s e t P i x e l ( j , i , c ) ;
118 antalPunkterBehandlet++;
119 updaterBar ( ) ;
120 }
121 }
122 try {
123 f i l m . skrivPPM( f i l ) ;
124 System . out . p r i n t l n ( ”\n” + f i l +
125 ” . ppm s k r e v e t t i l f i l \n” ) ;
126 }
127 catch ( IOException exn ) {
128 System . out . p r i n t l n ( ” F e j l ved udskrivning a f b i l l e d e : ” +
129 exn . getMessage ( ) + ”\n” ) ;
130 }
131 }
132 }
78

E.4 KameraVinkler.java
0 public class KameraVinkler {
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 KameraVinkler . java
3
4 KameraVinkler(Kamera [ ] kamera )
5
6 Constructor t i l o p r e t t e l s e a f e t KameraVinkler o b j e k t .
7
8 void t a g S e r i e ( Scene scene )
9
10 Tager a l l e kamera o b j e k t e r , og t a g e r e t b i l l e d a f scene , g i v e t
11 de f o r s k e l l i g e synspunkter .
12
13 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
14 private Kamera [ ] kamera ;
15
16 public KameraVinkler ( Kamera [ ] kamera ) {
17 this . kamera = kamera ;
18 }
19
20 public void t a g S e r i e ( Scene scene ) {
21 for ( int i = 0 ; i < kamera . length ; i ++) {
22 kamera [ i ] . k l i k ( scene ) ;
23 }
24 }
25 }
79

E.5 Kanvas.java
0 import java . awt . ∗ ;
1 import java . i o . ∗ ;
2
3 public class Kanvas{
4 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
5 Kanvas . java
6
7 Kanvas k l a s s e n er i k k e ændret i f o r h o l d t i l den u d l e v e r e d e form .
8 Kun h e n v i s n i n g e r t i l S t ø r r e l s e s f e j l er ændret , p l u s k l a s s e n
9 er f j e r n e t f r a packege k2 .
10
11 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
12 private Color [ ] [ ] kanvas ;
13 private int højde = 0 ;
14 private int bredde = 0 ;
15 private int a n t a l B i l l e d e r = 1 ;
16
17 public Kanvas ( int højde , int bredde , int gr˚atone )
18 {
19 this ( højde , bredde , new Color ( gr˚atone , gr˚atone , gr˚atone ) ) ;
20 }
21
22 public Kanvas ( int højde , int bredde , int rød , int grøn , int bl˚a )
23 {
24 this ( højde , bredde , new Color ( rød , grøn , bl˚a ) ) ;
25 }
26
27 // The c o n s t r u c t o r doing something .
28
29 public Kanvas ( int højde , int bredde , Color f a r v e )
30 {
31 højde = højde ;
32 bredde = bredde ;
33 kanvas = new Color [ højde ] [ bredde ] ;
34 setBaggrund ( f a r v e ) ;
35 }
36
37 public void setBaggrund ( int gr˚atone )
38 {
39 setBaggrund (new Color ( gr˚atone , gr˚atone , gr˚atone ) ) ;
40 }
41
42 public void setBaggrund ( int rød , int grøn , int bl˚a )
43 {
44 setBaggrund (new Color ( rød , grøn , bl˚a ) ) ;
45 }
46
47 public void setBaggrund ( Color f a r v e )
48 {
49 for ( int i = 0 ; i < højde ; i ++)
50 for ( int j = 0 ; j < bredde ; j++)
80

51 kanvas [ i ] [ j ] = f a r v e ;
52 }
53
54 public void s e t P i x e l ( int x , int y , int gr˚atone )
55 {
56 s e t P i x e l ( x , y , new Color ( gr˚atone , gr˚atone , gr˚atone ) ) ;
57 }
58
59 public void s e t P i x e l ( int x , int y , int rød , int grøn , int bl˚a )
60 {
61 s e t P i x e l ( x , y , new Color ( rød , grøn , bl˚a ) ) ;
62 }
63
64 public void s e t P i x e l ( int x , int y , Color f a r v e )
65 {
66 kanvas [ y ] [ x ] = f a r v e ;
67 }
68
69 public Color g e t P i x e l ( int x , int y )
70 {
71 return kanvas [ x ] [ y ] ;
72 }
73
74 public void mix ( Kanvas k )
75 {
76 i f ( ( højde ! = k . højde ) | | ( bredde ! = k . bredde ) )
77 throw new S t o e r r e l s e s f e j l ( ” B i l l e d e r ikke samme s t ø r r e l s e ” ) ;
78 for ( int i = 0 ; i < højde ; i ++)
79 for ( int j = 0 ; j < bredde ; j ++)
80 kanvas [ i ] [ j ] =
81 new Color ( ( kanvas [ i ] [ j ] . getRed ( ) ∗ a n t a l B i l l e d e r +
82 k . g e t P i x e l ( i , j ) . getRed ( ) ) / ( a n t a l B i l l e d e r + 1) ,
83 ( kanvas [ i ] [ j ] . getGreen ( ) ∗ a n t a l B i l l e d e r +
84 k . g e t P i x e l ( i , j ) . getGreen ( ) ) / ( a n t a l B i l l e d e r + 1) ,
85 ( kanvas [ i ] [ j ] . getBlue ( ) ∗ a n t a l B i l l e d e r +
86 k . g e t P i x e l ( i , j ) . getBlue ( ) ) / ( a n t a l B i l l e d e r + 1 ) ) ;
87 a n t a l B i l l e d e r ++;
88 }
89
90
91 public void skrivPPM( S t r i n g f i l n a v n ) throws IOException
92 {
93 PrintWriter u d f i l = new PrintWriter (new F i l e W r i t e r ( f i l n a v n+” .ppm” ) ) ;
94 Color p i x e l ;
95
96 u d f i l . p r i n t l n ( ”P3” ) ;
97 u d f i l . p r i n t l n ( bredde + ” ” + højde ) ;
98 u d f i l . p r i n t l n ( ”255” ) ;
99 u d f i l . p r i n t l n ( ) ;
100
101 for ( int i = 0 ; i < højde ; i++)
102 for ( int j = 0 ; j < bredde ; j++)
103 {
81

104 p i x e l = kanvas [ i ] [ j ] ;
105 u d f i l . p r i n t l n ( p i x e l . getRed ( ) + ” ” + p i x e l . getGreen ( ) + ” ” +
106 p i x e l . getBlue ( ) ) ;
107 }
108 u d f i l . c l o s e ( ) ;
109 }
110
111 public static void main ( S t r i n g [ ] args )
112 {
113 System . out . p r i n t l n ( ”\n\nINTERN AFPRØVNING AF: K2/Kanvas\n\n” ) ;
114
115 Kanvas t0 = new Kanvas ( 2 0 , 1 0 , 4 2 ) ;
116 // t r y { t0 . skrivPPM (” t0 ” ) ; }
117 // catch ( IOException e ) { System . out . p r i n t l n ( e ) ; }
118 System . out . p r i n t l n ( ” Ikke−k v a d r a t i s k kanvas o p r e t t e t . ” ) ;
119
120 Kanvas t1 = new Kanvas ( 2 0 , 2 0 , 1 2 7 ) ;
121 System . out . p r i n t l n ( ” g e t P i x e l c e n t e r + gr˚a konstruktør : ” +
122 t1 . g e t P i x e l ( 1 0 , 1 0 ) . e q u a l s
123 (new Color ( 1 2 7 , 1 2 7 , 1 2 7 ) ) ) ;
124
125 Kanvas t2 = new Kanvas ( 2 0 , 2 0 , 0 , 1 0 , 2 5 5 ) ;
126 System . out . p r i n t l n ( ” Getpixel h j ø r n e r + t r e t a l s k o n s t r u k t ø r : ” +
127 t2 . g e t P i x e l ( 1 9 , 0 ) . e q u a l s ( t2 . g e t P i x e l ( 0 , 1 9 ) ) ) ;
128
129 Kanvas t3 = new Kanvas ( 2 0 , 2 0 , new Color ( 2 5 5 , 2 5 5 , 2 5 5 ) ) ;
130 System . out . p r i n t l n ( ” f a r v e k o n s t r u k t ø r + c o l o r maxværdi : ” +
131 t3 . g e t P i x e l ( 1 0 , 1 0 ) . e q u a l s (new Color ( 2 5 5 , 2 5 5 ,
132 2 5 5 ) ) ) ;
133 t3 . setBaggrund ( 1 2 7 ) ;
134 System . out . p r i n t l n ( ”Gr˚a baggrund : ” +
135 t3 . g e t P i x e l ( 1 0 , 1 0 ) . e q u a l s (new Color ( 1 2 7 , 1 2 7 ,
136 1 2 7 ) ) ) ;
137
138 t3 . setBaggrund ( 1 2 7 , 1 2 8 , 1 2 9 ) ;
139 System . out . p r i n t l n ( ” t r e t a l s b a g g r u n d : ” +
140 t3 . g e t P i x e l ( 1 0 , 1 0 ) . e q u a l s (new Color ( 1 2 7 , 1 2 8 ,
141 1 2 9 ) ) ) ;
142
143 t3 . setBaggrund (new Color ( 1 , 2 , 3 ) ) ;
144 System . out . p r i n t l n ( ” farvebaggrund : ” +
145 t3 . g e t P i x e l ( 1 0 , 1 0 ) . e q u a l s (new Color ( 1 , 2 ,
146 3 ) ) ) ;
147
148 System . out . p r i n t l n ( ”\n\nGammelsmølf er en f a l l e r e t h a v e n i s s e . \ n\n” ) ;
149
150 t2 . s e t P i x e l ( 0 , 1 9 , 1 2 7 ) ;
151 t2 . s e t P i x e l ( 1 9 , 0 , 1 2 0 , 1 3 0 , 1 4 0 ) ;
152 t2 . s e t P i x e l ( 1 0 , 1 0 , new Color ( 0 , 0 , 0 ) ) ;
153
154 System . out . p r i n t l n ( ” s e t P i x e l hjørne og center , c o l o r minværdi : ”
155 + ( t2 . g e t P i x e l ( 0 , 1 9 ) .
156 e q u a l s (new Color (127 , 127 , 127)) &&
82

157 t2 . g e t P i x e l ( 1 9 , 0 ) .
158 e q u a l s (new Color (120 , 130 , 140)) &&
159 t2 . g e t P i x e l ( 1 0 , 1 0 ) .
160 e q u a l s (new Color ( 0 , 0 , 0 ) ) ) ) ;
161
162 System . out . p r i n t l n ( ”WriteBMP a f p r ø v e s ikke . Denne afprøvning ” +
163 ” f o r s ø g e r at undg˚a at bruge d i s k . ” ) ;
164
165 try
166 { t2 . s e t P i x e l ( 1 0 , 1 0 , 2 5 6 ) ; }
167 catch ( IllegalArgumentException e )
168 { System . out . p r i n t l n ( ” F a r v e f e j l f a n g e t : ” + e ) ; }
169
170 try
171 { t2 . s e t P i x e l ( 1 0 , 2 0 , 2 5 5 ) ; }
172 catch ( ArrayIndexOutOfBoundsException e )
173 { System . out . p r i n t l n ( ” I n d e x f e j l f a n g e t : ” + e ) ; }
174
175 /∗ T i l s t a n d l i g e nu :
176 t1 −− ren ( 1 2 7 , 1 2 7 , 1 2 7 )
177 t2 −− ( 0 , 1 0 , 2 5 5 ) med
178 ( 0 , 1 9 ) = ( 1 2 7 , 1 2 7 , 1 2 7 )
179 ( 1 9 , 0 ) = ( 1 2 0 , 1 3 0 , 1 4 0 )
180 ( 1 0 , 1 0 ) = ( 0 , 0 , 0 )
181 t3 −− ren ( 1 , 2 , 3 )
182 ∗/
183
184 t1 . mix ( t2 ) ;
185 t1 . mix ( t3 ) ;
186
187 /∗
188 t r y
189 {
190 t1 . skrivPPM (” t1 ” ) ;
191 t2 . skrivPPM (” t2 ” ) ;
192 t3 . skrivPPM (” t3 ” ) ;
193 }
194 catch ( IOException e )
195 { System . out . p r i n t l n ( e ) ; }
196
197 ∗/
198
199 System . out . p r i n t l n ( ” Billedmix : ” +
200 t1 . g e t P i x e l ( 7 , 7 ) . e q u a l s (new Color ( 4 2 , 4 6 ,
201 1 2 8 ) ) ) ;
202
203
204 /∗ Ekstern afprøvning . Skal l a v e 1 0 høj , 3 0 bred kanvas , med
205 p r i k i ( 9 , 1 ) , dvs . p˚a n æ s t ø v e r s t e l i n i e . ∗/
206
207 Kanvas t4 = new Kanvas ( 1 0 , 3 0 , 2 0 0 ) ;
208 t4 . s e t P i x e l ( 9 , 1 , 0 ) ;
209 /∗ t r y { t4 . skrivPPM (” t4 ” ) ; }
83

210 catch ( IOException e ) { } ; ∗/
211
212
213 }
214
215 }
84

E.6 Kugle.java
0 import java . awt . Color ;
1
2 public class Kugle extends Figur{
3 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
4 Kugle . java
5
6 Kugle ( Punkt centrum , double radius , Color f a r v e )
7
8 Constructor s æ t t e r k u g l e n s r e f l e k t i o n s k o e f f i c i e n t t i l
9 d e f a u l t v æ r d i e n a n g i v e t i Figur k l a s s e n
10
11 Kugle ( Punkt centrum , double radius , Color farve , double r e f l e k t i o n s k o e f f i c i e n t )
12
13 Constructor s æ t t e r k u g l e n s r e f l e k t i o n s k o e f f i c i e n t t i l
14 parameteren r e f l e k t i o n s k o e f f i c i e n t , som a n g i v e s f r a 0 t i l 1 .
15
16 Vektor findNormalvektor ( Punkt skaeringspunkt , Punkt o e j e )
17
18 Finder normalvektoren f o r en k u g l e i s k æ r i n g s p u n k t e t
19 mellem kuglen og l i n i e n .
20
21 Punkt s k a e r i n g s p u n k t ( Vektor vektor , Punkt o e j e ) {
22
23 Udregner e v e n t u e l l e skæringspunkter mellem kuglen og l i n i e n
24 d e f i n e r e t a f parametrene v e k t o r og o e j e .
25
26 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
27 // f i e l d s
28 private Punkt centrum ; // Kuglens centrum
29 private double r a d i u s ; // Kuglens r a d i u s
30 private Color f a r v e ; // Kuglens f a r v e
31
32 // c o n s t r u c t o r s
33
34 public Kugle ( Punkt centrum , double radius , Color f a r v e ) {
35 this ( centrum , radius , farve , Figur . r e f l e k t i o n s k o e f f i c i e n t D e f a u l t ) ;
36 }
37
38 public Kugle ( Punkt centrum , double radius , Color farve ,
39 double r e f l e k t i o n s k o e f f i c i e n t ) {
40 super ( farve , r e f l e k t i o n s k o e f f i c i e n t ) ;
41 this . centrum = centrum ;
42 this . r a d i u s = r a d i u s ;
43 this . f a r v e = f a r v e ;
44 }
45
46 // methods
47
48 public Vektor findNormalvektor ( Punkt skaeringspunkt , Punkt o e j e ) {
49 Vektor temp = Vektor . lavVektor ( centrum , skaeringspunkt ) ;
50
85

51 // udregner h v i l k e n v e j normalvektoren s k a l vende i f o r h o l d t i l ø j e t
52 // u d n y t t e s i det t i l f æ l d e , hvor noget a f kuglen l i g g e r inde i f i l m e n .
53 i f ( Vektor . laengde (
54 Vektor . subtraher ( Vektor . lavVektor ( o e j e ) ,
55 Vektor . adder ( Vektor . lavVektor ( centrum ) ,
56 temp ))) <
57 Vektor . laengde (
58 Vektor . subtraher ( Vektor . lavVektor ( o e j e ) ,
59 Vektor . adder ( Vektor . lavVektor ( centrum ) ,
60 Vektor . vend ( temp ) ) ) ) ) {
61 return temp ;
62 }
63 else {
64 return Vektor . vend ( temp ) ;
65 }
66 }
67
68 // Hjælpefunktion t i l skaeringspunkt , udregner skæringspunkt
69 private Punkt t s k a l a r ( Punkt oeje , Vektor vektor , double x ) {
70 Punkt sp = new Punkt ( o e j e . x+vektor . x∗x ,
71 o e j e . y+vektor . y∗x ,
72 o e j e . z+vektor . z ∗x ) ;
73 return sp ;
74 }
75
76 public Punkt skaeringspunkt ( Vektor vektor , Punkt o e j e ) {
77 //a , b og c t i l l ø s n i n g a f a n d e n g r a d s l i g n i n g
78 double a = ( vektor . x∗ vektor . x+vektor . y∗ vektor . y+vektor . z∗ vektor . z ) ;
79 double b = 2∗( vektor . x ∗( o e j e . x−centrum . x)+vektor . y ∗( o e j e . y−centrum . y)+
80 vektor . z ∗( o e j e . z−centrum . z ) ) ;
81 double c = Math . pow ( ( o e j e . x−centrum . x ) ,2)+
82 Math . pow ( ( o e j e . y−centrum . y ) ,2)+
83 Math . pow ( ( o e j e . z−centrum . z ) ,2) −
84 Math . pow( radius , 2 ) ;
85 // Diskreminant
86 double d = Math . pow(b ,2) − 4∗ a∗ c ;
87 // Linien skærer kuglen 2 gange
88 i f ( d>0) {
89 // x1 og x2 er l i g n i n g e n s l ø s n i n g e r .
90 double x1 = (−b−Math . s q r t ( d ) ) / ( 2 ∗ a ) ;
91 double x2 = (−b+Math . s q r t ( d ) ) / ( 2 ∗ a ) ;
92
93 // t j e k k e r om x1 s k æ r i n g s p u n k t e t er t æ t t e r e p˚a end x2 s k æ r i n g s p u n k t e t
94 // og om det er ude a f f i l m e n .
95 i f ( x1 < x2 && x1 > 1.0){
96 return t s k a l a r ( oeje , vektor , x1 ) ;
97 }
98 // da x1 i k k e kunne bruges t j e k k e s om x2 kan , ved at se om den er
99 // ude a f f i l m e n .
100 else i f ( x2 > 1.0){
101 return t s k a l a r ( oeje , vektor , x2 ) ;
102 }
103 else {
86

104 // begge punkter b e f i n d e r s i g enten bag ø j e t e l l e r f ø r f i l m e n .
105 return null ;
106 }
107 }
108 // Linien tangere kuglen .
109 i f ( d==0) {
110 double x1 = (−b−Math . s q r t ( d ) ) / ( 2 ∗ a ) ;
111 i f ( x1>=0) {
112 return t s k a l a r ( oeje , vektor , x1 ) ;
113 }
114 }
115 // Linien skærer i k k e kuglen .
116 return null ;
117 }
118 }
87

E.7 Mesh.java
0 import java . awt . Color ;
1
2 public class Mesh extends Figur{
3 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
4 Mesh . java
5
6 Mesh ( Trekant [ ] t r e k a n t e r , Color f a r v e )
7
8 Constructor som kun k a l d e r den anden c o n s t r u c t o r .
9 Ud over at den sender a l l e argumenter videre , s˚a sender den ogs˚a
10 s t a t i c v a r i a b l e n ” r e f l e k t i o n s k o e f f i c i e n t D e f a u l t ” f r a Figur k l a s s e n med .
11
12 Mesh ( Trekant [ ] t r e k a n t e r , Color farve , double r e f l e k t i o n s k o e f f i c i e n t )
13
14 Constructor som i n s t a n c i e r e s i n s u p e r k l a s s e n , og o p r e t t e r e t mesh med
15 best˚aende a f de t r e k a n t e r som f i n d e s i array ’ e t t r e k a n t e r .
16
17 Vektor findNormalvektor ( Punkt skaeringspunkt , Punkt o e j e )
18
19 r e t u r n e r e normalvektoren f o r den t r e k a n t som s i d s t u d e l e v e r e d e e t
20 skæringspunkt .
21
22 Punkt s k a e r i n g s p u n k t ( Vektor g i t t e r v e k t o r , Punkt o e j e )
23
24 r e t u r n e r e s k æ r i n g s p u n k t e t mellem den l i n j e som g i t t e r v e k t o r og o e j e udgør
25 og den t r e k a n t i meshet som l i g g e r t æ t t e s t p˚a o e j e .
26
27 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
28
29 // F i e l d s
30 private Trekant [ ] t r e k a n t e r ;
31 private int sidstRamteTrekant = −1;
32
33 // Constructors
34 public Mesh ( Trekant [ ] trekanter , Color f a r v e ){
35 this ( trekanter , farve , Figur . r e f l e k t i o n s k o e f f i c i e n t D e f a u l t ) ;
36 }
37
38 public Mesh ( Trekant [ ] trekanter , Color farve , double r e f l e k t i o n s k o e f f i c i e n t ){
39 super ( farve , r e f l e k t i o n s k o e f f i c i e n t ) ;
40 this . t r e k a n t e r = t r e k a n t e r ;
41 }
42
43 // Methods
44 public Vektor findNormalvektor ( Punkt skaeringspunkt , Punkt o e j e ){
45 // meshet er b l e v e t b e d t om en normalvektor , f ø r det er b l e v e t b e d t om
46 // e t skæringspunkt .
47 i f ( sidstRamteTrekant == −1){
48 throw new RuntimeException ( ”mesh kan ikke r e t u r n e r e en ” +
49 ” normalvektor , da der ikke er ramt nogen trekant ” ) ;
50 }
88

51 // r e t u r n e r e normalvektoren f r a den t r e k a n t som s i d s t u d l e v e r e d e e t
52 // skæringspunkt .
53 return t r e k a n t e r [ sidstRamteTrekant ] . findNormalvektor ( skaeringspunkt ,
54 o e j e ) ;
55 }
56
57 public Punkt skaeringspunkt ( Vektor g i t t e r v e k t o r , Punkt o e j e ){
58 // i n s t a n c i e r e de nødvendige arrays og v a r i a b l e r
59 Punkt [ ] s k a e r i n g s p u n k t e r = new Punkt [ t r e k a n t e r . length ] ;
60 double [ ] a f s t a n d e = new double [ t r e k a n t e r . length ] ;
61 int k o r t e s t A f s t a n d = −1;
62
63 for ( int i = 0 ; i < t r e k a n t e r . length ; i ++){
64 s k a e r i n g s p u n k t e r [ i ] = t r e k a n t e r [ i ] . skaeringspunkt ( g i t t e r v e k t o r ,
65 o e j e ) ;
66
67 i f ( s k a e r i n g s p u n k t e r [ i ] ! = null ){
68 a f s t a n d e [ i ] = Vektor . laengde ( Vektor . lavVektor ( oeje ,
69 s k a e r i n g s p u n k t e r [ i ] ) ) ;
70
71 // t j e k k e r om der er en t r e k a n t i mesh ’ e t som er b l e v e t ramt .
72 i f ( k o r t e s t A f s t a n d == −1){
73 k o r t e s t A f s t a n d = i ;
74 }
75 // t j e k k e r om den nye a f s t a n d som er f u n d e t er mindre end den
76 // som h i d t i l har været mindst .
77 i f ( a f s t a n d e [ i ] < a f s t a n d e [ k o r t e s t A f s t a n d ] ) {
78 k o r t e s t A f s t a n d = i ;
79 }
80 }
81 }
82 // der er ingen a f t r e k a n t e r n e som er b l e v e t b e r ø r t .
83 i f ( k o r t e s t A f s t a n d == −1){
84 return null ;
85 }
86 // r e t u r n e r e det skæringspunkt med den k o r t e s t e
87 // a f s t a n d t i l ø j e t , og gemmer det t i l senere brug .
88 else {
89 // notere den s i d s t e t r e k a n t som b l e v ramt .
90 sidstRamteTrekant = k o r t e s t A f s t a n d ;
91 return s k a e r i n g s p u n k t e r [ k o r t e s t A f s t a n d ] ;
92 }
93 }
94 }
89

E.8 Plan.java
0 import java . awt . Color ;
1
2 public class Plan extends Figur{
3 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
4 Plan . java
5
6 Plan ( Punkt p , Vektor vektor1 , Vektor vektor2 , Color f a r v e )
7
8 Constructor som kun k a l d e r den anden c o n s t r u c t o r .
9 Ud over at den sender a l l e argumenter videre , s˚a sender den ogs˚a
10 s t a t i c v a r i a b l e n ” r e f l e k t i o n s k o e f f i c i e n t D e f a u l t ” f r a Figur k l a s s e n med .
11
12 p u b l i c Plan ( Punkt punkt , Vektor vektor1 , Vektor vektor2 , Color farve ,
13 double r e f l e k t i o n s k o e f f i c i e n t )
14
15 Constructor som i n s t a n c i e r e s i n s u p e r k l a s s e , og udregner k o n s t a n t e r t i l
16 repræsentatio n a f p l a n e t ved l i g n i n g e n : Ax + By + Cy + D = 0 , og
17 som udregner en normalvektor t i l p l a n e t .
18
19 Punkt s k a e r i n g s p u n k t ( Vektor g i t t e r v e k t o r , Punkt o e j e )
20
21 r e t u r n e r e s k æ r i n g s p u n k t e t f o r p l a n e t og den l i n j e som g i t t e r v e k t o r
22 og o e j e udgør . Der gælder f o r s k æ r i n g s p u n k t e t at det i k k e m˚a l i g g e
23 bag filmen , og at der d e r f o r i k k e r e t u r n e s e t skæringspunkt hvor
24 g i t t e r v e k t o r s s k a l a r < 1.
25
26 Vektor findNormalvektor ( Punkt skaeringspunkt , Punkt o e j e )
27
28 r e t u r n e r e normalvektoren f o r p l a n e t som peger imod oeje , hvor o e j e
29 er ø j e t f r a kameraet og s k a e r i n g s p u n k t er s k æ r i n g s p u n k t e t f o r
30 f i g u r e n og den l i n j e som den a k t u e l l e g i t t e r v e k t o r og o e j e udgør .
31
32 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
33
34 // F i e l d s
35 private f i n a l double A, B, C, D;
36 private f i n a l Vektor normalvektor ;
37
38 // Constructors
39 // ved k a l d uden r e f l e k t i o n s k o e f f i c i e n t a n g i v e t .
40 public Plan ( Punkt p , Vektor vektor1 , Vektor vektor2 , Color f a r v e ){
41 this (p , vektor1 , vektor2 , farve , Figur . r e f l e k t i o n s k o e f f i c i e n t D e f a u l t ) ;
42 }
43
44 // ved k a l d med r e f l e k t i o n s k o e f f i c i e n t a n g i v e t .
45 public Plan ( Punkt punkt , Vektor vektor1 , Vektor vektor2 , Color farve ,
46 double r e f l e k t i o n s k o e f f i c i e n t ){
47 super ( farve , r e f l e k t i o n s k o e f f i c i e n t ) ;
48 normalvektor = Vektor . krydsprodukt ( vektor1 , vektor2 ) ;
49
50 // udregner k o n s t a n t e r t i l repræsentatio n a f p l a n e t ved l i g n i n g e n :
90

51 // Ax + By + Cz + D = 0
52 A = normalvektor . x ;
53 B = normalvektor . y ;
54 C = normalvektor . z ;
55 D = − A ∗ punkt . x − B ∗ punkt . y − C ∗ punkt . z ;
56 }
57
58 // Methods
59 public Punkt skaeringspunkt ( Vektor g i t t e r v e k t o r , Punkt o e j e ){
60 // f i n d e r nævneren i l i g n i n g e n p˚a opgaveformuler ing ens s i d e 9 , ø v e r s t .
61 double naevner = A ∗ g i t t e r v e k t o r . x + B ∗ g i t t e r v e k t o r . y + C ∗
62 g i t t e r v e k t o r . z ;
63
64 // er nævneren 0 , s˚a er p l a n e t og l i n j e n p a r a l e l l e og skærer i k k e
65 // hinanden .
66 i f ( naevner == 0){
67 return null ;
68 }
69
70 // t t i l i n d s æ t t e l s e i l i n j e n s p a r a m e t e r f r e m s t i l l i n g udregnes .
71 double t = − 1 ∗ ((A ∗ o e j e . x + B ∗ o e j e . y + C ∗ o e j e . z + D) / naevner ) ;
72
73 // t j e k k e r om s k æ r i n g s p u n k t e t l i g g e r bag kameraet .
74 i f ( t < 1.0){
75 return null ;
76 }
77
78 // p˚aregner s k a l a r e t p˚a g i t t e r v e k t o r e n
79 Vektor skalarAfV = Vektor . s k a l e r ( g i t t e r v e k t o r , t ) ;
80
81 // udregner og r e t u r n e r e s k æ r i n g s p u n k t e t .
82 return Vektor . t i l P u n k t ( Vektor . adder ( Vektor . lavVektor ( o e j e ) , skalarAfV ) ) ;
83 }
84
85 public Vektor findNormalvektor ( Punkt skaeringspunkt , Punkt o e j e ){
86 /∗ udregner om normalvektoren s k a l vendes om, afhængigt a f h v i l k e n
87 ∗ en a f dem som peger imod ø j e t .
88 ∗
89 ∗ udregner den f ø r s t e a f s t a n d s v e k t o r ved at l a v e en v e k t o r mellem ø j e t
90 ∗ og p l a n e t s skæringspunkt sammenlagt med normalvektoren .
91 ∗/
92 Vektor a f s t a n d s v e k t o r 1 = Vektor . lavVektor ( oeje ,
93 Vektor . t i l P u n k t ( Vektor . adder ( Vektor . lavVektor ( skaeringspunkt ) ,
94 normalvektor ) ) ) ;
95
96 // udregner den anden a f s t a n d s v e k t o r ved samme udregning som før , b o r t
97 // s e t f r a at normalvektoren er i n v e r t e r e t .
98 Vektor a f s t a n d s v e k t o r 2 = Vektor . lavVektor ( oeje ,
99 Vektor . t i l P u n k t ( Vektor . adder ( Vektor . lavVektor ( skaeringspunkt ) ,
100 Vektor . vend ( normalvektor ) ) ) ) ;
101
102 // r e t u r n e r e den v e k t o r som har den k o r t e s t e a f s t a n d t i l ø j e t .
103 i f ( Vektor . laengde ( a f s t a n d s v e k t o r 1 ) < Vektor . laengde ( a f s t a n d s v e k t o r 2 ) ) {
91

104 return normalvektor ;
105 }
106 else {
107 return Vektor . vend ( normalvektor ) ;
108 }
109 }
110 }
92

E.9 Punkt.java
0 class Punkt {
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 Punkt . java
3
4 Punkt ( double x , double y , double z )
5
6 Constructor der o p r e t t e r e t punkt i det 3− dimesionale plan .
7
8 Koordinaterne er f i n a l da de i k k e s k a l ændres .
9
10 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
11
12 // f i e l d s
13 public f i n a l double x ;
14 public f i n a l double y ;
15 public f i n a l double z ;
16
17 // c o n s t r u c t o r s
18 public Punkt ( double x , double y , double z ) {
19 this . x = x ;
20 this . y = y ;
21 this . z = z ;
22 }
23 }
93

E.10 Scene.java
0 import java . awt . Color ;
1
2 public class Scene {
3 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
4 Scene . java
5
6 Scene ( Figur [ ] f i g u r e r , Sol s o l )
7
8 Constructor som i n s t a n c i e r e Scenen , hvor f i g u r e r er a l l e f i g u r e r som
9 forekommer i scenen og s o l er den s o l som s k a l være i scenen .
10
11 Color nuance ( Punkt oeje , Vektor g i t t e r v e k t o r )
12
13 udregner nuancen i punktet f o r den f i g u r som den l i n j e der b l i v e r u d g j o r t a f
14 o e j e og g i t t e r v e k t o r rammer f ø r s t , hvor g i t t e r v e k t o r s s k a l a r i k k e m˚a være
15 mindre end 1 , og hvor det gælder at s o l e n ogs˚a s k a l ramme punktet .
16
17 o p f y l d e s det i k k e at g i t t e r v e k t o r s s k a l a r er mindre end 1 , da r e t u r n e r e s
18 farven f o r den næste f i g u r som rammes , hvor det gælder at g i t t e r v e k t o r s
19 s k a l a r er < 1;
20
21 rammer s o l e n i k k e punktet , da er punktet i skygge , og en s o r t r e t u r n e r e s .
22
23 rammes ingen f i g u r e r f r a scenen overhovedet , da r e t u r n e r e s s o r t .
24
25 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
26 // F i e l d s
27 private Figur [ ] f i g u r e r ;
28 private Sol s o l ;
29
30 // Constructors
31 public Scene ( Figur [ ] f i g u r e r , Sol s o l ){
32 this . f i g u r e r = f i g u r e r ;
33 this . s o l = s o l ;
34 }
35 // Methods
36 public Color nuance ( Punkt oeje , Vektor g i t t e r v e k t o r ){
37 Punkt skaeringspunkt = null ;
38 int f i g u r = −1;
39 // f i n d e r s k æ r i n g s p u n k t e t og den f i g u r som er nærmest ø j e t ved den givne
40 // v e k t o r .
41 {
42 double afstand = −1;
43
44 for ( int i = 0 ; i < f i g u r e r . length ; i ++){
45 // punktet der rammes p˚a f i g u r nummer i
46 Punkt skpunkt = f i g u r e r [ i ] . skaeringspunkt ( g i t t e r v e k t o r , o e j e ) ;
47
48 i f ( skpunkt ! = null ){
49 double temp = Vektor . laengde ( Vektor . lavVektor ( oeje , skpunkt ) ) ;
50
94

51 // den f ø r s t e f i g u r som b l i v e r ramt .
52 i f ( afstand == −1){
53 afstand = temp ;
54 f i g u r = i ;
55 skaeringspunkt = skpunkt ;
56 }
57
58 // h v i s denne f i g u r er t æ t t e r e p˚a ø j e t end den h i d t i l .
59 i f ( temp < afstand ){
60 afstand = temp ;
61 f i g u r = i ;
62 skaeringspunkt = skpunkt ;
63 }
64 }
65 }
66
67 // har i k k e ramt nogen f i g u r e r .
68 i f ( f i g u r == −1)
69 return Color . black ;
70 }
71 // t j e k k e r om det fundne skæringspunkt ogs˚a b l i v e r ramt a f s o l e n
72 {
73 // udregner vektoren mellem s o l e n og s k æ r i n g s p u n k t e t
74 Vektor solTilSkpunkt = Vektor . lavVektor ( s o l . p o s i t i o n ,
75 skaeringspunkt ) ;
76
77 // s k a l e r e v e k t o r e r e n ned , s˚a l e d e s t i l længde 1 , f o r at f o r at undg˚a
78 // t < 1 ved udregning a f skæringspunkt mellem s o l og f i g u r .
79 solTilSkpunkt = Vektor . s k a l e r ( solTilSkpunkt , 1 . 0 /
80 Vektor . laengde ( solTilSkpunkt ) ) ;
81
82 double afstand = −1;
83 Punkt naermestePunkt = null ;
84
85 for ( int i = 0 ; i < f i g u r e r . length ; i ++){
86 // punktet p˚a f i g u r nummer i som b l i v e r ramt a f s o l e n med
87 // r e t n i n g mod s k æ r i n g s p u n k t e t f r a ø j e t .
88 Punkt solpunkt = f i g u r e r [ i ] . skaeringspunkt ( solTilSkpunkt ,
89 s o l . p o s i t i o n ) ;
90
91 i f ( solpunkt ! = null ){
92 double temp = Vektor . laengde ( Vektor . lavVektor ( s o l . p o s i t i o n ,
93 solpunkt ) ) ;
94
95 // den f ø r s t e f i g u r s o l e n rammer .
96 i f ( afstand == −1){
97 afstand = temp ;
98 naermestePunkt = solpunkt ;
99 }
100
101 // denne f i g u r er t æ t t e r e p˚a s o l e n end den h i d t i l .
102 i f ( temp < afstand ){
103 afstand = temp ;
95

104 naermestePunkt = solpunkt ;
105 }
106 }
107 }
108
109 // har s o l e n overhovedet i k k e ramt nogen f i g u r .
110 i f ( naermestePunkt == null ){
111 throw new RuntimeException ( ” Solen ramte ikke det ”+
112 ”samme punkt som o e j e t ” ) ;
113 }
114
115 // det nærmeste punkt s o l e n rammer er i k k e det samme som s k æ r i n g s p u n k t e t .
116 double f o r s k e l = Vektor . laengde (
117 Vektor . lavVektor ( naermestePunkt , skaeringspunkt ) ) ;
118
119 // u n ø j a g t i g h e d e n mellem de to punkter er her v a l g t t i l maksimalt at m˚a
120 // være 0 . 0 0 0 0 0 1 , e l l e r s k o n s t a t e r e s det at s o l e n i k k e har ramt punktet .
121 i f ( f o r s k e l > 0.000001){
122 return Color . black ;
123 }
124 }
125
126 // s o l e n rammer a l t s˚a f i g u r e n , h v i l k e t gør at nuancen s k a l udregnes .
127 return f i g u r e r [ f i g u r ] . nuance ( skaeringspunkt , oeje , s o l ) ;
128 }
129 }
96

E.11 Sol.java
0 import java . awt . Color ;
1
2 public class Sol {
3 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
4 Sol . java
5
6 Sol ( Punkt p o s i t i o n , Color f a r v e )
7
8 Constructor der o p r e t t e r en l y s k i l d e i p o s i t i o n med l y s i n t e n s i t e t f a r v e
9
10 p o s i t i o n og f a r v e er f i n a l da de i k k e s k a l ændres
11
12 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
13
14 // f i e l d s
15 public f i n a l Punkt p o s i t i o n ;
16 public f i n a l Color f a r v e ;
17
18 // c o n s t r u c t o r s
19 public Sol ( Punkt p o s i t i o n , Color f a r v e ){
20 this . p o s i t i o n = p o s i t i o n ;
21 this . f a r v e = f a r v e ;
22 }
23 }
97

E.12 Stoerrelsesfejl.java
0 class S t o e r r e l s e s f e j l extends IndexOutOfBoundsException {
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 S t o e r r e l s e s f e j l . java
3
4 S t o e r r e l s e s f e j l ( S t r i n g s )
5 Constructor . s er f e j l b e s k e d e n .
6
7 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
8 S t o e r r e l s e s f e j l ( S t r i n g s )
9 { super ( s ) ; }
10 }
98

E.13 Trekant.java
0 import java . awt . Color ;
1 // i n d b y g g e t Point o b j e k t som kan h˚andtere double .
2 import java . awt . geom . Point2D . Double ;
3
4 public class Trekant extends Figur {
5 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
6 Trekant . java
7
8 Trekant ( Punkt a , Punkt b , Punkt c , Color f a r v e )
9
10 Constructor som kun k a l d e r den anden c o n s t r u c t o r .
11 Ud over at den sender a l l e argumenter videre , s˚a sender den ogs˚a
12 s t a t i c v a r i a b l e n ” r e f l e k t i o n s k o e f f i c i e n t D e f a u l t ” f r a Figur k l a s s e n med .
13
14 Trekant ( Punkt a , Punkt b , Punkt c , Color f a r v e )
15
16 Constructor som i n s t a n c i e r e s i n s u p e r k l a s s e , og s æ t t e r a , b og c t i l
17 punkt 1 , punkt 2 og punkt 3 .
18 Desuden o p r e t t e r den det plan som t r e k a n t e n l i g g e r i , og gemmer i
19 v a r i a b l e n plan .
20
21 Punkt s k a e r i n g s p u n k t ( Vektor g i t t e r v e k t o r , Punkt o e j e )
22
23 r e t u r n e r e s k æ r i n g s p u n k t e t f o r t r e k a n t e n og den l i n j e som g i t t e r v e k t o r
24 og o e j e udgør . f ø r s t t j e k k e s om der er i skæringspunkt mellem t r e k a n t e n s
25 plan og l i n j e n , og d e r e f t e r om det skæringspunkt l i g g e r i t r e k a n t e n .
26
27 Vektor findNormalvektor ( Punkt skaeringspunkt , Punkt o e j e )
28
29 r e t u r n e r e normalvektoren f o r t r e k n t e n s plan som peger imod oeje , hvor o e j e
30 er ø j e t f r a kameraet og s k a e r i n g s p u n k t er s k æ r i n g s p u n k t e t f o r
31 f i g u r e n og den l i n j e som den a k t u e l l e g i t t e r v e k t o r og o e j e udgør .
32
33 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
34 // F i e l d s
35 private f i n a l double r e f l e k t i o n s k o e f f i c i e n t D e f a u l t = 1 . 0 ;
36
37 private f i n a l Punkt punkt1 ;
38 private f i n a l Punkt punkt2 ;
39 private f i n a l Punkt punkt3 ;
40
41 private f i n a l Plan plan ;
42 // Constructors
43 public Trekant ( Punkt a , Punkt b , Punkt c , Color f a r v e ){
44 this ( a , b , c , farve , Figur . r e f l e k t i o n s k o e f f i c i e n t D e f a u l t ) ;
45 }
46
47 public Trekant ( Punkt a , Punkt b , Punkt c , Color farve ,
48 double r e f l e k t i o n s k o e f f i c i e n t ){
49 super ( farve , r e f l e k t i o n s k o e f f i c i e n t ) ;
50
99

51 punkt1 = a ;
52 punkt2 = b ;
53 punkt3 = c ;
54
55 plan = new Plan ( punkt1 , Vektor . lavVektor ( punkt1 , punkt2 ) ,
56 Vektor . lavVektor ( punkt1 , punkt3 ) , f a r v e ) ;
57 }
58 // Methods
59 public Punkt skaeringspunkt ( Vektor v , Punkt p){
60 Punkt skaeringspunkt = plan . skaeringspunkt ( v , p ) ;
61
62 // t j e k k e r om punktet l i g g e r i den plan som t r e k a n t e n udspænder ,
63 i f ( skaeringspunkt ! = null ){
64 // p r o j i c e r e t r e k a n t e n ned p˚a de t r e grundplaner
65 // X, Y p l a n e t
66 Double XYPlanPunkt1 = new Double ( punkt1 . x , punkt1 . y ) ;
67 Double XYPlanPunkt2 = new Double ( punkt2 . x , punkt2 . y ) ;
68 Double XYPlanPunkt3 = new Double ( punkt3 . x , punkt3 . y ) ;
69
70 // Z , X p l a n e t
71 Double ZXPlanPunkt1 = new Double ( punkt1 . z , punkt1 . x ) ;
72 Double ZXPlanPunkt2 = new Double ( punkt2 . z , punkt2 . x ) ;
73 Double ZXPlanPunkt3 = new Double ( punkt3 . z , punkt3 . x ) ;
74
75 // Z , Y p l a n e t
76 Double ZYPlanPunkt1 = new Double ( punkt1 . z , punkt1 . y ) ;
77 Double ZYPlanPunkt2 = new Double ( punkt2 . z , punkt2 . y ) ;
78 Double ZYPlanPunkt3 = new Double ( punkt3 . z , punkt3 . y ) ;
79
80 // f i n d e r a r e a l e r n e a f p r o j e k t i o n e r n e p˚a grundplanerne .
81 double arealXY = 0 . 5 ∗ a r e a l ( XYPlanPunkt1 , XYPlanPunkt2 , XYPlanPunkt3 ) ;
82 double arealZX = 0 . 5 ∗ a r e a l ( ZXPlanPunkt1 , ZXPlanPunkt2 , ZXPlanPunkt3 ) ;
83 double arealZY = 0 . 5 ∗ a r e a l ( ZYPlanPunkt1 , ZYPlanPunkt2 , ZYPlanPunkt3 ) ;
84
85 // t j e k k e r om arealXY er s t ø r s t
86 i f ( arealXY >= arealZX && arealXY >= arealZY ){
87 i f ( f i n d e s I T r e k a n t ( XYPlanPunkt1 , XYPlanPunkt2 , XYPlanPunkt3 ,
88 new Double ( skaeringspunkt . x , skaeringspunkt . y ) ) ) {
89 return skaeringspunkt ;
90 }
91 else{
92 // punktet b e f a n d t s i g i k k e inde i t r e k a n t e n .
93 return null ;
94 }
95 }
96 // t j e k k e r om arealZX er s t ø r s t
97 i f ( arealZX >= arealXY && arealZX >= arealZY ){
98 i f ( f i n d e s I T r e k a n t ( ZXPlanPunkt1 , ZXPlanPunkt2 , ZXPlanPunkt3 ,
99 new Double ( skaeringspunkt . z , skaeringspunkt . x ) ) ) {
100 return skaeringspunkt ;
101 }
102 else{
103 // punktet b e f a n d t s i g i k k e inde i t r e k a n t e n .
100

104 return null ;
105 }
106 }
107
108 // arealZY m˚a være det s t ø r s t e , og udfra d e t t e t j e k k e s om punktet
109 // l i g g e r i t r e k a n t e n .
110 i f ( f i n d e s I T r e k a n t ( ZYPlanPunkt1 , ZYPlanPunkt2 , ZYPlanPunkt3 ,
111 new Double ( skaeringspunkt . z , skaeringspunkt . y ) ) ) {
112 return skaeringspunkt ;
113 }
114 else {
115 // punktet b e f a n d t s i g i k k e inde i t r e k a n t e n .
116 return null ;
117 }
118 }
119 else {
120 // l i n j e n skær i k k e t r e k a n t e n s plan
121 return null ;
122 }
123 }
124
125 private boolean f i n d e s I T r e k a n t ( Double p1 , Double p2 , Double p3 , Double q ){
126 // udregner determinanter
127 double determinantSide1 =
128 ( q . getX () − p1 . getX ( ) ) ∗ ( p2 . getY () − p1 . getY ()) −
129 ( q . getY () − p1 . getY ( ) ) ∗ ( p2 . getX () − p1 . getX ( ) ) ;
130
131 double determinantSide2 =
132 ( q . getX () − p2 . getX ( ) ) ∗ ( p3 . getY () − p2 . getY ()) −
133 ( q . getY () − p2 . getY ( ) ) ∗ ( p3 . getX () − p2 . getX ( ) ) ;
134
135 double determinantSide3 =
136 ( q . getX () − p3 . getX ( ) ) ∗ ( p1 . getY () − p3 . getY ()) −
137 ( q . getY () − p3 . getY ( ) ) ∗ ( p1 . getX () − p3 . getX ( ) ) ;
138
139 return
140 ( ( determinantSide1 >= 0 && determinantSide2 >= 0 && determinantSide3 > = 0 ) | |
141 ( determinantSide1

157 public Vektor findNormalvektor ( Punkt p , Punkt o e j e ){
158 return plan . findNormalvektor (p , o e j e ) ;
159 }
160 }
102

E.14 Vektor.java
0 class Vektor {
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 Vektor . java
3
4 Vektor ( double x , double y , double z )
5 Contructor der l a v e r en v e k t o r
6
7 x , y og z er a l l e s t a t i c da de i k k e s k a l ændres .
8
9 s t a t i c Vektor lavVektor ( Punkt p1 )
10 Laver v e k t o r f r a 1 punkt
11
12 s t a t i c Punkt t i l P u n k t ( Vektor v1 )
13 Laver en v e k t o r om t i l e t Punkt
14
15 s t a t i c Vektor vend ( Vektor v1 )
16 I n v e r t e r e r en v e k t o r
17
18 s t a t i c double laengde ( Vektor v1 )
19 Udregner længden a f en v e k t o r ( Opgaveformulering B. 3 . 1 )
20
21 s t a t i c Vektor s k a l e r ( Vektor v1 , double s k a l a r )
22 M u l t i p l i c e r e r en v e k t o r med en s k a l a r ( Opgaveformulering B. 3 . 3 )
23
24 s t a t i c Vektor adder ( Vektor v1 , Vektor v2 )
25 Adderer 2 v e k t o r e r ( Opgaveformulering B. 3 . 4 )
26
27 s t a t i c Vektor s u b t r a h e r ( Vektor v1 , Vektor v2 )
28 Subtraherer 2 v e k t o r e r f r a hinanden ( Opgaveformuleringen B. 3 . 4 )
29
30 s t a t i c double s k a l a r p r o d u k t ( Vektor v1 , Vektor v2 )
31 Udregner s k a l a r p r o d u k t e t a f 2 v e k t o r e r ( Opgaveformulering B. 3 . 6 )
32
33 s t a t i c Vektor lavVektor ( Punkt p1 , Punkt p2 )
34 Laver en v e k t o r udfra 2 punkter ( Opgaveformuleringen B. 3 . 7 )
35
36 s t a t i c Vektor krydsprodukt ( Vektor v1 , Vektor v2 )
37 Udregner k r y d s p r o d u k t e t f o r 2 v e k t o r e r ( Opgaveformuleringen B. 3 . 8 )
38
39 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
40 // f i e l d s
41 public f i n a l double x ;
42 public f i n a l double y ;
43 public f i n a l double z ;
44
45 // c o n s t r u c t o r
46 public Vektor ( double x , double y , double z ) {
47 this . x = x ;
48 this . y = y ;
49 this . z = z ;
50 }
103

51
52 // methods
53 public static Vektor lavVektor ( Punkt p1 ) {
54 return new Vektor ( p1 . x , p1 . y , p1 . z ) ;
55 }
56
57 public static Punkt t i l P u n k t ( Vektor v1 ) {
58 return new Punkt ( v1 . x , v1 . y , v1 . z ) ;
59 }
60
61 public static Vektor vend ( Vektor v1 ) {
62 return new Vektor(−v1 . x,−v1 . y,−v1 . z ) ;
63 }
64
65 public static double laengde ( Vektor v1 ) {
66 return Math . s q r t (Math . pow( v1 . x ,2)+
67 Math . pow( v1 . y ,2)+Math . pow( v1 . z , 2 ) ) ;
68 }
69
70 public static Vektor s k a l e r ( Vektor v1 , double s k a l a r ) {
71 return new Vektor ( v1 . x∗ skalar , v1 . y∗ skalar , v1 . z∗ s k a l a r ) ;
72 }
73
74 public static Vektor adder ( Vektor v1 , Vektor v2 ) {
75 return new Vektor ( v1 . x+v2 . x , v1 . y+v2 . y , v1 . z+v2 . z ) ;
76 }
77
78 public static Vektor subtraher ( Vektor v1 , Vektor v2 ) {
79 return new Vektor ( v1 . x−v2 . x , v1 . y−v2 . y , v1 . z−v2 . z ) ;
80 }
81
82 public static double skalarprodukt ( Vektor v1 , Vektor v2 ) {
83 return v1 . x∗v2 . x+v1 . y∗v2 . y+v1 . z ∗v2 . z ;
84 }
85
86 public static Vektor lavVektor ( Punkt p1 , Punkt p2 ) {
87 return new Vektor ( p2 . x − p1 . x , p2 . y−p1 . y , p2 . z−p1 . z ) ;
88 }
89
90 public static Vektor krydsprodukt ( Vektor v1 , Vektor v2 ) {
91 return new Vektor ( v1 . y∗v2 . z−v1 . z ∗v2 . y ,
92 v1 . z ∗v2 . x−v1 . x∗v2 . z ,
93 v1 . x∗v2 . y−v1 . y∗v2 . x ) ;
94 }
95 }
104

E.15 XMLParseError.java
0 public class XMLParseError extends Throwable{
1 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
2 XMLParseError . java
3
4 XMLParseError( S t r i n g s )
5
6 Konstruerer e t XMLParseError o b j e k t . s er f e j l b e s k e d e n .
7
8 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
9 XMLParseError ( S t r i n g s ){ super ( s ) ; }
10 }
105

E.16 XMLParser.java
0 import java . awt . Color ;
1 // t i l opbygning a f xml
2 import javax . xml . p a r s e r s . DocumentBuilder ;
3 import javax . xml . p a r s e r s . DocumentBuilderFactory ;
4 import javax . xml . p a r s e r s . FactoryConfigurationError ;
5 import javax . xml . p a r s e r s . ParserConfigurationException ;
6 import org . xml . sax . SAXException ;
7 import org . xml . sax . SAXParseException ;
8 // t i l l o a d i n g a f xml f i l e n , p l u s e x c e p t i o n
9 import java . i o . F i l e ;
10 import java . i o . IOException ;
11 import java . u t i l . ∗ ;
12 import java . lang . Double ; // Double . parseDouble
13 import java . lang . I n t e g e r ; // I n t e g e r . p a r s e I n t
14 import org . w3c . dom . ∗ ; // NodeList , Document , Node , Element , e t c .
15
16 public class XMLParser
17 {
18 /∗ ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗
19 XMLParser . java
20
21 XMLParser( S t r i n g XMLSti)
22
23 Opretter XML o b j e k t et , henter en XML f i l ind , v i a f i l n a v n e t XMLSti ,
24 udtrækker , og o p r e t t e r a l l e kamera og scene elementer .
25
26 KameraVinkler hentKameraVinkler ( )
27
28 r e t u r n e r e det opbyggede KameraVinkler o b j e k t .
29
30 Scene hentScene ( )
31
32 r e t u r n e r e det opbyggede Scene o b j e k t .
33
34 ∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗∗/
35 // f i e l d s
36 private Figur [ ] f i g u r ;
37 private Kamera [ ] kamera ;
38 private Sol s o l ;
39
40 // array t i l f i l n a v n e , f o r at checke at de a l l e er f o r s k e l l i g e
41 private S t r i n g f i l n a v n e [ ] ;
42
43 // constructor , der er kun en . der k a s t e s kun IO e l l e r XML e x c e p t i o n s
44 public XMLParser( S t r i n g XMLSti ) throws XMLParseError , IOException {
45 NodeList nl ; // g e n e r a l node l i s t h o l d e r
46 Node [ ] n l a r r ; // g e n e r a l node array , s u b s t f o r n o d e l i s t .
47 Node [ ] nlarrMesh ;
48 Node [ ] nlarrKugle ;
49 Node [ ] n l a r r P l a n ;
50 Element root = null ; // document root h o l d e r
106

51
52 // her l o a d e s documentet .
53 try {
54 DocumentBuilderFactory f a c t o r y = DocumentBuilderFactory . newInstance ( ) ;
55 DocumentBuilder b u i l d e r = f a c t o r y . newDocumentBuilder ( ) ;
56 root=b u i l d e r . parse ( new F i l e (XMLSti ) ) . getDocumentElement ( ) ;
57 } catch ( SAXException sxe ) {
58 throw new XMLParseError ( ” I n v a l i d XML format : ” + sxe . getMessage ( ) ) ;
59 } catch ( ParserConfigurationException pce ) {
60 pce . printStackTrace ( ) ; // l a d os h˚abe det her i k k e kommer .
61 } catch ( IOException i o e ) {
62 throw new IOException ( ” F e j l i f i l s y s t e m : ” + i o e . getMessage ( ) ) ;
63 }
64
65 i f ( ! root . getNodeName ( ) . e q u a l s ( ” scene ” ) ) {
66 throw new XMLParseError ( ”Rod−element s k a l være a f type ” ) ;
67 }
68 // ////////////////////////////////////////////////////////////////////
69 // ////////////////////////////////////////////////////////////////////
70 // opbyg KameraVinkler
71 n l a r r = findElementer ( root , ” p i l o t s y n ” ) ;
72 i f ( n l a r r . length < 1) {
73 throw new XMLParseError ( ”Der kræves mindst et p i l o t s y n . ” ) ;
74 }
75 kamera = new Kamera [ n l a r r . length ] ;
76 f i l n a v n e = new S t r i n g [ n l a r r . length ] ;
77
78 for ( int i = 0 ; i < n l a r r . length ; i ++){
79 kamera [ i ] = lavKamera ( n l a r r [ i ] , i ) ;
80 }
81 // l a v sol , findElement s ø r g e r f o r kun en < s o l />
82 s o l = l a v S o l ( findElement ( root , ” s o l ” ) ) ;
83 // ////////////////////////////////////////////////////////////////////
84 // ////////////////////////////////////////////////////////////////////
85 // v i f i n d e r l i g e ud a f hvor s t o r f i g u r [ ] s k a l værer
86 nlarrMesh = findElementer ( root , ”mesh” ) ;
87 nlarrKugle = findElementer ( root , ” kugle ” ) ;
88 n l a r r P l a n = findElementer ( root , ” plan ” ) ;
89 int a n t a l F i g u r e r = nlarrMesh . length + nlarrKugle . length + n l a r r P l a n . length ;
90
91 f i g u r = new Figur [ a n t a l F i g u r e r ] ;
92 // l a v f i g u r e
93 nl = root . getChildNodes ( ) ;
94 int j = 0 ;
95 for ( int i = 0 ; i < nlarrMesh . length ; i ++) {
96 f i g u r [ j ++] = lavMesh ( nlarrMesh [ i ] ) ;
97 }
98
99 for ( int i = 0 ; i < nlarrKugle . length ; i ++) {
100 f i g u r [ j ++] = lavKugle ( nlarrKugle [ i ] ) ;
101 }
102
103 for ( int i = 0 ; i < n l a r r P l a n . length ; i ++) {
107

104 f i g u r [ j ++] = lavPlan ( n l a r r P l a n [ i ] ) ;
105 }
106 // c o n s t r u c t o r s l u t
107 }
108
109 // hjælpe f u n k t i o n t i l at have x/y/ z ud a f e t element .
110 private double [ ] punkter ( Node n ) throws XMLParseError{
111 Element elm = ( Element ) n ;
112 double [ ] p = new double [ 3 ] ;
113 try {
114 // x/y/ z s k a l f i n d e s , og have Double format .
115 p [ 0 ] = Double . parseDouble ( elm . g e t A t t r i b u t e ( ”x” ) ) ;
116 p [ 1 ] = Double . parseDouble ( elm . g e t A t t r i b u t e ( ”y” ) ) ;
117 p [ 2 ] = Double . parseDouble ( elm . g e t A t t r i b u t e ( ”z” ) ) ;
118 // de f o r s k e l l i g e e x c e p t i o n s bruges t i l at
119 // a f g ø r e r h v i l k e n f e j l det var
120 } catch ( NumberFormatException exn ) {
121 throw new XMLParseError ( ”’ s x/y/z a t t r i b u t t e r ”+
122 ” var ikke i k o r r e k t format ” ) ;
123 } catch ( RuntimeException exn ) {
124 throw new XMLParseError ( ” manglede x/y/z a t t r i b u t t e n ” ) ;
125 }
126 return p ;
127 }
128
129 private boolean checkTrekant ( Punkt p1 , Vektor v2 , Vektor v3 ) {
130 Punkt p2 = Vektor . t i l P u n k t ( Vektor . adder ( Vektor . lavVektor ( p1 ) , v2 ) ) ;
131 Punkt p3 = Vektor . t i l P u n k t ( Vektor . adder ( Vektor . lavVektor ( p1 ) , v3 ) ) ;
132 return checkTrekant ( p1 , p2 , p3 ) ;
133 }
134
135 private boolean checkTrekant ( Punkt p1 , Punkt p2 , Punkt p3 ) {
136 Vektor a = Vektor . lavVektor ( p1 , p2 ) ;
137 Vektor b = Vektor . lavVektor ( p2 , p3 ) ;
138 Vektor c = Vektor . lavVektor ( p3 , p1 ) ;
139 double aStr = Vektor . laengde ( a ) ;
140 double bStr = Vektor . laengde ( b ) ;
141 double cStr = Vektor . laengde ( c ) ;
142
143 return (
144 ( aStr + bStr ) > cStr &&
145 ( bStr + cStr ) > aStr &&
146 ( cStr + aStr ) > bStr ) ;
147 }
148
149 // hjælpe f u n k t i o n t i l at h i v e RGB ud a f e t < f a r v e/>
150 private int [ ] rgbFarver ( Node n ) throws XMLParseError{
151 Element elm = ( Element ) n ;
152 int [ ] p = new int [ 3 ] ;
153 try {
154 p [ 0 ] = I n t e g e r . p a r s e I n t ( elm . g e t A t t r i b u t e ( ” r ” ) ) ;
155 p [ 1 ] = I n t e g e r . p a r s e I n t ( elm . g e t A t t r i b u t e ( ”g” ) ) ;
156 p [ 2 ] = I n t e g e r . p a r s e I n t ( elm . g e t A t t r i b u t e ( ”b” ) ) ;
108

157 } catch ( NumberFormatException exn ) {
158 throw new XMLParseError ( ”’ s r /g/b a t t r i b u t t e r ”+
159 ” var ikke i k o r r e k t format ” ) ;
160 } catch ( RuntimeException exn ) {
161 throw new XMLParseError ( ” manglede r /g/b a t t r i b u t t e n ” ) ;
162 }
163 // rgb værdierne s k a l være i decimal , og inden f o r 0−255
164 i f ( p [ 0 ] > 2 5 5 | | p [ 1 ] > 2 5 5 | | p [ 2 ] > 2 5 5 | |
165 p [ 0 ] < 0 | | p [ 1 ] < 0 | | p [ 2 ] < 0 ) {
166 throw new XMLParseError ( ”’ s r /g/b a t t r i b u t t e r ”+
167 ” var uden f o r 0−255” ) ;
168 }
169 return p ;
170 }
171
172 private Element findElement ( Node n , S t r i n g t ) throws XMLParseError {
173 // m˚a kun f i n d e s e t Element a f type ” t ” i h e l e træet
174 Node [ ] nl = findElementer (n , t ) ;
175 NodeList n l l = ( ( Element ) n ) . getElementsByTagName( t ) ;
176 i f ( nl . length ! = 1 ) {
177 throw new XMLParseError ( ”For f˚a /mange ” ) ;
178 }
179 // c a s t t i l Element , da Element er
180 // umiddelbart mere t i l g æ n g e l i n g
181 Element elm = ( Element ) nl [ 0 ] ;
182 return elm ;
183 }
184
185 // f i n d e r a l l e de noder , som f i n d e s d i r e k t e i n ’ s childNodes l i s t
186 // kan i k k e l i g e f˚a den t i l at l a v e nodeList , s˚a det er bare node [ ] : (
187 private Node [ ] findElementer ( Node n , S t r i n g t ) throws XMLParseError {
188 NodeList nc = n . getChildNodes ( ) ; // n ’ s c h i l d n o d e s
189 Node [ ] nl = new Node [ nc . getLength ( ) ] ;
190 Node [ ] n l f ; // n o d e l i s t f i n a l
191 int antalPunkter = 0 ;
192
193 for ( int i = 0 ; i < nc . getLength ( ) ; i ++) {
194 S t r i n g navn = nc . item ( i ) . getNodeName ( ) ;
195 i f ( navn . e q u a l s ( t ) ) {
196 nl [ antalPunkter ] = nc . item ( i ) ;
197 antalPunkter++;
198 }
199 }
200 n l f = new Node [ antalPunkter ] ;
201 for ( int i = 0 ; i < antalPunkter ; i ++) {
202 n l f [ i ] = nl [ i ] ;
203 }
204 return n l f ;
205 }
206
207 private Kugle lavKugle ( Node n ) throws XMLParseError {
208 double r ; // r a d i u s
209 Punkt c ; // centrum
109

210 Color f a r v e ; // f a r v e
211
212 // f i n d r a d i u s
213 S t r i n g rAttr = findElement ( n , ” r a d i u s ” ) . g e t A t t r i b u t e ( ” r ” ) ;
214 i f ( rAttr == ”” ) {
215 // t r o r det her er godt ?
216 throw new XMLParseError ( ” mangler r a t t r i b u t ” ) ;
217 }
218 try {
219 r = Double . parseDouble ( rAttr ) ;
220 i f ( r

263 double [ ] pkoord = punkter ( nl [ i ] ) ;
264 // her s k a l a l l e s æ t t e s . l ø k k e n kører 3 gange , og
265 // p/v1 / v2 m˚a i k k e s æ t t e s to gange , r e s u l t e r e n d e i
266 // at de a l l e s æ t t e s
267 i f ( navn . e q u a l s ( ” stedpunkt” ) ) {
268 i f ( p == null ) {
269 p = new Punkt ( pkoord [ 0 ] , pkoord [ 1 ] , pkoord [ 2 ] ) ;
270 continue ;
271 }
272 } else i f ( navn . e q u a l s ( ” r e t n i n g s v e k t o r 1 ” ) ) {
273 i f ( v1 == null ) {
274 v1 = new Vektor ( pkoord [ 0 ] , pkoord [ 1 ] , pkoord [ 2 ] ) ;
275 continue ;
276 }
277 } else i f ( navn . e q u a l s ( ” r e t n i n g s v e k t o r 2 ” ) ) {
278 i f ( v2 == null ) {
279 v2 = new Vektor ( pkoord [ 0 ] , pkoord [ 1 ] , pkoord [ 2 ] ) ;
280 continue ;
281 }
282 }
283 // røg i k k e ind i en a f i f t e s t e n e
284 throw new XMLParseError ( ” Forkert id a t t r i b u t i ” ) ;
285 }
286
287 i f ( ! checkTrekant (p , v1 , v2 ) ) {
288 throw new XMLParseError ( ” Vektorer og punktet i ”+
289 ” d e f i n e r e ikke et plan ” ) ;
290 }
291 return new Plan ( p , v1 , v2 , f a r v e ) ;
292 }
293
294 private Mesh lavMesh ( Node n ) throws XMLParseError {
295 Color f a r v e ;
296 Punkt [ ] punkter ; // h o l d e r t i l de mulige t r e k a n t h j ø e r n e r
297 Trekant [ ] t r e k a n t e r ; // h o l d e r t i l de t r e k a n t e r som opbygges
298 NodeList nl ; // g e n e r e l n o d e l i s t
299 Node [ ] n l a r r ;
300 int antalPunkter ;
301 int antalTrekanter ;
302
303 // f i n d f a r v e .
304 Node f = ( Node ) findElement ( n , ” f a r v e ” ) ;
305 int [ ] rgb = rgbFarver ( f ) ;
306 f a r v e = new Color ( rgb [ 0 ] , rgb [ 1 ] , rgb [ 2 ] ) ;
307
308 // f i n d ud a f ” a n t a l p u n k t e r ” a t t r i b u t t e n , og sammenlign a n t a l ” punkt ”
309 Element punkterNode = findElement (n , ” punkter ” ) ;
310 // f i n d e s ” a n t a l p u n k t e r ” ?
311 S t r i n g apAttr = punkterNode . g e t A t t r i b u t e ( ” a n t a l p u n k t e r ” ) ;
312 i f ( apAttr == ”” ) {
313 throw new XMLParseError ( ” mangler a n t a l p u n k t e r a t t r i b u t ” ) ;
314 }
315 try {
111

316 antalPunkter = I n t e g e r . p a r s e I n t ( apAttr ) ;
317 } catch ( RuntimeException exn ) {
318 throw new XMLParseError ( ”’s a n t a l p u n k t e r ”+
319 ” i f o r k e r t format ” ) ;
320 }
321
322 // f i n d a n t a l a f elementer .
323 n l a r r = findElementer ( punkterNode , ”punkt” ) ;
324 // ( ( Element )n ) . getElementsByTagName (” punkt ” ) ;
325 i f ( n l a r r . length ! = antalPunkter ) { // sammenlign
326 throw new XMLParseError ( ” Ikke samstemmende a n t a l ”+
327 ” punkter i ” ) ;
328 }
329
330 // k r e e r punkter array
331 punkter = new Punkt [ antalPunkter ] ;
332 for ( int i = 0 ; i < n l a r r . length ; i ++) {
333 // f i n d i d a t t r i b u t e , brug d e t t e som indgang i punkter [ ] ;
334 try {
335 int j = I n t e g e r . p a r s e I n t ( ( ( Element ) n l a r r [ i ] ) . g e t A t t r i b u t e ( ” id ” ) ) ;
336 i f ( punkter [ j ] == null ) {
337 double [ ] pkoord = punkter ( n l a r r [ i ] ) ;
338 punkter [ j ] = new Punkt ( pkoord [ 0 ] , pkoord [ 1 ] , pkoord [ 2 ] ) ;
339 } else {
340 throw new XMLParseError ( ”Samme punkt d e f i n e r e t to gange” ) ;
341 }
342 // her fanges , h v i s i n t c o n v e r t e r i n g e n i k k e g i k godt
343 // e l l e r h v i s i d a t t r i b u t t e n mangler
344 // e l l e r h v i s i d a t t r i b u t t e n er uden f o r 0 − a n t a l p u n k t e r
345 } catch ( RuntimeException exn ) {
346 throw new XMLParseError ( ” mangler id a t t r i b u t , ”+
347 ” e l l e r i f o r k e r t format ” ) ;
348 }
349 }
350
351 // f i n d ud a f ” a n t a l t r e k a n t e r ” a t t r i b u t t e n ,
352 // og sammenlign a n t a l ” t r e k a n t ”
353 // f i n d e s ” a n t a l p u n k t e r ”?
354 S t r i n g atAttr = findElement ( n , ” t r e k a n t e r ” ) . g e t A t t r i b u t e ( ” a n t a l t r e k a n t e r ” ) ;
355 i f ( atAttr == ”” ) {
356 throw new XMLParseError ( ” mangler ”+
357 ” a n t a l t r e k a n t e r a t t r i b u t ” ) ;
358 }
359 try {
360 antalTrekanter = I n t e g e r . p a r s e I n t ( atAttr ) ;
361 } catch ( RuntimeException exn ) {
362 throw new XMLParseError ( ”’s a n t a l p u n k t e r ”+
363 ” i f o r k e r t format ” ) ;
364 }
365
366 // f i n d a n t a l a f < t r e k a n t /> elementer .
367 nl = ( ( Element ) n ) . getElementsByTagName( ” trekant ” ) ;
368 i f ( nl . getLength ( ) ! = antalTrekanter ) {
112

369 throw new XMLParseError ( ” Ikke samstemmende a n t a l ”+
370 ” t r e k a n t e r i ” ) ;
371 }
372
373 // l a v t r e k a n t e r
374 t r e k a n t e r = new Trekant [ antalTrekanter ] ;
375 for ( int i = 0 ; i < nl . getLength ( ) ; i ++) {
376 // f i n d de t r e t a l , som a f g ø r h v i l k e
377 // punkter udspænder t r e k a n t e n
378 Element elm = ( Element ) nl . item ( i ) ;
379 Punkt p1 , p2 , p3 ;
380 try {
381 p1 = punkter [ I n t e g e r . p a r s e I n t ( elm . g e t A t t r i b u t e ( ”p1” ) ) ] ;
382 p2 = punkter [ I n t e g e r . p a r s e I n t ( elm . g e t A t t r i b u t e ( ”p2” ) ) ] ;
383 p3 = punkter [ I n t e g e r . p a r s e I n t ( elm . g e t A t t r i b u t e ( ”p3” ) ) ] ;
384 } catch ( RuntimeException exn ) {
385 throw new XMLParseError ( ”’ s p1/p2/p3 a t t r i b u t ”+
386 ” mangler / f o r k e r t format ” ) ;
387 }
388 i f ( ! checkTrekant ( p1 , p2 , p3 ) ) {
389 throw new XMLParseError ( ”’ s p1/p2/p3 ”+
390 ” d e f i n e r e ikke en trekant ” ) ;
391 }
392 t r e k a n t e r [ i ] = new Trekant ( p1 , p2 , p3 , f a r v e ) ;
393 }
394 return new Mesh ( trekanter , f a r v e ) ;
395 }
396
397 private Kamera lavKamera ( Node n , int j ) throws XMLParseError {
398 int b = 0 ; // hoejde
399 int h = 0 ; // bredde
400 Vektor l = null ; // c o c k p i t v i n d u e l o d r e t
401 Vektor v = null ; // c o c k p i t v i n d u e v a n d r e t
402 Punkt p = null ; // p i l o t o e j e
403 Punkt s = null ; // c o c k p i t v i n d u e s t e d p u n k t
404 S t r i n g f i l n a v n ; // f i l n a v n , h e n t e t f r a < p i l o t s y n />’ s i d
405 Node [ ] n l a r r ; // g e n e r e l node array
406
407 // v i f i n d e r og checker højde og bredde
408 Element elm = ( Element ) n ;
409 try {
410 h = I n t e g e r . p a r s e I n t ( elm . g e t A t t r i b u t e ( ” hoejde ” ) ) ;
411 b = I n t e g e r . p a r s e I n t ( elm . g e t A t t r i b u t e ( ” bredde ” ) ) ;
412 } catch ( NumberFormatException exn ) {
413 throw new XMLParseError ( ”’s hoejde / bredde ”+
414 ” ikke i k o r r e k t format ” ) ;
415 } catch ( RuntimeException exn ) {
416 throw new XMLParseError ( ” mangler ”+
417 ” bredde e l l e r hoejde ” ) ;
418 }
419 i f ( h < 1 | | b < 1) {
420 throw new XMLParseError ( ”’s hoejde / bredde ”+
421 ” s k a l være p o s i t i v e ” ) ;
113

422 }
423
424 // v i f i n d e r f i l n a v n
425 try {
426 f i l n a v n = elm . g e t A t t r i b u t e ( ” id ” ) ;
427 // v i s ø r g e r f o r at f i l n a v n / i d er u n i k t
428 for ( int i = 0 ; i < f i l n a v n e . length ; i ++) {
429 i f ( f i l n a v n e [ i ] == null ) {
430 f i l n a v n e [ i ] = f i l n a v n ;
431 break ;
432 } else i f ( f i l n a v n e [ i ] . e q u a l s ( f i l n a v n ) ) {
433 throw new XMLParseError ( ” mangler ”+
434 ” unik id a t t r i b u t ” ) ;
435 }
436 }
437 } catch ( RuntimeException exn ) {
438 throw new XMLParseError ( ” mangler id a t t r i b u t ” ) ;
439 }
440
441 n l a r r = findElementer ( n , ”punkt” ) ;
442 i f ( n l a r r . length ! = 4 ) {
443 // der s k a l være f i r e elementer
444 throw new XMLParseError ( ”Mangler i < p i l o t s y n />.” ) ;
445 }
446
447 for ( int i =0; i

475 continue ;
476 }
477 }
478 throw new XMLParseError ( ” Forkert id a t t r i b u t i ” ) ;
479 }
480 // check f o r at se , om f i l m e n d e f i n e r e e t plan . e l l e r s f o r k a s t .
481 i f ( ! checkTrekant ( s , l , v ) ) {
482 throw new XMLParseError ( ” d e f i n e r e ikke ”+
483 ” et plan f o r vinduet ” ) ;
484 }
485 return new Kamera(p , s , l , v , h , b , f i l n a v n ) ;
486 }
487
488 private Sol l a v S o l ( Node n ) throws XMLParseError{
489 Color c ;
490 Punkt p ;
491
492 // f i n d f a r v e element
493 Node f = ( Node ) findElement ( n , ” f a r v e ” ) ;
494 int [ ] rgb = rgbFarver ( f ) ;
495 c = new Color ( rgb [ 0 ] , rgb [ 1 ] , rgb [ 2 ] ) ;
496
497 // f i n d p o s i t i o n f o r s o l
498 double [ ] pkoord = punkter ( findElement ( n , ”punkt” ) ) ;
499 p = new Punkt ( pkoord [ 0 ] , pkoord [ 1 ] , pkoord [ 2 ] ) ;
500 return new Sol (p , c ) ;
501 }
502
503 public Scene hentScene ( ) {
504 return new Scene ( f i g u r , s o l ) ;
505 }
506
507 public KameraVinkler hentKameraVinkler ( ) {
508 return new KameraVinkler( kamera ) ;
509 }
510 }
115

Litteratur
[1] Eric Jul. Erics kogebog. http://www.diku.dk/undervisning/2003f/dat0gb/kogebog.html.
[2] Eric Jul. Diku flight simulator 2004. Technical report, Datalogisk Institut, København
Universitet, 2003. Datalogi 0GB: K-opgave.
[3] James E. Rumbaugh. Modeling models and viewing views: A look at the model-viewcontroller
framework. JOOP 7(2), pages 14–20, 1994.
[4] Søren Sjørup. Pilotsyn. http://www.diku.dk/undervisning/2003f/dat0gb/pilotsyn.ps,
2003.
[5] w3.org. Well-formed xml documents. http://www.w3.org/TR/2000/REC-xml-
20001006#sec-well-formed.
[6] Perdita Stevens with Rob Pooley. Using UML: software engineering with objects and
components. Object Technology Series. Addison-Wesley Longman, 1999. Updated edition
for UML1.3: first published 1998 (as Pooley and Stevens).
116