The Neonland Experience - Linköping Universityweber.itn.liu.se/~karlu20/courses/TNM094/reports/... · användaren ta en bild. Slutligen utvecklades en enkel hemsida kopplad till

Linköpings universitet | Insitutionen för teknik och naturvetenskapKandidatarbete |Medieteknik

Vårterminen 2018 | LiU-ITN-TEK-G–18/039–SE

The Neonland ExperienceUtveckling av en chroma key-station till enutställningsmiljö

Anna Fredriksson HääggRonja FaltinJakob GunnarssonJesper MartinssonNicholas FrederiksenSimon Forsberg

Examinator: Karljohan Lundin Palmerius

Linköpings universitetSE-581 83 Linköping

013–28 10 00, www.liu.se

Sammanfattning

På Visualiserings centrum i Norrköping står en chroma key-station som besökarna kan använda för attvisualisera sig själva i en virtuell miljö. Detta projekts syfte är att utveckla en ny version av chromakey-stationen. Den nya stationen ska vidare byta ut den gamla i samband med att centret uppdaterarhela utställningen. Grundläggande krav från kunden är att chroma key-tekniken ska utföras i realtidoch användarna ska ha möjlighet att direkt se resultatet projicerat av en projektor framför sig. Dess-utom ska systemet anpassas till resterande utställningar på centret och därmed följa deras vision ochgrafiska profil. Slutligen bör stationen inspirera användaren till programmering och 3D miljöer ochväcka nyfikenhet till tekniken. För att göra detta finns ett sista krav på att systemet ska kunna ta enbild under av användaren under användning som användaren sedan ska få möjlighet att ladda ner påsin egna telefon eller dator.

Under arbetet har en agil utvecklingsmetod använts. Den första sprinten utnyttjades dels till förstudi-er och installation av ramverk och bibliotek men även för att dela ut ansvarsuppgifter inom gruppen.Då valdes exempelvis kundkontakt, scrummästare och rapportansvarig. Resterande sprintar planera-des allteftersom beroende på kvarvarande poster i projektets produktbacklogg. Produktbackloggenskapades med hjälp av de grundläggande kraven från kunden samt egenskrivna användarhistorier.Dagliga scrummöten hölls för att koordinera projektgruppen så att alla medlemmar visste vad somvar på gång. Utöver det hölls möten vid sprintstart och sprintslut. Efter andra sprintens slut samman-ställdes en första prototyp som visades för kunden. Även användartester för utomstående utfördes ochanalyserades.

Systemet utvecklades i spelmotorn Unreal Engine 4 både med hjälp av ramverkets egna verktyg,blueprints, men även med egenskrivna C++ klasser. Själva chroma key-operationerna implemente-rades genom att varje pixelvärde i kameraflödet jämfördes med ett intervall av referensvärden. Ompixelvärdet var i intervallet för referensvärdena klassades pixeln att tillhöra bakgrunden och gjordesdärför transparent. Vidare användes OpenCV för att behandla kameraflödet och spåra användaren.Referensrutor placerades där ikonerna skulle sitta. I referensrutorna jämfördes pixlarna mellan varjebildruta. Om förändring skett i bildrutan registrerades detta och efter ett bestämt antal registrering-ar markerades rutan, och därmed ikonen, som aktiverad. Med hjälp av denna teknik möjliggjordesfunktionen att låta användaren interagera med systemet, vilket var nödvändigt för att till exempel låtaanvändaren ta en bild. Slutligen utvecklades en enkel hemsida kopplad till cloud-databasen Imgur föratt hantera borttagning av bilder tagna av systemet.

Resultatet av arbetet blev en ny chroma key-station med ny 3D-miljö i 80-tals neonstil. Miljön inne-håller egenmodellerade objekt såsom berg i bakgrunden, palmer, blommor och en luftballong. En delav objekten är animerade och rör sig runt i miljön under användning. Användaren interagerar medgränssnittet genom att röra sig bakom knapparna. Under användning kan användaren ta en bild av sigsjälv i miljön. Bilden sparas sedan i en cloud-databas till vilken användaren ges tillgång via en länk.Bilderna i cloud-databasen rensas regelbundet och sparas därmed inte.

Sammanfattningsvis är projektets största grundkrav uppfyllt, nämligen att skapa en chroma key-station där användaren kan interagera med ett gränssnitt. En stor svårighet under projektets gånghar varit just att välja teknik. För både system/användar-interaktionen och bilddatabasen fanns många

i

SAMMANFATTNING ii

alternativa lösningar och mycket tid gick åt till att väga dem mot varandra, istället för att helhjärtatsatsa på en metod och hantera problem efter hand. En annan tidsbov som bidrog till att utvecklings-arbetet inte höll önskad hastighet var att versionshantering i Unreal Engine 4 visade sig vara merkomplex än förväntat. Lösningen blev att använda en server varifrån utvecklarna kunde checka ut ochin filer under arbetets gång. Utcheckade filer kunde ingen annan användare arbeta på. Avslutningsvisär systemet inte helt färdigställt för installation men ändå så pass färdigställt att en prototyp visats uppför kund som gav positiv feedback.

Innehåll

Sammanfattning i

Figurer vi

Tabeller vii

1 Inledning 11.1 Bakgrund . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

1.2 Syfte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.3 Frågeställning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.4 Avgränsningar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 Relaterat arbete 42.1 Chroma key . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1.1 Chromakey med RGB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.2 Chromakey med HSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1.3 Despill . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2 Unreal Engine 4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2.1 Villkor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.3 Open CV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.4 Databas för bilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.4.1 Imgur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.5 ShareX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.6 Existerande forskning kring inlärningsspel . . . . . . . . . . . . . . . . . . . . . . . 8

2.6.1 Gameplay-first . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.7 Ordlista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3 Utvecklingsprocess 103.1 Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.1 Produktbacklogg i HacknPlan . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.1.2 Sprintar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

iii

INNEHÅLL iv

3.1.3 Mötesrutiner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.2 Tidsplan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.4 Dokumentationsprinciper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.5 Kvalitetssäkring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.6 Systemarkitektur och modellering . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.7 Källor och referenser . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Implementering 164.1 Förstudie och Sprint 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.2 Chromakey . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.3 Virtuell miljö . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3.1 Designprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

4.3.2 Implementering av miljön . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4 Användargränssnitt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4.1 Tidig designprocess . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.4.2 Implementering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

4.5 Interaktion mellan användare och system . . . . . . . . . . . . . . . . . . . . . . . . 20

4.6 Funktionaliteten att ta och spara en bild . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6.1 Spara en bild . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6.2 Visa bilden . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.6.3 Ge användaren tillgång till bilden . . . . . . . . . . . . . . . . . . . . . . . 21

4.6.4 Automatisk borttagning av bilder . . . . . . . . . . . . . . . . . . . . . . . 21

5 Resultat 225.1 Systemarkitektur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Beskrivning av systemet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

6 Analys och diskussion 256.1 Metod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2 Resultat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.2.1 Aktivera knapparna . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

6.3 Svårigheter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.3.1 Versionshantering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.3.2 Plugins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.3.3 Tidsplanering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.4 Metoder för att spåra användaren . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

6.4.1 Interaktion med hjälp av en Kinect . . . . . . . . . . . . . . . . . . . . . . . 26

6.4.2 Interaktion med hjälp av kaskadklassificerare . . . . . . . . . . . . . . . . . 27

INNEHÅLL v

6.5 Metoder för att spara och visa en bild . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.5.1 Låta användaren ta en bild . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

6.5.2 Visa och tillgängliggöra bilden via hemsida . . . . . . . . . . . . . . . . . . 28

6.6 Chroma key-station som inlärningsspel . . . . . . . . . . . . . . . . . . . . . . . . . 29

6.6.1 Utveckling inom de tre dimensionerna . . . . . . . . . . . . . . . . . . . . . 29

6.7 Arbetet i ett vidare sammanhang . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

6.7.1 Systemets inverkan på individen . . . . . . . . . . . . . . . . . . . . . . . . 30

6.7.2 Systemets inverkan på samhället . . . . . . . . . . . . . . . . . . . . . . . . 31

7 Slutsatser 327.1 Återkoppling på frågeställningarna . . . . . . . . . . . . . . . . . . . . . . . . . . 32

7.1.1 Vilka metoder kan användas för att implementera ett gränssnitt mellan använ-dare och system när inga fysiska reglage används? . . . . . . . . . . . . . . 32

7.1.2 Vilka olika metoder kan implementeras i ett system för att tillåta användarenatt få en digital kopia av en bild de kan använda i eget bruk? . . . . . . . . . 32

7.1.3 Hur skapas ett intresseväckande och pedagogiskt innehåll till ett chroma key-baserat system som ska användas för barn och ungdomar i en utställningsmiljö? 33

7.2 Fortsatt arbete . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Litteraturförteckning 34

A Gantt-schema 36

B Arbetsfördelning 37

Figurer

1.1 Överblick av chroma key-stationen på Science centret . . . . . . . . . . . . . . . . . 1

2.1 Före och efter enkel chroma key-operation. . . . . . . . . . . . . . . . . . . . . . . 4

2.2 RGB färgrymden representerat som en kub. . . . . . . . . . . . . . . . . . . . . . . 5

2.3 HSL färgrymden representerat som en cylinder. . . . . . . . . . . . . . . . . . . . . 5

2.4 Skiss på skillnaden mellan en cloud-databas och en lokal databas. . . . . . . . . . . 7

3.1 HacknPlans kanban board under en sprint. . . . . . . . . . . . . . . . . . . . . . . . 11

3.2 Sprintschema med möten som projektgruppen följde under projektet. . . . . . . . . . 11

3.3 Ett exempel på hur Perforce ser ut i UE4 med markörer. . . . . . . . . . . . . . . . . 13

3.4 Exempel på kommentarer i blueprints . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.5 Övergripande skiss av systemet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.1 Bilden visar originaldelen, normalen av bilden, jämförelse mellan normalbilden ochen grön referensfärg och en alfammask. . . . . . . . . . . . . . . . . . . . . . . . . 17

4.2 Bilden visar en despillmask, applikationen av den och den slutgiltiga produkten . . . 17

4.3 Moodboard från kund. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

4.4 Moodboarden som utvecklades i samband med designprocessen. . . . . . . . . . . . 18

4.5 En luftballong i low-poly stil med ett material som markerar kanterna i UE4. . . . . . 19

4.6 En tidig skiss av användargränssnittet med ikoner. . . . . . . . . . . . . . . . . . . . 20

4.7 Tidig skiss av kameraikonen (för att ta en bild) och papperskorgs-ikonen (för att tabort en bild) med tidiga idéer om tema och färg. . . . . . . . . . . . . . . . . . . . . 20

5.1 En skiss av översiktlig systemarkitektur. . . . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Resulterande bild av huvudvyn när två personer använder systemet. . . . . . . . . . 23

5.3 Vyn som användaren ser efter den tagit en bild. . . . . . . . . . . . . . . . . . . . . 23

5.4 Vyn användaren ser om den valt att få länken till bilden. . . . . . . . . . . . . . . . . 24

