Implementation af en ray-tracer med antialiasing

Transkript

1 Roskilde Universitetscenter Datalogi OB Implementation af en ray-tracer med antialiasing (Implementation of a ray-tracer with antialiasing) En 1. moduls projektrapport af: Gruppe 29, Hus 42 Benjamin Beyer Kasper G. Christensen Lars Schjøth Vejleder: Henrik Høltzer Efteråret 2001

2 Abstract Målet med dette projekt var at udvikle en ray-tracer. Rapporten indeholder derfor en kort gennemgang af den bagvedliggende teori for ray-tracere og det tilhørende begreb antialiasing. Derudover beskrives, hvordan vi forestiller os, en ray-tracer skal opbygges. For at kunne teste programmet, er der lavet en brugergrænseflade, via hvilken man kan tilgå ray-traceren. De egenskaber, der ses som nødvendige for vores ray-tracer, fastsættes i en række krav til programmets funktionalitet. Disse krav er, at ray-traceren skal have en scene, der er sammensat af forskellige elementer og skal implementere lys og et kamera, så man kan kigge på elementerne i scenen. Programmet beskrives ud fra en række designmønstre. Til slut konkluderes, at alle de krav der er blevet stillet er blevet opfyldt, samt at visse dele af programmet er blevet udvidet, i forhold til det målsætningen specificerede. English abstract The goal of this project was to develop a ray tracer. Because of this, this thesis contains a brief summary of the theory of ray tracers and the related subject antialiasing. Also described is how we imagine a ray tracer should be constructed. To be able to test the program a user interface has been made, with which the ray tracer can be accessed. The properties, that are regarded necessary for our ray tracer, are written down in a list of demands that the functionality of the program must fulfil. These demands include that the ray tracer must have a scene, which is constructed of different elements, and that it must implement light and a camera, so that it is possible to look at the elements in the scene. How the program has been designed is described by comparing it to a number of design patterns. Finally it is concluded that all the demands we set have been fulfilled, and that certain parts of the program have been expanded compared to the specified goals.

3 Indholdsfortegnelse 1 INDLEDNING OVERORDNET MÅLSÆTNING MÅLGRUPPE RAY-TRACING GRUNDLÆGGENDE BESKRIVELSE AF RAY-TRACING BELYSNINGSMODELLER Ambient belysning Diffus belysning SCENEMODELLERING Boolske operationer PRÆCISIONSPROBLEMER ALIASING ALIASING I RAY-TRACING ANTIALIASING I RAY-TRACING KRAVSPECIFIKATION PROGRAMDESIGN OVERORDNEDE DESIGN-OVERVEJELSER Designmål Designmønstre Indkapsling Modulær opbygning SAMLET DESIGN-OVERBLIK MØNSTRE Template (AbstractTracer) Observer (AbstractTracer / TracerPanel) Facade (TracerApplet / TracerPanel) Strategy (Scene / Scene-element / Camera / Tracer) Whole-Part (Scene/SceneElement) Composite (SceneElement samt sub-klasser) IMPLEMENTATIONSDETALJER BEREGNING AF KAMERAET viewplaneheight, -Width og dist ViewPlaneHeight og -Width overfor xres og yres recalculatecamera getpixelcoord ANTIALIASING ALGORITMERNE Ingen antialiasing Supersampling Stokastisk antialiasing SCENEELEMENT Sphere...35

4 6.3.2 Plane TrianglePlane ElementIntersection og ElementSubstraction BELYSNINGSMODELLER Ambient belysning Diffus reflektion BRUGSTEST BELYSNINGSMODELLER KAMERAET ANTIALIASING Beregningstider DISKUSSION KONKLUSION PERSPEKTIVERING LITTERATURLISTE BØGER INTERNETADRESSER APPENDIKS A KORT VEJLEDNING TIL BRUGERGRÆNSEFLADEN... I 12.1 SCENEMANIPULERING...I 12.2 ÆNDRING AF KAMERAET...I 12.3 ÆNDRING AF LYSKILDER...I 12.4 VALG AF ANTIALIASING OG KØRSEL AF TRACEREN...I 13 APPENDIKS B CD ENS INDHOLD...II 14 APPENDIKS C KILDEKODE... III

5 Side 5 1 Indledning Billedsyntese på computere er en kompleks disciplin, der med mere og mere velfungerende algoritmer, efterhånden har fundet anvendelse mange steder. Nogle af de anvendelser der kan nævnes, er inden for filmindustrien, både til effekter i traditionelle spillefilm, og til avancerede tegnefilm, samt inden for andre områder hvor visualisering anvendes, for eksempel arkitektur, computerspil og kunstværker fremstillet med computeren som værktøj. En meget anvendt algoritme til billedsyntese er ray-tracing. Algoritmen har været anvendt som enkeltstående metode, men bruges nu i stigende grad i samspil med andre algoritmer (som f.eks. radiosity som ikke beskrives yderligere i denne rapport). Der findes mange mere eller mindre raffinerede og komplekse varianter af ray-tracing algoritmen. Nogle er optimeret med hensyn til hastighed og andre billedets realisme. Grundideen i dem alle er dog den samme: At beregne lysstrålers baner i et virtuelt rum med virtuelle objekter, og på baggrund af de beregnede interaktioner med objekterne generere et billede. Når ray-tracing benyttes til billedsyntese, er der nogle problemer der skal løses. Disse omfatter blandt andet problemer med begrænset nøjagtighed samt såkaldt aliasing. Aliasing er visuelle problemer der opstår, fordi det syntetiserede billede er digitalt, og det kan komme til udtryk som eksempelvis hakkede og ujævne kanter i billedet. Der er udviklet en lang række metoder til at afhjælpe sådanne problemer (de såkaldte anti-aliasing algoritmer). Antialiasing medvirker ofte til at gøre en ray-tracing væsentligt mere beregningstung, men kan også forbedre billedet betydeligt. [Glassner; 1991] I nærværende projektrapport beskæftiger vi os med ray-tracing og antialiasing. Rapporten er skrevet som et 1. moduls projekt på datalogioverbygningen på RUC, og har som sådan til formål at give de studerende erfaring i at planlægge, implementeret, afprøve og dokumentere middelstore programmeringsopgaver. På denne baggrund omhandler denne projektrapport design og udvikling af en ray-tracer (dvs. et program der benytter en ray-tracing algoritme til billedsyntese). Ray-traceren ønskes implementeret så den understøtter flere forskellige antialiasingalgoritmer, således at disse kan sammenlignes visuelt såvel som hastighedsmæssigt. Dette fører frem til følgende overordnede målsætning for projektet. 1.1 Overordnet målsætning Det overordnede formål med dette projekt er at udvikle en ray-tracer, der understøtter flere antialiasing-algoritmer. Da der ikke, inden for dette projekts rammer, kan udvikles en ray-tracer på niveau med dagens standarder, sættes det som en vigtig betingelse, at den udviklede løsning er åben for udvidelser. En mere nøjagtig specifikation af kravene til løsningen udsættes til afsnit 4 Kravspecifikation, da en del begreber må kendes for at gøre denne forståelig. 1.2 Målgruppe Denne projektrapport er henvendt til personer med interesse i grundlæggende ray-tracing samt udvikling af en raytracer. Der forudsættes således ikke et kendskab til ray-tracing, men en matematisk viden inden for rumgeometri er nødvendig, for at kunne følge de mere tekniske beskrivelser af ray-tracing. For at få fuldt udbytte af rapporten må det endvidere anbefales at læseren har programmeringserfaring med et objektorienteret sprog gerne Java, da begreber som klasser, interfaces, objekter, nedarvning, polymorfi osv. forudsættes at være velkendte.

6 Side 6 2 Ray-tracing Dette afsnit har til formål, at introducere læseren af denne rapport til grundbegreberne indenfor ray-tracing for således at lette forståelsen af det beskrevne program. Først beskrives grundideen i ray-tracing på et overordnet niveau. Derefter går vi lidt mere i dybden med nogle vigtige aspekter af ray-tracing: Belysningsmodeller og scenemodellering. Endelig beskrives et generelt problem, der ofte opstår i forbindelse med ray-tracing nemlig problemer med endelig præcision. 2.1 Grundlæggende beskrivelse af ray-tracing Ray-tracing er en kendt og meget anvendt billedsynteseteknik, der bygger på kendte fysiske teorier om lysets udbredelse i rummet. Ideen er, at et tilnærmet fotorealistisk billede kan genereres ved sporing af lysets stråler i en kunstig tredimensionel verden. Ray-tracing gør det derfor muligt at simulere både skygge, refleksion og gennemsigtighed. [Glassner; 1991] For lettere at forstå dette, må man kende lidt fysik. Det menneskelige øje giver hjernen sanseindtryk, ved at nerver i øjet opfatter de fotoner (lysstråler), der rammer dem. Lysstrålernes farve er bestemt af de objekter, de har ramt, inden de når øjet. Kommer en lysstråle fra en rød bold, er lysstrålen så at sige farvet rød af bolden. Lyset kommer selvfølgelig sjældent direkte fra selve bolden, men fra en anden lyskilde hvis lys reflekteres af bolden for derefter at ramme øjet. En lyskilde udsender et stort antal lysstråler, og kun et fåtal af disse rammer øjet. I ray-tracing følges lysstrålerne i modsat retning, altså fra øjet og ud i et tredimensionelt rum og hen til lyskilden. Således bliver kun de lysstråler, der er vigtige for billedet beregnet. [Glassner; 1991] En tracer består af følgende: Et matematisk, tredimensionelt rum. Dette rum kaldes ofte scenen, og er beskrevet ved et tredimensionelt koordinatsystem. Matematiske objekter (elementer) som eksisterer i scenen. Elementer kan være kugler, planer, kasser og andre objekter der kan beskrives i et tredimensionelt koordinatsystem ud fra matematiske ligninger. Lyskilder som bringer lys til scenen, for eksempel en punktlyskilde, behøver ikke være beskrevet som andet end et punkt i rummet og eventuelt en intensitet. Et kamera, som så at sige er øjet der ser ind i scenen. Kameraet kan forstås som et traditionelt kamera bare i virtuel forstand: Det kan flyttes, zoome og ændre perspektiv. Derudover kan det selvfølgelig tage billeder af scenen. Kameraet kan beskrives ved et punkt i rummet, der angiver dets position, ofte kaldet COP (Center Of Projection), samt specificering af kameraets orientering og visuelle egenskaber (f.eks. linsevinkel og billedopløsning). Billedet er en todimensional projektion af den tredimensionelle scene. Billedet beregnes ved at vektorer, forstået som lysstråler, beregnes i scenen. Vektorens skæring med scenens elementer har betydning for hvad der ses på billedet. Dette er illustreret på Figur 2.1. Øjet, forstået som kameraet, ser ind i scenen. Det todimensionale plan repræsenterer et bitmap og er beskrevet ved et antal pixler. Dette plan kaldes viewplanet. Gennem hver pixel beregnes en eller flere vektorer, afhængig af den benyttede ray-tracing algoritme, skærer vektoren med et element bestemmes pixlens farve af dette. Skærer vektoren ingen elementer får pixlen samme farve som baggrunden. Hvordan belysningen mere nøjagtigt beregnes, vil blive beskrevet i afsnittet: 2.2 Belysningsmodeller.

