Tron Style OpenGL ES 2.0 Shaders för ios Möjligheten att implementera ett Bloomfilter på ett ios-device

Transkript

1 C3LOOPS Tron Style OpenGL ES 2.0 Shaders för ios Möjligheten att implementera ett Bloomfilter på ett ios-device Christoffer Tamm Kandidatexamensarbete inom Datavetenskap Mälardalens högskola, Västerås Handledare: Rikard Lindell Examinator: Thomas Larsson

2 Sammanfattning I denna rapport undersöks möjligheten att skapa ett bloomfilter med hjälp av OpenGL ES 2.0 som ska kunna användas i interaktiva applikationer. Då omfattningen av det här projektet visade sig vara väldigt stort gjordes ingen utvärdering av filtret på någon interaktiv applikation. Däremot visar undersökningar och analyser av andra applikationer att det borde vara fullt möjligt att skapa ett bloomfilter som är snabb nog att kunna användas i interaktiva applikationer på mobila enheter. Arbetet som framställs i denna rapport beskriver hur denna teknik kan användas. Den undersöker bakgrunden till bloomfiltret och varför den används för att skapa illusionen av att ett objekt på skärmen är ljusare än de andra trots att de kan ha samma färg och ljusintensitet. Det finns också en kort förklaring om varför det är en lämplig tidpunkt att göra detta nu och inte för 5 till 10 år sedan. 1

3 Abstract In this report the possibility of creating a bloom filter with help of OpenGL ES 2.0 for use in interactive applications is examined. As the scope of this project turned out to be very large there was no evaluation of the filter on any interactive application. However, studies and analyzes of other applications imply that it is fully possible to implement a bloom filter that is fast enough to be able to use in interactive applications on mobile devices. The work presented in this report describes how these techniques can be used. It will also research the background of the bloom filter and why it is being used to create the illusion that some objects are brighter than others even though they might have the same color and light intensity. There is also a short explanation to why it is a good time to do this work now and not 5 to10 years ago. The rest of the report is written in Swedish. 2

4 Förord Jag vill tacka min handledare Rikard Lindell för den hjälp och vägledning han gett mig genom det här projektet. Jag vill också tacka mina vänner och min familj som har hjälpt och stöttat mig genom de svåraste partierna i detta utdragna projekt. Ett stort tack till er alla. 3

5 Terminologi C3LOOPS: Rendering: Enpass rendering: Flerpass rendering: Shader: Porta: FBO: Viewport: Ett forskningsprojekt på MDH lett av Rikard Lindell. Den beräkning datorn gör för att skapa en bild eller animation utifrån en 3D-modell. Att rendera en bild en gång för att uppnå de effekter man vill ha och sedan vara klar. Att rendera en bild en gång och sedan påverka resultatet flera gånger för att uppnå de effekter man vill ha. Ett litet program som beskriver en del av grafikpipelinen. Konvertera ett program så att det fungerar på en annan plattform. Framebuffer Object, ett buffertobjekt för det som ska ritas ut på skärmen. En region av skärmen som ska visa upp hela eller delar av den renderade bilden. 4

6 Innehållsförteckning Sammanfattning... 1 Abstract... 2 Förord... 3 Terminologi Introduktion C3LOOPS Syfte och mål Syfte Mål Resultat Relaterad forskning och teknik Tidigare forskning Mobilteknikens utveckling OpenGL OpenGL ES Shaders Metod Arbetstekniken Uppdelningen av förstudien Uppdelningen av implementationen Förstudie Glow-shading Bloomfilter Slutsatser av förstudie Implementation Implementeringen av Bloomfiltret Rendera scen till textur Rendera textur till skärm Applicera Bloomfiltret Sammanställ resultat Diskussion Slutsatser Framtida möjligheter

7 8 Referenser

8 1 Introduktion Att använda filter för att åstadkomma effekter i bilder är inget nytt, bland annat så beskriver Spencer et al. [1] att man med ett visst filter kan skapa illusionen av att något lyser. Olika filter kan användas för att skapa olika effekter, denna rapport fokuserar på ett specifikt filter nämligen bloomfiltret [2]. Ett bloomfilter används när man vill skapa en illusion av att något i bilden lyser men där fokus inte ligger på att det ska se 100 % realistiskt ut utan snarare att det ska gå snabbt att rendera och ge ett tillräckligt bra resultat för att kunna lura ögat. Denna typ av filter används ofta inom interaktiva program och applikationer, som till exempel spel, när man vill att användaren ska uppleva något som lysande eller ljusare men inte har råd att använda de mer exakta metoder för det. I interaktiva program och applikationer är det viktigt för upplevelsen att svarstiden är snabb, det betyder att om användaren gör något så skall det inte kännas som att det är någon fördröjning innan det syns på skärmen. Andra mer exakta filter för att imitera ljus lämpar sig bättre för användning där det inte spelar någon större roll hur lång tid det tar att applicera filtret på en bild eller rendera bilden direkt med filtret. Detta stämmer bra in på animerade filmer eller filmer som använder sig av effekter som skapas av datorrenderade bilder där realism är viktigare än att det går snabbt att rendera. När en animerad film skapas så spelar det ingen större roll hur lång tid en bildruta tar att rendera då de inte ska visa direkt när de skapas utan senare sätts ihop till en film när alla bildrutor är klara. Dessutom brukar man ha tillgång till enorma mängder beräkningskraft då flera datorer kan jobba på olika bilder i filmen samtidigt. Själva arbetet i det här projektet gjordes under våren och sommaren C3LOOPS C3LOOPS är en applikation för att skapa musik genom att kombinera korta loopar och beats till något nytt och spännande. Applikationen har skapats med inspiration från citatet: Jag älskar att allt ligger överst. Detta märks tydligt då grafiska representationer av de små looparna kan ligga utspridda över hela skärmen huller om buller med varandra och de grafiska representationerna av de större looparna, så kallade sammansatta loopar. Sammansatta loopar är de loopar som användaren skapar genom att kombinera en eller flera mindre loopar och spela dem i synk med varandra och lätt kunna byta till andra kombinationer av loopar inom den sammansatta loopen. Meningen är att det ska vara enkelt och intuitivt att skapa en loop som låter bra. C3LOOPS körs främst på mobila enheter som använder ios, Apples operativsystem för mobila enheter. Med den utveckling som gjordes samtidigt som detta examensarbete utfördes så har C3LOOPS fått ett enkelt backup-system som sparar varje ändring som görs i en sammasatt loop. Detta gjorde att det blev enkelt att gå tillbaka till ett tidigare stadium i den sammansatta loopens utveckling om användaren inte gillade det som hänt med den sedan senaste ändringen. 7