6.1 En tidig skiss av hemsidan. Hemsidan visar tre saker, bilden, länken och QR-kod tillsamma länk. Dessa tre funktioner var tänkt att bli implementerad i hemsidan . . . . . 29

A.1 Gantt-schema som visar den ursprungliga tidsplanen . . . . . . . . . . . . . . . . . 36

vi

Tabeller

2.1 Ordlista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

3.1 Protokoll under projektet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

vii

Kapitel 1

Inledning

I följande rapport analyseras och beskrivs projektet att utveckla en chroma key-station som ska stå ien utställningsmiljö. Rapporten presenterar olika metoder för att implementera chroma key såväl sominteraktion mellan användare och system helt utan fysiska reglage och inmatade personuppgifter.

1.1 Bakgrund

Norrköping Visualisering AB, vidare kallat NVAB, driver Science centret som är en del av konsortietVisualiseringscenter C vilket är en mötesplats kring visualisering för forskning, näringsliv, allmänhetoch skola [1]. Science centret har ett primärt mål att öka intresset för naturvetenskapliga ämnen ochteknik hos barn och ungdomar.

På Science centret finns en utställning rekommenderad för barn i åldrarna 5–10 år där de kan knåpamed appar, pussla, undersöka och skapa [2]. Utställningen innefattar även den chroma key-stationvilken detta projekt har i uppdrag att uppgradera. Chroma key-stationen består i nuläget av en upp-spänd greensscreen upplyst av två diffusa lampor, en projektor som projicerar bilden, en kamera ochen undangömd dator som chroma key-programmet körs på. Se bild 1.1.

Figur 1.1: Överblick av chroma key-stationen på Science centret

Utöver de elementen som behövs för själva chroma key-tekniken finns även dekor i form av maske-radkläder och leksaker som användarna kan användas för att utforska tekniken på ett roligt och lekfulltsätt.

1

KAPITEL 1. INLEDNING 2

1.2 Syfte

Syftet med projektet är att uppgradera den redan befintliga chroma key-stationen på Science centretmed ny teknik, ny miljö samt eventuell ny dekor. Datorn som programmet körs på kommer att bytas utmen den greenscreen som redan finns kommer vara kvar. Uppgraderingen ska designmässigt anpassastill de förändringar Science centret kommer göra när de byter ut resterande delar av utställningen.Vidare ska den nya miljön på något sätt vara dynamisk och 3D-modellerad till skillnad från dennuvarande miljön som bara är en 2D-bild. Slutligen ska stationen kompletteras med ny funktionalitet.Denna funktionalitet ska möjliggöra för användaren att ta en bild på sig själv i den virtuella miljönoch sedan spara bilden för användning i eget bruk utan att ange några personuppgifter.

1.3 Frågeställning

Med hjälp av projektets bakgrund och grundläggande krav från kunden, NVAB, har följande fråge-ställningar formulerats.

• Användarens interaktion med systemet kommer ske helt utan knappar och reglage och barastyras av användarens rörelser. Vilka metoder kan användas för att implementera ett gränssnittmellan användare och system när inga fysiska reglage används?

• Ett av kraven är att systemet ska möjliggöra för användaren att ta en bild. Vilka olika metoderkan implementeras i ett system för att tillåta användaren att få en digital kopia av en bild de kananvända i eget bruk? Vilka för- och nackdelar finns med respektive alternativ?

• Chroma key-stationen kommer användas på ett Science center i en utställning som ska inspirerabarn och ungdomar till teknik och programmering. Hur skapas ett intresseväckande och peda-gogiskt innehåll till ett chroma key-baserat system som ska användas för barn och ungdomar ien utställningsmiljö?

1.4 Avgränsningar

Ytan stationen har att tillgå är begränsad, dels påverkar detta storleken på den greenscreen som finnsmen även avståndet mellan användare och kamera. Detta medför en avgränsning att användarens benoch fötter kommer vara utanför kamerans synvinkel och därför inte kommer synas i den virtuella mil-jön. Om även golvet hade varit klätt med en greenscreen kunde stationen även inkluderat användarensben. Detta hade gett en bättre helhetsuppfattning och möjlighet att röra sig på djupet i miljön.

En annan avgränsning är att stationen enbart utvecklas efter den aktuella kundens behov och yta.Stationen är därmed inte så generaliserad att den enkelt kan flyttas eller distribueras till annan plats.

NVAB vill kunna köra det färdiga systemet på Windows och andra plattformar och har därför intetagits i åtanke vid utvecklingen av stationen. Både ramverket Unreal Engine 4 såväl som biblioteketOpenCV, som presenteras mer i kap 2, är dock kompatibelt med flertalet andra plattformar.

Vidare är en stor avgränsning att stationen bara kommer tillhandahålla en miljö. Vid de inledandediskussionerna fanns en tanke om flera olika miljöer som NVAB skulle kunna byta mellan. För attinte göra projektet för omfattande i första hand slopades dock denna idé.

Den sista stora avgränsningen handlar om användarens interaktion med systemet. Då tiden för pro-jektet är avgränsad begränsas vissa möjliga tekniker som hade tagit längre tid att implementera. Inga

KAPITEL 1. INLEDNING 3

färdiga trackingsystem, likt Microsoft Kinect, kommer användas utan all tracking ska ske med hjälpav olika bildbehandlingar av kameraflödet. Detta medför att interaktionen kommer vara begränsad tillfå moment och endast fungera i specifika sammanhang.

Kapitel 2

Relaterat arbete

Under utvecklingsprocessen krävdes förstudier av befintlig teori och kunskap om relaterat arbete inomområdet. Nedan beskrivs kortfattat den teori som använts.

2.1 Chroma key

Chroma key är ett bildbehandlingsverktyg som maskar ut ett objekt placerat framför en enfärgadskärm och ersätter bakgrunden med en annan textur likt figur 2.1. De vanligaste färgerna att användapå skärmarna och därmed byta ut är blå och grön. Detta för att de skiljer sig mest från människanshudfärger [3]. Skärmarna kallas bluescreen respektive greenscreen. Själva Chroma key-metoden an-vänds i flera olika sammanhang, exempelvis vid nyhetsinspelningar när meteorologen står framför enväderkarta och under filminspelningar för att lägga till specialeffekter.

Figur 2.1: Före och efter enkel chroma key-operation.

Det finns många olika sätt att implementera själva utmaskningsdelen av chroma key-tekniken. Me-toden som presenteras i denna rapport bygger på en teknik där varje pixelvärde jämförs mot en valdreferensfärg. Det finns emellertid mer komplexa tekniker som exempelvis bygger på korrelationenmellan rörelseoskärpan i bilden eller skillnader i bilddjupet [3].

Chroma key-tekniken som används i detta projekt bygger som tidigare nämnt på en metod där varjepixel i bilden studeras. De pixlar som blir kategoriserade som ”bakgrund” dvs har samma färgvärdesom skärmen i bakgrunden maskas bort genom att alfavärdet för pixeln sätts till noll. Pixlarna blirdärmed transparenta och syns inte längre. Detta låter vidare den nya, virtuella bakgrunden synasbakom objektet [4].

4

KAPITEL 2. RELATERAT ARBETE 5

För att identifiera vilka pixlar som ska kategoriseras som bakgrund analyseras färgvärdet i respekti-ve pixel och jämförs mot ett fast referensvärde. Referensvärdet har samma färgvärde som skärmeni bakgrunden. Likväl måste fler pixlar kategoriseras som ”bakgrund” än de som har exakt sammavärde som referensvärdet. Detta för att ta hänsyn till exempelvis områden med ljusskillnader, skug-gor eller veck i skärmen. För att göra detta definieras referensvärdet med både ett maximum- och ettminimumvärde. Alla pixlar som har färgvärden mellan dessa värden registreras som bakgrund. Olikafärgrymder kan användas för att studera pixelvärdena, nedan beskrivs två av dem mer ingående.

2.1.1 Chromakey med RGB

Metoden som använder färgrymden RGB som visas i figur 2.2 tar hänsyn till de olika färgkanalernaröd, grön och blå, när de går närmare ett förutbestämt värde. Eftersom olika färgnyanser definieras avtre variabler med RGB kan små förändringar i röd, grön eller blå kanal ge en skillnad som är svår attta hänsyn till. Av denna anledningen är det svårt att bestämma hur maximum- och minimumvärdenaska sättas.

Figur 2.2: RGB färgrymden representerat som en kub.

2.1.2 Chromakey med HSL

Metoden som använder färgrymden HSL som visas i figur 2.3 tar hänsyn till nyans (hue), mättnad(saturation) och ljusnivå (lightness) när den beräknar vilka pixlar som ska kategoriseras som bak-grund. HSL är skapat för att efterlikna den perceptuella uppfattningen av en färgskillnad. Då varjenyans har endast ett eget separat värde kräver jämförelsen med HSL bara ett värde för att det går attskilja en nyans från en annan. För att beräkna vilka pixlar som ska kategoriseras som bakgrund kanchroma key-tekniken genom att använda HSL därmed ta hänsyn till både nyans, mättnad och ljus utanatt jämföra flera värden. [5].

Figur 2.3: HSL färgrymden representerat som en cylinder.


2.1.3 Despill

När ett objekt placeras i ett rum där väggar och golv är täckta av en skarp färg samtidigt som ljusalampor lyser upp rummet, reflekterar de skarpt färgade ytorna sin färg på objektet. Detta betyder attobjekt i chroma key-stationen kommer färgas lite av reflektionerna. Bildbehandlingen som tar bortdessa reflektioner kallas despill.

2.2 Unreal Engine 4

Unreal Engine 4 vidare kallat UE4 är en spelmotor som främst används för att utveckla spel men ävenger möjlighet till att utveckla andra typer av applikationer. Programmering i UE4 sker i språket C++eller i UE4s egna verktyg blueprints. Blueprints är ett sätt att programmera utan att skriva kod, iställetär funktioner representerade som noder vilka kopplas ihop för att ge objekt, spelare och ljussättningm.m. önskad funktionalitet[6].

UE4 har en omfattande materialskapare där sömlösa material skapas med hjälp av matematiska funk-tioner. Variabler såsom färg, transparens, och yta representeras som noder i blueprints på sammasätt som funktioner. Materialen i UE4 är även PBR-material Physically based rendering vilket göratt materialen beter sig mer fysiskt korrekt under ljusskillnader än konventionella 3D-material. Defärdiga materialen kan sedan appliceras på modellerade objekt med hjälp av en drag-n-drop teknik.Materialen använder färgrymden RGB som standard.

Animeringar i UE4 kan hanteras med ett sekvensverktyg där key frames för ett eller flera objektsposition, rotation och skala i 3D-världen sparas. Då objektet ska förflyttas, roteras eller skalas placerasnya key frames ut i en tidslinje. Olika objekt kan kopplas till olika animeringar som aktiveras vid olikatillfällen under körtid.

2.2.1 Villkor

UE4 använder en distribueringspolicy som säger att användare får använda, utveckla och distribueraprodukter gratis tills dess bruttointäkter överskrider 3000 dollar under ett kvartal. Efter att det sker enfem procent royaltyavgift på produkter sålda över 3000 dollargränsen [6].

