Umeå universitet 4 februari 2004 Institutionen för datavetenskap David Olsson

Transkript

1 Umeå universitet 4 februari 2004 Institutionen för datavetenskap "! # $&%(')+*-,/.0))-132+$ ;:-.<>=-.@?BADCE2+2F$-.G4.H:()-1I6J4K, Handledare: Anders Backman (andersb@cs.umu.se) Christopher Holmberg (christopher.holmberg@coldwood.com)

2

3 Abstract The rapid development of dedicated graphics processors have made real-time rendering of shadows in three dimensional scenes possible. This thesis investigates the algorithms currently available and evaluates them with regard to performance, visual resulats and portability. A C/C++ implementation of a modification of the shadow volumes algorithm, performing all calculations on the graphics processor, is made and thoroughly evaluated. The results show that the implementation is stabile and performes well enough in order to be used in, for example, computer games with a large number of dynamically generated shadows. Several optimizations do, however, turn out to be very difficult to apply due to fundamental steps of the algorithm. This makes it hard to develop the algorithm any further, at least when it comes to performance.

4

5 Sammanfattning De senaste årens utveckling av grafikhårdvara har möjliggjort rendering av skuggor i tredimensionella miljöer i realtid. Denna rapport undersöker vilka algoritmer, lämpade för modern hårdvara, som finns tillgängliga idag och utvärderar dem baserat på prestanda, visuella resultat och portabilitet. En implementation i C/C++ av en variant på shadow volumes-algoritmen, som utför beräkningar enbart på grafikhårdvaran, görs och utvärderas mer ingående. Resultaten visar att implementationen är stabil och presterar så väl att den är möjlig att använda i till exempel datorspel där ett stort antal dynamiska skuggor kontinuerligt genereras. Det visar sig dock att algoritmens utformning försvårar implementationen av ett antal bra optimeringar vilket gör det svårt att vidareutveckla algoritmen vad gäller prestanda.

6

7 Innehåll 1 Inledning 1 2 Problemspecifikation 1 3 Grundläggande skuggrenderingstekniker Vad är skuggor? Varför skuggor i virtuella miljöer? Icke-realtids tekniker Rekursiv raytracing Radiosity Skuggor i realtid Projective planar shadows Shadow maps Shadow volumes Analys av moderna algoritmer för skuggor i realtid Modern grafikhårdvara Algoritmer för hårda skuggor Shadow maps i hårdvara Shadow volumes i hårdvara Algoritmer för mjuka skuggor Bild-baserade tekniker Objekt-baserade tekniker Slutsatser Implementation Grundläggande algoritm Stabilitet Resultat Diskussion Framtida arbete Scengraf Mjuka skuggor Tack till 41

8

9 Figurer 1 Illustration av de termer som används för att beskriva skuggor 2 2 Illustration av skuggors vikt för att avgöra objekts relativa position Skuggor framhäver mottagares geometri Skugga ger information om ej direkt synliga delar av blockerare 4 5 Ytor självskuggade av shadow map utan bias (från Williams[29]) 7 6 Aliasartefakter associerade med shadow map-algoritmen (från Everitt et al.[14]) Skuggpolygon givet en konturkant och en ljuskälla Grafikpipeline Högre kvalitet med aliasfri silhouette map-skugga (från Sen et al.[27]) Uppdelning vid silhouette map-jämförelse Punkter renderas till olika texlar baserat på id För få hårda skuggor ger ej mjuk skugga Specialfall med felaktig synlighetsmap Siluett projicerad med penumbra till plan (från Haines[17]) Haines platå för mjuka skuggor (från Haines[17]) Penumbrakilalgoritmens renderingssteg Skuggvolym baserad på hörnnormaler Till höger, korrekt skuggvolym jämfört med en, till vänster, felaktig skuggvolym baserad enbart på hörnnormaler Extra punkter ger korrekt skuggvolym Prestanda vid olika komplexitet Prestandans beroende av upplösningen Antalet ljuskällors påverkan på prestandan

10

11 1 Inledning Under de senaste decennierna har utvecklingen av datorer gått otroligt fort. Enligt den så kallade Moores lag fördubblas antalet transistorer möjliga att sätta in på en krets av given storlek var 18:e månad vilket lett till att processornas prestanda ökat lavinartat. Detta har i sin tur möjliggjort mer och mer avancerade applikationer. I och med uppkomsten av speciella, dedikerade, grafikprocessorer har även helt nya möjligheter för realtidsgrafik uppkommit. Då skuggor i realtid är ett av de mest komplicerade och prestandamässigt krävande problemen inom tredimensionell datorgrafik har det tidigare varit omöjligt att i någon större utsträckning visualisera dem på ett korrekt sätt. I och med de senaste framstegen inom grafikhårdvara har dock möjligheterna växt. Forskningen på området har varit omfattande och ett antal olika algoritmer har uppkommit. Detta har lett till att skuggor nu, i begränsade former, finns implementerade i, bland annat, många av de datorspel som släpps. Vidare erbjuder den senaste generationen av den grafikhårdvara som finns tillgänglig för vanliga konsumenter ny funktionalitet och förättrad prestanda som möjliggör applikationer med mer generella skuggor. De tidigare algoritmerna har dock nödvändigtvis genomgått förändringar och justeringar för att effektivt kunna utnyttja den nya hårdvaran. 2 Problemspecifikation Syftet med examensarbetet är att undersöka vilka algoritmer för att beräkna och rendera skuggor i tredimensionella miljöer i realtid som existerar och vilka som är användbara och anpassade för dagens grafikhårdvara. Algoritmerna ska utvärderas baserat främst på deras prestanda och visuella resultat. Andra viktiga faktorer är också de krav algoritmerna ställer på hårdvaran, då detta är väldigt avgörande för vilka plattformar det är möjligt att implementera dem, för vilka ändamål algoritmen passar (polygongeometrier, parametriska ytor, datorspel, visualisering av vetenskaplig data, för att nämna några) och slutligen också övriga för- och nackdelar associerade med algoritmerna. I och med denna studie skall också möjligheten till att erhålla mjuka skuggor (se sektion 3.1 för en förklaring) i realtid i någon större utsträckning för applikationer så som datorspel undersökas. Baserat på undersökningens resultat skall en implementation i C/C++ utföras. Den algoritm som implementeras skall vara den som verkar mest lämpad enligt de ovan beskrivna kriterierna. Framförallt är det viktigt att implementationen prestandamässigt klarar av att dynamiskt generera ett större antal skuggor i geometriskt komplexa scener (till exempel datorspel). Implementationen skall sedan testas för att undersöka om algoritmen lever upp till förväntningarna. Utöver prestandan skall också dess generalitet och Examensarbete 1 4 februari 2004

