Realtidsrendering av terräng med konsumenthårdvara (Real-Time Terrain Rendering with Consumer Level Hardware)

Transkript

1 Realtidsrendering av terräng med konsumenthårdvara (Real-Time Terrain Rendering with Consumer Level Hardware) Ett examensarbete av Martin Johannesson inom datalogi vid NADA, KTH. Namn: Martin Johannesson E-postadress: Handledare: Kai-Mikael Jää-Aro Examinator: Lars Kjelldahl Uppdragsgivare: Martin Johannesson

2 Sammanfattning Ett växande antal mjukvarutillämpningar, som simulatorer och spel, använder tekniker för realtidsrendering av terräng för att skapa en virtuell omgivning. Terrängrendering i realtid är en mycket krävande process och har historiskt krävt kraftfulla arbetsstationer för en acceptabel prestandanivå. Den snabba utvecklingen av grafikhårdvara i konsumentklassen har gjort det möjligt för utvecklare att använda terrängrendering i konsumentinriktad mjukvara. För att detta ska vara möjligt krävs dock att effektiva metoder för att organisera och rendera terrängdata används. Ett antal metoder för terrängrendering utvecklades under 1990-talet och början av 2000-talet, men få tar hänsyn till konsumenthårdvarans unika förutsättningar och egenskaper. Syftet med examensarbetet var att utvärdera ett antal olika metoder för terrängrendering med avseende på lämplighet för användning på konsumenthårdvara och att ta fram rekommendationer för metodval och implementation. Den största delen av arbetet bestod av en teoretisk utvärdering av de valda metoderna, men ett fåtal av de mest lämpade metoderna implementerades och utvärderades ytterligare i en prototyptillämpning. Arbetet resulterade slutligen i ett antal rekommendationer för val av metoder och anpassningar av de valda metoderna för terrängrendering på konsumenthårdvara. Rapporten innehåller en detaljerad beskrivning av både utvärderingsprocessen och rekommendationerna.

3 Abstract Real-Time Terrain Rendering with Consumer Level Hardware A growing number of software applications, such as simulators and games, make use of various real-time terrain rendering techniques to create an immersive virtual environment. Terrain rendering is a very demanding process and has historically required powerful workstations for acceptable real-time performance. However, the rapid development in consumer level graphics hardware have allowed developers to include terrain rendering in consumer level applications. In order to achieve a high frame rate, highly efficient methods for organizing and rendering terrain data are required. Several methods for terrain rendering were developed during the 1990s and early 2000s, but few take the unique conditions and properties of consumer level hardware into consideration. The purpose of the master s project presented in the thesis was to evaluate the suitability of various terrain rendering methods for use on consumer level hardware and to make recommendations based on the results of the evaluation. The bulk of the work consisted of a theoretical evaluation of the selected methods, but a few of the methods that were deemed more suitable were also implemented and further evaluated in a prototype application. The evaluations ultimately resulted in several recommendations for real-time terrain rendering with consumer level hardware. Both the entire evaluation procedure and the recommendations are presented in detail in the thesis.

4 Förord Denna rapport redogör för mitt examensarbete på institutionen för numerisk analys och datalogi (NADA) vid Kungliga Tekniska Högskolan (KTH) i Stockholm. Arbetet motsvarar 20 högskolepoäng och utgör det avslutande momentet för studier på Datatekniklinjen på KTH. Handledare på NADA var Kai-Mikael Jää-Aro och examinator var Lars Kjelldahl. Examensarbetets uppdragsgivare var jag själv, vilket hade både för- och nackdelar. Jag vill därför tacka alla inblandade för deras tålamod.

5 Innehållsförteckning 1 Inledning Bakgrund Problemställning Målsättning Avgränsningar Disposition Introduktion till 3d-grafikhårdvara Grundläggande begrepp Bildbuffert Hörn Texturmappning Djupbuffert Grafikpipeline Tidig pipeline Fixfunktionspipeline Programmerbar pipeline Allmän terrängrendering Grundläggande begrepp Höjdfält LOD (Level of Detail) Geometrisk avvikelse Vyvolymsgallring Baksidesgallring Några kända metoder för terrängrendering Brute Force Kvadträd Statisk LOD Diskret LOD Kontinuerlig LOD Lindstroms kontinuerliga LOD-metod ROAM-metoden Röttgers kontinuerliga LOD-metod Borttagning av gömda ytor med horisontberäkningar Förutsättningar och rekommendationer Hämtning av grafikdata Hörnbuffert Indexbuffert Effektiv parallellism Grafikprocessorns minnescache Grafikprocessorns hörncache Grafikhårdvarans minnesbandbredd Effektiv användning av hörnbuffertar Effektiv användning av hörnindexering Effektiv användning av tillståndsändringar Målsättning Jämförelse av metoder Lindstroms kontinuerliga LOD-metod ROAM-metoden... 30

6 3.5.3 Röttgers kontinuerliga LOD-metod Diskret LOD med hjälp av kvadträd Resultat av metodjämförelsen Min metod för terrängrendering Indata och triangulering Rendering av terrängen Resultat och slutsats Ljussättning av terräng Grundläggande tekniska förutsättningar Hörnbelysning Ljuskartor Per-pixelbelysning Några kända metoder för ljussättning av terräng En enkel belysningsmetod Hoffman och Mitchells metod för terrängbelysning Målsättning Min metod Lösning Skuggkarta Slutsats Texturering av terräng Några kända metoder för texturering av terräng Texturering med stor textur Repeterande texturrutor Repeterande texturlager med stor alfamask Stor textur med detaljtexturer Modellering av ekosystem Förutsättningar och rekommendationer Minnesförbrukning Texturfilter Mipmappning Övriga tekniska förutsättningar och rekommendationer Målsättning Min metod Jämförelse och val av metod Lösning Texturgenerering Slutsats Vegetation och atmosfäriska effekter Vegetation Atmosfäriska effekter Dis Markdimma Molnskugga Sammanställning och rekommendationer Rekommendationer för terrängrendering Rekommendationer för ljussättning Rekommendationer för texturering Förslag på realismförhöjande metoder Litteraturförteckning... 73

7 8.1 Referenser Övrig intressant litteratur i ämnet Bilaga 1 Terrängbilder... 78

8 1 Inledning 1 Inledning 1.1 Bakgrund Hårdvara i konsumentklassen för realtidsrendering av 3d-grafik utvecklats explosionsartat, både i avseende på prestanda och på försäljningsresultat. En anledning är den hårda konkurrens som råder mellan tillverkarna. Grafikkretsföretagens produktcykel har pressats ned till cirka sex månader och hårdvarans prestanda fördubblas i ungefär samma takt (NVIDIA Corporation, 2000(a)). Konkurrensen och massproduktionen av kretsar har bidragit till att maskiner som innehåller hårdvara för 3d-grafik kan säljas till ett överkomligt pris för genomsnittskonsumenten. Redan idag återfinns sådana maskiner i miljoner hushåll runt om i världen i form av tv-spelmaskiner och datorer. Det mjukvaruområde som har gynnats mest av den snabba utvecklingen är spel och annan underhållningsmjukvara, men det finns även ett flertal andra typer av tillämpningar som drar nytta av hårdvaran, bl.a. simulatorer och visualiseringsverktyg. Gemensamt för många tillämpningar är att 3d-hårdvaran används till rendering av en datorbaserad modell av verkligheten. För varje ny generation av grafikhårdvara och processorer kan modellen renderas med en större detaljrikedom. Hårdvarans prestandanivå kommer dock även inom en överskådlig framtid att sätta en övre gräns för detaljrikedomen. Följaktligen har mjukvaruutvecklare varit tvungna att utveckla ett flertal metoder för att effektivisera renderingsprocessen. 1.2 Problemställning I vissa tillämpningar, som till exempel simulatorer och spel, är visualisering av öppen terräng ett viktigt element. Historiskt har rendering av sådana miljöer i realtid varit en komplicerad process. Till stor del har detta berott på grafikhårdvarans hastighet och de stora mängder geometriska objekt, som utgör terrängen, som måste behandlas och renderas. Ett flertal metoder för rendering av terräng har beskrivits i vetenskapliga rapporter, men endast ett fåtal har haft förutsättningarna för realtidsrendering på konsumenthårdvara i åtanke. Detta är olyckligt då en av de största marknaderna för tilllämpningar som använder sig av terrängrendering är just konsumentmarknaden och begränsningarna hos konsumenthårdvara sammanfaller inte alltid med begränsningarna hos hårdvara för andra målgrupper. Det är därför intressant att utvärdera och om möjligt förbättra de metoder som används idag, med avseende på lämplighet för användning på konsumenthårdvara. 1.3 Målsättning Målet med examensarbetet var att undersöka, utvärdera, modifiera och, i vissa fall, implementera en delmängd av existerande metoder för realtidsrendering av terräng, för att slutligen kunna rekommendera lämpliga metoder för användning på konsumenthårdvara. Hela processen och resultatet skulle redovisas i rapporten, samt åskådliggöras i en fungerande prototypimplementation av föreslagna metoder. 1

9 1 Inledning 1.4 Avgränsningar På grund av det stora antalet metoder inom terräng- och miljörendering, har examensarbetet avgränsats till att enbart innefatta undersökning av metoder för höjdfältsbaserad terrängvisualisering med anslutande metoder för förhöjd realism. Exempel på metoder för förhöjd realism är olika typer av ljussättning, rendering av vegetation och atmosfäriska effekter. Med en höjdfältsbaserad terrängmodell menas en modell där terrängytan definieras av höjdvärden ordnade i ett rutnät. Anledningen till att enbart höjdfältsbaserade metoder har studerats är att majoriteten av befintliga metoder bygger på höjdfält. Dessutom är oftast existerande underliggande geografiska data angivna i form av ett höjdfält. Med konsumenthårdvara menas här främst datorer och grafikkort i konsumentklassen, men även tv-spelskonsoler ingår i samma kategori hårdvara. Då det är överlägset lättast att hitta information om PC-datorer med tillhörande grafikkort är det denna typ av hårdvara som behandlas i rapporten, om inget annat anges. De metoder och resultat som presenteras här är dock till största delen relevanta även för andra typer av konsumenthårdvara. 1.5 Disposition Rapporten är huvudsakligen organiserad i följande fyra delar: terrängrendering ljussättning av terräng texturering av terräng vegetation och atmosfäriska effekter Varje del utom den sista inleds med en översikt över relevanta begrepp, metoder och litteratur. Därefter följer en utvärdering av de olika metodernas lämplighet för implementation på konsumenthårdvara. Sedan beskrivs en implementation av den metod som har valts för användning i prototypen. Varje del avslutas med en utvärdering av implementationen. Den sista delen är av en mer resonerande natur och är mest avsedd för att ge en insyn i tekniker för rendering av vegetation och atmosfäriska effekter. 2

10 2 Introduktion till 3d-grafikhårdvara 2 Introduktion till 3d-grafikhårdvara 2.1 Grundläggande begrepp Bildbuffert Bilden som visas på en datorskärm består av ett rutnät av färgade rutor. En sådan ruta kallas för pixel (från engelskans picture element ) och varje pixel representeras som ett färgvärde i datorns grafikminne. Det område av minnet där färgvärdena lagras kallas (åtminstone här) bildbufferten. När ett färgvärde i bildbufferten ändras sker en motsvarande ändring på bildskärmen vid nästa bildskärmsuppdatering. Då frekvensen för bildskärmsuppdateringen oftast ligger i intervallet Hz, är fördröjningen mellan ändring i minnet och på bildskärmen som högst ms. Bildbufferten och dess koppling till bildskärmen är fundamenten hos tvådimensionell datorgrafik, men tredimensionell grafik bygger på samma grundläggande teknik. Den 3d-grafikhårdvara som används idag är optimerad för att rita och fylla trianglar i bildbufferten i en hög takt. Följaktligen måste ett 3d-objekt bestå av en mängd trianglar för att kunna behandlas och renderas av hårdvaran. Dessutom måste trianglarnas hörn transformeras från 3d-rummet till 2d-rummet (eller skärmrummet), eftersom ett 3d-objekt uttrycks i tredimensionella koordinater och en datorskärm är begränsad till två dimensioner (figur 1). Exakt hur transformationerna går till beskrivs inte i denna rapport då en lång matematisk utläggning krävs. Det är heller inte viktigt att förstå transformationerna i detalj för att förstå redogörelsen av examensarbetet i övrigt. Intresserade hänvisas till litteratur i ämnet (Angel, 2000). Objektet i 3D-rymden (0,0) Objektet i 2D på skärmen efter transformation x (0,1,1) (0,1,0) (1,1,0) y (120,117) (286,80) (500,107) (1,1,1) (370,160) (0,0,0) (292,267) (0,0,1) y (1,0,0) (132,347) (488,309) (1,0,1) (365,416) z x (640,480) Figur 1 Ett 3d-objekt måste transformeras från 3d-rymden till 2d-rymden för att kunna ritas ut på skärmen. 3

11 2 Introduktion till 3d-grafikhårdvara Renderingsprocessen av ett 3d-objekt kan förenklat delas upp i följande steg: 1. Konvertera 3d objektet till en mängd trianglar. 2. Transformera trianglarnas hörnpunkter till skärmkoordinater. 3. Rendera de transformerade trianglarna. Stegen är oberoende av varandra och utdata från varje steg är indata till nästa steg. Denna egenskap gör att processen är lämplig att utföras i en s.k. pipeline. Den hårdvara som används idag är därför baserad på en pipeline-arkitektur. En närmare studie av några typiska grafikpipelinemodeller följer i avsnitt Hörn Trianglarna i 3d-världen lagras i datorns minne som ett antal hörn. När en triangel ska renderas hämtas dess hörn från minnet och skickas till grafikkortet. I de APIer som används för realtidsrendering används ofta termen hörn för en instans av en datastruktur som innehåller ett flertal värden, som hörnkoordinater, texturkoordinater och färg. Vad texturkoordinater är förklaras senare i detta avsnitt Texturmappning En textur är en punktavbildad bild som kan appliceras på trianglar vid rendering. Förenklat resulterar detta i att färgen hos varje renderad pixel i en triangel influeras av färgen från en texel, vilket är ett annat namn för en pixel i texturen. Till exempel kan ett digitalt fotografi av en tegelvägg appliceras på ett 3d-objekts trianglar för att få objektet att se ut som en tegelvägg. För att kunna bestämma vilken texel en viss pixel influeras av används så kallade texturkoordinater. Texturen ges koordinater där (0,0) betecknar övre vänstra hörnet och (1,1) betecknar nedre högra hörnet (figur 2). Vidare brukar texturkoordinater anges i (u,v)-koordinater, vilket bara är en notation för vanliga 2d-koordinater. Detta gör det enklare att skilja på koordinater för hörn och andra punkter i 3dvärlden och koordinater i det tvådimensionella så kallade texturrummet. (0,0) (1,0) (0,1) (1,1) Figur 2 Bilden visar en tegeltextur och dess (u,v)-koordinater. Hörnen i en triangel som använder texturen tilldelas sedan texturkoordinater som representerar punkter i texturen. Vid rendering hämtas för varje pixel i triangeln en texel vars läge i texturen bestäms av en koordinat som fås genom interpolation av hörnens texturkoordinater (figur 3). 4

12 2 Introduktion till 3d-grafikhårdvara (0.2, 0.05) (0,0) (1,0) (0.1, 0.64) (0.8, 0.78) (0,1) (1,1) Figur 3 Triangelns hörn har texturkoordinater som bestämmer hur texturen appliceras på triangeln Djupbuffert När ett 3d-objekt renderas, ritas en triangel i taget ut i bildbufferten (Salvator, 2001). Detta skapar problem när två trianglar ligger bakom varandra i djupled, om triangeln närmast betraktaren ritas ut först. Det innebär då att när den bakomliggande triangeln ritas ut kommer dess pixlar att ritas ut i bildbufferten på samma ställe som den framförliggande triangelns pixlar tidigare ritades ut (figur 4). Figur 4 Den ljusare triangeln ligger egentligen framför den mörka triangeln, men om den mörka triangeln ritas ut efter den ljusa, ser det ut som den mörka är längst fram. Detta problem kan lösas på två sätt; antingen kan trianglarna före varje utritning sorteras i djupordning med hjälp av huvudprocessorn, utgående från betraktarens position och synvinkel eller så kan en så kallad djupbuffert användas i 3dgrafikhårdvaran. Det senare alternativet är att föredra och därför har i princip all 3dgrafikhårdvara i konsumentklassen en djupbuffert. Idén bakom djupbufferten är relativt enkel, men effektiv. För varje pixel som ritas ut, lagras ett djupvärde i djupbufferten på en plats som motsvarar pixelns position i bildbufferten. Nästa gång en pixel ska ritas ut på samma plats jämförs pixelns djupvärde med det djupvärde som redan finns i djupbufferten för den position där pixeln ska ritas ut. Om det visar sig att pixeln som ska ritas ut befinner sig djupare in i bilden än pixeln som redan är utritad avbryts utritningen av den nya pixeln. Resultatet är att de två trianglarna i exemplet ovan ritas ut korrekt oavsett vilken som ritas ut först. På grund av att djupbufferttesten sker tidigt i en modern pipeline kan det gå snabbare om trianglarna ritas ut framifrån och bakåt än annars. Detta beror på att utritningsoperationerna då avbryts tidigare. 5

13 2 Introduktion till 3d-grafikhårdvara 2.2 Grafikpipeline Den pipelinemodell som beskrivs här är löst baserad på de modeller som används i existerande konsumenthårdvara för PC-datorer. I litteratur om ämnet (NVIDIA Corporation, 1999) jämförs pipelinearkitekturen med ett löpande band på en fabrik. Idén går ut på att varje steg av renderingsprocessen utförs av en del av hårdvaran som är specialiserad på just det steget och kan utföra det snabbt och effektivt. Varje steg tar som indata de utdata som närmast föregående steg i pipelinen producerat och efter behandling skickas enhetens utdata vidare som indata till närmast efterföljande steg i pipelinen (figur 5). indata = x Steg 1 x x x Steg 2 Steg 3 Steg 4 x = utdata Figur 5 Indata skickas genom pipelinen och manipuleras av varje steg innan det skickas vidare till nästa steg. Eftersom varje stegs verksamhet är helt oberoende av vad som för tillfället pågår i de andra stegen, så länge korrekta indata produceras av föregående steg, kan alla steg i pipelinen arbeta samtidigt och utan paus. Att inte använda en pipeline och enbart ha ett sammansatt steg som gör hela arbetet skulle vara som att ha en pipeline där enbart ett steg i taget kan arbeta. Detta innebär att varje enhet av indata till det sammansatta steget skulle behöva genomgå alla steg i renderingsprocessen innan en ny indataenhet kunde börja behandlas (figur 6). Däremot kan en pipeline arbeta med lika många indataenheter samtidigt som det finns steg i pipelinen. Detta ökar effektiviteten avsevärt. Tid Renderingssteg med pipeline Steg 1 Steg 2 Steg 3 Steg 4 Steg 5 Indata 1 Indata 2 Indata 1 Indata 3 Indata 2 Indata 1 Indata 4 Indata 3 Indata 2 Indata 1 Indata 5 Indata 4 Indata 3 Indata 2 Indata 1 Renderingssteg utan pipeline Steg 1 Steg 2 Steg 3 Steg 4 Steg 5 Indata 1 Indata 1 Indata 1 Indata 1 Indata 1 6 Indata 6 Indata 5 Indata 4 Indata 3 Indata 2 Indata 2 7 Indata 7 Indata 6 Indata 5 Indata 4 Indata 3 Indata 2 8 Indata 8 Indata 7 Indata 6 Indata 5 Indata 4 Indata 2 9 Indata 9 Indata 8 Indata 7 Indata 6 Indata 5 Indata 2 10 Indata 9 Indata 8 Indata 7 Indata 6 Indata 2 11 Indata 9 Indata 8 Indata 7 Indata 3 12 Indata 9 Indata 8 Indata 3 13 Indata 9 Indata 3 Figur 6 När en pipeline med fem steg används hinner nio indataenheter behandlas innan tre indataenheter har hunnit behandlas utan pipeline. 6

14 2 Introduktion till 3d-grafikhårdvara I grafikpipelinefallet består indata av triangelhörn. De tre grundläggande stegen som beskrevs avsnitt 2.1 är i princip korrekta, men i praktiken delas stegen upp i flera steg. Dessutom tillkommer ett antal nya steg Tidig pipeline Innan den första 3d-grafikhårdvaran i konsumentklassen kom ut på marknaden sköttes hela renderingsprocessen på konsumentinriktade datorer av huvudprocessorn. Detta innebar i princip att all processortid användes till renderingsprocessen och inga resurser fanns kvar till annat (NVIDIA Corporation, 1999). Många tillämpningar, som till exempel simulatorer och spel, behöver även processortid till fysikberäkningar och andra uppgifter som inte är grafikrelaterade. Detta ledde till ett behov av 3d-grafikhårdvara som i någon grad var frikopplad från processorn och därmed kunde ge mer processortid över till annat. Första generationens 3d-grafikkretsar avlastade processorn genom att ta över utritningen av trianglar i 2d. Med andra ord behövde processorn fortfarande utföra krävande matrisberäkningar för att transformera trianglarnas hörn till 2d-rummet. Utvecklingen av 3d-hårdvara fortsatte dock i en takt som var tre gånger högre än takten för utveckling av processorer (NVIDIA Corporation, 2000(a)) Fixfunktionspipeline Nästa steg var att flytta även transformationerna från huvudprocessorn till 3dhårdvaran (Fosner, 2000). I praktiken innebar detta att en processor för matrismultiplikationer infördes i andra generationens pipeline (figur 7). Detta innebar att hela renderingsprocessen av objekt uppbyggda av trianglar kunde skötas av grafikhårdvaran i princip oberoende av processorn. Problemet att omvandla objekt som utgörs av andra primitiver än trianglar i realtid med hjälp av 3d-hårdvara är ännu inte helt löst, men en del försök att automatiskt omvandla högre ordningens ytor till trianglar har gjorts (ATI Technologies, 2001). Hörndata Transformation av hörn Klippning av trianglar Borttagning av bortvända ytor Rastrering Texturering av pixlar Djuptest Alfatest Stenciltest Alfablandning Figur 7 En fixfunktionspipeline kan modelleras enligt figuren Programmerbar pipeline Tredje generationens pipeline (figur 8), som användes till viss del vid implementationen av examensarbetets prototyptillämpning, ökade pipelinens flexibilitet genom att ersätta matrismultiplikationsprocessorn med en mer generell processor för manipulation av triangelhörn (Maughan och Wloka, årtal okänt). Utvecklaren har möjligheten att skriva små program för hörnprocessorn som körs för varje hörn som passerar genom pipelinen (NVIDIA Corporation, årtal okänt(b)). Givetvis kan ett program skrivas, som gör exakt samma matrismultiplikationer som matrismultiplikationsprocessorn i föregående generations pipeline. 7

