Användarutvärdering av aspekter inom datorbaserad realtidssnö: När bedömningen är subjektiv

Sammanfattning

Arbetets mål är att undersöka vilka snöaspekter en användare föredrar i ett bilspel med realtidssimulerad snö. Bakgrunden går igenom och förklarar begrepp inom området snö i datorgrafik. Tidigare artiklar inom liknande områden diskuteras och används även som bakgrund för snömetoder som tas upp i samma del. Efter bakgrundsdelen kommer problemformulering samt metodbeskrivningsdelen, som börjar med att arbetets problemformulering presenteras och förklaras. Det uttrycks hur tidigare artiklar inte utvärderat användares uppfattning av snö, vilket detta arbete då tar sig an att besvara.

Metodbeskrivningen förklarar tillvägagångssättet som arbetet använder för att besvara frågeställningen. Flera versioner av ett enklare bilspel skapas där varje version använder olika inställningar av tidigare nämnda snömetoder. Dessa versioner bedöms av testare för att förstå påverkan av de olika snöinställningarna. Följande del ​Implementation går igenom skapandeprocessen för spelet och de beslut som tagits under dess utveckling. Efter detta analyseras insamlad data från utförda test och slutsatser kring problemformuleringen dras.

En slutlig utvärderingsdel sammanfattar och diskuterar sedan arbetet i helhet utifrån olika synvinklar.

Nyckelord: ​Datorgrafik, Snö, Bilspel

Innehållsförteckning

1 Introduktio ​n 1

2 Bakgrund 2

2.1 Historik datorgrafik ​ inom spel 2

2.2 Hur grafik påverkar användarupplevelsen i spel 3

2.3 Realistisk grafikstil 3

2.4 Kategorisering av tekniker 3

2.5 Relatera ​de arbeten 4

2.6 Implementation av metoder 5

2.7 Liknande undersökning 6

3 Problemformulering 8

3.1 Metodbeskrivning 8

3.1.1 Beskrivning av spelet 9

3.1.2 Parametrar 9

3.2 Undersökning 1 ​2

3.2.1 ​Att ställa frågor 12

3.2.2 Diskussion kring val av undersökningsmetod 12

3.2.3 Genomförande av undersökningen 14

3.3 ​Utvärdering 15

3.3.1 ​Statistisk signifikans, medelvärde och standardavvikelse 15

3.3.2 ​Regressionsanalys 15

4 Implementation 17

4.1 Grunderna 17

4.1.1 Marken 17

4.1.2 Bilen 21

4.2 Spelmekanik 24

4.2.1 Kamerasystemet 24

4.2.2 Checkpoint-systemet 26

4.3 Snö 26

4.3.1 Occlusion-metoden 26

4.3.2 Fallande snö 31

4.3.3 Bilens avtryck 32

4.4 Spelvärlden 35

4.5 Parametrar 36

4.5.1 ​Genomförande av testen 38

5 ​ ​Utvärdering 41

5 ​.1 ​Presentation av undersökning 41

5 ​.1.1 ​Övriga kommentarer 44

5 ​.2 ​Analys av resultatet i förhållande till frågeställning 45 5 ​.2.1 ​Analys av snöspårens påverkan på upplevelsen 45 5 ​.2.2 ​Analys av snödjupet och snöfallets påverkan på upplevelsen 47

5 ​.2.3 ​Analys av FPS påverkan på upplevelsen 49

5 ​.3 ​Slutsatser 50

6 ​ ​Avslutande diskussion 52

6 ​.1 ​Sammanfattning 52

6 ​.2 ​Diskussion 52

6 ​.2.1 ​Parametrar 52

6 ​.2.2 ​Otydligt resultat 53

6 ​.2.3 ​Arbetets nytta 54

6 ​.3 ​Fortsatt arbete 54

6 ​.3.1 ​Hur arbetets undersökningsmetod kan användas i andra sammanhang 55

​ ​Referenser 57

1 Introduktion

Datorer använder datorgrafik för att skapa bilder i olika syften, exempelvis filmskapande, datorspel eller reklam (Wikipedia, 2020a). Bland de många fördelar med datorer över traditionella bildskapande metoder finns en begränsning inom datorgrafik: illustrering av verkligheten. Enligt Andrews (2013) ligger problemet i prestanda och optimeringar som leder till icke-realistiska kompromisser.

Den realistiska grafikstilen enligt Keo (2017) har som mål att skapa grafik som liknar verkligheten, vilket är krävande både när det gäller prestanda och arbetsinsats. Därmed är det av intresse att veta vilka delar av grafiken som bör prioriteras. Detta arbete behandlar snögrafik, för vilket det finns många olika metoder för dess skapande. Detta arbete har implementerat några metoder för skapandet av snögrafik, med målet att undersöka hur dessa påverkar en användares upplevelse av vackerhet samt realism när denna spelar ett enkelt 3D-spel.

Ett enkelt 3D-spel i genren bilspel utvecklades för att användas som utvärderingsplattform för olika typer av implementerad snögrafik. Dessa typer av snögrafik inspirerades av tidigare utvecklade metoder och påverkar snö på marken samt fallande snö. Ett enda program hanterar både genomspelning av alla spelets versioner samt besvarande av frågor för att hålla användarupplevelsen enkel.

En kvantitativ undersökning på en grupp respondenter genomfördes. Respondenterna spelade igenom olika versioner av spelet, där versionerna skiljer i inställningar av de olika snögrafikdelarna. Under en spelsession besvarade respondenterna frågor med hjälp av en 1-till-5-skala. Frågorna behandlade respondenternas uppfattning av versionernas realism samt vackerhet.

Analysen av datan används för en diskussion där påverkan av olika faktorer tas upp och hur dessa kan undersökas i ett framtida arbete. Slutligen diskuteras hur arbetets undersökningsmetod kan användas för att undersöka hur andra faktorer än snö kan påverka upplevelsen i spel.

1

2 Bakgrund

I denna del redovisas hur datorgrafik historiskt använts i datorspel. Därefter presenteras hur datorgrafik påverkar användarupplevelsen och vad som är utmärkande för den kategori av datorgrafik som försöker efterlikna verkligheten: realistisk grafikstil. Vidare beskrivs hur realistisk snö kan representeras med hjälp av datorgrafik och tekniska metoder för dess implementation kategoriseras och presenteras.

2.1 Historik datorgrafik inom spel

Sedan dess början har datorgrafik använts för att ge spelare en djupare inlevelse i en simulerad situation, som ofta har knytningar till verkliga fenomen (Therrien, 2008). Vissa spel använder grafik som efterliknar verkligheten för att uppnå ett realistiskt utseende. Andra spel undviker realism utan bygger istället en egen grafisk stil som inte behöver vara baserad på något ​verkligt fenomen (Keo, 2017). På detta sätt kan ett spel som ser snyggt ut skapas utan begränsningen av realism.

Allt eftersom hårdvaran och grafikalgoritmer har utvecklats har grafiken i spelen blivit allt mer sofistikerad. Tidiga spel som OXO (1952) hade mycket begränsad grafik. På slutet av 50-talet hade spel som Tennis-For-Two (1958) och Spacewar (1962) uppnått grafik där en enkel modell kunde renderas vilket var ett steg närmare realism (Computer History Museum, 2020).

På tidigt 70-tal utvecklades skuggningsalgoritmer ( ​shaders ​ ) som Gouraud Shading och Phong Shading vilket gjorde det möjligt att rendera objekt mer realistisk än vad den tidigare flat shading-algoritmen tillät. Dessa nya algoritmer var mer beräkningskrävande än tidigare algoritmer vilket begränsade deras användning, särskilt realistisk grafik med hjälp av Phong Shading. Allt eftersom mer kraftfulla processorer har utvecklats har dock Phong Shading blivit standard i modern grafik. År 1980 utvecklades strålföljning ( ​raytracing ​ ) vilket är datorgrafikens nästa steg för att uppnå mer realistisk skuggning. Denna metod är ännu mer beräkningskrävande än tidigare metoder, men ger ett mer realistiskt resultat då skuggor inte längre behöver approximeras utan beräknas som om de var ett resultat av faktiska ljusstrålar (Spina, 2012).

De senaste 15 åren har den exponentiella ökningen för beräkningshastighet minskat (National Research Council, ss. 156, 2011). Denna minskning beror på skillnader i prestanda mellan olika delar i en dator, främst minnets förmåga att snabbt hantera dess lagrade information (National Research Council, ss. 53, 2011).