12 Ljuskälla Blockerare Mottagare Penumbra Umbra Penumbra Skugga Figur 1: Illustration av de termer som används för att beskriva skuggor stabilitet diskuteras. Vidare skall möjliga plattformar fastslås. Slutligen skall den implementerade algoritmens möjligheter att utvecklas diskuteras. Främst är det då frågan om att förbättra dess prestanda och visuella resultat. 3 Grundläggande skuggrenderingstekniker 3.1 Vad är skuggor? Skuggor är ett fysikaliskt fenomen som uppstår i praktiskt taget alla miljöer där det finns en eller flera ljuskällor. På grund av att ljus endast kan färdas rakt fram och ej passera genom vissa typer av material, det vill säga sådana material som uppfattas som ogenomskinliga, kan ytor bestående av ogenomskinligt material hindra ljus från en ljuskälla att nå andra ytor. Givet en ljuskälla, L, och en punkt i världen, p, samt att det från p ej går att se någon del av L sägs då p vara i ljuskällans umbra. Då ljuskällor i verkligheten har utsträckning är det möjligt att det från p går att se delar av L i vilket fall p sägs vara i ljuskällans penumbra. Det område som utgörs av både umbra och penumbra sägs vara skugga[18]. Alla objekt i en miljö som mottar ljus sägs vara mottagare (eng. reciever). Vidare sägs alla objekt som hindrar ljus från att nå ett annat objekt vara blockerare (eng. occluder). Se figur 1 för en illustration av de termer som används för att beskriva skuggor. Det kommer att visa sig att det inom datorgrafik är viktigt att skilja mellan så kallade mjuka skuggor och hårda skuggor. Mjuka skuggor är de skuggor som beskrivs ovan och som finns i den verkliga värden. De uppstår då den ljuskälla som ger upphov till skuggan har en utsträckning vilket medför att ett penumbra skapas. Hårda skuggor erhålls då ljuskällan endast består av en oändligt liten punkt. Detta har till följd att hårda skuggor Examensarbete 2 4 februari 2004

13 Figur 2: Illustration av skuggors vikt för att avgöra objekts relativa position Figur 3: Skuggor framhäver mottagares geometri enbart har ett umbra och därmed har en väldigt abrupt övergång från ljus till skugga (därav namnet). 3.2 Varför skuggor i virtuella miljöer? Det faktum att skuggor är ett så vanligt fenomen gör att människan inte bara förväntar sig att de ska vara där utan också använder dem som referenspunkter för att skapa sig en bättre bild av omgivningen. Med andra ord har de inte enbart ett estetiskt värde utan är en viktig del för att trovärdiga virtuella miljöer som en användare på ett enkelt sätt kan navigera och verka i ska kunna skapas[18]. Först och främst använder människan skuggor för att avgöra objekts relativa position och storlek (se figur 2 för ett exempel på detta). För att uppnå detta krävs dock inte särskilt exakta skuggor utan det kan räcka med till exempel en mörkare cirkel under en modell av en människa för att det ska gå att avgöra dess position relativt ett underlag. Skuggor kan även ge så kallde ledtrådar (eng. cues) om en mottagares geometri (se figur 3) och även information om skymda blockerare eller delar av en blockerare som är skymda (se figur 4). I dessa fall är det viktigare att skuggorna är mer exakta. Examensarbete 3 4 februari 2004

14 Figur 4: Skugga ger information om ej direkt synliga delar av blockerare 3.3 Icke-realtids tekniker Rekursiv raytracing Raytracing är en, i grunden, förhållandevis enkel metod som kan användas för att generera projiceringar av tredimensionella scener. Algoritmen, som den beskrivs av Foley et al.[16], går ut på att, givet en projektionspunkt, skicka, för varje pixel i den bild som skall skapas, en så kallad stråle (eng. ray) ut från projektionspunkten, genom pixeln och ut i scenen. Färgen på pixeln beräknas genom att betrakta den närmaste punkt i vilken strålen skär ett objekt, det objektets diverse attribut (så som till exempel färg), ljuskällor och scenens andra egenskaper (så som dimma och liknande). Denna metod har vidareutvecklats till en rekursiv variant för att kunna hantera skuggor, reflektioner och brytningar (genom till exempel glas). Skuggor hanteras i denna algoritm genom att, för varje punkt på ett objekt där en stråle skär, skicka ut en ny stråle mot varje ljuskälla. Om en av dessa strålar skär ett annat objekt innan det når ljuskällan är punkten i skugga och ljuskällans påverkan ignoreras, annars tas ljuskällan in i beräkningen av pixelns färg. Förutom den extra skuggstrålen kan även reflektions- och brytningsstrålar skickas ut. Reflektionsstrålen beräknas med hjälp av strålens riktning och objektets normal i den punkt strålen skurit. Brytningsstrålen beräknas även den med hjälp av strålens riktning och objektets normal genom att använda Snells lag. För dessa strålar kan, när de eventuellt skär andra objekt, nya skugg-, reflektions- och brytningsstrålar skickas ut. Detta löses lämpligtvis på ett rekursivt sätt varför metoden kallas just rekursiv raytracing. För att slutligen beräkna en pixels färg tas alla bidrag från de rekursivt utskickade strålarna in tillsammans med det bidrag som den lokala beräkningen ger, det vill säga beräkningen som utfördes i den ursprungliga raytracingalgoritmen, och summeras. Denna metod ger mycket exakta och realistiska bilder vad gäller framförallt skuggor, reflektioner och brytning av ljus men är dock alldeles för Examensarbete 4 4 februari 2004