7 Side 7 Figur 2.1: Således vil et billede af det kunstige rum blive genereret ved ray-tracing. Øjet symboliserer kameraets position (COP = Center Of Projection). Planet strålen traces igennem kaldes viewplanet. 2.2 Belysningsmodeller Når en stråle traces som ovenfor, findes der flere metoder, der benyttes til at afgøre, hvor intens farven i et givent punkt skal være. Disse metoder bruges ofte sammen, og kunne betegnes belysningsmodeller, da det drejer sig om at afgøre, hvor oplyst et givent punkt er. Beregningen af belysningen i et punkt, resulterer i en skaleringsfaktor, som det belyste elements farve skaleres med. I de følgende afsnit beskrives de belysningsmodeller, der refereres til i dette projekt Ambient belysning Ambient belysning er en simpel belysningsmodel, som oftest benyttes i kombination med andre modeller, og som modellerer det faktum, at et rum sjældent er totalt mørkt. Der vil være en hvis lysstråling der reflekteres fra alle flader i rummet. Lyset vil således også nå ind under eksempelvis et bord, så skyggen fra bordet ikke er fuldkommen sort, selvom ingen lyskilder er placeret, så lyset falder direkte ind under bordet. Dette skyldes, at lyset spredes og reflekteres fra alle genstande i rummet (sceneelementerne). Skulle dette modelleres ved at beregne alle de reflekterede lysstråler, ville tracingen blive uhensigtsmæssigt beregningskrævende, så i stedet tilføjes en lille smule lys til alle elementer i scenen. Denne kunstige belysning, som man kan opfatte som om elementerne er en smule selvlysende, kaldes ambient belysning, og er altså et udtryk for den minimums-belysning, der vil være på alle elementer i scenen. [Glassner; 1991] Ambient belysning kan for eksempel angives som en faktor, der angiver den mindste skaleringsfaktor, som et elements farve må skaleres med. Findes et punkt hvor de øvrige belysningsmodeller angiver en lavere skaleringsfaktor, benyttes ambient-faktoren. Det er muligt at benytte ambient-belysning alene, og man kan for eksempel trace et billede med fuld ambient belysning, hvilket i praksis betyder, at alle punkter på et sceneelements overflade farves i sceneelementets farve. Dette svarer til en ambient-faktor på 1. Når der udelukkende benyttes ambient belysning, forsvinder den rumlige virkning, da der ikke vil forekomme nogen skygger Diffus belysning Diffus belysning modellerer belysning af matte overflader med en ru mikrostruktur. Sådanne overflader reflekterer lige meget lys i alle retninger (da den mikroskopiske ruhed i overfladen spreder lyset). I praksis opfører de fleste materialer sig på en måde, der modsvares af denne model. Hvor meget lys der reflekteres fra et givent punkt, afgøres af, hvor direkte belyst punktet er. Falder lyset vinkelret ind på overfladen (dvs. en vinkel på 0 grader med overfladens normalvektor), vil den være fuldt oplyst. Jo større afvigelse fra dette indfaldsvinklen udviser, des mindre belyst er overfladen. Når indfaldsvinklen når 90 grader med overfladenormalen, dvs. lyset er parallelt med overfladen, reflekteres det ikke længere fra punktet. Sammenhængen mellem vinkel og belysning er imidlertid ikke lineær, men modelleres typisk som cosinus til indfaldsvinklen. [Glassner; 1991]

8 Side 8 For at modellere diffus belysning, må der indføres lyskilder, der angiver hvorfra i scenen, lyset kommer. Når en stråle traces til et punkt på et sceneelement, beregnes der en vektor herfra og gennem lyskilden. Denne vektor kaldes skyggevektoren. Vinklen mellem denne skyggevektor og normalvektoren i punktet afgør belysningsfaktoren, som beskrevet ovenfor. Skærer skyggevektoren imidlertid med et andet sceneelement, der ligger foran lyskilden, kan lyset fra lyskilden ikke nå punktet, der derfor ligger i total skygge. For at afgøre om punktet er i skygge, er det nødvendigt at beregne afstanden fra skæringspunktet til skyggevektorens skæringspunkt. Dette illustreres på Figur 2.2, Figur 2.3 og Figur 2.4. Benyttes udelukkende diffus belysning, vil et punkt i skygge være sort (skaleringsfaktor 0), men anvendes der også ambient belysning, belyses punktet som beskrevet i foregående afsnit (2.2.1 Ambient belysning). Figur 2.2: En stråle traces ind i en scene, med en kugle og et plan. Skyggevektoren skærer ingen elementer. Skæringspunktet er ikke i skygge Figur 2.3: Skyggevektoren skærer et element. Afstanden til skyggevektorens skæring er mindre end til lyskilden. Skæringspunktet er i skygge. Figur 2.4: Skyggevektoren skærer et element. Afstanden til skyggevektorens skæring er større end til lyskilden. Skæringspunktet er ikke i skygge. 2.3 Scenemodellering Den scene der traces skal naturligvis modelleres. Ethvert sceneelement skal besidde en række egenskaber, for at kunne indgå i en tracing. Således skal der kunne foretages en skæringsberegning i forhold til et element, og normalvektoren i et eventuelt skæringspunkt skal kunne findes. Skæringsberegningen benyttes til at afgøre, om en lysstråle (beregnet som en vektor i rummet) rammer elementet, og hvis dette er tilfældet, benyttes normalvektoren til beregning af belysning i punktet, som beskrevet i afsnit Diffus belysning. Endvidere kan det være nødvendigt, at kunne afgøre om et punkt ligger inden i elementet, årsagen til dette beskrives i efterfølgende afsnit.

9 Side 9 Et sceneelement modelleres ud fra nogle matematiske ligninger, for eksempel repræsenteres en kugle ved dens ligning, hvorved det er muligt at beregne skæring med vektorer, samt finde normalen i et hvilket som helst punkt på kuglens overflade. Det er naturligvis også muligt at modellere mange andre elementer som for eksempel planer, kasser, cylindre, pyramider osv. I praksis indfører man ofte et sceneelement, der repræsenterer et trekantet planudsnit. Alle ikke-krumme overflader kan da opbygges af disse trekanter. Krumme overflader kan også tilnærmes med disse. Sceneelementer må, ud over deres rumlige udformning, også specificere egenskaber, der angiver, hvorledes de interagerer med lys. Dette er først og fremmest elementets farve, men kan også indbefatte egenskaber så som refleksion, ruhed og struktur. Disse egenskaber modelleres ofte som et, til elementet tilknyttet, materiale. For at gøre fleksibiliteten større, kan man benytte såkaldte boolske funktioner, til at kombinere ovennævnte typer af sceneelementer til sammensatte elementer Boolske operationer Boolske operationer er en betegnelse, for en måde at kombinere sceneelementer på, således at et sceneelement kan dannes ved kombination af andre elementer. De typiske boolske operationer er: subtraktion, foreningsmængde og fællesmængde. Disse operationer svarer til klassiske mængdebegreber, og illustreres på figurerne herunder. Det mørke område viser det element, der fremkommer, når den boolske operation udføres på de 2 indgående sceneelementer. Figur 2.5: Fællesmængde (intersection) Figur 2.6: Subtraktion (subtraction) Figur 2.7: Foreningsmængde (union) Ud fra primitive elementer, samt de i dette afsnit beskrevne operationer, er det muligt at opbygge en lang række forskelligartede sceneelementer til brug ved tracing. 2.4 Præcisionsproblemer I forbindelse med ray-tracing kan der ofte opstå problemer på grund af computerens endelige præcision. Da en computer altid må foretage numeriske beregninger med endelig præcision, vil der opstå afrundingsfejl. Disse fejl er i mange anvendelser irrelevante, da de ofte er af en meget lille størrelsesorden, men i ray-tracing kan disse fejl få betydning. Når skæring med et element beregnes, gælder det i matematikken, at det nøjagtige resultat altid ligger på overfladen (f.eks. på kuglens periferi). Når den faktiske beregning foretages på en computer, vil den endelige nøjagtighed føre til, at det beregnede punkt i virkeligheden ligger en lille smule ved siden af elementet. Dette kan føre til at det beregnede skæringspunkt ligger inden i elementet. Den lille forskydning kan umiddelbart syntes underordnet, da den er af meget lille størrelsesorden og ved ambient belysning er det da også ligegyldigt. Imidlertid kan der ske uhensigtsmæssige ting, når der regnes videre ud fra punktet. Er punktet, på grund af en præcisionsfejl, placeret inden i kuglen, vil der ved beregning af diffus belysning, ske det, at skyggevektoren skærer kuglen selv, på vej til lyskilden (illustreret på Figur 2.8), og derfor vil traceren vise punktet som værende i skygge. Dermed kan overfladen skygge for sig selv, hvilket giver anledning til nogle besynderlige visuelle resultater.

10 Side 10 Figur 2.8: På grund af endelig præcision, findes et skæringspunkt der ligger inden for sceneelementet. Derved kan overfladen skygge for sig selv For at undgå disse problemer, kan der vedtages nogle konventioner, som alle sceneelementer skal overholde. For eksempel kan det kræves, at ethvert skæringspunkt skal ligge på samme side af en overflade, som strålen, hvis skæring beregnes, kommer fra. Dermed kan en overflade ikke længere skygge for sig selv. Denne opførsel kan for eksempel opnås ved at beregne normalen således, at den peger til den side af overfladen, som strålen kommer fra, og derpå flytte skæringspunktet en smule i normalens retning. Denne lille forskydning skal være af en størrelsesorden, der sikrer, at punktet altid ligger på den vedtagne side af overfladen, men må samtidig ikke være så stor, at den kan ses på det tracede billede. Dette er normalt ikke noget problem. Den opnåede nøjagtighed kan for eksempel være i størrelsesordenen 10-12, mens der benyttes elementer med størrelser angivet i størrelsesordenen 10 2.

11 Side 11 3 Aliasing Aliasing opstår fordi instrumenter som datamater, CD-afspillere og kameraer er digitale. Digitale instrumenter kan ikke gengive et sammenhængende signal, da de til et givent tidspunkt kan befinde sig i én og kun én tilstand, uafhængigt af hvilke tilstande der kom før eller efter den nuværende. Al digital repræsentation eksisterer altså i endelige uafhængige tilstande. En effekt af dette ses i Figur 3.1. For at repræsentere et billede, deles det op i bidder/pixels, det ses ikke normalt, da øjet bedrager én til at se det som et sammenhængende billede, men ved forstørrelse fremkommer de enkelte pixels. Det samme gælder lyd-repræsentation; at en digitaliseret lydbølge lyder præcis som den analoge, skyldes udelukkende det faktum, at antallet af bidder/samples er så højt, at ændringen ikke kan høres. Figur 3.1: Forstørrelse af et bitmap - Ved forstørrelse ses at repræsentationen er diskontinuert. Så hvad er aliasing? Aliasing er mange ting og ses mange steder, men årsagen er den samme: Digitale instrumenters manglende evne til at danne et sammenhængende signal. Aliasing opstår, når øjet eller øret ikke snydes længere. Det ses i simple tegneprogrammer, når opløsningen er lav, og man tegner en skrå linje som i Figur 3.2. Tydelige hakker fremkommer langs linjens kant, problemet kan selvfølgelig løses ved bedre opløsning, men hakkerne vil altid være der og ses ved forstørrelse. Dette kaldes spatial aliasing [Glassner; 1991]. Figur 3.2: Spatial aliasing i en skrå linje. Ved gengivelse af levende billeder kan aliasing også forekomme. Denne form for aliasing kaldes temporal og lader sig blandt andet se i film. Skønt det normalt ikke ses, er en film, som man ser den i biografen eller i fjernsynet, ikke andet end en række stillbilleder, der afspilles i så høj fart (typisk 25 billeder per sekund), at vores øje, eller rettere vores hjerne, lader sig snyde. Det sker dog i enkelte tilfælde, at filmens ikke sammenhængende natur viser sig, som når hjulet på en bil tilsyneladende begynder at dreje i modsat retning af køreretningen. Dette sker fordi bilens eger (hjulkapslen) bevæger sig så hurtigt, at stillbillederne fanger egerne i en position, der tilsyneladende får hjulet til at dreje den forkerte vej. Dette er temporal aliasing [Glassner; 1989].

