Datavisualisatie in VR op een Oculus Quest

Bachelor Informatica

Datavisualisatie in VR op een

Oculus Quest

Matthijs Bes

25 oktober 2020

Inf

orma

tica

—

Universiteit

v

an

Amsterd

am

Samenvatting

Met het groter en complexer worden van datasets wordt het steeds uitdagender om een goede visualisatie van de data te maken. In het verleden zijn al visualisaties gemaakt in VR, met wisselend succes. Nu VR-apparaten in toenemende mate toegankelijk worden voor particulieren, is het interessant om te onderzoeken of datavisualisatie op een dergelijk apparaat te realiseren is. In deze scriptie wordt de implementatie van een glyphvisualisatie applicatie beschreven voor de Oculus Quest. Het is hierbij de uitdaging om de hardware zo efficiënt mogelijk te gebruiken. De applicatie kan een CSV-bestand visualiseren, waarbij de kolommen van het CSV-bestand door de gebruiker gemapt kunnen worden op de visuele variabelen die Jacques Bertin beschreef.

Inhoudsopgave

1 Introductie 7 2 Theoretische achtergrond 9 2.1 Eerdere resultaten . . . 9 2.2 Visuele variabelen . . . 9 3 Methode 13 3.1 Overwegingen . . . 13 3.2 VR hardware . . . 13 3.3 Visualisatiemethoden . . . 14 3.3.1 Glyph Visualisatie . . . 14 3.3.2 VTK . . . 14 3.3.3 IATK . . . 14 3.4 Software ontwikkelomgeving . . . 14 3.4.1 Game engine . . . 14 3.4.2 WebXR . . . 15 4 Implementatie 17 4.1 Aanpassingen Oculus SDK . . . 19 4.2 Scripts en classes . . . 21 5 Experimenten 23 5.1 Optimalisatie en experimenten . . . 23 6 Discussie 31 6.1 Verder onderzoek . . . 31

HOOFDSTUK 1

Introductie

Met de technologische vooruitgang van computer hardware wordt het mogelijk steeds grotere hoeveelheden data te genereren en op te slaan. Zowel wetenschappelijk onderzoek en simulaties als bedrijven maken gebruik van deze mogelijkheid [10]. Hierbij wordt gezocht naar correcte, bruikbare inzichten in het fenomeen dat zij bestuderen door middel van analyse van deze data. Met de conclusies die getrokken worden, kunnen vervolgens keuzes gemaakt worden voor vervolg-onderzoek of een bedrijfsstrategie. Een essentieel onderdeel in dit proces is het visualiseren van de data. Het menselijk brein is goed in het herkennen van visuele patronen en datavisualisatie zorgt voor een intuïtief begrip van de dataset die bestudeerd wordt [2].

Echter zit er ook een uitdaging in de steeds groter wordende datasets. Het maken van een geschikte visuele representatie van de data wordt namelijk steeds lastiger: Hoe kan een com-plexe dataset op zo’n manier worden weergegeven dat de menselijke patroonherkenning optimaal omgezet wordt in begrip van de data?

Het toepassen van virtuele realiteit (VR) in een datavisualisatie zorgt ervoor dat de visualisa-tie driedimensionaal is. Ook kan VR een hogere mate van immersiviteit brengen [4]. Het maakt het mogelijk om rondom een visualisatie te lopen, eronderdoor of erlangs te kijken, objecten te pakken en bijvoorbeeld met handgebaren te roteren. Er is steeds meer bewijs dat immersivi-teit en een verhoogd omgevingsbewustzijn van de gebruiker een positieve impact hebben op het begrip van de data [13][4].

In deze scriptie wordt de ontwikkeling van een applicatie beschreven waarin data gevisuali-seerd kan worden in VR op een low-end HMD. Hierbij wordt gebruik gemaakt van een Oculus Quest en is het de uitdaging om de beperkte capaciteit van de hard- en software van het HMD optimaal te gebruiken. Er wordt gekeken naar verschillende manieren om een visualisatie te reali-seren en de performance van deze verschillende manieren wordt vergeleken. De onderzoeksvraag luidt: Op welke manier kan een low-end HMD het beste gebruikt worden om data te visualiseren in VR?

In het volgende hoofdstuk wordt de theoretische context beschreven. Aan bod komen onder andere eerder behaalde resultaten en theorie over datavisualisatie. In de daaropvolgende sectie wordt bekeken hoe de theorie het beste is toe te passen in de implementatie. Vervolgens wordt de implementatie zelf beschreven. Hierin komen de verschillende functionaliteiten en ontwerpkeuzes aan bod. In het laatste hoofdstuk wordt gekeken naar de performance van de verschillende implementaties.

HOOFDSTUK 2

Theoretische achtergrond

2.1

Eerdere resultaten

Het idee van wetenschappelijke visualisatie in VR is niet nieuw. Al in het begin van de jaren 90 zijn er pogingen gedaan om met een head mounted display (HMD) wetenschappelijke data te visualiseren [21].

Virtuele realiteit - en de immersiviteit die het brengt - bevordert begrip van data in onder-zoeksdomeinen die van zichzelf van ruimtelijke aard zijn. Voorbeelden hiervan zijn paleontologie, hersentumoren, de verkenning van ondergrondse grotten, MRI, organische chemie, en fysica [13].

2.2

Visuele variabelen

Een invloedrijke onderzoeker op het gebied van datavisualisatie was Jacques Bertin. Hij was een cartograaf die bekend is geworden met zijn theoretische werk op het gebied van grafische representaties en datavisualisatie. Hij was zeer geïnteresseerd in het vraagstuk hoe data zo efficiënt mogelijk te visualiseren. Zijn ervaring op het gebied van cartografie leidde tot zijn publicatie van het boek “Sémiologie Graphique"[23][5]. Dit boek wordt gezien als een belangrijke bijdrage op het gebied van datavisualisatie. In dit invloedrijke boek introduceert Bertin zijn visuele variabelen en beschrijft hij hoe deze variabelen het beste te gebruiken zijn voor het visueel representeren van data.