15 långsam för att vara ett alternativ för realtidsvisualisering Radiosity Trots att ett område är i skugga så är det sällan helt mörkt i verkligheten, även om bara en enda ljuskälla är närvarande. Detta beror på att ljuset reflekteras och bryts tills det slutligen också når områden som ljuset inte kan nå direkt. Detta är ett mycket komplext fenomen som ofta approximeras med ett så kallat omgivande ljus (eng. ambient light). Detta är ett riktnings- och positionslöst ljus som påverkar alla delar av en scen lika mycket, oberoende av hur mycket ljus som når en given punkt. Genom att välja en lämplig intensitet och färg på det omgivande ljuset går det att göra en uppskattning av de komplicerade reflektionerna och brytningar som i verkligheten ger upphov till detta fenomen. Denna uppskattning leder dock till att till exempel en belyst yta inte kan reflektera vidare ljus på en annan yta. Trots den rekursiva raytracingalgoritmens exakta skuggor, reflektion och brytning använder den dock den ovan beskrivna modellen för det omgivande ljuset. Det existerar dock en så kallad radiosity-modell som kan beräkna ljusets spridning på ett mycket mer korrekt sätt. Detta inkluderar även skuggor då dessa egentligen är ett resultat av att ljus reflekteras och inte når en given punkt direkt. Radiosity-modellen, enligt Foley et al.[16], bygger på att all energi som släpps ut i en scen i form av ljus bibehålls antingen genom att reflekteras eller absorberas. I praktiken delas en scens geometri upp i små delar, så kallade patches. Dessa patches är den minsta del på vilken beräkningar utförs vilket innebär att storleken på dem avgör hur detaljerade beräkningarna blir. Mindre (och därmed fler) patches innebär dock mer beräkningar. Ekvation 1 beskriver det samband som är själva kärnan i metoden. B i = E i + ρ i 1 j n B j F j i A j A i (1) B i och B j är radiosity för patch i och j, det vill säga den hastighet med vilken energi (både utstrålad och reflekterad sådan) lämnar en patch, E i är den hastighet med vilken patch i utstrålar energi och ρ i är reflektiviteten för patch i. F j i är den så kallade form faktorn (eng. form factor) vilken är den del energi av all energi som patch j utstrålar som når patch i. Slutligen är A j och A i arean av patch i respektive j. Detta skapar alltså ett ekvationssystem F B = E som skall lösas för B vilket kan göras med Gauss-Seidel iteration. Det existerar även metoder för att lösa radiosityekvationen genom iterativa förbättringar. Det senare är det vanligaste då det går att kontrollera hur exakt lösning som krävs och är möjlig att beräkna inom rimlig tid. Radiosity-metoden är en mycket kostsam metod rent beräkningsmässigt men eftersom endast ljussättning som är oberoende av kamerans position Examensarbete 5 4 februari 2004

16 beräknas går den dock att använda i realtidssammanhang genom att med den förberäkna ljussättning och skuggor genererade av statiska ljuskällor och statisk geometri. Denna information kan lagras i till exempel light maps vilka är enkla att rendera i realtid. 3.4 Skuggor i realtid Projective planar shadows En mycket enkel, och därmed mycket begränsad, algoritm för att rendera skuggor i realtid går ut på att, givet en blockerare och en plan yta på vilken skugga kommer att kastas, projeceras blockeraren ner på ytan. Detta ger snabbt och enkelt en exakt skugga. Problemet är dock att den yta på vilken skugga kastas måste vara plan. Även om det går att, för ett godtyckligt antal plana polygoner, projicera ner blockeraren på varje polygon och därmed skapa en korrekt skugga för en polygon-geometri skalar algoritmen inte särskilt bra då denna metod innebär att en blockerare måste projiceras (vilket egentligen innebär att den måste transformeras och renderas) för varje yta som mottar skugga. Dessutom måste de projicerade skuggorna klippas så att de inte hamnar utanför den polygon som de skuggar. Vidare klarar algoritmen endast av skarpa skuggor Shadow maps Williams[29] beskriver ett sätt att se på uppgiften att rendera skuggor som ett hidden surface removal -problem sett ur ljuskällans synvinkel. Med det menas att det går att se på problemet på så sätt att de punkter i en scen som inte går att se från ljuskällan ligger i skugga. Det är precis detta som ligger till grund för shadow maps-algoritmen. Givet en ljuskälla och en godtyckligt avancerad scen består algoritmen av två steg. I det första steget beräknas en djup-bild av scenen sett från ljuskällan. För att utföra denna beräkning används z-buffer-algoritmen[8]. Syftet med detta är alltså att avgöra avståndet från ljuskällan till alla de punkter i scenen som dess ljus faller på. I nästa steg renderas scenen från kamerans position. För varje pixel beräknas, enligt z-buffer-algoritmen, avståndet till den punkt i scenen som den visualiserar. Det existerar en linjär transformation som mappar en pixels koordinater i kamerans vy till koordinater i ljuskällans vy. Genom att utföra denna transformation för varje pixel och sedan jämföra avståndet från ljuskällan till punkten i scenen som skall renderas med motsvarande avstånd lagrat i z-buffern beräknad i det första steget går det att avgöra om punkten ligger i skugga eller ej. Med andra ord, om avståndet från ljuskällan till punkten i scenen som skall renderas är mindre än eller lika med motsvarande avstånd i ljuskällans z-buffer, ljussätts pixlen. I annat fall ligger den i skugga. Examensarbete 6 4 februari 2004

17 Figur 5: Ytor självskuggade av shadow map utan bias (från Williams[29]) Algoritmen har ett antal problem i det ovan beskrivna grundläggande utförandet. Till att börja med så skapar en dators ändliga precision ett problem som illustreras väldigt effektivt genom så kallade självskuggande ytor. När en punkt transformeras från kamerans vy till ljuskällans vy borde, om punkten är en del av en yta som skall ljussättas, avståndet från ljuskällan till den transformerade punkten vara detsamma som värdet lagrat i ljuskällans z-buffer. Dels på grund av att avståndet lagrat i ljuskällans z-buffer har ändlig precision och dels på grund av att transformation och all dess indata också baseras på ändlig precision kommer avstånden i normalfallet inte vara exakt desamma. Resultatet kommer istället bli att vissa punkter längs en ljussatt yta anses ligga framför det värde som finns i ljuskällans z-buffer, vilket innebär att dessa blir ljussatta, och andra kommer att anses ligga bakom och därmed skuggas av sig själva (varför problemet kallas för självskuggande ytor). I figur 5 visas det Moire-mönster av skuggade och ljussatta pixlar som är typiskt för detta problem. För att lösa problemet med de självskuggande ytorna införs en bias i transformationen från kamerans vy till ljuskällans vy. Denna bias gör avståndet från de transformerade punkterna till ljuskällan något mindre än det egentligen är. Resultatet av denna bias är att precisionsproblemen upphör eftersom avstånd som egentligen skall vara så nära varandra att problem uppstår blir något åtskilda. Denna lösning innebär dock att skugglinjen förflyttas något. Hur mycket beror på storleken på biasen. Ett annat problem algoritmen lider av är att kanten mellan ett område i skugga och ett ljussatt område kommer att vara mer eller mindre kantig (se figur 6). Detta beror på att upplösningen på ljuskällans z-buffer är ändlig och en kant mellan ett område i skugga och ett ljussatt område kan bara uppstå mellan två punkter i z-buffern. Genom att öka upplösningen på z- buffer minskas givetvis de artefakter som uppstår på grund av detta men de kommer aldrig att försvinna helt. Dessutom kan vissa extrema perspektiv (till exempel sådana som ger upphov till mycket långa skuggor) göra att dessa artefakter framträder tydligt även om upplösningen av z-buffern är Examensarbete 7 4 februari 2004