15 2 Introduktion till 3d-grafikhårdvara Transformation av hörn Texturering av pixlar Hörndata Klippning av trianglar Borttagning av bortvända ytor Rastrering Djuptest Alfatest Stenciltest Alfablandning Manipulering av hörn med hjälp av hörnprogram Manipulering av pixel med hjälp av hörnprogram Figur 8 Den programmerbara pipelinen har alternativa vägar för att bibehålla kompatibiliteten med fixfunktionspipelinen. En liknande förändring infördes också på rastreringsnivå i pipelinen (NVIDIA Corporation, årtal okänt(a)). Istället för att enbart tilldela pixlarna i triangeln en färg från en eller flera texturer utökades pipelinen med en sorts pixelprocessor som kör ett litet program för varje pixel som ritas ut. Exempel på tillämpningar är bumpmappning (Angel, 2000) och noggranna ljusberäkningar, där ljusmodellen kan behandla varje pixel istället för den tidigare vanligare metoden att interpolera ljusnivåerna mellan hörnen (NVIDIA Corporation, 2000(b)). Även här kan ett program skrivas som utför samma operationer på pixeln som föregående generations pipeline utförde för varje pixel. 8

16 3 Allmän terrängrendering 3 Allmän terrängrendering 3.1 Grundläggande begrepp Höjdfält Det vanligaste sättet att representera terrängens struktur i ett visst område är att använda s.k. höjdfält (Angel, 2000). Ett höjdfält kan ses som ett antal höjdmätningar inom ett visst område. Matematiskt kan höjdfält definieras som de punkter som uppfyller en ekvation på formen z = f ( x, y) där (x,y) är koordinater i ett plan och z är höjden över planet. I tillämpningar för terrängvisualisering brukar ett reguljärt höjdfält användas, vilket innebär att mätpunkterna har valts så att de är ekvidistanta i xy-planet. Förenklat kan ett reguljärt höjdfält ses som ett rektangulärt rutnät där en höjdmätning har gjorts vid varje punkt (figur 9 och figur 10). På grund av de geometriska egenskaperna hos ett reguljärt höjdfält lagras höjdmätningarna lämpligen i matrisform, där varje indexpar i matrisen har ett motsvarande xy-koordinatpar. För att skapa en kontinuerlig yta av punkterna kan linjärinterpolation användas för att beräkna z-värden mellan närliggande punkter. Ytan blir då en approximation av den kontinuerliga yta som ligger till grund för höjdmätningarna. Om linjärinterpolationen utförs enligt figur 11, kan ytan ses som ett antal hopsatta trianglar. Det är denna egenskap som utnyttjas i terrängvisualisering, då 3d-grafikhårdvaran renderar trianglar effektivare än andra geometriska primitiv. z z y y Figur 9 Höjdmätningar i punktform. x Figur 10 Höjdmätningarna i rutnätsform x Figur 11 Triangulering av höjdfältet. 9

17 3 Allmän terrängrendering En av de mest uppenbara fördelarna med höjdfältsrepresentationen av terräng är att mätvärdesmatrisen är en lämplig datastruktur för lagring och behandling med hjälp av en dator. Dessutom är det ofta i höjdfältsform som lantmäterimätningar lagras, vilket gör det relativt enkelt att få tag på data till visualiseringstillämpningar. Ett vanligt exempel är de DEM-filer (Digital Elevation Model), som U.S. Geological Survey använder (U.S. Geological Survey, 2001). Representationen har dock vissa nackdelar. För att visualisera terrängen med hög detaljnivå krävs många och täta höjdmätningar. Detta resulterar i hög minnesförbrukning och lång körningstid för algoritmer som behandlar varje enskild punkt. En annan egenskap som gör höjdfältsrepresentationen olämplig för vissa terrängpartier är att vertikala stup och överhäng inte kan representeras. Detta beror på avståndet mellan punkterna i planet (figur 12) och det faktum att varje punkt enbart har en möjlig höjdmätning. Trots nackdelarna är denna representation ändå ofta en tillräckligt bra approximation för användning i interaktiva visualiseringstillämpningar. z x Figur 12 Punktavståndet begränsar brantheten LOD (Level of Detail) Inom terrängvisualisering används ofta s.k. LOD-tekniker. Teknikerna är inte enbart avsedda för terrängvisualisering utan används inom många visualiseringsområden där 3d-grafik används. Övergripande kan det sägas att LOD-tekniken går ut på att objekt renderas med olika detaljnivå beroende på ett antal faktorer, som till exempel avståndet till betraktaren och objektets geometriska komplexitet (Nirenstein och Winberg, 1998). Ett objekt med låg detaljnivå kan i regel renderas snabbare än ett objekt med hög detaljnivå. Detta kan utnyttjas genom att objekt som befinner sig långt från betraktaren renderas med en låg detaljnivå utan att betraktaren upplever någon nämnvärd skillnad. Rent tekniskt upptar ett objekt som renderas på avstånd ett mindre antal pixlar i bildbufferten än ett objekt nära betraktaren på grund av perspektivtransformationen och därmed är pixelavvikelsen mellan en hög detaljnivå och en låg detaljnivå ofta relativt låg. Givetvis beror det på hur den lägre detaljnivån konstrueras samt objektets geometriska egenskaper. Ett objekt med rundad yta kan till exempel upplevas som kantigt i en låg detaljnivå om objektet enbart är uppbyggt av polygoner, vilket är vanligt i realtidsgrafiksystem. I många terrängrenderingsmetoder utgör LOD metodens kärna. Det finns ett flertal olika sätt att tillämpa LOD med höjdfält, men den grundläggande idén är 10

18 3 Allmän terrängrendering densamma. Höjdfält renderas, som tidigare nämnts, som en mängd trianglar. Rendering av terrängens högsta detaljnivå innebär att alla mätpunkter i höjdfältet används som hörnpunkter i trianglarna vid utritning. En låg detaljnivå innefattar få mätpunkter och därmed också få, men stora, trianglar (figur 13). Om en lägre detaljnivå används vid utritningen av terrängytan blir resultatet en approximation av den högsta detaljnivån. Existerande terrängrenderingsmetoder använder flera olika typer av LOD och villkor för val av detaljnivå. Ett urval av intressanta metoder och angreppssätt har studerats under examensarbetets gång och en närmare genomgång följer i avsnitt 3.2. Figur 13 Bilden visar en möjlig triangulering av en lägre detaljnivå Geometrisk avvikelse När geometrisk avvikelse nämns i terrängrenderingssammanhang menas hur mycket en viss lägre detaljnivås triangulering avviker från den högsta detaljnivåns triangulering. Avvikelsen mäts vid varje mätpunkt som absolutvärdet av det vertikala avståndet mellan punkten och den yta som definieras av den lägre detaljnivån. Ofta har varje terrängrenderingsmetod ett eget sätt att beräkna den geometriska avvikelsen i ett område som omfattar mer än en punkt. Exempelvis skulle den totala geometriska avvikelsen i ett område kunna definieras som medelvärdet av den geometriska avvikelsen i mätpunkterna. Det är vanligt att terrängrenderingsmetoder använder sig av den geometriska avvikelsen projicerad i skärmrummet. Detta innebär att en vektor som motsvarar avståndet från mätpunkten till ytan transformeras till skärmrummet på samma sätt som objekt som ska renderas. Vektorns längd motsvarar då den geometriska avvikelsen på skärmen. Med andra ord tar en metod, som använder sig av den geometriska avvikelsen projicerad i skärmrummet, hänsyn till hur stor avvikelsen ser ut att vara från betraktarens synpunkt Vyvolymsgallring Generellt gäller att ju färre objekt som behandlas och renderas, desto snabbare går renderingsprocessen. Om alla objekt i den virtuella världen inte är i betraktarens synfält renderas de i onödan och dyrbar renderingstid slösas, eftersom objekt som inte är i synfältet förkastas av hårdvaran i ett sent skede i renderingsprocessen. Av den anledningen används ofta en metod som på engelska kallas frustum culling, här översatt till vyvolymsgallring, för att undvika att objekt som är utanför synfältet renderas (Picco, 2003). Metoden går förenklat ut på att en volym, i form av en 11

19 3 Allmän terrängrendering avkapad pyramid (figur 14), som utgör det område som betraktaren kan se, beräknas och sedan görs ett tredimensionellt överlappningstest för varje objekt och den så kallade vyvolymen. Om objektet överlappar vyvolymen renderas det, annars inte. Intressant att notera är att vyvolymen begränsas av ett främre och ett bakre plan, som gör att även objekt som är för nära eller för långt bort från betraktaren förkastas av överlappningstestet. Detta ger ytterligare prestandavinster. Figur 14 Vyvolymen har ett främre och ett bakre plan. Anmärkningsvärt är också att vyvolymsgallring kan användas på flera nivåer, då överlappningstestet kan göras på hela objekt eller på de primitiv som utgör objektet. Det senare innebär att om ett objekt endast delvis överlappar vyvolymen kan de primitiv som är utanför vyvolymen förkastas och detta kan innebära prestandaökningar om objektet innehåller ett tillräckligt stort antal primitiv. Det kan tyckas uppenbart att det faktum att färre objekt och primitiv renderas leder till en effektivare renderingsprocess, men så är inte alltid fallet. Detta beror på hårdvarans utformning och de undantag som rör terrängrendering tas upp i ett senare avsnitt Baksidesgallring En yta som är vänd bort från betraktaren behöver aldrig renderas, förutsatt att dess baksida inte är synlig (Weeks, 1997). Om ytan är en del av ett solitt objekt, som till exempel en kulle, kan den alltså förkastas. Det är en konceptuellt enkel idé, men två problem kvarstår. Hur beräknar man om en triangel är vänd från betraktaren eller inte och när i processen ska bortvända trianglar förkastas Innan triangeln hämtas till grafikhårdvaran för rendering kan en skalärprodukt för triangelns normalvektor N och en vektor V som motsvarar betraktarens vyriktning beräknas. Ur skalärprodukten kan sen vinkeln a mellan de två vektorerna beräknas enligt följande: cos( a ) = N V a = arccos( N V ) Om vinkeln a är mindre än 90 grader är triangeln vänd från betraktaren, förutsatt att triangelns normalvektor är riktad åt det håll ytan är vänd. 12

20 3 Allmän terrängrendering För terrängrendering, där ett stort antal trianglar renderas är detta kanske inte den bästa metoden, då en skalärprodukt skulle behöva räknas ut för varje triangel för varje bildruta. Ett alternativ är att låta hårdvaran bestämma om triangeln är bortvänd efter att den har transformerats och projicerats till skärmrummet (Salvator, 2001). Om hörnpunkterna för trianglarna i terrängen alltid anges medurs kan hårdvaran enkelt se att en triangel är bortvänd genom att hörnen kommer vara ordnade moturs i skärmrummet efter transformation och projektion (figur 15). Nackdelen med detta sätt är att de tre hörnpunkterna måste skickas till hårdvaran och triangeln förkastas inte förrän den ska rastreras Framsidan Figur 15 För betraktaren tycks hörnen i den bortvända triangeln vara ordnade moturs. 3.2 Några kända metoder för terrängrendering Det finns ett flertal kända metoder för att effektivisera visualisering av höjdfältsbaserad terräng, varav vissa är triviala, men forskare inom datorgrafik har utvecklat mer avancerade algoritmer och datastrukturer. I detta avsnitt följer en genomgång av några av de mest framträdande metoderna. Gemensamt för de flesta metoder är att de går ut på att i någon mening minimera det antal trianglar som behandlas och renderas i varje bildruta. I metodsummeringarna nedan är detta en underförstådd princip om inget annat anges. Flera av metoderna kan dessutom kombineras för en ännu effektivare visualiseringsprocess Brute Force Den enklaste metoden rent konceptuellt är brute force -metoden. Som namnet antyder går den ut på att behandla problemet med ren datorkraft, vilket innebär att samtliga trianglar i höjdfältet ritas ut i varje bild. Fördelarna med metoden är just enkelheten i både teori och implementation, samt att höjdfältet ritas ut korrekt utan ytterligare approximationer eller fel. Tyvärr överväger nackdelarna i dagsläget. Hårdvaran har ännu inte nått den prestandanivå som skulle krävas för att rita ut alla trianglar för ett stort terrängområde i en tillfredställande bildhastighet. 13

21 3 Allmän terrängrendering Troligtvis kommer brute force -metoden inte att bli användbar inom en överskådlig framtid, då kraven på detaljnivån hos terrängen ökar i takt med vad hårdvaran kan hantera. Vissa modifikationer för att göra metoden effektivare kan införas, som till exempel baksidesgallring, men metoden blir fortfarande inte tillräckligt effektiv Kvadträd Ett kvadträd är en hierarkisk datastruktur (Weisstein, 1999) som kan användas för hierarkisk uppdelning av höjdfält. Matematiskt kan trädet ses som en riktad acyklisk graf, där varje nod kan ha upp till fyra barnnoder (figur 16). Ett kvadträd kan enkelt konstrueras för ett höjdfält i matrisform. Hela matrisen motsvarar rotnoden. En logisk uppdelning av matrisen i kvadranter ger upphov till fyra lämpliga barnnoder, där varje kvadrant motsvarar en barnnod. Kvadranterna kan sedan i sin tur delas upp i fyra kvadranter som då motsvarar kvadrantens fyra barnnoder. En sådan uppdelning kan göras för varje nivå tills matrisen inte kan delas upp ytterligare, men alla tillämpningar av metoden behöver inte en så fullständig uppdelning, utan nöjer sig med ett visst antal nivåer (figur 17). Figur 16 Exempel på hur ett kvadträd kan se ut. Figur 17 Höjdfält uppdelat i ett kvadträd där löven motsvarar block av 3x3 mätpunkter. Den mest uppenbara fördelen med att använda ett kvadträd för terrängvisualisering är att hierarkisk vyvolymsgallring kan användas. På varje nivå i trädet utförs vyvolymsgallring på ett omslutande rätblock för hela nodens block av trianglar. Eftersom varje barnnods block av trianglar utgör en delmängd av nodens triangelblock behöver ytterligare vyvolymsgallring inte utföras på barnnoder om noden ligger helt utanför vyvolymen. Detta gör att färre vyvolymstester behöver göras när kvadträd används. Vissa metoder för att dela upp ett höjdfält kan leda till att sprickor uppstår i terrängen mellan olika block, men i detta fall används fortfarande den ursprungliga trianguleringen av höjdfältet och därmed undviks sådana problem. 14

22 3 Allmän terrängrendering Statisk LOD För att reducera antalet trianglar som ritas ut, men samtidigt bibehålla en relativt bra approximation av ursprungsytan, kan olika detaljnivåer gälla i olika delar av terrängen. Med andra ord kan fler mätpunkter användas där en lägre detaljnivå skulle avvika för mycket från den högsta detaljnivån. Exempelvis kan en lägre detaljnivå användas i områden där ytans krökning är liten utan att avvikelsen från en högre detaljnivå blir för stor (figur 18). I motsats till detta bör ett område där krökningen är stor ha en hög detaljnivå på grund av att fler trianglar krävs för att inte ytan ska få ett kantigt utseende. Metoden kallas statisk eftersom terrängens detaljnivå inte ändras under körningen av visualiseringen, utan enbart beräknas i förväg. Hög detaljnivå Låg detaljnivå Figur 18 Terrängpartiet till vänster har större avvikelse mellan detaljnivåerna än terrängpartiet till höger Diskret LOD Ett annat sätt att använda olika detaljnivåer är diskret LOD (Salvator, 2001). Metoden innebär att terrängens höjdfält delas upp i sektioner av godtycklig storlek och detaljnivån väljs individuellt för varje sektion ur ett fördefinierat urval av fasta detaljnivåer (figur 19 och 20). Valet av detaljnivå görs i varje bildruta baserat på ett villkor, som kan bero på ett flertal faktorer som till exempel avståndet till betraktarens position och storleksordningen på den geometriska avvikelsen mellan en högre och en lägre detaljnivå. Metoden kallas diskret på grund av att detaljnivån för en terrängsektion varierar mellan vissa fasta utvalda detaljnivåer utan mellanliggande nivåer. Vanligtvis kombineras metoden med en kvadträdsorganisation av de olika sektionerna, för att kunna dra nytta av hierarkisk vyvolymsgallring. Om olika detaljnivåer används för olika angränsande delar av terrängen kan sprickor uppstå mellan delarna, men detta kan undvikas genom att de olika delarna får en gemensam triangulering där de olika delarna möts. Figur 19 Sektion med hög detaljnivå. Figur 20 Sektion med låg detaljnivå. 15

23 3 Allmän terrängrendering Kontinuerlig LOD Ett flertal metoder för visualisering av terräng har utvecklats av forskare och utvecklare på universitet och företag. Majoriteten av dessa metoder bygger på någon form av kontinuerlig LOD (Lindstrom m.fl., 1996). Grovt förenklat går metoderna ut på att i realtid beräkna vilken detaljnivå, som ska användas i olika områden av terrängen. Valet av detaljnivå baseras på ett antal faktorer, som till exempel avståndet till betraktaren. Kontinuerlig LOD skiljer sig dock från diskret LOD genom att inga fasta detaljnivåer används. Varje triangel i höjdfältet kan antingen renderas eller slås ihop med närliggande trianglar och ersättas med en enda stor triangel i varje bildruta (se figur 21), vilket innebär att hela spektrumet av möjliga detaljnivåer kan förekomma. Figur 21 Trianglarna slås ihop och ersätts av större trianglar. Gemensamt för de flesta metoder som använder sig av kontinuerlig LOD är att valet av detaljnivå baseras på storleken av ett approximationsfel relativt den högsta detaljnivån. Nedan följer en genomgång av några av de viktigaste och oftast implementerade metoderna Lindstroms kontinuerliga LOD-metod På SIGGRAPH-konferensen 1996 presenterades en metod för terrängrendering, som utvecklats vid Georgia Institute of Technology av bl.a. Peter Lindstrom. Metoden använder sig av kontinuerlig LOD och är baserad på höjdfält. Vid körning delas metoden upp i två faser för varje bildruta: en förenklingsfas och en renderingsfas. Förenklingsfasen förenklar höjdfältet genom att välja lägre detaljnivåer för vissa områden tills den geometriska avvikelsen projicerad i skärmrummet blir för stor. Med hjälp av en kvalitetsfaktor kan gränsen för avvikelsen justeras. Genom att dela upp höjdfältet i ett antal block och sedan organisera dem i ett kvadträd kan områden som ligger utanför vyvolymen förkastas med hjälp av vyvolymsgallring. Även förenklingsfasen är uppdelad i två faser. Båda faserna behandlar höjdfältet nerifrån och upp. Först sker en mätpunktsbaserad förenkling, där synliga blocks triangulering av högsta detaljnivån undersöks av algoritmen. Om förenklingsvillkoret är uppfyllt för två sammanhängande trianglar slås de ihop till en enda stor triangel (figur 22). Resulterande trianglar undersöks sedan rekursivt och förenklas tills hela blockets triangulering inte kan förenklas mer. Metoden kan dock rationalisera processen till en viss del genom att vissa block, där alla trianglar uppenbarligen ska förenklas, förenklas utan att undersöka förenklingsvillkoret för varje individuell triangel. 16

24 3 Allmän terrängrendering Därefter sker en blockbaserad förenkling där hela block slås ihop till stora trianglar beroende på maxavvikelsen i varje block på mätpunktsnivå. Trianguleringsförenklingar ger ofta upphov till sprickor och så kallade T-korsningar (figur 23) i terrängytan där trianglar av olika detaljnivåer möts. Metoden har dock en algoritm för att lösa detta genom att vissa trianglar och mätpunkter i angränsande trianglar tas bort för att samma detaljnivå ska uppstå lokalt. Även angränsande block behandlas för att undvika att sprickor uppstår mellan blocken. Figur 22 Förenkling och sammanslagning av trianglar i två steg. T-korsning T-korsning Figur 23 En T-korsning hänger inte ihop när punkt 5 inte ligger i samma plan som triangel Renderingsfasen går rekursivt igenom varje block och konstruerar en serie triangelremsor som sedan renderas. För att höja effektiviteten använder även renderingsfasen sig av vyvolymsgallring för varje block, genom att undersöka om ett omslutande rätblock för hela blocket överlappar vyvolymen eller inte. Om ingen överlappning sker förkastas blocket ROAM-metoden En populär terrängrenderingsmetod bland utvecklare är ROAM (Real-time Optimally Adapting Meshes), som utvecklats i samarbete mellan Los Alamos National Laboratory och Lawrence Livermore National Laboratory. Även ROAM är en höjdfältsbaserad metod som använder sig av kontinuerlig LOD. Den geometriska avvikelsen projicerad i skärmrummet används som förenklingsfaktor i metoden, som beskrivs i ROAM-rapporten (Duchaineau m.fl., 1997), men andra faktorer kan användas. Trianguleringen av höjdfältet lagras i ett s.k. binärt triangelträd. Trädets rot (nivå 0) består av en enda stor triangel. Genom att dela rottriangeln på mitten i två delar fås noderna på nivå 1 i trädet. En likadan uppdelning av de två trianglarna på nivå 1 ger fyra trianglar på nivå 2. Ytterligare nivåer i trädet fås på samma vis genom rekursiv uppdelning (figur 24). 17

25 3 Allmän terrängrendering Ett rektangulärt höjdfält kan representeras av två binära triangelträd, där rottrianglarna har en gemensam bassida. Trianguleringen av höjdfältet får olika detaljnivå i olika områden av terrängen genom att trianguleringsmetoden inte väljer samma djup för trädet överallt. Där metoden anser att en mer detaljerad triangulering behövs delar den alltså upp trianglarna ytterligare genom att gå djupare i trädet. En viktig egenskap för binära trianguleringar som utgör en sammanhängande yta utan sprickor och T-korsningar är att alla grannar till en viss triangel t tillhör en nivå som är högst ett steg från den nivå t tillhör. Basgrannar tillhör antingen samma nivå som t eller närmast grundare nivå medan kortsidegrannar tillhör antingen samma nivå som t eller närmast djupare nivå. Nivå 0 Nivå 1 Nivå 2 Nivå 3 Nivå 4 Figur 24 Bilden visar de första fem nivåerna i ett binärt triangelträd. Själva förenklingsprocessen är upplagd på ett i sammanhanget ovanligt sätt. Istället för att börja om trianguleringen från början i varje bildruta, använder ROAM trianguleringen från förra bildrutan som utgångspunkt. För att ändra detaljnivån använder sig ROAM av två prioritetsköer, där den ena prioritetskön innehåller trianglar som ska delas och den andra innehåller trianglar som ska sättas ihop. Prioriteten i köerna bestäms av förenklingsfaktorn som beskrivs ovan. Detta gör att trianglar som är mest lämpliga att dela eller sätta ihop behandlas först. För att bibehålla en sammanhängande yta utan sprickor i det binära triangelträdet måste vissa trianglar ibland dessutom delas i en rekursiv följd tills trädet återigen uppvisar de grannegenskaper som beskrevs i föregående avsnitt. Det finns ett flertal fördelar med ROAM-metodens sätt att angripa problemet. Kösystemet kan ses som ett system för progressiv optimering, eftersom delningarna och hopsättningarna kan avbrytas när som helst. En konsekvens av detta är att en fast bildhastighet kan uppnås genom att köoperationerna avbryts när det är dags att byta bildruta. 18