De acht visuele variabelen die Bertin benoemt zijn: positie (in 2 dimensies), grootte, vorm, saturatie, kleur, oriëntatie en textuur. Deze variabelen hebben eigenschappen die bepalen hoe ze gebruikt dienen te worden in een visuele representatie. Deze eigenschappen zijn: selectiviteit, associativiteit, kwantitativiteit, ordinaliteit en lengte.

• Selectiviteit: Een visuele variabele is selectief als het veranderen van deze variabele voor een object makkelijk zichtbaar is in een groep van objecten.

• Associativiteit: Een visuele variabele is associatief als de variabele ervoor zorgt dat een groep objecten waarvan deze variabele overeenkomt makkelijk te onderscheiden is als groep. • Kwantitativiteit: Een visuele variabele is kwantitatief als het kan worden geïnterpreteerd

als numerieke hoeveelheid.

• Ordinaliteit: Een visuele variabele is ordinaal als deze gebruikt kan worden om een rang-schikking aan te geven.

• Lengte: Het aantal verschillende waardes dat een visuele variabele aan kan nemen met betrekking tot een bepaald doel. (bijv. kleur is alleen selectief als het aantal kleuren (lengte) lager is dan 7, maar blijft associatief tot ongeveer 10 kleuren)

Deze visuele variabelen en eigenschappen zijn later uitgebreid door onder andere Mackinlay [19] en MacEachren [17][18]. Deze uitbreiding is te zien in Figuur 2.1. Mackinlay maakte ook een rangschikking van de variabelen per eigenschap. Hiermee werd dus beschreven welke visuele ei-genschappen het meest selectief, associatief, kwantitatief en ordinaal zijn. Een overzicht hiervan is te zien in Figuur 2.2.

In dezelfde publicatie introduceerde Mackinlay een programma dat automatisch visuele re-presentaties creëerde, zonder tussenkomst van de gebruiker. Hierbij week hij af van de visie van Bertin, die in La Graphique zijn mening onderschreef dat een visuele representatie herschikbaar moet zijn:

“This is a fundamental point, because it is the internal mobility of the image which characte-rizes modern graphics. A graphic is no longer ’drawn’ once and for all; it is ’constructed’ and reconstructed (manipulated) until all the relationships which lie within it have been perceived." [6, p.5]

“A graphic is never an end in itself; it is a moment in the process of decision-making. The best graphic operations are those carried out by the decision-maker himself." [6, p.16]

Vraagstukken over data-analyse begonnen bij Bertin vaak met een tweedimensionale tabel. Hier-bij maakte hij onderscheid tussen datadimensies die herschikbaar waren en datadimensies die niet herschikbaar waren. Een voorbeeld van een dimensie die niet herschikbaar is, is tijd. In zo’n geval wil men de natuurlijke volgorde van de waardes behouden. Waren beide dimensies echter herschikbaar, dan was de geschikte visualisatie volgens Bertin een matrix.

Om nu meerdere visualisaties te maken met dezelfde matrix, werden vaak rijen en kolommen uitgeknipt en herschikt. Hier werd een fotokopie van gemaakt om vervolgens weer te herschikken tot een nieuwe visualisatie. Een voorbeeld hiervan is te zien in Figuur 2.3. Dit handmatig her-schikken van matrices kostte erg veel tijd. Bertin was dan ook enthousiast over de mogelijkheden die computers konden brengen voor het herschikken van visualisaties.

In deze scriptie wordt een VR-applicatie ontwikkeld voor de Oculus Quest, waarbij de prin-cipes van Bertin gehanteerd worden. Er wordt dus een visualisatie gemaakt van data, waarbij rekening gehouden wordt met de visuele variabelen die hij introduceerde. De gebruiker moet invloed hebben op hoe de visualisatie eruit komt te zien, en de visualisatie moet herschikbaar zijn, zodat datavisualisatie een proces blijft waarbij de gebruiker verbanden extraheert uit de data en niet een doel op zichzelf wordt.

Figuur 2.1: MacEachren’s uitbreiding op de visuele variabelen van Bertin. Figuur overgenomen van Roth, 2016 [25].

Figuur 2.2: Mackinlay’s uitbreiding op de visuele variabelen van Bertin [19].

Figuur 2.3: Het veranderen van cirkeldiagrammen in matrices, die vervolgens herschikt werden tot een duidelijke visualisatie [23].

HOOFDSTUK 3

Methode

3.1

Overwegingen

Om datavisualisatie in VR te realiseren, is het nodig om een aantal keuzes te maken. Ten eerste moet de hardware gekozen worden waarop het datavisualisatieprogramma zal draaien. Er zijn verschillende head mounted displays op de markt met ieder zijn voor- en nadelen.

Ten tweede moet bekeken worden welke visualisatiemethoden beschikbaar zijn. Er zijn een aantal API’s en softwarepakketten die kunnen helpen bij het maken van een visualisatie. Daar-naast is het mogelijk om geheel zelf een applicatie te maken.

Ten derde moet een software ontwikkelomgeving gekozen worden. Hier kan gedacht worden aan een game engine als Unity of Unreal Engine. Ook moet er gedacht worden aan het platform waarop de applicatie moet draaien. Zo is het mogelijk om een applicatie te maken die direct draait op het besturingssysteem van de hardware of kan een webapplicatie gemaakt worden die onafhankelijk is van het besturingssysteem van de hardware.

3.2

VR hardware

De twee bekendste categorieën van VR hardware zijn de CAVE (Cave Automatic Virtual En-vironment) en het HMD (Head Mounted Display). Bij CAVE technologie staat de gebruiker in een kamer waarvan één of meer muren - en eventueel de vloer - bestaan uit een groot display. De gebruiker heeft een bril op die 60 keer per seconde afwisselend het linker- en rechteroog afdekt. De schermen zijn gesynchroniseerd op de bril, zodat het correcte beeld altijd op het correcte oog valt. Op deze manier wordt stereoscopie gerealiseerd [8].