2.3 Open CV

OpenCV, Open Source Computer Vision Library, är ett mjukvarubibliotek för datorseende och maski-ninlärning med öppen källkod. OpenCV utvecklades för att tillhandahålla en gemensam infrastrukturför datorseende-applikationer och att påskynda utvecklingen av maskininlärning i kommersiella pro-dukter. Biblioteket har en stor mängd algoritmer som innehåller en omfattande uppsättning av bådeklassisk och modern datasyn samt maskininlärnings-algoritmer. Relevant för detta projekt är att Open-CV tillhandahåller algoritmer för att identifiera objekt, klassificera mänskliga handlingar i videoklipp,spåra kameraförflyttningar samt spåra rörliga objekt. OpenCV lutar sig huvudsakligen mot realtids-visningsapplikationer [7].


2.4 Databas för bilder

För att lagra filer i form av bilder i en databas kan cloud-databaser användas. En cloud-databasfungerar som en vanlig lokal databas med skillnaden att kommunikationen med databasen sker viainternet snarare än över ett LAN (local area network), en visuell förklaring visas i figur 2.4. Då behövsinte någon lokal hårdvara som databas vilket medför att utvecklare kan koppla upp sig till databasenoavsett vart de befinner sig. Cloud-databaser kan ha tredjeparts-API:er för att förenkla integreringmed andra applikationer. [8].

Figur 2.4: Skiss på skillnaden mellan en cloud-databas och en lokal databas.

2.4.1 Imgur

Imgur är en så kallad online image sharing community vilket är en webbplats där användare kanse, kommentera och rösta på bilder som andra användare har publicerat. Via hemsidan går det attpublicera bilder anonymt eller via ett Imgur-konto. Fördelarna med att publicera bilder via ett kontoär att kontoskaparen då kan behandla sina bilder efter att dem blivit publicerade. Användaren kan dåtill exempel redigera eller radera bilderna samt skapa dolda eller offentliga album. Sedan 2015 harImgur inte haft någon gräns på hur många bilder som får publiceras per konto [9].

Imgur har ett eget API kallat Imgur API som visar hela Imgurs infrastruktur genom ett standardiseratprogrammatisk gränssnitt [10]. Allt användarna kan göra via hemsidan går även att göra med kodvia Imgurs API. Imgur API:t är dessutom ett RESTful API vilket betyder att det använder HTTPförfrågningar för att hämta, uppdatera, publicera och radera data. Svaret återfås sedan som JSONkod [11]. Imgurs API stödjer en variation av programmeringsspråk exempelvis PHP, javascript ochpython.

Den senaste versionen av API:t använder OAuth 2.0 vilket är ett protokoll för auktorisering. Dettagör att alla förfrågningar som skickas krypteras och skickas via HTTPS (Hypertext Transfer ProtocolSecure). Emellertid kräver detta registrering av applikationen på Imgurs hemsida. Den registreradeapplikationen kopplas vidare till ett konto och detta konto kan sedan styras helt med hjälp av API:t.


2.5 ShareX

ShareX är ett gratisprogram som tillåter användaren att ta en skärmdump. Programmet kan vidareladda upp skärmdumpen direkt till en vald image hosting service, vilket ger möjlighet att direkt spridabilden. ShareX ger även användaren möjlighet att automatiskt publicera bildvideofiler från en mappså fort det skapas en ny fil i den. Programmet är skriven i programspråket C# i ramverket .NETFramework och är open source. ShareX är integrerad med flera image hosting API:er, bland annatImgur API:t [12].

2.6 Existerande forskning kring inlärningsspel

Inom området för inlärningsspel även kallat spelbaserad inlärning finns en hel del forskning ochartiklar över spelens potential [13]. Björn Berg Marklund menar att detta lett till fler argument föratt integrera spelen mer och mer i de formella läroplanerna. Emellertid verkar forskning kring hurdessa spel ska utvecklas och i vilka sammanhang de används bäst, existera i ringare omfattning. IMarklunds doktorsavhandling försöker han dock ge några exempel på områden att tänka över vidutveckling av inlärningsspel. Marklund nämner olika teorier som analyserar och diskuterar olika per-spektiv på inlärningsspel och hur olika utvecklingsstrategier krävs för olika användningsområden.För att förklara teorierna delas spelens tilltänkta användningsområden upp i fyra läger: learning-ingameplay-lägret, gameplay-in-learning-lägret, learning-first-lägret och gameplay-first-lägret. Detsistnämnda, gameplay-first, är applicerbart på chroma key-projektet och utreds därmed vidare.

2.6.1 Gameplay-first

Gameplay-first metoden är applicerbar när spelet framförallt är tänkt att inspirera och introducera nyamoment men inte har ett specifikt inlärningsmål för användaren. Fokus ligger på spelhistorien och attuppmuntra nyfikenheten hos användaren. Det nyfunna intresset kan sedan diskuteras vidare i grupperoch på så sätt fördjupa kunskapen [13]. Även Nyström och Mustaquim nämner just spelhistorien ochhur den kan uppmuntra användarens fantasi som en viktig dimension hos inlärningsspelet [14]. De taräven upp två andra dimensioner, spelregler och den tekniska plattformen, som måste verka motiveran-de för användaren. Spelreglerna ska vara tillfredsställande med avseende på svårighet och utmaning.Användaren måste förstå vad den ska göra även om exakt hur momentet ska utföras kan vara mindrerättframt. Detta tillför struktur och tillåter användaren att förlita sig på sina egna kunskaper. När an-vändaren sen upplever att den egna kapaciteten är tillräcklig förstärker det den positiva upplevelsen.Vidare bör den tekniska lösningen vara anpassad efter historia och spelregler för att ge användarenmöjlighet att utnyttja den till dess fulla potential.


2.7 Ordlista

Tabell 2.1: OrdlistaOrd Förklaring

AlphamaskEn svartvit bild där det vita i bilden blir opak och det

svarta blir genomskinligt.

PerforceEn programvara som används för bl.a.

applikationsutveckling och versionshantering

Repository En central plats där data sparas och hanteras

Depot Perforce namn på Repository

FBX Filformatet för att spara modellerade objekt

Greenscreen Eng grön skärm som används vid chroma key

GUIGraphical User Interface ( Svenska: Grafiskt

användargränssnitt)

HTTP

Hypertext Transfer Protocol, kommunikationsprotokoll

som används för överföring av bl.a HTML-dokument och

bildfiler

HTTPSEtt protokoll för krypterad transport av data för HTTP-

protokollet

ImgurOnline bilddelningsgemenskap och Image hosting service

Image Hosting serviceEn tjänst som gör det möjligt att ladda upp bilder till en

webbplatsp på Internet

JSONJavaScript Object Notation, är ett kompakt, textbaserat

format som används för att utbyta data

KeyframeInom datoranimation eller tecknad film är en bild som

definierar startpunkt eller slutpunkt för en mjuk rörelse

Luminiscens Variabel för ljusinformation

MATLAB

MATLAB är ett datorprogram och programspråk från

företaget MathWorks som är främst används för

matematiska och tekniska beräkningar

MorfologiTeori och teknik som används inom digital bildbehandling

vid analys och behandling av geometriska strukturer

OpenCV

Ett programvarumiljö som tillhandahåller funktionalitet

som del av större programvaruplattform för att

underlätta utveckling av programvaror, produkter och

lösningar

RamverkDatastruktur på disken som lagrar metadata för en

uppsättning filer eller en katalogstruktur

RGBFörkortning för rött, grönt och blått, grundfärgerna i ett

färgsystem för additiv färgblandning

UE4 Unreal Engine 4

Kapitel 3

Utvecklingsprocess

För att strukturera och organisera projektarbetet utvecklades en organisationsstruktur. I följande ka-pitel presenteras en ingående beskrivning av bland annat mötesrutiner, tidsplan och dokumentations-hantering.

3.1 Scrum

Utvecklingsmetodiken som använts är baserad på den agila metoden scrum. Precis som scrum före-språkar delades arbetet upp i utvecklingsperioder kallade sprintar. Utvecklingsmetoden scrum innefat-tar även en scrummästare. Scrummästaren valdes ut vid projektstart och såg till att alla möten följdede agila processerna och ansvarade för dokumentationen av alla projektmöten. Fler ansvarsområdendefinierades, tilldelades och tas upp i bilaga B.

3.1.1 Produktbacklogg i HacknPlan

Vid projektstart skapades en produktbacklogg innehållande ett flertal poster som utformats av pro-jektgruppen utifrån användarhistorier. Användarhistorierna sammanställdes i sin tur utifrån kundenskrav och visioner. Ett exempel på en användarhistoria är ”Som besökare vill jag kunna ladda ner entagen bild utan att ange några personuppgifter” och en av flera poster utifrån exemplet skulle dåkunna vara ”Implementera bildtagning i UE4”.

Produktbackloggen skapades och uppdaterades i projekthanteringsprogrammet HacknPlan. Hackn-Plan är ett projekthanteringsprogram för spelutveckling som är stark influerat av agila systemutveck-lingsmetoder [15]. I HacknPlan sorterades och organiserades alla poster genom att rangordna demmed avseende på vad som var viktigast. Vid ny sprintstart valdes sprintens poster ut och placeradespå en kanban board dedikerad för just den sprinten. En kanban board kan vara allt från en fysik tavlamed post-it-lappar till digitala versioner som i HacknPlan. Figur 3.1 visar HacknPlan med en typiskkanban board i en sprint. I HacknPlan skapades även mindre uppgifter för varje post som gjorde detlättare att avgöra om posten skulle bli klar i tid eller inte.

10

KAPITEL 3. UTVECKLINGSPROCESS 11

Figur 3.1: HacknPlans kanban board under en sprint.

3.1.2 Sprintar

Varje sprint varade i 10 dagar. Under en sprint hade projektgruppen som mål att utföra en hel utveck-lingsiteration inkluderande framtagning av prototyp, testning och utvärdering av eget arbete. Varjesprint innehöll också möten för sprintstart, sprintavslut samt korta dagliga möten. Figur 3.2 visar ettexempel på hur en sprint kunde se ut.

Figur 3.2: Sprintschema med möten som projektgruppen följde under projektet.


3.1.3 Mötesrutiner

Under sprintstarts-mötet uppdaterades alla posternas progression i HacknPlan och en plan för helasprinten skapades. Projektgruppen såg över sitt schema de kommande två veckorna och alla träffaroch möten fastställdes. Mötet varade mellan en till två timmar.

De kortare dagliga mötena på ca 15 minuter påminde om scrums dagliga möten där varje individ iprojektgruppen berättade vad de gjort förgående dag och vad de skulle göra härnäst. Mindre mot-gångar kunde diskuteras under det dagliga mötet men vid större problem bokades ett separat möteför de inblandade. Dagliga möten behövdes inte alltid och många av dom hölls i Discord i form avett grupp-samtal med samtliga i utvecklingsgruppen. Discord är en gratis röst- och text-chattserverursprungligen utvecklad för att skapa spelgemenskaper [16].