9 2 Syfte och mål I den här sektionen förklaras syftet och målet med arbetet är, vad som ska åstadkommas och lite kort om vilka begräsningar som finns. Projektet kretsar runt C3LOOPS som bygger på en forskningsprototyp från avhandlingen Jag älska att allt ligger överst [3]. C3LOOPS är en applikation som bygger på ytinteraktion, det vill säga att applikationen presenterar sitt innehåll på en oändligt stor tvådimensionell yta. Zoom och panorering används för att navigera över ytan. 2.1 Syfte Syftet med det här projektet är att undersöka möjligheterna att skapa en illusion av att objekten på skärmen i C3LOOPS lyser, få dem att ge ifrån sig en glöd. Detta för att ge C3LOOPS ett snyggare och lite flashigare utseende som ska göra det lite roligare att jobba med. Även om önskan om att ge objekten en glöd är viktig så är det nästan viktigare att C3LOOPS inte förlorar sin interaktivitet när filtret används. Det är med andra ord viktigt att filtret som appliceras inte är för beräkningstungt. En annan del är att filtret ska vara implementerad med hjälp av OpenGL ES 2.0 för att det ska kunna fungera på den generation av mobila enheter som fanns när projektet påbörjades såväl som på kommande mobila enheter. 2.2 Mål Det första delmålet är att lyckas implementera ett filter som skapar en jämn och fin glöd runt ett objekt på skärmen. Detta utan interaktivitet för att kunna avgöra om ett sådant filter överhuvudtaget går att implementera på en mobil enhet som kör ios. Andra del målet är att göra applikationen som implementerar filtret interaktivt. Detta för att kunna testa hur mycket filtret påverkar svarstiden för applikationen. För att filtret ska gå att implementera i en interaktiv applikation får inte uppdateringshastigheten hos applikationen försämras så mycket att det blir en kännbar fördröjning mellan det att användaren gör något och att applikationen ritar ut resultatet av den handlingen. Tredje delmålet är att kunna implementera ett filter som skapar en jämn och fin glöd runt objekten på skärmen utan att påverka interaktiviteten hos C3LOOPS nämnvärt. Helst ska filtret som appliceras gå att flika in i den befintliga grafikmotorn i C3LOOPS utan att behöva göra några alltför stora omskrivningar av den befintliga koden. Detta för att det inte ska bli så stora skillnader som gör att det kan bli svårare att underhålla C3LOOPS med alla dess funktioner, inklusive grafikmotorn. När vi talar om att interaktivitet ska bibehållas så syftar det på att scenen bör kunna ritas ut ungefär 30 gånger per sekund som minst. Detta är baserat på att spel oftast körs i minst 30 FPS [4], frames per second(utritningar av scenen per sekund). Under 30 FPS så kan det upplevas som att spelet blir hackigt. Helst ska ett spel köras i 60 FPS eller mer, ju snabbare uppdateringsfrekvensen är desto mjukare upplevs rörelserna i spelet. Så för att ha en objektiv bedömning på hur vida C3LOOPS fortfarande är interaktivt så får inte filtret orsaka att uppdateringshastighet hamnar under 30 FPS. 8

10 2.3 Resultat Det gick att skapa ett filter, i ett testprojekt som bara ritade ut ett objekt på skärmen, som uppfyllde kraven för det första delmålet. På internet och i litteratur inom området finns många bra exempel att utgå ifrån. Andra delmålet var lite besvärligare att uppnå då det till en början märktes en tydlig fördröjning mellan det att användaren utförde en handling till det att applikationen tillhandahöll resultatet. Det tredje delmålet gick inte att uppnå då det visade sig att det skulle kräva ganska stora omskrivningar av C3LOOPS grafikmotor för att kunna implementera en mer optimerad version av filtret än den som användes i det andra delmålet. Eftersom testprojektet var väldigt enkelt i förhållande till C3LOOPS så hade filtret antagligen behövts optimeras för att bevara interaktiviteten. 9