12 Side Aliasing i ray-tracing I ray-tracing ses både temporal og spatial aliasing. Temporal aliasing kan opstå i animationer genereret med ray-tracing. To eksempler følger: Hvis et objekt ligger på kanten mellem to pixler, kan objektet se ud som om det hopper op og ned, fordi forskellen mellem de to positioner er så lille, at objektet på ét stillbillede befinder sig i én pixel og i det efterfølgende i nabopixlen, og det på trods af, at kameraet stort set står stille. Et andet problem, der kan opstå, er at objekter, der er meget små eller er meget langt væk, nogle gange kan ses og andre gange ikke. Det er nemlig ikke sikkert at strålen fra en pixel rammer objektet, men flyttes kameraet lidt, kan det være, at objektet alligevel rammes, og det vil så se ud som om objektet pludselig forsvinder eller pludselig kommer til syne. [Glassner; 1991] Spatial aliasing ses som hakkede kanter på objekter og skygger. Disse skyldes at der ved traditionel ray-tracing sendes én stråle gennem hver pixel, der så enten rammer eller ikke rammer et givent objekt. Et objekt befinder sig derfor enten i en pixel eller ikke i en pixel. Dette skaber de, før omtalte, hakkede kanter. Se Figur 3.3. Figur 3.3: Venstre - repræsenterer et optimalt billede af en ellipsoide. Højre - samme ellipsoide ray-tracet traditionelt (en stråle per. pixel) ved lav opløsning. Der er her tale om at strålen enten rammer ellipsoiden eller ikke. 3.2 Antialiasing i ray-tracing I denne rapport vil det kun være spatial aliasing, der bliver behandlet, da den implementerede ray-tracer er programmeret til syntese af enkeltbilleder. Det skal dog nævnes, at de omtalte og implementerede antialiasingalgoritmer, i mange tilfælde nedsætter temporal aliasing. Den simpleste antialiasing-teknik i ray-tracing omtales i litteraturen som supersampling [Glassner; 1991] [Foley; 1990]. Teknikken går i al sin enkelhed ud på, at der sendes et større antal stråler gennem hver pixel. Hver stråle returnerer en farve, som derefter bruges til at finde et farvegennemsnit for pixlen. For en pixel der ligger i et objekts kantområde, vil nogle stråler ramme objektet, mens andre vil ramme enten baggrunden eller et andet objekt. Gennemsnitsfarven vil derfor være en farve, der ligger imellem eksempelvis baggrundsfarven og objektets farve. Således vil kanter blive uldne i stedet for hakkede, hvilket virker mere naturligt for øjet, som det ses på Figur 3.4. Figur 3.4: venstre - objekt uden antialiasing. Højre - med antialiasing.

13 Side 13 Supersampling er illustreret på Figur 3.5. Gennem hver pixel spores 9 stråler, men antallet kunne lige så godt være højere eller lavere. Antallet er op til programmøren, som må vægte algoritmens hastigheden i forhold til billedkvalitet. Figur 3.5: Supersampling - Et fast antal stråler/vektorer spores gennem pixlen. Et problem ved supersampling er, at der for hver pixel sendes det samme antal stråler igennem, lige meget om den befinder sig i et kantområde eller ej. Dette er ikke optimalt med hensyn til beregningstid. Der er derfor udviklet en udvidet supersampling-algoritme kaldet adaptiv supersampling. Denne algoritme sporer fem stråler; en i hvert hjørne og en i midten af pixlen. Eksisterer der farveforskel, større end en given grænseværdi, mellem de forskellige stråler, spores et ekstra antal stråler, gennem pixlen, i det område hvor der var farveforskel. Dette er illustreret på Figur 3.6. Figur 3.6: Adaptiv supersampling - a) Fem stråler spores gennem pixlen, strålernes farve sammenlignes. Farveforskel, større end grænseværdien, findes mellem to stråler. b) Der spores et nyt antal stråler gennem pixlen i det område farveforskellen findes. En ny farveforskel findes. c) Nye stråler spores gennem pixlen i området hvor farveforskellen findes. - Således forsættes der end til der ikke forekommer nye farveforskelle, større end grænseværdien, eller til et angivet maksimum. Foruden en betydelig hastighedsoptimering, yder adaptiv supersampling også et visuelt bedre resultat, da billedet bliver finere samplet, i de områder der er mest kritiske (eksempelvis kantområder). [Glassner; 1991] Både supersampling og adaptiv supersampling har dog et fælles problem, der skyldes supersamplings ordnede natur. Begge teknikker opdeler billedet i et større antal samples og opnår derved et bedre resultat. Men skønt supersampling og adaptiv supersampling reducerer aliasing-problemer som hakkede kanter, elimineres problemet ikke helt, netop fordi samplingen stadig er ensartet. Der findes en anden antialiasing-algoritme, som undgår de problemer, der opstår ved at benytte ensartet sampling. I stedet for at spore et antal stråler med fast afstand til hinanden gennem hver pixel. Kan strålerne sendes tilfældigt gennem pixlen. Antallet af stråler, der spores, er fast, og de er jævnt fordelt i pixlen, men ellers er de bestemt tilfældigt. Denne form for antialiasing kaldes stokastisk ray-tracing og er illustreret på Figur 3.7. Der findes forskellige metoder til beregning af strålernes fordeling. Den simpleste kaldes jitter, og fungerer ved at placere strålerne jævnt fordelt og derefter tilføje hver stråles placering en lille forskydning i en tilfældig retning (vha. en algoritme til generering af pseudo-tilfældige tal)

14 Side 14 Figur 3.7: Stokastisk ray-tracing - Et fast antal stråler spredt jævnt, men tilfældigt, ud over pixlen. Stokastisk ray-tracing tiltaler det menneskelige øje ved at tilføje en grad af støj til billedet. For det samme antal stråler pr. pixel er stokastisk ray-tracing dog langsommere end supersampling. Stokastisk ray-tracing kan nemlig ikke deles om hjørnestrålerne som i supersampling, så mens der gennemsnitligt kun beregnes ca. 6 stråler for en pixel, hvorigennem der spores 9 stråler i supersampling, beregnes alle 9 i stokastisk ray-tracing. Derudover kræver det også en ekstra beregning pr. stråle, at gøre dem stokastiske. Det visuelle resultatet er til gengæld betydeligt bedre ved stokastisk raytracing.

15 Side 15 4 Kravspecifikation I dette afsnit specificeres, hvilke krav der stilles til den, i forbindelse med dette projekt, implementerede ray-tracer. Da det ikke er muligt at skrive en avanceret ray-tracer inden for rammerne af dette projekt, vil der blive lagt meget vægt på, at det fremstillede produkt kan videreudvikles til en sådan. De overordnede krav til traceren angives her på punktform (i ikke-prioriteret rækkefølge): Traceren skal arbejde ud fra en repræsentation af en scene, der sammensættes af sceneelementer, og som skal kunne udvides med nye typer af sceneelementer. Eksempler på sceneelementer ønskes implementeret. Boolske operationer på sceneelementerne skal kunne implementeres. Det skal være muligt at implementere nye antialiasing-algoritmer, uden at ændre i eksisterende kode. Som minimum skal der implementeres en algoritme uden antialiasing, samt en med. Traceren skal understøtte en simpel belysningsmodel kun med ambient belysning. Det skal være muligt at tilføje mere komplekse belysningsmodeller, uden at ændre i eksisterende kode. Traceren skal arbejde ud fra et kamera. Det skal være muligt at implementere forskellige kamera-typer. Et generelt kamera, der kan placeres frit i scenen, ønskes implementeret. Brugergrænseflade til afprøvningsformål skal opbygges. Der lægges ikke vægt på betjeningen af programmet. Brugergrænsefladen skal være skarpt adskilt fra programlogikken, således at den let kan udskiftes. Det visuelle resultat af tracingen skal kunne følges på skærmen under beregningen, og det endelige resultat skal ligeledes vises på skærmen. Tracingen skal foregå på en separat tråd, således at brugergrænsefladen stadig er tilgængelig, mens der traces, og tracingen skal kunne afbrydes før den er fuldført.

16 Side 16 5 Programdesign I de følgende afsnit beskrives og begrundes designet af det udviklede program. Først ses på nogle generelle designovervejelser, herunder hvilke designmål vi har i sigte samt nogle generelle metoder til at opnå disse. Derpå følger et overblik over det samlede design, der efterfølgende beskrives i detaljer med udgangspunkt i en række design-mønstre. Da programmet er udviklet i Java, er designet generelt bygget op omkring objektorienterede principper og metoder. Til præcisering af begreberne komposition, aggregering og associering til brug ved vores UML-diagrammer, har vi benyttet en definition fundet på Internettet. [UML; 2001] 5.1 Overordnede design-overvejelser I det følgende beskrives nogle overordnede mål, der ligger til grund for vores design-valg. Desuden beskrives nogle generelle teknikker, der er nyttige i forbindelse med at opnå disse mål Designmål Da programmer generelt ændres og udbygges meget i deres levetid, og da det inden for rammerne af dette projekt ikke er muligt at udvikle et program med omfattende funktionalitet, er det et vigtigt mål for vores design, at det skal være let at udvide i mange retninger, uden at kassere eksisterende kode og måske vigtigere: Uden at ændre ved programmets overordnede struktur. Et kriterium, for at vores design er vellykket, er således, at det er simpelt at udvide vores implementation af designet med yderligere funktionalitet, uden at ændre i den generelle struktur. For at opnå at den udviklede kode i høj grad kan udvikles og genbruges, tager vi i vores design udgangspunkt i nogle generelle principper, der kort beskrives i de følgende afsnit Designmønstre Designmønstre opstår ved metodisk indsamling og generalisering af løsninger på design-problemer der ofte opstår i programudviklingen. Et designmønster er således en generel løsning på en klasse af programmeringsproblemer. Formålet med at generalisere og beskrive disse løsninger, er at gøre det muligt at trække på andres og egne tidligere erfaringer fra andre programmeringsprojekter, når et bestemt problem skal løses. Desuden giver designmønstrene os et ordforråd, der kan benyttes, når vi diskuterer design, og hjælper derved med at indfange og beskrive essensen af en given program-struktur. Vi vil i beskrivelsen af vores programdesign, tage udgangspunkt i en række designmønstre. Dette har en beskrivelsesmæssig fordel, da vi derved kan referere til begreber, som kan studeres nærmere i litteratur på området. Desuden giver dét, at være opmærksom på mønstrene, og dermed på andres design-erfaring, en mulighed for systematisk analyse, og dermed sandsynliggøres det også, at designet vil fungere i forbindelse med udvidelser, da dette er afprøvet før i andre kontekster Indkapsling Indkapsling er et begreb, der ofte får en fremtrædende plads i generelle diskussioner af objektorientering. Hovedideen med indkapsling er, at så mange detaljer som muligt skjules for brugeren af en given klasse (klienten). Dette bevirker at den indkapslede klasse bliver lettere at anvende, da klienten ikke skal bekymre sig om uvedkommende detaljer. Da en indkapslet klasse er lettere at anvende, er fejl sjældnere. Fejlmulighederne reduceres ved simpelthen at forhindre direkte tilgang til objektets attributter. I stedet tilgås attributterne via metoder, der ikke tillader, at objektet bringes i en ugyldig tilstand; altså at en af objektets attributter får en værdi, der ikke giver nogen mening, i forhold til det klassen repræsenterer (f.eks. kugle med negativ radius). På denne måde kan klienten altid gå ud fra, at et givent objekt vil opføre sig som foreskrevet. Det gør endvidere fejlfinding langt lettere, da de indkapslede klasser kan testes hver for sig, og fejlen derfor hurtigt isoleres til en given klasse. En yderligere fordel ved indkapsling er, at det bliver muligt at ændre på implementationen af klassen, så længe interfacet (metode-hovederne og konstruktorerne) ikke ændres, uden at behøve at ændre i resten af programmet. Man

