FPS I EN INTERAKTIV 3D- MODELLVISARE MED WEBGL

(1)

Mall skapad av Henrik

FPS I EN INTERAKTIV

3D-MODELLVISARE MED WEBGL

En FPS-jämförelse av WebGL

Javascript-biblioteken Three.js och Babylon.j

s.

FPS IN AN INTERACTIVE 3D MODEL

VIEWER WITH WEBGL

An FPS comparison of the WebGL Javascript

libraries Three.js and Babylon.js.

Examensarbete inom huvudområdet Informationsteknologi Grundnivå 30 högskolepoäng

Vårtermin 2020 John Söderberg

(2)

Sammanfattning

Denna studie jämför skillnader i FPS mellan de två WebGL-biblioteken Three.js och Babylon.js. Prestandan som mäts är hur många bilder per sekund, eller FPS (engelska frames per second) som en webbapplikation med 3D-grafik klarar att rendera. Prestandamätningarna utförs på en 3D-modellvisare som implementeras i både Three.js och Babylon.js. Testerna utförs på en bärbar dator med Windows 10. Hypotesen antar att Three.js inte kommer att prestera bättre än Bablyon.js Resultatet från studien visar dock att Three.js presterar bättre än Babylon.js. Studiens syfte är att ge utvecklare en uppfattning om vilket WebGL-bibliotek som är mest lämpligt att använda vid exempelvis utveckling av en e-handelssida där produkter har 3D-förhandsvisningar. Studien kan användas som grund eller inspiration för framtida forskning inom samma område.

(3)

Innehållsförteckning

1 Introduktion ... 1

2 Bakgrund ... 2

2.1 Prestanda i 3D-applikation ... 2

2.2 Interaktivitet ... 2

2.3 Inputsimulering med Macro Recorder ... 3

2.4 WebGL ... 4

2.4.1 WebGL ramverk och bibliotek ... 4

2.5 Val av bibliotek ... 5

2.6 3D-modellvisare (3D Model Viewer) ... 6

3 Problemformulering ... 7

3.1 FPS... 7

3.2 Interaktivitet ... 7

3.3 Frågeställning och hypotes ... 7

4 Metodbeskrivning ... 8 4.1 Alternativa metoder ... 8 4.1.1 Fallstudie ... 8 4.1.2 Användarstudie ... 9 4.2 Artefakt ... 9 4.3 Implementation ... 9 4.4 Testning ... 10 4.5 Etik... 10 5 Genomförande ... 11 5.1 Litteraturstudie ... 11 5.2 Progression... 12 5.2.1 Kodstruktur ... 13

5.2.2 Länkar till kodbibliotek ... 14

5.2.3 Uppdatera 3D-modellvisaren till Three.js r113 ... 15

5.2.4 Scenen ... 15

5.2.5 Kameran... 16

5.2.6 Ljuskällor ... 17

5.2.7 Importering av OBJ-fil ... 19

5.2.8 Rendering ... 22

5.2.9 FPS-mätning och Greasemonkey-script ... 23

6 Pilotstudie ... 25

6.1 Pilotstudie resultat ... 25

6.2 Pilotstudie diskussion ... 30

7 Utvärdering ... 31

7.1 Specifikation av hårdvara och mjukvara ... 31

7.2 Kodändringar från pilotstudien ... 31

7.3 Presentation av undersökning ... 32

7.4 Analys ... 36

7.5 Slutsatser ... 36

(4)

8.1 Sammanfattning ... 38

8.2 Diskussion ... 38

8.2.1 Etik och samhälle ... 39

8.3 Framtida arbete... 40

(5)

1 Introduktion

Internet är idag del av vår vardag och det är mycket vanligt att människor handlar produkter via internet, enligt en forskningsartikel av Javadi, et al. (2012). Då är det viktigt att kunden kan förhandsvisa produkten de är intresserade av att köpa, eftersom det inte finns något fysiskt objekt att titta på och interagera med. Detta stöds av en forskningsartikel av Hairong Li, Frank Biocca och Terry Daugherty (2002), som undersöker skillnaden mellan hur kunder upplever en produkt om den visas i 2D, jämfört med om den visas i 3D, där den kan visas från olika vinklar. Forskningens resultat visar att kunder får en bättre upplevelse och uppfattning av produkten om den kan visas i 3D, jämfört med om den visas i 2D.

Med hjälp av WebGL (se kapitel 2.4), är det möjligt att skapa webbapplikationer som kan rendera 3D-modeller. För att förenkla utvecklingen av webbapplikationer med WebGL används oftast ett Javascript bibliotek. Det finns ett flertal Javascript-bibliotek för WebGL att välja mellan och då är det intressant att veta om implementeringen av de olika biblioteken skiljer sig åt något i prestanda (se kapitel 2.1 för tydliggörande av begreppet prestanda).

I detta arbete kommer två populära Javascript-baserade WebGL-bibliotek för 3D-grafik jämföras för att undersöka vilket bibliotek som ger bäst prestanda. Biblioteken kommer jämföras en interaktiv 3D-applikation. Applikationen i fråga är en interaktiv 3D-modellvisare (se kapitel 2.4) och är en simplifierad representation av hur en e-handelsapplikation som visar produkter i 3D skulle kunna se ut.

De underliggande teknikerna som används i detta arbete är Javascript, WebGL och HTML5. Det finns ett flertal Javascript-bibliotek och ramverk för att underlätta byggandet av 3D-applikationer i WebGL (se kapitel 2.4.1).

(6)

2 Bakgrund

2.1 Prestanda i 3D-applikation

Prestanda kan betyda många olika saker. Prestanda kan t.ex. mätas efter hur en programvara använder olika resurser. Det kan vara CPU-användning, GPU-användning, minnes-GPU-användning, etc. som mäts. Prestanda kan också mätas på exekveringstid, eller renderingstid. Det är därför viktigt att tydliggöra vad som menas med prestanda i detta arbete. Begreppet prestanda innebär i detta arbete hur många bilder per sekund, eller FPS (frames per second) som applikationen klarar av att rendera under användning. Användning innebär att användaren interagerar med 3D-modellvisaren och roterar kamera runt 3D-modellen som visas. Muennoi och Hormdee (2016) nämner i sin artikel att det är vanligt att mäta FPS när prestanda ska mätas. Muennoi och Hormdee nämner även att 30 FPS är den minsta acceptabla bildhastigheten för att det inte ska upplevas som störande.

2.2 Interaktivitet

Interaktivitet kan ha flera betydelser när det gäller applikationer. En 3D-applikation, såsom 3D-modellvisaren som utvecklas i detta arbete, består av tre grundkompnenter; en scen som alla objekt som ska renderas av 3D-applikation befinner sig inuti. Den andra komponenten är en kamera som befinner sig inuti scenen projicerar ett begränsat område av scenen till det tvådimensionella fönstret som användaren ser på sin skärm. Den tredje komponenten är ett objekt, exempelvis en modell. Chris Hand (1997), tar i en artikel upp olika typer av interaktivitet i applikationer. Hand nämner i sin artikel att det finns olika typer av interaktivitet i 3D-applikationer. I artikeln delar Hand upp de olika typerna av interaktivitet i tre huvudsakliga typer av interaktion; objektmanipulering (object manipulation), fönstermanipulering (viewport manipulation) och applikationskontroll (application control).

• Objektmanipulering innebär direkt manipulering av objekt, dvs 3D-modeller, i form av skalning, rotering, translering, borttagning, skapande, etc. Manipuleringen kan ske t.ex. genom att användaren klickar på objektet med muspekaren, eller på något annat interaktivt element i scenen.

(7)

av kamerakontrollteknik som kallas för orbit, från det engelska ordet för omloppsbana. Tan, Robertson och Czerwinski (2001) beskriver i en artikel orbit-tekniken som ett sätt för användaren att lätt kunna se objektet från den önskade vinkeln. Med orbit-tekniken är kameran riktad mot en punkt i scenen och kan förflyttas i X-, Y-, och Z-led. Kameran behåller alltid samma avstånd till punkten och är ständigt riktad mot punkten, vilket resulterar i att kameran förflyttar sig i en cirkulär rörelse kring punkten. I Tan, Robertson och Czerwinskis fall är denna punkt ett 3D-objekt, som orbit-kameran rör sig runt. Figur 1 illustrerar hur kameran kan förflytta sig runt en mittpunkt. Användaren förflyttar kameran genom att klicka i fönstret och dra musen, antingen åt höger, vänster, uppåt, eller nedåt. 3D-modellvisaren som används i detta arbete har en orbit-kamera som förflyttar sig runt scenens origo, där en 3D-modell kommer att vara placerad.