Beräkningshastighet är ett sätt att mäta prestanda, men det berättar inte allt. Pre ​standa bör istället mätas på ett sätt som är relevant till den uppgift datorn förväntas utföra ​(​National Research Council ​, ss. 155, 2011)​. Inom datorspel mäts oftast prestanda i bilder per sekund eller frames per second (FPS). Hög FPS är bra då rörelse visas på skärmen annars kan rörelsen upplevas som hackig. Hög FPS är även viktig för användarens upplevda

2

responsivitet av datorn, då användarens input kan uppdatera skärmen snabbare vid högre FPS ​(Klappenbach, 2019)​.

2.2 Hur grafik påverkar användarupplevelsen i spel

Användarupplevelsen i spel syftar på de upplevda känslor ett spel förmedlar. Att grafiken påverkar användarupplevelsen kan ses då olika grafiska stilar över tid har utvecklats och applicerats på spel med liknande spelmekanik (Keo, 2017). Ett exempel på detta är spelen Overwatch (2016) och Battlefield 1 (2016). Båda spelen beskrivs som lagbaserade förstapersonskjutare, där Overwatch har en stiliserad grafikstil, medan Battlefield 1 strävar efter att få grafiken att se realistisk ut. Grafiken för ett spel är också viktig för dess marknadsföring då konsumentens första intryck ofta baseras på det den ser, vilket i sin tur påverkar spelets framgång (Keo, 2017).

Snögrafik utgör en viktig del i vissa spel och då inte alltid enbart för den visuella upplevelsen.

I spelet ​The Last of Us (2013) kan fiender följa efter spelarens fotsteg som lämnas i snön, medans snöfall kan begränsa fiendens sikt. I spelet ​Breath of the Wild (2017) utgör temperatur en viktig del av spelmekaniken och snö påvisar områden där temperaturen är låg.

En annan mekanik i Breath of the Wild är möjligheten att åka snowboard på snö för att snabbt ta sig fram, vilket även kan göras på annan terräng. Dock har snö lägre friktion och orsakar mindre skada på föremålet som används som snowboard (Stevens, 2017).

2.3 Realistisk grafikstil

Keo (2017) beskriver att den realistiska grafikstilen eftersträvar att få karaktärer, objekt, miljön och idealt hela spelvärlden att likna verkligheten till så stor del som möjligt. Denna stil beskrivs som mycket hårdvarukrävande och passar enbart för vissa spelgenrer, som racingspel. Dessutom krävs det mycket arbete från utvecklare för att skapa realistisk grafik.

Realism i spelgrafik kan definieras utifrån fyra faktorer, antal polygoner (där flera är mer realistiskt), texturupplösning (där högre upplösning är mer realistisk), belysning samt animationer (Concept Art House, 2015). Kombinationer av dessa kan i slutändan ge åskådaren en uppfattning av att det som grafiken föreställer är realistiskt. Denna bedömning är helt subjektiv och gränsen för vad som är realistiskt eller inte förändras i takt med att datorgrafik utvecklas mot det bättre.

2.4 Kategorisering av tekniker

I förhållande till prestanda finns två kategorier för skapandet av grafisk snö där den ena prioriterar realtidsexekvering och därmed försöker hålla prestandakostnaden låg, medan den andra fokuserar på verklighetstrogen snö oberoende av prestandakostnad. Realtidstekniker är de som används i spel, där tid för uträkning per individuell bildruta är kritiskt. ​Haglund, Andersson & Hast (2002) sammanfattar realtidssimulering väl: ​“Since speed is crucial for a real time rendering, we chose to make a fast approximation.“ ​Ohlsson & Seipel (2004) uttrycker tydligt att målet med realtidssimulering är högre FPS genom att i sin analys använda datan ​“an average frame rate of 13 frames per second were achieved.”.

3

Den andra kategorin, vilket här kallas för simulering, är fokuserad på fysiskt realistisk simulering av snö. Denna kategori används främst inom film / datavetenskap och kräver mycket mer exekveringsprestanda än en realtidslösning. “...our approach required on average only 21.1 s per frame, even including the snow mist computation times.” ( ​Dagenais, Gagnon

& Paquette, 2016) ​. Denna lösning är inte lämpad för realtidsexekvering då antalet FPS är lågt, vilket en användare skulle uppfatta som icke-responsivt enligt del av Henrikssons (2014) studie.

2.5 Relaterade arbeten

För realtidssimulering av snö är en vanlig metod att förrendera så mycket grafik som möjligt innan simuleringen körs. Detta görs för att minska mängden uträkningar som behöver ske under simuleringens gång, vilket är nödvändigt då realtidsaspekten också behöver processorkraft. Nackdelen med förrendering är att snön inte kan påverkas under simulationens gång, den förblir därmed statisk (Reynolds, Laycock & Day, 2014). Från undersökning av området fanns två huvudmetoder för realtidssimulering, den ena metoden är att använda en förgenererad ​mesh för att representera placering av snö, den andra är att använda en ​texture map kombinerat med en ​occlusion map som avgör vart och hur snö ska renderas av en shader.

Ohlsson & Seipel (2004) använder en per-pixel-metod, som liknar den som används för per-pixel skuggning i vanlig datorgrafik. För att bestämma hur mycket snö ett område skall ha, används en djupbuffert. Metoden är uppdelad i att först bestämma vart snö ska hamna, för att sedan rendera snön. Hänsyn tas till gravitationen, vilket innebär att en lutande yta kommer få mindre snö än en horisontell yta och ytor som täcks av andra ytor kommer inte få snö. En brusfunktion används för att ge mer varierat utseende på snöytan genom att förvränga ytans normal, vilket ger en illusion av djup. Sampling av pixlar används för att mjuka upp kanter mellan områden med snö och utan snö. En nackdel som Ohlsson & Seipel (2004) nämner med metoden är att den inte tar hänsyn till arean av området som täcks med snö, vilket kan innebära att vissa ytor täcks med för mycket snö. Ett annat problem är att få snö på dynamiska objekt när de flyttas in och ut från områden där det snöar. En fördel med metoden är att prestandan är oberoende av antalet objekt.

Enligt Reynolds, Laycock & Day (2014) samt Chang & Ryoo (2015) kan en occlusion map renderas före exekveringen av exempelvis ett spel, men detta innebär att ingen uppdatering kommer ske i realtid. En occlusion map kan användas för att bestämma hur snön ska placeras, exempelvis att snö hamnar på ett hustak, men inte på husets väggar (Reynolds, Laycock & Day, 2014).

Enligt Haglund, Andersson & Hast (2002) kan en mesh kombineras med trianglar vars punkter bestämmer snöhöjden. Dessa punkter väljs ut slumpmässigt så snö får ett naturligare utseende, men denna metod hanterar ingen fysik och ger inte naturliga kanter.

Enligt Festenberg & Gumhold (2011) kan en mesh användas vilket möjliggör skapandet av mer komplexa snöstrukturer som snöbryggor, men en stor nackdel med denna lösning är att den inte är dynamisk samt är komplex.

4

En vanlig teknik som används av lösningar där mer prestanda är tillgänglig, är att simulera fallande snö med hjälp av ett partikelsystem. Partiklarna motsvara snöflingor som sedan beter sig på ett förutbestämt sätt. Anledningen till att använda ett partikelsystem är att partiklar enkelt kan hanteras av fysikberäkningar på en per snöflinga nivå. Ett partikelsystem är även likt det verkliga fenomenet av fallande snö där varje partikel är en snöflinga, vilket gör det lämpligt för en simulering. Problemet med partikelsystem är att prestandakrav ökar linjärt med antal partiklar som simuleras, vilket gör det problematisk att simulera tungt snöfall med många partiklar. Om tekniken enbart använder ett partikelsystem för att simulera fallande snö, så kommer lösningen ha svårt att simulera det som människor uppfattar som “tung snö” (Wang & Wang, 2006).

2.6 Implementation av metoder

Lösningen som beskrivs av Reynolds, Laycock & Day (2014) använder sig av occlusion som är baserade på skuggmappingsmetoder (metoder i datorgrafik som används för att generera skuggor). Varje objekt har en egen occlusion map som bestämmer vart snö ska hamna på objektet, vilket låter metoden ta hänsyn till vindriktningen. Snö projiceras från en riktning i världen, där projektionerna träffar, avgör vad värdet för den punkten i occlusion mappen innehåller.