Een HMD is een scherm dat de gebruiker op zijn hoofd draagt, als een bril waardoor hij de virtuele wereld in kijkt. Vaak wordt het gebruikt in combinatie met hardware waarmee interactie met de virtuele wereld mogelijk gemaakt wordt. Veelal zijn deze headsets verbonden met een pc die zorgt voor de rekenkracht. Ook zijn er standalone modellen die uitgerust zijn met een eigen processor. De headsets die de rekenkracht van de computer gebruiken, hebben over het algemeen een hoger resolutie scherm, omdat de pc meer computerkracht kan leveren dan de processors in de standalone modellen.

Voor deze scriptie is geen CAVE-systeem beschikbaar. Ook hebben weinig mensen toegang tot een CAVE, waar HMD’s voor de consument beschikbaar zijn. Daarom is er voor gekozen om een applicatie te ontwikkelen voor een HMD. Voor vrijwel al het eerdere werk dat gedaan is op het gebied van datavisualisatie in VR op een HMD is een high-end HMD gebruikt, dat verbonden is met een computer. Echter is er nog weinig gedaan met een low-end, standalone HMD.

Een low-end, standalone HMD als de Oculus Quest heeft een significant lagere aanschafprijs dan een high-end HMD als de HTC Vive of Oculus Rift S. Daarnaast moet voor de high-end HMD’s een pc met voldoende rekenkracht aangeschaft worden. Het is interessant om te bekijken

of datavisualisatie in VR ook te realiseren is op een low-end HMD, omdat de lagere kosten ervoor zorgen dat het beschikbaar is voor een breder publiek.

In deze scriptie is er daarom voor gekozen om gebruik te maken van een Oculus Quest. De Quest werkt op Android en is uitgerust met een Qualcomm Snapdragon 835. Deze processor werd ook gebruikt voor high-end Android smartphones van een paar generaties geleden. Denk hierbij aan de Samsung Galaxy S8, de OnePlus 5 en de Google Pixel 2.

3.3

Visualisatiemethoden

Er zijn verschillende manieren om een datavisualisatie te maken in VR. Om de visuele variabelen van Bertin te gebruiken, ligt een glyph visualisatie voor de hand. Hierbij wordt ieder datapunt omgezet in een object in de ruimte waar de visuele variabelen op toegepast kunnen worden. Er zijn verschillende frameworks beschikbaar die hierbij kunnen helpen.

3.3.1

Glyph Visualisatie

Een veel gebruikte manier van datavisualisatie is het omzetten van elk datapunt in een “glyph"[7]. Dit is een object in de ruimte dat een datapunt representeert met behulp van verschillende visuele attributen. Zo kan een glyph bijvoorbeeld een bepaalde vorm, kleur, grootte en positie hebben. De visuele attributen bieden een snelle en intuïtieve weergave van de data [25]. Echter zijn dit soort visuele representaties vaak weergegeven op een 2D-computerscherm. Hierdoor wordt van het brein gevraagd om de tweedimensionale weergave te interpreteren als een driedimensionale ruimte. Ook kunnen bepaalde driedimensionale patronen niet goed weergegeven worden op een tweedimensionaal scherm. Afhankelijk van de oriëntatie van de weergave kan een vlak in de driedimensionale ruimte er op een tweedimensionaal computerscherm bijvoorbeeld uit zien als een lijn. Het is daarom interessant om een glyph visualisatie in VR te realiseren.

3.3.2

VTK

In 2017 is de open-source toolkit VTK (Visualization Toolkit) door Kitware uitgebreid om deze op verschillende manieren te implementeren in VR[22]. VTK is een API waarmee verschillende rendering algoritmes voor wetenschappelijke visualisatie gerealiseerd kunnen worden. Deze VR-implementaties van VTK werken voor high-end HMD’s als de Oculus Rift of de HTC Vive, die aangesloten zijn op een PC. Echter is er weinig te vinden over het gebruik van VTK op een Oculus Quest.

3.3.3

IATK

In 2019 werd de Immersive Analysis Toolkit (IATK) geïntroduceerd. Het is een software pak-ket voor Unity dat gebruikers in staat stelt om datavisualisaties te maken in een immersieve omgeving. Het bestaat uit een GUI waarin op hoger abstractieniveau datavisualisaties kunnen worden samengesteld en een API voor meer controle op lager abstractieniveau. Het is gebouwd om schaalbaar te zijn en dus bruikbaar voor grotere datasets. [11] De GUI is gemaakt om in Unity te gebruiken, waar de visualisatie aangepast kan worden naar behoefte. Een screenshot hiervan is te zien in Figuur 3.1. Ook biedt het een aantal interacties, waarbij bijvoorbeeld ver-schillende assen van datasets bij elkaar gesleept kunnen worden om zo een visualisatie te maken. De assen kunnen ook met een simpel gebaar weer weggegooid worden uit de visualisatie.

3.4

Software ontwikkelomgeving

Figuur 3.1: Een screenshot van de presentatie van IATK [1]. Hier wordt een glyph visualisatie gemaakt met behulp van Unity.

kunnen worden. Hier kunnen vervolgens scripts aan toegevoegd worden en de gebouwde appli-catie kan geëxporteerd worden naar verschillende platforms, waaronder Android en WebXR. Het exporteren naar Android ligt voor de hand, omdat dat het besturingssysteem is dat de Quest draait. WebXR is een standaard waarbij VR applicaties op het web getoond kunnen worden.

De twee meest gebruikte game engines zijn Unity en Unreal Engine. Hoewel ze vergelijkbare features hebben, zijn er ook duidelijke verschillen tussen beiden.

Unity maakt gebruik van Javascript en C#, waar Unreal Engine gebruik maakt van Blueprints en C++.