17 Side 17 kan endda nøjes med at kompilere den ændrede klasse. Er klassen ikke indkapslet, er det ikke muligt at ændre på objektets attributter eller disses betydning uden at omskrive klient-koden Modulær opbygning Modularitet kan i en vis forstand opfattes som indkapsling på et højere niveau. Et modul er således en logisk afgrænset enhed, ofte bestående af flere objekter, der varetager en velafgrænset opgave. En typisk opdeling er mellem program-logik og brugergrænseflade. Denne opdeling muliggør udvikling af en kerne der varetager den egentlige funktionalitet, samt en grænseflade der håndterer brugerinput og præsenterer data for eksempel på skærm eller printer. Denne opdeling betyder, at programmets brugergrænseflade kan tilpasses til forskellige platforme (f.eks. Windows, Unix el. Mac), uden at ændre ved den grundlæggende funktionalitet i programmet. Desuden gør det koden væsentligt lettere at vedligeholde, at det er muligt at ændre og forbedre programmets logik, uafhængigt af brugergrænsefladens opbygning, og at det tilsvarende er muligt at designe en bedre brugergrænseflade, uden at bekymre sig om hvordan programmets logik virker. I vores design ligger vi vægt på modularitet først og fremmest i kraft af en adskillelse af brugergrænseflade og programlogik. Dette betyder også, at vi kan tillade os at udvikle en relativt primitiv brugergrænseflade, der er velegnet til testformål, med den vished at den ved lejlighed kan udskiftes med noget pænere og mere funktionelt, uden at den fungerende program-logik berøres. 5.2 Samlet design-overblik I dette afsnit tilstræbes det at give et overordnet overblik over programmet, inden der, i de efterfølgende afsnit, ses nærmere på de enkelte dele af designet. Lad os starte med et overordnet klassediagram: Figur 5.1: Overordnet klassediagram, indeholdende de grundlæggende elementer i vores program. AbstractTracer-klassen repræsenterer den fælles funktionalitet for tracere med forskellige antialiasing-algoritmer. Fra AbstractTracer benyttes implementationer af Tracer-interfacet (på Figur 5.1 vises kun AmbientTracer) til at trace én stråle ad gangen. Subklasser til AbstractTracer overskriver tracingprocedure() og implementerer en specifik antialiasing-algoritme (ingen af disse subklasser er vist på Figur 5.1). AbstractTracer indeholder en indre klasse TracingThread, der sørger for at tracingen foregår på en separat tråd. Endvidere har AbstractTracer en reference til et kamera, der benyttes til at beregne de stråler det er relevant at trace. AbstractTracer og Tracer står for den grundlæggende tracing. Den scene der skal traces repræsenteres af Scene, der indeholder et antal sceneelementer (objekter af klasser der implementerer SceneElement-interfacet).

18 Side 18 En simpel tracing i denne model, altså med udgangspunkt i meget simple implementationer (uden lyskilder og uden antialiasing) repræsenteres i følgende collaboration-diagram: Figur 5.2: Collaboration-diagram for en simpel tracing af en scene med en kugle og et plan Med udgangspunkt i klassen NoAATracer, der er en simpel subklasse til AbstractTracer, der simpelthen tracer én stråle gennem hver pixel, foregår tracingen af en enkelt pixel som følger (svarer til diagrammet i Figur 5.2): 1. NoAATracer kalder getcop() i Camera. COP står for Center Of Projection og angiver kameraets placering. 2. NoAATracer kalder getpixelcoord() i Camera. Denne metode returnerer en given pixels scene-koordinater. 3. NoAATracer kalder getraythroughpoints() i VectorCalc. VectorCalc er en klasse der indeholder en række beregningsmetoder, og denne metode beregner en lysstråle gennem 2 punkter (her COP samt en pixel). 4. NoAATracer kalder trace() i AmbientTracer. AmbientTracer er en simpel implementation af Tracerinterfacet, der kun benytter 100% ambient belysning. Trace-metoden kaldes med den i 3. konstruerede lysstråle som parameter. 5. AmbientTracer kalder getintersection() i Scene. Scene repræsenterer scenen, og den kaldte metode returnerer skæring med det nærmeste sceneelement, eller null hvis ingen skæring findes. 6. Scene kalder getintersection() i Sphere. Sphere repræsenterer et konkret sceneelement en kugle, og den kaldte metode returnerer den nærmeste skæring. 7. Scene kalder getintersection() i Plane. Plane repræsenterer et plan, og den kaldte metode returnerer den nærmeste skæring. 8. NoAATracer kalder setpixel() i BufferedImage, for at sætte den tracede pixel til den farve, som kaldet af trace() (i 4) resulterede i. I vores program indgår følgende klasser, der benyttes som datastrukturer og derfor optræder mange steder i programmet. Disse klassers vigtigste funktionalitet er at indeholde, og give adgang til, de ønskede data samt at sikre, at disse data altid er gyldige.

19 Side 19 Figur 5.3: Simple dataklasser der indgår i designet. I følgende tabel opremses alle klasserne, og deres formål beskrives ganske kort. Når der i feltet type er angivet Klasse navn, angiver det at denne klasse nedarver fra (eller implementerer når der er tale om et interface), klassen/interfacet med navnet navn. Størsteparten af klasserne herunder beskrives dybere i efterfølgende afsnit. Navn Type Kort beskrivelse VectorCalc Statisk klasse Indeholder statiske metoder til vektorberegning. ColorScaling Statisk klasse Indeholder statiske metoder til farveberegning. Scene Klasse Repræsenterer en scene SceneElement Interface Repræsenterer et element i en scene. TrianglePlane Klasse Repræsenterer et trekantet plan-udsnit. SceneElement Sphere Klasse Repræsenterer en kugle SceneElement Plane Klasse Repræsenterer et plan SceneElement ElementSubtraction Klasse SceneElement Repræsenterer et sceneelement der fremkommer ved at trække et sceneelement fra et andet. ElementIntersection Klasse SceneElement Repræsenterer et sceneelement der fremkommer som fællesmængden af to sceneelementer. AbstractTracer Abstrakt klasse Implementerer fælles funktionalitet for alle antialiasing-algoritmer NoAATracer Klasse - Tracer uden antialiasing AbstractTracer SuperSamplingTracer Klasse - Tracer med antialiasing-algoritmen supersampling. AbstractTracer StochasticTracer Klasse - AbstractTracer Tracer med stokastisk antialiasing (jitter) Tracer Interface Repræsenterer en tracer der kan trace én stråle. DiffuseTracer Klasse Tracer Benytter diffus-belysning vha. punktformige lyskilder. AmbientTracer Klasse Tracer Benytter kun fuld ambient belysning.

20 Side 20 Camera Interface Repræsenterer et kamera StandardCamera Klasse Camera Et simpelt hardcoded kamera, der er placeret fast i scenen. GeneralCamera Klasse Camera Et generelt kamera der kan placeres frit i scenen. TracerApplet Klasse JApplet En brugergrænseflade beregnet til test. TracerPanel Klasse JPanel Et JPanel der optegner det tracede billede mens tracingen skrider frem. Fungerer som interface til traceren som helhed. PointLightSource Klasse Repræsenterer en punktformig lyskilde TraceResult Klasse Dataklasse der angiver resultatet af en tracing. Coord3D Klasse Dataklasse der repræsenterer et punkt i rummet. Material Klasse Dataklasse der repræsenterer et materiale. Intersection Klasse Dataklasse der repræsenterer en skæring. Ray Klasse Dataklasse der repræsenterer en lysstråle. Tabel 5.1: Oversigt over alle klasser i designet Med dette grundlæggende overblik, vil vi nu se nærmere på hvorledes de enkelte klasser spiller sammen i diverse designmønstre. 5.3 Mønstre I det følgende beskrives vores design med udgangspunkt i en række designmønstre. Generelt beskrives mønstrene først på et abstrakt niveau, hvorefter det beskrives, hvor og hvordan mønstret benyttes i vores design Template (AbstractTracer) Grundideen i Template-mønsteret er at lade en overordnet klasse indeholde en Template-metode, der kalder en eller flere andre metoder (krog-metoder), der overskrives i subklasserne. På denne måde har den overordnede klasse, via templatemetoden, kontrollen over udførslen, mens forskellige subklasser kan implementere forskellige algoritmer. [Gamma; 1995] Et generelt klassediagram: Figur 5.4: Generelt klassediagram for implementation af Template-mønstret Template-klassen vil ofte være en abstrakt klasse, hvor krog-metoderne vil være abstrakte. Templatemetoden kalder krog-metoderne, hvis konkrete implementationer først kodes i subklasserne. Ved hjælp af template-mønstret opnås et frame-work, dvs. en ramme der kan tilpasses til forskellige formål. I template-klassen kodes al fælles kode, og kontrollen bevares her, mens sub-klasserne implementerer de små forskelle, der er fra anvendelse til anvendelse. [Gamma; 1995]

21 Side 21 I vores design benyttes Template-metoden i forbindelse med AbstractTracer, der er en template-klasse med krogmetoden tracingprocedure(), og som styrer trådning af tracingen samt opdatering af billedet på skærmen via Observer-mønsteret se afsnit Observer (AbstractTracer / TracerPanel). Subklasserne (f.eks. NoAATracer og StochasticTracer) implementerer forskellige former for antialiasing, og disse implementeres ved at overskrive krogmetoden tracingprocedure() og her udelukkende koncentrere sig om det særlige for denne tracing. Figur 5.5: AbstractTracer og dens subklasser (Template-mønster) Den kontrol der ligger i AbstractTracer består først og fremmest i at køre tracingprocedure() på en særskilt tråd, samt implementere stop og start funktionalitet for traceren, der stopper og starter tråden. Designets styrke er, at man, ved implementationen af den enkelte antialiasing-algoritme, ikke behøver koncentrere sig om trådning, samt at man har en tracer, et kamera og en billed-buffer til rådighed fra super-klassen. Dog skal tracingprocedure() kontrollere stop-flaget med jævne mellemrum og afbryde tracingen, hvis dette er sat, samt kalde updateifrequired() med det aktuelle linienummer for hver billedlinie, for at sikre at opdatering af billedet på skærmen kan forløbe korrekt (mere om dette i efterfølgende afsnit) Observer (AbstractTracer / TracerPanel) Som angivet er et af vore design-mål, at designet skal være modulariseret. Dette skal først og fremmest forstås som et ønske om at opretholde en klar adskillelse af brugergrænseflade og program-logik. Specielt er det uønsket, at lade klasser, der indgår i selve tracerens logik, kalde brugergrænsefladeelementer. Kald i modsat retning (brugergrænseflade Æ program-logik) er ikke et design-problem, da det ikke forhindrer udskiftning af brugergrænsefladen. Dette design-mål resulterer i et problem: Hvornår skal brugergrænsefladen optegne det tracede billede på skærmen (vi ønsker at billedet tegnes efterhånden som tracingen skrider frem)? Vi kunne naturligvis lade AbstractTracer-klassen, som indeholder det tracede billede, stå for optegningen, men dette ville bryde den skarpe grænse mellem brugergrænseflade og programlogik, og ville for øvrigt tilføje yderligere kompleksitet til kodningen af separate antialiasing-algoritmer. Man kunne desuden sagtens forestille sig en brugergrænseflade, hvor billedet ikke ønskes optegnet, før det er færdigtracet, eller måske slet ikke ønskes vist, men blot gemt på disken. Dette ville i givet fald, også

22 Side 22 skulle indbygges i AbstractTracer-klassen, og ville føre til en, efter vores vurdering, for tæt kobling mellem programmets logik og brugergrænsefladen. Desuden ville det gøre AbstractTracer-klassens formål mere tvetydigt, hvilket af forståelsesmæssige grunde ikke er ønskeligt. Som alternativ har vi valgt at lade en separat brugergrænseflade-klasse (TracerPanel) stå for optegningen af billedet. Denne klasse er en del af brugergrænsefladen, og har ikke noget at gøre med selve tracingen. Som udgangspunkt forsynede vi TracerPanel med en indre klasse, der nedarver fra Thread, og som på en separat tråd tegner det tracede billede på skærmen med et fast tidsinterval. Det var imidlertid klart fra starten, at dette ikke var optimalt, da vi hellere ville have opdateret billedet efterhånden som tracingen skred frem, i stedet for efter bestemte tidsintervaller. Dette er både visuelt og med hensyn til udnyttelsen af processorkraften mere tilfredsstillende. Denne problematik løstes ved hjælp af Java-metoderne til tråd-styring wait() og notifyall(). Vi indførte således en konvention om, at AbstractTracer skal kalde notifyall() på sig selv, hver gang den har tracet et antal linier, angivet via en metode (setupdaterate()). På denne måde er det muligt at skrive en brugergrænseflade-klasse, der, via wait-metoden, venter på, at et givent antal linier er tracet, hvorpå den optegner billedet. Det er naturligvis også muligt, at undlade at optegne billedet, hvis dette ønskes. Den fremkomne løsning minder om grundtanken i design-mønstret Observer. Dette designmønster indbefatter to klasser: En observatør (TracerPanel) og en observerbar (AbstractTracer). Hver gang det observerbare objekt ændrer tilstand, signaleres til alle observatør-objekterne, der således kan udføre den ønskede kode. [Gamma; 1995] Vores implementation ved hjælp af tråde og wait/notify er imidlertid ikke det typiske i lærebøgerne, hvor mønstret normalt implementeres svarende til dette klassediagram: Figur 5.6: Generelt klassediagram for implementation af Observer-mønstret Det er så Observable-klassens opgave at indeholde referencer til hver af de (via metoden addobserver()) tilføjede Observer-objekter, og kalde disses update()-metode hver gang objektet ændrer tilstand. Observer-interfacet og Observable-klassen findes i Java API en, hvor Observable-klassen blandt andet indeholder addobserver() og notifyobservers() metoder, der er beregnet til formålet. [API; 2001] Denne implementation giver en synkronisering, der hurtigere fører til opdatering af Observer-objektet, da dette bliver kaldt straks der er sket en ændring, og ikke først når JVM ens tråd-planlægning beslutter at lade kontrollen overgå til den anden tråd. Vi kunne have valgt denne implementation i vores program, men har ikke gjort det, da vi først blev opmærksomme på denne fremgangsmåde, efter vi havde udført den først nævnte tråd-baserede implementation, og da denne virker tilfredsstillende, har vi valgt ikke at bruge tid på at ændre den Facade (TracerApplet / TracerPanel) Grundtanken i mønstret Facade, er at tilbyde et samlet interface til en række klasser, for at skjule sammenspillet mellem disse, og tilbyde klient-programmøren en simplere grænseflade til den tilbudte funktionalitet:

23 Side 23 Figur 5.7: Kompleks pakke uden Facade-klasse Figur 5.8: Kompleks pakke med Facade-klasse Dette mønster betyder dels, at det bliver lettere at skrive klient-klasser, der benytter pakken, dels sikres det at koblingen mellem klienterne og klasserne i pakken er svag. Dette har den fordel, at det er let at ændre på de enkelte klasser i pakken uden at påvirke klienterne. En klient kunne for eksempel være en brugergrænseflade, der benytter programlogikken gennem en facade-klasse. Dette er i høj grad med til at fremme modulariteten, da brugergrænseflade og programlogik bliver svagt koblede, og brugergrænsefladen derfor let kan udskiftes. [Gamma; 1995] Netop på denne måde benytter vi facade-mønstret, idet brugergrænsefladen (TracerApplet) tilgår tracer-funktionaliteten gennem facade-klassen:

24 Side 24 Figur 5.9: TracerPanel s rolle som facade Via Facade-mønstret simplificeres udskiftningen af brugergrænsefladen. TracerPanel kan generelt anvendes i andre brugergrænseflader, hvor tracingen skal vises på skærmen, og den svage kobling opretholdes Strategy (Scene / Scene-element / Camera / Tracer) Ideen i Strategy-mønstret er, at gøre det muligt at implementere flere algoritmer der kan udskiftes efter behov. Dette opnås i Java ofte ved brug af et interface, der implementeres på flere måder: Figur 5.10: Generelt klassediagram for implementation af Strategy-mønstret Det er således muligt at skifte den benyttede algoritme, simpelthen ved at lade Context-klassen referere til en anden implementation af Strategy-interfacet. [Gamma; 1995] Dette mønster er nyttigt i mange sammenhænge og fremmer mulighederne for udvidelse betragteligt, da det er muligt at udvikle første simple konkrete strategi, og senere udskifte denne med noget mere avanceret uden at røre ved programmets logik i øvrigt. Strategy-mønstret benyttet på de rette steder, medvirker således til at gøre det muligt at udvide et program på en let og elegant måde, der ikke griber ind i eksisterende kode. [Gamma; 1995]

25 Side 25 I vores program er der adskillige eksempler på anvendelse af dette mønster. Scene/SceneElement sammenhængen, som vi ser på i næste afsnit, kan også karakteriseres som et strategy-mønster, hvor interfacet SceneElement implementeres på forskellig vis, der repræsenterer de forskellige scene-elementer (kugle, plan osv.). Et andet indlysende eksempel er AbstractTracer s tilknytning til Camera: Figur 5.11: AbstractTracer og Camera samt dennes subklasser (Strategy-mønster) Her er StandardCamera den simple algoritme, der repræsenterer et kamera på en fast position med en fast opløsning, det vil sige at getcop(), getxres() og getyres() blot returnerer konstanter, og at getpixelcoord() går ud fra et fast ViewPlane og derfor meget simpelt kan udregne en given pixels scenekoordinater. GeneralCamera er en mere avanceret implementation, hvor kameraets egenskaber kan angives i konstruktoren og derefter kan ændres dynamisk via setmetoder. Strategy-mønstret er endvidere brugt i forbindelse med sammenhængen mellem Tracer og AbstractTracer. Tracer er defineret som et interface, og ud fra dette interface er implementeret to subklasser: En tracer der understøtter punktformige lyskilder og diffus refleksion, samt en der kun understøtter fuld ambient belysning:

26 Side 26 Figur 5.12: Tracer-interfacet med subklaser (strategy-mønster) Whole-Part (Scene/SceneElement) Whole-Part mønstret er et mere generelt strukturelt mønster, end de øvrige mønstre vi ser på i dette projekt. Grundideen her er at have klasser, der repræsenterer en samling af objekter. På sin vis er dette formål i familie med formålet med facade-mønstret, dog med den forskel at Whole-Part nærmere har til formål at skjule et stort antal af objekter, end at skjule komplekse sammenhænge mellem objekterne. Et eksempel på Whole-Part konstruktioner er elementer i tegneprogrammer, der typisk kan grupperes og behandles som et hele, for eksempel i forbindelse med rotation eller flytning. [Buschmann; 1996] Et eksempel på Whole-Part mønstret i vores design, er sammenhængen mellem Scene og SceneElement. Her er Scene Whole-klassen, der repræsenterer scenen som en helhed og bevirker, at traceren ikke behøver at bekymre sig om de enkelte SceneElement objekter. Denne konstruktion forenkler tracerens arbejde, ved at lade Scene-klassen håndtere de potentielt mange sceneelementer. Yderligere er de sammensatte sceneelementer af klasserne ElementIntersection og ElementSubtraction også opbygget efter Whole-Part mønstret, idet en af disse klasser repræsenterer en sammensætning af flere sceneelementer. Denne sammenhæng er dog en smule mere sofistikeret og beskrives i følgende afsnit Composite (SceneElement samt sub-klasser) Formålet med designmønstret Composite er at kunne konstruere Whole-Part relationer mellem objekter, hvor klienten kan behandle et sammensat objekt på samme måde som de primitive objekter. På denne måde bliver det meget simpelt at skrive en klient, der håndterer både sammensatte og primitive elementer. Endvidere bevirker denne struktur, at der på triviel vis kan laves sammensatte objekter, der består af andre sammensatte objekter. [Gamma; 1995] Den generelle klassestruktur kan repræsenteres således:

27 Side 27 Figur 5.13: Generelt klassediagram for implementation af Composite-mønstret Composite-klassen vil typisk tage et eller flere Component-objekter i sin konstruktor, og muligvis indeholde en addcomponent-metode. I vores design benyttes dette mønster i forbindelse med boolske operationer på sceneelementer. Interfacet SceneElement er således et Component-interface, og Sphere er et eksempel på en primitiv subklasse, hvorimod klassen ElementIntersection er en sammensat klasse (Composite). ElementIntersection repræsenterer et sceneelement der består af fællesmængden for to sceneelementer. Bemærk at på grund af strukturen, kan disse to sceneelementer godt selv være af klassen ElementIntersection (der jo implementerer SceneElement interfacet). Tilsvarende repræsenterer ElementSubtraction et sceneelement, der består af det første element, dog undtagen den del der er indeholdt i det andet element. Klassediagrammerne for SceneElement-interfacet med subklasser belyser strukturen mere nøjagtigt: Figur 5.14: SceneElement med subklasser (Composite-mønster)

28 Side 28 Med dette design er det altså muligt at lave sammensatte sceneelementer, der igen er sammensat af andre sammensatte sceneelementer og så videre indtil der i bunden af hierarkiet nødvendigvis må befinde sig primitive sceneelementer. Alle eksisterende og fremtidige implementationer af SceneElement interfacet, vil kunne indgå i denne struktur, uden ændringer i eksisterende kode, og alle sceneelementer primitive såvel som sammensatte vil kunne behandles ens via interfacet SceneElement.

29 Side 29 6 Implementationsdetaljer I underpunkterne af dette afsnit vil de mere indviklede og interessante dele af koden blive nøjere beskrevet. 6.1 Beregning af kameraet I korte træk, består kameraets forbindelse til scenen af punktet COP og de to vektorer viewdirection og updirection. Disse tre er defineret i forhold til et højredrejet koordinatsystem som er det samme som sceneelementerne befinder sig i. I de følgende afsnit beskrives kameraets egenskaber viewplaneheight, -Width og dist Man kan undre sig over hvilken rolle viewplanets opløsning i enheder (viewplaneheight viewplanewidth, altså viewplanets størrelse), og afstanden dist til viewplanet, har ved bestemmelsen af det færdige billede. Den bedste måde at beskrive dette er ved at undersøge hvilken indflydelse, en ændring af faktorerne vil have på det færdige billede. Vælger man enten opløsningen i enheder eller afstanden dist til viewplanet til at være konstant, vil man ved at ændre den ikke-fastholdte egenskab, blot bestemme hvor bred den vinkel er, hvormed man beskuer verden (dermed ændres billedets perspektiv). Billedmæssigt vil en forøgelse eller formindskelse af dist, eller en tilsvarende formindskelse eller forøgelse af opløsningen i enheder, derfor give indtryk af, at man henholdsvis zoomer ind eller ud på objekterne i scenen. Ved at zoome vil man samtidigt bestemme, hvorvidt de elementer som ligger i yderkanten er med på billedet. Dette kan ses på Figur 6.1 og Figur 6.2. Figur 6.1: Afstanden dist til viewplanet fastholdes mens viewplanets opløsning i enheder ændres. De tre billeder i højre side viser hvad man ser fra kameraets synspunkt COP (Center Of Projection), ved henholdsvis 1: et lille, 2: mellemstort og 3: stort viewplan.

30 Side 30 Figur 6.2: Viewplanets opløsning i enheder fastholdes mens afstanden dist til viewplanet ændres. De tre billeder i højre side viser hvad man ser fra kameraets synspunkt COP (Center Of Projection), ved henholdsvis 1: en stor, 2: mellemstort og 3: lille dist ViewPlaneHeight og -Width overfor xres og yres Sammenhængen mellem viewplanets opløsning i enheder (viewplaneheight viewplanewidth), og billedets opløsning i pixels (xres yres), og hvordan en ændring i den ene vil påvirke resultatet af tracingen, er følgende: Vælger man opløsningen i enheder til at være den samme som opløsningen i pixels, så vil en enhed på viewplanet svare til en pixel på det billede der genereres. Dette ses på Figur 6.3.

31 Side 31 Figur 6.3: Viewplanets opløsning i enheder svarer til billedets opløsning i pixels i forholdet 1:1. Vælger man derimod at nedsætte billedets opløsning, vil der ske det, at en pixel på skærmen vil være bestemt ud fra de viewplan-enheder, pixlen dækker over. Dette er illustreret på Figur 6.4. Gør man det modsatte, og sætter pixelopløsningen højere end opløsningen af ViewPlane-enheder, så vil flere pixler være bestemt ud fra en enkelt ViewPlane-enhed. Figur 6.4: Viewplanets opløsning i enheder svarer til billedets opløsning i pixels i forholdet 2:1.