26 3 Allmän terrängrendering I övrigt kan nämnas att metoden kan använda sig av vyvolymsgallring för att öka effektiviteten. Dessutom kan hörninterpolation användas i ROAM, vilket innebär att när en ny triangelhörnpunkt introduceras i trianguleringen, ritas den inte ut i sin faktiska position direkt, utan börjar ritas ut i ett läge som gör att trianguleringen ser oförändrad ut. I efterföljande bildrutor flyttas sedan hörnpunkten tills den når sin slutgiltiga position. Detta gör att ändringen i trianguleringen blir svårare att upptäcka Röttgers kontinuerliga LOD-metod En annan populär metod för terrängrendering utvecklades 1998 av Stefan Röttger m.fl. vid Universität Erlangen-Nürnberg. Liksom ovanstående metoder använder den sig av höjdfältrepresentation av terrängen och kontinuerlig LOD. Även här är förenklingsfaktorn baserad på den geometriska avvikelsen projicerad i skärmrummet. En kvalitetsfaktor ingår i beräkningen av förenklingsfaktorn och kan användas för att justera avvikelsegränsen. Förenklingsfaktorn kan dessutom förberäknas för varje LOD-nivå. Höjdfältet organiseras i ett kvadträd i form av en binär matris (figur 25 och 26), där ett element är satt till 1 om noden har barnnoder. Trianguleringsprocessen börjar uppifrån i trädet i varje bildruta och undersöker för varje nod den besöker om maxavvikelsen för nodens underliggande nivåer överstiger förenklingsfaktorn. I så fall sätts nodelementet i den binära matrisen till ett och nodens fyra barnnoder behandlas på samma sätt. I annat fall sätts nodelementet i den binära matrisen till noll och noden blir ett löv i trädet. När trianguleringen är klar representerar löven block av trianglar i olika detaljnivåer Figur 25 Den binära matrisen. Frågetecknen är ospecificerade element. Figur 26 Den binära matrisen motsvarar den vänstra trianguleringen av ett 9x9-höjdfält. I den högra trianguleringen har T-korsningar tagits bort enligt metoden. Renderingsprocessen traverserar trädet rekursivt och bildar triangelsolfjädrar av triangelblocken i löven. Vyvolymsgallring kan användas och då besöks inte noder som inte ligger i vyvolymen. Om närliggande block har olika detaljnivåer som skiljer sig med mer än en nivå, kan vissa trianglar förenklas ytterligare vid renderingsprocessen för att undvika att sprickor och T-korsningar bildas. Dessutom är det relativt enkelt att använda hörninterpolation med metoden. 19

27 3 Allmän terrängrendering Borttagning av gömda ytor med horisontberäkningar Om betraktaren befinner sig nere i en dalgång är bara dalens väggar synliga. Då är det önskvärt att den dolda terrängen inte renderas. Ett sätt att förkasta dolda delar av terrängen är att använda sig av horisontberäkningar (Mortensen, 2000). Översiktligt går metoden ut på att det som ligger bortom horisonten inte är synligt. Alltså behöver metoden veta vilka delar av terrängen som är synliga från olika vypunkter. Det grundläggande villkoret är att en mätpunkt i terrängens yta är gömd om vypunkten ligger bortom och under mätpunktens horisont (figur 27). Detta kan avgöras med ett synlighetstest, enligt följande: h R p Figur 27 Punkten p är gömd för betraktaren om denne befinner sig i område R. Punkten p är gömd om vypunkten ligger i R. Området R brukar kallas för en occlusion region på engelska. Synlighetstestet är dock konservativt, i den meningen att det kan finnas positioner för vypunkten utanför R från vilka punkten p också är gömd, till exempel bakom första kullen i figuren. I det ideala fallet skulle horisonten kunna räknas ut i alla riktningar från punkten p. h ( ϕ ) R ( ϕ ) p ϕ Figur 28 Den lägsta horisonten i ett visst riktningsintervall hittas och används sedan som horisont för hela intervallet. Dessvärre skulle detta ta för lång tid och för mycket minne i anspråk. En lösning är att dela upp horisonten i sektorer, där varje sektor motsvarar horisonten i ett riktningsintervall (figur 28). I varje sektor används det lägsta horisontvärdet i intervallet för synlighetstestet. Ju fler sektorer som används, desto större blir noggrannheten i synlighetsberäkningarna. Som vanligt måste en avvägning göras mellan metodens noggrannhet och resursförbrukning. Om horisonterna förberäknas 20

28 3 Allmän terrängrendering kan synlighetstestet utföras betydligt snabbare än om den vanligare metoden att undersöka skärningspunkterna för en linje mellan terrängpunkten och vypunkten används. Dessutom kan synlighetstestet utföras för en hel grupp terrängpunkter genom att en för gruppen gemensam lägsta horisont beräknas i alla riktningar. 3.3 Förutsättningar och rekommendationer Hämtning av grafikdata Grafikhårdvaran som sitter i PC-datorer har ett eget internminne som kallas videominnet. Det används exempelvis till att lagra bildbufferten och djupbufferten. Den del av minnet som återstår efter att de interna datastrukturerna skapats används till att lagra texturer och hörndata. Problemet är att många av dagens 3d-grafiktillämpningar använder mer texturer och hörndata än det finns plats för i videominnet. Lösningen är att lagra vissa data i datorns systemminne och sedan låta 3dgrafikhårdvaran hämta vad den behöver för tillfället från systemminnet. Det största problemet är då att överföringshastigheten från systemminnet är mycket lägre än från videominnet. Den första generationen 3d-grafikhårdvara för PC-datorer satt på samma buss som andra perifera enheter, som ljudkort, nätverkskort och internmodem. Denna buss kallas för Peripheral Component Interface och benämns oftast PCI. Tyvärr kan PCIbussen maximalt överföra 133 MB/s (Barron, 2001). Grafikhårdvarans behov av datatillförsel växte snabbt ifrån PCI-bussens förmåga att överföra data. Därför utvecklades den så kallade AGP-bussen, där AGP är en förkortning för Accelerated Graphics Port Interface. Huvudprocessorn Grafikkort AGP Kontrollkretsar Systemminne PCI PCI till perifera enheter Figur 29 Pilarna i bilden representerar bussar i systemet (Intel, årtal okänt). Första generationens AGP-buss kallas numera AGP 1x, där 1x betyder en gånger hastigheten hos första generationens AGP-buss. På samma sätt betyder följaktligen AGP 2x två gånger hastigheten hos första generationens AGP-buss. Överföringshastigheten hos AGP 1x är 264 MB/s och är därmed ungefär dubbelt så hög som överföringshastigheten hos PCI. Efterföljande generationer av AGP-bussen har dubblat hastigheten för varje ny generation och i skrivande stund har de första datorerna som utrustats med AGP 8x kommit ut på marknaden. Den teoretiskt 21

29 3 Allmän terrängrendering maximala överföringshastigheten hos AGP 8x är 2,1 GB/s. Fortfarande är dock AGP-bussen en flaskhals i systemet, men även överföringshastigheten mellan minnet och datorns kontrollkretsar är relevant när data överförs till grafikhårdvaran (figur 29). Grafikhårdvaran använder sig av DMA (Direct Memory Access) för att hämta data via AGP-bussen, vilket innebär att huvudprocessorn inte behöver vara involverad i överföringen, utan åtkomsterna sker direkt mellan grafikhårdvaran och systemminnet. Dock kan inte AGP nå hela systemminnet, utan kan bara komma åt en viss region av minnet som kallas AGP-minnet. Denna del av minnet är oftast väl tilltagen. Relevant är också att transaktioner på AGP-bussen kan göras samtidigt som transaktioner på PCI-bussen utförs. Dessutom kan huvudprocessorn läsa i systemminnet samtidigt som grafikhårdvaran läser i AGP-minnet Hörnbuffert Ett förhållandevis nytt begrepp inom 3d-området är den så kallade hörnbufferten (Dietrich, årtal okänt). I tidiga APIer för 3d-grafik på konsumenthårdvara, som till exempel Glide (3Dfx Interactive, Inc. 1997), angavs varje hörn i trianglarna för sig i ett funktionsanrop för triangelutritning. Dagens APIer och drivrutiner använder sig istället av hörnbuffertar där ett antal hörndatastrukturer ligger lagrade sekventiellt i en vektor. Vid utritning anges då som parameter till renderingsfunktionsanropet enbart en pekare till hörnbufferten samt ett heltal som talar om hur många av hörnen som ska behandlas. Detta är en effektivare metod på många sätt och inte enbart för att funktionsanrop är en dyr operation, i fråga om processortid. I en hörndatastruktur lagras ofta ett flertal olika hörnegenskaper, som position, färg, normalvektor och texturkoordinater. Hädanefter kommer termen hörn att användas både i den geometriska betydelsen och för att beteckna en instans av en hörndatastruktur. För att hårdvaran och mjukvaran ska veta hur ett hörn lagras i minnet används ofta ett så kallat hörnformat. I sin enklaste form är hörnformatet inget annat än ett antal flaggor som talar om vilka komponenter som ingår i ett hörn. Vilket hörnformat som används kan ändras under körning. Vanligt förekommande är ett hörnformat som innehåller just de komponenter som gavs som exempel ovan: position, färg, normalvektor samt texturkoordinater (figur 30). Hörn Position Normalvektor Färg Texturkoordinater x-värde (flyttal, 4 byte) y-värde (flyttal, 4 byte) z-värde (flyttal, 4 byte) x-värde (flyttal, 4 byte) y-värde (flyttal, 4 byte) z-värde (flyttal, 4 byte) RGBA-värde (4 byte) u-värde (flyttal, 4 byte) v-värde (flyttal, 4 byte) Figur 30 Ett hörn kan delas upp i flera komponenter som i sin tur kan bestå av flera värden. 22

30 3 Allmän terrängrendering En hörnbuffert bör skapas i ett initieringsskede i antingen AGP-minnet eller videominnet, beroende på storlek och vissa andra parametrar. Det går förvisso att skapa hörnbuffertar i vanliga systemminnet, men då kan grafikhårdvaran bara läsa in dem med en hastighet som motsvarar en bråkdel av teoretiskt maximum. Anledningen till att hörnbuffertar bör skapas i ett initieringsskede är att skapandet är en relativt dyr operation och därför inte bör göras i programmets huvudslinga. För statiska data är detta inget problem, men för dynamiska data blir det lite svårare. Istället för att skapa en ny hörnbuffert rekommenderas därför att en gammal hörnbuffert återanvänds. För att ändra på hörnen i en hörnbuffert måste huvudprocessorn ha exklusiv tillgång till hörnbufferten och denna måste därför låsas. Detta är en dyr operation och därför är det effektivare att använda statiska data, där detta är möjligt, eftersom det då inte finns någon anledning att låsa en hörnbuffert efter att den en gång har fyllts med statiska data. Indexbuffert T 1 F Hörnbuffert Hörn A 1 3 B T 4 D E 1 Hörn B 2 4 T 2 2 Hörn C 3 5 T 2 T 3 3 Hörn D 2 6 T 1 A 4 Hörn E 3 7 T 3 C 5 Hörn F T Figur 31 Polygonobjektet till vänster i figuren kan representeras av en hörnbuffert och en indexbuffert Indexbuffert En indexbuffert är kort sagt en vektor med sekventiellt lagrade 16- eller 32-bitars heltal. Heltalen är tänkta att användas som index till en hörnbuffert. Grafikhårdvaran hämtar och behandlar då hörnen efter den ordning som indexen i indexbufferten indikerar. På så sätt behöver inte ett hörn som delas av två trianglar lagras två gånger i hörnbufferten, utan samma hörn kan istället pekas ut två gånger av indexbufferten (figur 31). Det finns fler prestandarelaterade fördelar med att använda indexbuffertar och dessa tas upp i avsnitt

31 3 Allmän terrängrendering Effektiv parallellism Grafikhårdvarans komplexitet har nått en nivå där huvudkomponenten med rätta kan kallas för en grafikprocessor. Detta innebär att grafikprocessorn kan ses som en coprocessor till huvudprocessorn och tillsammans utgör de båda processorerna ett slags parallellt system (Cebenoyan och Wloka, 2002). För att maximera effektiviteten i parallellismen bör de båda processorerna arbetar samtidigt så mycket som möjligt. Med andra ord bör överlappningen av den tid där huvudprocessorn arbetar och den tid där grafikprocessorn arbetar vara så stor som möjligt. I vissa tillämpningar delar huvudprocessorn och grafikprocessorn vissa resurser och när den ena processorn använder en viss delad resurs måste den andra processorn vänta på sin tur att få tillgång till resursen. För att skaffa exklusiv tillgång till resursen måste processorn låsa den och sedan låsa upp den efter användning. Ju fler och mer långvariga låsningar programmet använder, desto större är sannolikheten att den andra processorn måste vänta på sin tur. Av den anledningen bör delade resurser undvikas så mycket som möjligt och låsningar bör vara så få och tidsmässigt korta som möjligt för att öka processortidsöverlappningen. Exempel på delade resurser som kan låsas av huvudprocessorn är texturer, bildbufferten, indexbuffertar och hörnbuffertar. Detta är ytterligare en anledning att undvika dynamiska hörnbuffertar i den mån det är möjligt. Låsningsoperationen i sig brukar dessutom vara en dyr operation. När ett program vill rendera ett antal trianglar i en hörnbuffert anropar programmet en renderingsfunktion som lägger en referens till hörnbufferten sist i en sorts intern renderingskö. Sedan fortsätter processorn köra programmet medan grafikprocessorn arbetar av renderingskön och renderar de trianglar som anges av referenserna i kön. För att få så bra parallellism som möjligt bör huvudprocessorarbetet för varje bildruta göras först och sedan bör själva renderingsanropen göras. På det viset kommer grafikprocessorn förhoppningsvis ha tillräckligt mycket arbete att göra för att den också ska överlappa huvudprocessorarbetet för nästa bildruta. Detta innebär att båda processorerna skulle arbeta samtidigt i hög grad (Huddy, 2002) Grafikprocessorns minnescache Precis som huvudprocessorn använder sig grafikprocessorn av en minnescache där senast lästa data hamnar, så att samma data snabbt kan återanvändas vid behov (Huddy, årtal okänt). När det inte finns ledigt utrymme kvar ersätter senast inlästa data tidigare inlästa data. Storleken på de minnesblock som läses in i cachen är i dagsläget oftast 32 byte och därför är ett hörnformat som är 32 byte stort (eller mindre) att föredra. Om hörnformatet inte har en storlek som är en multipel av 32 byte bör hörnen i hörnbufferten läsas in sekventiellt, eftersom de extra byte som fyller ut det sista minnesblocket för ett visst hörn då innehåller data som tillhör nästa hörn. När nästa hörn ska läsas in sekventiellt finns då redan en del av hörnet i förra hörnets minnesblock i cachen. Detta gäller således inte om hörnen läses i en mer utspridd ordning då sannolikheten för att de extra byte som ligger efter hörndata i minnesblocken är irrelevanta för övriga hörninläsningar är betydligt högre. I sådant fall skulle cachens effektivitet minska. 24

32 3 Allmän terrängrendering Grafikprocessorns hörncache Grafikprocessorn har förutom minnescachen även en hörncache. Där lagras hörn som är färdigbehandlade av grafikprocessorn (Huddy, årtal okänt). Vanligt för dagens hårdvara är att mellan tio och arton platser finns i hörncachen. I övrigt fungerar cachen som en FIFO-kö (First In, First out) där varje nytt hörn ersätter det hörn som har legat i cachen längst. Med andra ord ligger varje hörn i en tioplatsers hörncache kvar tills tio andra hörn har behandlats. Det är ovanligt att ersättningsmetoden FIFO används i en cache, men metoden har visats vara effektiv för en hörncache (Huddy, årtal okänt). Den fördel som hörncachen ger är att om den triangel som ska renderas har ett (eller flera) hörn som redan finns i hörncachen behöver hörnet inte hämtas från AGPminnet igen. Hörnet behöver inte heller transformeras eller behandlas av ett hörnprogram eftersom detta redan är gjort. En viktig förutsättning för att hörncachen överhuvudtaget ska fungera är dock att en indexeringsbuffert används, annars vet inte hörncachen vilket hörn som är vilket. Uppenbarligen måste index fortfarande läsas in från AGP-minnet, men ett index är oftast bara två byte stort och är därför en mycket mindre belastning för AGP-bussen Grafikhårdvarans minnesbandbredd Något som ofta utgör en flaskhals i systemet är överföringen av data mellan grafikprocessorn och videominnet där bland annat texturerna ligger (NVIDIA Corporation, 2002(a)). Ju fler pixlar som ritas ut, desto mer data måste överföras och den så kallade fyllhastigheten, som mäts i pixlar per sekund, beror till stor del på minnesbandbredden. Av den anledningen tar det längre tid att rita ut en större triangel än en liten triangel. Dessutom gäller att ju högre upplösning som används, desto fler pixlar måste ritas ut. Detta innebär att om en högre upplösning används kan färre trianglar ritas ut på lika lång tid som när en lägre upplösning används Effektiv användning av hörnbuffertar För att hörnbuffertar ska användas effektivt har de ledande tillverkarna av grafikhårdvara på konsumentnivå dragit upp ett antal riktlinjer. Här följer några rekommendationer som är relevanta vid terrängrendering: Generellt bör hörnformatet vara litet och kompakt, men i övrigt kan en hörnstorlek som är en multipel av 32 byte vara gynnsam då existerande hårdvara oftast hanterar sådana hörn snabbare (Huddy, 2002). Att byta aktiv hörnbuffert är en dyr operation och därför är det en bra idé att lagra hörnen från flera objekt i samma hörnbuffert och sedan särskilja dem med indexbuffertar (Dietrich, årtal okänt). Rendering av trianglar är i nuläget effektivast om åtminstone runt 200 trianglar ritas ut på en gång (Huddy, 2002). 25

33 3 Allmän terrängrendering Själva renderingsanropet är en dyr operation och detta är ytterligare än anledning till att fler trianglar bör ritas ut samtidigt (Huddy, 2002) Effektiv användning av hörnindexering Grafikhårdvaran stöder oftast tre olika sätt att översätta de hörn som läses in till trianglar. Renderingsfunktionen brukar ta en parameter som indikerar hur trianguleringen ska utföras. De tre olika metoderna har olika användningsområden och har olika grader av effektivitet. Den mest uppenbara metoden är att ordna hörnen i en triangellista, som kan ses som en lista av separata trianglar (figur 32). Detta betyder att för varje triangel som renderas läses tre hörn in av grafikhårdvaran. Nästa tre inlästa hörn utgör nästa triangel och sedan fortsätter det på samma sätt Figur 32 Hörnen i en triangellista representerar ett antal separata trianglar. Siffrorna betecknar hörnens index i triangellistan Figur 33 Trianglarna i triangelsolfjädern delar det första hörnet. En annan metod är att ordna hörnen i en s.k. triangelsolfjäder. Namnet kommer från utseendet på de objekt som kan renderas på triangelsolfjäderssättet (figur 33). Det första hörnet som läses in blir startpunkt för solfjädern och alla efterföljande trianglar har detta hörn som ett av sina hörn. Hörn nummer två i ordningen blir det andra hörnet i den första triangeln och det tredje hörnet fullbordar första triangeln. Alla efterföljande hörn resulterar därefter i en ny triangel mellan det aktuella hörnet, direkt föregående hörn i ordningen samt det första hörnet i solfjädern. Det tredje sättet är att ordna hörnen i en s.k. triangelremsa. Liksom i fallet med triangelsolfjädern är triangelremsan en sammanhängande följd av trianglar (figur 34). Skillnaden är att det inte finns ett gemensamt hörn som delas av alla trianglar. I en triangelremsa bildas dock fortfarande en ny triangel för varje nytt 26

34 3 Allmän terrängrendering hörn som läses in utom de två första hörnen. Varje triangel består av det senast lästa hörnet samt de två direkt föregående hörnen i ordningen Figur 34 Varje triangel i en triangelremsa utom den första delar två hörn med föregående triangel i remsan. Om enbart en hörnbuffert används vid renderingen bestämmer ordningen i hörnbufferten i vilken ordning hörnen läses in av grafikhårdvaran. När en indexbuffert används bestäms ordningen av indexvärdena, som läses in i den ordning de är lagrade i indexbufferten. Enligt hårdvarutillverkarnas riktlinjer är indexering att föredra, delvis på grund av att hörncachen inte kan utnyttjas annars. Allra bäst är att använda långa indexerade triangelremsor om detta är möjligt. Om inte, rekommenderas att indexerade triangellistor används. Triangelsolfjädrar har flera nackdelar när det gäller hårdvaruprestanda. Eftersom enbart en triangelsolfjäder kan renderas per renderingsanrop, blir triangelsolfjädrar aldrig speciellt långa då få objekt har trianglar som är organiserade på lämpligt vis. Som nämndes ovan bör minst 200 trianglar renderas per renderingsansrop för att effektiviteten ska vara hög. På grund av detta används triangelsolfjädrar sällan. Ofta kan objekt representeras av flera långa triangelremsor och då dessa blir tillräckligt långa är de särskilt effektiva att rendera, förutsatt att indexering används. Detta beror på att endast 2 + n hörn behöver läsas in från AGP-minnet (och transformeras) vid rendering av n trianglar, eftersom varje hörn bildar en triangel med de två direkt föregående hörnen, som då redan ligger i hörncachen. Om indexering inte används måste varje hörn i varje triangel läsas in och då behöver 3 n hörn läsas in. Om triangelremsorna blir korta eller om det inte ens är möjligt att representera ett objekt som triangelremsor är det dock bättre att använda indexerade triangellistor (Rogers, 1999), eftersom det, som tidigare nämnts, är viktigt att många trianglar renderas per renderingsanrop. När indexerade triangellistor används måste i värsta fall 3 n hörn läsas in från AGP-minnet (och transformeras) för att rendera n trianglar. Om trianglarna däremot organiseras så att tidigare hörn ofta återanvänds innan de hinner bli ersatta i hörncachen kan högre effektivitet uppnås. 27

