De oplettende lezer heeft gezien dat ik in mijn vorige blog een belofte heb gedaan, namelijk dat ik uit zou wijden over hoe we nou precies zo’n 3D-omgeving in een game engine stoppen. Spoiler: die belofte ga ik (nog) niet nakomen. Ik denk namelijk dat het leuker is om een aantal van onze huidige projecten in de spotlight te zetten. Ten eerste omdat mooie plaatjes het altijd beter doen dan lappen tekst, en ten tweede om nog eens extra te onderstrepen dat game engines wel degelijk toegevoegde waarde hebben in de wereld van GIS. Dus, without further ado: bij dezen enkele case studies.

>>> Ben je nu al de draad kwijt en heb je geen idee wat een game engine is? Zie dan het artikel GIS-data in game engines: introductie.

Op dit moment gebruiken we binnen Research voornamelijk de game engine Unity. In het verleden hebben we ook het één en ander geëxperimenteerd met Unreal en laten we daarnaast niet onze MineCraft-mod, EcoCraft, vergeten. Nu goed, er zijn honderden programma’s die je in de categorie game engine zou kunnen indelen, maar gelukkig hoeven we het daar nu niet over te hebben. Data is data; als één programma er chocola van kan maken, dan kan een ander programma dat ook. De vraag is alleen hoe het ontwikkelproces van die chocola precies in zijn werking gaat; is dat een multimachinaal proces gemaakt voor massaproductie, of een ambachtelijke, tijdrovende methode waar zeer veel liefde en handwerk aan te pas komt?

Mijn punt is dat de twee onderstaande voorbeelden vervaardigd zijn in Unity, maar dat ze net zo goed (met meer, of, maar hopelijk niet, minder moeite) in een andere engine gebouwd hadden kunnen worden.

3D in de ondergrond, in Augmented Reality

Data wordt steeds vloeibaarder. Als we vroeger op vakantie gingen, zochten we van tevoren op wat de toeristische trekpleisters in ons bestemmingsoord waren. Dat deden we vooraf, met reisgidsen of encyclopedieën. Toen kwam de computer en konden we van alles online opzoeken. Daarna konden we onze bestemming zelfs van tevoren nauwkeurig bekijken via Google Earth en later met Virtual Reality.
Tegenwoordig boeken we onze vakantie een dag van tevoren met onze smartphone en kijken we ter plekke op Google Maps welke restaurants of bezienswaardigheden er in de buurt zijn. Vanaf de muffe boeken is data over bezienswaardigheden, routes, et cetera, ‘doorgesijpeld’ naar het apparaatje dat je nu waarschijnlijk in je zak hebt.

Dezelfde trend zien we met 3D-visualisatie van data. We komen van fysieke maquettes en zijn op dit moment nog nét in het stadium van de viewers op de computer en in de webbrowsers. Met recente ontwikkelingen in technieken zoals Augmented Reality (AR), waarin je ‘virtuele toevoegingen’ aan de echte wereld kunt doen, komt het moment van de mobiele, real-time, centimeternauwkeurige 3D-viewer steeds dichterbij.

Research onderzoekt op dit moment de mogelijkheden voor een mobiele AR-applicatie om ondergrondse infrastructuur te visualiseren. Deze tool kan ontzettend behulpzaam zijn bij het graven van een proefsleuf. De bestuurder van een graafmachine kan live, in het veld, kijken waar bijvoorbeeld kabels en leidingen liggen, waar hij wel en niet moet graven aan de hand van een graafplan, of waar hij voorzichtig moet zijn omdat er mogelijk boomwortels in de grond zitten.

De informatie is er (in de vorm van KLIC-meldingen), en dus is het aan Unity om er chocola van te maken. Gelukkig is dit een klusje waar de engine wel raad mee weet.

De data specificeert waar kabels en leidingen precies liggen, alsmede de diameter en het type ervan. Unity maakt hier zonder problemen 3D-modellen van en kan die modellen aan de hand van GPS-positie en oriëntatie op ongeveer de goede plek leggen (relatief aan de locatie van de gebruiker). Daarna kan degene die de app gebruikt zelf nog het één en ander aan deze kalibratie tweaken, zodat de assets zeker weten op de juiste plek liggen.

Intussen wordt aan de hand van de camera-input en de gyroscoop van de telefoon berekend hoe de 3D-modellen georiënteerd zijn. Dit is een standaard functionaliteit voor AR, die het doet lijken alsof de virtuele objecten zich in de echte wereld bevinden. De modellen zijn als het ware ‘verankerd’ aan een punt in de echte wereld, en dienen zich altijd in dezelfde positie te bevinden ten opzichte van dat punt. Hiervoor gebruiken telefoons geavanceerde beeldverwerkingstechnieken die gebonden zijn aan het type telefoon en besturingssysteem. De software voor deze AR-functionaliteiten is gemaakt door Google (Android) en Apple (iOS) en is gebundeld in de libraries ARCore respectievelijk ARKit. Op zijn beurt bundelt Unity deze twee libraries, zodat de ontwikkelaar geen onderscheid meer hoeft te maken tussen de conventies van ARKit of ARCore. Unity zorgt er met zijn overkoepelende library ARFoundation voor dat het programma op zowel Android als iOS-telefoons werkt. We kunnen dan ook heel makkelijk een export maken voor Apple en voor Google, zonder daarvoor iets in de code van de applicatie te doen.