Figur 1: ​Visar hur occlusion-metoden fungerar. De blå pilarna representerar vindriktningen, den röda cirkeln är ett objekt, medan det svarta strecket är ett plan. Den gråa färgen visar ungefär vart snö skulle hamna med vindriktningen som i bilden, dvs ingen snö på ett område

till vänster om objektet.

Occlusion mapping inspirerat av ​Ohlsson & Seipel (2004) implementeras genom att använda flera ​raycasts ​ för att bestämma om en yta ska täckas av snö eller inte. Dessa raycasts sker ifrån ett långt avstånd och deras vinkel i förhållande till marken representerar vindriktningen. De ytor raycasten träffar är de ytor som täcks med snö. Det som sker är att varje objekt har en occlusion-textur och varje pixel hos occlusion-textur prövas med en raycast, om raycasten träffade pixeln sätts pixelns färg till svart, annars om raycasten inte träffade sätts pixelns färg mot vit. Sampling används för att kontrasten mellan objektets snötäckta yta och objektets yta som saknar snö inte ska bli skarp. Sampling fungerar så att närliggande pixlar till den träffade pixeln även får en färg och beroende på hur många närliggande pixlar som träffas ju svartare färg får den närliggande pixeln. Ju fler samlingspunkter som används, desto mjukare blir kontrasten mellan de snötäckta och icke-snötäckta ytorna hos objektet.

5

Figur 2: ​Visar hur occlusion-metoden faktisk kan påverka utseendet på objekt, här i spelmotorn Unity ​(Unity Technologies, 2020a)​. De röda linjerna visar vindriktningen, vilken

går uppifrån höger till nedåt vänster. Tre objekt finns med i scenen och som bilden tydligt visar så blockerar de två mindre objekten områden på det stora planet och dessa områden täcks inte av snö. Dessutom så är baksidan av sfären inte täckt av snö, då detta område

blockeras av sfärens framsida.

Ohlsson & Seipel (2004) beskriver en metod för att skapa snövolym på marken där en textur läggs på marken. Texturens värden används sedan av en shader för att höja eller sänka motsvarande vertex i den texturerade marken.

Genom att modifiera värdet för snöhöjd i texturen, som även används för volym, kan snö vid till exempel bilspår sänkas eller höjas, genom att objektet som påverkar snön ändrar värdet i texturen på den plats som motsvarar objektets plats i världen. Detta uppnås inom Unity via en raycast som antas träffa marken. Utifrån denna träff utvinns sedan en UV-koordinat på texturen som täcker ytan, värdet på motsvarande UV-koordinat för snöhöjd i texturen ändras sedan till ett förbestämt värde.

Fallande snö skapas med hjälp av ett partikelsystem. Spelmotorn Unity ​(Unity Technologies, 2020a) stödjer direkt att användare skapar partikelsystem där inställningar kan justeras efter eget behov. I detta fall anpassas partikelsystemet så att det visuellt liknar fallande snöflingor.

För att öka realismen hos snön använder Dagenais, Gagnon & Paquette (2016) förutom marksnö med djup och fallande snöpartiklar, ett tredje element: dynamiska snöpartiklar som kan flytta sig i förhållande till dynamiska objekts rörelse. Deras lösning använder partiklar som påverkas av fysik för att uppnå denna effekt.

2.7 Liknande undersökning

Ett tidigare examensarbete ( ​Henriksson​, 2014) har genomfört en undersökning om hur mycket en volymetrisk eldshader kan skalas ner tills det att den slutar prestera

6

tillfredsställande. Detta har likheter med detta arbetets frågeställning då båda undersökningarna behandlar grafik och hur ändringar av parametrar påverkar användarupplevelsen. Därmed är det lämpligt att titta på vilken undersökningsmetod Henriksson ​ använde och ta ​inspiration av detta för att förbättra detta arbetes undersökning.

Henriksson (ss. 29-30, 2014) genomförde en pilotfas innan sin undersökning. Ett av pilotfasens syften var att hitta vilka parametrar som var mest relevanta, då antalet parametrar i kombination med det begränsade antalet respondenter gjorde det omöjligt att genomföra en djupgående undersökning av varje parameter. Dessutom hade pilotfasen även syfte att hitta den lägsta FPS som respondenterna kunde tänkas titta på. Pilotfasen genomfördes genom att låta en liten grupp respondenter titta på ändringar på parametervärden och säga till när den lägsta acceptabla nivån hade nåtts samt när parameterändringarna inte längre hade någon påverkan. Dessutom fick respondenterna säga hur stor påverkan de tyckte att varje parameter hade på artefakten. Med denna pilotfas lyckades Henriksson hitta de viktigaste parametrarna och vad deras lägsta och högsta värde borde vara.

Undersökningen av Henrikssons (ss. 31-37, 2014) artefakt utfördes på tio personer som alla hade intresse av spel och var i tjugoårsåldern. För att hålla testningen konsistent användes samma dator i alla tio undersökningar me ​d samma processer igång, vilket kontrollerades genom användandet av ​Windows Task Manager ​ . Alla personer som deltog fick veta vad de skulle titta på och att de skulle gradera vad de tyckte om den eldeffekt de hade sett enligt en skala från 1 till 5. Testpersonerna fick ingen ytterligare information om artefakten när de ställde frågor. Då det fanns tre relevanta parametrar, där varje parameter hade två inställningar, fanns det totalt åtta olika versioner. Varje person fick se alla åtta versioner i en semi-slumpmässig ordning med paus mellan varje version där personen skulle gradera den versionen som personen nyligen hade sett. När en person hade sett alla åtta versionerna fick de se och gradera dem igen för en andra och tredje gång. En genomtittning av alla åtta versionerna kallar Henriksson för ett test.

Mätdatan från Henrikssons (ss. 31-37, 2014) undersökning visade på större variation mellan första och andra testen än mellan andra och tredje testen, då respondenterna saknade referenspunkter i första testet. Analysen av resultatet fokuserar därmed på test två och tre.

Resultat från test två och tre presenteras i arbetet som två grafer:

1. Medelvärdet av varje respondents gradering av varje scen.

2. Det totala medelvärdet av graderingen av varje scen med en spridning som tar hänsyn till respondenternas svar. Om en scen fick en 3:a och en 5:a skulle dess medelvärde vara 4 och dess spridning vara från 3 till 5.

7

3 Problemformulering

När det gäller grafik i spel går det inte enbart att titta på hårda fakta t.ex. vilken metod som använder minst processorkraft, då det även enligt Keo (2017) är viktigt att veta vad användarna bryr sig om när det gäller grafiken. Detta är viktigt i utvecklandet av spel där hänsyn behöver tas avseende begränsade resurser som processorkraft. Spelutvecklare vill då veta hur resurserna kan användas på bästa möjliga sätt för att optimera användarupplevelsen. Enligt Keo (2017) har tekniker som eftersträvar fotorealism blivit mer och mer realistiska allt eftersom hårdvaran har blivit bättre, men ännu har inte riktig fotorealism ​uppnåtts. Även realistiska spel vill behålla en högbilduppdateringsfrekvens, i Henriksson (2014) pilotstudie uppfattade respondenterna att vid en bilduppdateringsfrekvens under 20 FPS påverkade inte längre grafikkvalitet deras bedömning. Även om bra grafikkvalitet är önskvärt måste detta vägas mot spelets prestanda.

Detta kan ses i spel som Star Wars Jedi: Fallen Order (2019) där spelaren ges möjlighet att välja mellan mer detaljerad men mer prestandakrävande grafik, eller mindre detaljerad grafik som inte är lika prestandakrävande.

Snö har många fysikaliska egenskaper som gör det svårt att simulera det på ett verkligt sätt och samtidigt behålla en rimlig prestanda. I princip kan varje snöflinga ses som en partikel, men detta är allt för krävande i de flesta sammanhang och en enklare modell måste användas. Metoderna som nämns under rubrik 2.5 utför detta, men ingen av dem har genomfört någon undersökning på hur personer upplever deras lösningar.

Målet med detta arbete är att besvara frågan “Hur påverkar olika snörelaterade grafiska aspekter en spelares uppfattning av grafisk kvalitet i ett 3D-spel som utspelar sig i en realistiskt inspirerad snömiljö?” Syftet är att ge en förståelse för vilka snörelaterade grafiska aspekter som bör prioriteras vid utveckling av snö i datorspel.

De metoder som användes för att skapa snömiljön avgränsas till occlusion, snö på marken och partikelmetoden som alla beskrivs under rubrik 2.6. Spelets prestanda hålls inom ramen för en realtidssimulering som enligt Henriksson (2014) betyder att spelet håller över 20 FPS.