Volgens een publicatie van Ithaca College, waarin onderzocht werd welke van deze twee game engines het meest geschikt was voor een vak waarbij studenten een game moesten ontwikkelen, is Unity iets minder complex en wat makkelijker aan te leren dan Unreal Engine. Ook heeft het betere online hulpmiddelen en tutorials en is het stabieler dan Unreal Engine. Daar tegenover staat dat het met Unreal Engine makkelijker is om een meer professioneel uitziende applicatie te maken [12].

3.4.2

WebXR

De WebXR Device API, ontwikkeld door W3C Immersive Web Community Group, biedt een platform-onafhankelijk interface voor functionaliteit voor alle AR- en VR apparaten. Met deze API kan op een eenvoudige manier WebGL gebruikt worden voor het renderen van immersieve applicaties op het web [20]. Een groot voordeel hiervan is dat allerlei verschillende VR-apparaten dezelfde applicatie kunnen draaien door naar de website te gaan waar deze gehost wordt. Mozzilla heeft de WebXRExporter voor Unity gemaakt [24], die gratis te downloaden is in de Unity Asset Store. Hiermee kan een Unity project geëxporteerd worden naar deze standaard in de vorm van HTML en Javascript. Er zijn voor deze scriptie pogingen gedaan om het uiteindelijke Unity project van de gebouwde applicatie te exporteren naar WebXR met behulp van deze WebXRExporter, maar zonder succes.

HOOFDSTUK 4

Implementatie

Er zijn een aantal functionele eisen waar de implementatie aan moet voldoen. De applicatie moet in staat zijn om:

• Een CSV bestand in te lezen

• Dit CSV bestand om te zetten in een glyph visualisatie

• De visuele variabelen van Bertin te gebruiken in deze visualisatie

• De gebruiker flexibiliteit te bieden in de mapping van visuele variabelen die gekozen wordt In de applicatie kan een visualisatie gemaakt worden van een CSV-bestand. Dit bestand wordt ingelezen door een C# Unity script dat wordt aangeroepen bij het opstarten van de applicatie. De kolommen van dit CSV-bestand kunnen vervolgens gemapt worden op de verschillende visuele variabelen van Bertin. De keuze voor deze mapping wordt aan de gebruiker overgelaten. De gebruiker heeft op de linkerpols een matrix van checkboxes zitten waarmee de mapping gemaakt kan worden. Aan deze matrix kunnen kolommen van het CSV-bestand toegevoegd worden, die vervolgens door middel van de checkboxes aan één of meer visuele variabelen toegewezen kunnen worden. Vervolgens klikt de gebruiker op ‘draw data’ en de visualisatie wordt getoond volgens de mapping die de gebruiker gekozen heeft. Ook bevat het menu een slider voor de schaal van de assen van de dataset. Deze stappen zijn te zien in Figuur 4.1, Figuur 4.2, Figuur 4.3 en Figuur 4.4.

Figuur 4.1: Nog geen kolommen toegevoegd, dus wordt op “choose columns"geklikt.

Figuur 4.3: De kolommen worden op de x, y, en z as geplaatst en er wordt op “draw data"geklikt.

Figuur 4.4: De visualisatie is nu zichtbaar.

4.1

Aanpassingen Oculus SDK

Het OVRPlayerController script is aangepast om ervoor te zorgen dat de gebruiker vrijuit door de visualisatie kan bewegen. De werking van zwaartekracht is weggehaald; dit is te zien in Listing 4.1. Ook is ervoor gezorgd dat de gebruiker omhoog en omlaag kan bewegen met de joystick van de rechter controller, zoals te zien in Listings 4.2, 4.3 en 4.4.

// G r a v i t y if ( C o n t r o l l e r . i s G r o u n d e d && F a l l S p e e d <= 0) F a l l S p e e d = (( P h y s i c s . g r a v i t y . y * ( G r a v i t y M o d i f i e r * 0. 002 f ) ) ) ; else F a l l S p e e d += (( P h y s i c s . g r a v i t y . y * ( G r a v i t y M o d i f i e r * 0. 002 f ) ) * S i m u l a t i o n R a t e * Time . d e l t a T i m e ) ; m o v e D i r e c t i o n . y += F a l l S p e e d * S i m u l a t i o n R a t e * Time . d e l t a T i m e ; Listing 4.1: Dit stuk code is verwijderd uit het script om de zwaartekracht uit te schakelen.

// No p o s i t i o n a l m o v e m e n t if we are in the air

if (! C o n t r o l l e r . i s G r o u n d e d ) M o v e S c a l e = 0.0 f ;

Listing 4.2: Dit stuk code is verwijderd om vrije beweging te realiseren.

bool m o v e F o r w a r d = I npu t . G e t K e y ( K e y C o d e . W ) || In put . G e t K e y ( K e y C o d e . U p A r r o w ) || O V R I n p u t . Get ( O V R I n p u t . B u t t o n . P r i m a r y T h u m b s t i c k U p ) ; bool m o v e L e f t = I npu t . G e t K e y ( K e y C o d e . A ) || In put . G e t K e y ( K e y C o d e . L e f t A r r o w ) || O V R I n p u t . Get ( O V R I n p u t . B u t t o n . P r i m a r y T h u m b s t i c k L e f t ) ; bool m o v e R i g h t = I npu t . G e t K e y ( K e y C o d e . D ) || In put . G e t K e y ( K e y C o d e . R i g h t A r r o w ) || O V R I n p u t . Get ( O V R I n p u t . B u t t o n . P r i m a r y T h u m b s t i c k R i g h t ) ; bool m o v e B a c k = I npu t . G e t K e y ( K e y C o d e . S ) || In put . G e t K e y ( K e y C o d e . D o w n A r r o w ) || O V R I n p u t . Get ( O V R I n p u t . B u t t o n . P r i m a r y T h u m b s t i c k D o w n ) ; bool m o v e U p = O V R I n p u t . Get ( O V R I n p u t . B u t t o n . S e c o n d a r y T h u m b s t i c k U p ) ; // t o e g e v o e g d voor v e r t i c a l e b e w e g i n g bool m o v e D o w n = O V R I n p u t . Get ( O V R I n p u t . B u t t o n . S e c o n d a r y T h u m b s t i c k D o w n ) ; // t o e g e v o e g d voor v e r t i c a l e b e w e g i n g