32 Side recalculatecamera Hver gang en af attributterne ved kameraet ændres, så skal hele kameraet genberegnes for, at disse ændringer viser sig korrekt. Dette gøres via metoden recalculatecamera(). Nedenstående er koden for denne metode. Coord3D up = VectorCalc.scaleToLength(VectorCalc.crossProduct(VectorCalc.crossProduct( viewdirection,updirection), viewdirection),viewplaneheight / 2); Coord3D left = VectorCalc.scaleToLength(VectorCalc.crossProduct(up, viewdirection), viewplanewidth / 2); Coord3D center = VectorCalc.add(COP,VectorCalc.scaleToLength(viewDirection, dist)); upperleft = VectorCalc.add(VectorCalc.add(center,up),left); double pixelwidth = viewplanewidth / xres; double pixelheight = viewplaneheight / yres; right = VectorCalc.scaleToLength(VectorCalc.negate(left),pixelWidth); down = VectorCalc.scaleToLength(VectorCalc.negate(up),pixelHeight); I linie 1 beregnes vektoren up, som er vinkelret på synsretningen viewdirection, og som ligger i den generelle retning, i hvilken updirection-vektoren ligger. At det er den generelle retning skyldes, at synsretningen menes at være den væsentligste at fastholde, så hvis updirection og viewdirection ikke er ortogonale, så går man ud fra, at det er fordi, det for det meste er uoverskueligt, i hovedet, at skulle udregne en vektor, der er ortogonal med den synsretning man har valgt. Kort er det der sker, at man først beregner krydsproduktet mellem viewdirection og updirection, og derefter beregner krydsproduktet mellem dette resultat og viewdirection. Dette medfører, at så længe viewdirection og updirection ikke er parallelle, så vil man først få en vektor, som er en normal til det plan, der udspændes af viewdirection og updirection, hvorefter man ved at krydse denne vektor på synsretningen vil få en vektor i opretningen. Dette ses på Figur 6.5. Til sidst skaleres vektoren til at have en længde, der svarer til halvdelen af viewplaneheight. Linie 3 og 4 beregner vektoren left ved krydsproduktet mellem up og viewdirection, derefter skaleres den til at have en længde, der svarer til halvdelen af viewplanewidth. Længderne på up og left vælges således, fordi vektorerne kan lægges til viewplanets centrum, og dermed findes hjørnepunktet. Figur 6.5: Bestemmelse af vektoren up. Først beregnes krydsproduktet viewdirection updirection, som kaldes temp. Derefter beregnes krydsproduktet temp viewdirection, der så giver vektoren up. Ved 5 beregnes center som er centrum for viewplanet, ved at skalere synsretningen til at have samme længde som afstanden fra COP til viewplanet og lægge den til COP. Herefter (linie 6) beregnes det øverste venstre hjørne af viewplanet ved at lægge center sammen med up og left. I de sidste linier, fra 7 til 10, beregnes først, hvor stor en del af viewplanet en pixel dækker i højde og i bredde, hvorefter de to vektorer right og down beregnes. Right beregnes ved at man inverterer vektoren left og skalerer den til at have samme længde som en pixel er bred. Down beregnes ligeledes ved at man inverterer vektoren up, og skalerer den til at have samme længde som en pixel er høj.

33 Side getpixelcoord Denne metode benyttes til at finde en pixels koordinater i viewplanet. Nedenstående kode er metoden getpixelcoord. Her er px pixlens nummer fra venstre mod højre, og py pixlens nummer oppefra og ned; x og y er tal mellem 0 og 1 som beskriver hvor langt inde i pixlen, man befinder sig. Coord3D xdir = VectorCalc.scale(right, (px + x)); Coord3D ydir = VectorCalc.scale(down, (py + y)); Coord3D point = VectorCalc.add(VectorCalc.add(upperLeft,yDir),xDir); I linie 1 beregnes xdir, som er en vektor fra viewplanets øverste venstre hjørne til pixlens placering i viewplanet i billedets x-retning. Dette gøres ved at skalere right til at være (px + x) gange sin egen længde. Tilsvarende, i linie 2, beregnes ydir, som er en vektor i billedets y-retning fra viewplanets øverste venstre hjørne til pixlens placering i viewplanet. Til sidst, linie 3, bestemmes pixlens koordinater ved at lægge de to vektorer xdir og ydir sammen med det øverste venstre hjørne af viewplanet. 6.2 Antialiasing algoritmerne I de følgende afsnit vil de implementerede antialiasing-algoritmer blive beskrevet. Alle algoritmerne er implementeret ved at nedarve fra AbstractTracer klassen og overskrive metoden tracingprocedure(). På denne måde genbruges trådstyring, samt hjælpemetoder og nogle felter. Der er implementeret tre subklasser til AbstractTracer: En der implementerer en simpel tracing uden antialiasing men som medtages her for at vise nogle generelle detaljer, der ikke vil blive medtaget i beskrivelsen af de egentlige antialiasing-algoritmer en der implementerer supersampling, og en der implementerer stokastisk antialiasing ved hjælp af jitter. I det følgende vil disse subklassers implementation af tracingprocedure() blive beskrevet Ingen antialiasing Den simpleste tracing foregår ved at trace en stråle gennem midten af hver pixel, og lade resultatet af dette afgøre pixlens farve. Følgende pseudokode viser hvorledes dette er implementeret: Sæt py = 0 Så længe py < billedets vertikale opløsning Sæt px = 0 Så længe px < billedets horisontale opløsning pcoord = scenekoordinat for (px, py, 0.5, 0.5) stråle = stråle gennem COP og pcoord tresultat = trace(stråle) sæt farven af pixel (px, py) til tresultat.farve Hvis stop-flaget er sat: Afbryd Forøg px med 1 Gentag Send signal til observatører hvis nødvendigt Forøg py med 1 Gentag Send opdateringssignal til observatører Beregningen af pcoord der angiver et scenekoordinat svarende til et bestemt sted i en pixel, foregår ud fra pixlens koordinater, samt et koordinatsystem inden i pixlen med koordinater i intervallet [0;1]. Derfor svarer (px, py, 0.5, 0.5) til midten af pixlen med koordinatet (px, py). Der sendes et signal til alle observatører (dvs. this.notifyall() kaldes se eventuelt afsnit Observer (AbstractTracer / TracerPanel)), hvis linienummeret (py) er et helt multiplum af en angiven opdateringshyppighed. Denne opdateringshyppighed angives via metoden AbstractTracer.setUpdateRate(). Stop-flaget er et protected felt i AbtractTracer, der benyttes i forbindelse med trådstyringen. Generelt skal alle subklasser af AbstractTracer sende signaler til obersvatører og teste stop-flaget som vist her. Desuden er fremgangsmåden for at trace en stråle et bestemt sted i en pixel (linie 5-7) generelt anvendelig for alle algoritmerne. Disse detaljer vil ikke blive medtaget i beskrivelsen af de følgende algoritmer. Med denne simple tracing-algoritme i baghovedet kan vi nu se på de to algoritmer, der benytter antialiasing.

34 Side Supersampling Klassen SuperSamplingTracer implementererede som udgangspunkt en supersampling-algoritme, der sender en stråle i hvert hjørne samt en i midten af pixlen. Da dette imidlertid ikke gav et visuelt tilfredsstillende resultat, tilføjede vi fire ekstra stråler pr. pixel og opnåede derved nedenstående sample-mønster. Figur 6.6: Sampling-mønster for den implementerede supersampling. For at udnytte den fordel supersampling har; at en del af de samme stråler benyttes for flere pixels, må vi opbygge en datastruktur, der kan gemme resultatet af tracingen af de relevante stråler. Lad os først se på hvilke stråler der kan genbruges: Figur 6.7: Genbrug af strålerne i pixlernes hjørner Som det ses af Figur 6.7 kan alle hjørnestråler genbruges for op til 4 pixels. For at udnytte dette opbygges et array top og et array bottom der indeholder resultaterne af tracingen af hjørnestrålerne. Når en række pixels er beregnet, sættes referencen til top til at pege på bottom-arrayet, der opbygges et nyt bottom-array, og derpå kan næste linie traces. På den måde undgås det, at nogle stråler traces mere end en gang. I overordnet pseudokode foregår det således: Opret arrays top og bottom Trace en stråle i øverste venstre hjørne for alle pixels i øverste linie. Gem resultatet i top Trace en stråle i øverste højre hjørne af sidste pixel på øverste linie. Gem resultatet i top For hver linie Trace en stråle i nederste venstre hjørne for alle pixels på linien. Gem resultatet i bottom Trace en stråle i nederste højre hjørne af sidste pixel på linien. Gem resultatet i bottom For hver pixel på linien Trace de 5 stråler inden i pixlen. Beregn gennemsnitsfarve af de 5 stråler, samt de 4 relevante fra top og bottom. Farv pixlen med gennemsnitsfarven Gentag Sæt top = bottom Gentag Gennemsnitsfarven beregnes vha. klassen ColorScaling, der har en metode getaveragecolor() der beregner gennemsnittet af en Collection af farver Stokastisk antialiasing Som den sidste antialiasing-algoritme, har vi, i klassen StochasticTracer, valgt at implementere stokastisk antialiasing ved jitter. Dette er implementeret således, at pixlen deles op i 3x3 kvadrater. Inden for hver af disse kvadrater placeres der en tilfældig stråle. I pseudokode foregår tracingen som følger:

35 Side Opret en liste: colors For hver linie For hver pixel på linien Sæt i = 0 Så længe i < 1 Sæt j = 0 Så længe j < 1 x = tilfældig værdi mellem i og i + 1/3 y = tilfældig værdi mellem j og j+ 1/3 trace en stråle gennem pixlen i position (x,y) Gem den resulterende farve i listen colors Forøg j med 1/3 Gentag Forøg i med 1/3 Gentag Beregn farvegennemsnittet af listen colors Sæt pixlens farve til det beregnede gennemsnit Gentag Gentag Denne algoritme kunne hastighedsoptimeres ved at beregne et kort over de tilfældigt spredte stråler ved konstruktionen af StochasticTracer objektet, således at denne del af arbejdet allerede var gjort på trace-tidspunktet. Dette ville koste hukommelse men forøge hastigheden. 6.3 SceneElement Alle implementeringer af SceneElement skal indeholde metoden getintersection(ray). Denne vigtige metode bruges til at bestemme et eventuelt skæringspunkt, for de elementer scenen kan indeholde. Hvis strålen kan skære elementet flere gange, skal det fundne skæringspunkt, være dét tættest på udgangspunktet for strålen, da det kun er det nærmeste skæringspunkt, der har betydning for traceren. Foruden skæringspunkt returnerer et sceneelement, elementets normalvektor i skæringspunktet og sceneelements materiale. Disse oplysninger er alle indeholdt i klassen Intersection. Den anden metode, SceneElement kræver implementeret, er withinelement(coord3d). Denne metode returnerer en boolean, der angiver, hvorvidt et punkt er indeholdt i et element eller ej. Metoden muliggør implementation af boolske operationer og bruges af ElementIntersection og ElementSubtraction Sphere Sphere beskriver en kugle i scenen. Dens to eneste public metoder er angivet af SceneElement og er getintersection(ray) og withinelement(coord3d). En kugle defineres ud fra et punkt i rummet (kuglens centrum) og en længde (dens radius). Dette er nok til at beskrive kuglen ved dens ligning: (x-x c) 2 +(y-y c) 2 +(z-z c) 2 = r 2 Hvor: r = radius og (x c,y c,z c) = centrum. Sphere s vigtigste funktion er at bestemme, hvorvidt kuglen skæres af en stråle eller ej og i så tilfælde i hvilket skæringspunkt. Dette bestemmes, når metoden getintersection(ray) kaldes. Sphere benytter simpel kendt matematik til at bestemme skæringspunkter. Disse beregninger foretages i fire hjælpemetoder: calcdicriminant(), calcintersection(double discriminant), calcnormal() og precisioncorrection(). Beregningerne foretages i flere metoder, for at simplificere koden. Udfra resultatet af første metode kan det nemlig ses, om strålen rammer kuglen, og dermed om det er nødvendigt at foretage flere beregninger. I første del af beregningerne beskrives den parameteriserede stråle (Ray) ved parameterfremstillingen: (x, y, z) = (x o, y o, z o) + t (x d, y d, z d) Hvor: (x o, y o, z o) = strålens udganspunkt, (x d, y d, z d) = strålens retning.