Figur 1 Orbit-kamera rörelse

2.3 Inputsimulering med Macro Recorder

(8)

användas, då dess inspelningsfunktion gör det mindre tidskrävande att skapa en kamerasekvens än genom att programmera en kamerasekvens med Javscript.

2.4 WebGL

WebGL är ett Javascript-API som gör det möjligt att använda datorns grafikprocessor för att rendera 2D- och 3D-grafik i en webbapplikation (Feng, et al., 2011). WebGL är baserat på OpenGL och använder ett HTML5 canvas-elment för att rita ut grafiken. Alla moderna webbläsare har stöd för WebGL och har haft stöd för det sedan 2011. Moderna webbläsare innefattar bl.a. Google Chrome, Mozilla Firefox, Opera, Apple Safari och Microsoft Edge (MDN Web Docs, 2019). WebGL är ett lågnivå-API (Feng, et al., 2011) och har i sig självt inga fördefinierade funktioner för att rita ut 3D-objekt. Därför används oftast ett Javascript-bibliotek som underlättar användningen av WebGL. Två populära Javascript-ramverk för 3D grafik med WebGL är Three.js och Babylon.js.

2.4.1 WebGL ramverk och bibliotek

Det finns ett flertal Javascript-bibliotek för användning av WebGL och många av dessa Javascript-bibliotek finns tillgängliga på Github. Github är världens största webbhotell för programvaruprojekt som använder versionshanteringsverktyget Git, enligt en forskningsartikel skriven av Borges, et al. (2016). Three.js och Babylon.js är två av de populäraste biblioteken och finns officiellt på Github. Tittar man närmare på Githubs statistik över använding, stjärnmarkeringar och forks, ser man att Three.js är det populäraste WebGL Javascript-biblioteket bland alla projekt på Github. Där har Three.js 57,1 tusen stjärnmarkeringar och Babylon.js har 10,6 tusen stjärnmarkeringar (se tabell 1). A-Frame är det bibliotek som är näst populärast på Github, men eftersom A-Frame används främst för att skapa Virtual Reality-applikationer och är A-Frame inte relevant, eftersom Virtual Rreality ligger utanför omfattningen av detta arbete.

Ramverk Används av Stjärnmarkeringar Forks

A-Frame 2595 10 798 2600+

OSG.js N/A 669 176

PlayCanvas 11 5005 845

Three.js 26 026 57 174 21 700+

Babylon.js 1462 10 573 2000+

(9)

• Babylon.js (Babylon.js, 2020) är ett annat populärt Javascript-bibliotek och ramverk för 3D-grafik, som funnits sedan 2013. Det använder WebGL och HTML5 för att rita ut 3D-grafik. Babylon.js har 147 826 rader kod och har därmed en större filstorlek än Three.js. Det finns en möjlighet att den större mängden kod hos Babylon.js kan påverka prestandan.

Fördelen med att använda Babylon.js är att det finns inbyggda funktioner för kamerainteraktivitet (Babylon.js, 2020), vilket gör det lättare att bygga interaktiva 3D-applikationer, jämfört med Three.js. Three.js har inga inbyggda funktioner för kamerainteraktivitet, istället måste egna funktioner kodas. Saknaden av inbyggda funktioner för kamerainteraktivitet leder till att implementering av kamerainteraktivitet med Three.js är mer tidskrävande än med Babylon.js.

2.5 Val av bibliotek

I detta arbete kommer Javascript-biblioteken Three.js och Babylon.js att jämföras. Arbetet är inspirerat av ett tidigare arbete av Axel Karlsson och Oscar Nordquist (2018), där Three.js och Babylon.js jämförs. Därför valdes Three.js och Babylon.js som de bibliotek som ska jämföras även i detta arbete. Jämförelsen som Karlsson och Nordquist gjorde var på en icke-interaktiv applikation som hade i uppgift att konvertera en 2D-höjdkarta till 3D-data. Syftet med detta arbete är att i stället undersöka hur samma bibliotek presterar i en annan typ av applikation, i detta fall en interaktiv 3D-modellvisare (se kapitel 2.6).

Grundlogiken hos både Three.js och Babylon.js är liknande, men skiljer sig ändå åt så pass mycket att en jämförelse är motiverat. För att demonstrera vissa likheter och skillnader kommer två kodstycken från respektive bibliotek att jämföras och diskuteras. Kodstyckena innehåller den Javascript-kod som krävs för att skapa en scen, skapa en kamera med 45 grader synfältsvinkel, lägga till kameran i scenen och rendera scenen Kodexemplet i figur 2 visar kodstycket för Three.js.

Figur 2 Skapa en scen med Three.js

I kodexemplet i figur 3 visas kodstycket för Babylon.js. Som man kan se i de båda kodexemplen är kodstrukturen liknande på det sättet att man skapar ett scen-objekt (scene), samt ett kamera-objekt (camera). Kamera-objektet läggs till i scenen och scenen renderas sedan.

Båda biblioteken använder ett HTML5 canvas-element för att rita ut grafiken. Skillnaden är att Babylon.js kräver att man själv skapar ett canvas-element i HTML-koden, medan Three.js automatiskt skapar ett canvas-element genom renderingsobjektets render-metod. Sättet att skapa kameraobjektet på skiljer sig

var scene = new THREE.Scene();

var camera = new THREE.PerspectiveCamera(45, window.innerWidth / window.innerHeight, 0.1, 1000);

var renderer = new THREE.WebGLRenderer();

renderer.setSize( window.innerWidth, window.innerHeight ); document.body.appendChild( renderer.domElement );

(10)

mellan de båda biblioteken. Three.js använder grader för att bestämma kamerans synfältsvinkel, medan Babylon.js använder radianer. I Three.js anges synfältsvinkeln

som en parameter i kamera-objektets konstruktor. I Babylon.js anges synfältvinkeln efter att kameraobjektet har skapats, genom att sätta ett värde för kameraobjektets fov-egenskap.

Figur 3 Skapa en scen med Babylon.js

För att rendera scenen används i båda kodexemplen en typ av renderings-objekt. I Three.js används objektet WebGLRenderer (renderer) och i Babylon.js används objektet Engine (engine). Vad som skiljer sig är hur renderingen utförs. I Three.js används renderer-objektets render metod, som tar scenobjektet och kameraobjektet som parametrar. I Bablyon.js används engine-objektets runRenderLoop-metod för att skapa en loop som kallar på scenobjektets render-funktion.

Filstorleken hos de båda biblioteken skiljer sig signifikant (se tabell 2). Antalet rader kod i Babylon.js är 2,9 gånger mer än antalet rader kod i Three.js, vilket möjligtvis kan påverka prestandan.

Bibliotek Rader kod Filstorlek (KB)

Three.js 50 524 1218,007

Babylon.js 147 826 7448,2

Tabell 2 Three.js och Babylon.js filstorlekar och antal rader kod.

2.6 3D-modellvisare (3D Model Viewer)

3D-applikationen som kommer att användas för att mäta ramverkens prestanda består av en scen, en kamera och en 3D-modell. 3D-modellen är placerad i mitten av scenen. Applikationen är interaktiv och typen av interaktivitet är fönstermanipulering (se kapitel 2.2). Den interaktiva delen innebär att användaren har kontroll över kamerans position och kan med hjälp av musen rotera kameran runt 3D-modellen på X-, Y- och Z-axlarna.

Som nämndes tidigare i kapitel 2, jämförde tidigare forskning av Karlsson och

var canvas = document.getElementById("renderCanvas"); var engine = new BABYLON.Engine(canvas, true);

var scene = new BABYLON.Scene(engine);

var camera = new BABYLON.UniversalCamera("Camera", 0, 0 10, new BABYLON.Vector3(0,0,0), scene);

camera.fov = 0.8;