11 3 Relaterad forskning och teknik Det här avsnittet kommer att handla om den forskning och teknik som är relaterad till det arbete som gjorts i och med detta examensarbete. Det har hänt mycket inom datorgrafik de senaste åren, speciellt inom grafiken för interaktiva applikationer och program. Detta kan ses särskilt tydligt om vi tittar på spelens utveckling, även om det mesta som har hänt beror på hårdvaruutvecklingen då teorierna och algoritmerna har funnits där sedan ganska lång tid tillbaka. 3.1 Tidigare forskning Det finns forskning från mitten på 1980-talet där olika metoder för att efterlikna människans uppfattning av ljus och ljuskällor tas upp. Olika algoritmer undersöks för att se vilken eller vilka som kommer närmast den mänskliga uppfattningen. Bland annat skrevs en publikation om ekvationen bakom rendering av bilder där ljus och dess reflektioner beter sig på ett realistiskt sätt [5]. Det som Kajiya kom fram till i avhandlingen var grunderna till vad vi idag kallar Ray Tracing och Path Tracing. Två metoder som går ut på att man skjuter ut strålar från betraktarens perspektiv in i bilden, sedan följer man strålarna när de reflekteras av objekten i bilden och letar sig sin väg mot ljuskällan. Detta för att återge belysningen och reflektionerna på ett realistiskt sätt. Då skärmar oftast har samma ljusstyrka över hela skärmen och bara färgen varierar mellan de olika pixlarna så är det svårt att förmedla vad som skall betraktas som starkt ljus. Det har gjorts forskning på hur man kan efterlikna hur den mänskliga upplevelsen av ljusa objekt i en datorrenderad bild med hjälp av olika filter. Bland annat har man studerat hur ögat uppfattar väldigt ljusa objekt i olika ljusförhållanden. Spencer et. al. [1] går igenom hur människan uppfattar ljusa objekt och de fenomen som kan återfinnas runt ljusa objekt. Det framgår att det sken som vi kan se stråla ut från väldigt ljusa objekt till stor del beror på ofullkomligheter i våra ögon. Ögonen klarar helt enkelt inte av de stora kontrasterna som kan uppstå. Spencer et. al. går också igenom de matematiska ekvationerna som visar på detta och tar fram algoritmer för att kunna återskapa dessa effekter runt väldigt ljusa objekt i olika ljusförhållanden. Algoritmerna kommer från sammanställningen av flera olika publikationer om det mänskliga ögat och olika försök till att beräkna effekterna som vi upplever runt ljusa objekt. Resultatet av det som Spencer et al. [1] kommer fram till ligger till grund för de algoritmer och filter som används idag för att realistiskt simulera ljus i datorrenderade bilder utan att använda Ray Tracing eller Path Tracing. Det finns andra mindre beräkningstunga metoder för att lura ögat att tro att det är ett självlysande objekt som renderas till bilden. En av de metoderna kallas för Gaussian Smoothing eller Gaussian Blur [6]. Denna metod går ut på att man med hjälp av en Bell Curve, normalfördelningskurva, utgår från en texel, texturens motsvarighet till pixel, och sprider ut färgen som finns i den texeln till de omkringliggande texelarna baserat på normalfördelningen. Resultatet av detta filter slås sedan ihop med originalbilden för att få en tillräckligt bra illusion av ljus som kan användas och renderas till skärmen. 10

12 ( ) ( ( ) ) Funktion 1: Gaussian funktion där A > 0, - B, C 0 och - D Figur 2: Normalfördelningskurva baserat på Funktion 1 där A=, B=0, C=1 och D=0 Med denna information så kan man få ut hur spridningen av färgen ska vara över till exempel fem texlar. Den mittersta texeln, den texel vars färg som ska spridas, ska, enligt grafen, ha 6/16:ar av färgintensiteten. Det motsvarar arean under funktionskurvan mellan x=-0,5 och x=0,5 vilket motsvarar den mittersta texeln. Det två närmaste pixlarna i vardera i både x-led och y-led får 4/16:ar av färgintensiteten, det representerar arean under funktionskurvan mellan antingen x=0,5 och x=1,5 eller x=-0,5 och x=-1,5. De yttersta texlarna får då 1/16 vardera av färgintensiteten. De ovan nämnda metoderna skapar illusionen av ett sken runt objekt som skall verka ge ifrån sig ljus i olika grad och i olika ljusförhållanden. Yoshida et al. har gjort en jämförande studie av Spencer et al.s metod, Point Spread Function (PSF), och en Gaussian Blur metod [7]. Där undersöker de vilken utav metoderna som skapar den kraftigaste illusionen av ljusstyrka från ett objekt till den lägsta beräkningskostnaden. Slutsatserna som Yoshida et al. drar är att, om renderat korrekt, så kan den effekt som åstadkoms av de båda metoderna göra att upplevelsen av ljusstyrkan förhöjs med 25-30%. Det framgår också att det inte är nödvändigt att imitera hur ögat fungerar för att åstadkomma detta utan går att göra på enklare och mindre beräkningstunga sätt. Gaussian filter kan effektivt användas för att skapa denna illusion till många aspekter bättre än den metod som Spencer et al. föreslår. Det framgår av Yoshida et al. att ett Gaussian filter skapar en minst lika stark eller starkare upplevd ljusstyrka än den upplevelse som förmedlas av PSF och går betydligt snabbare att rendera. Gaussian-filtret har dock en nackdel som gör att det inte lämpar sig för att realistiskt återge ljusstyrkan och det är att filtret har en tendens att påverka formen och storleken på det ljusemitterande objektet. Då detta inte brukar vara ett så stort problem då resultatet fortfarande ser 11