18 Figur 6: Aliasartefakter associerade med shadow map-algoritmen (från Everitt et al.[14]) mycket hög. Detta problem är inbyggt i den bildbaserade metod som shadow map-algoritmen är och har därmed ingen enkel lösning. Lösningar existerar dock och en sådan diskuteras i sektion Slutligen är det svårt att med algoritmen, som den är beskriven ovan, skapa punkt-ljuskällor, det vill säga ljuskällor som har en position men ingen riktning utan strålar ut lika mycket ljus åt alla håll. Anledningen till detta är att hela den volym som ljuskällan skall kasta ljus över måste renderas till en z-buffer. Detta innebär att desto större volym som skall täckas av ljuskällan, desto högre upplösning krävs på z-buffern för att mängden artefakter vid skuggkanterna inte skall öka. En ljuskälla med stor spridning kan dock skapas med shadow maps genom att beräkna flera z-buffrar per ljuskälla. Genom att inte låta de volymer som dessa z-buffrar representerar överlappa varandra men inte heller lämna tomrum emellan varandra går det att för varje pixel undersöka till vilken av ljuskällans z-buffrar som den skall transformeras och därmed beräkna om den skall ljussättas eller ej. Algoritmens stora fördel är att den inte stället något krav på vilken typ av geometri som kan vara blockerare. Den är med andra ord inte begränsad till, till exempel, polygoner utan klarar även av att korrekt beräkna skuggor till olika typer av parametriserade ytor. Vidare är algoritmen av linjär komplexitet vilket kommer från användadet av z-buffer-algoritmen som i sig har linjär komplexitet. Dock bygger algoritmen på att ljuskällan inte har någon volym vilket har till följd att endast skarpa skuggor kan genereras. Modifikationer och utvecklingar av algoritmen för att komma förbi denna begränsning existerar dock och några av dem beskrivs i sektion Examensarbete 8 4 februari 2004

19 L Figur 7: Skuggpolygon givet en konturkant och en ljuskälla Shadow volumes Shadow volumes-algoritmen beskriven av Crow[10] bygger på att skuggor kan ses som den volym av rymden de upptar. I just denna algoritm defineras denna volym av polygoner som innesluter den, så kallade skuggpolygoner. Givet en polygon-geometri och en punkt-ljuskälla defineras skuggpolygonerna med hjälp av objektets kontur, sett från ljuskällan, och ljuskällans position. Då geometrierna är polygonbaserade kommer konturen alltid att uppstå på en kant mellan två polygoner vilket innebär att en skuggpolygon kan defineras av en konturkant, de två kanter som går från ljuskällan genom de två ändarna på konturkanten och vidare tills de når något av planen som utgör vy-volymen (se figur 7). Själva konturkanten uppstår på en delad kant mellan en polygon som, sett ur ljuskällans vy, är framåtvänd och en polygon som, sett ur ljuskällans vy, är bakåtvänd. Det är viktigt att kunna skilja på vad som är skuggpolygonernas framoch baksida eftersom för att avgöra om en punkt är i skugga eller ej räknas antalet framåtvända skuggpolygoner (sett från kamerans vy) mot antalet bakåtvända skuggpolygoner. En framåtvänd skuggpolygon gör att allt bakom den hamnar i skugga, det vill säga allt bakom en framåtvänd skuggpolygon ligger i skuggans volym. En bakåtvänd polygon å andra sidan omvänder effekten av en framåtvänd polygon. Alla punkter i en scen där räkningen av framåtvända skuggpolygoner är positivt ligger alltså i skugga. Denna enkla algoritm har dock ett par specialfall som komplicerar det hela något. Till att börja med kan vy-punkten givetvis ligga inne i en skuggvolym. Detta innebär att den första skuggpolygon som påträffas kommer att vara en bakåtvänd sådan istället för en framåtvänd som är normalfallet. Lösningen på detta är att alltid se till att allt som ligger framför en bakåtvänd skuggpolygon och allt som ligger bakom en framåtvänd skuggpolygon alltid ligger i skugga. Vidare är det, till skillnad från shadow map-algoritmen, inga problem att skapa punkt-ljuskällor som strålar ut lika mycket ljus i alla riktningar. Nackdelar är att algoritmen endast klarar av polygonbaserade geometrier och att algoritmen, precis som i fallet med shadow maps, utgår från en ljuskälla utan volym och därmed skapar skarpa skuggor. Dessutom är algoritmens komplexitet svårbestämt och beror inte på en enda faktor. Examensarbete 9 4 februari 2004

20 Blockerarnas geometriska komplexitet är förstås en faktor men även den andel av en skuggvolym som vid ett givet tillfälle är synlig från vypunkten är ännu något som påverkar algoritmens prestanda. Då ytterligare faktorer också existerar kan det vara vanskligt att säga alltför mycket om algoritmens effektivitet för en given scen utan att göra faktiska tester. 4 Analys av moderna algoritmer för skuggor i realtid 4.1 Modern grafikhårdvara För att bättre kunna förstå hur vissa algoritmer fungerar och vad som är deras för- och nackdelar krävs grundläggande insikt i hur ett modert grafikkort arbetar. Det viktigaste är att ha en bild av hur geometridata i olika steg bearbetas för att skapa den slutgiltiga bilden. Figur 8 visar en schematisk bild av en typisk grafikpipelines olika steg (vissa detaljer skiljer sig åt mellan de olika grafik-apier som existerar). Det första som normalt sker med den geometridata som kommer in i pipelinen är att den transformeras från lokala modellkoordinater till projektionskoordinater. Detta transformationssteg går dock att förändra genom den möjlighet till vertexprogram som de senaste generationerna av grafikhårdvara erbjuder. Istället för de fördefinerade transformationerna kan ett mer eller mindre enkelt, av applikationsprogrammeraren skapat, program definera hur geometrins positioner, färger, normaler, texturkoordnater, etc skall beräknas. Utifrån utdatat från detta steg konstrueras nu primitiver (punkter, linjer, trianglar, etc) och dessa rasteriseras sedan. För varje pixel som rasteriseras utförs normalt ett antal operationer, så som textursampling, som i slutändan resulterar i den slugiltiga färgen på pixeln. På ett liknande sätt som för transformationssteget kan dessa fördefinerade operationer bytas ut mot ett, av applikationsprogrammeraren skapat, program. Detta program körs för varje pixel och kan utföra valfria beräkningar (inklusive textursamplingar) för att på ett godtyckligt sätt beräkna färgen på den pixel för vilket programmet körs. 4.2 Algoritmer för hårda skuggor Shadow maps i hårdvara. Shadow maps passar mycket bra för att skapa realtidsskuggor då algoritmen går att implementera på ett effektivt sätt med hjälp av funktioner som finns i dagens grafikhårdvara. Everitt et al.[14] beskriver en metod där de funktioner som krävs av grafikhårdvaran i det enklaste fallet är en z-buffer och texturmappning. Examensarbete 10 4 februari 2004