engine.runRenderLoop(function () { scene.render();

(11)

3 Problemformulering

3.1 FPS

Som tidigare nämndes i kapitel 2, visar forskningen av Li et al. (2002) att användare får en bättre uppfattning av produkter på e-handelswebbsidor om de kan förhandsgranskas i 3D, istället för i 2D. Det är då viktigt att applikation som ska rendera 3D-modellen och låta användaren interagera med den håller god prestanda och en hög FPS för att upplevas positivt av användaren. Problemet är att låg FPS hos en rörlig och interaktiv 3D-applikation kan leda till frustration hos användaren. En studie av Stephen Gulliver och Gheorghita Ghinea (2004), visar att FPS kan påverka människors uppfattning om kvalité. Gulliver och Ghineas studie visar att låg FPS generellt uppfattas som låg kvalitét av användaren och är därför något som bör undvikas. Den minst Därför är det viktigt att identifiera vilket bibliotek som ger bästa möjliga FPS I 3D-modellvisaren.

3.2 Interaktivitet

Både Three.js och Babylon.js går att använda till att implementera 3D-modellvisaren. Som nämns i kapitel 2.4.3 så har Babylon.js inbyggd funktionalitet för olika typer av interaktion, exempelvis kamerakontroll. I Three.js däremot måste all typ av interaktion (se kapitel 2.2) implementeras för hand. Det finns alltså ingen inbyggd funktionalitet, vilket gör att Babylon.js är mindre tidskrävande att implementera för interaktiva 3D-applikationer. Problemet är då att välja rätt bibliotek. Är Babylon.js enklare att implementera men presterar sämre än Three.js?

3.3 Frågeställning och hypotes

Frågeställningen: Vilket WebGL Javascript-bibliotek, Babylon.js eller Three.js, ger högst antal FPS i 3D-modellvisaren?

Hypotesen: Hypotesen är att 3D-modellvisaren som är implementerad med Three.js kommer att ha lägre FPS än 3D-modellvisaren som är implementerad med Babylon.js. Alternativ hypotes: Den alternativa hypotesen är att antalet FPS inte kommer skilja sig signifikant mellan modellvisaren som är implementerad med Three.js och 3D-modellvisaren som är implementerad med Babylon.js.

(12)

4 Metodbeskrivning

Metoden som ska användas är experimentmetoden. Experimentmetoden är en empirisk undersökningsmetod och gör det möjligt att jämföra och visa skillnader mellan de olika teknikerna som testas (Wohlin et al. 2012). En nackdel med experimentmetoden är att den kan bli mycket kostsam. Wohlin et al. (2012) skriver att experimentmetoden kan bli betydligt kostsammare att använda jämfört med exempelvis fallstudie, eller användarstudie, eftersom experimentmetoden ofta kräver fler resurser än de två sistnämnda. En stor fördel med experimentmetoden är att man i testmiljön har full kontroll över de olika variablerna (Wohlin et al. 2012). Nackdelen med detta är att det finns en risk att resultatet från experimentets labbmiljö inte stämmer överens med verkligheten (Reips, 2000). En sak som kan skilja sig från labbmiljön och verkligheten är svarstider, beroende på användarens hårdvara och internetuppkoppling. En webbapplikation med för långa svarstider löper risken att användaren väljer att inte använda den (Butkiewicz, et al. 2013), vilket helt nullifierar den positiva effekten en hög FPS skulle ha. Eftersom hårdvaran hos enheten som kör 3D-modellvisaren har en stor inverkan på prestandan kommer testerna utföras på flera olika typer av hårdvara. Trots riskerna och nackdelarna med experimentmetoden är den ändå den lämpligaste metoden för detta arbete.

Experimentmetoden anses mest lämplig eftersom prestandan mellan två Javascript-bibliotek ska jämföras. Prestandamätningen utförs med benchmark-test. Eftersom 3D-modellvisaren har en rörlig och interaktiv kamera är det rimligt att mäta bildhastigheten hos den. Cai och Nerukar (1998) talar om vikten av att ha benchmark-tester som är replikerbara. För att ett benchmark-test ska vara replikerbart krävs det att utförs i en kontrollerad miljö, där förutsättningarna är identiska vid varje test. Därför är experimentmetoden lämplig.

Resultatet kommer att ge en uppfattning av vilket WebGL-bibliotek, av Three.js och Babylon.js, som ger högst antal FPS i en 3D-modellvisare för användning på exempelvis e-handelssidor. Resultatet kommer att utvärderas statistiskt och vid behov kommer ANOVA- och Tukey-tester att utföras.

4.1 Alternativa metoder

Utöver experimentmetoden finns två andra empiriska metoder; fallstudie och användarstudie. 3D-applikationen implementerad med Three.js kommer att representera baseline.

4.1.1 Fallstudie

(13)

är en fallstudie inte lämpligt. En fallstudie är heller inte lämpligt eftersom det inte är någon färdig eller befintlig produkt som används i arbetet.

4.1.2 Användarstudie

En användarstudie innebär att man samlar in data från, eller om användare med syfte att förklara eller undersöka deras kunskap eller beteende (Wohlin et al. 2012). Datainsamling sker oftast via en enkät, eller via intervju, eller en kombination av båda. En grupp användare låts använda en produkt eller tjänst under en period, därefter sker datainsamling. Detta avser oftast en befintlig produkt eller tjänst som har varit i bruk under en längre period.

Det finns flera exempel på hur en användarstudie skulle kunna appliceras på detta arbete. Ett exempel på en användarstudie är att undersöka om det finns någon upplevd skillnad hos slutanvändare mellan de två olika implementationerna av 3D-modellvisaren. Upplevd skillnad går inte att mäta med enbart experiment, utan kräver att man utför en användarstudie.

Det blir dock svårt att motivera en användarstudie i just detta arbete, eftersom artefakten i detta arbete inte är en färdig, eller befintlig applikation som används i verkliga livet. En användarstudie faller heller inte inom tidsramen för detta arbete. Wohlin, et al. (2012) skriver att en användarstudie kräver ett stort antal användare för att den insamlade datan ska vara användbar, vilket är mycket tidskrävande.

4.2 Artefakt

Två artefakter kommer att skapas, som experimentet i detta arbete ska utföras på. De båda artefakterna består av två olika implementationer av samma applikation, dvs 3D-modellvisaren; en implementerad med Three.js och en implementerad med Babylon.js.

3D-modellvisaren har kamerakontroller för att visa 3D-modellen från alla möjliga vinklar och från olika avstånd. Prestandan hos 3D-modellvisaren kommer att påverkas av 3D-modellens polygonmängd. En lämplig uppsättning 3D-modeller måste tas fram. För att kunna replikera exakt samma kamera-rörelser i samtliga tester används programvaran Macro Recorder (Macro Recorder, 2020) för att simulera användar-input (se kapitel 4.3).

4.3 Implementation

(14)

4.4 Testning

3D-modellvisaren kommer att testas med tio olika komplexitetsnivåer med ökande grad. Komplexitet innebär antalet hörn i geometrin som ska renderas. För varje komplexitetsnivå ökar antalet hörn, vilket kommer påverka prestandan, då mer data måste beräknas och renderas.

Programvaran Macro Recorder kommer att användas vid testning av 3D-modellvisaren. Med Macro Recorder kan en sparad musrörelsesekvens spelas upp, vilket möjliggör replikering av testet. Replikerbarhet är viktigt enligt Wohlin, et al (2012).

4.5 Etik

Experimenten involverar inte människor, så det finns inga risker med att experimentet strider mot mänskliga rättigheter.

(15)

5 Genomförande

5.1 Litteraturstudie

Det finns en stor mängd litteratur i form av böcker om WebGL. De flesta böckerna som finns är i guideformat och riktade mot nybörjare. Dessa böcker ger en god grund för att förstå vad WebGL är och hur det fungerar rent tekniskt. En bok som förklarar vad WebGL är och hur det fungerar är WebGL: Up and Running, skriven av Tony Parisi (Parisi, 2012) Det finns även böcker för både Three.js och Babylon.js. Det finns många böcker i guideformat som förklarar hur Three.js fungerar och hur man använder det. Babylon.js däremot, som är det yngre av de två biblioteken, har betydligt färre böcker. En bok som ger en förståelse för hur Babylon.js kan användas är Babylon.js Essentials, skriven av Julien Moreau-Mathis (Moreau-Mathis, 2016). Utöver böcker finns en stor mängd information om både Three.js och Babylon.js att hämta från olika webbaserade källor. Båda biblioteken har omfattande officiell dokumentation tillgänglig på webben (Babylon.js, 2020 & Three.js, 2020), vilket var tillräckligt för implementationen av 3D-modellvisaren.

Under implementationen av 3D-modellvisarens javascript-kod användes webbsidor som källor som komplettering till forskningsartiklar. Webbsidor används främst för att hitta information om vilka funktioner som finns tillgängliga i de olika biblioteken och hur syntaxen ser ut. De webbsidor som användes var främst Three.js och Babylon.js officiella dokumentationssidor.

Eftersom 3D-modellvisaren som är implementerad i Three.js är baserad på en färdig applikation från Github (Lorti, 2016) implementerades inte så mycket ny kod. Därför behövdes inte så många källor. När 3D-modellvisaren uppdaterades till senaste versionen av Three.js behövdes koden skrivas om på ett fåtal ställen. Orsaken var att viss syntax ändrats i senare versioner av Three.js och att vissa funktioner fasats ut och ersatts med andra. För att lösa detta användes Three.js officiella dokumentation som källa. På Three.js Github-sida finns en guide som beskriver vilka kodändringar som krävs i en Three.js-applikation som ska uppgraderas från en version till en nyare (Three.js, 2020). Denna guide var en användbar källa när 3D-modellvisaren uppdaterades till version r113.

För implementationen av 3D-modellvisaren i Babylon.js används främst Babylon.js officiella dokumentation som källa (Babylon.js, 2020). Babylon.js har omfattande officiell dokumentation komplett med kodexempel. Dokumentationen är användbar för att hitta komponenter och funktioner som motsvarar de Three.js-komponenter som använts i implementationen av Three.js.

(16)

Inspiration för genomförandet av experimentet hämtades ifrån postern Comparing Rendering Performance of Common Web Technologies for Large Graphs (Horak, et al, 2018), där tvådimensionell rendering med WebGL jämfördes med två andra teknologier. I sitt experiment använde de Macro Recorder (Macro Recorder, 2020) för att simulera och automatisera användarinput vid testning. Det är ett lämpligt tillvägagångssätt för även detta experiment. Inspiration togs också från deras tester där komplexiteten ökas efter regelbundna tidsintervaller.

5.2 Progression

Progressionskapitlet går igenom de viktigaste stegen vid implementering av koden. Vid implementeringen av 3D-modellvisaren användes samma HTML-fil från Lortis (Lorti, 2016) implementation, som sedan modifierades. All Javascript-kod ligger inuti en <script>-tagg i HTML-filen. Alla HTML-element och CSS-kod från Lortis implementation som inte medför någon väsentlig funktionalitet raderades från HTML-filen. Strukturen i HTML-filen och Javascript-koden hos de båda implementationerna av 3D-modellvisaren ser identisk ut i respektive implementation. För att visa att de båda implementationerna av 3D-modellvisaren faktiskt kan räknas som samma applikation kommer koden att förklaras och jämföras. De fullständiga HTML-filerna finns i Appendix A och B.

En viktig skillnad mellan Three.js och Babylon.js är hur det tredimensionella koordinatsystemet fungerar. I Three.js är X-axeln höger-axeln, Y-axeln uppåt-axeln och Z-axeln framåt axeln. Skillnaden i Babylon.js är att X- och Z-axeln skiftar plats och blir därmed blir X-axeln framåt-axeln och Y-axeln blir höger-axeln. Skillnaden mellan koordinatsystemen innebär att koordinater inte kan kopieras direkt från Three.js till Babylon.js.

(17)

Komplexitetsnivå Antal hörn

1 200K

2 800K

3 1400K

4 2000K

Tabell 3 Komplexitetsnivåer för pilotstudie.

Figur 4 3D-modell av byst

5.2.1 Kodstruktur

(18)

funktionerna och eventuella skillnader förklaras i närmare detalj i kapitel 5.3.2 till 5.3.7.

3D-modellvisaren består av fyra huvudsakliga komponenter; en scen, en kamera, en uppsättning ljuskällor, samt en 3D-modell. Både Three.js och Babylon.js har objekt i sina respektive kodbibliotek för dessa komponenter. Scenen består av ett scenobjekt, kameran består av ett kameraobjekt, ljuskällorna består av tre ljusobjekt och 3D-modellen består av ett 3D-objekt.

Figur 5 Three.js funktioner i init()

Figur 6 Babylon.js funktioner i init() 5.2.2 Länkar till kodbibliotek

I figur 7 och 8 visas de javascriptfiler som krävs för att implementera 3D-modellvisaren med Three.js, samt Babylon.js, respektive. three.js är det huvudsakliga kodbiblioteket för Three.js och babylon.js är det huvudsakliga kodbiblioteket för Babylon.js. De övriga filerna är extra kodbibliotek som krävs för att implementera den önskade funktionaliteten hos 3D-modellvisaren. I implementationen med Three.js krävs OrbitControls.js för att kameran i scenen ska kunna ha orbit-kontroller. OBJLoader.js och MTLLoader.js krävs för att det ska gå att importera filer av typen OBJ och MTL. De tre sistnämnda kodbiblioteken ges ut av Three.js och följer med vid nedladdning av Three.js.

Implementationen med Babylon.js behöver inget extra kodbibliotek för orbit-kontroller, då det finns inkluderat i huvudbiblioteket. Extra kodbibliotek för att importera OBJ och MTL-filer krävs dock och den nödvändiga koden finns i filen babylon.objFileLoader.js, som ges ut av Babylon.js och följer med vid nedladdning av

(19)

Sammanfattningsvis kräver implementationen med Three.js totalt fyra kodbibliotek, medan implementationen med Babylon.js endast kräver två kodbibliotek12_{. Den sista}

länkade filen är fpsmeter.js och används endast för att hämta FPS-värden vid mätningar.

Figur 7 Three.js länkade scriptfiler

Figur 8 Babylon.js länkade scriptfiler 5.2.3 Uppdatera 3D-modellvisaren till Three.js r113

Det första som gjordes var att uppdatera Lortis (2016) 3D-modellvisare till Three.js version r113. Uppdateringen innebar att hämta version r113 från Three.js Github-sida och sedan ersätta de gamla Three.js filerna med de nya från version r113. Därefter gjordes nödvändiga ändringar i koden för att 3D-modellvisaren skulle fungera med version r1133_.

5.2.4 Scenen

Funktionen createScene()4_{innehåller koden som skapar och konfigurerar}

3D-modellvisarens scen. Koden för createScene() i de både implementationerna kan ses i figur 9 och 10. I båda fallen är scenen ett objekt som måste skapas och lagras som variabeln scene. En skillnad som kan ses i figur X är att i implementationen med Bablyon.js anges bakgrundsfärgen med scenobjektets clearColor-egenskap 5 _{. I}

Three.js anges bakgrundsfärgen med en metod från renderingsobjektet, som kan ses i figur 15. Det krävs också att scenobjektets egenskap useRightHandedSystem är satt till true i Babylon.js för att 3D-objekt i scenen inte ska bli spegelvända vid rendering

6_{, jämfört med implementationen med Three.js.}

(20)

Figur 9 Three.js createScene()

Figur 10 Babylon.js createScene() 5.2.5 Kameran

Funktionen createCamera() 7_{, i figur 11, skapar och konfigurerar 3D-modellvisarens}

kameraobjekt. I implementationen med Three.js skapas ett kameraobjekt av typen THREE.PerspectiveCamera. Synfältet sätts till 45 grader och bildformatet anpassas till storleken på webbläsarfönstret, genom att använda window.innerWidth och window.innerHeight. Kameraobjektet har ingen inbyggd funktionalitet för orbit-kontroller. För att aktivera orbit-kontroller för kameraobjektet måste objektet THREE.OrbitControls skapas, vilket görs i funktionen createCameraControls() 8_,

som kan ses i figur 12. Kameran får en tröghetsfaktor på 0.25, genom att använda egenskaperna enableDamping och dampingFactor. Därefter flyttas kameraobjektet 10 enheter längs Z-axeln, vilket innebär att kameran positioneras 10 enheter ifrån scenens origo. Egenskapen enableZoom tillåter användaren att zooma in och ut med musens scroll-hjul 9_.

Babylon.js har en typ av kameraobjekt med inbyggd funktionalitet för orbit-kontroller. Alltså krävs bara ett objekt för att få samma funktionalitet som implementationen med Three.js och därför används bara en funktion i Babylon.js, som rent kodmässigt utför samma uppgift som createCamera() och createCameraControls() i Three.js. Denna funktion kan ses i figur 13. Kameraobjektet heter BABYLON.ArcRotateCamera. Synfältets standardvärde i Babylon.js är 45 och därför behövs inte någon kod för att konfigurera synfältet i implementationen med Babylon.js. För att aktivera orbit-kontrollerna används metoden attachControl(). Kamerans tröghet sätts med egenskapen inertia10_{. Babylon.js beräknar kameras tröghet annorlunda än Three.js}

och därför behövs ett högre tröghetsvärde. 0.75 är ett värde som resulterar i en tröghet som är så lik implementationen i Three.js som möjligt. Standardvärdet för kamerans rörelsehastighet är betydligt högre i Babylon.js än i Three.js. Genom att sätta egenskaperna angularSensibilityX och angularSensibilityY till 50011_{uppnås en}

rörelsehastighet liknande den i implementationen med Three.js. Även egenskapen

function createScene() { scene = new THREE.Scene(); }

function createScene() {

scene = new BABYLON.Scene(engine);

scene.clearColor = new BABYLON.Color3(0.1, 0.1, 0.1); scene.useRightHandedSystem = true;

(21)

wheelPrecision krävde justering12_{för att zoom-funktionen skulle bete sig likadant som}

i implementationen med Three.js.

Figur 11 Three.js createCamera()

Figur 12 Three.js createCameraControls()

Figur 13 Babylon.js createCamera() 5.2.6 Ljuskällor

Three.js och Babylon.js har olika varianter av ljusobjekt som kan placeras i scenen som ljuskällor. I detta fall är samtliga ljuskällor i scenen är riktade ljus (engelska: directional lights), som både Three.js och Babylon.js har stöd för. Ett riktat ljus i både Three.js och Babylon.js är en ljuskälla som belyser från en angiven riktning genererar även skuggor. Tre ljuskällor skapas; Ett ljus som belyser modellen från höger, ett som belyser från vänster och ett som belyser bakifrån.

12_{https://github.com/b16johso/webgl-3d-model-viewer-using-babylon.js/commit/2375c4f}

function createCamera() {

camera = new THREE.PerspectiveCamera(45, window.innerWidth / window.innerHeight, 1, 1000);

camera.position.z = 10; }

function createCameraControls() {

controls = new THREE.OrbitControls(camera, renderer.domElement); controls.enableDamping = true;

controls.dampingFactor = 0.25; controls.enableZoom = true; }

(22)

Funktionen createLights() 1314_{, figur 14 och 15, skapar tre ljuskällor som läggs till i}

scenen och belyser 3D-objektet. I Three.js anges ljuskällans färg i objektets parametrar, medan i Babylon.js anges färgen via egenskapen diffuse. Som tidigare nämnt skiljer sig koordinatsystemen åt mellan Three.js och Babylon.js och därför har X-, Y- och Z-värdena för positionering andra värden i implementationen med Babylon.js. En annan skillnad är att i Three.js läggs ljusobjekten till i scenen genom att använda scenobjektets add()-metod, medan i Babylon.js specificeras scenobjektet i ljusobjektets konstruktorparametrar och aktiveras sedan med metoden setEnabled().

Figur 14 Three.js createLights()

function createLights() {

keyLight = new THREE.DirectionalLight(new THREE.Color("rgb(255, 220, 200)"), 1.0 );

keyLight.position.set(-100, 0, 100);

fillLight = new THREE.DirectionalLight(new THREE.Color("rgb(200, 200, 255)"), 0. 75);

fillLight.position.set(100, 0, 100);

backLight = new THREE.DirectionalLight(0xffffff, 1.0); backLight.position.set(100, 0, -100).normalize();

(23)

Figur 15 Babylon.js createLights() 5.2.7 Importering av OBJ-fil

En 3D-modell i OBJ-format består av två filer; en OBJ-fil som innehåller geometridatan och en MTL-fil som innehåller data om material och texturer.

Funktionen importModel()15_{används för att importera bystets 3D-modell, samt}

texturer. För att importera en 3D-modell i Three.js med filformatet OBJ, tillsammans med dess texturer måste de båda objekten THREE.MTLLoader() och THREE.OBJLoader() användas 16 17_{, som kan ses i figur 13. THREE.MTLLoader()}

läser först in 3D-modellens MTL-fil med metoden load(). Den andra parametern i load()-metoden är en funktion som körs när filen lästs in. Denna funktion skapar ett THREE.OBJLoader()-objekt. THREE.OBJLoader gör det möjligt att läsa in 3D-modellens .obj-fil. Det använder en liknande load()-metod för att läsa in filen. När

15_{https://github.com/b16johso/webgl-3d-model-viewer-using-three.js/commit/2e42e58} 16_{https://github.com/b16johso/webgl-3d-model-viewer-using-three.js/commit/77f21b8} 17_{https://github.com/b16johso/webgl-3d-model-viewer-using-three.js/commit/fe88b03}

keyLight = new BABYLON.DirectionalLight("DirectionalLight", new BABYLON.Vector3( 100, 0, -100), scene);

keyLight.diffuse = new BABYLON.Color3.FromInts(255, 220, 200); keyLight.intensity = 1.0;

fillLight = new BABYLON.DirectionalLight("DirectionalLight", new BABYLON.Vector3 (-100, 0, -100), scene);

fillLight.diffuse = new BABYLON.Color3.FromInts(200, 200, 255); fillLight.intensity = 0.75;

backLight = new BABYLON.DirectionalLight("DirectionalLight", new BABYLON.Vector3 (-100, 0, 100), scene);

backLight.diffuse = new BABYLON.Color3.FromInts(255, 255, 255); backLight.intensity = 1.0;

(24)

OBJ-filen lästs in anropas ytterligare en funktion. I denna funktion skalas, roteras, samt transleras det resulterande 3D-objektet för att bystet ska stå upprätt och få plats inom kamerans synfält, samt vara vänd mot kameran. Rotation i Three.js anges i radianer och för att få fram det antal radianer som motsvarar 90 grader divideras pi med två.

Till skillnad från implementationen med Three.js sköter Babylon.js importering av både OBJ- och fil i samma metod, som kan ses i figur 16. Den tillhörande MTL-filen importeras automatiskt om den existerar i samma sökväg som OBJ-MTL-filen och har samma namn som OBJ-filen. Objektet som används är BABYLON.SceneLoader 18_.

(25)

Därefter manipuleras objektet på samma sätt som i implementationen med Three.js. Skillnaden är att objektet roteras på Y-axeln istället för på Z-axel.

Figur 16 Three.js importModel()

function importModel() {

var mtlLoader = new THREE.MTLLoader(); mtlLoader.setPath("assets/");

var url = "barone-exported.mtl";

mtlLoader.load(url, function (materials) { materials.preload();

var objLoader = new THREE.OBJLoader(); objLoader.setMaterials(materials); objLoader.setPath("assets/"); objLoader.load( "barone-exported.obj", function (object) { object.scale.set(0.2, 0.2, 0.2); object.rotation.x = -(0.5 * Math.PI); object.rotation.z = -(0.5 * Math.PI); object.position.set(0, -3, 0); scene.add(object); }, function (xhr) {

console.log((xhr.loaded / xhr.total) * 100 + "% loaded"); },

function (error) {

console.log("An error happened"); }

(26)

Figur 17 Babylon.js importModel() 5.2.8 Rendering

För att en scen i Three.js ska kunna renderas måste ett renderingsobjekt skapas, vilket görs i funktionen createRenderer() 19_{, som kan ses i figur 18. Renderingsobjektet heter}

THREE.WebGLRenderer och lagras i variabeln renderer. Renderingsobjektet har en

var model = BABYLON.SceneLoader.ImportMesh( "",

"./assets/",

"barone-exported.obj", scene,

function (mesh) {

var newMesh = BABYLON.Mesh.MergeMeshes(mesh, true, true, null, false, tr ue);

newMesh.scaling = new BABYLON.Vector3(0.2, 0.2, 0.2); newMesh.rotation.y = -(0.5 * Math.PI); newMesh.rotation.x = -(0.5 * Math.PI); newMesh.position.y = -3; console.log("Import successful"); }, function (xhr) {

console.log((xhr.loaded / xhr.total) * 100 + "% loaded"); },

function (error) {

console.log("An error happened"); }

(27)

Babylon.js hanterar rendering på ett annat sätt. I Babylon.js används istället ett objekt som heter BABYLON.Engine, som har en metod som heter runRenderLoop() som loopar igenom en funktion som specificeras i dess parametrar, varje frame. runRenderLoop() anropar då scenobjektets render() metod, som renderar scenen20_.

Koden som skapar renderingsobjektet och anropar renderingsmetoden kan ses i figur 19, och ligger i init()-funktionen.

Figur 18 Three.js createRenderer()

Figur 19 Babylon.js renderloop 5.2.9 FPS-mätning och Greasemonkey-script

För att mäta antal FPS används FPSMeter.js. FPSMeter.js är ett kodbibliotek som gör det enkelt skapa en mätare som med HTML-element visar FPS. För att spara FPS-värden vid mätning används ett Greasemonkey-script 21_{som hämtar värdet från}

FPS-mätarens DOM-element och sparar värdena i en array och upprepas efter ett givet intervall. För att mätningen ska kunna startas automatiskt under de automatiserade testerna så startar mätningsintervallet efter klickdetektion. Klickdetektion används eftersom det första kommandot som MacroRecorder-sekvensen utför är att trycka ned vänster musknapp för att sedan kunna flytta runt kameran i 3D-modellvisaren. Arrayen med FPS-värden laddas sedan ned som en CSV-fil vid ett keydown-event på

20_{https://github.com/b16johso/webgl-3d-model-viewer-using-babylon.js/commit/cb1eff0} 21_{https://github.com/b16johso/webgl-fps-greasemonkey/commit/54b68f9}

function createRenderer() {

renderer = new THREE.WebGLRenderer();

renderer.setPixelRatio(window.devicePixelRatio);

renderer.setSize(window.innerWidth, window.innerHeight); renderer.setClearColor(new THREE.Color("hsl(0, 0%, 10%)"));

container.appendChild(renderer.domElement); }

engine = new BABYLON.Engine(canvas, true);

engine.runRenderLoop(function () { meter.tickStart();

(28)

(29)

6 Pilotstudie

För att säkerställa att det planerade experimentet är genomförbart och att 3D-modellvisarens kod, samt script för datainsamling fungerar korrekt utförs en pilotstudie. Pilotstudien går ut på att kameran flyttas runt efter ett förbestämt mönster under en bestämd tid, medan ett script samlar in FPS-värden som förekommer under testkörningen. I pilotstudien testas varje implementation av 3D-modellvisaren med 4 testfall, där varje testfall har olika komplexitetsnivåer. Varje komplexitetsnivå testas under 20 sekunder, med intervallet mellan mätpunkter är på 1 sekund, vilket innebär 20 mätpunkter per komplexitetsnivå, totalt 200 mätpunkter. Nedan presenteras mätningarnas resultat.

Under testning av båda implementationerna av 3D-modellvisaren körs applikationen på en lokal webbserver genom Live Server-tillägget för Microsoft Visual Studio Code (Visual Studio Marketplace, 2019). Samtliga mätningar utfördes i Mozilla Firefox, med hjälp av Macro Recorder (Macro Recorder, 2020) och ett Greasemonkey-script (appendix C).

6.1 Pilotstudie resultat

(30)

(31)

(32)

(33)

Figur 23 Pilotmätning testfall 4

(34)

Figur 24 Pilotstudie medelvärden med standardavvikelser

6.2 Pilotstudie diskussion

(35)

7 Utvärdering

Efter att pilotstudien utförts går det konstatera att studien är genomförbar och resultaten tyder på att det finns en märkbar skillnad i prestanda mellan Three.js Babylon.js som kan jämföras. Pilotstudiens resultat visar att Three.js presterar märkbart bättre än Babylon.js och klarar av att hålla en högre FPS. De två biblioteken som ska testas och jämföras har varit lokalt installerade för att utesluta extern påverkan från eventuella nätverksstörningar. I ett försök att utesluta eventuella prestanda skillnader orsakade av koden har logiken och grundstrukturen mellan de två implementationerna hållits så snarlika som möjligt.

Testning utförs med simulering av en användares interaktion med applikationen, genom förprogrammerade kamerasekvenser. I resultatet från pilotstudien fanns regelbundet återkommande dalar som syns i linjediagrammen. De uppstod vid samma tidpunkt i varje testfall. Troligtvis orsakas dessa dalar av den programmerade kamerarörelsen som utförs av inputsimuleringsverktyget, Macro Recorder, som användes. I det fallet att liknande återupprepande dalar uppstår i detta resultat, ska ytterligare en mätning göras med en annan kamerasekvens.

I detta kapitel presenteras testfallen som kommer utföras, samt de primära mätningarnas resultat. Samma mätningar som utfördes i pilotstudien kommer utföras

7.1 Specifikation av hårdvara och mjukvara

Specifikationerna för datorn som testerna utfördes på finns i tabell 4.

Operativsystem Processor Minne Grafikkort

Windows 10 Home Intel Core i5-8250U 8GB DDR3 Intel UHD Graphics 620

Tabell 4 Systemspecifikationer

7.2 Kodändringar från pilotstudien

Greasemonkey-scriptet har förändrats för att reducera mängden manuellt arbete som krävs när mätresultaten ska visualiseras. Under pilotstudien skapade scriptet en CSV-fil för varje testfall, innehållande FPS-värdena, som sedan fick slås samman manuellt. Greasmonkey-scriptet ändrades så att endast en CSV-fil skapas, innehållande FPS-värdena för samtliga testfall.

(36)

användas och då blir det för tidskrävande att programmera kamerasekvensen för hand, så istället används Macro Recorders ”record”-funktion för att spela in musrörelsen under en tid, vilket innebär att kamerasekvensen inte ställer tillbaka kameran i sitt ursprungsläge längre. Därför gjordes denna kodändring.

7.3 Presentation av undersökning

I pilotstudien utfördes varje testfall under 20 sekunder med mätningar varje sekund. För att få ut fler mätpunkter och därmed ett säkrare resultat ökas tiden som varje testfall körs under till 240 sekunder, eller 4 minuter. Testerna utförs i Firefox med samma Greasemonkey-script som användes under pilotstudien, med små modifikationer. Komplexitetsnivån ökas i varje testfall med en faktor av 5. Det innebär att antalet hörn börjar med 200K och ökas successivt med 1000K hörn per testfall. Testfallen som ska utföras, samt deras respektive komplexitetsnivåer (antal hörn) finns i tabell 5. Samma dator som användes under pilotstudien används för att utföra testerna. Testfall Antal hörn 1 200K 2 1200K 3 2200K 4 3200K 5 4200K

Tabell 5 Testfall och komplexitetsnivåer

(37)

Figur 25 Linjediagram FPS-värden testfall 1

Linjediagrammet i figur 26 visar resultatet för testfall 2. Jämfört med testfall 1 så är det betydligt större variation i resultatet för Three.js. Babylon.js har precis som i testfall 1 ett stort antal plötsliga dalar. Dock är dalarna större i testfall 2.

(38)

Linjediagrammet i figur 27 för testfall 3 visar att resultatet för Three.js har jämnats ut något jämfört med resultatet it testfall 2. Babylon.js visar färre stora dalar jämfört med testfall 2.

(39)

Figur 29 Linjediagram testfall 5

Figur 30 Stapeldiagram medelvärde och standardavvikelse

(40)

ANOVA-statistik p-värde

48.672728720233444 9.203118663043315e-12

Tabell 6 ANOVA-testresultat

7.4 Analys

Efter samtliga testfall har utförts går det att tydligt se skillnader mellan prestandan hos Three.js- och Babylon.js-implementationerna av 3D-modellvisaren. Linjediagrammen i kapitel 7.3 tyder på att Three.js har en genomgående högre FPS än Babylon.js. Stapeldiagrammet i figur 30 visar att Three.js höll ett högre medelsnittsvärde av FPS i samtliga testfall. Dock är det svårt att säga vad det beror på att Three.js presterar bättre.

Det går även att konstatera att i 3D-modellvisaren implementerad med Three.js så fluktuerar FPS-värdet betydligt mer än i 3D-modellvisaren implementerad med Babylon.js. Det går att se i linjediagrammen och stapeldiagrammets standardavvikelser bevisar det. Babylon.js håller en förhållandevis jämn FPS-nivå, med frekventa plötsliga och stora dalar, som inte varar mer än någon sekund. Huruvida en ständigt fluktuerande FPS, eller en jämn FPS med plötsliga avbrott är att föredra är något som kan diskuteras och undersökas vidare i framtida arbeten.

En intressant observation är att FPS-nivån i 3D-modellvisaren implementerad med Babylon.js verkar stabilisera sig och antalet dalar minskar ju lägre den genomsnittliga FPS-nivån är. Även stapeldiagrammet tyder på att FPS-nivån jämnar ut sig ju lägre den genomsnittliga FPS-nivån är, då standardavvikelsen blir mindre med varje testfall.

7.5 Slutsatser

(41)

det är en 3D-applikation med en statisk kamera eller 3D-applikation med en interaktiv kamera.

(42)

8 Avslutande diskussion

8.1 Sammanfattning

Två populära WebGL-bibliotek, Three.js och Babylon.js, jämfördes för att se vilket av biblioteken som presterade effektivast med anseende på FPS. För att jämföra prestandan mellan de två olika biblioteken implementerades en 3D-modellvisare i två varianter; en implementerad med Three.js och en implementerad med Babylon.js. Det är 3D-modellvisarens FPS som testas och mäts och vars uppmätta nivå avgör hur väl ett bibliotek presterar. FPS (engelska ”frames per second”), eller bilder per sekund, är något som bevisats ha stor påverkan hos en användares upplevelse av rörliga eller interaktiva medier. Låg FPS kan leda till en negativ upplevelse för användaren (Gulliver & Ghineas, 2004).

För att svara på frågeställningen jämförs de två biblioteken genom ett empiriskt experiment. I experimentet används 5 olika testfall för att samla FPS-värden. Användarinteraktion simuleras under varje testfall med hjälp av programmet Macro Recorder, genom en förinspelad kamerasekvens som utför olika kamerainteraktioner under mätningarna.

Resultatet, som presenteras i kapitel 7, visar på att Three.js presterar något bättre än Babylon.js vid rendering av scener med hög komplexitet och därmed motvisas hypotesen att Three.js skulle prestera sämre än Babylon.js.

8.2 Diskussion

Att implementera 3D-grafik med WebGL i en webbapplikation visade sig vara mindre komplicerat än förväntat. Erfarenheten i detta arbete var att Babylon.js var enklare att arbeta med, vad gäller implementering av interaktivitet, än Three.js. Därför kan Babylon.js vara att föredra över Three.js i vissa situationer.

Som tidigare konstaterats i kapitel 2 så är Three.js och Babylon.js bland de mest använda Javascriptbiblioteken för WebGL. Trots detta finns det ytterst få studier som jämför de två biblioteken och hur de presterar gentemot varandra. Därför fanns det inte mycket tidigare forskning inom ämnet att utgå ifrån. Syftet med denna var att komma fram till vilket av biblioteken Three.js och Babylon.js som presterar bäst i en 3D-modellvisare.

(43)

biblioteken som studien jämför utvecklas och förbättras ständigt. Därför finns det en begränsad tidsram för hur länge denna studie är relevant.

En upptäckt som gjordes under pilotstudien var att Macro Recorder, som används för att simulera input från en användare, möjligtvis kan ha en negativ inverkan på resultatet. I linjediagrammen som presenterar resultaten av pilotstudien, som kan ses i kapitel 6, uppstår märkbara dalar vid exakt samma tidpunkt i samtliga testfall. Därefter gjordes ändringar i kamerasekvensen som körs av Macro Recorder och samtliga testfall upprepades. Resultaten från testfallen med den modifierade kamerasekvensen visade inte samma dalar som uppstod med den första kamerasekvensen. Resultatet tyder på att dalarna kan ha uppstått på grund av den valda kamerasekvensen och hur Macro Recorder exekverar den. När ytterligare en ny kamerasekvens skapades, denna gång från grunden, för användning i den huvudsakliga studien, visade dock resultaten inga regelbundna dalar som i pilotstudien. Det går därför inte dra någon slutsats huruvida Macro Recorder och kamerasekvensen har någon direkt negativ effekt på prestandan eller inte, men man bör vara medveten om att det finns en möjlighet när resultatet ska analyseras och presenteras.

3D-modellen som användes för att testa artefaktens prestanda i studien är en något orealistisk representation av vad som skulle användas i en liknande applikation i verkligheten. 3D-modellen som användes är för komplex och har för högupplösta texturer för vad som är rimligt att strömma över internet. Filstorleken är relativt stor och tar både lång tid att läsas in av webbläsaren och att läsas in av WebGL. I verklig implementering av en liknande applikation skulle 3D-modellen optimeras för webben innan användning. Orsaken till att en så komplex modell användes var främst för att se hur de båda biblioteken som testas presterar under hård press.

8.2.1 Etik och samhälle

Ett vanligt forskningsetiskt problem är replikerbarhet. I denna studie är prestandan hos artefakten stort beroende av hårdvaran hos maskinen som kör artefakten. Det är främst maskinens GPU som påverkar hur väl artefakten presterar och beroende på hur kraftig GPU som används för att utföra experimentet kan resultatet variera stort. Vissa delar av studien, såsom val av hårdvara, kan därför vara svårt att replikera.

(44)

Samhällsnyttan som denna studie bidrar med är att ge utvecklare som vill implementera t.ex interaktiva 3D-förhandsvisningar för produkter i e-handelstjänster en uppfattning om vilket WebGL-ramverk som presterar bäst i en interaktiv 3D-applikation såsom 3D-modellvisaren som används i denna studie. Med en allt större växande e-handel runt om i världen, samt utveckling inom 3D-grafik i webbläsare med WebGL. Med utveckling av 3D-skanningsteknologi ökar möjligheten för e-handelssidor att kunna rendera realistiska och interaktiva 3D-förhandsvisningar av produkter. Med hjälp av denna studie kan utvecklare informera sig om vilket WebGL-bibliotek som presterar bäst i en sådan situation.

En samhällsrisk är att en ökad användning av WebGL 3D-applikationer på webben kan det leda till ökad batteriförbrukning hos mobiler. 3D-applikationer är betydligt mer resurskrävande än traditionella webbapplikationer som endast visar text och bilder. Högre resursanvändning är energikrävande och skulle leda till att användarnas mobiltelefoner behöver laddas oftare och förbrukar därmed energi. Högre resursanvändning bidrar även till slitage på komponenterna i mobiltelefonen och kan på så vis även påverka livslängden hos mobiltelefonen.

En annan samhällsrisk som en ökad användning av WebGL 3D-grafik i e-handelssidor skulle medföra är ökad nätverkstrafik. Komplexa 3D-modeller med högupplösta texturer, som krävs för att användaren ska få en så verklig upplevelse av produkten som möjligt, medför stora filstorlekar som skapar mycket nätverkstrafik och kan bli ett stort problem för t. ex användare som har begränsad datamängd för internetanvändning. För användare som använder mobilnätet kan de stora filstorlekarna även leda till stora kostnader. Därför kan det vara bra att göra det valbart för slutanvändaren om de vill förhandsvisa en produkt i 3D eller i traditionell 2D.

8.3 Framtida arbete

I denna undersökning testades och jämfördes de två WebGL-biblioteken Three.js och Babylon.js genom att skapa en 3D-modellvisarapplikation och sedan mäta FPS vid rendering av en scen med olika grader av komplexitet. Det finns ytterligare bibliotek för WebGL, utöver Three.js och Babylon.js. I ett framtida arbete skulle det vara intressant att utföra samma experiment på andra bibliotek och se hur de presterar jämfört med Three.js och Babylon.js.

(45)

Det skulle också vara intressant att mäta på inläsningstiden av 3D-modeller hos de olika implementationerna av 3D-modellvisaren. Ju komplexare en 3D-modell är, desto större blir filstorleken och därmed blir inläsningstiden längre. Det skulle även vara intressant att mäta på om det skiljer sig något i inläsningstid mellan Three.js och Babylon.js. Om det tar lång tid för applikationen att läsa in en 3D-modell kan det skapa en negativ upplevelse hos användaren, vilket helt skulle nullifiera den positiva effekten en hög FPS skulle ha.

I denna studie används en extern FPS-räknare, i form av javscript-biblioteket FPSMeter.js, i kombination med ett Greasemonkey-script för att mäta FPS. I ett framtida arbete skulle titta på andra alternativ för att mäta FPS, som inte kräver att några externa filer laddas in, t. ex om en webbläsare har inbyggda verktyg för mätning av prestanda.

Experimentet utfördes med webbläsaren Mozilla Firefox. Firefox kan vara en möjlig källa till det ojämna resultatet som kan ses i linjediagrammen i kapitel 7. Därför skulle det vara intressant att utföra samma experiment i andra webbläsare, till exempel Google Chrome, Microsoft Edge, eller Apple Safari. Resultatet från en studie som jämför WebGL-prestandan mellan olika webbläsare med hjälp av experimentet från denna studie skulle kunna hjälpa webbläsarleverantörer att hitta lösningar för att optimera sina webbläsare för ökad prestanda med WebGL.

(46)

Referenser

Babylon.js. 2020. Babylon.js Documentation. [ONLINE] Available at: https://doc.babylonjs.com/. [Accessed 19 February 2020].

Borges, H., Hora, A., Valente, M., (2016). Predicting the Popularity of GitHub Repositories. In PROMISE 2016: The 12th International Conference on Predictive Models and Data Analytics in Software Engineering. Ciudad Real, Spain, September 2016. New York, NY, United States: Association for Computing Machinery. 1 - 10.

Butkiewicz, M., Madhyastha, H., Sekar, V., 2013. Characterizing Web Page Complexity and Its Impact. IEEE/ACM Transactions on Networking, 22(3), 943 - 956.

Cai, J., Nerukar, A., (1998). Making benchmarks uncheatable. In IEEE International Computer Performance and Dependability Symposium. IPDS'98. Durham, NC, USA, 9-9 Sept. 1998. Piscataway, NJ, US: IEEE. 216 - 226.

cgtrader. 2020. Bust of Baronesse Sipiere free 3D model. [ONLINE] Available at: https://www.cgtrader.com/free-3d-models/scanned/various/bust-of-baronesse-sipiere. [Accessed 9 April 2020].

Feng, L., Wang, C., Li, C., Li, Z., (2011). A Research for 3D WebGIS based on WebGL. In

Proceedings of 2011 International Conference on Computer Science and Network Technology. Harbin, China, 24-26 Dec. 2011. Piscataway, NJ, USA: IEEE. 348 - 351.

FPSMeter. 2020. FPSMeter.js. [ONLINE] Available at: https://darsa.in/fpsmeter/. [Accessed 10 April 2020].

GitHub. 2019. GitHub. [ONLINE] Available at: https://github.com/. [Accessed 12 December 2019].

Gulliver, S., Ghinea, G., (2004). Changing frame rate, changing satisfaction? [multimedia quality of perception]. In 2004 IEEE International Conference on Multimedia and Expo (ICME). Taipei, Taiwan, 27-30 June 2004. Piscataway, NJ, USA: IEEE.

Hand, C., 1997. A Survey of 3D Interaction Techniques. Computer Graphics Forum, 16 (5), 269-281.

Horak, T., Kister, U., Dachselt, R. 2018. Comparing Rendering Performance of Common Web Technologies for Large Graphs. [POSTER] Exhibited at IEEE VIS 2018. Berlin, Germany, 21-26 Oct 2018

(47)

Lindman, J., Paajanen, A., Rossi, M., (2010). Choosing an Open Source Software License in Commercial Context: A Managerial Perspective. In 2010 36th EUROMICRO Conference on Software Engineering and Advanced Applications. Lille, France, 1-3 Sept. 2010. Piscataway, NJ, USA: IEEE. 237 - 244.

Lorti, 2016. WebGL 3D Model Viewer Using three.js. [ONLINE] Available at: https://github.com/Lorti/webgl-3d-model-viewer-using-three.js. [Accessed 23 March 2020]. Macro Recorder. 2020. Macro Recorder. [ONLINE] Available at: https://www.macrorecorder.com/. [Accessed 8 April 2020].

MDN Web Docs. 2019. WebGL: 2D and 3D graphics for the web - Web APIs | MDN. [ONLINE] Available at: https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API. [Accessed 12 December 2019].

Moreau-Mathis, J., 2016. Babylon.js Essentials. 1st ed. Birmingham, United Kingdom: Packt Publishing.

Muennoi, A., Hormdee, D., (2016). 3D Web-based HMI with WebGL Rendering Performance.

In 2016 3rd International Conference on Mechanics and Mechatronics Research (ICMMR 2016). Chongqing, China, June 15-17. MATEC Web of Conferences.

Parisi, T., 2012. WebGL: Up and Running. 1st ed. Sebastopol, CA, USA: O'Reilly Media Inc.. Reips, U.-D. (2000). The Web Experiment Method: Advantages, disadvantages, and solutions. In M. H. Birnbaum (Ed.), Psychological experiments on the Internet (pp. 89-118). San Diego, CA: Academic Press.

Tan, D., Robertson, G., Czerwinski, M., (2001). Exploring 3D navigation: combining speed-coupled flying with orbiting. In CHI '01: Proceedings of the SIGCHI Conference on Human

Factors in Computing Systems. Seattle, Washington, USA, March. New York, NY, USA:

Association for Computing Machinery. 418-425.

Three.js. 2020. Three.js Docs. [ONLINE] Available at: https://threejs.org/docs/. [Accessed 19 February 2020].

Three.js GitHub. 2020. Migration Guide. [ONLINE] Available at: https://github.com/mrdoob/three.js/wiki/Migration-Guide. [Accessed 8 April 2020]. Visual Studio Marketplace. 2019. Live Server. [ONLINE] Available at: https://marketplace.visualstudio.com/items?itemName=ritwickdey.LiveServer. [Accessed 8 April 2020].

(48)

Appendix A - Three.js HTML-fil.

<!DOCTYPE html>

<title>WebGL 3D Model Viewer Using three.js</title> <meta charset="utf-8" />

var camera, controls, scene, renderer; var keyLight, fillLight, backLight;

(49)

container = document.createElement("div"); document.body.appendChild(container); /* Camera */ createCamera(); /* Scene */ createScene(); /* Lights */ createLights(); /* Model */ importModel(); /* Renderer */ createRenderer(); /* Controls */ createCameraControls(); /* Events */

window.addEventListener("resize", onWindowResize, false); window.addEventListener("keydown", onKeyboardEvent, false); }

function onWindowResize() {

(50)

renderer.render(scene, camera); } function onKeyboardEvent(e) { if (e.code === "KeyI") { importModel(); } } function createScene() {

scene = new THREE.Scene(); }

camera = new THREE.PerspectiveCamera(45, window.innerWidth / wind ow.innerHeight, 1, 1000);

camera.position.z = 10; }

keyLight = new THREE.DirectionalLight(new THREE.Color("rgb(255, 2 20, 200)"), 1.0);

keyLight.position.set(-100, 0, 100);

fillLight = new THREE.DirectionalLight(new THREE.Color("rgb(200, 200, 255)"), 0.75);

fillLight.position.set(100, 0, 100);

backLight = new THREE.DirectionalLight(0xffffff, 1.0); backLight.position.set(100, 0, -100).normalize(); scene.add(keyLight); scene.add(fillLight); scene.add(backLight); } function createRenderer() {

renderer = new THREE.WebGLRenderer();

renderer.setPixelRatio(window.devicePixelRatio);

(51)

function createCameraControls() {

controls = new THREE.OrbitControls(camera, renderer.domElement); controls.enableDamping = true;

controls.dampingFactor = 0.25; controls.enableZoom = true; }

var mtlLoader = new THREE.MTLLoader(); mtlLoader.setPath("assets/");

var url = "barone-exported.mtl";

mtlLoader.load(url, function (materials) { materials.preload();

var objLoader = new THREE.OBJLoader(); objLoader.setMaterials(materials); objLoader.setPath("assets/"); objLoader.load( "barone-exported.obj", function (object) { object.scale.set(0.2, 0.2, 0.2); object.rotation.x = -(0.5 * Math.PI); object.rotation.z = -(0.5 * Math.PI); object.position.set(0, -3, 0); scene.add(object); }, function (xhr) {

console.log((xhr.loaded / xhr.total) * 100 + "% loade d");

},

function (error) {

(52)

Appendix B - Babylon.js HTML-fil.

<!DOCTYPE html>

<title>WebGL 3D Model Viewer Using babylon.js</title> <meta charset="utf-8" />

var container, canvas;

var camera, controls, scene, engine; var keyLight, fillLight, backLight;

(53)

canvas = document.createElement("canvas"); container.appendChild(canvas);

engine = new BABYLON.Engine(canvas, true); // Generate the BABYLO N 3D engine /* Scene */ createScene(); /* Camera */ createCamera(); /* Lights */ createLights(); /* Model */ importModel(); /* Renderer */ engine.runRenderLoop(function () { //Update FPSMeter each frame meter.tickStart();

scene.render(); meter.tick(); });

/* Events */