13 tillräckligt realistiskt ut så lämpar sig ett Gaussian filter alldeles ypperligt för interaktiva program. Det är också en utav anledningarna till att det används mycket inom spel där det är av stor vikt att en scen kan renderas så snabbt som möjligt. Gaussian filtret kan enligt Lönroth et. al. [8] användas till mer än att bara få objekt i scenen att se ljusa ut. Det kan också användas för att visa att objekt är ur fokus eller befinner sig långt bort. Detta för att styra betraktaren uppmärksamhet till en viss del av bilden. Filtret kan dessutom enligt Barsky et. al. [9] användas för att approximera färgen på dolda pixlar när man ska göra det som Lönroth et. al. beskriver i sin rapport. Med hjälp av detta kan man få mer precisa blur effekter på det som ska var ur fokus i bilden. 3.2 Mobilteknikens utveckling Utvecklingen av det vi kallar för mobiltelefoni startade redan på 1940-talet men det dröjde fram tills den integrerade kretsen kom på slutet av 1950-talet innan telefonerna kunde göras mer eller mindre portabla [10]. Under tiden som följde satsades stora resurser på att utveckla tekniken och 1973 kunde Motorolas vice VD, Martin Cooper, visa upp en portabel telefon som vägde nästan 800 gram på New Yorks gator. Vid den tidpunkten ska han ha förutspått att teknologin skulle gå att förminska ytterligare så att telefonen tillslut skulle få plats i bröstfickan. Det skulle dock dröja ytterligare tio år innan mobiltelefonen blev tillgänglig för allmänheten lanserade Motorola formellt sin telefon, DynaTAC 8000X. Den vägde cirka ett kilo och kostade nästan 4000 amerikanska dollar. Tack vare att såväl pris som vikt sjunkit har användandet av mobiltelefoner ökat explosionsartat sedan dess. I dag kan en mobiltelefonanvändare äga en telefon som normalt väger någonstans runt gram och har fler funktioner än att bara kunna ringa röstsamtal. Idag mer än någonsin är mobila enheter, såsom smarta mobiltelefoner(smartphones), en viktig del av unga personers vardag. Detta beskriver S. Kurkovsky i sin avhandling om hur den mobila kulturen vi har idag kan integreras i utbildningar inom datavetenskap och programmering [11]. Även om delen om hur man kan locka fler studenter till utbildningar inom datavetenskap och programmering inte är så intressant för detta arbete så innehåller rapporten mycket annan intressant information. Bland annat beskriver den att mobila enheter används till så gott som allt i vardagen bland unga personer. Att det gäller just unga personer beror på att de oftast representerar majoriteten av gruppen som kallas för early adopters, den grupp av personer som snabbast tar till sig ny teknik och börjar använda den. De mobila enheterna kan användas till att surfa på internet, spela spel, hålla sig uppdaterad om vad som händer i världen omkring en, uppdatera och läsa information från sociala medier, såsom Facebook och Twitter, eller göra bankärenden. Då mobila enheter har blivit så pass populära på senare tid finns det en marknad för små lätta applikationer, applikationer som inte kräver så mycket processorkraft. Även om en applikation är bra och fyller en funktion kan den vara tråkig eller i värsta fall omöjlig att använda om inte det grafiska gränssnittet är lätt att förstå och ser någorlunda bra ut. För att locka användare till en applikation från en annan applikation som har samma syfte krävs ett användarvänligt och snyggt gränssnitt. Detta gäller dock inte generellt för spel då de oftast är olika fast de fyller samma syfte nämligen underhållning, användargränssnittet bör dock fortfarande vara användarvänligt. 3.3 OpenGL OpenGL står för Open Graphics Library och är ett utav de mest använda API:erna för att skapa program som renderar 2D eller 3D grafik på datorer såsom till exempel PCs, arbetsstationer, med 12