Listing 4.3: Toevoegingen voor verticale beweging van de gebruiker.

if ( m o v e F o r w a r d ) M o v e T h r o t t l e += ort * ( t r a n s f o r m . l o s s y S c a l e . z * m o v e I n f l u e n c e * V e c t o r 3 . f o r w a r d ) ; if ( m o v e B a c k ) M o v e T h r o t t l e += ort * ( t r a n s f o r m . l o s s y S c a l e . z * m o v e I n f l u e n c e * B a c k A n d S i d e D a m p e n * V e c t o r 3 . back ) ; if ( m o v e L e f t ) M o v e T h r o t t l e += ort * ( t r a n s f o r m . l o s s y S c a l e . x * m o v e I n f l u e n c e * B a c k A n d S i d e D a m p e n * V e c t o r 3 . left ) ; if ( m o v e R i g h t ) M o v e T h r o t t l e += ort * ( t r a n s f o r m . l o s s y S c a l e . x * m o v e I n f l u e n c e * B a c k A n d S i d e D a m p e n * V e c t o r 3 . ri ght ) ; if ( m o v e U p ) // t o e g e v o e g d voor v e r t i c a l e b e w e g i n g M o v e T h r o t t l e += ort * ( t r a n s f o r m . l o s s y S c a l e . y * m o v e I n f l u e n c e * B a c k A n d S i d e D a m p e n * V e c t o r 3 . up ) ; if ( m o v e D o w n ) // t o e g e v o e g d voor v e r t i c a l e b e w e g i n g M o v e T h r o t t l e += ort * ( t r a n s f o r m . l o s s y S c a l e . y *

4.2

Scripts en classes

Het CSVData.cs script leest de rijen uit een CSV-bestand en slaat het op in instanties van de klasse DataPoint (zie Listing 15). De verschillende kolommen met hun waardes staan in de dictionary. Verder heeft DataPoint een GameObject dat getekend gaat worden als het datapunt in de visualisatie. Tijdens het creëren van de instanties van DataPoint, wordt ook gekeken naar wat de hoogste en laagste waardes van elke kolom zijn. Deze informatie wordt tijdens het tekenen van een visualisatie gebruikt om de operaties op de datapunten in proportie te houden. Stel bijvoorbeeld dat een kolom met een waardebereik van tussen 0.1 en 10.000 op schaling in alle dimensies gemapt wordt. In dat geval is het niet de bedoeling dat het datapunt met waarde 0.1 verdwijnt, terwijl het datapunt met waarde 10.000 het grootste deel van het scherm in beslag neemt.

p u b l i c cla ss D a t a P o i n t

{

p u b l i c Dic tio nar y <string, string> v a l u e s ;

p u b l i c G a m e O b j e c t Cube ;

p u b l i c V e c t o r 3 S c a l i n g = new V e c t o r 3 (1.0 f , 1.0 f , 1.0 f ) ;

p u b l i c D a t a P o i n t ( G a m e O b j e c t D a t a s e t )

{

U n i t y E n g i n e . O b j e c t C u b e P r e f a b = R e s o u r c e s . Load (" D a t a P o i n t ") ; Cube = G a m e O b j e c t . I n s t a n t i a t e ( Cub ePr efa b , V e c t o r 3 . zero ,

Q u a t e r n i o n . i d e n t i t y ) as G a m e O b j e c t ; Cube . t r a n s f o r m . l o c a l S c a l e = new V e c t o r 3 (0.5 f , 0.5 f , 0.5 f ) ; Cube . t r a n s f o r m . p a r e n t = D a t a s e t . t r a n s f o r m ; Cube . S e t A c t i v e (f als e) ; } }

Listing 4.5: De klasse DataPoint.

In MenuScript.cs wordt het menu aangestuurd dat de gebruiker in staat stelt om kolommen uit het CSV-bestand te mappen op visuele variabelen. Het menu wordt hier geïnitialiseerd, het gedrag van alle knoppen is hier gedefinieerd en hier wordt opgeslagen welke kolommen op welke variabelen gemapt zijn. Deze worden doorgegeven aan CSVData.cs, die vervolgens de bijbehorende operaties (positionering, schaling, rotatie) toepast op de datapunten.

HOOFDSTUK 5

Experimenten

Bij het ontwikkelen van VR-applicaties is het van belang om de performance te meten. Als het aantal frames per seconde te laag is, valt de immersieve ervaring van VR weg. In dat geval is de applicatie waardeloos. Bij het maken van de applicatie is immers bewust gekozen voor de immersiviteit van VR. Zeker bij een VR-applicatie voor datavisulisatie is de immersiviteit belangrijk, omdat het het intuïtief begrip van de data versterkt.

In dit onderzoek is de performance ook van belang omdat er wordt bekeken of een dergelijk datavisualisatieprogramma kan draaien op de Oculus Quest, welke over minder hoogwaardige hardware beschikt dan tegenhangers als de HTC Vive en Oculus Rift.

5.1

Optimalisatie en experimenten

De applicatie maakt gebruik van de “cars” dataset van het CORGIS (Collection of Really Great, Interesting, Situated Datasets) dataset project [3]. Tijdens het ontwikkelen en testen van de applicatie is deze dataset beperkt tot de eerste 100 datapunten om het proces van ontwikkelen en testen te versnellen. Om de performance te testen met deze dataset is een script geschreven dat een visualisatie maakt waarbij de lengte, hoogte en breedte van de auto’s gemapt worden op respectievelijk de x-, y-, en z-as, en de camera op constante snelheid laat draaien.