35 3 Allmän terrängrendering Effektiv användning av tillståndsändringar Enligt hårdvarutillverkarnas riktlinjer bör utvecklaren vara försiktig med hur denne hanterar tillståndsändringar i renderingsslingan. Med tillståndsändringar menas till exempel byte av aktiv textur, byte av hörnprogram, byte av hörnbuffert, byte av indexbuffert, aktivering av djupbuffert och andra liknande ändringar. Med andra ord alla ändringar som på något sätt ändrar 3d-grafikhårdvarans totala tillstånd på något vis. Tillståndsändringar är dyra operationer eftersom pipelinen inte kan påbörja behandling av några nya hörn förrän tillståndsändringen är klar. Tillståndsändringar bör därför minimeras. Dock är det inte det totala antalet tillståndsändringar i renderingsslingan som ska minimeras, utan antalet tillfällen där en eller flera tillståndsändringar sker (Huddy, 2002). Alltså bör tillståndsändringarna samlas i grupper som utförs utan att renderingsanrop sker mellan tillståndsändringarna. På samma sätt som det är effektivare att rendera ett flertal trianglar på en gång är det effektivare att göra flera tillståndsbyten på en gång. Ett sätt att uppnå en effektivare gruppering är att sortera de trianglar som ska renderas efter vilket tillstånd hårdvaran måste vara i när de renderas. Då är grupperingen av tillståndsändringarna lättare att göra. 3.4 Målsättning När jag valde en metod att implementera i prototyptillämpningen hade jag satt upp ett flertal mål. Ett övergripande mål var att metoden skulle vara lämplig för användning på konsumenthårdvara. Konkreta exempel på sådan hårdvara är Microsofts tv-spelskonsol Xbox, NVIDIAs grafikkretsar i GeForce-serien och ATIs grafikkretsar i Radeon-serien. De flesta terrängrenderingsmetoder som tidigare har utvecklats har inte tagit hänsyn till konsumenthårdvarans speciella förutsättningar, som beskrevs ovan. Dock har mitt mål inte varit att hitta den optimala terrängrenderingsmetoden, utan att hitta en eller flera lämpliga metoder för integration av terrängrendering i en interaktiv tillämpning där terrängen är en av flera komponenter. Med andra ord var jag inte intresserad av att hitta en terrängrenderingsmetod som tar för mycket resurser i anspråk och därmed inte kan samexistera med andra komponenter och renderingsprocesser. En mycket viktig resurs är huvudprocessorn. I flera terrängrenderingsmetoder används huvudprocessorn i stor utsträckning. Detta gör att tillämpningar som exempelvis simulerar fysiska egenskaper i 3d-världen i realtid inte kan tilldela fysikrutinerna mycket processortid. Som nämndes ovan uppnås maximal effektivitet i parallellismen om både huvudprocessorn och grafikprocessorn konstant har något att göra. Att då använda huvudprocessorn till att göra en stor del av arbetet i terrängrenderingsprocessen är en felfördelning av resurser. Dessutom ökar grafikhårdvarans prestanda för närvarande i en högre takt än processorns, vilket gör att metoder som behandlar enskilda trianglar med hjälp av huvudprocessorn i stor omfattning kommer få svårt att hålla igång grafikprocessorn samtidigt i framtiden. Av dessa anledningar hade jag som ett mål att välja en metod som frikopplar processorn från renderingsprocessen i hög grad. Ett annat mål var att metoden skulle vara skalbar. Både i den meningen att olika terrängstorlekar skulle kunna renderas av metoden samt att metodens prestandanivå 28

36 3 Allmän terrängrendering skulle växa i takt med grafikhårdvarans utveckling. Med andra ord var mitt mål att metoden skulle kunna ha en praktisk användning även i framtida tillämpningar. Flexibilitet och generalitet är två ledord i mjukvaruutveckling. Så också i detta fall, där många metoder dock är specialiserade i hög grad. Ett av mina mål var att hitta en metod som lätt kan utökas med ny funktionalitet när exempelvis ny hårdvara släpps eller tidigare oförutsedda tekniker blir tillgängliga. Om metoden samtidigt är generell nog att kunna behandla renderingsproblem som inte enbart rör terräng är detta givetvis en fördel. Jag hade även målsättningen att terrängrenderingsmetodens visuella kvalitet skulle nå upp till en nivå i klass med existerande implementationer. Då utseendet hos terrängen till vissa delar har rent artistiska aspekter avses här endast den tekniska visuella kvaliteten, som enbart innefattar sådana faktorer som val av metod direkt kan påverka. Slutligen var målet för själva implementationen av metoden att den skulle klara av att upprätthålla en acceptabel genomsnittlig bilduppdateringshastighet i en relativt hög upplösning ( pixlar) för rendering av ett typiskt höjdfält. Allmänt ses en uppdateringsfrekvens på 30 fps (bilder per sekund) som en acceptabel nivå (NVIDIA Corporation, 2002(b)), men jag satte gränsen vid 60 fps vid körning på prototyputvecklingsmaskinen. Ytterligare ett mål var att metoden inte skulle vara alltför komplicerad att implementera, då en enklare metod oftast är enklare att implementera effektivt. Vidare bör nämnas att metoderna utvärderades med förutsättningen att höjdfältets mätpunkter inte skulle kunna ändras under körning. Med andra ord tog jag ingen hänsyn till hur väl metoderna hanterar dynamisk terräng. Däremot finns för varje metod några ord om dynamisk terräng i avsnitt 3.5. För att sammanfatta målen som jag även använde som metodvalskriterier följer nedan en lista med önskvärda egenskaper hos metoden: Metoden bör vara lämplig för anpassning till grafikhårdvarans förutsättningar. Metoden bör frikoppla huvudprocessorn i hög grad. Metoden bör vara skalbar. Metoden bör vara flexibel och generell. Metoden bör ha en konkurrensmässig teknisk visuell kvalitet. Metoden bör inte vara för komplicerad att implementera. Implementationen bör kunna upprätthålla en bildhastighet på 60 fps. 3.5 Jämförelse av metoder Lindstroms kontinuerliga LOD-metod Lindstroms metod använder sig av kontinuerlig LOD och är därför på många sätt beroende av huvudprocessorn. De förenklingsberäkningar som metoden gör blir ganska processorintensiva i och med att många tester måste göras. Förenklingsvillkoret beror på ett värde som måste projiceras till skärmrummet för varje test och 29

37 3 Allmän terrängrendering detta kräver ett antal matrismultiplikationer och kvadratrotsberäkningar. Detta är processorintensiva operationer och processorn blir därmed inte frikopplad i någon högre grad. Dessutom måste T-korsningar elimineras rekursivt efter förenklingen. Även själva renderingen är processorintensiv eftersom varje triangel som ska renderas måste behandlas och kopieras till en dynamisk hörnbuffert. Metoden konstruerar rekursivt triangelremsor vid renderingen utgående från den triangulering förenklingsprocessen utfört. Dock krävs att en operation som kallas hörnbyte måste kunna utföras i hörnbufferten för att långa triangelremsor ska kunna konstrueras. Operationen går ut på att de två senast använda hörnen byter plats efter användning innan de bildar en triangel med nästa hörn och följer därmed inte ovanstående beskrivning för hur en triangelremsa fungerar. Konsumenthårdvara har inte stöd för hörnbytesoperationen och därför kan enbart kortare triangelremsor bildas med metoden. Det är effektivare att rendera långa triangellistor än flera korta triangelremsor och därför bör inte triangelremsor användas med metoden. Metoden kan av ovan nämnda skäl inte ses som särkilt skalbar jämfört med en metod som avlastar processorn mer. Inte heller är den visuella kvaliteten speciellt hög då hörninterpolation inte stöds av metoden så som den är beskriven. Detta gör att plötsliga märkbara förändringar syns på skärmen när trianguleringen ändras. I övrigt är metoden inte speciellt svår att implementera, men den måste utökas med en metod för att hantera dynamiska hörnbuffertar på konsumenthårdvara. För dynamisk terräng behöver metoden inte modifieras, eftersom höjdfältets mätpunkter ändå måste undersökas och kopieras till en hörnbuffert i varje bildruta. På grund av denna egenskap är det tänkbart att Lindstroms metod blir mer intressant om dynamisk terräng med frekventa ändringar av höjdfältet ska användas ROAM-metoden Även metoden ROAM är i hög grad beroende av processorn. Metodens test av förenklingsvillkor måste med hjälp av matrismultiplikationer projicera den geometriska avvikelsen till skärmrummet. Hanteringen av de båda prioritetsköerna som metoden använder vid trianguleringen belastar även den huvudprocessorn. Metoden bygger på idén om bildkoherens, vilket innebär att metoden bibehåller en triangulering där trianglar läggs till eller tas bort istället för att hela höjdfältet trianguleras om från början för varje bildruta. För att metoden ska vara som mest effektiv får betraktarens position och vyriktning inte ändras mycket på ett litet tidsintervall. I många tillämpningar som till exempel spel och fordonssimulatorer kan både betraktarens position och vyriktning ändras hastigt. Av den anledningen är det svårt att säga om bildkoherens ger någon fördel för den typen av program. Till skillnad från de kvadträdsbaserade metoderna lagras trianguleringen i en trädstruktur med pekare som kopplar ihop noderna i trädet. Om en sådan trädstruktur inte implementeras på ett effektivt sätt minskar processorcachens effektivitet, då trädets noder lätt kan bli utspridda i minnet. Cachen är som effektivast när data som används frekvent ligger inom ett litet minnesområde där en given läsning i minnet sker i närheten av tidsmässigt närliggande läsningar. 30

38 3 Allmän terrängrendering Metodens bildkoherens sparar in en del processorarbete, men då hörnbuffertar inte kan manipuleras lika lätt som en trädstruktur måste ändå hela trianguleringen gås igenom i varje bildruta och varje triangel måste kopieras till en dynamisk hörnbuffert. Dessutom måste den hörninterpolation som metoden stöder skötas av processorn, vilket innebär att ett stort antal interpolationer måste göras. Ibland måste triangeldelningar tvingas fram för att undvika T-korsningar. Detta kan rekursivt orsaka att fler delningar behövs på andra ställen och i värsta fall ger detta upphov till en lavinartad effekt som belastar huvudprocessorn ytterligare. På grund av denna och ovanstående anledningar kan metoden inte ses som särskilt processoravlastande och därmed inte heller skalbar. En annan fundamental idé hos metoden är att när den tid som avsatts för att rendera en viss bildruta tar slut kan trianguleringsprocessen avbrytas. Då själva renderingen av trianglarna utförs av grafikprocessorn är det svårt att använda sådana tidsbaserade villkor, eftersom det är omöjligt eller åtminstone tidskrävande att få tag på uppgifter om huruvida grafikprocessorn är upptagen eller inte. När renderingen av trianglarna ska utföras efter trianguleringen kan grafikprocessorn ha en godtyckligt lång renderingskö att behandla. Av den anledningen förloras en del av den precision som metoden hade behövt för att dynamiskt kunna anpassa trianguleringsprocessen till bildhastigheten. Fördelen med metoden är att den visuella kvaliteten är mycket bra. Trianguleringen avviker inte mycket från den högsta detaljnivån och hörninterpolationen gör att betraktaren inte behöver besväras av att stora abrupta förändringar sker i terrängen på skärmen. Metoden är ganska flexibel, speciellt då förenklingsvillkoret kan bytas ut mot ett godtyckligt eget villkor. Dessutom är ROAM ganska generell då det är möjligt att den övergripande principen kan användas till annat än terräng. Däremot är implementation inte helt enkel. Träd- och köhanteringsfunktioner måste implementeras effektivt och metoden måste utökas med hantering av dynamiska hörnbuffertar för att kunna användas på konsumenthårdvara. För dynamisk terräng tycks ROAM inte vara en lämplig metod. Metodens effektivitet beror till stor del på bildkoherens och störst bildkoherens uppnås när terrängen eller vypunkten inte ändras speciellt mycket. Stora ändringar av terrängen skulle resultera i många delningar och hopsättningar av trianglar. Processorn skulle därmed bli ännu mer belastad än tidigare Röttgers kontinuerliga LOD-metod Av de olika metoderna som använder sig av kontinuerlig LOD är Röttgers metod den som tycks vara mest processoravlastande. Det faktum att metoden förenklar uppifrån och ner, till skillnad från Lindstroms metod som förenklar nedifrån och upp, innebär att metoden inte behöver behandla lika många trianglar, men fortfarande behandlas en stor del av dem. Förenklingsvillkorstestet är även det effektivare än i både ROAM-metoden och Lindstroms metod, till stor del beroende på att förberäknade värden kan användas vid testet. Vid rendering måste varje triangel som ska renderas dock fortfarande kopieras av huvudprocessorn till en 31

39 3 Allmän terrängrendering dynamisk hörnbuffert. Hörninterpolation är enkelt att använda med metoden, men huvudprocessorn måste då utföra ett stort antal interpolationer. I slutändan frikopplar inte heller Röttgers metod huvudprocessorn i hög grad. Själva renderingsprocessen utgår från att triangelsolfjädrar är effektiva och konstruerar därför sådana vid renderingen. Då triangelsolfjädrarna inte innehåller särskilt många trianglar är detta ytterst ineffektivt på konsumenthårdvara. Metoden är heller inte speciellt flexibel eller generell. Den är i stor utsträckning specialiserad för terräng. Den visuella kvaliteten är däremot bra, vilket kan förväntas sig av en metod som använder kontinuerlig LOD i kombination med hörninterpolation. Röttgers metod är förhållandevis enkel att implementera, men den skalar dåligt på grund av triangelsolfjädrarna och utnyttjandegraden av huvudprocessorn. Metoden är dock den metod som passar bäst för användning på konsumenthårdvara av de metoder som bygger på kontinuerlig LOD. För rendering av dynamisk terräng behöver metoden inte modifieras speciellt mycket. En fördel med Röttgers metod är som tidigare nämnts att förenklingsfaktorn kan förberäknas för alla punkter i höjdfältet. Om höjdfältet ändras dynamiskt måste även de förberäknade värdena uppdateras. Detta gör metoden betydligt mer processorberoende om många höjdmätningsändringar sker Diskret LOD med hjälp av kvadträd En konceptuellt enklare metod är att använda diskret LOD i kombination med en kvadträdsorganisation. Rent praktiskt innebär detta att höjdfältet delas upp i ett kvadträd av ett visst djup och varje löv i trädet representerar ett rektangulärt område i höjdfältet enligt beskrivningen av kvadträd ovan. Trädets djup och omfattningen av de områden löven representerar kan varieras beroende på tillämpningen. Genom att införa ett antal detaljnivåer, med tillhörande trianguleringar, för varje löv införs diskret LOD i metoden. Trianglarna i varje område kan lagras i en statisk hörnbuffert och när trädet renderas behöver metoden enbart traversera kvadträdet och med hierarkisk vyvolymsgallring ta reda på vilka löv som överlappar vyvolymen och därmed är synliga för betraktaren. Till sist renderar metoden blockvis trianglarna som tillhör de synliga löven. För att bestämma vilken detaljnivå varje löv ska renderas på behövs ett detaljnivåvillkor. Till exempel kan lövets avstånd till betraktaren användas som villkor. Huvudprocessorn blir frikopplad i högre grad än för de ovan beskrivna metoderna, eftersom enskilda trianglar inte behandlas av huvudprocessorn. Det enda processorn behöver göra är att traversera kvadträdet och utföra den hierarkiska vyvolymsgallringen. Detta arbete måste utföras även för ovanstående metoder som också använder sig av kvadträd. Skillnaden är att ingen triangulering görs av metoden, eftersom fördefinierade trianguleringar för olika detaljnivåer finns att tillgå. Processorn behöver enbart testa detaljnivåvillkoret för varje löv och välja en detaljnivå. När detaljnivån är vald är det bara för processorn att lägga en referens 32

40 3 Allmän terrängrendering till lövets trianglar i renderingskön. Eftersom trianglarna renderas som stora block blir effektiviteten högre än om ett fåtal trianglar i taget skulle renderas. Inte heller behöver trianglarna kopieras av huvudprocessorn till en dynamisk hörnbuffert för varje bildruta eftersom en statisk hörnbuffert kan användas. Det är ganska uppenbart att metoden dessutom är mer skalbar än de ovan beskrivna metoderna. Om fler trianglar ska ritas ut kan fler hörn och trianguleringar av högre detaljnivå enkelt tillföras kvadträdslöven. På grund av den höga graden av frikoppling från processorn skalas metoden automatiskt om grafikhårdvaran och/eller AGP-bussen uppgraderas till snabbare versioner. De två grundläggande teknikerna som ligger till grund för metoden, nämligen diskret LOD och kvadträd, är i sig två generella metoder utan en direkt koppling till terrängrendering. Detta gör att metoden också är en relativt generell modell. Varken kvadträdet eller LOD-nivåerna förutsätter att ett visst format används för de trianglar som lagras och renderas. Till exempel skulle en stadsmiljö kunna representeras av metoden. Generaliteten i sig medför en viss flexibilitet och det är relativt enkelt att lägga till ny funktionalitet. Metoden är (åtminstone konceptuellt) enkel att implementera, på grund av att de två underliggande teknikerna i sig är relativt enkla att implementera. Den eventuella svårigheten ligger i detaljer som att bestämma djupet och storleken av det område som ett löv ska representera. Det vore relativt enkelt att använda dynamisk terräng med metoden. Det enda som behövs är att motsvarande hörn i hörnbufferten ändras när terrängens höjdfältsmätningar ändras. Som tidigare nämnts är det en dyr operation att låsa en hörnbuffert, men om små ändringar görs av terrängen med låg frekvens är detta troligtvis en överkomlig kostnad. Dessutom skulle huvudprocessorn fortfarande vara frikopplad i hög grad, då enbart enkla kopieringsoperationer skulle behövas för själva ändringen av hörnens höjdvärde. 3.6 Resultat av metodjämförelsen Diskret LOD i kombination med kvadträd framstår tydligt som den metod som bäst når upp till de mål jag satte ovan. De frågor som kvarstår är huruvida hörninterpolation kan användas med metoden utan att huvudprocessorn måste utföra en mängd interpolationer. I övrigt når kanske den visuella kvaliteten inte upp till samma nivå som för metoder som använder sig av kontinuerlig LOD, men skillnaden borde knappt bli märkbar om väl utförda trianguleringar för de olika detaljnivåerna används. När betraktaren rör sig genom terrängen ändras trianguleringen på skärmen inom ett lövområde enbart när det är dags att byta detaljnivå. För metoder som använder kontinuerlig LOD ändras ständigt trianguleringen och utseendet på skärmen kan i hög grad ändras från bildruta till bildruta på en individuell triangulär nivå. Med andra ord har båda angreppssätten nackdelar, men resultatet blir i båda fallen acceptabelt. Baserat på jämförelsen valde jag att implementera en metod som använder sig av diskret LOD i kombination med kvadträd. Jag resonerade så att om metoden kunde infria alla löften och verkligen kunde visa sig vara lämplig för användning på 33

41 3 Allmän terrängrendering konsumenthårdvara, skulle skalbarheten, generaliteten och den konceptuella enkelheten väga tyngre än de andra metodernas något utseendemässigt optimalare trianguleringar. 3.7 Min metod för terrängrendering Indata och triangulering Det första steget var att skapa ett höjdfält. Ett vanligt sätt att representera ett höjdfält är att lagra det i form av en gråskalebild, där varje bildpunkts färgvärde motsvarar höjden för en punkt i höjdfältet. Normalt används 256 gråskalor, där svart motsvaras av färgvärdet 0 och vitt motsvaras av färgvärdet 255. Varje bildpunkt kan då representeras som en byte. Jag valde att istället använda två byte för varje bildpunkt, vilket innebär att höjdnivåer kan representeras av en bildpunkt. På det sättet kan 256 gånger fler unika höjdnivåer representeras till en endast två gånger större lagringskostnad. Höjdfältets storlek beror på tillämpningens behov. Eftersom prototypens enda syfte var att vara en prototyp valde jag en storlek som jag ansåg vara en ganska typisk storlek för genomsnittstillämpningen på den grafikhårdvara jag hade tillgång till under utvecklingen. Huruvida så verkligen är fallet kan jag inte avgöra, men de terrängrenderingstillämpningar jag har sett tycks ha höjdfält av liknande dimensioner. Till exempel visade det sig vid en närmare studie att höjdfält med punkter används i spelet Battlefield 1942 från Digital Illusions CE. I konkreta siffror hade höjdfältet jag använde punkter, vilket innebär att höjdfältsrutor, eller trianglar, kan representeras vid en fullständig triangulering av höjdfältet. Anledningen till att jag valde att använda höjdfältsrutor är att grafikhårdvaran lättast hanterar texturer som har dimensioner som är potenser av 2. Därmed skulle en textur som har dimensionerna texlar ha en pixel per höjdfältsruta om texturen täcker hela höjdfältet. Textureringen beskrivs noggrannare i textureringsavsnittet. Det finns ett flertal olika sätt att generera ett höjdfält. Till exempel kan mätdata från existerande terräng användas. I många tillämpningar används dock virtuella mätdata, som har genererats syntetiskt i någon mening. Exempelvis kan en datorspelutvecklare vilja skapa en fiktiv spelvärld, som kräver en för ändamålet specialutformad terräng. Det finns ett flertal program för att underlätta manipulering av höjdfält, men mätvärdena kan även ritas ut i bilden manuellt med hjälp av ett vanligt bildbehandlingsprogram. Ofta blir terrängens utseende mer realistiskt när ett höjdfältsprogram används. Jag använde ändå den mer primitiva metoden att manuellt rita ut höjdvärdena, eftersom det var renderingsmetoden och inte metoder för skapandet av indata som jag skulle undersöka. Resultatet blev ett böljande landskap i form av en något fyrkantig ö. I figur 35 har höjdfältet skalats ned till en vanlig bild med 256 gråskalor för att kunna avbildas här. När testdata hade skapats började jag fundera på hur kvadträdsuppdelningen av höjdfältet skulle ske. Själva uppdelningen är i sig en enkel process, då den enbart går ut på att rekursivt dela upp höjdfältet i kvadranter. Svårigheten ligger i att bestämma ett lämpligt djup för kvadträdet och därmed även bestämma lövens storlek. Ju fler nivåer trädet har, desto färre höjdfältspunkter och trianglar innehåller 34

42 3 Allmän terrängrendering löven. I tabell 1 nedan visas egenskaper för löv av ett antal olika möjliga lövstorlekar i ett kvadträd som motsvarar ett höjdfält av den storlek jag valde. Figur 35 Höjdfältet representeras av en gråskalebild där de ljusare partierna representerar högre höjder än de mörka partierna. Tabell 1 Tabellen visar några olika lövstorlekar och träddjup. Lövstorlek (punkter x punkter) Träddjup (nivåer) Antal löv (löv) Trianglar per löv (trianglar) 1 x x x x x x x x Som tidigare nämnts bör åtminstone 200 trianglar ritas ut per renderingsanrop och då metoden ritar ut alla trianglar i ett löv på en gång bör varje löv innehålla minst 200 trianglar. Av den anledningen kan träddjup 7 och uppåt förkastas. När ett träddjup ska väljas bör hänsyn även tas till den hierarkiska vyvolymsgallringen. På grund av att metoden måste traversera ända ned till de synliga löven gäller, för en genomsnittlig bildruta, att ju fler nivåer trädet har, desto fler vyvolymstester måste göras av huvudprocessorn. Samtidigt gäller att ju större löven är, desto mindre är vyvolymstesternas precision. I många fall kan betydligt fler trianglar behöva ritas ut om större löv används. Valet av lövstorlek blir därför en avvägning mellan att belasta huvudprocessorn eller grafikhårdvaran. Vad som bör prioriteras beror på 35