14 mera. Det används mycket i program inom marknaderna för bland annat CAD (computer aided design), underhållning, tillverkning, spel utveckling och virtuell verklighet. OpenGL kan användas oberoende av vilket operativsystem som körs och underlättar för utvecklare att använda de senaste funktionerna på grafikhårdvaran [12]. OpenGL utvecklades i början på 1990-talet av Silicon Graphics för att skapa ett API som skulle gå att använda oberoende av vilken hårdvara som den kördes på. Idag så är det Khronos Group, ett ickevinstdrivande teknologikonsortium, som ansvarar för utvecklingen av OpenGL [13] [14] OpenGL ES OpenGL ES är en begränsad version av OpenGL och är skapat för att användas i inbyggda system som bland annat mobiltelefoner, konsoler och fordon [15]. Som sin storebror är OpenGL ES ett API för att rendera 2D och 3D grafik och är fritt att använda för att skapa applikationer med mer eller mindre avancerad grafik. OpenGL ES är anpassat för att kräva så lite minne som möjligt och är optimerat för att använda så få instruktioner som möjligt för att nå det önskade resultatet. Detta är angeläget för att dra så lite energi som möjligt, vilket är viktigt för mobila enheter som går på batteri. Det finns ett inbyggt stöd för att köra OpenGL ES både på dedikerad hårdvara för grafiken eller som mjukvarurutiner på CPUn [15]. Man kan även köra vissa delar som mjukvarurutiner och andra delar på den dedikerade hårdvaran. Detta gör att det blir enkelt för utvecklare som därmed inte behöver bli begränsade till den ena eller andra lösningen. Det betyder också att samma applikation kan utnyttja olika resurser på olika enheter. Om en enhet har väldigt kraftfulla grafikkretsar och inte har så stora begränsningar på energiåtgången kan applikationen använda hårvaruaccelererad grafik. På en annan enhet med större begränsningar på energikonsumtion och minimala grafikkretsar kan grafiken köras som mjukvarurutiner på CPUn istället Shaders Shaders är små program designade för att köras i en specifik del av renderingspipelinen, delen måste vara definierad som en programmerbar del i renderingspipelinen [16]. Shaders har en uppsättning av input- och output-variabler som de får från föregående steg och kan skicka vidare till nästa steg oavsett om det är programmeringsbart eller inte. Olika shaders är specialanpassade för olika steg i renderingspipelinen. De har sin egen uppsättning av interna variabler och anpassade uppsättningar av input och output. Även då alla shaders är skrivna med samma programmeringsspråk så har de olika distinkta uppgifter och kan bara passa in i en specifik del av renderingspipelinen. Shaderprogram kan kombineras ihop med andra shaderprogram för att skapa ett program som beskriver hela pipelinen. Nedan beskrivs de shadertyper som fanns vid tiden för undersökningen inför projektet, det har tillkommit flera shadertyper sedan dess och det går att få mer information om dem på OpenGLs wikisida på internet. 13

15 Figur 2 En förenklad version av OpenGLs renderingspipeline. De gröna områdena kommer att beskrivas i denna rapport. Bilden är inspirerad av bilden på OpenGLs wikisida för renderingspipelinen [17]. Under tessellationssteget bryts primitiverna ner till sina grundprimitiver, punkt, linje eller triangel. I klippningssteget tas de primitiver som ligger utanför kamerans synvinkel bort. Under rastreringsprocessen bryts primitiven ner i mindre element baserat på storleken av primitiven. I slutsteget görs de sista testerna som till exempel djuptest GLSL Programmeringsspråket som används i OpenGLs shaders är primärt OpenGL Shading Language, GLSL [18]. Det finns flera programmeringsspråk som går att använda tillsammans med OpenGL. GLSL är däremot det enda språket som är en del utav OpenGL-kärnan. GLSL är ett programmeringsspråk som liknar programmeringsspråket C och mycket av C-språkets funktionalitet återfinns i GLSL Vertex shader Vertex shadern, VS, är ett programmerbart shadersteg som ligger först i renderingspipelinen och hanterar bearbetningen av individuella noder, koordinater i en 2D eller 3D rymd som beskriver ett hörn av en primitiv(punkt, linje, triangel etcetera) [19]. VS introducerades i OpenGL 2.0. En VS har ett 1:1 förhållande mellan input och output, det vill säga att en nod kommer in och en nod skickas vidare till nästa steg i renderingspipelinen. Detta betyder att en VS bara kan bearbeta noder och inte skapa nya noder. Det vanligaste användningsområdet för en VS är att transformera noder från den interna världens koordinatsystem till skärmenskoordinatsystem som kommer att användas vid rendering av bilden. Det finns även andra användningsområden för en VS, bland annat så kan den användas för att ge en nod specifik ljussättning eller göra förberedande arbete för senare steg i renderingspipelinen. En VS tar en uppsättning av användardefinierade variabler, främst noder som beskriver scenen som ska renderas och matriser som används för att översätta nodernas koordinater till skärmkoordinater [20]. Man definierar inputvariablerna i shadern genom att skriva nyckelordet in innan variabeldeklarationen. De användardefinierade inputvariablerna tilldelas ett eller flera nodattributindex, dessa kan tilldelas på ett av tre sätt. Det första sättet är att man i VS definierar vilket index som en specifik variabel ska hämta sitt värde ifrån, detta görs genom att använda sig av nyckelordet Layout följt av ett nummer, inom parenteser, följt av definitionen av inputvariabeln. Den andra metoden är att man utanför shadern, innan det kombinerade shaderprogrammet som VS ingår i används, anger vilken inputvariabel som ska hämta sitt värde från vilket index. Den tredje metoden, som körs om ingen av de två ovan nämnda metoderna har använts, är att OpenGL självt tilldelar inputvariablerna till index. Om den senast nämnda metoden används kan värdena på variablerna skilja sig åt mellan olika körningar av olika sammansatta shaderprogram oavsett om det 14