21 Geometridata Fix pipeline Värld, kamera och projektiontransformation Vertex blending Primitivkonstruktion Rasterisering Fix pipeline Per pixel operationer Framebuffer Programmerbar pipeline Vertexprogram Programmerbar pipeline Pixelprogram Texturminne Pixeldata Pixeloperationer Figur 8: Grafikpipeline Z-bufferten används, vilket beskrivs i sektion 3.4.2, för att skapa en djupbild sett från ljuskällan. Denna djupbild placeras sedan i en textur vilken projiceras på lämpligt vis på geometrin i scenen. När scenen slutligen renderas från kamerans vy jämförs varje pixels avstånd från ljuskällan med det värde på den texel som den mappar mot i den projicerade djupbilden. Det krävs alltså att hårdvaran erbjuder något sätt att utföra denna jämförelse. I OpenGL kan detta ådstakommas med hjälp av extensionerna ARB shadows, vilken ger möjligheten att utföra per-pixeljämförelsen mot djuptexturen, och ARB depth texture, vilken definerar ett speciellt texturformat för djuptexturen. Även i DirectX finns ett speciellt texturformat. Med hjälp av de operationer som finns för att kombinera texturer kan dessutom per-pixeljämförelsen mot djuptexturen göras med den i APIet inyggda funktionaliteten. Projektionen av djuptexturen kan utföras på ett par olika sätt vilka alla ger samma resultat. Ett sätt är att låta varje punkt på ett objekt i scenen få texturkoordinater (s, t, r, q) som motsvarar punktens position i scenen (x, y, z, w). Texturkoordinaterna transformeras sedan med hjälp av en texturmatrix T för att skapa den korrekta projektionen. T defineras enligt ekvation T = zbias P L (2) där L är den transformation som transformerar en punkt i världskoordinater till ljuskällans vy-koordinater och P är en projektionsmatris som projicerar alla punkter från kamera-koordinater till skärm-koordinater. Då skärmkoordinaterna (i OpenGL) är mellan 1.0 och 1.0 och värdena i djuptexturen mellan 0.0 och 1.0 måste den sista matrisen appliceras för att en meningsfull jämförelse skall kunna göras. Matrisen skalar först alla koordinater med faktorn 0.5 vilket innebär att värde ligger mellan 0.5 och 0.5. Vidare så utför den en translation som ger koordinaterna värden mellan 0.0 och 0.1 med Examensarbete 11 4 februari 2004

22 Figur 9: Högre kvalitet med aliasfri silhouette map-skugga (från Sen et al.[27]) undagtag för z-koordinaten där en bias införs i zbias. Denna bias krävs för att undvika fenomemet med självskuggande ytor (se sektion 3.4.2). Genom att använda ett texturfilter (till exempel GL LINEAR om OpenGL används) för att minska aliasartefakter som uppstår erhålls en mjuk kant på skuggan. Denna skall dock inte misstas för en ersättning för ett korrekt renderat penumbra utan har enbart effekten att aliasartefakterna minskar. Att kombinera shadow maps med mipmapping är dock inte möjligt eftersom mipmap-nivåerna eventuellt måste byggas upp vid varje bilduppdatering då scenen, och därmed ljussättningsförutsättningarna och ljuskällans z-buffer, kan ändras när som helst. Själva färgsättningen av de skuggade områdena kan implementeras med till exempel fragmetprogram/pixel shaders för att uppnå en effekt där enbart omgivande ljus finns kvar (alternativt lämna kvar lite diffust ljus för att inte tappa allt för mycket djupkänsla i skuggade områden) och inga specular highlights uppstår.. Genom att komplettera ljuskällans z-buffer med en så kallad silhouett map visar Sen et al[27] hur det möjligt att reducera de aliasartefakter som är associerade med shadow maps till noll (se figur 9). I silhouette mappen lagras information om var inom den givna texeln som skuggsiluetten egentligen går. Genom att sedan utnyttja denna information kan aliasfria skuggor renderas. Algoritmen består av tre steg. I det första steget renderas scenen från ljuskällan för att skapa en shadow map. Detta steg fungerar precis som motsvarande steg i shadow map-algoritmen. I det andra steget skapas silhouette mappen. Detta steg kräver, till skillnad från shadow map-algoritmen, infor- Examensarbete 12 4 februari 2004