Spelmekaniken begränsas till ett enkelt tredimensionellt bilspel, utvecklat för att besvara frågan för detta arbete. Frågorna om de snörelaterade grafiska aspekterna behandlar snö på marken och fallande snö och ställs kring hur realistisk respondenterna tyckte att snögrafiken var, samt en fråga där respondenterna subjektivt bedömer hur vacker de tyckte att snögrafiken i spelet var.

Det går att undersöka många olika grafiska stilar och hur dessa tillsammans påverkar användarupplevelsen, men detta skulle ha varit för mycket arbete för denna undersökning.

Därav är detta arbete begränsat till den realistiska grafikstilen definierad enligt Keo (2017).

3.1 Metodbeskrivning

I och med de problem som beskrivits i problembeskrivningen skapas ett enkelt spel, där fokus ligger på att implementera en realtidssimulering av en snömiljö som använder metoderna occlusion, snö på marken samt partiklar. Elementen i scenen som har med snö att göra är programmerade för att använda parametrar som påverkar dess utseende till

8

bekostnad av prestanda. Prestandan hålls över gränsen beskriven av Henriksson (2014) som 20 FPS för att spelet fortfarande skulle kännas responsivt. Genom att ändra på parametrarna kan en scens utseende varieras utan att ändra på spelmekaniken eller scenens uppsättning.

Undersökningen använder en kvantitativ metod där respondenten efter att ha spelat igenom spelet ombeds poängsätta den grafiska upplevelsen av snömiljön i spelet enligt en 1-till-5-skala på ett liknande sätt som Henrikssons (2014) undersökning om eldeffekter gick till, där respondenterna fick gradera vad de tyckte om eldeffekter med olika parameterinställningar enligt en 1-till-5-skala. Denna poänggivning används sedan för att bilda en uppfattning av vilka element i scenen respondenterna prioriterar och eventuellt visa på möjliga samband mellan olika parametrar.

Undersökningen frågar respondenterna dels hur realistisk de anser att snögrafiken är, vilket har ett objektivt svar då snö är ett verkligt fenomen och då kan betraktas som en beteendefråga enligt Østbye et al. (2003). Den andra frågan till respondenterna är hur vacker de tycker snögrafikens utseende är, vilket är en helt subjektiv fråga då hur vackert något är beror helt på vad personen tycker, därmed liknar det en attitydfråga enligt Østbye et al.

(2003). Respondenterna svarade på båda frågorna separat med en 1-till-5-skala där 1 är sämst och 5 är bäst. Det är möjligt för en respondent att betygsätta realism som en femma, men samtidigt anse att snön var ful och därmed ge en etta på frågan gällande utseende.

3.1.1 Beskrivning av spelet

Artefakten består av ett tredimensionellt spel i genren bilspel med tredjepersonsperspektiv där spelaren kör runt i en scen vars miljö ​består av objekt med realistisk utseende för att passa in på den realistiska grafikstilen enligt Keo (2017). Scenens miljö är täckt av snö som skapas enligt de metoder som beskrivs i rubrik 2.6.

Anledningen till att ett bilspel användes var att dess spelmekanik är enkel, vilket gör det lättare att implementera spelet på ett bra sätt samt gör det enklare för respondenterna att snabbt kunna utvärdera spelet utan att de behöva investera mycket tid för att lära sig mekaniken. En bil kräver ingen komplicerad animation för dess rörelse, jämfört med till exempel en humanoid karaktär. Att få hjul att rulla är mycket enklare än att skapa en gånganimation. En nackdel med att använda en bil som spelarens avatar är att om ett förstapersonsperspektiv används krävs kulisser för en bils interiör, vilket är krävande att skapa. Detta var anledningen till att ett tredjepersonsperspektiv användes i detta arbetets spel.

Bilspelet utvecklades i spelmotorn Unity och använder många av Unitys inbyggda system för att utföra grundläggande funktioner ​(Unity Technologies, 2020a).

3.1.2 Parametrar

Enligt Henriksson (2014) bör antalet parametrar begränsas beroende på antalet respondenter för att underlätta testning. Henrikssons artefakt har tre parametrar med två inställningar för varje parameter, detta ger totalt åtta versioner då alla kombinationer av parametrarna används. Skillnaden mellan parameterinställningarna i Henrikssons test var kvaliteten på eldeffekten – arbetets mål var att utvärdera om det var värt att använda hög

9

kvalitet på en parameter eller om användarna kunde acceptera en lägre inställning, vilket skulle bespara prestanda.

Henrikssons (2014) arbete an ​vände sig av en pilotstudie för att bilda en tidig uppfattning av vilka parametrar som respondenterna uppfattade som viktigast. De slutgiltiga parametrarna baserades sedan på resultatet av denna studie.

Då detta arbete inte har samma mängd möjliga parametrar som Henrikssons (2014) så valdes istället att direkt fastställa de parametrar som ansågs mest troliga att påverka utseendet av de snöaspekter som skall utvärderas. De parametrar som valdes baserades på de implementationer av de snödelar som beskrivs i rubrik 2.6. En pilotstudie genomfördes innan det slutliga testet, där det fastställdes att de parametrar som används är relevanta och ger ett användbart resultat. Konstanter är de delar av spelet som inte förändras mellan tester.

Valda parametrar:

1. Spår i snön: Tre variationer används.

1.1 Inga spår skapas efter bilen.

1.2 Spår efter bilen implementeras med så hög realism så möjligt, detta kräver mer prestanda.

1.3 Spår efter bilen approximeras till grundläggande former för att minska prestandaåtgången.

2. Djup av snötäcke: Två variationer används.

2.1 Snötäcket har inget djup.

2.2 Snötäcket har djup.

3. Intensitet på snöfallet: Tre variationer används.

3.1 Låg intensitet, få partiklar, lägre prestandaåtgång.

3.2 Mellan intensitet, ett medelvärde mellan låg och hög intensitet.

3.3 Hög intensitet, många partiklar, högre prestandaåtgång.

4. Hastighet på snöfallet: Tre variationer används.

4.1 Låg hastighet, partiklarna faller ner långsamt.

4.2 Mellan hastighet, ett medelvärde mellan låg och hög hastighet.

4.3 Hög hastighet, partiklarna faller ner snabbt.

10

Valda Konstanter:

1. Spelmekaniken är konstant i scenen.

2. Alla objekt i scenen – mark, omgivning, bil – är konstanta.

3. Ljud används inte i scenen.

4. Ljussättning är konstant under körning.

5. Prestanda hållas inom ramen för realtidssimulering.

Figur 3: ​Visar alla valda inställningar av parametrar för att testa varje parameters påverkan.

Om alla möjliga kombinationer av parametrar skall testas blir undersökningstiden för varje respondent allt för lång. Antalet kombinationer bör vara snarlikt det som användes i Henrikssons (2014) undersökning för att underlätta testning. Det valdes därför att genomföra ett mindre test där varje parameter endast testas en gång för varje möjligt värde den kan inneha. Fyra parametrar valdes där varje parameter kunde inneha två eller tre olika värden. Sju versioner skapades där varje version har en unik kombination av värden på parametrarna och varje parametervärde finns med i åtminstone en version.

11

Henriksson (2014) upptäckte under sitt testande att den sämre versionen av den ändrade parametern ofta graderades högre än den bättre versionen då alla andra parametrar förblev oförändrade. Enligt Henriksson tyder det på att de lägst valda värdena för parametern inte var tillräckligt låga för att påvisa en tydlig upplevd skillnad. Det är därför viktigt att välja parametervärdena med omsorg så att skillnaden mellan de högsta och minsta värdena är tillräckligt stora. Detta togs i åtanke då passande värden för denna undersökning valdes.

3.2 Undersökning

3.2.1 Att ställa frågor

Enligt Østbye et al. (2003) finns tre huvudgrupper av frågor som vanligtvis förekommer.

Dessa tre grupper är beteendefrågor, kunskapsfrågor och attitydfrågor.

Beteendefrågor är de frågor vars syfte är att ta reda på vad respondenten har gjort eller observerat. Dessa frågor tenderar att ge pålitliga svar men kräver att de är tydliga så att respondenten förstår vad som frågas efter (Østbye et al., 2003).

Kunskapsfrågor har som syfte att ta reda på vilka kunskaper respondenten besitter.

Vanligtvis ställs enbart några få kunskapsfrågor som då brukar fungera som stickprov. Likt beteendefrågor tenderar kunskapsfrågor att ge tillförlitliga svar, men det finns en risk att respondenten kan försöka dölja en kunskapsbrist (Østbye et al., 2003).