16 är exakt samma VS kod som körs. Detta medför att det inte är en alltför pålitlig metod för att tilldela värden till inputvariablerna. Det är fullt möjligt att ha flera inputvariabler så länge deras nodattributindex inte krockar [20]. Vissa inputvariabler kan ta upp flera index, till exempel tar en matris upp ett index per kolumn i matrisen medan en nod bara tar upp ett index. Det finns dock en övre gräns på hur många inputvariabler som kan användas, ingen inputvariabel får sitt värde tilldelat från ett index som är större än GL_MAX_VERTEX_ATTRIBS. Outputen från VS skickas vidare till nästa definierade steg i renderingspipelinen [21]. VS har tre olika fördefinierade outputs som har olika användning. Den första är en koordinat med fyra komponenter (x, y, z, w) som anger positionen för den bearbetade noden. Nummer två definierar bredden och höjden, i pixlar(bildpunkter), och används endast när man renderar punktprimitiver. Den sista är en lista med ett värde för varje distans till ett av de plan som begränsar vad man kan se i scenen, de är positiva om den nod som skickades med ut ligger inom dessa begränsningsplan Geometry shader Geometry Shader, GS, introducerades i OpenGL 3.2 och befinner sig mellan Vertex shadern och Fragment shadern i renderingspipelinen [22]. GS är den shadertyp som styr behandlingen av primitiverna, de grundläggande geometriska formerna. Den tar in en primitiv som input och kan skicka ut noll eller flera primitiver som output. Den vanligaste användningen för en GS är om man vill rendera samma primitiv till flera olika mål utan att behöva byta renderingsmål ute i programmet som använder GS. Eller för att spara undan primitiverna som har genererats av Vertex shadern för att kunna återanvända dem flera gånger. En GS är lite speciell då en GS bara jobbar med endast en typ av primitiv som input och en typ av primitiv som output [23]. Typen av inputen måste stämma överens med typen av primitiv som används tillsammans med renderingskommandot, till exempel om man vill rendera trianglar kan GS bara använda sig av primitiver som är trianglar. En GS tar en primitiv som input där varje primitiv består av lika många noder som krävs för att beskriva primitiven [24]. Vilken typ av primitiv som används som input definieras på följande sätt: Layout(primitivtyp) in;. Då det föregående steget, i renderingspipelinen, inte skickar ut en primitiv så får en GS en lista av variabler som input. Antalet element i listan korresponderar med antalet noder som krävs för primitivtypen som används. Varje element i listan innehåller de värden som föregående steg hade som output. De inputs som är baserade på primitiver skickas inte som listor utan kommer in en i taget. GS kan ha hur många noder som önskas som outputs, upp till ett definierat maximum som definieras i shadern enligt följande: Layout(primitivtyp, max_vertices=antal) out [25]. När outputen ska skrivas måste först alla variabler ha värden tilldelade sedan kallas funktionen EmitVertex(), detta måste göras för varje nod i primitivtypen som används. Om flera primitiver skall användas som output så delas de upp genom att kalla på funktionen EndPrimitive(), efter att man kallat på EmitVertex() för varje nod i primitiven. Sedan upprepas denna procedur så många gånger som önskas. Om antalet noder i outputen skulle överstiga det definierade max antalet noder som är tillåtna i outputen så kommer de noder som överstiger det antalet gå förlorade, de kommer inte skickas vidare i 15

17 renderingspipelinen. Outputen görs per nod och innehåller samma data som Vertex Shadern skickar ut. Vid rendering av samma primitiv till olika renderingsmål finns ytterligare två outputs. Den ena är en heltalsvariabel som anger i vilket lager som primitiven ska renderas i, alla noder i primitiven måste ligga i samma lager. Den andra är också en heltalsvariabel som används för att ange vilket renderingsmål som skall användas. Denna kräver antingen att man använder OpenGL 4.1 eller har tillägget ARB_viewport_array, det är tekniskt sett en OpenGL 4.1 funktion men finns på de flesta hårdvaruplattformar som kan köra OpenGL Fragment shader En Fragment Shader, FS, arbetar med fragment av primitiver som kommer från rastreringssteget, som inte är programmeringsbart [26]. Rastreringen bryter ner primitiver i mindre fragment baserat på storleken på primitiven. Ett fragment innehåller en koordinat som beskriver vart den ska ritas ut tillsammans med de övriga värdena som de tidigare stegen har skickat ut tillsammans med varje nod. Precis som med Vertex Shadern så har FS ett 1:1 förhållande mellan input och output, ett fragment kommer in och ett fragment skickas ut. FS är den shader som färgsätter bilden och gör djuptester för att kunna avgöra vad som ska ritas ut och vad som ligger dolt bakom något annat. FS är unik i förhållande till andra shaders definierade i OpenGL då den har tillgång till de flesta textureringsfunktionerna [27]. Textureringsfunktionerna används när man vill rendera objekt där ytan täcks av en textur, en bild. Dessutom så har FS tillgång till kommandot discard som kastar bort det nuvarande fragmentet som då inte kommer att ritas ut på skärmen. Fragment kan även kastas bort om djuptestet misslyckas, det vill säga om ett annat fragment ligger framför det nuvarande fragmentet. FS har en uppsättning inputs som hämtas från de föregående stegen i renderingspipelinen [28]. De användardefinierade inputvariablerna måste definieras på exakt samma sätt som de var definierade i det senaste programmerbara steget i renderingspipelinen. De vanligaste inputvariablerna är en uppsättning koordinater som anger positionen för fragmentet i skärmkoordinater, ett booleskt värde som anger om det är fram eller baksidan utav primitiven som fragmentet avser och en punkt. Positionen för fragmentet består av fyra komponenter, X, Y, Z och W, där X, Y och Z beskriver vart på skärmen fragmentet ska ritas ut. Z skrivs till djupbufferten för att användas i djuptestet om inte FS skriver till gl_fragdepth då används det värdet. W är 1 delat på det interpolerade värdet av W hade i den interna världens koordinatsystem som skickades ut från det senaste programmerbara steget i renderingspipelinen. Normalt anges koordinaten i ett koordinatsystem där origo är definierat i det nedre vänstra hörnet i viewporten, detta går att påverka men är inte att rekommendera om det inte är absolut nödvändigt. Det är egentligen bara primitiver som trianglar som använder det booleska värdet då de kan ha både en fram och baksida. Värdet är falskt om det är baksidan som visas annars är det sant. Punkten används endast när man jobbar med primitivtypen punkt, punkten som skickades in håller koordinater som beskriver vart fragmentet befinner sig i förhållandet till sidan av primitiven. Det finns fler typer av input som inte behandlas här då de inte används i detta projekt. Som output har FS en eller flera användardefinierade färgbuffertar i den nuvarande framebufferten, en buffert för det som ska renderas till bilden oavsett om det är till en skärm eller en textur/bild [29]. FS skickar dessutom ut ett flyttalsvärde som definierar på vilket djup i bilden som fragmentet ligger. Det kan påverka huruvida fragmentet syns eller inte baserat på om det finns något annat fragment 16