23 mation om scenens geometri. Scenens siluetter extraheras genom att använda någon av de metoder som normalt används för detsamma inom shadow volumes (se sektion för en redogörelse av hur detta kan gå till) och denna information lagras sedan i silhouette mappen. Då algoritmen kräver information om scenens geometri anses denna algoritm vara en hybrid mellan shadow map- och shadow volumes-algoritmen. Silhouette mappen är förskjuten en halv pixel i vardera dimension vilket har effekten att texlarna i ljuskällans z-buffer motsvarar hörnen på texlarna i silhouette mappen. I det tredje steget används shadow mappen och silhouette mappen för att rendera scenen med skuggor. Detta går till som så att varje pixel som skall renderas transformeras till dess position i ljuskällans vy, på samma sätt som i shadow map-algoritmen. Jämförelser görs då med de fyra texlarna i ljuskällans z-buffer som motsvarar hörnen på texeln i silhouette mappen. Om alla dessa jämförelser ger att pixeln antingen är i skugga eller ljus renderas pixeln enligt resultatet. Om resultaten av de olika jämförelserna skiljer sig åt innebär detta att en siluett går genom silhouette map-texeln. Genereringen av silhouette mappen går till på så sätt att scenens siluetter rastereras som linjer till silhouette mappen. Genom att, för varje texel som dessa linjer skär, beräkna en punkt inom texeln som linjen går genom och lagra denna i texeln erhålls en komplett silhouette map. Då rasteriseringsalgoritmer för linjer normalt inte garanterar att alla pixlar som den matematiska linjen skär kommer att bli satta utförs detta steg genom att rasterisera en rektangel med en viss bredd istället. Vidare får inte siluetter som ej är synliga från ljuskällan rasteriseras till silhouette mappen. Genom att testa mot de fyra texlar i shadow mappen som motsvarar den aktuella texeln i silhouette mappen går det att avgöra om en siluett är synlig eller ej. Renderingen implementeras i hårdvara med hjälp av pixel shaders. Genom att först testa om en pixel är inom en silhouette map-texel som inte innehåller någon siluettpunkt och därmed är helt i skugga eller helt ljussatt avgörs de triviala fallen. Om silhouette map-texeln innehåller en punkt delas texeln upp i kvadranter så som i figur 10. Varje kvadrant anses vara i skugga eller ej baserat på huruvida det hörn på texeln som ligger inom kvadranten är i skugga eller ej. För att avgöra om pixeln skall renderas som skuggad eller ej beräknas alltså inom vilken kvadrant i texeln pixeln finns. Detta test utförs genom att dela upp varje kvadrant i två delar (se figur 10) och utföra enkla test på dessa trianglar. Vid väldigt avancerade scener överträffar algoritmens prestanda shadow volumes. Detta kräver dock så pass avancerade scener att det endast rör sig om bilduppdateringsfrekvenser under tio bilder per sekund på dagens konsumenthårdvara. I fall med mindre avancerade scener klarar algoritmen klart realtidskravet men är dock något sämre än både implementationer av shadow map- och shadow volumes-algoritmerna. En faktor som påverkar detta är att både shadow map och shadow volumes har ett bra stöd i hårdvara Examensarbete 13 4 februari 2004

24 Figur 10: Uppdelning vid silhouette map-jämförelse vilket inte riktigt är sant för silhouette maps Shadow volumes i hårdvara. En enkel metod som Heidmann[20] beskriver för att lägga över en del av arbetet beskrivet i sektion på grafikhårdvaran är att utnyttja stencilbufferten för att avgöra vilka områden i en scen som är i skugga och vilka som inte är det. Givet en uppsättning skuggpolygoner går det att avgöra om en pixel är i skugga eller inte genom att räkna antalet skuggpolygoner som passeras på väg till den punkt i scenen som pixeln motsvarar. För alla framåtvända skuggpolygoner som passeras adderas ett till summan och för alla bakåtvända subtraheras ett. Om resultatet är större än noll innebär detta att vi passerat fler framåtvända skuggpolygoner än bakåtvända och att pixeln är inom skuggvolymen. Om summan är noll innebär detta att antalet framåtvända och bakåtvända skuggpolygoner som passerats är detsamma och pixeln är inte i skugga. Då stencilbufferten kan utföra enkla operationer så som addition och subtraktion beroende på resultat vid till exempel z-buffer-jämförelser passar den utmärkt för att utföra den ovan beskriva räkningen. Först renderas scenen med enbart omgivande ljus. Syftet med detta är dels att rendera den skuggade delen av den slutgiltiga bilden och dels att fylla z-buffern med djupvärden för scenen. I nästa steg renderas de framåtvända skuggpolygonerna, dock enbart till stencilbufferten. Varken färg- eller z-bufferten förändras alltså men jämförelser med z-bufferten utförs dock. För varje punkt på en framåtvänd skuggpolygon som är synlig enligt z-buffertestet ökas värdet i stencilbufferten med ett. Givetvis måste dock stencilbuffertens värden nollställas innan detta steg kan utföras. I nästa steg renderas de bakåtvända skuggpolygonerna och värdena i stencilbufferten minskas. I det slutliga steget renderas scenen till färgbufferten, dock enbart till de pixlar där stencilbuffertens värde är noll. Examensarbete 14 4 februari 2004

25 P1 P3 P0 P1 P2... P2 P4 P0 Pn Figur 11: Punkter renderas till olika texlar baserat på id. Även om det innebär stora förtjänster att kunna använda stencilbufferten för att avgöra vilka pixlar som är skuggade och vilka som är ljussatta ligger fortfarande en stor del av arbetet i form av att hitta siluettkanter och beräkna skuggpolygoner på CPUn istället för på grafikhårdvaran. Detta har som konsekvens, utöver förlorad prestanda, att manipulationer av geometrin som utförs på grafikhårdvaran ej kommer att märkas i de beräknade skuggvolymerna om inte beräkningarna dupliceras på CPUn, vilket i sin tur leder till att artefakter och oegentligheter kan uppstå då samma beräkning på CPUn och grafikhårdvaran kan ge olika resultat. Detta innebär dessutom att beräkningar av siluettkanter och skuggvolymer måste utföras på olika sätt beroende på vilket typ av geometri som beräkningen utförs på. Genom att använda de programmerbara grafikpipelines som modern grafikhårdvara erbjuder är det dock möjligt att placera även dessa beräkningar på grafikhårdvaran med en metod som Brabec och Seidel[5] beskriver och därmed lösa dessa problem. Det krävs dock att geometrin genomgår en enkel preprocessing. Den första delen av algoritmen går ut på att att avgöra vilka kanter i en geometri som är siluettkanter. Denna del utförs i ett antal steg och det första steget är att lagra alla punkters världskoordinater på grafikkortet. Då denna information kommer att krävas i senare steg lagras den i en textur med hjälp av ett vertexprogram. Vidare måste varje punkt ha ett unikt id-nummer som tilldelas i preprocessingen. Punkterna skickas sedan till grafikhårdvaran tillsammans med dess id-nummer (som ett vertex-attribut). Vertex-programmet använder dessa id för att avgöra i vilken texel som varje punkt skall renderas (se figur 11). Färgvärdena på texlarna kodas för att lagra punkternas positioner i världskoordinater. Då grafikhårdvara transformerar alla punkter direkt till kamera-koordinater krävs att vy-transformationen sätts till identitetsmatrisen för att punkternas världskoordinater skall beräknas. I nästa steg för att hitta siluettkanterna renderas alla kanter, på liknande sätt som i föregående steg, som punkter till en textur. Detta kräver alltså att alla kanter, också de, har unika id-nummer. Dessa id-nummer kan, tillsammans med information om vilka trianglar som delar en given kant, beräknas i preprocessingen. För varje kant som skall renderas som en punkt skickas information om mellan vilka två punkter den går och information om de två punkter som utgör de tredje punkterna på de två trianglarna som delar Examensarbete 15 4 februari 2004