36 Side 36 Herefter substitueres parameterfremstillingens (x, y, z) værdier ind i kuglens ligning: (x o+x d t-x c) 2 +(y o+y d t-y c) 2 + (z o+z d t-z c) 2 = r 2 Herved har man en andengradsligning med t som ubekendt: a t 2 +b t+c = 0 Hvor: a = x d 2 +y d 2 +z d 2 = 1, da strålens retningsvektor er normaliseret. b = 2 (x d (x o-x c) 2 +2 (y d (y o-y c) 2 +2 (z d (z o-z c) 2 c = (x o-x c) 2 -(y o-y c) 2 -(z o-z c) 2 Beregner man nu diskriminanten for denne andengradsligning, som det gøres i calcdiscriminant(), kan man aflæse en del om strålens skæring med kuglen: 1. Diskriminanten er negativ - der er intet skæringspunkt. 2. Diskriminanten er nul - strålen tangerer kuglen og der er præcis ét skæringspunkt. 3. Diskriminanten er positiv - der er to skæringspunkter. Diskriminanten beregnes som: d = b 2-4 a c Er diskriminanten negativ stopper alle beregninger, og getintersection(ray) returnerer null. Ellers forsætter beregningerne, og diskriminanten sendes videre til calcintersection(double discriminant). Her beregnes første rod af t1. b t 1 = 2 d Er denne rod større end nul, er dette skæringspunkt det, der ligger tættest på strålens udgangspunkt da denne værdi af t altid vil være mindre end den efterfølgende t2. I dette tilfælde beregnes skæringspunktet og returneres. Er det derimod mindre end eller lig nul, betyder det, at skæringspunktet ligger bag eller på strålens udgangspunkt, og det kan derfor ikke bruges. Dette medfører, at den anden rod beregnes: t 2 = b+ 2 d Hvis denne rod også mindre end eller lig nul findes intet fornuftigt skæringspunkt og null returneres. Kan t bruges, beregnes skæringspunktet lettest og hurtigst ved indsættelse af t i strålens parameterfremstilling: (x, y, z) = (x o, y o, z o) + (x d, y d, z d) t Herefter beregnes normalen til skæringspunktet. Dette gøres simpelt ved at beregne en vektor fra kuglens centrum til skæringspunktet, for derefter at dividere komponenterne med radius, således at normalvektoren er en enhedsvektor. Disse beregninger udføres i calcnormal(). Det er nu nødvendigt at undersøge, om skæringspunktet ligger inden i kuglen, for hvis det gør, skal normalvektoren vendes. Hvilket gøres med negate() i hjælpeklassen VectorCalc. Slutteligt i getintersection(ray) justeres skæringspunktet, så man undgår præcisionsproblemer(som forklaret i afsnit 2.4 Præcisionsproblemer). Dette gøres med metoden precisioncorrection(). Herefter returneres et Intersection objekt indeholdende skæringspunkt, normalvektor og elementets materiale.

37 Side 37 Den anden public metode withinelement(coord3d) bestemmer om et punkt er indeholdt i kuglen. Dette gøres ved, at afstanden mellem centrum og det punkt, der ønskes undersøgt, beregnes. Er afstanden mindre end radius, ligger punktet indenfor kuglen Plane Plane beskriver et plan i rummet. Planet udstrækker sig i det uendelige. Plane indeholder ligesom Sphere kun to public metoder, dem angivet i interfacet SceneElement. Strålens skæring med planet findes ved kald af getintersection(ray), og beregnes på tilsvarende måde, som i Sphere. Strålens parameterfremstilling substitueres ind i planets ligning. Planets ligning er: a x+b y+c z+d = 0 Hvor (a, b, c) svarer til planets normalvektor, og d er en konstant der angiver afstanden fra planet til koordinatsystemets udgangspunkt. [Glassner; 1991] Strålens parameterfremstilling: (x, y, z) = (x o, y o, z o) + t (x d, y d, z d) Herved fås følgende brøk, når t er isoleret: t = -(a x o+b y o+c z o+d)/( a x d+b y d+c z d+d) Udfra denne brøks tæller kan flere egenskaber ved skæringen aflæses. 1. Tælleren er lig nul - strålen er parallel med planet og der sker derfor ingen skæring. Udregningerne stopper og null returneres. 2. Tælleren er mindre end nul - strålen skærer planet og skæringspunkt, normalvektor og materiale returneres. 3. Tælleren er større end nul - strålen rammer planet bagfra. Det vil sige at normalvektoren vender væk fra strålen. Derfor vendes normalvektoren og returneres med skæringspunkt og materiale. Frem for at beregne både tæller og nævner fra start. Opnås en fordel med hensyn til beregningshastighed ved først at beregne tælleren og dernæst kun beregne nævneren hvis skæring findes. Som i Sphere er beregningerne delt ud i et antal private hjælpemetoder. Her calcintersection() og precisioncorrection(coord3d). calcintersection() foretager de før omtalte beregninger, og precicioncorrection(coord3d) har præcis samme formål som i Sphere, nemlig at flytte skæringspunktet væk fra elementet således at afrundningsproblemer undgås. withinelement(coord3d) returnerer altid false. Et plan er 2-dimensionalt og har derfor intet rumfang, og et punkt kan derfor ikke være indeholdt i dette element TrianglePlane TrianglePlane beskriver et grundelement i tredimensionel modellering, nemlig en trekantet flade, også kaldet et face. Det unikke ved dette element er, at alle elementer kan konstrueres udfra faces. Kugler, kasser, cylindere og komplekse objekter så som tekander, dyr, møbler og hvad man ellers kunne forestille sig, alle kan tilnærmes med faces. At vi så i praksis bruger andre metoder til at skabe visse geometriske elementer, er ganske enkelt fordi det er simplere og hurtigere. TrianglePlane benytter Plane ved komposition. Det der grundlæggende sker ved et getintersection(ray) kald er, at strålen først testes for skæring med det plan, som trekanten ligger i. Skærer strålen dette plan undersøges det, om skæringspunktet ligger inden for trekantens areal. Hvis den gør returneres skæringspunktet, ellers returneres null. Således vil kun den del af planet, der ligger i trekanten optegnes på skærmen. En trekant skabes udfra tre punkter i rummet. Udfra disse tre punkter findes to retningsvektorer og en normalvektor til trekanten. Disse vektorer bruges efterfølgende til at konstruere et plan, der ligger i plan med trekanten.

38 Side 38 Når getintersection(ray) kaldes testes strålen somsagt først mod planet. Skæringspunktet, om noget, sendes videre til en privat hjælpemetode, checkintersection(intersection) som returnerer en boolesk værdi. true returneres hvis skæringspunktet ligger indenfor trekanten, false hvis ikke. checkintersection(intersection) foretager sig flere ting. Først projiceres trekanten i plan med x-y, x-z eller y-zakserne. Således at de efterfølgende beregninger kan foretages i to dimensioner og dermed forsimples. Hvilket plan trekanten skal projiceres ned i, bestemmes af det dominante komponent i trekantens normalvektor. Idet det dominante komponent bliver smidt væk, dermed forvrænges trekanten så lidt som muligt ved projektionen. Det dominante komponent er det, der har den numerisk største værdi. På Figur 6.1 kunne normalvektoren for eksempel have komponenterne (-1, 6, 1), og her ville x-komponenten tydeligvis være dominant, også selvom normalvektoren blev vendt. Trekanten vil derfor blive projiceret ned i x-z planet. Figur 6.1: Trekant i rummet og det plan det ligger i, angivet med normalvektor. Efter projektionen forskydes trekanten, således at skæringspunktet kommer til at ligge i (0 0). Dette gøres for at simplificere beregningerne, som det vil vise sig. Et eksempel på en forskydning ses illustreret Figur 6.2. Figur 6.2: a) trekanten ABC, b) trekanten ABC forskudt til A'B'C' sådan at skæringspunktet ligger i (0,0). Efter alle disse krumspring er ideen så, at man nu kan, se hvorvidt et skæringspunkt ligger indenfor trekanten, ved at tælle hvor mange af trekantens linjestykker, der skærer med den positive del af u-aksen i et uv-koordinatsystem. Det svarer til at du, ud fra skæringspunktet, sender en tilfældig vektor. Skærer denne vektor med trekanten én gang ligger

39 Side 39 skæringspunktet indenfor trekanten, skæres trekanten nul eller to gange ligger skæringspunktet udenfor trekanten. Se Figur 6.3. Figur 6.3: a) (0,0) er ikke indeholdt i trekanten da trekanten skærer u-aksen 2 gange, b) (0,0) er indeholdt i trekanten da trekanten skærer den positive del af u-aksen én gang. Denne metode kan også bruges, hvis man tester for skæring med polygoner. Nul eller et lige antal skæringer med polygonet vil betyde, at skæringspunktet ligger udenfor polygonet, mens et ulige vil betyde, at skæringspunktet ligger indenfor polygonet. For at teste hvorvidt et linjestykke skærer med x-aksen, efter trekanten er projiceret og forskudt, benytter vi en private metode kaldet lineintersection(double[], double[]). De to parametre (double array) er endepunkterne i det linjestykke, der ønskes testes for skæring med u-aksens positive del. Metoden returnere en boolean; true hvis linjestykket ligger skærer, false hvis ikke. Denne metode har den fordel, at den kan genbruges, i fald et polygon- SceneElement skulle implementeres. checkintersection(intersection) kalder således lineintersection(double[], double[]) tre gange, tæller antallet af skæringer og returnerer en true eller false værdi, alt efter om skæringspunktet ligger indenfor trekanten eller ej. getintersection(ray) returnerer kun et skæringspunkt, hvis checkintersection(intersection) er sand, ellers returneres null. Som Plane er TrianglePlane 2-dimensionalt og har derfor intet rumfang. Ergo returnerer withinelement(coord3d) altid false ElementIntersection og ElementSubstraction ElementIntersection og ElementSubtraction er begge unikke, i det de repræsenterer en boolsk operation foretaget på to sceneelementer. ElementIntersection repræsentere fællesmængden af to sceneelementer, mens ElementSubtraction skærer ét element fra et andet. Begge klassers constructor tager to sceneelementer, som kan være et hvilket som helst element, så længe det implementerer SceneElement. De kan derfor også tage andre ElementSubtraction- og ElementIntersection-elementer som parametre. WithinElement s vigtigste opgave er, at yde ElementIntersection og ElementSubtraction en metode til at bestemme hvorvidt et punkt er indeholdt i et element. Denne metode er central for de to klasser men bliver også benyttet af Sphere ElementIntersection Idéen vi fik til ElementIntersection var meget simpel; hvis et skæringspunkt ikke var indeholdt i begge elementer skulle de negligeres. Figur 6.4 belyser princippet med to kugler og Figur 6.5 med et plan og en kugle.

40 Side 40 Figur 6.4: Fællesmængden af to kugler - a) strålen skærer begge kugler i henholdsvis S 1 og S 2. S 2 returneres da skæringspunktet er indeholdt i kugle 1. b) Strålen skærer kugle 2, da skæringspunktet ikke er indeholdt i den anden kugle negligeres det. Figur 6.5: Fællesmængden af et plan (1.) og en kugle (2.) - tegnet i to-dimensioner. - a) Strålen skærer kugle og plan. Skæringspunktet i planet (S 1) returneres, da det er indeholdt i kuglen. b) Ingen af skæringspunkterne er indeholdt i de to elementer, så intet skæringspunkt returneres Implementeringen var uhyre simpel som det ses af nedenstående kode. getintersection(ray) finder først eventuelle skæringspunkter med de to sceneelementer, for hvilke fællesmængden ønskes. Dette gøres ved at kalde deres respektive getintersection(ray) se kode linje 2 og 6. Hvis begge elementer ikke skæres af strålen, returneres null. Derefter testes det, hvorvidt det ene eller det andet skæringspunkt er indeholdt i det andet element. Dette gøres i linje 10 og 13 med withinelement(coord3d). Hvis et det ene elements skæringspunkt er indeholdt i det andet element, behøves beregningerne ikke at forsætte, da det andet elements skæringspunkt så ikke kan være indeholdt i det første element. public Intersection getintersection(ray ray) { Intersection intersection1 = element1.getintersection(ray); if(intersection1 == null){ return null; } Intersection intersection2 = element2.getintersection(ray); if(intersection2 == null){ return null; } if(element2.withinelement((intersection1.getpoint()))) { return intersection1; } if(element1.withinelement((intersection2.getpoint()))) { return intersection2; } return null; } //end getintersection() ElementIntersection s withinelement(coord3d) kalder sine sceneelementers withinelement(coord3d). Den returnerer true, hvis det medfølgende punkt er indeholdt i begge elementer - altså er indeholdt i fællesmængden.