18 som ligger framför det. Djupvärdet kan antingen skrivas manuellt eller så tilldelas det, som nämnts tidigare, från den inkomna positionens Z komponent. Färgerna som FS skickar ut kallas för fragment colors och är en vektor med fyra komponenter. Likt Vertex Shaderns input kan dessa färger tilldelas på ett av tre sätt. Det första sättet är att ange färgerna på är genom att i FS ange vilken färg som ska tilldelas vilken färgtyp genom att använda nyckelorden Layout och out. Om det första sättet inte används kan man tilldela färgerna innan man använder det sammansatta shaderprogrammet genom att kalla på glbindfragdatalocation(gluint program, GLunit colornumber, const char* name);. Där program är det sammansatta shaderprogrammet som använder FS, colornumber är den fragment color man vill tilldela variabeln och name är namnet på variabeln som ska bli tilldelad färgen. Det tredje sättet som används om inget av de två tidigare nämnda sätten används är en automatisk tilldelning som sätter godtyckliga värden på alla färger. Värdena kan skilja sig mellan olika sammansatta shaderprogram även om de kör samma FS. När alla outputs har fått sina värden och FS är klar med sin exekvering, tar nästa steg i renderingspipelinen vid och ritar ut resultatet. 17

19 4 Metod För att uppnå målen skall först en förstudie göras för att undersöka vilka lämpliga filtertekniker som finns tillgängliga och uppfyller kraven. Den lämpligaste filtertekniken väljs ut för implementation och empirisk mätning. Detta för att kunna undersöka huruvida det är praktiskt möjligt att skapa ett filter för de grafiska effekterna som efterfrågas. Mätningarna ska användas för att kunna avgöra om filtret är tillräckligt effektivt för att det inte ska påverka responsiviteten och interaktiviteten nämnvärt. 4.1 Arbetstekniken Under hela projektet jobbade jag enligt den agila tekniken Scrum [30] [31]. Scrum är en arbetsteknik som framförallt används av mjukvaruutvecklare. Tekniken bygger på att man jobbar i korta itterationer, så kallade sprinter, som kan vara allt från några dagar till en månad. För att veta vad som ska göras så tar man in önskemål från en så kallad produktägare, det är också produktägarens uppgift att prioritera önskemålen. Efter att produktägaren har prioriterat önskemålen så ska denne tillsammans med en Scrum master och i vissa fall utvecklarteamet planera vad som ska göras under en sprint. En Scrum master är den personen som överser utvecklingen och sköter kontakten mellan utvecklarteamet och produktägaren. Det är också Scrum masterns uppgift att se till så att utvecklarteamet vet vad de ska göra. Utvecklarteamet består av 3 eller flera personer och är personerna som sköter utvecklingen av själva mjukvaran. För att kunna avgör vad som ska göras måste först utvecklingsteamet uppskatta hur lång tid det kommer att ta att implementera de olika önskemålen och eventuellt bryta ned dem i mindre delar som är mer överskådliga. När det är gjort kan det hända att produktägaren vill prioritera om vissa utav önskemålen om det visar sig att vissa viktiga punkter inte kommer att hinnas med i denna sprint. Under sprintens gång hålls dagliga möten för att alla i utvecklarteamet och Scrum mastern ska hållas uppdaterade om hur det går. Dessa möten ska vara väldigt korta, max 15 minuter långa. I slutet av varje sprint ska alla de funktioner som har utvecklats under sprinten gå att använda och visas upp i en demonstration. Eftersom jag jobbade ensam i projektet så passade det inte alla delar av Scrum så bra, till exempel så var det inte praktiskt att ha dagliga möten med mig själv. Däremot passade det bra att jobba iterativt då jag hade veckovisa möten med min handledare, som också på sätt och vis agerade som produktägare. Det var min handledare som försåg mig med önskemål om vad som skulle göras och en enkel prioritering utav dem. Jag tog sedan hand om att dela upp de olika önskemålen i mindre delar så att det var lättare att få en klar bild över vad som behövde göras. Under hela processen försökte jag alltid ha något att visa upp eller ny information om hur utvecklingen fortlöpte till veckomötena Uppdelningen av förstudien Det högst prioriterade önskemålet var att ta reda på om det överhuvudtaget var möjligt att göra det som efterfrågades. För att det skulle bli enklare att definiera när detta var uppnått delade jag upp önskemålet i fyra delar. Första steget blev att undersöka om det fanns något sätt att åstadkomma det som önskades. Andra steget var, om nu första steget gav ett positivt resultat, söka reda på så många olika tekniker som möjligt för att ha en så bred grund som möjligt att starta ifrån. Tredje steget vara att undersöka vilka krav de olika teknikerna hade på både mjukvaran och hårdvaran för 18