Inför varje sprintavslut hölls ett utvärderingsmöte och en kvalitetssäkring av producerad kod i formav en gruppgranskning. Under utvärderingsmötet analyserades sprinten och diskussioner hölls omsprintens effektivitet, vilka poster som inte har blivit färdiga i tid och varför. Under mötet diskuteradesäven projektgruppens arbete och dynamik för att avgöra om nästa sprint borde se annorlunda ut. Undergruppgranskningen analyserades kodens kommentarer och refaktorering utfördes vid behov. Mötetvarade oftast mellan en till två timmar.

3.2 Tidsplan

Under projektstart skapades en tidsplan som skulle följas under projektets gång och anpassas allt ef-tersom arbetet fortskred. En detaljerad tidsplan kan ses i Gantt-schemat i bilaga A. Vidare planeradesrespektive sprint vid sprintstart och då jämfördes även sprintplanen med tidsplanen. Nedan är plane-ringen för de olika sprintarna övergripligt presenterade.

Sprint 0 Under sprint 0 utfördes förstudier och förberedelser. Ramverk, bibliotek och ett versions-hanteringssystem bestämdes och installerades. Detta för att implementering av systemet skulle kunnapåbörja under sprint 1.

Sprint 1 Målet för sprint 1 var att kunna läsa in videofilen från kameran in i UE4 och utföra bildbe-handlingsmetoden chroma key i realtid. En första skiss av användargränssnittet var också ett mål försprinten.

Sprint 2 Målet för sprint 2 var att en första prototyp skulle vara färdig att visa kunden. Den förstaprototypen skulle innehålla en enkel miljö med ett berg och ett lysande material. Det skissade använ-dargränssnittet skulle implementeras i UE4 och fungera tillsammans med den skapade miljön.

Sprint 3 Målet under sprint 3 var att implementera interaktionen mellan användaren, objekten i miljönoch användargränssnittet. Nedladdningen av en bild med inkluderande delmoment som en hemsidaoch en länk för nedladdning skulle vara implementerade.

Sprint 4 Målet var att inleda sprint 4 med användartester som skulle uppmärksamma ifall någraförbättringar eller förändringar behövdes. Dessa förändringar/förbättringar skulle sedan utföras underresterande tid av sprinten.

Sprint 5 Sprint 5 är den sista sprinten och målet med sprinten var att paketera, kalibrera och levereradet färdiga systemet till kunden. Innan dess skulle systemet också stress-testas och analyseras.


3.3 Versionshantering

Under utvecklingsprocessen användes versionshanteringssystemet Perforce som då kopplades direkttill UE4. Perforce tillåter användare att ansluta till en central servers repository med hjälp av program-varan P4V. Utvecklare som arbetar med Perforce laddar ner en egen version av serverns depot ochskapar en eller flera workspaces vilket är kopior av den lokala depot:en.

Filer som ska redigeras checkas ut av utvecklaren och låses därmed för resterande utvecklare. Inteförrän den senaste redaktören blivit klar med filen och checkat in den igen kan andra utvecklarechecka ut den. UE4 och Perforce samspelar vidare på så sätt att UE4:as GUI visar vad alla utvecklareanvänder genom att en blå bock markerar de filer som är utcheckade av någon annan. UE4 visar vilkanya objekt som inte finns med i serverns depot genom att markera med frågetecken på de nya filernaoch ett plustecken på de som har blivit markerade för tillägg [17], se figur 3.3.

Figur 3.3: Ett exempel på hur Perforce ser ut i UE4 med markörer.

3.4 Dokumentationsprinciper

Den agila strukturen kräver att all kod och alla blueprints kommenteras och dokumenteras på ettrutinmässigt sätt. Detta så att all kod kan förstås utan muntlig förklaring. I färdig kod kommenteradesklasser övergripligt men även enskilda funktioner fick någon kort kommentar. Kommentarer i UE4skrevs framförallt i de blueprints som användes för själva chroma key-operationerna av kameraflödet.För att göra det infogades textrutor direkt i den blueprint som hade anknytning till den nod som skulleförklaras. Se exempel i figur 3.4. Ingen enskild projektmedlem ”ägde” sin egen kod. Det fanns därfören ömsesidig strävan efter att så många som möjligt skulle kunna läsa och dra nytta av all kod somskrivits.

I fråga om dokumentation av de olika mötesprotokoll fördes alla mötena av någon på mötet utseddsekreterare. Av logistiska skäl var sekreteraren oftast scrummästaren men viss rotation av postenförekom. Vilka möten som protokollfördes redovisas i tabell 3.1. Där visas även hur de sparades.

Tabell 3.1: Protokoll under projektet

Mötestyp DokumentationstypSprintplaneringsmöten Löpande i ett och samma dokumentDagliga möten Löpande i ett och samma dokumentUtvärderingsmöten Löpande i ett och samma dokumentKodgranskningsmöten Löpande i ett och samma dokumentHandledarmöten Separata dokument för varje möteKundmöten Separata dokument för varje möte


Figur 3.4: Exempel på kommentarer i blueprints

Alla protokoll sparades i en gemensam Google drive-mapp till vilken alla projektmedlemmar hadetillgång. De olika scrum mötena protokollfördes i ett och samma löpande dokument för respektivemötestyp. Detta för att enkelt kunna söka och hitta gamla beslut och diskussioner.

3.5 Kvalitetssäkring

Kvalitetssäkring av kod och blueprints skedde löpande under hela arbetsprocessen men blev intensi-vare i takt med att större delar av systemet blev färdigt. Kodgranskning har gjorts på två olika sättunder arbetets gång. Dels i mindre grupper där alla i gruppen var insatta i posten och dennes oli-ka uppgifter och dels i helgrupp när kod eller blueprints var färdiga att läggas in i systemet. Dengemensamma kodgranskingen skedde i samband med sprintavslut då alla projektets medlemmar varnärvarande. Vad gäller ren kod diskuterades framförallt kommentarer och kodeffektivitet under kod-granskningen. När det kommer till blueprints tog granskningen en annan form. Eftersom ingen egenkod producerats där låg fokus mer på hur flödet genom funktionerna skapats. De som inte var insattai posten började med att kolla igenom de färdiga blueprints. De fick sedan chansen att ställa frågoroch ge kommentarer. I vissa fall gjordes ändringar för att skapa ett mer intuitivt och förståeligt flöde.Vid behov kompletterades även blueprints med fler kommentarer för att förklara hur noderna hängdeihop.


3.6 Systemarkitektur och modellering

I början av varje sprint gjordes en övergripande skiss över systemet likt figur 3.5 på en whiteboardeller på papper. Skisserna gjordes för att öka gruppens förståelse för systemet och verka som diskus-sionsunderlag. Utöver det gjordes enklare skisser för att förstå mindre problem.

Under projektets gång har systemets planerade innehåll förändrats mellan sprintar även om någrahuvudenheter har varit konstanta. Detta ledde till att den övergripande modellen för systemet föränd-rades under projektets gång.

Figur 3.5: Övergripande skiss av systemet.

3.7 Källor och referenser

De flesta referenser och källor som har använts under projektets gång har varit dokumentationssidorskrivna av respektive ramverk eller bibliotek. Vissa dokumentationssidor har emellertid inte uppda-terats på ett tag. I dessa fall studerades forum och liknande för att få information om någon annanutvecklare visste mer om exempelvis en specifik funktion.

UE4 är ursprungligen till för spelutvecklare och inte för bildbehandling med chroma key i realtid. Pågrund av detta var det ibland svårt att hitta både dokumentation och vetenskapliga artiklar om justdenna kombination. Relevant information söktes därför även i videos, böcker eller forumtrådar.

Kapitel 4

Implementering

Nedan beskrivs processen för att implementera systemet.

4.1 Förstudie och Sprint 0

Arbetsprocessen startade, som nämnt i kapitel 3.1.2, med sprint 0 samt en förstudie som sedan lågtill grund för den teorin som användes i projektet. Teorin är densamma som presenterats i kapitel 2.Versionshanteringssystemet sattes upp och grundläggande kunskap delades mellan alla projektmed-lemmar som då fick en kunskapsgrund att utgå ifrån.

Under denna process skrevs även användarhistorier för att definiera vad kunden, handledaren ochutvecklarna ville få ut av det färdiga systemet. Dessa användarhistorier konkretiserades sedan tillriktiga poster som rangordnades i samråd med kunden. När posterna var rangordnade fördes de in iproduktbackloggen.

Sammanfattat kan mycket av tiden beskrivas som overhead. Karakteriserande för denna fas var attmycket av projektets brainstorming och idéskapande gjordes. Inga idéer slogs ner direkt utan fickförst chans att undersökas närmare. Det var även då de organisationsstrukturer inom projektgruppensom beskrivs i kapitel 3 togs fram och i viss utsträckning testades i praktiken för första gången.

4.2 Chromakey

I början av projektet utfördes ett chroma key-test i MATLAB för att bättre förstå hur chroma key-operationerna fungerade. Testet gick ut på att förstå och se resultatet av morfologiska operationer isamband med chroma key.

Testerna i MATLAB ledde vidare till tester i UE4:as materialskapare. Där implementerades ett mate-rial som dels skapade en alfamask som gjorde att pixlar med den valda skärmfärgen blev transparenta.Även en despill-mask skapades. Detta material applicerades sedan på ett bilboard-objekt med vide-oflödet.

För att skapa alfamasken användes en kopia av videoflödet. Först normaliserades bilden för att ta bortluminiscensen. Detta för att omfånget av nyanser i bilden skulle bli mindre och ljusskillnader ellerskuggor på greenscreenen skulle försvinna. Denna metod att ta bort luminiscens kan emellertid ledatill artefakter i kanterna på alfamasken.

Den normaliserade bilden jämfördes sedan med den gröna referensfärgen och differensen blev en bildi gråskala. Ett maximum- och en minimum-värde bestämdes till 0.73 respektive 0.7. Pixlar med vär-

16

KAPITEL 4. IMPLEMENTERING 17

den under minimum gjordes transparenta och pixlar med värden över maximum gjordes helt synliga.Pixlar med differensvärden mellan minimum och maximum skalades linjärt från transparent till heltsynlig. Detta generade alfamasken där de synliga pixlarna hade värdet ett och de transparent värdetnoll. Denna process visas i 4.1.

Figur 4.1: Bilden visar originaldelen, normalen av bilden, jämförelse mellan normalbilden och engrön referensfärg och en alfammask.

En till kopia av bilden användes till despill-operationen som skulle ta bort det gröna reflekteradeljuset från objektet. Första steget var att skapa en ny alfamask av kopian fast nu med både maximum-och minimumvärde satt till 0.9. Sedan inverterades alfamasken och subtraherades från den förstamasken. Resultatet blev en dispillmask som representerar konturerna av objektet. Pixlar definieradeav dispillmasken färgades lila istället för gröna för att anpassas till färgskalan i den virtuella miljön.Vägen från den originella bilden och slutprodukten visas i figur 4.1 och 4.2 [18].