43 3 Allmän terrängrendering tillämpningens egenskaper. Vyvolymsgallring kan implementeras ganska effektivt för lövens omslutande rätblock och tar därför inte så mycket processortid i anspråk. Figur 36 Kvadträdet till vänster har djupet 3 och kvadträdet till höger har djupet 4. De gråa löven överlappar vyvolymen, som i figuren representeras av en triangel. I (figur 36) visas två olika kvadträdsrepresentationer av ett höjdfält där kvadträdet till vänster har djupet 3 och kvadträdet till höger har djupet 4. Triangeln föreställer vyvolymen och de mörka löven är löv som överlappar vyvolymen och därför renderas. För det högra trädet renderas 25 löv och för det vänstra trädet renderas 11 löv. I det senare fallet innehåller dock varje löv fyra gånger fler trianglar och 11 löv motsvarar 44 löv i det förra fallet. Det djupare trädet ritar i det här fallet ut 43% färre trianglar och därmed belastas grafikhårdvaran mindre. Förvisso beror triangelkvoten på vyvolymens läge, men oavsett läge ritas alltid lika många eller fler trianglar ut om ett litet träddjup används. Jag valde att använda ett träddjup på 6 nivåer där löven innehåller punkter med motiveringen att terrängen bör kunna integreras med ett program som i övrigt också belastar grafikhårdvaran ganska mycket. Av den anledningen kan det vara bra att reducera antalet trianglar terrängen ritar ut i varje bildruta. Egentligen innehåller löven punkter för att lövet ska innehålla höjdfältsrutor. Punkterna som har lagts till delas dock med närliggande löv. Själva uppdelningsprocessen var relativt lätt att implementera i form av en rekursiv funktion. För att förhoppningsvis gynna huvudprocessorns cache lagrades alla trädets löv och noder i en enda sammanhängande vektor i minnet. Eftersom cachen läser in stora block av data från minnet på en gång lönar det sig om efterföljande läsningar sker i närheten av senaste läsningen. Huruvida det gav någon prestandahöjning är svårt att säga av flera anledningar, där den största anledningen är att jag inte hade tillgång till lämpliga verktyg för att studera cachebeteendet för mitt program. Nästa steg var att dela upp triangelhörnen i hörnbuffertar. Det finns gränser för hur stora hörnbuffertar kan vara och det kan vara en fördel om hela hörnbufferten kan indexeras med ett 16-bitars värde, vilket motsvarar hörn. Den största fördelen med att använda 16-bitars index är att grafikhårdvaran då bara behöver hämta 16-bitars värden över AGP-bussen när indexering används, till skillnad från när 32-bitars index används. Höjdfältet jag använde har hörn och jag valde att dela upp punkterna i åtta hörnbuffertar. Jag organiserade hörnbufferten så 36

44 3 Allmän terrängrendering att varje lövs hörn lagrades sammanhängande efter varandra. Detta gjorde att de hörn som delades av två löv dubblerades, vilket inte är effektivaste sättet. Rent organisationsmässigt var det enklare på det sättet och fick duga för prototypen. I varje hörnbuffert lagrades hörnen från 128 av totalt löv. Det totala antalet hörn i en enskild hörnbuffert blev då hörn. Uppdelningen av höjdfältet i hörnbuffertar utfördes så att löven i stor grad tilldelades samma hörnbuffert som närliggande löv enligt figur Figur 37 Höjdfältet delades upp i 8 delar där varje del tilldelades en hörnbuffert. Efter att hörnbuffertarna hade skapats var det dags att ta itu med själva trianguleringen för löven. Till att börja med bestämde jag mig för att använda tre LOD-nivåer och för enkelhetens skull valde jag att halvera antalet hörn i varje LOD-nivå. Den första nivån innefattade alla hörnen i lövet och den andra nivån hoppade över vartannat hörn och så vidare (figur 38). Med en sådan triangulering uppstår tyvärr T-korsningar när olika LOD-nivåer möts i angränsande löv och jag löste problemet genom att låta kanterna hos första och tredje LOD-nivån anpassa sig efter andra LOD-nivån (figur 39). På detta sätt uppstår inga sprickor mellan löv som har olika LOD-nivåer. Figur 38 Bilden visar möjliga trianguleringar för de tre olika LOD-nivåerna. Figur 39 Trianguleringarna har samma punktantal i kanterna och kan användas bredvid varandra utan att sprickor uppstår. 37

45 3 Allmän terrängrendering Eftersom jag triangulerade alla löv på samma sätt räckte det med endast tre indexbuffertar för alla löven, där varje LOD-nivå representerades av en indexbuffert. Jag lyckades inte skapa en enda lång triangelremsa av trianguleringen och fick därför använda triangellistor. Den triangulering jag valde är på inga sätt optimal och borde kanske mer anpassas till de olika lövens individuella geometriska egenskaper. En möjlig förbättring vore att konstruera en algoritm som gör bättre trianguleringar. Med den triangulering jag valde utnyttjas inte heller grafikhårdvaran optimalt då färre än 200 trianglar ritas ut när andra och tredje LOD-nivåerna används. Tanken var att med den stora mängd trianglar som ritas ut går det ändå snabbare att rita ut färre trianglar även om inte hårdvaran utnyttjas maximalt. Däremot skapade jag hörnindexeringen av trianguleringen så att angränsande trianglar lagrades nära varandra i indexbufferten för att hörncachen skulle kunna utnyttjas i hög grad. Dessutom organiserades hörnen i hörnbufferten så att läsningar av hörn från närliggande trianglar skulle ske på ett sådant sätt att hörnen läses in av hårdvaran i en nästan sekventiell ordning för att även grafikprocessorns minnescache skulle utnyttjas i hög grad Rendering av terrängen Själva renderingsprocessen var relativt enkel att implementera efter att organisationen av hörnpunkterna och trianglarna var avklarad. För varje nod i kvadträdet beräknade programmet vid trädkonstruktionen dimensionerna för ett rätblock som omslöt barnnoderna i trädet. Vid renderingen traverserar renderingsprocessen trädet rekursivt och testar för varje nod om dess omslutande rätblock överlappar vyvolymen. Om så är fallet fortsätter traverseringen nedåt i trädet, men om ingen överlappning finns fortsätter inte traverseringen med barnnoderna. När ett löv träffas på som överlappar vyvolymen betyder det att lövet är synligt och ska ritas ut. Den första versionen av renderingsfunktionen ritade ut lövets trianglar direkt, men i ett försök att öka parallellismen används i den andra (och senaste) versionen en renderingskö, där programmet stoppar synliga löv. Det enda som skiljer de två olika versionerna åt är i vilken ordning operationerna utförs. När trädet har traverserats klart går programmet igenom renderingskön och renderar alla löven. På det sättet sker inga tyngre operationer på huvudprocessorn mellan varje renderingsanrop och sannolikheten för att huvudprocessorn och grafikprocessorn arbetar samtidigt ökar. Det är dock svårt att säga hur stor skillnaden blir då processorn i övrigt inte utförde speciellt krävande operationer, som till exempel fysiksimulationer, i mitt program. Valet av LOD-nivå för varje löv baseras på avståndet från betraktaren till lövets mittpunkt och behöver därför inte beräknas med matrismultiplikationer, som i de tidigare presenterade metoderna. Detta avlastar processorn ytterligare. Möjligtvis kan resultatet bli en aning visuellt mindre avvikande från den högsta detaljnivån med ett förenklingsvillkor som projicerar den geometriska avvikelsen i skärmrummet, men på bekostnad av bilduppdateringshastigheten. I värsta fall måste renderingsprocessen byta aktiv hörnbuffert ganska ofta när det senaste lövet tillhör en annan hörnbuffert än nästa löv som ska renderas i listan. I ett försök att ytterligare effektivisera renderingsprocessen testades olika sorteringar av 38

46 3 Allmän terrängrendering renderingskön innan renderingen. Först sorterades löven efter deras tilldelade hörnbuffertar för att minska antalet byten av den aktiva hörnbufferten vid renderingen. Sedan sorterades renderingskön efter avståndet från lövets mittpunkt till betraktaren för att löven skulle renderas framifrån och bakåt och på så vis hjälpa djupbufferttesterna att förkasta pixlar tidigt. Här är det viktigt att notera att det är själva löven som sorteras och inte individuella trianglar i löven. Med andra ord sker sorteringen för trianglarna blockvis och processen kan därför inte användas som ett alternativ till djupbuffring. En sortering av individuella trianglar skulle för övrigt kräva för mycket processortid för att en sådan metod skulle vara intressant. Tyvärr blev det ingen märkbar skillnad i renderingshastighet när sorteringarna användes vilket tyder på att flaskhalsen i systemet inte låg i denna del av renderingsprocessen. Troligtvis är tillståndsändringarna relativt få redan från början för den metod som används i programmet. Efter att ha provkört en tidig version av prototypen insåg jag att LOD utan hörninterpolation är visuellt oacceptabelt då byten av detaljnivå resulterade i störande plötsliga geometriska avvikelser. Av den anledningen utarbetade jag en metod för att använda hörninterpolation med diskret LOD. Metoden är baserad på hörnprogram, eftersom interpolationsberäkningen då kan utföras av grafikprocessorn och utan att hörndata i hörnbufferten behöver ändras. När hörnprogram används går renderingsprocessen långsammare än om en fixfunktionspipeline används, men den extra funktionaliteten väger upp nackdelarna. Dessutom har grafikhårdvaruföretagen snabbat upp hörnprogrammen ordentligt i de senare versionerna av grafikprocessorerna. Innan förklaringen av hur hörninterpolationen fungerar behöver det hörnformat jag valde förklaras. Jag hade som mål att ha ett hörnformat på antingen 24 eller 32 byte, eftersom dessa hörnstorlekar är effektivast. Till att börja med behövdes tre flyttal på fyra byte vardera för att specificera x-, y- och z-position för hörnet. Då hade tolv byte förbrukats. I textureringsavsnittet framgår att prototypen använder sig av tre texturer på en gång med texturkoordinater som faktiskt är multipler av varandra. Av den anledningen kunde jag, genom att i hörnprogrammet multiplicera en uppsättning texturkoordinater med två konstanter för de andra två texturerna, spara in på texturkoordinatdata i hörnen och enbart ange texturkoordinater för den stora heltäckande texturen. Till detta gick det åt två flyttal på fyra byte vardera. Så här långt hade 20 byte förbrukats. Då återstod fyra eller åtta byte för att komma upp i 24 respektive 32 byte. Detta utnyttjade jag för hörninterpolationen och lade till ytterligare ett flyttal på en byte, som motsvarade ett andra y-värde för hörnet. Den slutgiltiga hörnstorleken blev alltså 24 byte. Den tredje LOD-nivån används enbart på stort avstånd från betraktaren och när ett löv övergår till den andra LOD-nivån skulle det knappt vara möjligt att urskilja skillnaden om hörninterpolation används eller inte. Därför bestämde jag mig för att enbart hörninterpolera mellan första och andra LOD-nivån. När hörnbuffertarna skapas av programmet beräknas det andra y-värdet i hörnstrukturen som det höjdvärde där hörnet skulle hamna för att höjdfältet skulle se exakt likadant ut i första och andra LOD-nivån. Med andra ord det höjdvärde som gör att varje hörn ligger i ytan som den andra LOD-nivåns triangulering ger upphov till. 39

47 3 Allmän terrängrendering Första LOD-nivån Andra LOD-nivån Figur 40 Hörnets position interpoleras mellan dess riktiga position och en position i den lägre LOD-nivåns yta. Om höjdfältet betraktas från sidan skulle ett hörn, som enbart används i första LOD-nivån, mellan två hörn som används i den andra LOD-nivån, ligga på den räta linje som utgör en triangelkant mellan hörnen enligt figur 40. När hörnprogrammet körs tillhandahåller renderingsprocessen en interpolationsparameter i intervallet [0, 1] för varje löv som beror av avståndet mellan betraktaren och lövets mittpunkt. Denna parameter använder hörnprogrammet för att bestämma hörnens position i höjdled. När ett löv kommer precis så nära att LOD-nivån växlar från den andra nivån till den första är interpolationsparametern 0. De hörn som används i den första nivån, men inte i den andra, ligger då fortfarande i den yta som definieras av andra LOD-nivåns triangulering. När betraktaren kommer ännu närmre lövet ökar interpolationsparametern tills den når värdet 1. Då har hörnet flyttat sig till den slutliga positionen i första LOD-nivån. Resultatet blir en mjuk övergång från den lägre LOD-nivån till den högre. Slutligen skulle metoden kunna förbättras avsevärt med hjälp av borttagning av gömda löv med hjälp av horisontberäkningar. Jag inledde ett försök att implementera en sådan teknik, men det visade sig snart vara en komplicerad process rent implementationsmässigt. Jag övergav därför försöket på grund av att implementationen av prototypen inte var avsedd att vara så komplicerad och att jag inte hade full förståelse för hur själva horisontberäkningarna rent praktiskt skulle implementeras. 3.8 Resultat och slutsats Det stora antalet variabler och möjliga flaskhalsar i renderingsprocessen gör att det är mycket svårt att genom konkreta mätningar avgöra terrängmetodens effektivitet. Bristen på verktyg för mätning gjorde det inte lättare för mig. Trots detta lyckades jag göra vissa mätningar för prototypen, som jag kunde använda som underlag för min slutgiltiga utvärdering av metoden. Det som enkelt går att mäta är det genomsnittliga antalet bildrutor per sekund (fps) och antalet utritade trianglar per sekund (tri/s) för renderingsprocessen. Mätresultaten skulle kanske kunna jämföras med teoretiska värden för triangelrendering från grafikhårdvarutillverkarna, men ett sådant värde är ganska ointressant då det är stor skillnad mellan teoretiskt ideala renderingsförhållanden och praktiska renderingsförhållanden. Ett program som endast renderar 500 otexturerade trianglar som totalt tar upp en pixel på skärmen vid utritning undviker ett flertal av de flaskhalsar som inverkar vid terrängrendering. I övrigt kunde jag undersöka om metoden nådde upp till mina mål i allmänhet. För att testa prototyptillämpningen i en miljö som inte enbart innehåller själva terrängen 40

48 3 Allmän terrängrendering lade jag till en välvd yta som motsvarade himlen, ett antal polygoner som utgjorde en havsyta samt ett stort antal träd (se avsnitt 6.1). Ursprungligen hade jag enbart mätningar från min utvecklingsplattform, men under färdigställandet av rapporten fick jag tillgång till en dator med likvärdig processor och ett grafikkort, som var två produktcykler modernare än det grafikkort jag använde under utvecklingen. En jämförelse mellan mätningarna på de två olika datorerna gav en mer nyanserad bild av prototypens egenskaper. Här följer mer detaljerade specifikationer av de två datorerna: Dator A: Utvecklingsdatorn har en Intel Pentium 4-processor med en klockfrekvens på 1,7 GHz. Grafikkortet är ett nvidia GeForce 3 och sitter på en AGP 4x-buss. Dator B: Datorn med modernare grafikkort har en AMD Athlon-processor som motsvarar en Intel Pentium 4-processor på cirka 1,3 GHz. Grafikkortet är ett ATI Radeon 9700 Pro och sitter på en AGP 4x-buss. Mätningarna gjordes på båda datorerna i upplösningen pixlar. De gick ut på att mäta det genomsnittliga antalet bildrutor per sekund samt antalet utritade trianglar per sekund för några olika renderingskonfigurationer. För att få förhållandevis representativa värden skapade jag en flygrutt genom terrängen, som betraktaren följde automatiskt vid varje mätning. Totalt användes fem olika renderingskonfigurationer: 1. Full rendering: Terrängen renderades tillsammans med himmel, hav och vegetation. 2. Enbart terräng: Enbart terrängen renderades med diskret LOD. 3. Enbart LOD 0: Enbart terrängen renderades med enbart första LOD-nivån för varje löv. 4. Enbart LOD 1: Enbart terrängen renderades med enbart andra LOD-nivån för varje löv. 5. Enbart LOD 2: Enbart terrängen renderades med enbart tredje LOD-nivån för varje löv. Resultatet av mätningarna återfinns i tabell 2, tabell 3 och figur 41 nedan. En positiv upptäckt är att prototypen på båda plattformarna når upp till (och med stor marginal upp över) målgränsen på 60 fps. Detta gäller även vid full rendering och därmed finns alltså tillräckligt med resurser kvar för att rendera även andra objekt än terrängen. Tabell 2 Bilduppdateringar per sekund vid rendering. (fps) Tabell 3 Miljoner renderade trianglar per sekund. (Mtri/s) Rendering Dator A (fps) Dator B (fps) Rendering Dator A (Mtri/s) Dator B (Mtri/s) Full rendering Full rendering 2,6 7,9 Enbart terräng Enbart terräng 4,3 12 Enbart LOD Enbart LOD 0 7,0 27 Enbart LOD Enbart LOD 1 5,0 13 Enbart LOD Enbart LOD 2 2,2 5,7 41

49 3 Allmän terrängrendering Terrängen med diskret LOD renderas avsevärt mycket snabbare än terräng med enbart högsta LOD-nivån, vilket bekräftar att metoden går betydligt fortare än om brute force -metoden skulle användas. Faktum är att med diskret LOD går metoden nästan lika fort som de metoder som enbart använder lägre LOD-nivåer i hela terrängen. Intressant att notera är att störst utnyttjandegrad, i fråga om trianglar per sekund, gäller när enbart första LOD-nivån används. Detta tyder på att effektiviteten vid utritning av löv som har färre än 200 trianglar är betydligt lägre, vilket var ett väntat resultat. Här kan ett bättre resultat troligtvis uppnås genom att experimentera med lövstorlekarna eller att ett bättre utritningssystem med dynamiska indexbuffertar som kombinerar flera löv på en gång utvecklas. Trots detta uppvisar prototypen egenskaper som efterfrågades i avsnitt 3.4. Trianglar per sekund FPS (bilder per sekund) Dator A Dator B 400 Dator A Dator B LOD LOD 0 LOD 1 LOD 2 LOD-nivå 0 LOD LOD 0 LOD 1 LOD 2 LOD-nivå Figur 41 Diagrammen visar en jämförelse mellan mätresultaten för de två plattformarna. Andra aspekter som bör studeras är huruvida processorn är så frikopplad som väntat och om metoden skalar som väntat när en likvärdig huvudprocessor och ett snabbare grafikkort används. För att se om processorn var frikopplad lade jag in en slinga som gjorde en miljon divisioner och villkorliga hopp i varje bildruta. Om processorn vore flaskhalsen i systemet borde rimligtvis en sådan slinga påverka bildhastigheten negativt. Efter ett flertal mätningar kunde ingen skillnad i bildhastighet på grund av slingan påvisas. Detta talar för att processorn är frikopplad i hög grad. Efter varje 6-månaders produktcykel dubbleras normalt grafikhårdvarans prestanda (NVIDIA Corporation, 2000(a)). Det innebär att dator B borde ha grafikhårdvara som är cirka fyra gånger snabbare än grafikhårdvaran i dator A. När enbart LOD 0 används stämmer antagandet. Vid full rendering sjunker dock faktorn till tre gånger. En närmare studie av mätningarna för LOD 1 och LOD 2 tyder på att de små löven är ännu ineffektivare på den snabbare hårdvaran. Den snabbare hårdvaran kan uppenbarligen hantera ett stort antal trianglar och gissningsvis kan metodens effektivitet höjas av att en högre mätpunktstäthet införs i höjdfältet. Detta skulle innebära att varje löv skulle innehålla fler punkter och trianglar. Metoden som sådan tycks ändå skala relativt bra. Efter mätningarna drog jag slutsatsen att den implementation jag gjort av metoden med kvadträd i kombination med diskret LOD når upp till de mål jag satte för metoden. Jag anser att metoden kan rekommenderas för effektiv terrängrendering på konsumenthårdvara. 42

50 4 Ljussättning av terräng 4 Ljussättning av terräng 4.1 Grundläggande tekniska förutsättningar Hörnbelysning Innan 3d-hårdvara hade texturenheter användes nästan uteslutande hörnbelysning vid realtidsrendering. Hörnbelysning (NVIDIA Corporation, 2000(b)) går ut på att varje hörn i trianglarna, som renderas, tilldelas en ljusnivå i form av ett färgvärde. När triangeln renderas interpoleras ljusnivåerna över triangelytan och varje pixel som ritas ut får en ljusnivå som ligger någonstans mellan hörnens ljusnivåer (figur 42 och 43). Ofta används normalvektorer som associeras med hörnen för att beräkna vilken ljusnivå hörnet bör tilldelas. Sådana beräkningar kan utföras i realtid om inte antalet hörn är för många. Hörnbelysning kan därför användas om en ljussättning som ändras dynamiskt önskas. Figur 42 Ljusnivåerna interpoleras över ytan. Figur 43 En hörnbelyst triangel Ljuskartor Ett vanligt förekommande alternativ till hörnbelysning är ljuskartor. En ljuskarta (NVIDIA Corporation, 2000(b)) är en textur där varje punkt representerar en ljusintensitet. Ofta genereras ljuskartor programmatiskt med hjälp av en belysningsalgoritm, men kan även skapas manuellt. Vid rendering kombineras ljuskartor med vanliga texturer för varje polygon med hjälp av multitexturering, vilket innebär att två eller fler texturer kan kombineras matematiskt och därmed samtidigt appliceras på en polygon vid rendering (figur 44). Ljuskartor kan generellt inte genereras i realtid, då alltför många beräkningsoperationer skulle krävas. Detta gör att ljuskartor inte är en lämplig teknik för dynamisk ljussättning. Figur 44 Ljuskartan till vänster kan appliceras på texturerade 3d-objekt som då ser belysta ut. 43