26 kanten med i form av id-nummer för de respektive punkterna. För varje kant kan sedan planekvationerna för de två trianglarna som delar kanten beräknas. Genom att räkna ut avståndet från de två planen till ljuskällan, och jämföra vilket tecken de två avstånden har, går det att säga om kanten är en siluettkant eller ej. Denna information kodas sedan ner som en flagga i texturen på en position som beräknas med hjälp av kantens id-nummer. Då detta steg kräver information om punkterna vilken finns lagrad i texturer måste detta steg implementeras i ett fragmentprogram. Den andra delen i algoritmen använder den information om punkterna och kanterna som beräknats i föregående del för att rendera skuggpolygonerna. Då vertexprogram inte kan skapa nya punkter utan enbart manipulera redan existerande sådana måste alla punkter som utgör skuggpolygonerna skickas från CPUn till grafikhårdvaran. Den information som algoritmen kräver om varje skuggpolygon är följande: Två index till punkterna som utgör start- och slutpunkt för den kant som denna skuggpolygon hör till. Ett index till informationen om kantens siluetteflagga. En flagga som avgör om punkten skall skjutas ut mot oändligheten eller ej. Varje skuggpolygon består alltså av fyra punkter varav två är kantens startoch slutpunkter. De två andra är punkter som skjuts ut mot oändligheten från ljuskällan. Vilka två detta är avgörs genom att sätta flaggan som skickas med på lämpligt vis. För att avgöra om en given skuggpolygon verkligen skall renderas undersöks först och främst kantens siluettflagga. Om kanten inte är en siluettkant finns det ingen anledning att rendera polygonen och punkten flyttas ut ur vy-volymen så att den klipps bort. Annars ges som utdata av vertexprogrammet antingen de världskoordinater som specificerats av punktens index eller en punkt i oändligheten som beräknas utifrån ljuskällans position. Det andra delen kan användas för att utföra de stencilbuffer-operationer som beskrivs i algoritmen ovan. Problemet med algoritmen är att beräkningen av skyggpolygonernas punkter givetvis måste utföras innan rasterisering och därmed måste implementeras som ett vertexprogram. Detta innebär dock att det inte är möjligt att komma åt den information om punkter och kanter som finns lagrad i texturer. Lösningen på detta är att ladda ner informationen till CPUn och skicka den direkt vidare till grafikhårdvaran i form av vertexattribut. På dagens grafikhårdvara med dagens vanliga grafik-apin (till exempel OpenGL och DirectX ) är det alltså inte möjligt att implementera denna algoritm för shadow volumes helt och hållet på grafikhårdvaran. För CPU-intensiva applikationer är det ändå ett bra alternativ då en stor del av arbetet ändock utförs av grafikhårdvaran istället för av CPUn. Examensarbete 16 4 februari 2004

27 I tester utförda med ett ATI Radeon 9700 kommer algoritmen upp i cirka 20 bilduppdateringar per sekund för en scen med tre ljuskällor och ett par tusen polygoner. Om vertexprogram skulle kunna läsa texturer skulle algoritmen dock snabbas upp väsentligt. Ett problem med metoder för att, med hjälp av stencil bufferten, implementera shadow volumes är att skuggpolygonerna kan klippas av de främre och det bakre klipp-planen om till exempel vy-punkten färdas in i en skuggvolym. Detta skapar områden där beräkningen av antalet framåtvända och bakåtvända skuggpolygoner som utförs med stencilbufferten inte stämmer vilket resulterar i en slutgiltig bild med områden som är felaktigt skuggade. Ett annat sätt man kan se på det hela är att stencilbufferten, för varje pixel, räknar antalet gånger en framåtvänd skuggpolygon passeras minus antalet gånger en bakåtvänd skuggpolygon passeras på vägen mellan vypunkten och den punkt i scenen pixlen representerar. Införs ett främre klipp-plan blir innebörden snarare att stencilbufferten räknar antalet passering mellan det främre klipp-planet och punkten pixeln representerar, i vilken problemet blir mer uppenbart. Lösningar[11] på detta problem har lagts fram men de är nästan alla svåra att implementera och förhållandevis instabila. Då den traditionella metoden är att öka eller minska stencilbufferten varje gång en pixel på en framåtvänd respektive bakåtvänd skuggpolygon är synlig enligt z-bufferten är det dock en viktig insikt som Carmack[7] kommer fram till att samma resultat kan erhållas genom att minska varje gång en framåtvänd skuggpolygon inte är synlig enligt z-bufferten och öka varje gång en bakåtvänd skuggpolygon inte är synlig. Utförs det hela i denna omvända ordning kan algoritmen beskrivas som att stencilbufferten räknar antalet antalet gånger en bakåtvänd skuggpolygon minus antalet gånger en framåtvänd skuggpolygon passeras på vägen mellan oändligheten och punkten i scenen pixeln representerar. I realiteten innebär detta dock att antalet passeringar räknas från det bakre klipp-planet och punkten i scenen. Detta innebär att till exempel problemet med att skuggorna blir felaktiva om vy-punkten färdas in i en skyggvolym försvinner då skuggorna beräknas från andra hållet. Genom att stänga den öppna änden på skuggvolymen innan det bortre klippplanet går det dessutom att se till att det aldrig uppstår situationer där något av klipp-planen klipper upp ett hål i skuggvolymen och skapar felaktiga skuggor. Denna metod går dessutom, enligt Everitt och Kilgard[12], att utöka och göra ännu stabilare genom att sätta avståndet till det bortre klipp-planet Examensarbete 17 4 februari 2004