20 att sålla bort de tekniker som inte gick att implementera med de begränsningar som fanns. Det sista steget var att fördjupa sig i den teknik som verkade mest lovande och gå igenom den grundligt för att kunna avgöra om det var möjligt att integrera den med C3LOOPS Uppdelningen av implementationen Det andra önskemålet handlade om att göra en implementation av den valda tekniken från förstudien i C3LOOPS eller åtminstone skapa en implementation som senare skulle kunna integreras i C3LOOPS. Här valde jag att dela upp önskemålet i många små delar för att ge en mer överskådlig bild av arbetet jag hade framför mig. Första prioriteten blev att skapa ett testprojekt som jag kunde lägga allt fokus på grafiken och få den att fungera som det var tänkt. Nästa steg blev att försöka efterlikna hur grafiken i C3LOOPS renderades. Tredje steget var att implementera de delar som skulle skapa de grafiska effekterna som efterfrågades ett steg i taget för att sedan slå samman de olika stegen för att skapa det slutliga resultatet. Sist men inte minst skulle sedan den lösning jag implementerat i mitt testprojekt lyftas över i C3LOOPS, detta skulle göras i två steg. Det första steget var att undersöka vart jag skulle kunna kapa renderingen för att kunna kila in min kod. Andra steget skulle vara att faktiskt inkorporera min implementation i C3LOOPS renderingsprocess. 19

21 5 Förstudie Det önskade resultatet var att få utseendet på den slutgiltiga produkten att vara Tron-inspirerat. Tron är en film där många starka färger (färger som upplevs ljusa/starka för det mänskliga ögat) får en glöd. Då Tron-glöd kan vara en vag förklaring på vad som skulle uppnås blev det viktigt att ta reda på tre saker: Vad är Tron-glöd?, Hur manifesterar sig den? och Vilka är de viktigaste komponenterna?. Tron-glöd är den glöd som är så typiskt för Tron filmerna och spelen, den visar sig som ett flödande ljus som kommer från intensiva färger och ljuset ska mjukt tona ut. Bland de viktigaste elementen i Tron-glöd är att endast starka färger får glöd, att glöden inte slutar abrupt och pixlarna inte framstår tydligt. Det finns i huvudsak två olika metoder för att uppnå det önskade resultatet. Den ena använder sig av alla tre typer av shaders, nämnda tidigare, för att skapa en Tron-inspirerad glöd. Låt oss kalla denna metod för Glow-shading. Den andra metoden använder två av shader-typerna för att skapa den Tron-inspirerade glöd som efterfrågas. Denna metod går ut på att man applicerar ett bloomfilter på bilden. Enligt [2]används denna teknik bland annat för att göra illusionen av ljus verkligare genom att ge ljuskällor en glöd. 5.1 Glow-shading Glow-shading är en relativt ny metod för att skapa en glöd. Metoden bygger på att, med hjälp av en Geometry Shader, skapa sex nya noder som bildar ett rätblock runt ett linjesegment [32]. Sedan skickas all information till Fragment Shadern, där görs en point-to-line beräkning. Med de värden som Fragment Shadern beräknat så bestäms hur stark färgen ska vara en viss distans från linjesegmentet. Renderingstiden för denna metod varierar beroende hur många linjesegment som ska få glöd. Denna metod är enkel att implementera men kräver att man tänker på vad som renderas och hur det renderas. Den kräver också stöd för OpenGL 3.0 eller senare för att kunna använda Geometry Shadern 5.2 Bloomfilter Att använda ett bloomfilter är en relativt gammal metod för att skapa en glöd. Den här metoden skiljer sig markant från Glow-shading, bland annat använder sig inte denna metod av en Geometry Shader. Metoden använder sig av flera steg som skapar olika effekter på olika texturer som till sist slås samman för att uppnå en glöd i det slutgiltiga resultatet [6]. Första steget är att rendera in en scen till en textur. När scenen är renderad till en textur plockas de områden som ska få glöd ut med hjälp av ett och High-passfilter och renderas till en ny textur. I nästa steg körs en Downsampler i flera omgångar och sparar resultaten i nya texturer, det är det föregående resultatet som blir input till nästa omgång. Härifrån finns två olika metoder att använda. Det första alternativet är att skapa glöden i alla riktningar, horisontellt och Figur 3 Exempel på hur en fylld cirkel kan se ut före och efter ett bloomfilter har applicerats. Den högra bilden visar en fylld cirkel innan ett bloomfilter har applicerats. Den vänstra bilden visar samma fyllda cirkel efter ett bloomfilter har applicerats. vertikalt, samtidigt. Det andra alternativet är att först skapa den horisontella glöden och sedan den 20