Figur 4.2: Bilden visar en despillmask, applikationen av den och den slutgiltiga produkten

4.3 Virtuell miljö

Den virtuella miljön som skapades utgick från kundens idéer och behov samt studerad forskning ochteori som nämnts i kap 2.6. Utvecklingsprocessen delades upp i två delprocesser, en designprocessoch en implementeringsprocess.

4.3.1 Designprocess

Designprocessen inleddes med en diskussion om vilken känsla som skulle förmedlas och hur miljönpå ett bra sätt skulle komplettera resterande delar av kundens utställning. Potentiella objekt listadesoch vägdes mot varandra. Målet var att skapa en intressant miljö med några överraskningselement somgärna fick ha potential att göras dynamiska. I enlighet med presenterad teori, se kap 2.6, utveckladesmiljön för att engagera användaren och uppmuntra egen fantasi. Detta gjordes genom att välja utenkla objekt och designa dem något surrealistiska. På så sätt tillåts användaren själv att bilda sin egenuppfattning om miljön och dennes innebörd.

Parallellt med arbetet att skissa och planera objekten i miljön utvecklades färgdesignen och ljussätt-ningen. Färgmässigt var ledorden från kunden Kung Fury och piña colada. Deras moodboard visas ifigur 4.3.


Figur 4.3: Moodboard från kund.

Med kundens moodboad som grund utvecklades en egen moodboard som var mer anpassat till självachroma key-stationen och den miljön som faktiskt skulle implementeras. Resultatet visas i figur 4.4.

Figur 4.4: Moodboarden som utvecklades i samband med designprocessen.

Färgschemat skapades utifrån en rosa färg plockad från Kung Fury-bilden i figur 4.4 med en appli-kation kallad Adobe Capture. Resterade färger och nyanser valdes med hjälp av mColorWheel. Bådaapplikationerna kan hämtas från länkarna [19] respektive [20].


4.3.2 Implementering av miljön

Efter designprocessen påbörjades arbetet med att implementera miljön. De objekt som slutligen valtsut modellerades alla från grunden i Blender och exporterades sedan till FBX filer för att kunna im-porteras i UE4. Objekten modellerades i en low-poly-stil för att ett material som skapades i UE4skulle kunna markera de ”kanter” som då uppstår. Se figur 4.5. Denna typ av design valdes för att geanvändaren en övergripande inblick i hur modelleringen gjorts och hur polygoner ser ut.

Figur 4.5: En luftballong i low-poly stil med ett material som markerar kanterna i UE4.

Allt eftersom objekten blev färdigmodellerade placerades de in i UE4 och kopplades till det tidigarenämnda materialet. Val av de olika objektens färger gjordes efter moodboarden. Slutligen implemen-terades animeringar för de objekt som skulle vara dynamiska.

4.4 Användargränssnitt

För att styra systemet krävdes ett användargränssnitt som användaren skulle kunna hantera utan fy-siska reglage. Användargränssnittet implementerades gradvis med designskisser, formgivning ochimplementering i UE4.

4.4.1 Tidig designprocess

Grundidén för användargränssnittet diskuterades redan under sprint 0. Då skapades en skiss på huranvändaren utnyttjade ikoner för att styra systemet, se figur 4.6.

I figur 4.6 syns också ikonerna som sedan vidareutvecklades under projektet gång. Innan ikonernaformgavs användes platshållare för att tillåta ett tidigt test av implementeringen i UE4.

4.4.2 Implementering

När grundskissen och implementeringstesterna var utförda startade designprocessen för egna ikoner.De 4 ikonerna som togs fram var kameraikonen för att kunna ta en bild, soptunneikonen för att slänga


Figur 4.6: En tidig skiss av användargränssnittet med ikoner.

bilden samt nerladdningsikonen och tillbakaikonen som är formgivna som pilar. Pappers-skissen påtvå av ikonerna kan ses i figur 4.7.

Figur 4.7: Tidig skiss av kameraikonen (för att ta en bild) och papperskorgs-ikonen (för att ta bort enbild) med tidiga idéer om tema och färg.

Efter att ikonerna var färdigskissade formgavs de i programmet Adobe Illustrator. Ikonerna framtogsbåde i en detaljerad version och i en enklare version men efter tester valdes de senare. När ikonernavar färdiga lades de in i olika widgets som representerade de olika användarvyerna; huvudvyn - detvill säga den vyn användaren möts av i startläget, vyn som visar bilden, och vyn som visar länken.

4.5 Interaktion mellan användare och system

För att interagera med systemet ska användaren hålla handen bakom den knapp användaren vill akti-vera. För att göra detta implementerades funktioner i C++ och openCV som jämförde bildinnehålleti knappområdet mellan olika bilder. Varannan bild sparades som referensbild som nästa bild sedanjämfördes med. För att göra jämförelsen konverterades samtliga bilder till gråskala och ett Gaussian-Blur-filter applicerades. Sedan beräknades den absoluta skillnaden mellan nuvarande bild och dennesreferensbild och sparades i en ny bildmatris. Den nya bildmatrisen trösklades och utvidgades viadilation, följt av en beräkning av antalet konturer i bilden. Om antalet konturer överskred det mini-mumvärde som bestämts registrerade programmet detta som en förändring. Efter ett bestämt antalförändringar på en knapp markerades knappen som aktiverad med en booleanvariabel. Efter testerfastställdes gränsen för antalet förändringar till 16 stycken.

När funktionen för att aktivera knapparna var implementerad kopplades koden ihop med level-bluprinti UE4 som sköter integreringen av kodklasser i själva editorn. I blueprintet kopplades sedan boolean-variablerna till ikonerna i gränssnittet samt funktioner för att visa de olika användarvyerna.


4.6 Funktionaliteten att ta och spara en bild

Systemet hade många funktioner och krav. Ett av de största kraven var att kunna ge användaren ensouvenir i form av en digital bild. Alltså att användaren på något sätt ska kunna ladda ner bilden somtogs i systemet genom att använda en länk.

4.6.1 Spara en bild

Bilden som tas under användning skulle vara en bildruta av vad den virtuella kameran i UE4 såg. Detär även den virtuella kamerans bild som projiceras av projektorn framför användaren. Bilden i frågasparades i första hand lokalt på datorns hårddisk.

Ta-bild-funktionen implementerades i en C++ klass med hjälp av UE4 funktionen FScreenshotRe-quest::RequestScreenshot som återfinns på UE4 dokumentationens hemsida [21]. När ta bild-funk-tionen kallas tas den tidigare sparade bilden bort och en ny läggs till med samma namn. Detta ledertill att det alltid är max en bild lagrad på den lokala hårddisken.

4.6.2 Visa bilden

För att visa den tagna bilden användes funktioner i UE4 som kan ladda in bilder från en lokal mapppå datorn. Eftersom bilden alltid sparades med samma namn kunde alltid samma sökväg användas föratt hitta bilden.

4.6.3 Ge användaren tillgång till bilden

För att ladda upp den tagna bilden på webben och vidare ge användaren tillgång till den användesprogrammet ShareX. ShareX konfigurerades till att ständigt läsa av innehållet i den mapp där “tabild”-funktionen sparade de tagna bilderna. Varje gång en ny bild skapades laddade ShareX upp dennya bilden till ett förutbestämt, dolt album på hemsidan Imgur.com [22]. När bilden laddades uppsparades länken till den i datorns urklipp. För att visa användaren länken skapades en C++ funktionsom kopierade innehållet i urklippet till en variabel som kunde visas i användargränssnittet.

4.6.4 Automatisk borttagning av bilder

För att inte ha för många bilder i Imgur albumet ska de ske en form av rensning genom att Imgur varjemorgon tar bort albumet. Detta betyder även att användarens länk bara varar fram till nästa morgon.Resningen implementerades via ett javascript på en extern hemsida. Detta krävde dock att hemsidanmåste vara uppe och köras på åtminstone en enhet för att kunna utföra rensningsfunktionen. Av dennaanledning är det en krav att hemsidan ska auto-startas tillsammans med UE4-programmet och körs ibakgrunden.

Kapitel 5

Resultat

Projektet resulterade i en chroma key-station där användare kan se sig själva i en virtuell miljö. Ka-pitlet behandlar den resulterade systemarkitekturen samt en beskrivning av systemet.

5.1 Systemarkitektur

I figur 5.1 visas systemets systemarkitektur. För att programmet ska fungera korrekt krävs en gre-enscreen som ska vara placerad bakom användaren. UE4-programmet och kameran kommunice-rar med OpenCV. UE4-programmet utför sedan chroma key-operationen och skickar informationentill datorns grafikkort som skriver ut en bild till skärmen. Användaren kan interagera med Unreal-programmet genom att röra sig framför kameran.

Då användaren väljer att ta en bild sparar UE4-programmet en skärmdump på den lokala hårddisken.Programmet ShareX kollar kontinuerligt den mapp vilken skärmdumparna sparas i och laddar uppvarje nyligen skapad bild till ett dolt album på hemsidan Imgur. ShareX kopierar den nya bildlänkentill urklipp. UE4-programmet läser in länken från urklippet och skriver ut den på skärmen. En hemsidakommunicerar med det tidigare nämnda albumet genom Imgur’s API och raderar alla bilder varjemorgon.

Figur 5.1: En skiss av översiktlig systemarkitektur.

22

KAPITEL 5. RESULTAT 23

5.2 Beskrivning av systemet

Systemet tar användaren till ett neonfärgat fantasiland. Figur 5.2 visar ett exempel på hur systemet kanse ut vid början av användningen. I figuren syns den slutgiltiga miljön med berget i bakgrunden, enblomma, en bladväxt, 3 palmer, 3 kuber och den animerade ballongen som flyger runt. Färgsättningenär gjord efter moodboarden presenterad i kap 4.3.1.

Figur 5.2: Resulterande bild av huvudvyn när två personer använder systemet.

Uppe till höger finns en kameraknapp som användaren kan interagera med och aktivera för att ta enbild. När användaren vinkar framför knappar fylls en progress bar runt om ikonen så att användarenfår återkoppling på hur länge den måste vinka. När just kameraknappen är aktiverad startas en ned-räkning från 3 och sedan tas en bild i samband med att skärmen blir vit för att likna en blixt. Figur 5.3visar vad användaren möts av när bilden är tagen.

Figur 5.3: Vyn som användaren ser efter den tagit en bild.

KAPITEL 5. RESULTAT 24

Kameraknappen byts ut mot en laddaner-knapp i form av en grön pil och en släng-knapp i form av enröd soptunna. Mitt på skärmen visas bilden så att användaren kan se hur den ser ut. Väljer användarenatt slänga bilden återgår systemet till huvud-vyn där kameraknappen syns. Väljer användaren däremotladdanerknappen visas istället vyn i figur 5.4.

Figur 5.4: Vyn användaren ser om den valt att få länken till bilden.

Då visas förutom bilden en länk till Imgur varifrån användaren kan ladda ner sin bild till en egenenhet. Med hjälp av pratbubblor från en räv och en robot upplyses användaren hur nedladdningen gårtill och att bilden raderas nästa morgon. Uppe till höger syns nu en tillbaka-knapp i form av en blå pilriktad åt vänster. I figur 5.4 syns även hur en knapp ser ut när användaren försöker aktivera den.