Vad beteendefrågor och kunskapsfrågor har gemensamt är att det finns objektivt korrekta svar, vilket inte den tredje huvudgruppen: attitydfrågor (Østbye et al., 2003).

Attitydfrågor syftar på frågor om exempelvis en persons attityd, vilket endast finns i denna persons huvud vilket gör det mycket svårt att bekräfta om det svar som personen ger är tillförlitligt. Formuleringen av frågorna är viktiga när det gäller attitydfrågor, då de har stor påverkan på svaren. Därför är det viktigt att ställa välformulerade attitydfrågor. Dessutom bör man tänka på vad det är man frågar om, exempelvis kan en respondent ge ett otillförlitligt svar på en tabubelagd fråga (Østbye et al., 2003).

3.2.2 Diskussion kring val av undersökningsmetod

Här diskuteras möjliga felkällor avseende undersökningen och åtgärder för dessa. Frågorna som respondenterna får behandlar de parametrar som beskrivs under 3.1.2, då dessa är direkt kopplade till arbetets frågeställning.

I Henrikssons (2014) undersökning hade respondenterna inte någon referenspunkt att gradera eldens utseende efter. Detta resulterade i att den första testomgången inte togs med i resultatet. För att undvika detta problem tillåts i detta arbete respondenten bilda en uppfattning av alla versioner innan en bedömning krävs. Detta gör att undersökningen jämför alla scener mot varandra. För att veta hur mycket ett parametervärde påverkar resultatet behöver endast en parameter ändras mellan varje version.

12

I denna undersökning, till skillnad från Henriksson (2014), behöver respondenterna inte enbart titta på ett objekt i realtid utan även spela ett enkelt spel. Denna interaktiva del kan komma att ta fokus från respondenterna och kan påverka hur mycket respondenten märker av snögrafiken, vilket i sin tur kan komma att påverka resultatet. För åtgärda detta är målet i spelet enkelt och oförändrat mellan spelomgångarna.

En annan potentiell felkälla enligt Henriksson (2014) är valet av respondenter. I Henrikssons undersökning var alla respondenter bekanta med Henriksson sedan tidigare vilket Henriksson betraktade som en potentiell felkälla då deras tidigare relation kunde påverka respondentens betygsättning. Henriksson nämner också att respondenternas kön och vilka spel de är intresserade av kan ha påverkat resultatet. Dessutom kontrollerade inte Henriksson hur mycket erfarenhet respondenterna hade av virtuell eld, vilket var vad respondenterna skulle titta på och gradera. Enligt Henriksson kan detta ha bidragit till den variation hos svar som sågs mellan respondenter. För att åtgärda skall detta arbetes respondenter på eget initiativ välja att delta i undersökningen istället för att bli personligen uppmanade av författarna.

En kvalitativ undersökning är bättre än en kvantitativ undersökning för att upptäcka nyanserade åsikter hos undersökningspersoner (Østbye et al., 2003). Detta kan vara bra för det här arbetets undersökning då frågor som “hur realistisk upplever du bilden” inte lätt kan besvaras med en enkät där testpersoner enbart ger ett numeriskt värde. Genom att lägga mer tid på individuella testpersoner och analysera deras mer utförliga upplevelse kan ett mer nyanserat svar uppnås. Detta tar dock längre tid och leder till en mindre samplingsmängd än en kvantitativ undersökning. Det är även mer komplicerat att genomföra flera individuella personundersökningar än att skicka ut enkäter och sedan analysera ett sammanfattat dokument med data.

Då ämnet i arbetets undersökning kan betraktas som subjektivt, finns det en risk att varje persons åsikt varierar kraftigt. Det är då bra att undersöka en stor mängd personer för att minska variationer och extremfall och på så sätt bilda en uppfattning av majoritetens åsikt, vilket gör en kvantitativ undersökning lämplig. Nackdelen med en kvantitativ undersökning med en 1-till-5-skala är att den inte ger svar varför respondenterna tycker som de gjorde, vilket gör det svårt att få fram en djupare slutsats som kan appliceras på framtida projekt (Østbye et al., 2003).

Henrikssons (2014) undersökning använder en kvantitativ metod där varje respondent fick sätta ett värde från 1 till 5 på varje scen de såg. Då detta arbete liknar Henrikssons är det rimligt att anta att en liknande metod skulle fungera. Problemet med att använda en kvalitativ studie är att den syftar på att gå djupare inom något område, men då detta arbete inte hade någon data att bygga teorier på eller någon grund att stå på, så var detta opraktiskt.

En kvantitativ analys handlar om datainsamling och detta behöver inte detaljerade teorier för att vara effektiv till skillnad från en kvalitativ undersökning (Østbye et al., 2003). Slutsatsen blev att en kvantitativ analys ansågs mer praktisk för detta arbete.

I Henrikssons (2014) undersökning fick respondenterna besvara frågor direkt efter det de sett en scen. Detta gjordes med förhoppning om att respondenten då kommer ha scenen

13

färskt i minnet. Av samma anledning ställs frågorna i detta arbetes spel direkt efter att respondenten har spelat igenom en version.

I Henrikssons (2014) undersökning fick varje respondent se varje scen tre gånger. Detta motverkade problemet att första gången respondenterna såg scenerna hade de ingen referenspunkt att göra en bedömning efter. När respondenterna sedan såg scenen för andra och tredje gången kunde de använda första omgången som referens och detta syns i Henrikssons data då värdena i andra och tredje genomgången är närmare varandra än värdena mellan första och andra genomgången. För att i detta arbete ge respondenterna en referenspunkt får de först spela igenom de sju versionerna utan att ge bedömning. Sedan får respondenterna spela igenom de sju versionerna igen, men då ge bedömning efter varje spelad version.

Slutligen finns det en risk att frågorna är otydligt ställda. Det är viktigt för både beteendefrågor (frågan om realism) och attitydfrågor (frågan om utseende) att de är tydligt ställda, så att respondenterna vet exakt vad det är som frågas om och därmed ger så pålitliga svar som möjligt. Ett problem med attitydfrågor är svårigheten att bekräfta om en respondent svarade ärligt eller inte; svaren avseende snöns vackerhet bör behandlas med en viss osäkerhet (Østbye et al., 2003).

3.2.3 Genomförande av undersökningen

Respondenter deltog i undersökningen genom att de besökte ett Google-dokument som länkades via Högskolan i Skövdes facebookgrupp (Facebook, 2020). I detta dokument fanns information kring testet samt möjlighet för respondenterna att ladda ner det testprogram som genomförde detta arbetes undersökning. Testprogrammet bestod av versioner av spelet samt undersökningsfrågor som utfördes i en förbestämd ordning. I varje version av spelet kör respondenten bilen till några förutbestämda positioner i scenen, valda för att respondenten skall uppleva så mycket av scenens miljö som möjligt. Testprogrammet kördes på respondenternan egna maskiner vilket innebär att prestandaskillnader uppstod mellan respondenterna. För att konstatera att en respondents maskin höll sig inom ramen för realtidssimulering sparades det genomsnittliga FPS-värdet för varje version och om detta understeg kravet på 20 FPS räknades inte respondentens bedömning.

Testprogrammet användes enligt följande. Innan någon form av bedömning gjordes av respondenten spelar hen först igenom alla versioner av spelet, med syfte att bilda en referenspunkt som tillåter jämnare bedömning i senare steg likt den funktion första bedömningen i Henrikssons (2014) undersökning hade. Efter denna snabbare överblick av alla versioner ombads respondenten spela igenom en version i taget till det att den hade testat alla möjliga versioner igen. Denna gång ställdes dock frågor efter varje spelad version där respondenten gav en bedömning av nuvarande version i förhållande till alla tidigare visade versioner. Scenerna jämfördes avseende realism, samt hur vackra de uppfattades vara.

Respondenten gav sin bedömning i en 1-till-5-skala där 1 och 2 innebär att respondenten tyckte att nuvarande versionen är sämre än de andra, en trea att versionen inte visar stor skillnad mot de andra, en fyra eller femma att versionen är bättre än de andra.

14

3.3 Utvärdering

Här beskrivs de metoder som arbetet använder för att utvärdera resultaten från undersökningen.

3.3.1 Statistisk signifikans, medelvärde och standardavvikelse