Met de OVR Metrics Tool [15] van Oculus kan een aantal performance statistieken in de vorm van een grafiek of getal getoond worden tijdens het testen van de applicatie op de Oculus Quest. Ook kunnen deze waardes in een CSV-bestand worden vastgelegd. Voor de eerste blik op de performance is het aantal frames per seconde, het CPU-gebruik en het GPU-gebruik bekeken. Deze metingen zijn opgeslagen in een CSV-bestand en er zijn grafieken van geproduceerd. Zie hiervoor Figuur 5.1 en Figuur 5.2. In tabel 5.1 staan de beste, slechtste en gemiddelde waardes voor dit experiment. Hierbij moet worden opgemerkt dat de worst case van het aantal frames per seconde 1 is, alleen bij het opstarten van de applicatie. Als pas gekeken wordt vanaf het moment dat de visualisatie daadwerkelijk getoond wordt, is de worst case hier 36 fps. Hetzelfde geldt voor de best case van het GPU-gebruik. Deze is alleen 26% vóór de visualisatie getoond wordt. Vanaf de visualisatie is de best case 81%.

Worst Case Best Case Average Case

FPS 1 73 47.3

CPU-gebruik 85% 18% 35.4%

GPU-gebruik 93% 26% 83.6%

Tabel 5.1: Beste, slechtste, en gemiddelde waardes voor FPS, CPU-gebruik en GPU-gebruik bij een ronddraaiende camera in een visualisatie van 100 datapunten vóór optimalisatie.

Figuur 5.1: Het aantal frames per seconde over tijd met een ronddraaiende camera in een visu-alisatie met 100 datapunten vóór optimvisu-alisatie. Te zien is dat de grafiek een cyclus toont, die zich herhaalt wanneer de camera een omwenteling voltooid heeft.

Figuur 5.2: Het CPU- en GPU-gebruik over tijd met een ronddraaiende camera in een visualisatie met 100 datapunten vóór optimalisatie. Het CPU-gebruik heeft een piek bij het opstarten van de applicatie. Het GPU-gebruik blijft na het opstarten van de applicatie constant hoog.

Oculus heeft als richtlijn voor performance de volgende doelen: [14] • 72 FPS (verplicht om een applicatie in de Oculus Store te publiceren) • 150-175 draw calls per frame

te kijken waar eventuele bottlenecks liggen, is de Unity Profiler gebruikt. Dit is een tool die inbegrepen zit bij Unity, waarin de performance verder geanalyseerd kan worden. Zo is ook hier CPU- en GPU-gebruik te zien, alsmede gebruik van geheugen, geluid, netwerk, UI, en belichting. Deze statistieken worden per frame opgeslagen en ook is per frame te zien hoeveel tijd elke functie vraagt van de CPU en GPU. Daarnaast zijn statistieken over de rendering te zien als het aantal draw calls en het aantal driehoeken voor ieder frame. Met de Unity profiler is gekeken naar het experiment dat op de Quest draaide. In Figuur 5.3 en Figuur 5.4 zijn screenshots hiervan te zien. In Figuur 5.3 is te zien dat de CPU voor dit frame in totaal 27.79 ms bezig was met de PlayerLoop, waarvan het 60.8% van de tijd aan het wachten was op de GPU. In Figuur 5.4 is te zien dat de gpu 97 draw calls doet voor dit frame.

Figuur 5.3: De Unity Profiler met onder in de tijd die elke functie gebruik maakt van de CPU vóór optimalisatie. De CPU is het grootste deel van de tijd aan het wachten op de GPU.

Figuur 5.4: De Unity Profiler met onder in de tijd die elke functie gebruik maat van de GPU vóór optimalisatie. Wat opvalt is het hoge aantal draw calls.

Om de applicatie efficiënter te maken, is het dus een goed idee om het aantal draw calls te reduceren. Dit is gedaan door de meshes van alle datapunten te combineren tot één mesh. Op deze manier hoeft de GPU niet een draw call te doen voor elk datapunt, maar in plaats daarvan tekent het de hele dataset als één grote mesh. Unity heeft een script gepbuliceerd dat ervoor zorgt dat de meshes van alle kinderen van een object combineert tot één mesh [26]. In de implementatie zijn alle datapunten kind van het lege GameObject “Dataset”. Dit script kon dus worden gebruikt om de meshes van alle datapunten te combineren, met als enige aanpassing dat de mesh van “Dataset"steeds opnieuw wordt geïnitialiseerd wanneer deze functie wordt aangeroepen. Dit is gedaan omdat de gebruiker meerdere visualisaties na elkaar moet kunnen maken. Hierbij moeten de datapunten eerst weer los van elkaar bewogen kunnen worden, alvorens een nieuwe “dataset mesh"te genereren.

Na optimalisatie zijn er opnieuw metingen gedaan met hetzelfde script en 100 datapunten. De resultaten staan in Figuur 5.5, Figuur 5.6 en tabel 5.2. Ook hier geldt voor de worst case van het aantal frames per seconde dat deze plaatsvindt voor de visualisatie gestart is. Tijdens de visualisatie is de worst case 49 FPS. Voor de best case van het GPU-gebruik en CPU-gebruik geldt dat hier ook. Na het starten van de visualisatie is de best case voor het CPU-gebruik 36% en voor het GPU-gebruik 39%.

Worst Case Best Case Average Case

FPS 1 73 62.8

CPU-gebruik 100% 14% 57.1%

GPU-gebruik 86% 21% 57.1%

Tabel 5.2: Beste, slechtste, en gemiddelde waardes voor FPS, CPU-gebruik en GPU-gebruik bij een ronddraaiende camera in een visualisatie van 100 datapunten na optimalisatie.

Figuur 5.5: Het aantal frames per seconde over tijd met een ronddraaiende camera in een visu-alisatie met 100 datapunten na optimvisu-alisatie.