Knapparna är inaktiverade i 2 sekunder varje gång vyn äntrats. Detta för att användaren inte skaaktivera en knapp av misstag innan den förstått vad knappen gör. När en knapp ska aktiveras jämförsystemet varannan bildruta i knappområdet. Bilden i knappområdet måste förändras 16 gånger för attknappen ska aktiveras. Om inga förändringar har skett i området dras räknaren för förändringarna neren enhet varannan bildruta.

I nuläget är den virtuella kameran statisk vilket innebär att användaren inte kan se mer av miljön ändet som visas från start. Bildfrekvensen från kameraflödet är mellan 25–30 bilder/sekund och klarardärmed hastiga rörelser från användaren. Kameraflödet färgbehandlas och görs lite rosa/lila för attanvändaren ska passa in mer i bakgrunden.

Kapitel 6

Analys och diskussion

I detta kapitel presenteras en analys och diskussion kring projektets arbetsmetod, slutprodukt, poten-tial för vidareutveckling och påverkan utifrån etiska perspektiv.

6.1 Metod

Den agila arbetsprocessen som presenterats i kap 3 har använts i så stor utsträckning som möjligt.Problem uppstod under perioder då andra kurser samt högtider krockade med tidsplaneringen. Mångadagliga scrummöten blev då inställda och framförallt uppehölls inte utvecklingshastigheten. Dettadiskuteras mer i kap 6.3.3.

Mycket av arbetet gjordes enskilt. Att inte parprogrammera utan istället dela upp poster och uppgiftergjorde att varje gruppmedlem kunde arbeta individuellt. På så sätt effektiviserades arbetet. Vid störreproblem som den enskilde projektmedlemmen inte kunde lösa samlades dock hela eller delar av pro-jektgruppen och hjälptes åt. Vid några tillfällen väntade gruppen för länge innan den gemensammainsatsen gjordes. Då förlorades mycket tid som kunde sparats ifall alla hjälpts åt tidigare.

Något som hindrade gruppmedlemmarna från att arbeta tillsammans i grupp var att alla inte hadebärbara datorer med möjlighet att använda UE4. Vid gruppmöten kunde därmed inte alla testa idéerdirekt. Detta är värt att nämna trots att det inte kunde undvikas. Emellertid bidrog det även till attmöten hölls så korta och koncisa som möjligt. På så sätt förlorades ingen tid på onödiga diskussioner.Sammanfattningsvis har arbetet med projektet fungerat väl och underlättats tack vare ett gott humör iprojektgruppen samt gemensamma sol-pauser.

6.2 Resultat

Systemet har fortfarande några brister. En synlig brist är att skärpan på användaren är en aning oskarp.Oskärpan på användaren påverkas delvis av kameran och en bättre kamera kommer att förbättra bildeni sin helhet. Uppdateringsfrekvensen däremot är ok och systemet har en bildhastighet mellan 25-30bilder/sekund.

6.2.1 Aktivera knapparna

När en användare vinkar framför en knapp är det ibland svårt att aktivera den. Detta kan bero påljussättning alternativt att kameran i systemet ger en bild med otillräcklig skärpa, färg och kontrast.

25

KAPITEL 6. ANALYS OCH DISKUSSION 26

Vid tester blev en del användare irriterade när rörelser inte registrerades direkt. Problemet skulle kanlösas med en bättre kamera alternativt att algoritmen som kollar om förändringar skett i bildrutanjusteras lite.

6.3 Svårigheter

Utvecklingen av projektet skedde inte smärtfritt och det förekom vissa svårigheter under projektetsgång. Allt från tekniska svårigheter till tidsplanering.

6.3.1 Versionshantering

Det valda versionshanteringssystemet Perforce var projektets tredje versionshanteringssystem. Initialttestades versionshantering i Visual Studio som använder Git. Detta system fungerade inte om man intebetalade eftersom maxantalet utvecklare i ett team var 5 personer. Även det andra systemet användeGit men med GitHub och GUI:n Sourcetree. Detta fungerade inte då problem uppstod med att vissafiler ej kunde pushas och sammanfogning av filer inte fungerade för vissa projektmedlemmar.

Även Perforce hade problemet att maxantalet teammedlemmar var fem personer men efter kontaktmed Perforces kundtjänst berättade de att två personer kunde använda samma konto vilket löste pro-blemet.

6.3.2 Plugins

Projektet använde sig ursprungligen av ett plugin för att hämta in videoflödet från kameran. Vid när-mare inspektion visade det sig dock att förändringar i variabler såsom bildhastigheten eller bildstor-leken inte förändrade slutprodukten. Paketering av projektet fungerade inte heller då de plugin somanvändes inte följde med i det paketerade projektet. Detta resulterade i att en ny videokamera-klassskrevs och att inga andra externa plugin kunde användas.

6.3.3 Tidsplanering

Redan tidigt i projektplaneringen gjordes insatser för att strukturera och planera det kommande ar-betet. Inga detaljer bestämdes utan endast övergripande milstolpar och leverabler. Under projektetsgång har en rad oväntade och oplanerade händelser inträffat som på olika sätt påverkat tidsplanen.Konsekvensen blev att projektet inte avancerade i den hastighet som först planerats vilket i sin turexempelvis resulterade i att inga riktiga användartester hann göras.

6.4 Metoder för att spåra användaren

Utöver den metod som används i projektet har ytterligare två metoder studerats.

6.4.1 Interaktion med hjälp av en Kinect

Den första metoden som studerades var med hjälp av en Microsoft Kinect-kamera. Kameran registre-rade hela kroppen och ett osynligt skelett placerades i miljön för att registrera rörelserna. När skelettet


fanns i scenen kunde skelettets position användas för interaktion. En av fördelarna med Kinect är möj-ligheten till kollision över hela skelettet, vilket ger möjligheten till enkla minispel.

Då Kinecten projektgruppen fick tillgång till var av den första versionen fanns enbart plugins till-gängligt för att ta hand om indata från en person åt gången. Tid fanns inte för att implemntera ett egetplugin och eftersom flera användare skulle kunna använda stationen samtidigt fungerade slopadeskinecten.

6.4.2 Interaktion med hjälp av kaskadklassificerare

Utöver Kinecten prövades även en metod för att spåra öppna och knutna händer. För att göra det kräv-des en kaskadklassificerare. En kaskadklassificerare berättar i grunden för OpenCV vad som ska letasefter i bilder. Det finns många kaskadklassificerare tillgängliga för nedladdning på internet. De flestaär för att känna igen ansikten, ögon, öron och mun. Projektgruppen behövde två kaskadklassificeraresom berättade för OpenCV hur man känner igen en öppen och en stängd hand.

Projektgruppen försökte generera en egen kaskadklassificering[24] och implementerade denna i sy-stemet. Resultat var dock inte tillförlitligt nog. Trots att programmet registrerade handen och det varmöjligt att ta en bild, förlorade den spårningen på handen om användaren rörde sig för mycket, var förlångt ut i hörnen eller för dåligt ljussatt. Även storleken på handen påverkade eftersom mindre händerregistrerades allt mer sällan än större. Detta kunde implementerats bättre om mer tid hade funnits ochbättre data till kaskadklassificeraren givits. Projektgruppen bestämde sig dock för att det alternativsom används i det slutgiltiga systemet var mer intuitivt.

6.5 Metoder för att spara och visa en bild

Nedan beskrivs de alternativ gruppen har undersökt för att låta användaren ta en bild och sedan visadenna bild för användaren.

6.5.1 Låta användaren ta en bild

Vid efterforskning kring eventuella lösningar framkom många olika sätt att spara en skärmdump ieditorn men inte under körtid. Efterforskningens fokus skiftade därför till att få tillgång till en virtuellkameras videoström under körtid. Tanken var att spara undan en bildruta från denna videoström istäl-let för att aktivt “ta en bild”. Ett “UTextureRenderTarget2D”-objekt används då för att kontinuerligtuppdatera en textur och sedan hämta bildinformationen från denna textur. Lösningen verkade lovandeoch implementering påbörjades. Denna metod var dock ett misslyckande då alla bilder som sparadesblev helt svarta.

Att slutligen välja att använda sig av funktionen RequestScreenshot som presenterats i kap4 ledde tillavsevärt mindre kod och gav bättre prestanda. Detta då den inte krävde att en textur uppdaterades ivarje bildruta. Den största svårigheten var egentligen att hitta funktionen då den inte dyker upp direktnär det görs skärmdumps-relaterade UE4 sökningar på Google.

Det var alltid tänkt att implementationen för att ta en skärmdump skulle ske inom UE4:s gränssnitt ut-an tredjepartsprogram. Om tredjepartsprogram hade använts istället för UE4 skulle eventuellt ShareXvara ett alternativ. Nackdelar är då att en skärmdump tas av allt som visas på skärmen istället förvad den virtuella kameran i UE4 registrerar. Det går då inte att använda sig av olika effekter för attindikera att en bild tas då dessa effekter även skulle hamna på bilden.


Tillgängliggöra bilden för användaren

Att ta en bild och spara lokalt var bara halva problemet, användaren skulle också få tillgång till bildenför eget bruk. Frågan var hur användaren skulle få tag på bilden i digitalt format.

Det som efterfrågades var en server kopplad till en hemsida från vilken användaren kunde ladda nersin bild. Någon form av säkerhet var viktig då endast användaren skulle kunna komma åt sin egenbild. Ett problem som tidigt uppstod med idén om att använda en server var att kunden inte hade enegen server tillgänglig. Detta var andningen till att Imgur interagerades med systemet.

Bilderna som användaren tar laddas upp i ett dolt album på Imgur. Detta betyder att endast de med rättlänk kan se och ladda ner bilden. Emellertid är det ändå en säkerhetsrisk att låta bilderna ligga uppe.Av denna anledning implementerades funktionen att radera bilderna med jämna mellanrum. C++klassen kopplad till UE4 kunde dock inte komma åt Imgurs API. Därför blev lösningen att skapa denexterna hemsidan som sköter hanteringen av Imgur-kontot. Det bästa vore såklart om systemet självkunde ordna detta men lösningen med hemsidan ansågs vara lättast och snabbast att implementera.Det stora nackdelen är dock att hemsidan måste köras i bakgrunden hela tiden för att fungera.

Nackdelar med att använda Imgur

Det finns både för och nackdelar med den metod som gruppen har implementerat. Att använda entredjepartshemsida för att “hosta” bilderna gör att gruppen själva inte behöver implementera en egendatabas men leder även till mindre kontroll.Efter att en bild har tagits bort är det inget som stopparImgur från att tilldela samma länk till en ny bild som laddas upp. Detta kan leda till att om en an-vändare använder deras tilldelade länk efter att deras bild har raderats kan de få tillgång till en heltannan bild. Detta är en allvarlig brist då en användare av stationen kan försöka öppna sin länk efter attsystemet tagit bort bilden. Viktigt att poängtera är att länkar sällan skrivs över så snabbt men i teorinär det möjligt. Imgur tillåter dessutom bilder av olämplig karaktär på dolda album. Olämpligt innehållkan vara nakenhet, pornografi, svordomar, våld eller annat störande ämne.