Detta arbete analyserar realismen och vackerheten hos de olika versionerna av arbetets artefakt genom att beräkna medelvärde och standardavvikelse (σ) baserat på de olika respondenternas bedömningar.

Medelvärdet är det värde som fås när alla respondenternas svar summeras och sedan divideras på antal respondenter. Standardavvikelsen visar hur mycket respondenterna bedömningar avviker från varandra, ju större standardavvikelse desto mer varierar respondenternas svar.

För detta arbete har en statistisk signifikansnivå på två standardavvikelser från medelvärdet valts. Den statiska signifikansnivån är den största osäkerhetsnivå för vilket man väljer att dra slutsatser. För en normalfördelning är det ungefär 95% sannolikhet att det faktiska värdet ligger inom två standardavvikelser från medelvärdet (Wikipedia, 2020c). Vilket även motsvarar en osäkerhet på ca 5% att det faktiska värdet inte ligger inom två standardavvikelser från medelvärdet utan istället hamnar utanför. Detta innebär att det är svårare att dra en slutsats ju större standardavvikelsen är, en sådan standardavvikelse orsakas av större variation hos svaren från respondenterna.

En enkel analys som jämför två eller fler bedömningar utförs genom att utvärdera om medelvärdet +-σ för bedömningen av en version av arbetets bilspel delvis sammanfaller med medelvärdet +- σ för bedömningen av en annan versionerna, visas att det med hög sannolikhet inte är skillnad på de jämförda versionerna. Alltså det går inte att säga vilken av versionerna som respondenterna tyckte bättre eller sämre om. I fallet då medelvärdet +-σ inte sammanfaller med varandra, är sannolikheten stor att den ena versionen är bättre än den andra och då kan en slutsats dras mellan bedömningarna av dessa versioner.

3.3.2 Regressionsanalys

Syftet med en regressionsanalys är att avgöra vilka parametrar som har störst inverkan på realismen eller vackerheten hos spelet. Regressionsekvationen skrivs som ​Ekv 1 (Wikipedia, 2020b).

y ​ i ​ = k ​ 0 ​ + k ​ 1 ​ x ​ i1 ​ + k ​ 2 ​ x ​ i2 ​ + k ​ 3 ​ x ​ i3 ​ + ε ​ i Ekvation 1

● y ​ i ​ är medelvärdet på bedömningen från spelversion ​i ​ ⁽ ​i ​ = 1, 4, 5, 6 och 7).

● x ​ i ​ är parametervärdena som används i spelversion ​i ​ ⁽ ​i ​ = 1, 4, 5, 6 och 7). Indexsiffran står för de olika parametrarna (1 djup, 2 intensitet, 3 hastighet).

● ε ​ i​ är en restterm för spelversion ​i ​ ⁽ ​i ​ = 1, 4, 5, 6 och 7).

● k-värdena ​ är okända konstanter, det är de som är önskvärda att beräkna.

Indexsiffran står för de olika parametrarna (1 djup, 2 intensitet, 3 hastighet).

15

De värden som är valda för ​x ​ i ​ visas i Tabell 1.

Regressionsekvation beräknas i Excel (Microsoft, 2020). Från Excel fås k-värdet med standardavvikelsen för varje konstant. Detta resultat tolkas på följande sätt:

● Om k är positiv ökar realism eller vackerhet när respektive konstant ökar.

● Om k är negativ minskar realism eller vackerhet när respektive konstant ökar.

● Om två standardavvikelser är mindre än absolutvärdet av k är k signifikant på 95%-nivån.

● Om två standardavvikelser är större än absolutvärdet av k är k inte signifikant på 95%-nivån.

Tabell 1: ​Visar vilka värden som valdes för ​x ​ i ​ . Värdena kan väljas godtyckligt så länge det finns en logisk koppling. För enkelhets skull används 1 för att representera hög inställning på

en variabel, 0.5 för att representera mellan inställning och 0 för att representera låg inställning.

Djup av snötäcket = ​x​ i1 Intensitet på snöfallet = ​x​ i2 Hastighet på snöfallet = ​x​ i3

Snötäcket har djup

Snötäcket har inget djup

Låg intensitet, få partiklar

Mellan intensitet

Hög intensitet, många partiklar

Låg hastighet

Mellan hastighet

Hög hastighet

x ​ i1 ​ = 1 x ​ i1 ​ = 0 x ​ i2 ​ = 0 x ​ i2 ​ = 0.5 x ​ i2 ​ = 1 x ​ i3 ​ = 0 x ​ i3 ​ = 0.5 x ​ i3 ​ = 1

16

4 Implementation

I denna del av arbetet förklaras de moment som krävdes för att skapa arbetets artefakt, ett bilspel. Spelet skulle enligt del 3.1.1 vara “ett tredimensionellt spel i genren bilspel med tredjepersonsperspektiv, där respondenterna som spelar artefakten kör runt i en scen.

Scenens miljö ​består av objekt med realistisk utseende, för att passa in på den realistiska grafikstilen enligt Keo (2017). Artefaktens miljö är täckt av snö, som skapades enligt de metoder som beskrivs under rubrik 2.6.“.

Artefakten utvecklades i spelmotorn Unity ( ​Unity Technologies, 2020a). För att möjliggöra shaderprogrammering i Unitys verktyg ​Shader Graph ​(​Unity Technologies, 2020b) används renderingspipelinen ​Lightweight Rendering Pipeline ​(​Unity Technologies, 2020c). Shader Graph användes då detta gör shaderprogrammering i Unity enklare och smidigare. Light Weight Rendering Pipeline möjliggör även användandet av effektiva post-processing-effekter vilket utnyttjades i artefakten. Den enda nackdelen med Light Weight Rendering Pipeline för detta projekt är dess låga upplösning av skuggor, detta motverkades genom att skala upp allt i spelvärlden med en faktor 10, vilket därmed ökar skuggors upplösning med samma faktor 10.

För att göra det enkelt att jobba på distans användes Unitys ​Collaborate ​(​Unity Technologies, 2020h). Fördelen med Collaborate är att den är anpassad för Unity och gör det enkelt att ladda upp och hämta ner ändringar av artefakten. Nackdelen är att gratisversionen av Collaborate har ett mycket begränsat lagringsutrymme, vilket har begränsade mångfalden hos objekten i spelvärlden.

Artefakten baserades huvudsakligen inte på något annat arbete. Innan artefakten kunde skapas behövde därmed en grundläggande idé av dess utseende skapas utöver den tidigare breda beskrivningen i del 3.1.1. Stora aspekter av artefakten kunde direkt bestämmas baserat på de metoder som skulle implementeras. Resten utvecklades i takt med artefakten.

4.1 Grunderna

De första delarna som implementerades var de som är mest kritiska för artefaktens mekanik:

en bil samt mark för bilen att åka på. Detta gjordes då stora delar av arbetets snömetoder bygger på interaktion mellan bilen och marken, då marken samt bilen tidigt blev färdiga kunde de andra delarna av arbetet påbörjas. Bilens utveckling prioriteras då dess mekanik även är kritisk för respondenternas upplevelse, då den skall kännas tillräckligt naturligt för att respondenterna skall kunna fokusera på omgivningen.

4.1.1 Marken

Markens form baserades på egenskaper som upptäcktes under arbetets gång. Den fyrkantiga formen användes för att eliminera de fel som uppstod då en textur skulle täcka en mer komplex mark. I och med att denna 2D-textur inte direkt kan kläs över ett 3D-objekt som inte är en fyrkant likt texturen själv, krävdes en mappning från en 2D-textur till ett 3D-objekt. På ett vanligt objekt med komplexa former gjordes denna mappning med hjälp av en förgenererad UV-map. Denna map vecklar ut ytor av objektet huller om buller på en

17

2D-textur. Denna textur kunde sedan användas för att hitta en 3D-positions motsvarande position i en 2D-textur eller tvärtom.

Under arbetet med artefakten upptäcktes att om en textur skall appliceras på ett komplext UV-mappat objekt leder detta till att pixlar intill varandra i 2D-texturen inte nödvändigtvis ligger intill varandra på objektet. Om sedan fotsteg genereras på ett sådant objekt måste varje pixel av fotsteget hämtas i världen med hjälp av raycasts, vilket gör högupplösta fotsteg mycket krävande.

Om en textur istället appliceras på ett enkelt UV-mappat objekt där pixlar intill varandra i texturen även ligger intill varandra i världen kan fotsteg drastiskt optimeras. Endast en pixels position i texturen behöver hämtas med en raycast, fotsteget kan sedan ritas kring den pixeln utan ytterligare dyr beräkning.