Dit keer is het gemiddeld aantal frames per seconde hoger met 62.8. Echter voldoet dit nog niet aan de doelstelling van 72 fps. Om te analyseren waar dit aan ligt is wederom de Unity Profiler gebruikt. Screenshots hiervan zijn te zien in Figuur 5.7 en in Figuur 5.8. Dit keer wordt de GPU een stuk korter gebruikt per frame. In het geval van dit specifieke frame is dat 3.831 ms. Ook is te zien dat het aantal draw calls nu gereduceerd is naar 18. De CPU wacht dit keer niet meer lang op de GPU, maar is het meeste van de tijd bezig met de functie PlayerConnection.Poll, welke zorgt voor de connectie tussen de Quest en de PC tijdens het meten van de performance. Er is ook gemeten met de OVR Metrics Tool zonder dat de Quest verbonden was met de PC, echter leverde dit geen betere prestatie op.

Figuur 5.7: De Unity Profiler met onder in de tijd die elke functie gebruik maakt van de CPU na optimalisatie. PlayerConnection.Poll neemt het meeste tijd in beslag.

Figuur 5.8: De Unity Profiler met onder in de tijd die elke functie gebruik maakt van de GPU na optimalisatie. Het aantal draw calls is significant gereduceerd.

Na het optimaliseren is dezelfde meting weer gedaan, maar dan voor de hele dataset van 5077 datapunten. De resultaten zijn te zien in Figuur 5.9, Figuur 5.10 en Tabel 5.3. De grafieken lijken nu weer meer op het geval van 100 datapunten voor de optimalisatie. In de Unity Profiler is ook te zien dat de CPU nu weer aan het wachten is op de GPU (zie Figuur 5.11 en Figuur 5.12 ). Bij het visualiseren van de gehele dataset is de bottleneck ook na optimalisatie dus het tekenen door de GPU.

Figuur 5.9: Het aantal frames per seconde over tijd met een ronddraaiende camera in een visua-lisatie met 5077 datapunten na optimavisua-lisatie. Het patroon ziet er weer uit als een cyclus, waarbij één cyclus gelijk staat aan één omwenteling van de camera.

Figuur 5.10: Het CPU- en GPU-gebruik over tijd met een ronddraaiende camera in een visuali-satie met 5077 datapunten na optimalivisuali-satie.

Worst Case Best Case Average Case

FPS 1 73 36.9

CPU-gebruik 94% 0% 15.8%

GPU-gebruik 99% 16% 92.6%

Tabel 5.3: Beste, slechtste, en gemiddelde waardes voor FPS, CPU-gebruik en GPU-gebruik bij een ronddraaiende camera in een visualisatie van 5077 datapunten na optimalisatie.

Figuur 5.11: De Unity Profiler met onder in de tijd die elke functie gebruik maakt van de CPU na optimalisatie en met de gehele dataset van 5077 datapunten. Te zien is dat de CPU nu weer het grootste gedeelte van de tijd op de GPU aan het wachten is.

Figuur 5.12: De Unity Profiler met onder in de tijd die elke functie gebruik maakt van de GPU na optimalisatie en met de gehele dataset van 5077 datapunten.

HOOFDSTUK 6

Discussie

6.1

Verder onderzoek

Het is binnen de tijdspanne van dit project niet gelukt om een aantal softwarepakketten te gebruiken die in hoofdstuk 3 genoemd zijn. Met name IATK lijkt interessant, omdat dit mooie interacties voor VR biedt en het ook werkt met Unity.

Ook zou het interessant zijn om nog eens te kijken naar het exporteren van de applicatie naar de webXR standaard. Zoals eerder genoemd zijn hier wel pogingen toe gedaan, maar is dit niet gelukt. Toch zou het mogelijk moeten zijn om dit met Unity te realiseren en dit zou direct het voordeel opleveren dat de applicatie met verschillende apparaten en besturingssystemen te gebruiken is.

6.2

Ethisch aspect: gedwongen Facebook account

In het tweede kwartaal van 2014 is Oculus overgenomen door Facebook voor een bedrag van €2.000.000.000. Daarnaast heeft Facebook in het afgelopen decennium ook Whatsapp en Inst-agram overgenomen. Deze overnames zorgen ervoor dat Facebook kan beschikken over een groot aantal persoonlijke gegevens van mensen over de hele wereld. Het is maar de vraag of Facebook hier verantwoordelijk mee omgaat. Zo kwam in 2018 aan het licht hoe Facebook data van haar gebruikers zonder hun toestemming aan Cambridge Analytica beschikbaar stelde. Gebruikers van de app van Cambridge Analytica werden verteld dat zij mee konden doen aan een enquête waar-bij de gegevens strikt gebruikt zouden worden voor academische doeleinden. Echter verleende Facebook aan Cambridge Analytica ook toegang tot de gegevens van de Facebookvrienden van deze gebruikers. Deze gegevens werden vervolgens gebruikt om politieke doeleinden te promoten [9].

Vanaf Oktober 2020 moet iedereen die voor het eerst een Oculus apparaat gebruikt inloggen met een Facebook account. Op 1 januari 2023 stopt de support voor Oculus accounts volledig. Gebruikers die geen Facebook account hebben of deze niet willen gebruiken op hun Oculus apparaat zullen geen toegang meer hebben tot alle functionaliteit [16]. Er zijn vraagtekens te plaatsen bij de intentie van dit beleid, zeker met in het achterhoofd hoe Facebook in het verleden om is gesprongen met de gegevens van haar gebruikers.

Doordat deze applicatie gemaakt is voor de Oculus Quest, zal ook deze applicatie uiteindelijk alleen beschikbaar zijn voor mensen die gebruik maken van de services van Facebook. Om dit te voorkomen, zou de app in de toekomst geïmplementeerd kunnen worden voor een ander platform dan Oculus. Hierbij is te denken aan WebXR, omdat de applicatie in Unity gemaakt is en Unity een exportfunctie voor deze standaard heeft.