51 4 Ljussättning av terräng Per-pixelbelysning Per-pixelbelysning är en ny teknik i realtidssammanhang som fortfarande utvecklas vidare för varje ny generation av 3d-hårdvara. Den övergripande principen för perpixelbelysning är att ljusberäkningar kan utföras för varje pixel i den renderade triangelytan (NVIDIA Corporation, 2000(b)). Med andra ord kan tekniken, i likhet med hörnbelysning, användas för dynamisk ljussättning med en hög pixelprecision, som är i klass med den som uppnås vid användning av ljuskartor. För perpixelbelysning krävs en normalkarta, som är en typ av textur där värdet hos varje punkt motsvarar en normalvektor. När en normalkarta appliceras på en triangel kan hårdvaran använda denna information för att göra liknande ljusberäkningar som de som utförs i hörnbelysningsfallet. 4.2 Några kända metoder för ljussättning av terräng En enkel belysningsmetod För realtidsrendering används ofta en enkel ljusmodell, som utgörs av tre reflektionskomponenter: ambientljus, diffuseljus och specularljus (Angel, 2000). Ljusmodellen är lokal, i den meningen att varje enskilt objekt enbart ljussätts med hänsyn till ljus direkt från ljuskällorna och inte ljus som reflekteras från andra objekt. För terrängrendering innebär detta att ljuset beräknas individuellt för varje triangel och de ljuskällor som direkt belyser den. Ljuskällorna förutsätts i modellen vara punktljuskällor, som sprider ljus likformigt i alla riktningar. Det ljus som betraktaren ser reflekteras från varje punkt på trianglarnas ytor med den totala intensiteten I som en kombination av de tre reflektionskomponenterna med intensiteterna I amb, I diff samt I spec enligt följande samband: I = I amb + I diff + I spec Ambientkomponenten representerar ljus som reflekterats från många objekt och kan ses som en oriktad likfördelad bakgrundsbelysning. Ambientljuset har alltså samma intensitet i hela terrängen och bidrar med en konstant ljusterm för varje punkt på trianglarnas ytor. Ambientkomponenten är en mycket grov approximation av global belysning, där ljus som reflekteras från varje enskild yta i världen bidrar till ljussättningen av varje annan yta. Diffusekomponenten representerar ljus som tas emot från en ljuskälla och reflekteras lika i alla riktningar. Sådant ljus uppfattas följaktligen lika av alla observatörer, oberoende av position. Däremot beror intensiteten hos diffusekomponenten på ljusets infallsvinkel från ljuskällan (figur 45). Diffusekomponenten skalas om med en faktor som räknas ut som en skalärprodukt mellan en vektor som pekar på ljuskällan och en normalvektor för den punkt eller yta som belyses. Faktorn blir som störst när vektorn som pekar på ljuskällan och normalvektorn sammanfaller. Då är ytan nämligen som mest vänd mot ljuskällan och belysningen blir som mest intensiv. Ytor som inte är speciellt blanka har en hög diffusefaktor, då ytojämnheten orsakar spridning av ljuset i alla riktningar. 44

52 4 Ljussättning av terräng Ljuskälla L N N Ljuskälla Yta L Yta Figur 45 Den vänstra ytan blir belyst med en högre intensitet än den högra. Specularkomponenten representerar ljus som tas emot från en ljuskälla och reflekteras i en koncentrerad riktning beroende på ljusets infallsvinkel. Blanka ytor har en hög specularityfaktor, eftersom jämnheten i ytan inte ger upphov till en stor spridning av ljuset. En perfekt spegel har en yta som har en specularkomponent, men saknar diffusekomponent. I figur 46 nedan åskådliggörs de olika ljuskomponenterna lite tydligare. Figur 46 Bollen till vänster har endast en ambientkomponent. Bollen i mitten har både en ambientkomponent och en diffusekomponent. Bollen till höger har en ambientkomponent, en diffusekomponent och en specularkomponent Hoffman och Mitchells metod för terrängbelysning Metoden delar upp belysning i två olika kategorier: direkt och indirekt belysning (Hoffman och Mitchell, 2001). Skillnaden är att direkt belysning omfattar ljus som når en viss punkt i terrängen direkt från ljuskällan, medan indirekt belysning omfattar ljus som först reflekterats från en annan punkt i terrängen. Vidare separerar metoden direkt belysning i solljus och ljus som reflekteras från himlen, där solljuset bidrar mest till den totala belysningen av terrängen. Eftersom solen inte är en punktkälla, utan har en utsträckning, ser metoden solen som en riktad ljuskälla med nästan parallellt utgående ljus. Metoden tar alltså hänsyn till den lilla vinkelavvikelse som finns i solljuset för att återge de mjuka skuggor vinkeln ger upphov till. 45

53 4 Ljussättning av terräng Ljus från himlen är uppenbarligen solljus som sprids i alla möjliga riktningar av bland annat luftmolekyler och vattendroppar i atmosfären. I metoden ses himlen dock som en av solen oberoende ljuskälla som täcker en hel hemisfär, där intensiteten varierar över hela himlens yta. Den indirekta belysningen har en liten inverkan på den totala belysningen av terrängen, men ljusberäkningarna tar ändå hänsyn till den för att förhöja realismen i ljusmodellen. Metoden är utformad för realtidsrendering där en momentan belysning beräknas för varje bildruta. Solljus, ljus från himlen och indirekt ljus beräknas var för sig och kombineras slutligen för varje punkt i en ljuskarta, som laddas upp till 3d-hårdvaran efter varje beräkningspass. Ljuskartan appliceras sedan på terrängen som en textur kombinerad med övriga terrängtexturer. För att kunna bibehålla en tillfredsställande bilduppdateringsfrekvens kan inte ljuskartans upplösning vara för hög. Nedan följer en mer detaljerad sammanfattning av de två beräkningsstegen Enbart solljus För att öka realtidsberäkningarnas effektivitet kan vissa beräkningar utföras i förväg. Metoden använder sig av en s.k. horisontkarta där horisontvinklar lagras för varje punkt i ljuskartan. Solens rörelse approximeras med en rörelse i ett vertikalt plan och därmed behöver horisontvinklar bara beräknas i solplanet (figur 47). Figur 47 Metoden låter solen röra sig enligt en kurva i ett plan och solen kan bara ses från punkten när den är ovanför horisonterna. Dessutom beräknas ytnormalen för varje punkt i ljuskartan i förväg och sparas i en normalkarta i form av ett index till en tabell som innehåller de förberäknade normalerna. För att öka effektiviteten begränsas antalet normaler till 256. Detta kan utföras genom att 256 lämpliga vektorer väljs ut och sedan väljs ett index för varje punkt i ljuskartan på ett sådant sätt att den motsvarande vektorns avvikelse från den beräknade ytnormalen minimeras. Vid körning beräknas för varje bildruta intensitetsfaktorn hos infallande ljus på en yta med en viss ytnormal (figur 45) för varje normalvektor i den tidigare beräknade tabellen genom att beräkna skalärprodukten mellan en vektor som pekar mot solen och ytnormalen. I varje bildruta beräknas även maximi- och minimivinklar för solljuset för varje bildruta (figur 48). Dessa jämförs sedan med horisontvinkeln för varje punkt i ljuskartan för att beräkna en synlighetsfaktor. Faktorn är 1 om horisontvinkeln är mindre än solens minimivinkel, 0 om horisontvinkeln är större än solens maximivinkel och i intervallet (0,1) om horisontvinkeln är mellan sol- 46

54 4 Ljussättning av terräng vinklarna. Slutligen multipliceras synlighetsfaktorn med intensitetsfaktorn för att beräkna solljusets bidrag till varje punkt i ljuskartan. Figur 48 Solljusets maximi- och minimivinklar Enbart ljus som reflekteras från himlen För att beräkna ljuset för varje punkt i ljuskartan som reflekteras från himlen måste det inkommande ljuset integreras över hela hemisfärens synliga yta, vilken approximeras med hjälp av en horisontkarta för åtta riktningar. En sådan beräkning kan inte utföras i realtid. En approximativ lösning är att dela upp himlen i ett litet antal områden, där varje område har konstant ljusintensitet och färg över hela sin yta. För varje punkt i ljuskartan och varje himmelområde kan en faktor för himmelområdets inverkan på punkten beräknas i förväg. Vid körning multipliceras sedan himmelsområdets färg och intensitet med den förberäknade faktorn för att beräkna himmelsljusets bidrag till varje punkt i ljuskartan Indirekt ljus För att detaljerat kunna beräkna inverkan av ljuset som reflekteras från omgivningen skulle en global belysningsmetod kunna användas, men alltför mycket beräkningar skulle behöva göras för att en sådan metod skulle utgöra ett rimligt alternativ för realtidsrendering. Däremot kan en mindre krävande approximation användas. Idén bakom den approximation som används i metoden är att terrängpunkter som är synliga från en viss terrängpunkt blir belysta med intensitet och färg som ligger nära motsvarande egenskaper hos utgångspunkten. Ett exempel som används av metodens upphovsmän är att punkter som är synliga från en punkt i en mörk dal har en tendens att också vara i samma mörka dal. På samma sätt är ofta punkter som är synliga från en upplyst bergstopp också upplysta bergstoppar. Därför antar metoden att ljuset som reflekteras från andra omkringliggande synliga punkter i terrängen har samma intensitet som den punkt ljusberäkningarna för tillfället behandlar. I metoden används ett matematiskt uttryck som har både sådan reflektion och direkt ljus från himlen som parametrar. 4.3 Målsättning När jag valde modell för ljussättningen hade jag som mål att terrängen inte skulle ha en enbart lokal ljussättning. Terrängen skulle kunna kasta skuggor över sig själv och andra objekt. Den skulle dessutom vara effektiv vid rendering och helst kunna beräknas innan programmet körs. Slutligen var det önskvärt att metoden skulle vara förhållandevis enkel att förstå och implementera på grund av den begränsade tid som var avsatt för implementation av ljusmodellen i prototyptillämpningen. 47

55 4 Ljussättning av terräng 4.4 Min metod Lösning Den metod jag kom fram till nådde upp till de mål jag hade satt och visade sig rent tekniskt vara mer flexibel än väntat. Dock lämnar metoden en del att önska i form av realism och är dessutom relativt statisk. En tillämpning som kräver att hänsyn tas till solens förflyttning bör troligtvis implementera Hoffmans metod, även om den metod som presenteras här skulle kunna anpassas till en mer dynamisk situation. När jag skulle välja ljusmodell visade en närmare undersökning av de ovan beskrivna metoderna att ingen av dem uppfyllde de önskningar jag hade. Den enkla modellen är enkel att implementera, men utan kastade skuggor i terrängen blir resultatet utseendemässigt alltför orealistiskt. Modellen är helt enkelt långt under den standard som används i dagens tillämpningar. Hoffmans modell är desto svårare att implementera och förstå, men utseendemässigt är resultatet överlägset. Tabell 4 Tabellen visar en jämförelse av olika belysningsmodeller. Egenskaper Enkel metod Hoffman/Mitchell Min metod Enkel att förstå och implementera Skuggar terrängen Skuggar andra objekt Kan göra beräkningar i förväg Ja Nej Ja Nej Ja Ja Nej Nej Ja Ja Ja Ja Approximerar indirekt ljus Ja (grovt) Ja Ja (grovt) Effektivitet vid rendering Lämplighet för dynamisk ljussättning Visuell kvalitet Hög Medel Hög Medel Hög Låg Låg Hög Medel I tabell 4 finns en jämförelse av de olika modellerna i listform. Den ljussättningsmetod jag har utformat är löst baserad på de två sedan tidigare kända metoderna och ligger någonstans mellan de båda när det gäller visuell kvalitet, prestanda och svårighetsgrad. Nedan följer en närmare beskrivning av metoden. Ljussättningsmetoden är baserad på ljuskartor, men kan även användas för hörnbelysning. Om ljuskartan och höjdfältet har samma dimensioner, det vill säga har ett 1:1-föhållande för texlar och hörn i höjdfältet, kan varje texel i ljuskartan appliceras på motsvarande hörn i höjdfältet. Texelns färgvärde multipliceras då med hörnets färgvärde vilket ger samma effekt som när en ljuskarta används, men med skillnaden att ljusvärdet interpoleras över trianglarna om hörnbelysning används. 48

56 4 Ljussättning av terräng Solen ses av metoden som en riktad ljuskälla med parallella ljusstrålar. Detta innebär att solljusets infallsvinkel i varje punkt i terrängen är densamma. Innan själva ljuskartan kan börja genereras måste solstrålarnas riktning bestämmas. Riktningen representeras av en vektor som pekar i den riktning ljuset kom ifrån. För att avsevärt förenkla beräkningarna förutsätts att vektorn inte har någon z- komponent och därför alltid ligger i xy-planet. Detta innebär mer intuitivt att solens strålar alltid infaller från öster, väster eller rakt uppifrån. Antag att solstrålarna infaller från väster. Detta innebär att enbart delar av terrängen som är till väster om en viss punkt kan blockera solstrålarnas väg till punkten och följaktligen kastar terrängen skuggor åt öster. Att bestämma huruvida en sådan blockering sker eller inte är själva kärnan i metoden. För varje punkt i höjdfältsmatrisen bestämmer metoden en ekvation för en linje som är parallell med solstrålevektorn och går igenom punkten. Därefter undersöker metoden alla punkter som ligger på samma rad i höjdfältet i västlig riktning för att avgöra om någon av dem blockerar solstrålarnas väg till utgångspunkten. Själva punktundersökningen kan metoden göra på två alternativa sätt Alternativ 1 Det första alternativet tycktes rent intuitivt innan testkörning vara ett bra sätt, men visade sig inte fungera speciellt bra. I ett försök att kompensera för approximationen att ljusstrålarna ses som parallella infördes en modifierad version av den synlighetsfaktor som används i Hoffmans metod ovan. För att bestämma synlighetsfaktorn sätter den första alternativa metoden ett litet intervall i höjdled runt den undersökta punktens höjdvärde. Om sollinjen från utgångspunkten ligger ovanför höjdintervallet blir synlighetsfaktorn 1, eftersom solen inte är blockerad. Om sollinjen ligger under intervallet blir synlighetsfaktorn 0, eftersom solen är helt blockerad. Om sollinjen däremot ligger i intervallet runt den undersökta punkten ser metoden solen som enbart delvis blockerad och synlighetsfaktorn får ett värde i intervallet [0, 1] som motsvarar var sollinjen ligger i intervallet runt punkten. Den slutliga synlighetsfaktorn får minimivärdet av de synlighetsfaktorer som erhållits från samtliga punktundersökningar. Det var meningen att beräkningarna skulle ge upphov till mjuka skuggövergångar i terrängen, men i praktiken blev övergångarna enbart mjuka i öst-västlig riktning och belysningen blev allmänt ganska rutig (se figur 49). Eftersom bara punkter från en höjdfältsrad i taget behandlades, utan hänsyn vare sig till höjdfältskolumnerna eller till det avstånd som är mellan punkterna, blev inte resultatet det förväntade Alternativ 2 Det andra alternativet går ut på att enbart undersöka om sollinjen ligger under den undersökta punktens höjdvärde, utan intervall. Om så är fallet, ser metoden solen som blockerad i utgångspunkten. Detta ger upphov till skarpa skuggövergångar, men genom att låta den färdiga ljuskartan behandlas med ett Gaussiskt utjämningsfilter (Fisher m.fl., 2000) blir skuggövergångarna mjukare. Även andra ljusövergångar blir mjukare, vilket leder till ett mer realistiskt utseende hos den relativt lågupplösta ljuskartan. För att bibehålla utbytbarheten med det första alternativa punktundersökningssättet sätts synlighetsfaktorn till noll när solen är blockerad och 49

57 4 Ljussättning av terräng annars ett. Även i detta fall får den slutliga synlighetsfaktorn minimivärdet av de synlighetsfaktorer som fåtts från samtliga punktundersökningar. Figur 49 De övre bilderna visar belysning med alternativ 1 och de undre bilderna visar belysning med alternativ 2. Bilderna till vänster visar endast ljusinformation. Figur 50 Bilden visar ett exempel på hur en ljuskarta kan se ut. 50

58 4 Ljussättning av terräng Efter punktundersökningen beräknar metoden en diffuseintensitet för utgångspunkten enligt den enkla ljusmodellen ovan och multiplicerar den sedan med synlighetsfaktorn för punkten. Ju högre synlighetsfaktorn är, desto större inverkan har diffuseljuset från solen på punktens ljusnivå. Indirekt ljus approximeras av metoden med en ambientintensitet enligt den enkla ljusmodellen, men någon specularityintensitet används inte av metoden eftersom terrängyta generellt inte har någon stor reflektivitetskoefficient. Därefter beräknar metoden den totala intensiteten som en summa av den skalade diffuseintensiteten med ambientintensiteten och lagras i ljuskartan i en texel som motsvarar den aktuella höjdfältspunkten. När ljuskartan är komplett kan den se ut som i figur Skuggkarta När andra objekt ska införas i terrängen, som till exempel träd, är det av intresse att veta om trädet står i skugga eller inte på grund av att terrängen blockerar solen. Av den anledningen utformade jag även en metod för att beräkna en skuggkarta som beräknas på nästan samma sätt som ljuskartan. Den grundläggande idén går ut på att räkna ut ett värde för varje punkt i höjdfältet på vilken höjd över punkten solen inte längre är blockerad och lagra den på motsvarande plats i skuggkartan. Detta innebär att objekt som befinner sig i intervallet mellan punkten och höjdvärdet i skuggkartan är skuggade. Hur höjdvärdet bestäms beskrivs nedan. Till att börja med skapar metoden en matris som har samma dimensioner som höjdfältet med ett element per mätpunkt och nollställer samtidigt samtliga element i matrisen. Antag återigen att solstrålarna infaller från väster. För varje punkt i höjdfältet utförs följande operationsslinga: 1. Bestäm solstrålelinjens ekvation för utgångspunkten. 2. Undersök en punkt i taget i samma höjdfältsrad som utgångspunkten i östlig riktning. 3. För varje punkt som undersöks, räkna ut var solstrålelinjen ligger höjdmässigt vid punkten. 4. Lagra för punkten i skuggmatrisen det värde som är störst av sollinjehöjden och det värde som redan ligger i skuggmatrisen. Detta värde är noll från början. När slingan har upprepats för alla punkter i matrisen har den önskade skuggkartan skapats. Skuggkartans upplösning blir dock inte tillräckligt hög för att helt realistiskt kunna återge de skuggor som terrängen skulle kasta på andra objekt, men det är en i många fall effektiv approximation. 4.5 Slutsats Den valda ljussättningsmetoden är inte perfekt, men den uppfyller de mål jag hade satt för ljussättningen av terrängen. Att använda ljuskartor vid belysning av terräng är en effektiv metod, men själva beräkningen av värdena i ljuskartan kan göras på ett mer realistiskt vis än i den metod jag implementerade. Trots detta anser jag att den valda metoden har en i realtidssammanhang detaljerad beräkningsmodell som tar hänsyn till både solens position och skuggkastning. En mer avancerad beräkningsmodell kan enkelt integreras med metoden om en sådan önskas. 51

59 4 Ljussättning av terräng Sammanfattningsvis är min slutsats att metoden kan rekommenderas för användning på konsumenthårdvara. Exempelbilder på hur den belysta terrängen ser ut finns i bilaga 1 (figur 71-75). 52

60 5 Texturering av terräng 5 Texturering av terräng 5.1 Några kända metoder för texturering av terräng Texturering med stor textur Ett enkelt sätt att texturera terrängen är att använda sig av en stor texturbild, som är avsedd att täcka hela höjdfältet (Guymon, 2000). Rent tekniskt tilldelas varje mätpunkt texturkoordinater, som vid rendering bestämmer vilka delar av texturen som ska täcka de olika trianglarna (figur 51). Mer intuitivt kan texturen liknas vid en stor filt som läggs över hela terrängen. = + Figur 51 Bilden visar ett satellitfoto applicerat på höjdfältet. När satellitbilder eller flygfoton finns att tillgå används vanligtvis denna metod. Ofta genereras dock terrängens textur programmatiskt och andra metoder kan då vara att föredra. Ett urval av sådana metoder beskrivs nedan. En uppenbar begränsning med att använda en enda stor textur är att texturen måste ha en mycket hög upplösning (och kräver därmed mycket minne) för att inte detaljerna ska bli diffusa när texturen sträcks ut över ett stort terrängparti. En texlar stor textur skulle till exempel ha en texel per höjdfältsruta om den applicerades på ett höjdfält med mätpunkter. Om avståndet mellan mätpunkterna motsvarade en meter skulle då varje texel täcka ett område motsvarande en kvadratmeter och därmed skulle texeltätheten per höjdfältsruta vara relativt låg. I figur 52 och 53 nedan visas ett exempel på hur det kan se ut med en stor genererad textur som täcker hela terrängen. Figur 52 Höjdfältet som ska textureras. Figur 53 Höjdfältet efter texturering. 53

61 5 Texturering av terräng Repeterande texturrutor För att minska minnesförbrukningen används ofta ett litet antal mindre repeterande texturrutor istället för en enda stor textur (Guymon, 2000). Det är en metod som går ut på att ett fåtal texturer återanvänds över stora delar av terrängen. Till exempel kan en mindre grästextur appliceras på ett flertal närliggande trianglar i terrängen för att ge en illusion av att en större grästextur har använts. Ett grundläggande krav är att grästexturen kan repeteras sömlöst, vilket innebär att två instanser av samma textur kan placeras bredvid varandra utan att en skarv eller söm är synlig där texturerna möts (figur 54). Figur 54 Texturen till vänster är sömlös och kan repeteras enligt bilden till höger. En uppenbar nackdel med metoden är att repetitionen av texturen ofta ger upphov till synliga upprepningar i terrängen. Visuellt utmärkande drag hos en texturruta blir ännu tydligare när texturen repeteras. Av denna anledning används ofta relativt neutrala och jämna texturer för repetition. Ett sätt att lindra upprepningseffekten är att öka variationen genom att använda ett flertal olika, men snarlika, texturer som kan placeras bredvid varandra sömlöst. En slumpvis placering av de olika texturerna gör att mönster i figuren blir mindre framträdande. Figur 55 Repeterande texturer kan ge upphov till en viss kantighet. Upprepning är dock inte det enda problemet med metoden. Som synes i figur 55, kan de olika texturerna ge upphov till en rutig och kantig texturering över terrängen vid exempelvis övergångar från stentextur till grästextur. Det går till viss del att kringgå detta problem genom att generera övergångstexturer, där en övergångstextur mellan texturerna (gräs- och stentexturerna i exemplet) innehåller element från båda typerna av texturer på ett till synes mer naturligt sätt (figur 56). Om ett 54

62 5 Texturering av terräng flertal olika sorters texturer förekommer i direkt anslutning till varandra i terrängen krävs ett stort antal övergångstexturer, vilket leder till att en större mängd minne tas i anspråk och därmed upphävs delvis argumentet om metodens minnessnålhet. Figur 56 Texturen i mitten är en övergångstextur mellan texturerna till vänster och höger Repeterande texturlager med stor alfamask Hårdvara för 3d-grafik har nu stöd för multitexturering, vilket innebär att när en triangel renderas kan flera texturer användas på en gång för samma triangel. Texturerna kan kombineras på flera olika sätt och detta kan utnyttjas för texturering av terrängen. En metod är att använda flera repeterande texturer i lager där multitexturering används för att kombinera lagren (Guymon, 2000). Figur 57 Texturlager A och texturlager B kombineras av alfamasktexturen C och resultatet syns i D. 55