En ytterligare fördel med en stor yta med enkel UV-mappning är att den saknar sömmar där UV-mappningen övergår mellan delar av objektet. Vid sömmar finns ingen koppling mellan vertexar på båda sidor av sömmen vilket gör att om deras höjdvärden är olika bildas ett hål i objektet.

Figur 4: ​Exempel på hål skapade av olika höjd på vertexar kring en UV-mappnings söm.

Markens upplösning är kritisk då höjdändring endast kan ske per vertex. En låg upplösning på marken betyder att upplösningen på fotstegen också är låg. Därför valdes det att skapa markens mesh med hög upplösning innan körning. Ett alternativ till denna metod hade varit att ändra markens upplösning dynamiskt under körning. Detta kan tjäna prestanda samt öka upplösningen där det behövs genom att möjliggöra olika upplösningar, exempelvis beroende på vad kameran ser. Detta är dock väldigt komplicerat jämfört med att skapa en högupplöst mesh från början (Mr_Admirals, 2015). Marken skapades i mjukvaran ​Blender ​ ⁽ ​The Blender Foundation, 2020) ​. Detta gjordes då Blender är gratis samt har inbyggda funktioner för att öka upplösningen av mesh, se Figur 5 och Figur 6.

18

Figur 5: ​Hela marken sett ovanifrån där varje orange linje motsvarar en linje mellan två vertexar.

Figur 6: ​En närmare titt på marken. Visar tydligt hur den höga densiteten av vertexar motsvarar markens upplösning.

För att bilda ett snötäcke på marken användes en shader vars funktion var väldigt likt det som planerades i del 2.6. Denna shaders främsta funktion är att höja eller sänka alla vertexar i marken beroende på ett värde i en 2D-textur kallad height-map. Denna height-map har samma upplösning som antalet vertexar i meshen så att varje pixel motsvarar en vertex, vilket i detta fall är 2048*2048. Beroende på varje vertexs höjdvärde ändras även dess färg mellan en färg tagen ifrån en marktextur eller en ifrån en snötextur.

19

Figur 7: ​Huvuddelen av markens shader där de olika delarna är markerade med nummer. Se Appendix D för tydligare bilder av delarna ett till fem.

Den huvudsakliga delen av shadern bestod av fem delar enligt Figur 7, dessa beskrivs nedan.

1. Tar in ett värde mellan 0 och 1 från texturens heightmap beroende på nuvarande vertexens UV-koordinat. Detta värde multipliceras sedan med en variabel som används för att skala värdet 0 till 1 för att motsvara snöns höjd i världen. Nuvarande vertexs normal multipliceras sedan med detta värde och skickas vidare till nästa steg.

2. En brusfunktion genererar ett värde mellan 0 och 1 beroende på den nuvarande vertexens position i världen. Detta värde modifieras för att motsvara en liten

förändring upp eller ner i snön. Det slutliga värdet multipliceras sedan med vektorn från steg 1 och vektorn skickas vidare till nästa steg.

3. Dotprodukten av nuvarande vertexs normal används för att avgöra markens lutning.

Om lutningen är för hög blir resultatet av funktionen 0, annars 1. Detta gör att branta ytor inte täcks med snö. Detta värde 0 till 1 multipliceras med vektorn från steget innan och vektorn fortsätter sedan till nästa steg.

4. Texturen från occlusionmetoden som beskrivs i del 4.3.1 används för att ge ett värde mellan 0 och 1 beroende på om marken skall kan nås av snö eller inte. Detta värde 0 till 1 multipliceras med vektorn från tidigare steg och skickas vidare.

5. Kedjan av multiplikationer där normalen modifieras för att slutligen motsvara snöns höjd. Positionen från nuvarande vertex adderas med den modifierade normalen och denna position sätts sedan till vertexens slutliga renderade position.

20

Figur 8: ​Delen av markens shader som hanterar färg.

Den del av markens shader som visas i Figur 8 använder vektorn som skapas i Figur 7:s längd för att generera två värden A och B mellan 0 och 1 som är inverterade i förhållande till varandra. Om värde A är 1 är värde B 0. De två texturerna som motsvarar marken samt snön multipliceras med ett värde var, därefter adderas deras färger. Detta leder till att en mjuk övergång mellan texturernas färger uppnås genom att värdet skiftar mellan 0 och 1. Denna slutliga färg appliceras sedan som nuvarande vertexs färg.

4.1.2 Bilen

Bilen förflyttas med Unitys fysiksystem ( ​Unity Technologies, 2020j), vilket gör att bilen har en mer naturlig rörelse än att oberoende av fysik flytta bilen vid varje uppdatering. Som framdrivningsteknik används ett Unitysystem som heter ​Wheelcollider ​ ⁽ ​Unity Technologies, 2020d) ​. Anledningen att använda Wheelcollider är att bilens hjul till skillnad från exempelvis

21

ett flygplan eller rymdskepp, nästan alltid har kontakt med marken och fysik mellan marken och hjulen är svårt att representera i ett spel, vilket är ett problem som Wheelcollider löser.

Som inspiration och vägledning för hur Wheelcollider används i Unity, utgick arbetet från denna video av Mustafa ( ​2019). Likt ​Mustafas bil använder bilen i artefakten fyra Wheelcolliders, en för varje hjul och varje Wheelcollider objekt är barn till bilen på samma sätt som i Mustafas video, vilket ser till att deras positioner relativt bilen alltid är konstanta.

Den mest betydelsefulla skillnaden mellan Mustafas video och Wheelcolliders i artefakten är att ​Sideways Friction Stiffness variabeln är satt till nio i artefakten (​Unity Technologies, 2020d) ​. Detta är för att bilen gärna sladdar när den ska svänga om variabeln är satt till ett, vilket är ett icke önskvärt beteende då det försvårar genomspelningen av artefakten vilket går emot målet att artefakten ska vara enkelt att spela igenom. Lösningen på detta problem hittades genom att experimentera med olika värden på Wheelcollider variablerna tills bilen slutade sladda.

Figur 9: ​Bilden visar det oönskvärda sladdningsbeteendet bilen har när ​Sideways Friction Stiffness ​ variabeln är satt till ett för bilens fyra Wheelcolliders. Vid hög hastighet kan bilen

knappt svänga och istället sladdar i samma riktning som bilen körde emot innan svängen.

För att bilen ska svänga behöver enbart de två främre ​Wheelcolliders Steer Angle (​Unity Technologies, 2020d) vinklas för resten tar fysiken hand om. För att bestämma storleken på vinklingen av Wheelcolliders, används en metod som heter ​Ackerman Styrning ​ vars mål är att se till så hjulen vinklas på så sätt att bilen inte slirar när den svänger ( ​Engineering Explained, 2019) ​. Ackerman Styrning i artefakten implementerades enligt följande video av BlinkAChu (2019). I artefakten fall är syftet med Ackerman Styrning inte att förhindra sladdning vilket är ett problem även efter implementeringen av Ackerman Styrning, utan för realismens och estetikens skull, då hjulen med denna styrning ger realistiska spår i snön. Då hjulen vrids, vrids även deras spår vilket leder till bredare spår. Problemet med sladdning

22

löstes, som nämnts ovan, genom att öka stiffness på Sideways Friction hos Wheelcolliders, vilket indikerar att implementeringen av Ackerman Styrningen i artefakten är felaktig.

Ett problem som upptäcktes var att bilen i vissa fall kunde tippa eller fastna på olika objekt.

Ett tydligt fall där bilen kan fastna är om bilen från startposition backar in i bergväggen.

Problemet motverkas genom att en konstant nedåtkraft applicerades på bilen men detta tar inte helt bort risken att bilen tippar eller fastna. Skulle bilen tippa eller fastna så finns en nödlösning där man genom att trycka på R knappen sätter bilens position till sin startposition.

För bilens utseende användes först bilen från Mustafa ( ​2019) exempel, ​dock ansågs inte denna bils utseende vara tillräckligt realistisk. Istället används den bil som nämns i Appendix A nr 7. Bilen förseddes med nya strålkastare och bakljus, då bilens egna strålkastare och bakljus saknade ljus. De nya strålkastarna och bakljusen skapades genom att använda kuber och sfärer vars former liknar bilens egna strålkastare och bakljus. Dessa placerades sedan framför motsvarande objekt på bilen. Genom att växla mellan de ursprungliga mörka färgerna hos bilens strålkastarna och bakljusen till en mycket ljusare version av färgerna, ser det ut som att strålkastarna och bakljusen sätts på eller av. Dessutom har Unity spotlights (Unity Technologies, 2020i) satts som barn till strålkastarna och bakljusobjekten vilket gör att bilens strålkastare och bakljus faktisk lyser upp omgivningen.