Bibliografie

[1] Vis 2018: [tutorial] introduction to iatk: An immersive visual analytics toolkit. https: //vimeo.com/320646218, 2018.

[2] Syed Mohd Ali, Noopur Gupta, Gopal Krishna Nayak, and Rakesh Kumar Lenka. Big data visualization: Tools and challenges. In 2016 2nd International Conference on Contemporary Computing and Informatics (IC3I), pages 656–660. IEEE, 2016.

[3] Austin Cory Bart. Cars csv file. https://corgis-edu.github.io/corgis/csv/cars/, 2015. [4] Ahmed Bayyari and M Eduard Tudoreanu. The impact of immersive virtual reality displays on the understanding of data visualization. In Proceedings of the ACM symposium on Virtual reality software and technology, pages 368–371, 2006.

[5] Jacques Bertin. Semiology of graphics (wj berg, trans.). Madison, WI: The University of Wisconsin Press.(Original work published 1967), 1983.

[6] Jacques Bertin. Graphics and graphic information processing. Walter de Gruyter, 2011. [7] Rita Borgo, Johannes Kehrer, David HS Chung, Eamonn Maguire, Robert S Laramee,

Helwig Hauser, Matthew Ward, and Min Chen. Glyph-based visualization: Foundations, design guidelines, techniques and applications. In Eurographics (STARs), pages 39–63, 2013. [8] Bill Buxton and George W Fitzmaurice. Hmds, caves & chameleon: a human-centric analysis of interaction in virtual space. ACM SIGGRAPH Computer Graphics, 32(4):69–74, 1998.

[9] Carole Cadwalladr. The great british brexit robbery: how our

demo-cracy was hijacked. https://www.theguardian.com/technology/2017/may/07/ the-great-british-brexit-robbery-hijacked-democracy, 2017.

[10] CL Philip Chen and Chun-Yang Zhang. Data-intensive applications, challenges, techniques and technologies: A survey on big data. Information sciences, 275:314–347, 2014.

[11] Maxime Cordeil, Andrew Cunningham, Benjamin Bach, Christophe Hurter, Bruce H Tho-mas, Kim Marriott, and Tim Dwyer. Iatk: An immersive analytics toolkit. In 2019 IEEE Conference on Virtual Reality and 3D User Interfaces (VR), pages 200–209. IEEE, 2019. [12] Paul E Dickson, Jeremy E Block, Gina N Echevarria, and Kristina C Keenan. An

experience-based comparison of unity and unreal for a stand-alone 3d game development course. In Proceedings of the 2017 ACM Conference on Innovation and Technology in Computer Sci-ence Education, pages 70–75, 2017.

[13] Ciro Donalek, S George Djorgovski, Alex Cioc, Anwell Wang, Jerry Zhang, Elizabeth Law-ler, Stacy Yeh, Ashish Mahabal, Matthew Graham, Andrew Drake, et al. Immersive and collaborative data visualization using virtual reality platforms. In 2014 IEEE International Conference on Big Data (Big Data), pages 609–614. IEEE, 2014.

[14] LLC. Facebook Technologies. Testing and performance analysis | oculus developers. https: //developer.oculus.com/documentation/unity/unity-perf/.

[15] LLC. Facebook Technologies. Ovr metrics tool | developer center | oculus. https: //developer.oculus.com/downloads/package/ovr-metrics-tool/, 2020.

[16] LLC. Facebook Technologies. A single way to log into oculus

and unlock social features | oculus. https://www.oculus.com/blog/

a-single-way-to-log-into-oculus-and-unlock-social-features/, 2020.

[17] Alan M MacEachren. How maps work: Issues in representation, visualization and design. New York: Guilford Press. ception and Performance, 15(3):419–433, 1995.

[18] Alan M MacEachren, Robert E Roth, James O’Brien, Bonan Li, Derek Swingley, and Mark Gahegan. Visual semiotics & uncertainty visualization: An empirical study. IEEE Trans-actions on Visualization and Computer Graphics, 18(12):2496–2505, 2012.

[19] Jock Mackinlay. Automating the design of graphical presentations of relational information. Acm Transactions On Graphics (Tog), 5(2):110–141, 1986.

[20] Blair Maclntyre and Trevor F Smith. Thoughts on the future of webxr and the immersive web. In 2018 IEEE International Symposium on Mixed and Augmented Reality Adjunct (ISMAR-Adjunct), pages 338–342. IEEE, 2018.

[21] Philip J Mercurio, Thomas Erickson, D Diaper, D Gilmore, G Cockton, and B Shackel. Interactive scientific visualization: An assessment of a virtual reality system. In INTERACT, pages 741–745, 1990.

[22] Patrick O’Leary, Sankhesh Jhaveri, Aashish Chaudhary, William Sherman, Ken Martin, David Lonie, Eric Whiting, James Money, and Sandy McKenzie. Enhancements to vtk enabling scientific visualization in immersive environments. In 2017 IEEE Virtual Reality (VR), pages 186–194. IEEE, 2017.

[23] Charles Perin, Jean-Daniel Fekete, and Pierre Dragicevic. Jacques bertin’s legacy in infor-mation visualization and the reorderable matrix. Cartography and Geographic Inforinfor-mation Science, 46(2):176–181, 2019.

[24] Mozzila Reality. Github - mozillareality/unity-export: Assets for creating webxr-enabled unity3d projects. https://github.com/MozillaReality/unity-webxr-export, 2018.

[25] Robert E Roth. Visual variables. International Encyclopedia of Geography: People, the Earth, Environment and Technology: People, the Earth, Environment and Technology, pages 1–11, 2016.

[26] Unity Technologies. Unity - scripting api: Mesh.combinemeshses. https://docs.unity3d. com/ScriptReference/Mesh.CombineMeshes.html, 2020.