De tweede render stage bestaat wederom uit een vertex en fragment shader. Als input wordt de floating-point texture gebruikt die de output van de eerste render stage was. Daarnaast krijgen
de shaders een vaste set aan geometrie als invoer. Deze geometrie wordt ´e´en keer aangemaakt en opgeslagen in een Vertex Buffer Object (VBO).
(a) (b) (c) (d)
Figuur 6.4: (a) Het geometrie grid opgebouwd uit rechthoeken (wit), geplaatst voor de camera (frustum met groene lijnen). (b) Raycasting lijnen (rood) door de hoekpunten van de rechthoeken, op zoek naar snijding met het z = 0 vlak. (c) Het grid wordt geplaatst op de snijpunten met het vlak gevonden door de raycasting. (d) Detail view van grid nadat het geplaatst is door de raycasting stap. Het is te zien dat niet elk hoekpunt een raycasting lijn heeft, wat enkel voor dit plaatje zo is (de lijnen zouden anders te veel informatie verbergen). In werkelijkheid wordt een raycasting berekening voor elk hoekpunt gedaan.
De geometrie bestaat uit een grid aan rechthoeken (OpenGL quads om precies te zijn). De hoek- punten van de rechthoeken hebben hetzelfde aantal in de breedte en de hoogte als het aantal pixels van de output van de eerste render stage. Dit grid wordt met behulp van een ingegeven matrix geplaatst voor de camera. Voor elke vertex wordt daarna in de vertex shader een ver- gelijking opgesteld van de lijn tussen de camera en de vertex. Met behulp van een raycasting algoritme wordt gevonden waar deze lijn het z = 0 vlak snijdt. Met de uitkomst van het ray- casten in de vertex shader kan het grid aan rechthoeken geplaatst worden op de positie van het terrein dat op dit moment in beeld is. Dit proces is in figuur 6.4 te zien.
(a) (b) (c)
Figuur 6.5: Nadat met raycasting de geometrie grid op de juiste plek is gezet (a) wordt de hoogtedata uit de eerste render stage genomen (b) en over de geplaatste geometrie gelegd (c).
Nadat de geometrie is geplaatst in de ruimte wordt de hoogte-informatie uit de eerste shaderstage over het grid gelegd (zie figuur 6.5). Dit gebeurd in de vertex shader. De laatste stap die in de vertex shader gebeurd is dat de hoogte component van de grid hoekpunten wordt aangepast. Omdat het grid geplaatst is door te raycasten met het z = 0 vlak, hebben alle hoekpunten een waarde van 0 voor de z component. Door de hoogte-informatie uit de eerste shaderstage te samplen kan dit worden aangepast, waarbij het grid wordt vervormt om het hoogteverloop van het terrein weer te geven (figuur 6.6).
(a) (b)
Figuur 6.6: (a) Output van de eerste render stage, met slechts een kleur mapping toegepast om aan de floating-point waarden grijswaarden toe te kennen. (b) Deformatie van terrein door de tweede render stage, met dezelfde kleur mapping als (a).
De functionaliteit die in deze render stage is gerealiseerd lijkt erg op wat in tessellation shaders mogelijk is. Omdat gekozen is enkel OpenGL 2 technologie te gebruiken is deze functionaliteit niet beschikbaar. Het is echter toch mogelijk gebleken om equivalente functionaliteit te bouwen die kan draaien op systemen waar minder strenge systeemeisen aan zijn gesteld.
HOOFDSTUK 7
Interface
Om de data inzichtelijk te maken is het nodig de data accuraat en aantrekkelijk weer te geven. De gebruiker moet ook de mogelijkheid hebben de dataset te verkennen. Hiervoor is een intu¨ıtieve interface belangrijk. De gebruiker moet snel kunnen leren omgaan met de applicatie.
Multi-touch interfaces zijn bij uitstek geschikt om geografische datasets toegankelijk te maken voor ruimtelijke verkenning [JLG+12]. Ze bieden de mogelijkeid om verscheidene interactie mo-
gelijkheden aan te bieden via ´e´en input apparaat. Daarnaast zullen veel gebruikers reeds bekend zijn met multi-touch interfaces die voor consumentenapparaten beschikbaar zijn, zoals tablets, smartphones en multi-touch trackpads.
Om het user interface design “Principle of Least Astonishment”principe te volgen is gekozen om een aantal multi-touch interacties te implementeren waar een gebruiker van bijvoorbeeld Google Earth op multi-touch devices al mee bekend zal zijn. Dit zijn ook de interacties die in andere wetenschappelijke visualisatie toepassingen met een multi-touch interface gebruikt wor- den [BRS+10].
7.1
Zoomen
(a) (b) (c)
Figuur 7.1: De twee gele cirkels geven de positie van de twee vingers. In (a) heeft de gebruiker net haar vingers op het multi-touch apparaat gelegd zonder ze te bewegen. In (b) zijn de vingers uit elkaar gegaan t.o.v. (a) en is het terrein dichterbij gekomen. In (c) zijn de vingers dichterbij elkaar t.o.v. (a) en de camera staat nu verder van het terrein af.
Voor het zoomen worden twee vingers gebruikt. De gebruiker kan door de twee vingers van elkaar af te bewegen inzoomen en het terrein dichter bij de camera halen. Door de vingers dichter bij elkaar te brengen kan de gebruiker de camera verder van het terrein af bewegen. Deze interacties zijn ge¨ıllustreerd in figuur 7.1.
In het geval waar de camera recht naar beneden kijkt is het zoomen equivalent aan een tweedi- mensionale zoom. Dit maakt deze gevallen voor de hand liggend qua implementatie. Als zoomen
wanneer de camera gekanteld is een mogelijke interactie is, dan moet deze kanteling in het zoo- men worden meegenomen.
(a) (b)
(c) (d)
Figuur 7.2: Zoomen van een camera met een tilt. De gele cirkels geven de positie van de twee vingers aan. De rode cirkel geeft de positie tussen de twee vingers aan. Wat zich onder de rode cirkel bevindt bepaalt de richting van het zoomen. In (a) hebben de vingers nog niet bewogen. Bij (b) zijn ze uit elkaar en is het terrein dichterbij, bij (c) zijn de vingers bij elkaar en is het terrein verder weg. (d) Het kijk frustum van (a) in groen en de zoom richting (rode lijn) van (a).
Om zoomen in een 3D omgeving correct te laten verlopen wordt er gezoomd naar het punt van het terrein dat zich tussen de twee vingers bevindt. Het schermco¨ordinaat van dit punt wordt bepaald, waarna met behulp van een raycasting algoritme het punt van het terrein dat zich daar op het scherm bevindt wordt achterhaald. De vector die tussen dit punt en de camerapositie ligt bepaalt de richting van het zoomen. Deze vector is duidelijk te zien in figuur 7.5d.
7.2
Rotatie
Voor rotatie wordt wederom eerst het scenario waar de kijkrichting haaks staat op het terrein genomen. De camera kijkt dus eerst recht naar beneden. Dit geval is conceptueel eenvoudiger, omdat de rotatie gelijk is aan een tweedimensionale rotatie. Het is makkelijker in te schatten wat het verwachte gedrag is.
(a) (b) (c)
Figuur 7.3: De twee gele cirkels geven de positie van de twee vingers. De rode cirkel geeft de positie tussen de twee vingers en bepaalt de as waaromheen gedraaid wordt. Bij (a) zijn de vingers net neergezet, bij (b) hebben ze iets met de klok mee gedraaid en bij (c) zijn ze verder met de klok meegedraaid. Het terrein volgt de draaiing van de vingers.
De gebruiker gebruikt twee vingers om het terrein te roteren. Hierbij draaien de vingers om een imaginair middelpunt dat tussen de twee vingers ligt. Dit middelpunt bepaald het punt waaromheen het terrein draait. De hoeveelheid draaiing van de vingers bepaalt de hoeveelheid draaiing van het terrein.
(a) (b) (c)
(d) (e) (f)
Figuur 7.4: De twee gele cirkels in (a), (b) en (c) geven de posities van twee vingers aan. Deze draaien met de klok mee. (d), (e) en (f) laten de cameraposities van (a), (b) en (c) vanuit een extern perspectief zien. De vector tussen de camera en het punt onder de vingers is in beeld (rode lijn). Ook de vector waaromheen gedraaid wordt is te zien (gele lijn), welke loodrecht op het terrein vlak staat.
Bij het draaien met een gekantelde camera wordt gekeken naar het punt dat tussen de twee vingers ligt. De vector tussen de camera en het terrein dat onder dit punt ligt is te zien in fi- guur 7.4. Het lijkt logisch om deze vector als draaiings-as te gebruiken. Dit zou echter betekenen dat de horizon niet meer horizontaal zou staan vanuit de camera. Dit is iets dat vermeden dient te worden, omdat de gebruiker zijn ruimtelijke houvast anders kan kwijtraken.
In plaats daarvan is een andere draaings-as gekozen. Het punt van het terrein dat tussen de vingers ligt wordt genomen en een vector wordt opgesteld dat vanaf dit punt recht omhoog gaat. Dit is de draaings-as, waarbij tijdens de rotatie de kantelhoek van de camera behouden blijft.
In figuur 7.4 draait de rode vector om de gele vector en behoudt de rode vector dezelfde hoek ten opzichte van de gele vector.
7.3
Camera Bewegen
(a) (b)
(c) (d)
Figuur 7.5: Twee vingers worden met gele cirkels aangegeven in (a) en (b). Het middelpunt tussen de vingers is met een rode cirkel gemarkeerd. Hetzelfde stuk terrein blijft onder de rode cirkel wanneer de vingers bewegen tussen (a) en (b). (c) en (d) geven de cameraposities van (a) en (b) weer vanuit een extern perspectief. Het uiteinde van de rode vector blijft op hetzelfde punt van het terrein zitten tijdens de translatie terwijl de camera beweegt.
Voor het bewegen van de camera worden wederom twee vingers gebruikt. De positie van het ter- rein dat tussen de twee vingers ligt wordt bepaald. Als de vingers bewegen zodat dit punt ergens anders op het scherm terecht komt, dan wordt bepaald wat het nieuwe punt van het terrein is dat nu tussen de vingers ligt. De vector die tussen deze twee punten van het terrein ligt – het punt bij de start van de vingerbeweging en het punt bij het einde – kan dan worden opgesteld. Dit is de vector waarmee in omgekeerde richting de camerapositie wordt getransleerd.
Dit heeft als effect dat het lijkt alsof hetzelfde stukje van het terrein onder de vingers blijft zitten wanneer de vingers bewegen. Verder werkt het goed samen met de zoom en rotatie in- teracties. Als het middelpunt tussen de vingers bij het zoomen of roteren een beetje verspringt, dan zorgt de translatie stap dat hetzelfde punt van het terrein tussen de vingers blijft liggen.
7.4
Kijkrichting Camera
Voor het veranderen van de kijkrichting van de camera worden drie vingers gebruikt. Bij deze vorm van interactie blijft de camera op dezelfde positie in de ruimte. De camera verandert enkel de kijkhoek ten opzichte van het terrein.
(a)
(b) (c) (d)
(e)
Figuur 7.6: De drie gele cirkels geven de posities van drie vingers aan. De vingers beginnen in het midden bij (c). Bij (b) en (d) zijn de vingers respectievelijk naar rechts en naar links bewogen t.o.v. (c), waarbij de camera naar links en naar rechts is gedraaid. Bij (a) en (e) zijn de vingers respectievelijk naar beneden en naar boven bewogen t.o.v. (c), waarbij de camera naar beneden en naar boven is gedraaid.
Als naar figuur 7.6 gekeken wordt, dan is te zien dat de camera zich in de tegengestelde richting van de vingers draait. Dit is gedaan om de gebruiker het gevoel te geven dat het terrein ongeveer onder de vingers blijven zitten tijdens de beweging van de vingers. Dit is niet zo exact bedoelt als wat bij sectie 7.3 is gerealiseerd om het terrein onder de vingers te houden.
Het terrein kan ingebeeld worden als een projectie op een bol. Om de kijkrichting interactie voor te stellen kan deze inbeelding gebruikt worden. De vingers pakken de bol en draaien deze wanneer ze bewegen.
Een andere optie waarmee de interactie kan worden voorgesteld is dat wanneer de vinger naar links en rechts bewegen ze de camera laten nee knikken. En als de vingers naar boven en beneden bewegen laten ze de camera ja knikken.
HOOFDSTUK 8
Meetresultaten
Bij het ontwerpen van het systeem zijn een aantal keuzes gemaakt. De aanname was dat deze keuzes ten goede zouden komen van onder andere de performance en responsiviteit. Om te testen of de onderliggende aannames correct waren zijn metingen uitgevoerd met meerdere versies van de software, waar een gemaakte keuze wordt gecontrasteerd met een versie waar deze keuze anders is gemaakt.
8.1
Test Omgeving
De server gebruikt voor het testen is een systeem met een Intel Xeon E5620 processor draaiende met een kloksnelheid van 2.4 Ghz, met 4 cores die een totaal van 8 threads kunnen draaien (2 th- reads per core). Op het systeem zijn 24 GB aan RAM geheugen aanwezig. De software omgeving van de server is de x86-64 versie van Ubuntu 10.04.4 LTS met de 2.6.32-24-server #43-Ubuntu SMP Linux kernel.
De client omgeving draait op een 2012 MacBook Pro (type 9,1) met een Intel Core i7 pro- cessor draaiende met een kloksnelheid van 2.3 Ghz, met 4 cores die een totaal van 8 threads kunnen draaien (2 threads per core). Op het systeem zijn 4 GB aan 1600 MHz DDR3 RAM geheugen aanwezig. De software omgeving van de client is OS X 10.9.3. De GPU van het client systeem is een NVIDIA GeForce GT 650M videokaart met 512 MB videogeheugen. Het systeem heeft daarnaast ook een Intel HD Graphics 4000 GPU, maar deze draait niet tijdens het testen.
De netwerkverbinding van de server heeft een upload snelheid naar de client van ongeveer 1.1 MB/s. Deze is gevonden door met scp een bestand van de server naar de client te versturen. De server heeft een download snelheid van ongeveer 5.5 MB/s, gevonden door met wget het bestand http://speedtest.wdc01.softlayer.com/downloads/test10.zip op te halen. Het client sys- teem heeft een netwerkverbinding met een download snelheid van ongeveer 113 Mb/s (14 MB/s) en een upload snelheid van ongeveer 6 Mb/s (0.75 MB/s). Deze snelheden zijn gevonden met speedtest.net.
8.2
Test Scenario’s
Om de metingen te verrichten zijn een aantal test scenario’s uitgewerkt. Bij deze scenario’s kan de camera in de client een set aan vaste posities innemen die vooraf ingeprogrammeerd zijn. Dit lijdt tot een systeem dat meerdere malen gedraaid kan worden op gelijke wijze, waarbij enkel het aspect van het systeem dat onderzocht wordt gevarieerd wordt.
Scenario A Laat de camera boven het midden van Nederland beginnen, recht naar beneden kijkend. De camera begint op een hoogte van 1km. In een minuut verplaatst de camera zich hierna van 1km naar 150km hoogte. De verplaatsing gebeurt met een constante snelheid. In een
tweede minuut verplaatst de camera zich dan van 150km naar 100m hoogte. Dit test scenario neemt dus in totaal 2 minuten in.
Scenario B Laat de camera ook boven het midden van Nederland beginnen, recht naar be- neden kijkend. De camera begint op een hoogte van 180 m. De camera blijft daarna 20 se- conden stilstaan. Daarna verdubbelt de camera zijn hoogte (naar 360 m) en blijft daarna 20 seconden stilstaan. Dit verdubbelen en stilstaan herhaald zich tot de camera een hoogte van 180 m × 210 = 184.32 km heeft bereikt. De camera blijft nog 20 seconden stilstaan, waarna de
test eindigt. Dit test scenario neemt een totaal aan 220 seconden in.
Metingen zijn genomen met een client die op een resolutie van 800 bij 600 draait. De verti- cale synchronisatie (vsync) staat uit tijdens de metingen.