Då användaren skriver in länken som visats i programmet kan användaren också se andra bilder iImgurs rekommenderade bildflöde. Även om dessa bilder måste följa en mycket hårdare standard änför bilder i de dolda albumen så är detta negativt. Användaren kan exempelvis tro att bilden som togsär offentlig då användaren ser andra offentliga bilder. Kunden fick information om detta men tyckteändå lösningen var tillräckligt bra eftersom en egen server inte kunde tillhandahållas.

6.5.2 Visa och tillgängliggöra bilden via hemsida

Tidigt i projektet hölls diskussioner om att låta en extern hemsida visa både bilden och länken föranvändaren. I 6.1 visas en tidig skiss på hur hemsidan var tänkt att se ut. En version av hemsidansom hade funktionerna; visa bild, visa imgur-länk och generera/visa QR-kod skapades. Hemsidankopplades sedan till UE4 för att visas i gränssnittet. Efter några tester och olika design på hemsidan,beslöt gruppen dock att inte använda hemsidan till visning av bild och länk. Största anledningen varatt hemsidan inte uppdaterades tillräckligt snabbt. För hemsidan tog det cirka 10 sekunder för att fåfram bilden och länken efter uppladdning av bild. Det ansågs att vara alldeles för långsamt. På grundav att hemsidan inte kunde användas så som det var tänkt innebar det att lösningen för QR-kodeninte heller kunde användas. En ny lösning för QR-kod generering implementerades inte på grund avtidsbrist.


Figur 6.1: En tidig skiss av hemsidan. Hemsidan visar tre saker, bilden, länken och QR-kod till sammalänk. Dessa tre funktioner var tänkt att bli implementerad i hemsidan

6.6 Chroma key-station som inlärningsspel

Redan i början av projektet fanns en önskan om att i designprocessen fokusera på att utveckla chromakey-stationen så att den kan användas för spelbaserad inlärning. I takt med att arbetet framskred ham-nade det perspektivet tyvärr lite i glömskan. Detta då arbetets centraliserades kring tekniska lösningartill de olika funktionaliteterna. Med det lades ändå avsevärt mycket tid på att faktiskt utveckla ettsystem som har grundläggande förutsättningar för att fungera som just ett inlärningsspel.

6.6.1 Utveckling inom de tre dimensionerna

I teorin som presenterades i förstudien lyftes det upp tre dimensioner som tillsammans bygger ihopinlärningsspel; plattform, spelhistoria och spelregler. Nedan förs en djupare diskussion om hur dessaanalyserades vid utveckling av chroma key-stationen.

Plattform

Plattform i denna kontext avser vilken teknisk lösning systemet bygger på och inte vilket operativ-system det körs på. Projektets mål, syfte och grundläggande krav fastställde därmed plattformen såtill vida att systemet skulle bygga på en chroma key-teknik. Däremot var det inte bestämt vilken typav choma key-teknik som skulle användas eller hur. Olika lösningar diskuterades men gruppen varslutligen enad om att val av teknisk lösning för själva chroma key-operationerna inte skulle ha någonstörre inverkan på själva inlärningsmomentet. Det enda som faktiskt bestämdes var att den tekniskalösningen för chroma key-operationerna åtminstone behövde vara så pass bra att användaren inte an-märkte på dem. Problem med chroma key-operationerna hade inte bara varit ett störande moment,utan även påverkat det allmänna intrycket av teknik och programmering vilket chroma key-stationenhar som uppdrag att inspirera till.


Spelhistoria

När det kommer till spelhistorien handlar det som appliceras på chroma key-stationen mest om denvirtuella miljö som skapas. I mycket av den teori som analyserats framställdes miljöns inspirerandeeffekt samt potential att väcka nyfikenhet som det absolut viktigaste. Under hela arbetsprocessenkämpades det med att realisera detta i designen. Kunden gav relativt fria tyglar gällande miljön sålänge den följde deras moodboard. Detta gjorde att det enda som begränsade oss var vår egen fantasimen framförallt tidsbristen. Som ovan nämnt upptogs mer tid än beräknat på funktionaliteten vilketgjorde att arbetet med miljön sköts lite åt sidan. Tanken är emellertid fortfarande att utveckla miljönunder de sista sprintarna.

Det som framförallt saknas i arbetet med miljön en djupare analys av målgruppen. I slutänden krävsdetta för att verkligen se vilken typ av miljö som fungerar och vilken som blir för platt. Om miljöngörs mer dynamisk krävs det även tester för att se om användarna förstår varför objekt rör sig och hurde kan göra för att påverka det. Vidare för detta diskussionen till den tredje dimensionen.

Spelregler

Spelreglerna definierar vad användaren kan och inte kan göra för att interagera med systemet. Ett brainlärningsspel har tydliga regler så att användaren förstår vad den ska göra och får samtidigt direktfeedback. Eftersom det länge var oklart hur interaktionen skulle implementeras har spelreglerna dis-kuterats mycket under projektets gång. Exempelvis studerades tidigt många varianter då spårningenav användaren skulle ske med hjälp av en Kinect. En del av problematiken med den lösningen vardock att Kinecten bara kunde registrera en av användarna åt gången. Både för kunden och ur ett in-lärningsperspektiv är socialiseringen mellan spelarna viktig. Om då endast en användare kan användastationen åt gången försämrar det upplevelsen avsevärt. Detta var en av anledningarna varför Kinec-ten släpptes som möjlig lösning. I slutänden uppstår samma problem i det här perspektivet som idiskussionen med miljön.

6.7 Arbetet i ett vidare sammanhang

Alla system har mer eller mindre påverkan på såväl individ som samhälle. Det utvecklade systemet idet här projektet är inte speciellt omfattande och kommer inte heller distribueras i någon större skala.Likväl kan samhälleliga och etiska aspekter ändå vara relevanta att diskutera.

6.7.1 Systemets inverkan på individen

Ur ett kritiskt perspektiv rör systemets negativa påverkan på individen framför allt dennes personligaintegritet. Även om bilderna som tas sparas på ett dolt Imgur album som endast kunden och utveck-larna har tillgång till finns alltid en risk för obehörigt intrång. Vissa insatser för att minska risken hargjort, till exempel genom att bilderna raderas automatiskt efter en viss tid. I slutändan har dock riskenatt bilder sprids felaktigt analyserats som så pass liten att större insatser än de som tidigare nämntsinte gjorts.


6.7.2 Systemets inverkan på samhället

Förutom systemets påverkan på individen som använder det får det färdiga systemet även en direktinfluens på samhället. När det kommer till chroma key-stationen skulle den mest påtagande inverkanvara att den kan bidra till en fortsatt utveckling av övervakningssamhället. Detta eftersom kameranalltid kommer vara igång och ha möjlighet att spara information om vem som var där och vad dengjorde.

En annan tanke till chroma key-stationen rör dess bidrag till det fortsatta åtskiljandet av tid och rum.Detta är inte nödvändigtvis en negativ effekt. Med hjälp av chroma key-stationen skulle händelseroch miljöer å ena sidan förlora sin lokala kontext, men samtidigt tillgängliggöras för alla och därmedbidra med mer kunskap och information. I nuläget är miljön surrealistisk och egentligen inte kopplattill något konkret. Däremot är tekniken nu utvecklad för att göra om miljön och till exempel anknytaden till historiska händelser eller något annat område kunden skulle vilja fördjupa sina användareskunskaper i.

Kapitel 7

Slutsatser

Det huvudsakliga syftet, att uppgradera själva chroma key-tekniken och skapa en ny miljö är upp-nått. Under en visning för kunden av prototypen fick projektgruppen positiv feedback och kundenuppskattade både miljön och funktionaliteterna för att ta en bild.

7.1 Återkoppling på frågeställningarna

Inledningsvis presenterades tre frågeställningar som diskuterats genom rapporten. Den generella slut-satsen av alla frågeställningarna är att det finns väldigt många lösningar på ett och samma problem.Att utvärdera alla lösningarna är därför en omöjlighet och i rapporten har vi valt att fokusera på någraenstaka alternativ.

7.1.1 Vilka metoder kan användas för att implementera ett gränssnitt mellananvändare och system när inga fysiska reglage används?

Metoden som slutligen implementerades i projektet för att styra gränssnittet, var att beräkna föränd-ringar i vissa områden i bilden. Andra metoder som diskuterade men som uteslöts var att registrerahandgester eller att använda en Microsoft Kinect. Handgesterna uteslöts då tiden inte fanns att utveck-la ett tillräckligt stabilt system för att tolka handgesterna korrekt. Dessutom hade det krävts djupareanvändarstudier av vilka typer av handgester som skulle vara användbara och logiska för användaren.

Möjligheterna med en Kinect är stora men då den Kinecten som fanns att tillgå var av en äldre modellsaknades stöd för att integrera den i Unreal Engine på ett smidigt sätt. Med en nyare version av enKinect skulle dess skelettfunktionalitet möjliggjort för mer avancerad användarinteraktion så somenklare minispel i miljön. En Kinect hade därför varit mycket användbar för att utöka interaktionenmellan användaren och systemet.

Sammanfattningsvis kan gränssnitt mellan användare och system utan fysiska reglage implementeraspå många olika sätt. Den avgörande faktorn för vilken metod som väljs är därför vad systemet skautföra samt vilka resurser som finns att tillgå.

7.1.2 Vilka olika metoder kan implementeras i ett system för att tillåta använ-daren att få en digital kopia av en bild de kan använda i eget bruk?

Under projektets gång undersöktes ett flertal olika metoder för att spara och distribuera en digital bild.För att spara en bild används ett inbyggt funktionsanrop i UE4 för att ta en skärmdump. Denna metod

32

KAPITEL 7. SLUTSATSER 33

ger till skillnad från att projicera varje bildruta på en textur och sedan spara bildtexturen som en bildmycket mindre kod, vilket gör koden lättare att förstå. Utöver det ger den inbyggda funktionen bättreprestanda då ingen textur ständigt behöver uppdateras. En nackdel är att valmöjligheter försvinnerpå vilken upplösning den sparade bilden ska ha då den men den inbyggda funktionen får sammaupplösning som skärmen.

För att ge användaren tillgång till den sparade bilden används ShareX för att ladda upp bilden dolt påImgur, där användaren får ta del av bildlänken direkt på stationens skärm. Andra alternativ hade varitatt skapa en egen databas med tillhörande hemsida till vilken användaren får en adress till. Problemetär att projektgruppen själva skulle behöva stå för att vara värdar för dessa. Ett annat alternativ skullevara att implementera en lokal hemsida som mejlar bilderna till användarna, dock då interaktionenmed systemet enbart sker med rörelse skulle det vara omständligt att skriva en mejladress. Lösningenmed att använda ShareX och Imgur är bra för att den inte involverar plugin vilket gör att projektetlättare kan paketeras. Dessutom leder användningen av tredjepartsprogramvara att mindre kod behö-ver underhållas från projektgruppens håll, men det betyder även att systemet kan påverkas av externaprogramuppdateringar