41 Side ElementSubtraction ElementSubtraction fungerer stort set som ElementIntersection, men er noget mere kompliceret. Principielt forgår det sådan, at et sceneelement, trækkes fra et andet. Dette gøres, som det ses skrevet i nedenstående kode fra getintersection(ray) i ElementSubtraction. Det er vigtigt at pointere, at det er element2, der trækkes fra element public Intersection getintersection(ray ray){ if (ray == null) { throw new NullPointerException("Null pointer not allowed as parameter"); } //end if Intersection intersection1 = element1.getintersection(ray); if(intersection1 == null) { return null; } //end if Intersection intersection2 = element2.getintersection(ray); if(intersection2 == null) { return intersection1; } //end if if(element2.withinelement(intersection1.getpoint())) { Coord3D addedlengthvector = VectorCalc.scaleToLength(ray.getDirection(), 1E-6); Ray newray = new Ray(VectorCalc.add(intersection2.getPoint(), addedlengthvector), ray.getdirection()); Intersection tempintersection2 = element2.getintersection(newray); if(tempintersection2!= null) { intersection2 = tempintersection2; } //end if if(element1.withinelement(intersection2.getpoint())){ return intersection2; } // end if return null; } //end if return intersection1; } //end getintersection Det der først sker er, at de to elementers skæringspunkt findes (linje 6-14). Hvis element 1 ikke skæres af strålen, slutter beregningerne, da der ikke vil være det endelige element. element2, derimod, behøver ikke at skære med strålen. Hvis ikke den har returneres element1 s skæring, da strålen rammer element 1 et sted, hvor elementet ikke overlapper element2. Linje beskriver situationer som den illustreret på Figur 6.6. Begge elementer skæres af strålen. Hvis element1 s skæringspunkt ligger indeni element2, vil det sige, at dette skæringspunkt ikke skal bruges, da det skal fratrækkes element2. Til gengæld ønskes element2 s indre skæringspunkt returneret. Dette gøres ved, at en ny strålevektor findes inden i element2 og testes for skæring med elementet. Først flyttes element2 s skæringspunkt et stykke ind i element2 i strålevektorens retning (linje 17-19). element2 s indre skæring findes derefter (linje 20). Figur 6.6: ElementSubtraction mellem to kugler. Kugle 1 fratrækkes kugle 2. - a) Strålen skærer begge kugler i S1 og S2. - b) Strålens udgangspunkt flyttes indenfor kugle 2 og strålens skæring med kugle 2. indvendigt findes.

42 Side 42 element2 s indre skæringspunkt returneres kun hvis det ligger indeni element2 som det ses linje For at undgå situationer som den illustreret i Figur 6.7. Figur 6.7: ElementSubtraction mellem to kugler. Kugle 1 fratrækkes kugle 2. - a) Strålen skærer begge kugler i S1 og S2. - b) Strålens udgangspunkt flyttes indenfor kugle 2 og strålens skæring med kugle 2. indvendigt findes. ElementSubtraction s withinelement(coord3d) returnerer true, hvis det undersøgte punkt befinder sig i element1 og ikke i element2; ellers returneres null. 6.4 Belysningsmodeller I de følgende afsnit, vil de to udviklede implementationer af Tracer-interfacet blive beskrevet. Det drejer sig om klasserne AmbientTracer og DiffuseTracer, der implementerer to forskellige lysmodeller for en tracing. Begge klasser implementerer tracer-interfacet, og har dermed metoden trace(), der tracer en enkelt stråle gennem en scene Ambient belysning Klassen AmbientTracer implementerer en meget simpel tracer, der udelukkende belyser ethvert punkt med fuld ambient belysning. Dette betyder at hvis en stråle rammer et sceneelement, returneres objektets farve, og i modsat fald returneres baggrundsfarven. I pseudokode foregår det således: skæring = strålens skæring med scenen Hvis skæring er null ingen skæring returner baggrundsfarven Ellers skæring fundet returner sceneelementets farve Denne meget simple belysningsmodel giver ikke et 3-dimensionelt indtryk af scenen, da der ikke forekommer skygger Diffus reflektion Klassen DiffuseTracer implementerer diffus belysning. Belysningen beregnes ved at sende en skyggevektor fra skæringspunktet mod lyskilden, hvis denne vektor skærer med et sceneelement, er punktet muligvis i skygge, afhængig af afstanden til skæringspunktet til lyskilden. Hvis punktet ikke er i skygge, beregnes hvor meget lys, der reflekteres, idet skaleringsfaktoren sættes til cosinus til vinklen mellem skyggevektoren og normalvektoren. Detaljer vedrørende diffus belysning er beskrevet i afsnit Diffus belysning. Hvis et punkt belyses af flere lyskilder, antager algoritmen at punktet belyses med lys, svarende til det fra den kraftigste af kilderne (den hvis vinkel er mindst i forhold til normalen i skæringspunktet). Der angives desuden en ambientfaktor, der angiver den mindste tilladte skaleringsfaktor. Dette betyder, at ethvert punkt altid er belyst svarende til denne faktor. I pseudokode foregår tracingen således:

43 Side skæring = strålens skæring med scenen Hvis skæring er null ingen skæring returner baggrundsfarven Ellers skaleringsfaktor = ambient faktor For hver lyskilde skyggestråle = beregn stråle fra skæring til lyskilde skyggeskæring = spørg scenen om skæring med skyggestrålen hvis (skyggeskæring er null) eller (afstanden fra skæring til lyskilde er mindre end fra skæring til skyggeskæring) vinkel = beregn vinkel mellem normal og skyggestråle faktor = cos(vinkel) Hvis faktor > skaleringsfaktor skaleringsfaktor = faktor Gentag skæring fundet returner farven skaleret med den fundne faktor Hvis-sætningen i linie 9 og 10 består af 2 logiske udtryk med et eller imellem og evaluerer til sand, hvis punktet ikke er i skygge i forhold til den aktuelle lyskilde. Den første del af sætningen er sand, hvis skyggestrålen ikke skærer med noget element, og er dette tilfældet, er det sikkert at punktet ikke er i skygge. Den anden del er nødvendig, for at afgøre hvorvidt det objekt skyggestrålen skærer med, faktisk skygger for lyskilden (se evt. forklaring og illustrationer i afsnit Diffus belysning).

44 Side 44 7 Brugstest I dette afsnit foretages nogle tests af det udviklede produkt, for at dokumentere at det virker, samt at belyse den implementerede funktionalitet lidt nærmere. Brugstesten tager udgangspunkt i en udviklet standardscene, der traces med forskellige indstillinger, hvoraf de fleste kan vælges fra brugergrænsefladen (se evt. 12 Appendiks A kort vejledning til brugergrænsefladen). 7.1 Belysningsmodeller Der er implementeret to belysningsmodeller i form af to implementationer af tracer-interfacet. Herunder ses et skærmbillede af hele traceren, hvor standardscenen (bliver oprettet ved tryk på Create standard scene ) er tracet med diffus belysning (vha. klassen DiffuseTracer). Figur 7.1: Skærmbillede af ray-traceren, med standardscenen tracet med diffus belysning. Kameraindstillingerne fremgår af højre side af skærmbilledet. Man kan ikke via brugergrænsefladen vælge belysningsmodel, men ved nogle få ændringer i TracerPanel skiftes traceren til at benytte AmbientTracer, og dermed en belysningsmodel der udelukkende benytter fuld ambient belysning, hvilket i praksis betyder, at en tracing af en stråle enten resulterer i det ramte sceneelements ikke-skalerede farve eller i baggrundsfarven. Dermed fremkommer det nedenfor viste billede ved tracing af standardscenen med samme indstillinger i øvrigt som brugt ovenfor. Figur 7.2: Standardscenen tracet udelukkende med ambient belysning (vha. klassen AmbientTracer) Eneste ændringer for at opnå dette er, at AbstractTracer skal konstrueres med en instans af AmbientTracer i stedet for af DiffuseTracer. Derudover skal indholdet af metoderne clearalllightsources() og addlight() i TracerPanel

45 Side 45 udkommenteres, da disse metoder ikke kan fungere ved brug af udelukkende ambient belysning (Dette betyder at de brugergrænsefladeelementer der har med lyskilder at gøre, mister deres funktionalitet). 7.2 Kameraet Som omtalt i afsnit 6.1 Beregning af kameraet er der implementeret et generelt kamera, der kan placeres frit i scenen. Herunder vises eksempler på to forskellige kameraplaceringer, hvor standardscenen betragtes fra alternative synsvinkler. I det første eksempel er op-vektoren ændret, svarende til at kameraet drejes omkring front-vektoren, således at billedet ses på skrå. Kameraindstillinger eksempel 1 Opløsning: 320x240 Afstand: 1000 Viewplane size: 640x480 Position: (320, 240, 1000) Front vektor: (0, -0.15, 1) Op-retning: (0.8, 0.5, 0) I det næste eksempel ses scenen oppefra. Dette er opnået ved at ændre kameraets position til et punkt et stykke over sceneelementerne. Front-vektoren er ændret til at være parallel med y-aksen i negativ retning derved kigges nedad, og op-retningen er ændret, så elementerne ses fra en ny vinkel. Kameraindstillinger eksempel 2 Opløsning: 320x240 Afstand: 1000 Viewplane size: 640x480 Position: (320, 1480, 0) Front vektor: (0, 1, 0) Op-retning: (0.5, 0, 0.5) Med disse 2 eksempler har vi demonstreret nogle af kameraets muligheder. Det er muligt at ændre kameraets indstillinger direkte fra brugergrænsefladen (indtast de ønskede indstillinger i felterne til højre, og tryk på position camera. Næste gang der traces, benyttes de nye kameraindstillinger). Dermed kan man eksperimentere med forskellige opløsninger, afstande, størrelser af viewplanet osv. 7.3 Antialiasing Der er implementeret to antialiasing-algoritmer samt en tracer uden antialiasing. Herunder ses resultatet af en tracing af standardscenen med hver af disse tre algoritmer, men derudover de samme indstillinger som blev benyttet i Figur 7.1.

46 Side 46 Figur 7.3: Standardscenen tracet uden antialiasing Figur 7.4: Standardscenen tracet med supersampling Figur 7.5: Standardscenen tracet med stokastisk antialiasing Det ses at uden antialiasing opstår hakker i kanterne. Specielt udtalt i kanten af skålen. Det er derimod vanskeligt at se forskel på supersampling og stokastisk antialiasing på disse billeder. På det supersamplede billede fornemmes dog nogle små hakker blandt andet i bordbenet, som ikke ses med stokastisk antialiasing. For tydeligere at kunne se forskellen på algoritmerne, zoomes ind på kuglen i skålen. Derved fremkommer nedenstående figur. Figur 7.6: Uden antialiasing Figur 7.7: Supersampling Figur 7.8: Stokastisk antialiasing Her ses aliasingen meget tydeligt, og forskellen på supersampling og stokastisk antialiasing fremgår også, idet man på Figur 7.8 kan se at pixlerne i kanten ikke er farvelagt jævnt, men at der derimod forekommer støj. På nedenstående figurer zoomes ind på intersection-elementet ved siden af skålen. Her ses tydeligere forskel på de to antialiasing-algoritmer. Figur 7.9: Supersampling: Den nederste kant kan stadig forekomme hakket selvom farverne er udjævnet. Figur 7.10: Stokastisk antialiasing. Hakker undgås ved at tilføje støj. Der får kanten til at virke uskarp. Ved supersampling bliver kanterne blødere, men da strålerne sendes ens for hver pixel, kan der stadig forekomme farveskift, der fornemmes som hakker på billedet. Ved stokastisk antialiasing bliver disse bløde hakker afløst af støj, som generer det menneskelige øje mindre. Efter således at have set på de visuelle aspekter af de implementerede algoritmer, kunne det være interessant at se på hastighederne af disse. Dette vil blive belyst kort i følgende afsnit.