De kracht van Unity blijkt in dit project dus op twee manieren: ten eerste het dynamisch genereren van 3D-modellen aan de hand van data en ten tweede de beschikbaarheid van de standaard AR-libraries waarmee je zowat zonder een regel code met Augmented Reality aan de slag kan.

Crowd simulation & COVID

Zoals ik in mijn eerdere blogpost beschreef kunnen game engines erg goed gebruikt worden voor het maken van dynamische, interactieve omgevingen. In het kader van de Coronapandemie doet Research op dit moment onderzoek naar crowd simulation en COVID. Het idee is om een computerprogramma te maken waarin beleidsmakers verschillende scenario’s kunnen testen. Wat voor invloed heeft bijvoorbeeld het instellen dan een avondklok op de drukte in een stad? Of wat gebeurt er als een bepaalde straat afgezet of eenrichtingsverkeer wordt?

Om dit te realiseren is een hele dynamische omgeving nodig. Het is niet een kwestie van ‘een model draaien’ en dat vervolgens analyseren: met dit systeem kan real-time geïnteracteerd worden en bij het instellen van bepaalde regels dienen de agents (de gesimuleerde mensen) zich aan te passen. Tegelijkertijd dient er voor elk persoon in de simulatie bijgehouden te worden met hoeveel mensen ze in contact zijn geweest, waar ze heen gaan, en wat voor eigenschappen ze hebben. Met 5000 agents die zich tegelijkertijd door de simulatie bewegen, is dit een hele (optimalisatie)klus. We zijn hier mensen op haast individuele basis aan het modelleren en natuurlijk willen we het ook nog eens op een vloeiende 30 FPS kunnen bekijken!

Over de techniek hierachter zal ik later (misschien) uitweiden, want daar zou ik wel een boek over schrijven. Het mooie van dit project zit hem in de verschillende datalagen die we hier samenbrengen. Om de 3D-omgeving te genereren, gebruiken we de BGT (voor het toepassen van de juiste texture op de verschillende lagen, zoals fietspaden, gras, etc.) en het AHN (voor de hoogte van het terrein en de vormen van de gebouwen). Uit OSM (lantaarnpalen, bankjes, etc.) en het boomregister halen we het straatmeubilair en de bomen. Al deze datalagen voegen we samen om een digital twin van een bepaald gebied te maken.

>>> Zie ook het artikel van Corentin over hoe navigation meshes gegenereerd worden.

In deze 3D-omgeving worden de agents losgelaten. Het idee is dat die allemaal voortkomen uit een synthetische populatie - een soort geanonimiseerde replica van de ware bevolking. We maken dus niet alleen een digital twin van de omgeving, maar ook van de mensen die er wonen. Op basis van wat we weten over de bevolking geven we de agents een persona, die onder andere een leeftijd, een beroep en een ‘agenda’ bevat. Dat laatste bepaalt uiteindelijk naar welke points of interest (POIs) een agent gaat.

Uiteraard zijn deze POIs ook locatiegebonden en daarmee is het cirkeltje weer rond en zijn we weer aangekomen bij de zuivere GIS-data.

Ik hoop dat je het inmiddels niet zo gek meer vindt dat we hiervoor een game engine gebruiken. Zoals ik eerder zei zijn game engines heel goed in 3D-objecten tekenen en genereren. Unity biedt daarnaast ook een uitgebreid scala aan pathfinding-functies, waarmee we routes kunnen berekenen die ook nog eens flexibel zijn: dat wil zeggen dat een agent niet per se gebonden is aan zijn eerder berekende pad; hij kan autonoom terug navigeren als hij om wat voor reden dan ook om moet lopen. Door verschillende waarden aan verschillende (BGT-)gebieden toe te kennen, zorgen we ervoor dat agents eerder geneigd zijn om op de stoep te lopen, dan op de straat of over het gras.

De gebruiker kan heel veel parametriseren en op veel manieren interacteren met de simulatie; eigenlijk een beetje alsof het een computerspel is. En laat Unity nu net gemaakt zijn om computerspellen mee te bouwen.

Concluderend

Ik ben in deze blog ingegaan op een aantal concrete projecten waar Unity, of enig andere game engine, zich bij uitstek voor leent.

Het moge duidelijk zijn dat GIS-data in deze projecten centraal staat: zonder GIS-data hadden we geen idee waar kabels en leidingen lagen en zouden we ook niet weten waar agents in een crowd simulation-model wel en niet mogen lopen.

Ik heb geprobeerd om het ook andersom aan te tonen: dat Unity centraal kan staan in het visualiseren van en interacteren met GIS-data. Twee grote aspecten zijn daarin de toegankelijkheid van Augmented Reality en het creëren van interactieve crowd simulation-modellen.