7.1.3 Hur skapas ett intresseväckande och pedagogiskt innehåll till ett chro-ma key-baserat system som ska användas för barn och ungdomar i enutställningsmiljö?

Att utveckla ett spelbaserat inlärningssystem visade sig ha många fler dimensioner än de som först be-aktats. Sammanfattningsvis upplevde projektgruppen att det var svårt att kombinera fokus på den tek-niska utvecklingen och samtidigt hitta tid för att utveckla en rolig och intresseväckande miljö/spelidé.Den stora lärdomen är att för att utveckla ett system för en viss målgrupp, i vårt fall barn och ung-domar, krävs information om just den målgruppen. Fokus bör ligga på att hitta något målgruppenmotiveras av och på så sätt kan bli nyfiken av att lära sig mer om. Små överraskningsmoment kanvara bra för att åstadkomma detta.

Teknikmässigt är det viktigt att både plattform och spelregler samverkar så att användarens uppfatt-ning av sin kunskap reflekterar det den faktiskt kan åstadkomma i systemet. Det vill säga systemetbeter sig som användaren förväntar sig. Utställningsmiljön gör vidare att utställarna har möjlighet attkombinera själva stationen med mer detaljerad information om hur tekniken fungerar. På så sätt kanden intresserade användaren lära sig ännu mer. Att användaren dessutom kan få med sig något hem(bild från användningen) gör slutligen att lärdomen kan spridas vidare även efter att användaren harlämnat utställningsmiljön.

7.2 Fortsatt arbete

Utöver att färdigställa de grundläggande kraven har projektgruppen under arbetets gång utvecklatandra idéer på möjlig vidareutveckling utav chroma key-stationen. Framförallt handlar det om att för-bättra miljön och göra den mer anpassad för input från användaren. Exempelvis vore det intressant attutveckla en funktion för användaren att påverka objekten och därigenom utföra kortare uppdrag ellerminispel. I samband med detta skulle användaren även kunna introduceras till lite lättare programme-ringstekniker så som loopar och booleans. De skulle kunna förklaras genom att låta användaren bytafärger på objekt, lägga till filter eller lägga ihop korta sekvenser av rörelser. Chroma key-tekniken harmycket potential och tillsammans med OpenCV finns möjlighet att implementera många funktionali-teter till stationen.

Litteraturförteckning

[1] Visualiseringcenter C, Vad är Visualiseringcenter C?, Visualiseringcenter C, hämtad: 2018-05-05http://visualiseringscenter.se/visualiseringscenter-c

[2] Visualiseringcenter C, PROFESSOR PUPILLS LABORATORIUM, Visualiseringcenter C, häm-tad: 2018-05-05http://visualiseringscenter.se/professorpupillslaboratorium

[3] Bagiwa Mustapha Aminu, Wahab Ainuddin Wahid Abdul, Idris Mohd Yamani Idna, Khan Sule-man och Choo Kim-Kwang Raymond Chroma key background detection for digital video usingstatistical correlation of blurring artifact, Digital Investigation, December 2016, hämtad: 2018-05-08https://www.sciencedirect.com/science/article/pii/S1742287616300925?

[4] Chroma key, Nationalencyklopedin, December, hämtad: 2018-05-07http://www.ne.se/uppslagsverk/encyklopedi/lång/chroma-key

[5] Christopher Schultz, Digital Keying Methods, University of Bremen Center for Computing Te-chnologies Tzi, 2006-09-01, hämtad: 2018-05-06http://www.tzi.de/tzikeyer/keying_report.pdf

[6] The Epic Games Team, Unreal Engine, Epic Games, hämtad: 2018-05-07https://www.unrealengine.com

[7] OpenCV Team, About - OpenCV, OpenCV Team, 2018, hämtad: 2018-05-06https://opencv.org/about.html

[8] Margaret Rouse,cloud database , TechTarget, 2017, hämtad: 2018-05-05https://searchcloudapplications.techtarget.com/definition/cloud-database

[9] The Imgur Team, Imgur.com, Imgur Inc , 2018, hämtad:2018-05-05https://imgur.com/

[10] The Imgur Team, Imgur API, Imgur Inc , 2018, hämtad:2018-05-05https://apidocs.imgur.com/

[11] Margaret Rouse,RESTful API, 2014, TechTarget, hämtad: 2018-05-05https://searchmicroservices.techtarget.com/definition/RESTful-API

[12] The ShareX Team,ShareX, Frequently asked questions, 2007-2018, ShareX, hämtad: 2018-05-05https://getsharex.com/docs/faq

34

LITTERATURFÖRTECKNING 35

[13] Björn Berg Marklund, Unpacking Digital Gamebased Learning, University of Skövde, 2015,hämtad: 2018-04-12http://his.diva-portal.org/smash/get/diva2:891745/FULLTEXT01.pdf

[14] Moyen Mustaquim och Tobias Nyström, An Inclusive Framework for Developing Video Gamesfor Learning, UK: Academic Publishing International Limited European Conference on GamesBased Learning, 2012, hämtad: 2018-04-12http://uu.diva-portal.org/smash/record.jsf?pid=diva2

[15] HacknPlan Team, What is HacknPlan?, HacknPlan, hämtad: 2018-05-05http://hacknplan.com/knowledge-base/what-is-hacknplan/

[16] Discord Team, About - Discord, Discord Team, hämtad: 2018-05-05https://discordapp.com/company

[17] The Perforce Team, Introducing Perforce, Perforce Software inc, hämtad: 2018-06-07https://www.perforce.com/perforce/r15.1/manuals/intro/index.html

[18] Ryan Brucks, Setting Up A Chroma Key Material in UE4, ShaderBits, 2017-09-29, hämtad:2018-05-08https://www.unrealengine.com/en-US/blog/setting-up-a-chroma-key-material-in-ue4

[19] Adobe Capture CC, Adobe Capture CC, Adobe Systems Inc, 2018-04-18, hämtad: 2018-05-07https://itunes.apple.com/se/app/adobe-capture-cc/id1040200189?mt=8

[20] Yanmei He, mColorWheel, Yanmei He, 2016-04-14, hämtad: 2018-05-07https://itunes.apple.com/us/app/mcolorwheel/id613052410?mt=8

[21] Unreal Engine 4 Unreal Engine 4 Documentation, Epic Games, Inc, 2017 hämtad: 2018-05-07http://api.unrealengine.com/INT/API/Runtime/Engine/FScreenshotRequest/RequestScreenshot/1/

[22] The Imgur Team, Imgur, Imgur, Inc , 2018, hämtad: 2018-05-07https://imgur.com/

[23] OpenCV Team, OpenCV Documentation, OpenCV Team, 2018, hämtad: 2018-05-07https://docs.opencv.org/3.4/d7/d8b/tutorial_py_face_detection.html

[24] OpenCV Team, OpenCV Documentation, OpenCV Team, 2018, hämtad: 2018-05-07https://docs.opencv.org/2.4/doc/user_guide/ug_traincascade.html

[25] UE4 ANSWERHUB Accessing camera images, 2016, hämtad: 2018-05-09https://answers.unrealengine.com/questions/486630/accessing-camera-images.html

[26] Shari Lawrence Pfleeger och Joanne M. Atlee, Software Engineering, Fourth Edition, Interna-tional Edition, Pearson 2010

Bilaga A

Gantt-schemaU

pp

gift

Slu

tdat

um

Pro

jekt

pla

n2

01

8-0

2-2

3

Tekn

iska

stu

die

r

Spri

nt

02

01

8-0

2-2

8

Spri

nt

12

01

8-0

3-2

1

Spri

nt

22

01

8-0

3-1

9

Spri

nt

32

01

8-0

3-1

6

Spri

nt

42

01

8-0

3-1

7

Spri

nt

52

01

8-0

3-1

8

Test

pro

toty

per

An

vän

dar

test

er

Pro

jekt

rap

po

rt2

01

8-0

5-1

0

Op

po

ner

ings

rap

po

rt2

01

8-0

5-2

2

Slu

tsem

inar

ium

20

18

-06

-01

Avs

täm

nin

gsm

öte

n

Ten

ta-p

erio

d

MTD

Pås

kled

igh

et

Om

ten

ta-p

erio

d

v.1

8v.

19

v.2

0v.

21

v.2

2v.

13

v.1

4v.

15

v.1

6v.

17

v.8

v.9

v.1

0v.

11

v.1

2

Figur A.1: Gantt-schema som visar den ursprungliga tidsplanen

.

36

Bilaga B

Arbetsfördelning

Anna Fredriksson HääggHar haft rapporten som specifikt ansvarsområde. Utöver det har tid lagts på studier av forskning ominlärningsspel, design och modellering av 3D objekt samt implementering av spelmiljön. Var ävenmed och designade och utvecklade systemets grafiska profil. När det kommer till implementering ut-vecklade hon kopplingen mellan C++ klassen för knapparna och användargränssnittet i UE4. Det villsäga implementeringen av vilka vyer som skulle visas när och hur kopplingen sker mellan aktivering-en av en knapp och den progressbar som visas i gränssnittet.

Ronja FaltinVar scrummästare genom projektet och ansvarig för dokumentationen. Främst designat användar-gränssnittet och den grafiska profilen samt efterforskat kring interaktionssystem i UE4 och blueprints.Har designat och ritat alla ikoner och grafiska bilder förekommande i systemet inklusive systemetsfärgschema och moodboard.

Jakob GunnarssonDelansvarig för bokning av salar och har varit delaktig med bildbehandling, chroma key och data-bashantering för att kunna ladda ner bilder. Han har utforskat på hur användaren ska få tillgång till enbild utan egen server. När det gäller helt självständig implementering har han utvecklade funktionali-teten för att låta användaren ta en bild som sparas lokalt på datorn.

Jesper MartinssonHar haft kundkontakt och varit versionshanteringsansvarig under hela projektet. Han efterforskadeom och skapade 3D modeller samt alla texturer och animationer till modellerna. Han skötte exporte-ringen av 3D modeller från blender och importeringen av dem i UE4. Främst har han arbetade medbildbehandling och chroma key funktionen i UE4.

Nicholas FrederiksenHar varit delansvarig för bokning av salar och bidragit främst inom databashantering och utformningav hemsida. Har skrivit i html, css och javascript. Har implementerat Imgur API:t i hemsidan föratt kunna rensa album, uppdatera album och hämta länk till senast tillagda bild i album. Har arbetatmed bildbehandling med chroma key i sprint 0 och sprint 1 i form av efterforskning och testning avblueprints i Unreal Engine.

Simon ForsbergVar kvalitetsansvarig under projektets gång och har gjort implementering av OpenCV, input från USB-kamera till Unreal Engine, interaktionssystem, motiontracking, och bildbehandling med chroma key.

37

Documents

The Neonland Experience - Linköping Universityweber.itn.liu.se/~karlu20/courses/TNM094/reports/... · användaren ta en bild. Slutligen utvecklades en enkel hemsida kopplad till