28 till oändligheten. I OpenGL defineras perspektiv-projektionsmatrisen som P = 2 d near r l 0 r+l 0 2 d near t b r l 0 t+b t b 0 2 d far d near d far d near 0 0 d far+d near d far d near där d near och d far är avståndet till det närmre och det bortre klipp-planen, respektive, l, r, t och b är koordinaterna på det hitre klipp-planet som de vänstra, högra, övre och nedre klipp-planen, respektive, passerar. Genom att låta d far gå mot oändligheten erhålls en projektionsmatris på formen lim P = P inf = d far 2 d near r+l r l 0 r l 0 2 d 0 near t+b t b t b d near Används denna projektionsmatris och skuggpolygonerna skjuts med hjälp av homogena koordinater ut också de ända till oändligheten och volymens öppna ändar stängs erhålls en mycket stabil algoritm som alltid genererar korrekt renderade skuggor. Kraven för att detta skall fungera är dock att en perspektiv-projektion används då ett bortre klipp-plan inte går att erhålla med en ortografisk projektion. Vidare krävs att all geometri endast består av trianglar, är stängd och att rasteriseraren skapar vattentäta primitiver, det vill säga att inga pixlar sätts två gånger eller missas på kanter som delas mellan två trianglar. Givet en ljuskälla L består de stängda skuggvolymerna i denna algoritm av skuggpolygoner som går från siluettkanterna och bort från L till oändligheten, blockerarnas, från ljuskällans vy sett, framåtvända trianglar och blockerarnas, från ljuskällans vy sett, bakåtvända trianglar utskjutna till oändligheten. För en siluettkant som går mellan punkterna A och B består en skuggpolygon av de fyra punkter som beskrivs i ekvation 5. (3) (4) (B x, B y, B z, B w ) (A x, A y, A z, A w ) (A x L w L x A w, A y L w L y A w, A z L w L z A w, 0) (B x L w L x B w, B y L w L y B w, B z L w L z B w, 0) (5) Varje, från ljuskällans vy sett, bakåtvänd triangel skapar en skuggpolygon som stänger en del av skuggvolymens ände i oändligheten enligt ekvation 6 där A, B och C är de punkter trianglen består av. (A x L w L x A w, A y L w L y A w, A z L w L z A w, 0) (B x L w L x B w, B y L w L y B w, B z L w L z B w, 0) (C x L w L x C w, C y L w L y C w, C z L w L z C w, 0) (6) Examensarbete 18 4 februari 2004

29 För att stänga även den närmre delen av skyggvolymen skapas även en främre skuggpolygon för varje, från ljuskällans vy sett, framåtvänd triangel. Om triangeln består av punkterna A, B och C skapas den främre skuggpolygonen helt enkelt enligt ekvation 7. (A x, A y, A z, A w ) (B x, B y, B z, B w ) (C x, C y, C z, C w ) (7) För varje siluettekant renderas alltså de skuggpolygoner som genererats. Vidare renderas också de skuggpolygoner som genererats för varje blockerare för att stänga skuggvolymens ändar. Detta sker som vanligt i två omgångar. I den första renderas endast de, från vy-punkten sett, framåtvända skyggpolygonerna och för varje enligt z-buffern ej synlig punkt minskas stencilbuffertens värde. I det andra renderas de bakåtvända skuggpolygonerna och för varje ej synlig punkt ökas stencilbuffertens värde. Precis som i orginalalgoritmen för shadow volumes är då alla punkter där stencilbuffertens värde är skilt från noll i skugga.. Då det existerar hårdvara som inte har stöd för en stencilbuffer i hårdvara, till exempel Playstation 2, finns det behov att kunna rendera shadow volumes effektivt utan en stencilbuffer. Genom att antingen använda alpha-kanalen i den vanliga färg-bufferten är det möjligt att dels uppnå samma hårdvaruacceleration som stencilbufferten ger och dels möjligt att låta rendera skuggvolumerna med en lägre upplösning och därmed minska den tid grafikhårdvaran använder för att rasterisera skuggvolymerna[26]. Problemet har varit att det inte finns någon möjlighet till subtraktion på färgbufferten men genom att använda multiplikation och division för att dubbla respektive halvera värdet i alpha-kanalen varje gång en punkt på en framåtvänd respektive bakåtvänd är synlig går dock samma effekt att uppnå. 4.3 Algoritmer för mjuka skuggor Bild-baserade tekniker. Ett enkelt sätt att skapa mjuka skuggor som beskrivs av Heckbert och Herf[19][22]är att, givet en ljuskälla med utsträckning, välja ut ett antal punkter inom ljuskällans utsträckning och låta varje punkt agera som en ljuskälla utan utsträckning och därmed skapa skarpa skuggor med hjälp av shadow maps-algoritmen. Dessa skarpa skuggor kombineras sedan för att skapa illusionen av en enda mjuk skugga. Algoritmen kräver att blockerare och objekt som kommer att bli skuggade identifieras i förväg. För varje objekt som kommer att motta skugga beräknas en textur genom att för varje punkt på ljuskällan rendera en Examensarbete 19 4 februari 2004

30 Figur 12: För få hårda skuggor ger ej mjuk skugga binär blockeringsmap (eng. binary occlusionmap) där varje punkt har värdet 0 för blockeraren och 1 för alla andra objekt. Dessa blockeringsmappar kombineras så att varje punkt innehåller antalet punkter på ljuskällan som är blockerade. Denna kombinerade blockeringsmap läggs sedan in som en textur tillsammans med övriga, vanliga texturer och vanlig ljussättning när scenen renderas. Då blockeringsmapparna är oberoende av varandra och kan beräknas separat är denna algoritm lämplig att parallellisera. Algoritmens prestanda beror på antalet punkter på ljuskällan för vilka hårda skuggor renderas och på antalet objekt som mottar skugga. Vidare så beror prestandan i varje renderingspass på antalet polygoner i blockeraren. I praktiken gör detta att algoritmen enbart klarar av att kasta skugga på en enda plan polygon för realtids-kravet skall uppfyllas. Även om det går att minska antalet punkter på ljuskällan för vilka hårda skuggor renderas innebär detta att bildkvaliteten minskar då för få punkter innebär att den slutgiltiga bilden ser ut att bestå av flera hårda skuggor istället för en mjuk (se figur 12).. Genom att förändra ovanstående algoritm på så sätt att den enbart består av en enda map för en hel scen istället för en map för varje objekt på vilket skugga skall kastas går den att göra effektivare. I den utökade algoritmen av Agrawala et al.[1] består blockeringsmappen, eller den så kallade layered attenuation map, av flera lager som lagrar hur stor del av ljuskällan som når en viss punkt i scenen. Algoritmen består av ett steg där attenuation-mappen skapas genom att scenen renderas från varje punkt på ljuskällan i riktning med ljuskällans normal i punkten. De bilder som skapas från dessa punkter transformeras sedan till en gemensam referenspunkt, ljuskällans mittpunkt. För varje pixel i dessa bilder undersöks nu avståndet till de objekt som renderats i dem. Det objekt som är närmast utgör det första lagret och antalet punkter på ljuskällan som ser detta objekt räknas och utifrån detta går det att avgöra hur stor del av ljuskällan som är synlig för detta objekt. Om det från någon av punkterna på ljuskällan går att, för den aktuella pixeln, se ett annat Examensarbete 20 4 februari 2004