63 5 Texturering av terräng I figur 57 ovan representerar bild A en stentextur som har repeterats över hela terrängen och på samma sätt representerar bild B en repeterad grästextur. För att kombinera lagren kan en s.k. alfamasktextur, som i bild C, användas. Alfamasktexturen spänner över hela terrängen och repeteras således inte. När terrängen sedan renderas väljs för varje pixel, som ritas ut, en pixel från textur A eller B eller ett viktat medelvärde från både textur A och B. Hur mycket av A och hur mycket av B som ska användas bestäms av alfamasktexturen. Ju vitare alfamasktexturen är vid pixeln som ska ritas ut, desto mer bidrar textur A till slutresultatet och omvänt gäller för textur B. Slutresultatet i bild D blir således en kombination av de repeterande texturerna A och B med automatiskt genererade övergångstexturer. I detta exempel förbrukas minne genom lagring av texturerna A, B och den högupplösta texturen C. En invändning är att textur C förbrukar mycket minne. Jämfört med att använda en enda stor textur för hela terrängen, som beskrevs ovan, behöver inte textur C vara lika högupplöst för att detaljnivån i terrängtextureringen ska bli lika bra (eller bättre). Detta beror på att de repeterade texturerna bidrar med en hög detaljnivå medan alfamasktexturen enbart bidrar med ett val av texturlager på en lägre detaljnivå. Texeltätheten i textureringen för terrängen blir alltså högre till ett lägre minnespris om alfamasktexturmetoden används Stor textur med detaljtexturer Multitexturing kan även användas för andra angreppssätt. Ett sätt att öka texeltätheten i textureringen när en stor textur som täcker hela terrängen används är att använda sig av en s.k. detaljtextur (Guymon, 2000). Den stora texturen tillför då själva grundtexturen med en relativt låg detaljnivå, exempelvis en texel per triangel, vilket skulle innebära att varje triangel har en enda färg tagen från den stora texturen. Detaljtexturen, i form av en mindre repeterande textur, tillför sedan detaljer i form av ett mönster som kombineras med den texelglesa större texturen (figur 58). Dessutom kan flera olika repeterande detaljtexturer användas och kombineras med en alfamasktextur, enligt metoden som beskrevs i föregående avsnitt. Resultatet blir en mindre minnesförbrukning för kombinationen av detaljtexturerna, alfamasktexturen och den stora texturen än för en enda stor textur med samma texeltäthet. Figur 58 Detaljtexturen bidrar med en större texeltäthet till den större utsträckta texturen. 56

64 5 Texturering av terräng Modellering av ekosystem Ett sätt att bestämma utseende och position för texturer och objekt i terrängen är att algoritmiskt generera någon sorts modell för detta. Johan Hammes (årtal okänt) har utvecklat en sådan modell, som beskrivs i Modelling of ecosystems as a data source for real-time terrain rendering. Modellen går ut på att utvecklaren manuellt specificerar ett antal olika typer av virtuella ekosystem, som definierar klimat- och markförhållanden. Därefter tilldelas olika områden i terrängen olika ekosystem algoritmiskt baserat på ett antal parametrar för området i fråga. Hammes använder följande parametrar: Höjd över havet: Ju högre upp över havet terrängområdet är, desto mindre gynnsamma är förhållandena för växtlighet i området. Relativ höjd: Områdets lokala höjdläge är en parameter som indikerar att området är i en dalgång, uppe på en bergstopp eller någonstans däremellan. Nedsänkta områden är ofta våtare och skyddade medan upphöjda områden ofta är mer väderbitna. Lutning: Lutningen inverkar på jordens kvalitet och djup. Exempelvis har branta sluttningar ofta ingen växtlighet. Lutningsriktning: Lutningens riktning inverkar bland annat på antalet soltimmar området utsätts för. Multifraktalt brus: Så kallade multifraktala funktioner uppvisar ofta mönster som påminner om lokala grupperingar av växter och ekosystem i naturen. Denna parameter kan ses som ett sätt att införa en större variation i modellen för att efterlikna naturen ytterligare. 5.2 Förutsättningar och rekommendationer Minnesförbrukning De flesta svårigheter med texturering på grafikhårdvara är relaterade till minnesförbrukning. En tillämpning kan lagra texturer i både AGP-minnet och videominnet, men högst prestanda uppnås om texturerna som används för tillfället är lagrade i videominnet. Tyvärr är videominnet ganska litet (Risley, 2001) och texturerna måste samsas om utrymmet med bland annat bildbufferten. När en textur dimensioneras finns tre avgörande variabler som bestämmer hur mycket minne den förbrukar i videominnet. Dessa variabler är: Upplösning: Upplösningen bestämmer hur många texlar texturen innehåller. Vanligtvis finns en övre gräns för den upplösning hårdvaran klarar att hantera. Ofta är en upplösning där antalet pixlar i både höjdled och sidled är en 2-potens lämplig. Bitdjup: Bitdjupet bestämmer hur många bitar varje texels färgvärde representeras av. Hårdvaran kan oftast hantera texturer som har ett bitdjup på 16 eller 32 bitar. Texturkomprimeringsgrad: För att få rum med maximalt antal texturer i videominnet kan texturerna komprimeras. Olika grader av komprimering kan användas och ju högre komprimeringsgrad som används, desto lägre blir texturens kvalitet. 57

65 5 Texturering av terräng Utvecklaren har i regel ingen kontroll över grafikhårdvarans minneshantering och kan endast uppskatta hur mycket videominne som finns över till texturer och eventuellt index- och hörnbuffertar. När det gäller min terrängmetod är hörnbuffertarna med allra största sannolikhet lagrade i AGP-minnet, eftersom de är för stora för att få plats i videominnet. År 2002 när examensarbetet utfördes var videominnets storlek oftast mellan 64 och 256 MB. En typisk tillämpning använder åtminstone två 32-bitars bildbuffertar och en 16- eller 24-bitars djupbuffert. Anledningen till att två bildbuffertar används är att en teknik som kallas dubbelbuffring ofta används. Denna teknik innebär att medan en bildbuffert visas kan tillämpningen ändra i den andra bildbufferten. När ändringarna är klara byter hårdvaran aktiv buffert och den andra bildbufferten visas istället. En 32-bitars bildbuffert tar upp fyra byte per pixel på skärmen och en 24- bitars djupbuffert tar upp tre byte per pixel på skärmen. I tabell 5 har ungefärligt kvarvarande minnesutrymme som kan används för texturer i videominnet beräknats för vanligt förekommande upplösningar och videominnesstorlekar. Tabell 5 Ungefärlig minnesförbrukning för olika upplösningar och videominnesstorlekar. Videominne (MB) Upplösning (pixlar x pixlar) Bildbuffertar (MB) Djupbuffert (MB) Ledigt minne (MB) x 600 3,7 1,4 58, x 768 6,0 2,3 55, x ,0 3,8 50, x ,6 5,5 43, x 600 3,7 1,4 122, x 768 6,0 2,3 119, x ,0 3,8 114, x ,6 5,5 107,9 En okomprimerad textur som är 256 pixlar bred och 256 pixlar hög med ett bitdjup på 32 bitar tar upp bitar minne, vilket är detsamma som 256 kb. Detta är en typisk storlek för texturer som används i dagens tillämpningar. I vissa fall används även ett antal högupplösta texturer som är 512 pixlar breda och 512 pixlar höga. En sådan textur tar okomprimerad upp 1 MB minne. Grovt räknat innebär detta att på hårdvara med 64 MB videominne som kör i upplösningen finns det plats för runt 40 högupplösta texturer eller runt 160 texturer med en något lägre upplösning. 58

66 5 Texturering av terräng Texturfilter När en texturerad triangel renderas väljer hårdvaran för varje renderad pixel ett färgvärde från en viss texel, vars position i texturen bestäms av texturkoordinaterna. Med andra ord mappas texlar till pixlar. Så länge mappningen har ett 1:1- förhållande är resultatet visuellt tillfredsställande (Vuylsteker, 2002). Om förhållandet blir sådant att flera texlar mappas till en och samma pixel (figur 59) uppstår ofta flimmer om betraktaren eller triangeln rör sig, då hårdvaran mer eller mindre godtyckligt väljer en av texlarna. För att undvika flimmer används därför ofta texturfiltrering, som går ut på att när förhållandet är sådant att flera texlar mappas till en pixel räknar hårdvaran ut ett viktat medelvärde för färgen på (en delmängd av) de texlar, som mappas till pixeln. Pixeln tilldelas därefter detta färgvärde och flimret blir betydligt mindre tydligt. Nackdelen är att eftersom filtreringen arbetar med flera texlar på en gång istället för att bara välja en texel belastas minnesbussen mellan videominnet och grafikprocessorn betydligt mer då fler texlar måste hämtas från minnet. Beroende på vilken typ av filter som används belastas minnesbussen i olika grad. Figur 59 När texturen mappas på de två trianglarna till höger mappas flera texlar till samma pixel i den högraste triangeln Mipmappning Ett sätt att undvika den extra belastningen av minnesbussen som filtrering medför, men ändå reducera flimmer, är att använda en teknik som kallas mipmappning (Mueller, årtal okänt). Tekniken går ut på att ett antal kopior av texturen skapas, men i stegvis lägre upplösningar. En konsekvens av att filtrera en hel textur är att den i praktiken blir en lägre upplöst version av sig själv, eftersom ett flertal texlar krymps ihop till en enda genomsnittlig texel. Med andra ord filtrerar mipmappning texturen i förväg. Rent praktiskt lagras texturen som den ursprungliga versionen och en kopia för varje ytterligare mipnivå som önskas. Varje mipnivå har en upplösning som är hälften så hög både i höjd- och sidled. Om en textur har dimensionerna pixlar och tre mipnivåer önskas kommer den första mipnivån ha upplösningen pixlar. Den andra nivån kommer ha upplösningen pixlar och den tredje nivån kommer ha upplösningen pixlar. Hårdvaran väljer vid rendering den mipnivå som för tillfället har det bästa texel/pixel-förhållandet. Nackdelen med mipmappning är att mer videominne förbrukas på grund av de extra mipnivåtexturerna. Om antalet mipnivåer betecknas 59

67 5 Texturering av terräng n och ursprungstexturens storleken i byte betecknas K blir minnesförbrukningen för mipnivåtexturerna sammanlagt F(n, K) kb, där F(x, y) definieras som F ( x, y) = y 1 x 1 i i= 0 4 och följaktligen blir minnesförbrukningen i exemplet ovan 336 kb, vilket är 80 kb mer än för enbart texturen utan användning av mipmappning Övriga tekniska förutsättningar och rekommendationer Texturering kan inte effektiviseras på lika många sätt som andra delar av renderingsprocessen, men nedan följer några punkter som utvecklaren bör tänka på. Vid tiden för examensarbetet (2002) hade senaste generationen grafikhårdvara mellan tre och åtta texturkanaler. Detta innebär att tre till åtta texturer kan kombineras samtidigt för en triangel vid rendering. Att byta aktiv textur för en texturkanal är en dyr operation (Dietrich, 1999) och därför gäller de rekommendationer om minimering av tillståndsändringar som beskrevs i avsnitt även här. För att rationalisera bort vissa texturbyten kan flera texturer sättas ihop till en stor textur och med texturkoordinaternas hjälp kan trianglarna använda olika delar av den stora texturen istället för att de mindre texturerna byts (Dietrich, 1999). 5.3 Målsättning När jag valde metod för textureringen hade jag följande mål: Texeltätheten i terrängens texturering skulle vara hög. Många olika typer av terrängunderlag skulle kunna finnas i terrängen. Textureringen skulle inte ta upp för mycket minne. Textureringen skulle inte ha för stor negativ inverkan på renderingshastigheten, exempelvis på grund av alltför många tillstångsändringar. Textureringen skulle använda tre texturkanaler för att vara kompatibel med tidig tredje generationens grafikhårdvara, som till exempel grafikkretsarna i Microsofts Xbox eller NVIDIAs GeForce 3-kretsar, men fortfarande enkelt kunna utökas för att använda fler texturkanaler på nyare hårdvara. Textureringsmetoden skulle inte vara för komplicerad att implementera, men fortfarande ge ett acceptabelt resultat på övriga punkter. Textureringen skulle vara åtminstone visuellt acceptabel. Det skulle vara lätt att utöka textureringsmetoden för att dra nytta av funktioner, som har bättre stöd av moderna hårdvarumodeller, såsom bumpmappning och per-pixelljussättning. 60

68 5 Texturering av terräng 5.4 Min metod Jämförelse och val av metod Till att börja med kan metoden med enbart en stor textur förkastas direkt. Den upplösning som skulle krävas för att få en tillräcklig texeltäthet skulle, i de fall där en sådan upplösning över huvud taget kan hanteras av hårdvaran, ha en alltför stor minnesförbrukning. Om höjdfältet är höjdfältsrutor stort med en inte alltför stor punkttäthet skulle, lågt räknat, en texeltäthet på texlar behövas per höjdfältsruta för att uppnå en acceptabel nivå. Detta skulle innebära att den stora texturen skulle behöva innehålla texlar, vilket skulle motsvara 1 GB texturdata. Vid tiden för examensarbetet (2002) var detta inte en möjlig metod för realtidsrendering. Metoden med repeterande texturrutor har en utmärkt texeltäthet, men faller på andra punkter. Först och främst skulle en stor mängd texturer behövas för att ett stort antal olika typer av terrängunderlag skulle kunna representeras och för att kunna representera alla kombinationer av möjliga övergångar från ett underlag till ett annat. Dessutom skulle en stor mängd texturbyten behöva göras när trianglarna i ett kvadträdlöv renderas. Då renderingsmetoden bygger på att trianglarna renderas blockvis utan avbrott för tillståndsändringar är det inte lämpligt med många texturbyten. Repeterande texturlager med en stor alfamask har en betydligt bättre passform till den renderingsmetod som används i prototypimplementationen. Inga texturbyten skulle behövas och metoden skulle i den meningen vara effektiv. Tyvärr når inte heller denna metod upp till de mål som sattes upp i föregående avsnitt. Alfamasken skulle behöva vara relativt högupplöst för att övergångarna mellan de olika texturlagren skulle bli visuellt tillfredsställande. Exakt hur hög upplösningen skulle behöva vara är svårt att säga och skulle bero på texturlagrens egenskaper. Det största problemet är dock att enbart två olika texturlager kan kombineras samtidigt på det sätt som beskrivs ovan, vilket innebär att enbart två olika terrängunderlag kan användas. Dessutom skulle en tredje texturkanal, förutom de två kanaler som används av texturlagren, tas i anspråk av alfamasken. Detta gör att metoden inte enkelt kan utökas till att använda fler texturkanaler. Det är tänkbart att den absolut senaste hårdvaran vid tidpunkten för examensarbetet (2002) skulle klara av att välja mellan alla tillgängliga texturkanaler på en gång med hjälp av ett pixelprogram. Huruvida detta är möjligt eller inte har jag inte undersökt, eftersom jag utvecklade prototypimplementationen på en hårdvarumodell som enbart hade tre texturkanaler och en liten uppsättning pixelprograminstruktioner och därför inte hade kunnat provköra en sådan lösning. Varianter av den här metoden kan dock bli intressanta i framtiden när större delen av hårdvaran som används i hemmen har fler texturkanaler, speciellt då det vore relativt enkelt att utöka denna metod till att använda till exempel bumpmappning. Det alternativ som återstår är metoden med en stor textur och detaljtexturer. Metoden är inte perfekt, men den når i hög grad upp till de mål jag angav ovan. Av den anledningen är detta den metod jag valde. Texeltätheten blir med detaljtexturer lika stor som om en vanlig repeterande textur används. Förvisso kan detaljtexturen ge terrängen ett något repetitivt utseende, men de färgvariationer som den stora 61

69 5 Texturering av terräng texturen ger minskar denna effekt. Dessutom kan detaljtexturlager blandas med en alfamask på hårdvara som har fler än tre texturkanaler. Den stora texturen kan utan problem representera olika terrängunderlag. Faktum är att varje texel i den stora texturen kan representera ett visst terrängunderlag. En direkt konsekvens är att ju högre upplösning som används, desto fler typer av markunderlag kan användas i terrängen. I övrigt behöver inte upplösningen vara alltför hög då det är detaljtexturen som bidrar med texeltätheten. Hur hög upplösning den stora texturen ska ha blir en avvägningsfråga mellan minnesförbrukning och visuell kvalitet. Minnesförbrukningen blir dock endast summan av storleken av huvudtexturen och de detaljtexturer som används. För den terrängrenderingsmetod som används är denna textureringsmetod perfekt. Eftersom texturerna spänner över hela höjdfältet behöver inga tillståndsändringar göras på grund av texturbyten. Implementationsmässigt är metoden enkel och orsakar inga svårigheter. För en huvudtextur och en detaljtextur räcker två texturkanaler till, men om fler detaljtexturer önskas kan metoden utan problem dra nytta av ytterligare texturkanaler. Just den egenskapen gör dessutom att metoden lätt kan utökas med bumpmappning och per-pixelljussättning Lösning Den valda textureringsmetoden var enkel att implementera och till en början använde jag en stor huvudtextur av storleken texlar samt en mipmappad detaljtextur som också var texlar stor. Eftersom höjdfältet hade höjdfältsrutor hade mappningen ett 1:1-förhållande mellan huvudtexturtexlar och texturrutor. Detaljtexturen valde jag att repetera så att varje höjdfältsruta täcktes av hela detaljtexturen. Vid testkörning visade det sig att terrängen på långa avstånd såg texturmässigt odetaljerad ut. För att motverka detta infördes ytterligare en mipmappad detaljtextur av storleken rutor, som jag repeterade så att varje repetition av texturen täckte ett stort antal texturrutor. Resultatet blev att den nyinförda detaljtexturen på avstånd blev mer framträdande och gav terrängen ett mer detaljrikt utseende. Minnesförbrukningen blev för de tre texturerna cirka 2,6 MB och det anser jag vara rimligt i terrängsammanhang. För att spara texturminne och en texturkanal applicerades belysningen på huvudtexturen i förväg genom att ljuskartans texlar multiplicerades med huvudtexturens texlar. I figur 60 återges den belysta huvudtexturen som genererades enligt metoden nedan. + Figur 60 Terrängtexturen till vänster kombineras med ljuskartan för att få fram den belysta huvudtexturen. 62

70 5 Texturering av terräng Texturgenerering För att generera själva terrängtexturen utformade jag en metod som är löst baserad på Hammes ekosystemmodell. En stor skillnad är att modellen enbart tar hänsyn till höjd och lutning i sina beräkningar. För att uppnå en högre grad av realism bör givetvis Hammes metod användas, men jag använde en enklare modell för att undersöka om idén om ekosystemmodeller är lämplig för texturgenerering. Då mer ingående ekologiska kunskaper skulle krävas för att ge parametrarna i Hammes modell realistiska värden ansåg jag det befogat att här använda en något naivare modell. Den metod jag har utformat räknar ut en vikt för varje områdes lämplighet för en viss typ av fördefinierade ekosystem. Området är i detta fall varje ruta mellan höjdpunkterna vilket motsvarar en texel i terrängtexturen. Ekosystemet med den största vikten anses av metoden vara den mest troliga ekosystemtypen för området. En referens till denna ekosystemtyp sparas i en matris för vegetationsutplacering och liknande. Varje ekosystemtyp definieras som en samling av tolv egenskaper. Till att börja med tilldelas varje ekosystemtyp en textur. Från dessa texturer kommer metoden att välja ut texlar som används vid konstruktionen av den slutgiltiga terrängtexturen. Varje ekosystemtyp tilldelas vidare en trädtäthetsfaktor som används vid utplacering av träd i terrängen. De tio återstående egenskaperna används uteslutande för den viktberäkning som nämndes i föregående stycke. Dessa egenskaper innefattar: Minimal höjd: Den absolut lägsta höjd där den aktuella ekosystemtypen kan existera. (Betecknas h min ) Låg höjd: Den undre höjdgränsen för intervallet där förhållandena är som mest gynnsamma. (Betecknas h låg ) Hög höjd: Den övre höjdgränsen för intervallet där förhållandena är som mest gynnsamma. (Betecknas h hög ) Maximal höjd: Den absolut högsta höjd där ekosystemtypen kan existera. (Betecknas h max ) Höjdfaktor: En faktor som bestämmer hur dominant ekosystemtypen är höjdmässigt. (Betecknas k h ) Minimal lutning: Den absolut minsta lutning i områden där ekosystemtypen uppträder. (Betecknas l min ) Liten lutning: Den undre lutningsgränsen för intervallet där förhållandena är som mest gynnsamma. (Betecknas l låg ) Stor lutning: Den övre lutningsgränsen för intervallet där förhållandena är som mest gynnsamma. (Becknas l hög ) Maximal lutning: Den absolut största lutning i områden där ekosystemtypen uppträder. (Betecknas l max ) Lutningsfaktor: En faktor som bestämmer hur dominant ekosystemtypen är lutningsmässigt. (Betecknas k l ) Vikten beräknas som en produkt av två separat beräknade vikter för höjd respektive lutning. Höjdvikten w h (h) där h motsvarar områdets höjd bestäms av följande funktion: 63

71 5 Texturering av terräng w h ( h) = ( h h ) ( h h ) k låg ( h h) ( h h ) max min h 0,, max min k, hög h, h h h min låg hög h < h h h < h h annars låg hög max Lutningsvikten w l (l) där l motsvarar områdets lutning bestäms på samma sätt av följande funktion: w l () l = ( l l ) ( l l ) låg k ( l l) ( l l ) max min l 0,, max min k, hög l, l l l min låg hög l < l l l < l l annars I figur 61 nedan avbildas viktfunktionerna för en tänkbar ekosystemtyp. låg hög max vikt vikt huvudområde huvudområde höjdfaktor lutningsfaktor min undre gräns övre gräns höjd max 256 min undre övre max 90 gräns gräns lutning Figur 61 Viktfunktionerna används för att beräkna vilken ekosystemtyp, som dominerar i ett visst område. Det kan tyckas att detta system är något orättvist eftersom det räcker för en ekosystemtyp att med en extremt liten marginal ha en högre vikt än en annan ekosystemtyp för att den ensam ska råda i området. För att råda bot på detta och göra processen lite rättvisare beräknar metoden en procentsats för hur stor del av summan av samtliga vikter varje enskild vikt utgör. Procentsatsen kan ses som ett mått på hur stor inverkan en viss ekosystemtyp har på området. När metoden slutligen bestämmer färgvärdet för den texel, som motsvarar det aktuella området, tar den en texel från en textur för varje ekosystemtyp och beräknar sedan en viktad summa av färgvärdena för dessa texlar, där de beräknade procentsatserna utgör vikterna. Detta innebär att den slutgiltiga texeln för området influeras av samtliga ekosystemtyper till en viss grad, där graden mycket väl kan vara noll. I figur 62 visas ett exempel där en ekosystemtyp med grästextur dominerar i platta och låga områden, medan en ekosystemtyp med bergtextur dominerar i brant sluttande och höga områden. 64