Figur 10: ​Visar bilen sett framifrån, utan strålkastare.

23

Figur 11: ​Visar bilen sedd framifrån, med de mycket ljusa cirklarna är strålkastare, satta som barn till bilen. Detta göra att deras position relativt bilen förblir densamma.

4.2 Spelmekanik

4.2.1 Kamerasystemet

Artefakten använder ett tredjepersonsperspektiv, vilket valdes innan utvecklingen av artefakten påbörjades. Anledningarna till detta val beskrivs i 3.1.1. I den första iteration av artefakten var kameran ett barn till bilen, vilket var en enkel lösning för att få kameran att följa med bilen. Detta innebar att kameran var helt stel i förhållandet till bilen, vilket ansågs inte vara bra för spelupplevelsen. Ett annat problem med denna lösning var att kameran kunde hamna inne i hus och andra objekt i spelvärlden, vilket också ansågs försämra spelupplevelsen och minska känslan av realism.

Figur 12: ​Exempel där fasta kameran hamnar inuti ett annat objekt.

För att lösa dessa problem utvecklades kamerasystemet enligt en video av ​Filmstorm (2017)​.

Istället för att kameran är ett barn till bilen så är den istället ett barn till ett objekt som heter CameraBase ​ . Detta objekt ska söka sig till en målpunktobjekt som heter ​CameraFollowObj vilket är ett barn till bilen. Anledningen till detta är att med denna konstruktion kan genom att flytta CameraFollowObj ​, kontrollera den punkt som CameraBase ska ha i förhållande till bilen, vilket inte går om ​CameraBase ​ är ett barn till bilen. Till skillnad från när kameran var

24

ett barn till bilen kan CameraBase enbart förflyttas ett begränsat avstånd i varje uppdatering, vilket innebär att om bilen rör sig tillräckligt snabbt framåt eller bakåt, kommer CameraBase och därmed kameran att hamna längre bak eller längre fram relativt till bilen, se Figur 13 och Figur 14. Dock finns det ett maxavstånd som CameraBase kan ha till CameraFollowObj, vilket innebär att kameran inte kan hamna för nära eller för långt bort från bilen.

Även kamerans rörelse när bilen svänger har gjorts mjukare genom att rotera CameraBase ​.

Istället för att använda CameraFollowObj ​, ​ används bilens egna rotation vilket CameraBase kommer att anpassa sin rotation till.

För att kameran inte ska hamna bakom eller i något objekt används lösningen från Filmstorm (2017) video ​. Ett problem här var att CameraBase kollisionsundvikningshastighet var satt för låg, vilket gjorde att kameran kunde åka igenom hus och andra objekt. Detta löstes genom att öka hur snabbt kollisionshantering fick flytta kameran.

Figur 13: ​När bilen åker snabbt framåt hamnar kameran längre ifrån bilen.

Figur 14: ​När bilen åker snabbt bakåt hamnar kameran närmare bilen.

4.2.2 Checkpoint-systemet

Syftet med checkpoint-systemet är att agera som spelmekaniken som bestämmer när artefakten är avklarat, samt se till att respondeterna kör runt banan på ett kontrollerat sätt så

25

att spelarna i undersökningen bör ha liknande upplevelser och inte missa delar av banan och miljön som är planerat att de ska se. Checkpoint-systemet bygger på principen att enbart en checkpoint i taget kan vara aktiv. När bilen kör igenom den aktiverade checkpointen avaktiveras den och nästa checkpoint aktiveras. Artefakten avslutas när den sista checkpointen körs igenom, vilket är det enda sätt som artefakten är menat att avslutas på.

Den aktiva checkpointen markeras av en stor röd pil som pekar ner mot den, se Appendix A nr 6. Respondenterna förväntas köra under pilen för att checkpointen ska avklaras.

Figur 15: ​Visar hur checkpoints är utplacerade på banan. Totalt finns det åtta checkpoints vilka är markerade med siffrorna 1 till 8 i den ordning de är aktiva. De lila pilarna visar den

rutt en respondent förväntas köra, från bilens startposition nere i vänstra hörnet till slutpositionen vid checkpoint nummer åtta. Denna rutt bör innebära att spelarna ser det

mesta av banan, inklusive att köra igenom tunneln, där det inte finns snö på marken på grund av occlusion-metoden.

4.3 Snö

4.3.1 Occlusions-metoden

Occlusion-metoden som används i artefakten är inspirerad av ​Ohlsson & Seipel (2004) och dess syfte är att se till att snö enbart hamnar på ytor som fallande snö faktisk kan nå, exempelvis så ska det inte finnas snö inne i tunneln då denna är övertäckt med stenar sett från snöriktningen. Metoden bygger på att en punkt bara ska ha snö om den är den närmaste punkten till himlen sett från snöriktning. Till skillnad från Ohlsson & Seipel (2004) metod så har occlusions-metoden i ​artefakten ​inget brusfunktion vilket gör den enklare att implementera. Eftersom snöfallet i ​artefakten ​är kraftigt ska ytorna som täcks av snö vara helt täckta med snö. Därmed ansågs det extra arbetet med att implementera brus på ett tillfredsställande sätt inte vara nödvändigt och den sparade tiden kunde läggas på annat.

För att ge shadern input om ett objekts occlusion används en occlusions-textur, exempelvis är ​GroundOcclusionTexture ​ occlusions-texturen för marken. Pixlarna på occlusions-texturerna har färger mellan vitt och svart, där de svarta områdena är punkter där snö ska placeras.

26

Occlusions-texturerna skapas av ett skript som heter ​TextureScript ​ . TextureScript skapar en occlusions-textur av valfri pixelstorlek. I ​artefakten ​har alla occlusions-texturerna storleken 2048 * 2048 pixlar och har därmed samma upplösning. Alla pixlar i occlusions-texturerna är till början vita och för varje pixel görs en raycast från en inställbar riktning som representerar snöriktningen, vilket i ​artefakten ​har varit (x,y,z) = (0,-1,0) för alla occlusions-texturer, som är rakt neråt sett från markens perspektiv. Startpositionen för raycasten sett från pixelns perspektiv är i motsatt riktning till riktningen på raycasten. Detta innebär att raycasten kommer träffa pixeln om ingen objekt är emellan raycastens startposition och pixeln. I sin tur innebär detta att om raycasten träffar objektet som occlusions-texturen tillhör, så är detta området exponerat för snö och därmed sätts pixelns färg mot svart. För att kanterna mellan där det ska vara snö och områdena där det inte ska vara snö, inte skall bli för skarpa så används sampling, vilket innebär att även pixlarna som är grannar till den träffade pixeln blir mörkare. För att en pixel ska bli helt svart så måste den och dess närmsta 288 pixlarna alla vara exponerade för snö. När TextureScript har gått igenom alla pixlar, vilket för en 2048 * 2048 textur är 4,194,304 pixlar, är occlusions-texturen klar för användning.

Figur 16: ​Occlusions-texturen för stillastående bilar i artefakten. De svarta områdena är där snö ska placeras på bilen medan de vita områdena representerar de områden på bilen som

inte ska ha snö.

Det tar det betydande tid att enbart skapa en enda occlusions-textur då en 2048 * 2048 textur har många pixlar och det ska göras en raycast för varje pixel. Felinställningar innebär därmed att mycket tid går förlorad om occlusions-texturen behöver göras om. Detta innebär att det är önskvärt att återanvända samma occlusions-textur, vilket enbart fungerar för objekt av samma form och position. Ett exempel är stenmuren i artefakten, då eftersom stenmuren ser ut som den gör kan en enda occlusions-textur användas för samtliga stenar i stenmuren.

Ett betydelsefullt problem som har uppstått med TextureScript och skapandet av occlusions-texturer är att den inte alltid tog hänsyn till objektets skalor, för ett objekt vars förälder var uppskalat med en faktor 10, ignorerade TextureScript att göra raycast för de yttre pixlarna och istället gjorde flera raycast på de inre pixlarna, vilket innebar att enbart ett litet område på objektet täcktes med snö. Detta problem löstes genom att skapa en variabel som låter användaren av TextureScript skriva in vilken skala objektet och dess föräldrar har och detta i sin tur justerar avståndet mellan raycast så de riktas mot rätt pixlar.

27