Bachelor Informatica
VR-TrackerRecorder: real-time
monitoring en opslag van
Virtual Reality tracking data
voor offline analyse
Olaf van Houten
13 april 2021
Inf
orma
tica
—
Universiteit
v
an
Ams
terd
am
Samenvatting
Steeds meer VR-experimenten worden buiten de gecontroleerde omgeving van labora-toria uitgevoerd. Hierdoor zijn de experimenten toegankelijker voor meer proefpersonen, wat een grotere dataset oplevert. Veelal worden deze experimenten in publieke ruimtes als universiteiten en musea gedaan. Echter door COVID-19 is het lastiger deze experimenten op een verantwoorde manier uit te voeren. Bij deze experimenten wordt een grote hoeveelheid data gegenereerd die onder andere de rotatie en positie van het VR apparaat in de simulatie beschrijven. Momenteel zijn er weinig mogelijkheden om deze data op te slaan voor latere analyse.
Hiervoor is een systeem ontwikkeld, VR-TrackerRecorder, die het mogelijk maakt op afstand VR tracking data te vergaren door middel van een cross-platform client. De client stuurt zijn data real-time naar een REST-server die het in een MySQL-database verwerkt. Om de prestaties van VR-TrackerRecorder te meten is onderzocht hoeveel datapunten ver-stuurd en verwerkt kunnen worden in de database. Uit de resultaten blijkt dat het concept werkt, echter vooralsnog met beperkingen, met name de snelheid waarmee data opgeslagen kan worden. Daarom wordt meer onderzoek naar de prestaties van VR-TrackerRecorder aanbevolen, om beter inzicht te krijgen waar de overhead vandaan komt.
Inhoudsopgave
1 Introductie 4
1.1 Gerelateerd werk . . . 5
2 Ontwerp 6 2.1 Het opslaan van trackingdata . . . 7
2.2 Centrale dataopslag . . . 8
2.3 Geschikt voor meerdere VR apparaten . . . 8
2.4 Lage overhead . . . 8 2.5 Ontwerp . . . 9 3 Implementatie 11 3.1 Client-side integratie . . . 11 3.2 Server-side integratie . . . 12 4 Resultaten 14 5 Discussie 16
HOOFDSTUK 1
Introductie
Virtual Reality (VR) is een term die wordt gebruikt voor gesimuleerde omgevingen die de fysieke wereld nabootsen, of waarin juist een fantasiewereld word gecree¨erd [7, 1]. Er worden verschil-lende typen VR onderscheiden waaronder Augmented Reality (AR) en Mixed Reality/Extended Reality (MR/XR). VR is een snel groeiende markt en biedt naast entertainment mogelijk een oplossing waar alternatieve oplossingen te duur, te gevaarlijk of te moeilijk zijn. Voorbeelden hiervan zijn een nog niet bestaand huis bezichtigen, een openhartoperatie nabootsen of het ver-beteren van sportprestaties [13].
De structuur van een VR-opstelling bestaat uit een Head Mounted Display (HMD, de VR-bril) en eventueel twee controllers, zie figuur 1.1. Zowel de HMD als de controllers beschikken over sensoren die rotatie en positie kunnen meten. Deze kan de computer vervolgens gebruiken om een realistische omgeving te simuleren. Een aantal voorwaarden zijn een lage responsetijd (100 ms of lager) in de simulatie en hoge refreshrate (60 Hz of hoger) van de HMD, waar veel rekenkracht voor nodig is. Een gevolg kan zijn dat gebruikers van de VR-applicatie kinetose ervaren, ofwel bewegingsziekte, waarbij de hersenen tegenstrijdige informatie ontvangen waardoor men misselijk kan worden [15]. Daarom is het belangrijk dat een dergelijk data tracking systeem zo min mogelijk overhead veroorzaakt, zodat de integriteit van de simulatie behouden blijft. Met overhead wordt overmatig gebruik van middelen binnen het computersysteem bedoeld, zoals rekentijd.
Belangrijk voor veel toepassingen is het kunnen opslaan en ophalen van tracking data vergaard binnen de VR applicatie. Met tracking data wordt verwezen naar de parameters die binnen de VR-omgeving gebruikt worden om de posities en bewegingen van het hoofd en eventuele controllers te registreren. Met deze data kan menselijk gedrag bestudeerd worden na het gebruik van een VR-applicatie [10, 3]. Deze informatie is nuttig voor wetenschappelijk onderzoek naar menselijk gedrag, voor het meten van sportprestaties, voor het analyseren van vorderingen in revalidatie en het meten van prestaties in trainingssimulaties [13, 16]. Normaal gesproken wordt deze data tijdens gebruik van de applicatie verwijderd, waardoor er geen uitgebreide analyses kunnen plaatsvinden. Bovendien maakt centrale opslag van data het mogelijk om op afstand data te vergaren in de anderhalvemetersamenleving. Om deze redenen is het cruciaal om een systeem te ontwikkelen waarbij tracking data opgeslagen kan worden [5, 4].
Dit onderzoek beschrijft VR-TrackerRecorder, een data tracking systeem, dat in staat is de handelingen van gebruikers van VR-applicaties op te slaan voor latere analyse en presentatie. Binnen dit project wordt onderzocht hoe een dataopslag systeem gebouwd kan worden voor VR-applicaties met minimale impact op de prestaties van de simulatie. Om dit te beantwoorden zal eerst onderzocht worden welke software het meest geschikt is om de VR-applicatie in te maken. Daarnaast moet er een afweging gemaakt worden welk opslagmedium gebruikt wordt. Tenslotte zal aan de hand van een experiment de prestaties van het opslagsysteem gemeten worden.
1.1
Gerelateerd werk
In de afgelopen jaren worden steeds meer onderzoeken gedaan met behulp van VR. Dit wordt veelal binnen gecontroleerde omgevingen gedaan als laboratoria, onderzoeken op afstand zijn nog schaars. De studie van Ratcliffe et al. laat zien dat VR-experimenten op afstand een nuttige onderzoeksmethode is, echter met beperkingen betreffende data vergaring en opslag [5]. In de huidige tijd van de COVID-19 pandemie zijn veel locaties als universiteiten en laboratoria tijdelijk gesloten of slechts beperkt open, waardoor het moeilijker is onder gecontroleerde omstandigheden experimenten uit te kunnen voeren. Dit probleem is tevens geconstateerd door Steed, Ortega et al. die in een artikel aandacht vragen voor ethische en praktische dilemma’s rondom VR onderzoek tijdens de pandemie [4]. In een van de genoemde oplossingen wordt verwezen naar eerder onderzoek van Steed, Friston et al., waaruit blijkt dat het vergaren van VR tracking data buiten gecontroleerde omgeving haalbaar is [14].
Verder is het belangrijk te realiseren dat tracking data het mogelijk maakt gebruikers indirect te identificeren. Uit onderzoek van Miller et al. blijkt dat VR tracking data informatie produceert waarmee een gebruiker met 95% zekerheid kan worden ge¨ıdentificeerd [3]. Echter geen aandacht is besteed aan privacy en veiligheid voor onderzoekers of proefpersonen, omdat geen gebruikt is gemaakt van persoonsgegevens.
HOOFDSTUK 2
Ontwerp
Voorafgaand aan het ontwerp zijn een aantal eisen opgesteld waar het data tracking systeem aan moet voldoen.
1. Het opslaan van trackingdata; de data zal gestructureerd moeten worden opgeslagen zodat onderscheid gemaakt kan worden tussen bijvoorbeeld verschillende gebruikers, trainings-sessies, experimenten, locaties en verschillende configuraties van VR hardware.
2. Centrale dataopslag; om wetenschappelijk onderzoek over gedistribueerde locaties mogelijk te maken is het wenselijk om de data, die wordt geproduceerd, centraal op te slaan. 3. Geschikt voor meerdere VR apparaten; van verschillende merken en voor applicaties die
zijn ontwikkeld in verschillende software development environments.
4. Lage overhead; het is van belang dat het ontwerp effici¨ent is in het gebruik van resources, zodat het systeem niet interfereert met de prestaties van de simulatie.
2.1
Het opslaan van trackingdata
De data die gegenereerd wordt binnen een VR-applicatie gaat momenteel verloren na gebruik. Hierdoor is het niet mogelijk om deze data achteraf te analyseren. Een belangrijke eis is dus dat de tracking data opgeslagen kan worden, zodat de resultaten op een later moment geanaly-seerd kunnen worden. Dit maakt het mogelijk onderzoek te doen naar het gedrag van mensen binnen een VR-stimulus. Een voorbeeld hiervan is de vorderingen van een revaliderend pati¨ent inzichtelijk te maken [12, 16].
Uit een sessie met een VR simulatie kunnen verschillende typen tracking data onderscheiden worden:
• Float-waarden die de rotatie en eventueel positie beschrijven. Wanneer alleen de rotatie gemeten wordt door een apparaat is er sprake van drie degrees of freedom (DOF). Dit betekent dat er drie float-waarden nodig zijn om de rotatie van een apparaat weer te geven. Bij meting van zowel rotatie als positie zijn per apparaat zes DOF, en dus zes floats.
• Float-waarden om knoppen van de controllers te beschrijven die een waarde tussen 0 en 1 meten. Hier betekent een waarde van 1 dat de knop geheel is ingedrukt.
• Boolean-waarden voor de overige controller knoppen, dit zijn variabelen die alleen de waarde true of false hebben.
Figuur 2.1: VR Controller met een aantal datatypen die gegenereerd worden.[11] Deze waarden worden minimaal 60 keer per seconde gemeten, dit kan meer zijn afhankelijk van het type VR-apparaat. Mede door de snelheid van de metingen wordt een grote hoeveelheid data gegenereerd. Om spaarzaam om te gaan met opslagruimte worden deze datatypes niet gecombineerd tot ´e´en tabel. Deze typen data zijn onafhankelijk van elkaar en worden dus in een eigen tabel opgeslagen. Het is van belang NULL waarden door de hele database hetzelfde te interpreteren, volgens Codd’s derde regel: Systematic Treatment of NULL Values [2]. Een nieuwer inzicht voortgekomen uit deze regel, is NULL waarden in een database zo veel mogelijk te vermijden. Hieruit volgt dat het niet gewenst is 3DOF data in dezelfde tabel als 6DOF data op te slaan. Om de verschillende tracking sessies van elkaar te onderscheiden zal metadata van de sessie ook opgeslagen worden in de database. Dit wordt in een eigen tabel weergegeven, die door middel van ID’s onderling van elkaar onderscheiden kunnen worden.
2.2
Centrale dataopslag
De vergaarde data kan bruikbaar zijn voor, en gegenereerd worden vanaf, meerdere partijen en daarom is het wenselijk deze op een centrale locatie op te slaan. Door een internet connectie tussen de VR-bril en de server op te zetten, wordt het mogelijk dat data van verschillende locaties verzameld worden bij de server. De server zet dit vervolgens met de juiste structuur in de database. Een voordeel hiervan is dat bij een crash tijdens de simulatie weinig data verloren gaat. Daarnaast heeft niet elk VR-apparaat voldoende opslagruimte om de hoeveelheid gegenereerde data te kunnen bewaren.
Centrale dataopslag is des te relevanter nu veel mensen vanuit huis werken tijdens de COVID-19 pandemie. In het voorbeeld van de revaliderende pati¨ent zouden zowel de therapeut als de pati¨ent toegang kunnen krijgen tot de gegevens in de database. Een zwaarwegende eis die hier nauw mee samenhangt is privacy en veiligheid. Het is wenselijk dat privacy gevoelige informatie niet voor iedereen toegankelijk is. Een incident zoals het data lek bij de GGD afgelopen jaar waarbij de persoonsgegevens van duizenden mensen te koop werden aangeboden moet te allen tijde voorkomen worden [8]. Hoewel beveiliging een cruciale eis is voor het eindproduct, is het niet de focus van dit onderzoek.
2.3
Geschikt voor meerdere VR apparaten
Omdat niet iedereen toegang heeft tot hetzelfde type VR-bril is het essentieel dat het systeem zo veel mogelijk apparaten ondersteunt. Hoewel de standaarden voor VR nog niet vast staan, is het wel mogelijk door middel van game engines meerdere VR devices te ondersteunen. Deze ondersteuning zit over het algemeen niet in de standaard installatie van een game engine, maar is een losse component die vaak via een manager te installeren is. Voorbeelden van zulke com-ponenten zijn OpenXR, XR Interaction Toolkit en Oculus Integration [17, 9, 6]. Deze laatste is specifiek gericht op Oculus apparaten, waar XR Interaction Toolkit en OpenXR bedoeld zijn om de verschillende brillen samen te krijgen onder ´e´en framework. XR Interaction Toolkit is gelimiteerd aan Unity in tegenstelling tot OpenXR die gericht is op het samenbrengen van VR-apparaten ongeacht welk platform gebruikt wordt. Hoewel OpenXR een initiatief is voor een nieuwe standaard voor VR/AR software development, is deze relatief nieuw en nog niet volledig ondersteund.
2.4
Lage overhead
Een VR-applicatie vergt een relatief hoge performance om een overtuigende simulatie voort te brengen. Zodra de prestaties van de simulatie ondermaats zijn, is het mogelijk dat gebruikers van de simulatie kinetose kunnen ervaren. Dit is nadelig voor de ervaring van de gebruiker en de consistentie van de resultaten. Om te proberen de overhead van VR-TrackerRecorder te reduceren, zal deze een connectie met de database server opzetten, waarover alle data verstuurd kan worden naar de server. Het verwerken van de data vindt dan plaats op de server en niet op de headset. Of de overhead daadwerkelijk wordt gereduceerd zal door middel van een ander onderzoek moeten blijken.
2.5
Ontwerp
Ten eerste is onderzocht welke software beschikbaar is om VR applicaties in te bouwen. Een eerste optie is de VR-applicatie geheel zelf te coderen. Een gevolg hiervan is dat een dergelijke VR-app voor een specifiek doel kan worden ontwikkeld. Hierdoor is het mogelijk meer boilerplate code te vermijden, waardoor de prestatie naar verwachting verbeterd kan worden. Het nadeel wat hier tegenover staat is dat waarschijnlijk voor elke VR-device apart code geschreven zal moeten worden. Uiteraard kost dit meer tijd en werk die niet in andere aspecten van het onderzoek gestoken kan worden.
Daarom is voor dit onderzoek een afweging gemaakt tussen twee game engines te weten Unity3D1 en Unreal Engine2, om een generiek systeem te bouwen die geschikt is voor verschil-lende VR-apparaten. Beiden zijn cross-platform, bezitten een framework voor het cree¨eren van VR-software voor verschillende VR-devices en zijn gratis in gebruik zolang geen geld gevraagd wordt voor de producten. Unity werkt langer aan VR-functionaliteit en heeft een lagere instap drempel dan Unreal Engine. Verder zijn er meer zelfstudiebronnen beschikbaar voor Unity dan voor Unreal, mede omdat Unity meer gebruikers telt. Een ander verschil is de programmeertaal die gebruikt wordt, bij Unity is dit C#, bij Unreal wordt van C++ gebruik gemaakt. C# wordt gezien als een taal die makkelijker te leren is. Echter als men helemaal niet wil coderen biedt Unreal’s blueprints een goede oplossing. Hier kan men door middel van visueel scripten nage-noeg hetzelfde bereiken als met gebruikelijk programmeren, en eventueel kunnen beide methodes gecombineerd worden.
Uit de vooraf genoemde eisen en ontwerp overwegingen is het volgende concept ontstaan, weergegeven in figuur 2.2. In dit figuur is weergegeven hoe meerdere VR-apparaten tracking data naar de server communiceren, waarna het vervolgens in de database verwerkt kan worden. Door middel van sensoren in het VR-apparaat wordt data gegenereerd. Normaliter wordt deze data gebruikt door een softwarelaag om de huidige staat van de stimulus te berekenen, en wordt vervolgens verwijderd. In dit concept wordt deze data opgevangen en direct verzonden door de VR-TrackerRecorder, die in verbinding is met een server. Deze server bewaart het op gestructu-reerde wijze in een database. Vanuit de database zijn de gegevens beschikbaar voor analyse of eventuele verdere bewerking.
Figuur 2.2: Schematische weergave verbinding meerdere VR-clients met de VR TrackerRecorder server.
In figuur 2.3 is weergegeven hoe de tabel structuur van de database is opgebouwd. Hierin is een tabel genaamd sessions beschreven die het mogelijk maakt de verschillende sessies te onderscheiden. Elke rij in de tabel beschrijft een andere sessie of experiment, en heeft een unieke ID om duplicatie te voorkomen, Session ID (SID). De tabellen Tracking Data, Real Controller Data en Binary Controller Data worden gebruikt om de verschillende type data in op te slaan die door het VR-apparaat zijn gegenereerd. Het SID wordt vervolgens gebruikt om binnen deze tabellen onderscheid te maken tussen de verschillende sessies. Om de HMD en de controllers te differenti¨eren is van hetzelfde principe gebruik gemaakt door middel van een hardware tabel met unieke Controller ID’s, ofwel CID. In het huidige concept wordt alleen gebruik gemaakt van de HMD en twee controllers, echter is het met deze structuur mogelijk met minimale ingreep uit te breiden naar meerdere controllers.
HOOFDSTUK 3
Implementatie
De implementatie valt onder te verdelen in twee componenten; een client-side en een server-side.
3.1
Client-side integratie
Figuur 3.1: Hierarchy en Inspector binnen de Unity Editor.
Voor de implementatie van de client-side applicatie is gekozen voor de Unity 3D game en-gine, omdat Unity’s VR framework verder ontwikkeld is dan Unreal’s. Unity biedt geen directe mogelijkheid om VR-functionaliteit te integreren in de applicaties, maar dit is wel mogelijk door middel van packages. Hiervan worden door Unity twee packages ondersteund, Oculus Integration en XR Interaction Toolkit, en dienen als laag tussen de hardware van verschillende VR apparaten en Unity zelf en zijn te installeren met behulp van de Unity Package Manager. Omdat Oculus Integration alleen Oculus-brillen ondersteunt, is gekozen voor XR Interaction Toolkit. Dit heeft als voordeel dat meer verschillende VR-devices compatibel zijn met de VR-TrackerRecorder. De XR Interaction Toolkit cre¨eert een gameobject genaamd XR Rig, wat een VR apparaat beschrijft binnen de simulatie. De XR Rig valt onder te verdelen in drie gameobjecten; ´e´en HMD (Main Camera) en twee controllers (LeftHand/RightHand Controllers) (figuur 3.1.a). In elk van de drie gameobjects is per onderdeel de rotatie en positie beschreven per momentopname in het Transform-component (figuur 3.1.b). Deze data is op te vragen door de gameobjects uit te brei-den met een script (VR-TrackerRecorder) die het Transform-component uitleest. Een andere taak die het script moet volbrengen is het verzenden van de tracking data naar de server. Dit wordt gedaan door middel van een webrequest, een Unity object om te communiceren met
web-Bij aanvang van een sessie wordt in het script eerst Start() aangeroepen. Deze functie wordt ´
e´enmalig uitgevoerd en zoekt welke hardware specificaties bij het script van toepassing zijn. Deze informatie wordt vervolgens gebruikt om in de database op te zoeken welk Controller ID bij het VR apparaat hoort. Als het om de HMD gaat, dan wordt tevens een nieuwe sessie gemaakt in de database, en wordt het Session ID direct opgevraagd. Dit is een static parameter, in tegenstelling tot Controller ID, want deze is voor alle onderdelen van de XRRig hetzelfde. Tijdens de sessie wordt elke frame de Update()-functie uitgevoerd. In Update() wordt de tracking data van het huidige frame verzonden naar de server. Voor het versturen van tracking data wordt onderscheid gemaakt tussen de controllers en de HMD, want controllers genereren naast 6DOF/3DOF data tevens data van de knoppen. Daarbij is het belangrijk dat asynchronische oproepen gebruikt worden, zodat niet op een antwoord van de server gewacht hoeft worden. Anders kan het voorkomen dat de server niet in hetzelfde frame een antwoord stuurt, en dat frames overgeslagen worden door het wachten op reactie van de server.
3.2
Server-side integratie
De proof-of-concept server hoeft nog niet te voldoen aan zware performance- en beveiligings-eisen. Om deze reden is gekozen voor EasyPHP DevServer 17.0, die het mogelijk maakt door middel van een setup bestand een localhost server te installeren. EasyPHP heeft een module voor MySQL die makkelijk te installeren is, waardoor het bij installatie voorzien is van een database. De koppeling tussen de server en de database is tot stand gebracht door een script geschreven in PHP. Het script ontvangt GET-requests met tracking data en vertaalt dit naar SQL-queries om het in de database te verwerken.
Eerder is beschreven hoe een nieuwe sessie ontstaat bij het starten van de client. In figuur 3.2 is schematisch weergegeven hoe de communicatie tussen de server en client verloopt na het star-ten van de client-applicatie. De client is onderverdeeld in drie hardware onderdelen, omdat elk onderdeel een eigen VR-TrackerRecorder-component heeft en daarom drie verschillende connec-ties met de server maakt. De HMD stuurt de gegevens van de sessie naar de server, deze maakt vervolgens een nieuwe rij in de database. Naast de data die in de rij gevoegd wordt, genereert de database ook een unieke waarde voor het Session ID. De client heeft het Session ID nodig voor het verzenden van tracking data. Met een SQL-query worden alle Session ID’s opgevraagd die dezelfde naam hebben als zojuist in de database is toegevoegd. Namen van sessies hoeven niet uniek te zijn, dus is het mogelijk dat de query resulteert in meerdere Session ID’s. Om deze reden sorteert de query de resultaten op aflopende volgorde, zodat altijd de nieuwste waarde naar de client gestuurd wordt. Als de HMD het Session ID heeft ontvangen, maakt deze dat kenbaar aan de controllers.
Ieder hardware onderdeel van de client vraagt zijn eigen Controller ID op en wordt apart geregistreerd. Daarbij wordt nader onderscheid gemaakt tussen de verschillende type/merken VR apparatuur. Bij het opvragen van een Controller ID wordt eerst gecontroleerd of deze al bestaat. Indien dat niet het geval is, dan gaat het om een nieuw apparaat en wordt deze toegevoegd in de database.
Na ontvangst van het Session ID en de Controller ID’s kan de tracking data verstuurd worden. Dit gebeurt elke frame vanuit de sendData()-functie zolang de sessie actief is. De tracking data is in drie categorie¨en onderverdeeld zoals beschreven in sectie 2.1. Voor elke categorie is een apart script geschreven om de tracking data in de database te verwerken.
HOOFDSTUK 4
Resultaten
Het doel van het experiment is te onderzoeken hoeveel invoegingen in de database mogelijk zijn per seconde. Voor het experiment is het niet van belang wat voor bewegingen de data beschrijft, alleen dat gemeten wordt hoeveel data per seconde in de database opgeslagen kan worden. Ten behoeve van het experiment is een Oculus Quest ter beschikking gesteld, alle metingen zijn hiervan afkomstig. Voor elke frequentie is een interval van 10 seconden gekozen, beginnend bij 2 Hz en toenemend met 1 Hz na elke 10 seconden. De proefneming is voltooid na de meting van 72 Hz, de refreshrate van de Oculus Quest. Er zijn vijf iteraties van het experiment uitgevoerd, om afwijkingen in resultaten zichtbaar te maken.
De resultaten van deze vijf iteraties zijn verwerkt in figuur 4.1 en 4.2, met de blauwe lijn wordt het gemiddelde resultaat van de vijf metingen weergegeven. De variantie van de data wordt aangegeven door middel van rode foutbalken en de stippellijn stelt de ideale hoeveelheid invoegingen voor, ofwel x invoegingen bij x Hz.
Figuur 4.2: Percentage geslaagde database invoegingen per frequentie. Uit de grafieken zijn een paar bijzondere meetpunten af te lezen:
• Tot 25 Hz is het aantal invoegingen nagenoeg parallel aan de ideale lijn. Na 25 Hz neemt het aantal invoegingen procentueel aanzienlijk af.
• Bij 36 Hz vindt de grootste toename van invoegingen plaats van de gemeten frequenties. Opvallend is dat 36 Hz de helft is van de maximale gemeten frequentie van 72 Hz en dat hierna het aantal invoegingen stabiliseert op ongeveer 31 invoegingen per seconden. • Op 60 Hz is duidelijk een piek in de grafiek te zien. Opmerkelijk is dat direct na de piek
HOOFDSTUK 5
Discussie
In dit project is onderzocht hoe een dataopslag systeem gebouwd kan worden voor VR-applicaties met minimale impact op de prestaties van de simulatie. Om de prestaties van VR-TrackerRecorder te meten is een experiment opgezet dat meet hoeveel invoegingen per seconde in de database verwerkt kunnen worden. De verwachting was dat VR-TrackerRecorder datapunten kan in-voegen op dezelfde frequentie als de Oculus Quest, namelijk 72 Hz. In de praktijk blijkt de VR-TrackerRecorder te werken, echter met ongeveer de helft minder invoegingen dan verwacht. Om dit probleem verder in kaart te brengen zijn meer experimenten nodig, bij voorkeur met meer verschillende VR-apparaten om limitaties van de Oculus Quest uit te sluiten. Andere apparaten werken bovendien met een hogere refresh rate, dat kan als gevolg hebben dat er meerdere datapunten opgeslagen kunnen worden. Echter is een averechts effect niet uit te sluiten, waar procentueel minder data wordt opgeslagen bij een hogere frequentie.
Een ander mogelijk knelpunt is dat bij iedere invoeging in de database opnieuw connectie gemaakt moet worden met de database. Wellicht is het mogelijk tijd te winnen door de connectie ´
e´en keer op te zetten en te hergebruiken.
In toekomstig onderzoek is tevens aan te bevelen te experimenteren met het versturen van meerdere datapunten per invoeging. Dit zou een prestatiewinst kunnen opleveren, omdat dan minder verzendingen naar de server nodig zijn, zonder datapunten te verliezen.
De float-waarden van de tracking data worden naar een string geconverteerd en naar de server gestuurd. Deze converteert vervolgens de string terug naar float-waarden bij het invoegen in de database. Wanneer data als floats behouden kan blijven bij het versturen, kan de conversie tweemaal achterwege blijven. Omdat conversie plaatsvindt op zowel de server als de VR-Headset, wordt mogelijk aan beide kanten de overhead gereduceerd.
Hoewel dit onderzoek heeft aangetoond dat de VR-TrackerRecorder een nuttig instrument is om data van VR-simulaties op te slaan, zal aanvullend onderzoek gedaan moeten worden om het systeem te optimaliseren.
Bibliografie
[1] J.N. Bailenson. Experience on Demand: What Virtual Reality Is, How It Works, and What It Can Do. New York, NY: W.W. Norton & Company, 2018.
[2] E.F. Codd. The Relationsal Model for Database Management, Version 2. Addison-Wesley, 1990.
[3] M.R. Miller en F. Herrera en H. Jun et al.
”Personal identifiability of user tracking data during observation of 360-degree VR video”. In: Nature (2020). doi: 10.1038/s41598-020-74486-y. url: https://doi.org/10.1038/s41598-10.1038/s41598-020-74486-y.
[4] A. Steed en F. Ortega en A. Williams et al.
”Evaluating Immersive Experiences during COVID-19 and beyond”. In: ACM interactions (mei 2020). url: https://interactions. acm.org/blog/view/evaluating- immersive- experiences- during- covid- 19- and-beyond.
[5] J. Ratcliffe en F. Soave en N. Bryan-Kinns et al.
”Extended Reality (XR) Remote Research: a Survey of Drawbacks and Opportunities”. In: arXiv (jan 2021). doi: 10.1145/3411764. 3445170.
[6] Khronos Group. OpenXR. Versie 1.0. 2021. url: https://www.khronos.org/openxr/. [7] P. Milgram en H. Takemura en A. Utsumi en F. Kishino.
”Augmented reality: A class of displays on the reality-virtuality continuum”. In: Telemanipulator and Telepresence Tech-nologies 2351 (jan 1994). doi: 10.1117/12.197321.
[8] M. van de Klundert en J. Schellevis.
”Lek in GGD-systeem al driekwart jaar aanwezig”. In: NOS (jan 2021). url: https://nos.nl/artikel/2366341-lek-in-ggd-systeem-al-driekwart-jaar-aanwezig.html.
[9] Facebook Technologies LLC. Oculus for Developers. Versie build 27.0. 2021. url: https: //developer.oculus.com/documentation/.
[10] J. Brookes en M. Warburton en M. Alghadier et al.
”Studying human behavior with virtual reality: The Unity Experiment Framework”. In: Behavior Research Methods (apr 2019). doi: 10.3758/s13428- 01242- 0. url: https://doi.org/10.3758/s13428- 019-01242-0.
[11] Oculus. Oculus Controller Art. https://developer.oculus.com/downloads/package/ oculus-controller-art/. 2020.
[12] B. F. Pacileo.
”Quantifying user physical activity in a virtual environment: the case of SyncVR Medical”. Masterscriptie. Amsterdam, NL: University of Amsterdam, aug 2020. [13] B. Bideau en R. Kulpa en N. Vignais et al.
”Using Virtual Reality to Analyze Sports Performance”. In: IEEE Computer Graphics and Applications 30.2 (2010), p. 14–21. doi: 10.1109/MCG.2009.134.
[14] A. Steed en S. Friston en M. Murcia L´opez et al.
”An ’In the Wild’ Experiment on Presence and Embodiment using Consumer Virtual Reality Equipment”. In: IEEE transactions on visualization and computer graphics (2016). doi: 10.1109/TVCG.2016.2518135.
[16] H. Sveistrup.
”Motor rehabilitation using virtual reality”. In: Journal of NeuroEngineering and Rehabilitation (2004). doi: 10.1186/1743-0003-1-10. url: https://doi.org/10. 1186/1743-0003-1-10.
[17] Unity Technologies. Unity. Versie 2020.1. 2021. url: https://www.unity.com/.
[18] HTC VIVE. VIVE Pro HMD: Setting up a room-scale play Area. https://www.vive. com / eu / support / vive pro hmd / category _ howto / setting up room scale play -area.html. 2021.