72 5 Texturering av terräng Figur 62 Höga och kraftigt lutande områden har ingen växtlighet i texturen. 5.5 Slutsats Min slutsats är att den valda textureringsmetoden har lämpliga egenskaper för användning på konsumenthårdvara. Detta gäller speciellt för hårdvara som endast har tre texturkanaler. I framtiden kommer andra förutsättningar att gälla när antalet texturkanaler blir fler och allt mer avancerade pixelprogram kan skrivas. Vid tiden för examensarbetet (2002) och åtminstone för några år framåt kommer troligtvis den metod jag implementerade (eller variationer av metoden) vara ett lämpligt alternativ. Tills nyare hårdvara når hemmen i stor utsträckning rekommenderar jag den metod som beskrivs här för användning på konsumenthårdvara. 65

73 6 Vegetation och atmosfäriska effekter 6 Vegetation och atmosfäriska effekter 6.1 Vegetation Ett sätt att förhöja realismen i terrängen är att rendera någon form av vegetation. I min prototypimplementation har jag valt att rendera träd. Det finns många olika sätt att göra detta på och här följer en redogörelse för den metod jag har utvecklat. Till att börja med måste varje träd placeras ut i terrängen. Om ett stort antal träd ska renderas blir det ett ganska omfattande arbete om utplaceringen sker manuellt. Av den anledningen har jag valt att placera ut träden algoritmiskt. Det enklaste sättet vore kanske att beräkna vanliga slumptal för trädens position, men då blir spridningen av träden ganska jämn över terrängen, förutsatt att en likformigt fördelad slumptalsfunktion används. Jag bestämde mig därför för att försöka hitta en funktion som skulle ge upphov till en mer naturlig fördelning av träd. I övrigt satte jag en gräns på högst 100 träd per kvadträdlöv för att trädrenderingen inte skulle kräva för mycket resurser. Själva träden utgjordes av fyra trianglar i form av två korsställda rektanglar med en tillhörande trädtextur för att undvika att trädet ser för platt ut (figur 63). Små slumpmässiga färg- och storleksvariationer gjorde att träden inte var helt identiska. Ett bättre tillvägagångssätt vore att ha ett flertal olika tredimensionella modeller av träd, men jag hade inte tillgång till sådana. Dessutom är trädens utseende irrelevant för själva utplaceringsalgoritmen. Figur 63 Trädtexturen appliceras på två genomskinliga rektanglar. När jag valde en trädfördelningsfunktion letade jag efter en funktion som på något sätt kunde ta hänsyn till att träd i naturen ofta växer i närheten av andra träd. En till synes slumpartad funktion som uppvisar ett sådant beteende, är den så kallade Perlin-brusfunktionen. En brusfunktion är en funktion som varierar över rummet med en uniform frekvens. Perlin-brus är så kallat koherent brus (Zucker, 2001), vilket innebär att bruset definieras av en brusfunktion som är kontinuerlig över hela sin definitionsmängd. En koherent brusfunktion f(x) skulle kunna se ut enligt figur 64. Perlin-brusfunktionen bygger i grunden på pseudoslumptal och kan därför ses som ett slags slumpfunktion, som inte är likformigt fördelad. Brusvärdena ses i 66

74 6 Vegetation och atmosfäriska effekter slutändan av trädplaceringsalgoritmen som en indikator för hur många träd som ska placeras ut inom ett visst område. f(x) Figur 64 Exempel på hur en koherent brusfunktion kan se ut. x Det första steget i utplaceringsalgoritmen är att beräkna ett brusvärde i intervallet [0, 1] för varje ruta i höjdfältets rutnät och lagra värdet på en motsvarande plats i en brusmatris som har ett element för varje höjdfältsruta. Därefter multipliceras varje brusvärde med en träddensitetsfaktor i intervallet [0, 1] från ekosystemmatrisen. Träddensitetsfaktorn är ett sätt att styra graden av växtlighet för en viss typ av ekosystem. Figur 65 visar en grafisk tolkning av en typisk brusmatris, där svart motsvarar värdet noll, vitt motsvarar värdet ett och alla andra gråskalor motsvarar värden däremellan. Figur 65 Exempel på perlinbrus. Figur 66 Perlinbrusvärden under 0.55 har förkastats. 67

75 6 Vegetation och atmosfäriska effekter Redan i detta skede syns ett ganska klumpartat mönster i figuren. För att göra fördelningen av träd ännu mer lokalt grupperad sätter algoritmen en gräns för vilka värden som kommer användas. Alla brusvärden under 0,55 förkastas och sätts till 0. Nu framträder ett betydligt mer lokalt grupperat mönster i matrisen (figur 66). I nästa steg normaliserar algoritmen alla värden i varje delmatris som motsvarar ett kvadträdlövs område. Detta innebär att brusvärdena skalas om så att summan av alla brusvärden i delmatrisen blir ett. De normaliserade värdena representerar en procentsats av alla 100 träden som har tilldelats området, enligt ovan. Det sista steget i utplaceringsalgoritmen är att undersöka om trädets position i höjdled ligger under skugghöjdvärdet i skuggkartan, vilket skulle innebära att trädet befinner sig i skuggan av terrängen. Om så är fallet multipliceras trädets färg med en skuggfaktor. För att effektivt rita ut de utplacerade träden utformade jag en renderingsmetod som enbart ritade ut träd i närheten av betraktarens position. Resultatet var att träden helt plötsligt uppstod i bilden när betraktaren rörde sig. För att göra detta moment mindre irriterande införde jag en avståndsbaserad genomskinlighet för träden, med hjälp av ett hörnprogram. Renderingsmetoden i sin slutgiltiga form har ett avståndsvärde som sätter en gräns för hur långt bort från betraktaren träd kan renderas. Bortom denna gräns ritas inga träd ut. Ytterligare en avståndsgräns sattes nära betraktaren. Träd som ritas ut närmre än den närmre gränsen renderas helt utan genomskinlighet. De träd som renderas mellan närmre och bortre gränsen renderas med ett genomskinlighetsvärde som linjärt går från 0 % genomskinlighet vid den närmre gränsen till 100 % genomskinlighet vid den bortre gränsen (figur 67 och 68). På detta sätt introduceras träden gradvis i bilden och stör då inte betraktaren lika mycket som i den ursprungliga metoden. genomskinlighet 100% 0% närmre gräns bortre gräns avstånd Figur 67 Trädens genomskinlighet ökar tills avståndet når den bortre gränsen där de slutar ritas ut. 0% 0% 0% 10% 20% 30% 40% 50% 60% 70% 80% 90% 100% renderas inte närmre gräns bortre gräns Figur 68 Trädens genomskinlighet regleras linjärt. 68

76 6 Vegetation och atmosfäriska effekter För maximala renderingsprestanda bör alla träd lagras i ett fåtal stora hörnbuffertar för att minimera antalet hörnbuffertbyten. Indexering rekommenderas också eftersom varje rektangel i träden består av ett triangelpar som delar två hörn. Träden bör dessutom renderas som en triangellista eftersom en triangelremsa som längst skulle kunna bli två trianglar lång och betydligt fler trianglar behöver ritas ut på en gång för att effektivt utnyttja grafikhårdvaran. En idé jag hade för att förbättra vegetationsrenderingen var att i förväg generera lågupplösta texturer föreställande vegetationen som kunde projiceras på terrängen och på ett avstånd bortom bortre trädgränsen ge ett sken av att träd renderas även där. Exakt hur texturen skulle genereras har jag dock inte utrett, men en eventuell framtida bearbetning av de terrängrenderingsmetoder jag har implementerat skulle kunna använda sig av sådana texturer. 6.2 Atmosfäriska effekter Dis Ett sätt att öka realismen hos terrängen är att i renderingsprocessen ta hänsyn till atmosfärens diseffekt. För en betraktare ser en kulle på långt avstånd ut att ha en annan färg än om betraktaren skulle befinna sig närmare kullen (figur 69). En sådan effekt bidrar mycket till realismen, men är inte alls komplicerad att implementera. Grafikhårdvaran tar nämligen hänsyn till en dimfaktor när pixlar ritas ut i bildbufferten, genom att multiplicera dimfaktorn med hörnfärgen. Figur 69 Diseffekterna i bilden är tydliga. Bilden används med tillstånd från Bob Ribokas (2003). Det finns ett antal parametrar att ställa in för att få rätt sorts diseffekt eller dimeffekt och om ett hörnprogram används får utvecklaren fullständig kontroll över dimfaktorn. I prototypimplementationen har det senare utnyttjats och dimfaktorn räknas 69

77 6 Vegetation och atmosfäriska effekter ut med en enkel linjeekvation, som beror av det aktuella hörnets djupvärde, för att åstadkomma en linjär ökning av dimfaktorns påverkan i djupled Markdimma Dimma som ligger precis över marken kan också göras i ett hörnprogram. I detta fall beror dimfaktorn på hörnets höjdvärde istället. Jag testade markdimma i praktiken i prototypimplementationen och effekten fungerade förhållandevis väl. För att öka realismen bör dock en mer avancerad modell för markdimman användas än den enkla linjeekvation som jag använde Molnskugga För grafikhårdvara som har många texturkanaler kan molnskugga vara en intressant effekt. Moln brukar ofta röra sig över himlen och när molnen skymmer solen kastar molnet en skugga på de delar av terrängen där solen skyms. Resultatet blir att stora skuggområden rör sig över terrängen. Ett enkelt sätt att emulera denna effekt är att göra en stor textur som är en approximation av de skuggor som molnen skulle kasta på terrängen. Eftersom en betraktare på terrängens yta sällan kan koppla ihop skuggornas utseende med molnens utseende behöver skuggtexturen i allmänhet inte vara en perfekt representation av molnens skugga för att betraktaren ska uppleva effekten som realismförhöjande. Implementationsmässigt är molnskuggor enkelt att åstadkomma. Den stora skuggtexturen appliceras över hela terrängen med multitexturering på samma sätt som detaljtexturen. Slutligen flyttas skuggtexturen genom att ett hörnprogram i varje bildruta adderar ett lämpligt värde till de texturkoordinater som bestämmer skuggtexturens läge. 70

78 7 Sammanställning och rekommendationer 7 Sammanställning och rekommendationer Målet med examensarbetet var att komma fram till rekommendationer av lämpliga metoder för användning på konsumenthårdvara. Varje utredande kapitel i denna rapport avslutades därför med en sådan rekommendation. För att få en mer övergripbar bild av det slutliga resultatet följer här en sammanställning av de rekommendationer som gjordes i tidigare avsnitt. 7.1 Rekommendationer för terrängrendering Efter en teoretisk granskning av ett antal metoder för att rendera en terrängyta utgående från höjdmätningar i ett höjdfältsrutnät rekommenderades i avsnitt 3.8 en metod för användning på konsumenthårdvara. Metoden bedömdes i hög grad uppfylla de mål som sattes upp i avsnittet och kombinerar hierarkisk bortsållning av objekt utanför synfältet (m.h.a. kvadträd och vyvolymsgallring) med avståndsbaserat blockvist byte av detaljnivåer (diskret LOD) för att rendera terrängen. När den rekommenderade metoden implementerades utökades den med bland annat hörnprogrambaserad hörninterpolation för mjukare övergångar mellan olika detaljnivåer i terrängen. Implementation uppvisade vid provkörningar och mätningar egenskaper som starkt indikerade att den teoretiska granskningen även stämde i praktiken. 7.2 Rekommendationer för ljussättning För en högre grad av realism bör den renderade terrängytan ljussättas. Olika belysningsmodeller undersöktes och i avsnitt 4.5 rekommenderades en belysningsmetod som var baserad på en kombination av idéer från de undersökta modellerna. Metoden bygger på en stor ljuskarta som täcker hela terrängen. Ljuskartan är en textur som enbart innehåller belysningsinformation. Belysningsinformationen beräknades genom att spåra en stråle till solen från varje terrängpunkt. En punkt som inte belyses direkt av solen antas ligga i skugga. Varje punkt fick slutligen ett ljusvärde som beräknades som produkten av skuggfaktorn och ett värde som representerade infallsvinkeln för solljuset relativt terrängytans normalvektor vid punkten. Vidare beskrevs också en metod för att bestämma om ett objekt som inte tillhör terrängen skuggas av terrängen eller inte. Metoden baseras på ovan nämnda strålspårning och lagrar för varje terrängpunkt ett höjdvärde som objektet måste befinna sig ovanför för att inte vara skuggat av terrängen. 7.3 Rekommendationer för texturering För att underlaget i terrängen ska bli mer övertygande behöver texturer appliceras på terrängytan. Ett antal metoder för texturering undersöktes och en metod framstod som mer lämplig än övriga och rekommenderades i avsnitt 5.5 för användning på konsumenthårdvara. Metoden går ut på att en stor textur med färginformation appliceras på terrängen. För att inte förbruka alltför mycket videominne måste texturens upplösning vara ganska låg. Texturen tillför då inte tillräckligt med bildinformation i terrängen. För att råda bot på detta tillförs två gråskaletexturer 71

79 7 Sammanställning och rekommendationer (detaljtexturer) i olika upplösning som repeteras över terrängen och tillför mer detaljer till textureringen. Textureringen av terrängen är troligtvis det område som kan utvecklas mest när mer avancerad hårdvara kommer ut på marknaden. En metod för automatisk generering av den stora texturen beskrevs också i textureringskapitlet. I stora drag gick metoden ut på att ett sannolikt underlag valdes för varje punkt i texturen beroende på ett antal faktorer som terrängens höjd och lutning i området. Underlagsbestämningen var relativt enkel men kan enkelt utökas med mer avancerade faktorer. 7.4 Förslag på realismförhöjande metoder I avsnitt 6.1 föreslogs en metod för att placera ut och rendera träd i terrängen. Metoden gick ut på att trädens position bestämdes av en pseudoslumpmässig Perlinbrusfunktion med ett organiskt utseende. För själva utritningen föreslogs att två korsställda rektanglar texturerade med ett fotografi av ett träd kan användas. Dessutom beskrevs en metod för att med hjälp av ett hörnprogram gradvis introducera träd i bilden baserat på trädens avstånd till betraktaren. I övrigt föreslogs tre dimrelaterade atmosfäriska effekter i avsnitt 6.2. Den första effekten var dis och kan enkelt åstadkommas genom att en ekvation beroende på avståndet till betraktaren ställs upp för dimman i ett hörnprogram. Grafikhårdvara har i allmänhet en dimfaktor som appliceras på de pixlar som ritas ut i bildbufferten och det är denna faktor som hörnprogrammet kan manipulera. Den andra effekten som föreslogs var markdimma. Denna effekt kan implementeras på samma sätt som dis, men med en markrelativ höjdbaserad ekvation istället för en betraktarrelativ avståndsbaserad ekvation. Den sista effekten gick ut på att emulera molnskuggor. En sådan effekt kan åstadkommas genom att en stor skuggtextur stegvis flyttas över landskapet med hjälp av ett hörnprogram som ändrar texturkoordinaterna. 72

80 8 Litteraturförteckning 8 Litteraturförteckning 8.1 Referenser 3Dfx Interactive, Inc Glide Programming Guide. API-dokumentation från 3DfxInteractive, Inc. (Senast besökt maj 2003) Angel, E Interactive Computer Graphics: A Top-Down Approach With OpenGL. 2 nd ed. Addison-Wesley. ISBN X ATI Technologies TRUFORM White Paper. ATI Technologies. (Senast besökt maj 2003) Barron, D D Card Guided Tour. (Senast besökt maj 2003) Cebenoyan, C. Wloka, M Graphics Performance: Balancing the Rendering Pipeline. NVIDIA Corporation. (Senast besökt maj 2003) Dietrich, S. Årtal okänt. Optimizing For Hardware Transform and Lighting. NVIDIA Corporation. (Senast besökt maj 2003) Dietrich, S Maximizing Texture Performance. (Senast besökt maj 2003) Duchaineau, M. Wolinsky, M. Sigeti, D. E. Miller, M. C. Aldrich, C. Mineev- Weinstein, M. B ROAMing Terrain: Real-time Optimally Adapting Meshes. Lawrence Livermore National Laboratory, Los Alamos National Laboratory. (Senast besökt april 2002) Fisher, R. Perkins, S. Walker, A. Wolfart, E Spacial Filters Gaussian Smoothing. (Senast besökt maj 2003) Fosner, R All Aboard Hardware T&L. Game Developer. April s Guymon, M Moving Mountains: Terrain Generation Methodology. Game Developer. Januari s

81 8 Litteraturförteckning Hammes, J. Årtal okänt. Modeling of Ecosystems as a Data Source for Real-Time Terrain Rendering. (Senast besökt maj 2003) Hoffman, N. Mitchell, K Photorealistic Terrain Lighting in Real Time. Game Developer. Juli s Huddy, R DirectX8 Performance. NVIDIA Corporation. (Senast besökt maj 2003) Huddy, R. Årtal okänt. The Efficient Use Of Vertex Buffers. NVIDIA Corporation. (Senast besökt maj 2003) Intel. Årtal okänt(a). 3D University: Intel 3D graphics. (Senast besökt maj 2003) Intel. Årtal okänt(b). Tutorial: AGP Technology. (Senast besökt maj 2003) Lindstrom, P. Koller, D. Ribarsky, W. Hodges, L. F. Faust, N. Turner, G. A Real-Time, Continous Level of Detail Rendering of Height Fields. Georgia Institute of Technology, SAIC. (Senast besökt april 2002) Maughan, C. Wloka, M. Årtal okänt. Vertex Shader Introduction. (Senast besökt maj 2003) Mortensen, J Real-Time Rendering of Height Fields Using LOD and Occlusion Culling. Master s Thesis at Computer Science Department, University College London. (Senast besökt april 2002) Mueller, C. Årtal okänt. Mipmapping. (Senast besökt maj 2003) Nirenstein, S. Winberg, S Hierarchical Level of Detail Optimisation. Computer Science Honours Project. UCT Computer Science Department. (Senast besökt maj 2003) 74

82 8 Litteraturförteckning NVIDIA Corporation Demystifying 3D Graphics. NVIDIA Corporation. (Senast besökt maj 2003) NVIDIA Corporation. 2000(a). New NVIDIA GPU Breaks One Billion Pixels Per Second Barrier. Pressrelease. NVIDIA Corporation. (Senast besökt maj 2003) NVIDIA Corporation. 2000(b). Technical Brief Per-Pixel Lighting and Bump Mapping with the NVIDIA Shading Rasterizer. NVIDIA Corporation. NVIDIA Corporation. 2002(a). Technical Brief NVIDIA Lightspeed Memory Architecture II: Breakthrough Memory Design for Industry-Leading Performance. NVIDIA Corporation. NVIDIA Corporation. 2002(b). Technical Brief NVIDIA nfinitefx II Engine: From Research to Real Time. NVIDIA Corporation. NVIDIA Corporation. Årtal okänt(a). Technical Brief NVIDIA nfinitefx Engine: Programmable Pixel Shaders. NVIDIA Corporation. NVIDIA Corporation. Årtal okänt(b). Technical Brief NVIDIA nfinitefx Engine: Programmable Vertex Shaders. NVIDIA Corporation. Picco, D Frustum Culling. (Senast besökt maj 2003) Ribokas, B Bild. (Senast besökt augusti 2003) Risley, D Video Memory. (Senast besökt maj 2003) Rogers, D. H Vertex Cache Optimization. NVIDIA Corporation. (Senast besökt maj 2003) Röttger, S. Heidrich, W. Slusallek, P. Seidel, H. P Real-Time Generation of Continuous Levels of Detail for Height Fields. Graphische Datenverarbeitung, Universität Erlangen-Nürnberg. (Senast besökt april 2002) Salvator, D ExtremeTech 3D Pipeline Tutorial. (Senast besökt maj 2003) 75

83 8 Litteraturförteckning U.S. Geological Survey USGS Digital Elevation Models. U.S. Geological Survey. (Senast besökt maj 2003) Vuylsteker, P Texture Filtering. (Senast besökt maj 2003) Weeks, J D Backface Culling. Code x Software. (Senast besökt maj 2003) Weisstein, E. W Quadtree. Wolfram Research, Inc. (Senast besökt maj 2003) Zucker, M The Perlin noise math FAQ. (Senast besökt maj 2003) 8.2 Övrig intressant litteratur i ämnet Assarsson, U. Möller, T. Årtal okänt. Optimized View Frustum Culling Algorithms for Bounding Boxes. Journal of Graphics Tools. #5, Vol 1. s Bacik, M Rendering the Great Outdoors: Fast Occlusion Culling for Outdoor Environments. Game Developer. April s Blow, J Terrain Rendering at High Levels of Detail. Bolt Action Software. (Senast besökt april 2002) Blow, J Rendering Level-of-Detail Forecast. Game Developer. Augusti s Blow, J Unified Rendering LOD Part 2. Game Developer. April s Haines, E. Möller, T Real-Time Shadows. Utdrag ur boken Real-Time Rendering. ISBN (Senast besökt september 2002) Hoffman, N. Preetham, A. J Photorealistic Real-Time Outdoor Light Scattering. Game Developer. Augusti s Hoppe, H Smooth View-Dependent Level-of-Detail Control and its Application to Terrain Rendering. IEEE Visualization s

84 8 Litteraturförteckning Huddy, R Basic Mistakes. NVIDIA Corporation. (Senast besökt maj 2003) Lander, J Mighty Morphing Mesh Machine. Game Developer. December s Lindstrom, P. Pascucci, V Visualization of Large Terrains Made Easy. IEEE Visualization Lawrence Livermore National Laboratory. (Senast besökt april 2002) Macri, D Fast AGP Writes for Dynamic Vertex Data. Game Developer. Maj s Martin, K Using Bitmaps for Automatic Generation of Large-Scale Terrain Models. Game Developer. Oktober s Nuydens, T. Årtal okänt. Terrain Texturing. (Senast besökt september 2002) O Neil, S. Årtal okänt. A Real-Time Procedural Universe, Part 1: Generating Planetary Bodies. (Senast besökt april 2002) Sempé, L. R Sky Domes. (Senast besökt april 2002) Stewart, A. J Hierarchical Visibility in Terrains. Eurographics Rendering Workshop. Juni s Stewart, A. J Fast Horizon Computation at All Points of a Terrain with Visibility and Shading Applications. IEEE Transactions on Visualization and Computer Graphics. #4, Vol 1. s Tsui, C Daylight, Sky and Sun Rendering. Year 3 BSc Computer Science Individual Project at the Department of Computer Science, UCL. (Senast besökt oktober 2001) Turner, B Real-Time Dynamic Level of Detail Terrain Rendering with ROAM. (Senast besökt april 2002) 77

85 Bilaga 1 - Terrängbilder Bilaga 1 Terrängbilder Figur 70 Terrängen med ofyllda trianglar. Figur 71 Terrängen med en stor textur och belysning. 78