WARGame: creëren van een gedistribueerde augmented reality spelomgeving door het toevoegen van virtuele content aan de fysische wereld

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter

WARGame: cre¨ eren van een gedistribueerde “augmented reality” spelomgeving door het toevoegen van virtuele content aan de fysische wereld door Pieter Dhondt, Tim Verbelen

Promotoren: prof. dr. ir. Bart Dhoedt, prof. dr. ir. Filip De Turck Scriptiebegeleiders: Matthias Strobbe, Olivier Van Laere

Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen

Academiejaar 2008–2009

VOORWOORD

i

Voorwoord Wanneer we kijken naar het toekomstbeeld van computers en het Internet zoals het wordt voorgesteld door toonaangevende bedrijven, dan spreken ze vrijwel allemaal over ubiquitous en cloud computing, the Internet of things enz. Ook augmented reality is een begrip dat vaak voorkomt in toekomstvoorspellingen. Iedereen is altijd en overal geconnecteerd, en krijgt continu – al dan niet nuttige – informatie toegestuurd via het Internet. Om al deze informatie ten alle tijde weer te geven, komt dan ook vaak het concept van een futuristische bril naar voor, die al deze informatie gestructureerd voor je ogen plaatst. We waren dan ook aangenaam verrast toen we te horen kregen dat er een thesisonderwerp over augmented reality was, en de keuze stond dan ook snel vast. Voor de eerste keer in onze vijf jaar durende opleiding hadden we echt het gevoel te kunnen doen waarvoor we deze studierichting in de eerste plaats gekozen hebben: werken aan een volgende stap op weg naar dat toekomstbeeld. Wij willen in de eerste plaats dan ook onze thesisbegeleiders, Matthias en Olivier bedanken, voor het aanbrengen van dit onderwerp en de 9 maanden waarin wij altijd op hen konden rekenen. Samen met hen willen wij ook onze promotoren bedanken voor het gegeven vertrouwen en de geboden kans, dat we zelf het onderwerp mochten uitwerken. Daarnaast ook een woordje van dank aan het Studierstube team van Dieter Schmalstieg (Graz University of Technology), voor het beschikbaar stellen van hun framework en ons op weg te zetten. Wij willen ook zeker Ozan Cakmakci (University of Central Florida) en Gerhard Reitmayr (University of Cambridge) bedanken, voor de schitterende ervaring als student volunteer op de ISMAR’08 conferentie. Wij bedanken ook alle deelnemers aan onze gebruikerstest, voor het geven van hun ongezouten mening en de positieve reacties links en rechts. Maar net zoals op een voetbalveld komt de grootste steun van de zijlijn. Wij willen dan ook iedereen bedanken die ons al die jaren gesteund heeft. Bedankt aan onze ouders die ons de

mogelijkheden hebben gegeven om te komen waar we nu zijn en altijd achter onze keuzes hebben gestaan. Bedankt ook aan onze vrienden en vriendinnen, om er voor ons te zijn, te zorgen voor de momenten van ontspanning en de fantastische jaren in Gent.

Pieter Dhondt en Tim Verbelen, mei 2009

TOELATING TOT BRUIKLEEN

iii

Toelating tot bruikleen

“De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Pieter Dhondt en Tim Verbelen, mei 2009

WARGame: cre¨ eren van een gedistribueerde “augmented reality” spelomgeving door het toevoegen van virtuele content aan de fysische wereld door Pieter Dhondt, Tim Verbelen Masterproef ingediend tot het behalen van de academische graad van Master in de ingenieurswetenschappen: computerwetenschappen Academiejaar 2008–2009 Promotoren: prof. dr. ir. Bart Dhoedt, prof. dr. ir. Filip De Turck Scriptiebegeleiders: Matthias Strobbe, Olivier Van Laere Faculteit Ingenieurswetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: prof. dr. ir. Daniël De Zutter

Samenvatting In dit werk beschrijven we de ontwikkeling van WARGame, dat staat voor Wearable Augmented Reality Game. Met een video see-through setup nemen twee spelers het tegen elkaar op in een gedistribueerde augmented reality spelomgeving. De spelers kunnen zich vrij rondbewegen in de reële wereld, maar door middel van 2D markers wordt deze uitgebreid met virtuele objecten. Een Wii Remote wordt gebruikt om te interageren met de applicatie. Om de andere speler te detecteren wordt gebruik gemaakt van kleurdetectie algoritmes. Er wordt ook onderzoek verricht naar locatiebepaling door middel van sensor fusion van locatie informatie van de markers en gemeten Wi-Fi signaal sterktes. Tot slot evalueren we ons systeem zowel op technisch vlak als op het gebied van usability.

Trefwoorden augmented realtiy, game, gedistribueerd, video see-through, Wii Remote, sensor fusion, Wi-Fi localization

WARGame: a distributed augmented reality game environment Tim Verbelen∗

Pieter Dhondt† Olivier Van Laere Matthias Strobbe Filip De Turck Piet Demeester

Bart Dhoedt

Ghent University - IBBT Department of Technology, Gaston Crommenlaan 8 bus 201, 9050 Gent, Belgium

A BSTRACT This paper presents an indoor augmented reality first person shooter game: WARGame (Wearable Augmented Reality Game). WARGame aims for the experience of a first person shooter, played between two persons in the real world augmented with virtual game items. We describe the software and algorithms used for fiducial vision-based tracking, Wi-Fi localization and player detection. We also evaluate our game on performance and usability. Index Terms: H.5.1 [Information interfaces and presentation]: Multimedia Information Systems—Artificial, augmented and virtual realities; 1

I NTRODUCTION

Video games have come through a huge evolution. Boundaries are crossed and pushed further as we move towards fotorealistic rendering and enormous open game worlds. However, in most of the cases it still remains just watching a screen and pushing some buttons. The success of the Nintendo Wii game console shows that people like to move intuitively as if they were in the game themselves. This improves the game experience and makes it a lot more fun. With WARGame, we want to bridge the final gap and make gaming a real immersive experience. Instead of standing in front of a screen, the player should actually be in the game him/herself. Using a backpack setup, the player can move freely in the real environment, which is augmented with virtual items. 2

R ELATED

WORK

A lot of research is being done about Augmented Reality (AR) gaming. Piekarski et al. created ARQuake [5], an extension of the desktop game Quake, where the reality is augmented with Quake models (weapons, monsters, objects of interest). It uses GPS to track the location of the player and a plastic gun with a button to shoot. In order to manage the occlusion of monsters by buildings a 3D map of the environment is made and loaded as a Quake map. Another AR variant of a famous game is Human Pacman [3]. In contrast with ARQuake, it supports multiple players. One player plays as Pacman and has to collect all the cookies in the world. Other players are the ghosts that have to catch Pacman. Like ARQuake, it is also played outdoors and uses GPS for location tracking. Special cookies, called treasure boxes are represented as real items in the world and communicate with the system through Bluetooth devices. To detect if a ghost catches Pacman, a special touchsensor is used. The different players communicate with a central server by means of Wi-Fi. In NetAttack [4] two teams of two players have to compete against eachother to find certain objects. Those objects are augmented using large fiducial markers. Each team consists of an in∗ e-mail: † e-mail:

[email protected] [email protected]

door player and an outdoor player. The indoor player follows the game from behind a desktop computer and supports the outdoor player using an audio link. The outdoor player walks around and has to collect the game artifacts while trying to hide from the opposing outdoor player. His position is tracked by GPS and inertial sensors and are shown to the indoor player. For WARGame we use several elements from those games. Like ARQuake our aim is to develop a first person shooter game and so we will also use some kind of gun as input device. Because we don’t use virtual monsters, but human players our game is distributed like Human Pacman. Our virtual game items are augmented with fiducial markers as in NetAttack. However, because we want to play WARGame indoors, we can’t use GPS for location tracking. To shoot at the enemy player, accurate and robust player detection is needed. 3

WARG AME

WARGame stands for Wearable Augmented Reality Game as we provide a free-world gaming experience that lets you be a part of the game. In this section, we will explain our typical setup, the user interface, the way we use augmented reality and the different parts that characterize WARGame. 3.1

Setup

The hardware setup of WARGame consists of a video see-through configuration. A webcam is mounted on a helmet which captures the world around us. The video output is sent to a head-mounted display (HMD) that can be worn as regular glasses. On the HMD earbuds are attached which provide the sound. As for player input, we use a Wii Remote inside a Wii Gun that controls the movement of the on-screen cursor as well as input from the player such as shooting or requesting info like the score or the environment map. The Wii Remote is wirelessly connected via bluetooth. All the hardware comes together and is controlled by a portable computer that runs our application. We have put this in a regular backpack in order to minimize movement issues. Another vital part of WARGame is the use of colored vests for the player detection. We have chosen for a fluorescent yellow and orange colored vests that are worn above the backpack so the detection remains optimal. You can see a fully equipped player of WARGame in figure 1. The visible parts are the camera helmet, video glasses, the Wii Gun and the colored vest. All in all a very wearable and movable setup. The WARGame application is built using the Studierstube augmented reality framework [6]. 3.2

User interface

The player uses the Wii Remote to control the crosshair on the screen. We use the Wii Gun extension to make the game more intuitive. The player can shoot by pulling the trigger and reload by pressing the A-button. On the screen - as seen in figure 4 - the health is displayed on the lower left, and on the right the remaining bullets can be seen. The shirt in the middle shows the color that the player should be wearing. On top of the screen the timer represents the time left in the game and on the left of it, game-related messages are displayed as the accompanied events occur.

section 3.5) of every marker, this information can be used to estimate the player’s position in the game map.

Figure 1: The setup of WARGame

The player can display extra information by using the other buttons of the Wii Remote. By pressing the button 1 the player can choose to display a big fullscreen map with the item locations marked on it, or a small map in the upper right corner of the screen. On those maps the last known location of the players is also displayed, if this info is available (more information about this will be discussed in section 3.5). Button 2 is used to display the scoreboard of the current game. The Wii Remote is also used to provide feedback to the player. When he is hit by a shot the Wii Remote starts to vibrate. The power of his gun is showed by the amount of LEDs burning. 3.3

Items

Virtual items are added to the reality with ArtoolkitPlus [7]. The player can pick up those items by looking at them from a close distance. When a player fetches an item, it becomes inactive for some time. In the current version of WARGame we have 4 game items. Each of these items are show in figure 2. Healthpack The players health decreases as he gets shot by the enemy. To recover he can try to pick up a healthpack. Ammopack The ammopack gives the player an extra 20 bullets. Powerup The damage a shot can cause depends on the power of the gun. Every player starts with a small amount of power. By collecting powerups, this power will raise and the player will be able to do more damage and kill his opponent with only a few hits. As the player shoots, the power will decrease again to the initial value. The current power of the gun is shown by the LEDs on the Wii Remote.

3.4 Player detection To kill the other player we have to be able to detect him. Therefore the players wear colored vests. These are detected by histogram back projection and Camshift (Continuously Adaptive Mean Shift) [2], algorithms frequently used for face detection. First, we collect images of the colored vest in different lighting conditions. From these images we calculate a normalized 3D histogram in the HSV colorspace. We calculate the sum of all those histograms and normalize the resulting 3D histogram. This histogram is then used for back projection. This records how well pixels in an image fit the distribution of the colored vest histogram. As a result we get a grayscale image in which a white pixel resembles a high probability of being part of a colored vest as can be seen on figure 3.

(a) Input image

(b) Grayscale image

Figure 3: Detecting the colored vest in a video frame. The input image on the left is converted to a grayscale image on the right. The Camshift uses the grayscale image to calculate the bounding box.

The resulting grayscale image is used as input for the Camshift algorithm. This algorithm looks for peaks in a density distribution, or in our case bright segments in our grayscale image, which in fact is the player to be detected. When a player is detected, we draw a bounding box around him and display his name above the bounding box. The user also hears a sound to notify that an enemy is in sight.

Flag Each player has its base camp with a flag. The goal of the game is to capture the enemies flag and safely bring it to your own base camp. When your opponent steals your flag, you can recover it by killing your opponent.

(a) Healthpack

(b) Ammopack

(c) Power-up

(d) Flag

Figure 2: The different game items in WARGame.

Next to those game objects, there are also other virtual objects like signs or decorative objects. Because we know the location (see

Figure 4: An enemy is detected ingame.

3.5 Location tracker To help the player navigate through the game environment, a map of the environment is available with his position marked on it. Besides that the location of all the items and the enemy are visible on it. To estimate the player’s location we can use the known location of the

markers as stated in section 3.3. We also use the measured strength of available Wi-Fi access points as location estimator. Our Wi-Fi localization algorithm uses a probabilistic approach based on [1]. This consists of an offline training phase and an online detection phase. In the training phase, we choose training points on the map, and measure the signal strenghts of the networks 20 times. For each training point, we save the mean values of our measurements. For each network, we calculate the signal strength at each point on the map by linear interpolation. This gives us a signal strength map for each network.

4 E VALUATION We used a set of metrics such as CPU time, latency, memory usage etc. to evaluate our application. We also conducted a user study to gain feedback from end users. We deployed the application on two laptops, a Dell XPS M1330 and a Macbook pro, both with an Intel Core 2 Duo clocked at 2.20GHz and 2GiB memory. The server program was tested on a desktop pc with an Intel Core 2 Duo clocked at 3GHz and 4GiB memory. We used two i-Glasses 920HR HMDs and Logitech Quickcam Pro 9000 webcams for the video see-through setups. 4.1 Performance and scalability We measured performance using the windows perfmon tool. We identified that our application only consumes around 100MB of memory and the CPU load is less then 70% as shown on figure 7. Thus there is still room for extra load.

Figure 5: Left: map of the building. Right: signal strength map of the hallways (brighter is higher signal strength)

In the detection phase we use a particle filter to estimate the location. For every particle we calculate the probability that we would have this measurement knowing we are on that particle’s location: Prob(m|x) = ∏ exp(− i

(mi − Mi (x))2 ) σ2

(1)

where mi is the measured strength for access point i, Mi (x) the value of the signal strength map of access point i on location x and σ the variance on our measurements. We weigh our particles according to Prob(m|x) and resample the particle filter. To take the information of the known marker locations in account we also update the particle filter when we see a certain marker, favoring the particles close to the marker location.

Figure 7: The % CPU time used, there is still room for extra load.

Another important metric is the latency of the system. Therefore we measured the time it takes from the moment client 1 pulls the trigger until the sound is heard by client 2. This time interval consists of 3 parts: the time from the trigger until the sending of the message, the network time and the time when client 2 receives the message until the sound is heard. Because the three machines are connected to a local network, the network time is negligible. The time on client 2 is also less then a millisecond. As for the time on client 1 we measured an average time of 64 ms, and a maximum of 234 ms. Since the act of pulling the trigger itself takes an average user about 100 ms to 400 ms, we can conclude we meet the realtime demands. A last research issue was how well the server would scale to more players. Therefore we measured the time needed to process a message in the case of 2, 5, 10 and 20 players. Using linear regression we can then estimate the processing time for more players. We then determined an upper border for the number of messages the server would receive every second as a function of the number of players. These two curves let us estimate the number of players our server can handle as seen on figure 8. In the current setup where a player sends a location update every second we arrive at 110 players. When we raise the update frequency of location messages, it lowers the server capacity. In the hypothetical case of clients sending location updates at 100 Hz we arrive at 24 players, which is still good.

Figure 6: The location of the player and the items are shown ingame.

3.6

WARGame Server

Our stand-alone C++ server hosts the game and keeps a list of all players and their score. The player client sends all game events (shot, pick up item) to the server which distributes it to the other clients. Updates about the player’s location are sent every second.

Figure 8: The server scalability: how many players can the server handle?

4.2 User study For the user study we had to find a suitable location. Because of the lack of depth perception we had to avoid doors or small passages which are difficult to manage. The location also had to be an interesting game environment with the possibility to take cover, strategic item locations and good balance for the two players. Therefore we decorated a demo room ourselves in which we invited test users to play.

Figure 9: Two test users playing WARGame.

To evaluate the game experience we gathered feedback from test users by a questionnaire. The questions were rated from 1 to 5 with 1 the worst score and 5 the most positive. The results are covered in table 1. The hardware setup Were you troubled by dizzyness? Were you troubled by headache? Were you troubled by delay? Were you troubled by warmth of the backpack? Were you troubled by the weight on your back? WARGame features Was the other player detected correctly? What did you think of the interaction with the markers Was it easy to aim? Could you move around easily? The game experience What did you think of the game experience? Is there added value compared to regular video games? Would you pay for it? Would you pay for it when the technology is more mature?

3.52 4.52 2.64 3.96 4.32 3.08 3.96 2.56 3.2 4.24 4.42 3.12 4.3

Table 1: The results of the user study

At the time of writing, we collected data from 25 people between 19 and 31 years old. There weren’t many complaints about the hardware setup. Only the delay doensn’t score good, and some people were troubled by dizzyness afterwards. The main cause of the delay is that one of the laptops begins to overheat towards the end of the round (10 min.). This causes the CPU to underclock itself to lower the temperature with a stuttering video stream as consequence. The player detection was evaluated pretty good, but sometimes the color wasn’t properly detected due to the lighting conditions. The interaction with the markers went well, but the aiming was found more difficult. The lack of depth perception and the smaller field of view lowered the rating for walking around with the setup. The overall rating was very good. Most people were very suprised how well it ran and liked the experience of actually be-

ing in the game. They also considered the game experience much intenser than regular video games. Almost everyone would pay for playing WARGame when the technology has advanced and some of them would even consider to pay for the current application. 5 C ONCLUSION AND FUTURE WORK We have described WARGame, an augmented reality first person shooter game. Using a video see-through backpack setup two players compete to capture each others flag. Game items are augmented using the ARToolKitPlus library, and players are identified using colored vests. As an input device, we use the Wii Remote and Wii Gun, which gives the player an intuitive feeling of shooting. We also implemented a coarse level of location tracking using Wi-Fi signal strengths and marker locations. With WARGame we showed that augmented reality can give conventional multiplayer shooter games an extra dimension and give the players the feeling to actually be in the game. By offering a nice gameplay experience users pay less attention to the drawbacks of the backpack setup. The main drawback of our approach remains the use of the colored vests. This restricts the environment where the game can be played and the number of players. More accurate tracking of the players’ location and orientation would allow more clients. Using stereo vision or optical see-trough displays adds the feeling of depth, which would undoubtedly improve the user experience. The game itself is easily extensible with new item types, game modes etc. More immersive ways for feedback such as force feedback vests are also a nice add-on. ACKNOWLEDGEMENTS The research presented in this paper was done within the scope of our MSc thesis in order to obtain the degree of Master in Engineering: Computer Science. The authors wish to thank Matthias Strobbe and Olivier Van Laere for the support, and the Studierstube team for their platform. Matthias Strobbe is a research assistant of the Fund for Scientific Research - Flanders (F.W.O.-Vlaanderen). R EFERENCES [1] S. S. A. Howard and G. Sukhatme. An experimental study of localization using wireless ethernet. In Proceedings of the International Conference on Field and Service Robotics, July 2003. [2] J. G. Allen, R. Y. D. Xu, and J. S. Jin. Object tracking using camshift algorithm and multiple quantized feature spaces. In VIP ’05: Proceedings of the Pan-Sydney area workshop on Visual information processing, pages 3–7, Darlinghurst, Australia, Australia, 2004. Australian Computer Society, Inc. [3] A. D. Cheok, S. W. Fong, K. H. Goh, X. Yang, W. Liu, and F. Farzbiz. Human pacman: a sensing-based mobile entertainment system with ubiquitous computing and tangible interaction. In NetGames ’03: Proceedings of the 2nd workshop on Network and system support for games, pages 106–117, New York, NY, USA, 2003. ACM. [4] I. Lindt and W. Broll. Netattack - first steps towards pervasive gaming. ERCIM News, (57):49–50, 2004. [5] W. Piekarski and B. Thomas. Arquake: the outdoor augmented reality gaming system. Commun. ACM, 45(1):36–38, 2002. [6] D. Schmalstieg, A. Fuhrmann, G. Hesina, Z. Szalavári, L. M. Encarnaça˜ o, M. Gervautz, and W. Purgathofer. The studierstube augmented reality project. Technical Report TR-186-2-00-22, Institute of Computer Graphics and Algorithms, Vienna University of Technology, dec 2000. [7] D. Wagner and D. Schmalstieg. Artoolkitplus for pose tracking on mobile devices. In Proceedings of 12th Computer Vision Winter Workshop, 2007.

INHOUDSOPGAVE

ix

Inhoudsopgave

Voorwoord

i

Toelating tot bruikleen

iii

Overzicht

iv

Extended abstract

Gebruikte afkortingen

v

xiii

1 Inleiding

1

2 Wat is Augmented Reality?

3

3 State of the art

6

3.1

3.2

Displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.1.1

Monitor based displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

6

3.1.2

Head mounted displays . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.1.3

Handheld displays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

Tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3.2.1

Tracking m.b.v. sensoren . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.2.2

Vision-based tracking . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

INHOUDSOPGAVE

3.2.3 3.3

3.4

x

Hybride tracking technieken . . . . . . . . . . . . . . . . . . . . . . . . . .

10

Software frameworks voor augmented reality . . . . . . . . . . . . . . . . . . . . .

11

3.3.1

Toolkits voor 3D visualisatie . . . . . . . . . . . . . . . . . . . . . . . . .

11

3.3.2

Abstractie lagen voor tracking devices . . . . . . . . . . . . . . . . . . . .

12

3.3.3

Augmented reality frameworks . . . . . . . . . . . . . . . . . . . . . . . .

13

Bedrijven en consortia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

4 WARGame

16

4.1

Wat is WARGame? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

16

4.2

Augmented reality games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

4.3

WARGame setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

5 Implementatie 5.1

5.2

22

Ontwerpbeslissingen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

5.1.1

Marker-based versus marker-less . . . . . . . . . . . . . . . . . . . . . . .

23

5.1.2

Client-server versus peer-to-peer . . . . . . . . . . . . . . . . . . . . . . .

24

5.1.3

Thick client versus thin client . . . . . . . . . . . . . . . . . . . . . . . . .

24

Software platform en bibliotheken . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.2.1

Studierstube . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

5.2.2

ACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

5.2.3

OpenCV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

5.2.4

FMOD

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

5.3

Architectuur

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

5.4

Virtuele objecten met ARToolKitPlus . . . . . . . . . . . . . . . . . . . . . . . .

30

5.4.1

ARToolkitPlus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

30

5.4.2

Cameramodel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

31

INHOUDSOPGAVE

xi

5.4.3

Camera kalibratie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

34

5.4.4

Spelobjecten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

35

5.5

Wii input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

36

5.6

VideoAnalyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.6.1

Kleurdetectie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

38

5.6.2

Camshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.7

Game engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

5.8

Game server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

43

5.9

LocationTracker

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.9.1

Vision-based locatiebepaling . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.9.2

Wi-Fi localisatie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.9.3

Wi-Fi signal strength maps . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.9.4

Sequentiële Monte Carlo methode . . . . . . . . . . . . . . . . . . . . . .

49

5.9.5

Sensor fusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

51

5.9.6

Locatiegegevens in WARGame . . . . . . . . . . . . . . . . . . . . . . . .

52

6 Resultaten 6.1

6.2

6.3

53

Performantie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

53

6.1.1

Latentietijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

54

6.1.2

Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

Schaalbaarheid server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

56

6.2.1

Aantal berichten per seconde . . . . . . . . . . . . . . . . . . . . . . . . .

57

6.2.2

Verwerkingstijd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

58

6.2.3

Bandbreedte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

Gebruikersstudie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

INHOUDSOPGAVE

xii

6.3.1

Hardware setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6.3.2

Spelfeatures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

63

6.3.3

Spelervaring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

64

6.3.4

Open vragen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

65

7 Mogelijke uitbreidingen

66

7.1

Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

66

7.2

Platform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

68

7.3

WARGame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

69

8 Conclusie

70

GEBRUIKTE AFKORTINGEN

Gebruikte afkortingen ACE

Adaptive Communication Environment

ACM

Association for Computing Machinery

API

Application programming interface

AR

Augmented Reality

BSD

Berkeley Software Distribution

CCD

Charge-Coupled Device

CORBA

Common Object Request Broker Architecture

CPU

Central Processing Unit

DLL

Dynamic Link Library

DOF

Degrees Of Freedom

DVD

Digital Versatile Disc

FPS

First Person Shooter

GPS

Global Positioning System

HCI

Human Computer Interface

HMD

Head-mounted display

IEEE

Institute of Electrical and Electronics Engineers

IP

Internet Protocol

ISO

International Organization for Standardization

kbps

kilobit per seconde

LAN

Local Area Network

LCD

Liquid Crystal Display

LED

Light Emitting Diode

LGPL

GNU Lesser General Public License

Mbps

Megabit per seconde

xiii

GEBRUIKTE AFKORTINGEN

MR

Mixed Reality

PDA

Personal Digital Assistant

RSSI

Received Signal Strength Indication

RTT

Round Trip Time

SFM

Structure From Motion

SGI

Silicon Graphics Inc.

SLAM

Simultaneous Localization And Mapping

SSID

Service Set Identifier

TCP

Transmission Control Protocol

TGS

Template Graphics Software

UDP

User Datagram Protocol

USB

Universal Serial Bus

VRML

Virtual Reality Markup Language

VRPN

Virtual Reality Peripheral Network

Wi-Fi

Wireless Fidelity

XML

Extensible Markup Language

xiv

INLEIDING

1

Hoofdstuk 1

Inleiding Augmented reality is een vrij recent onderzoeksgebied in de computerwetenschappen. Het combineren van virtuele objecten met de realiteit spreekt tot de verbeelding van vele mensen en opent deuren naar tal van applicaties voor navigatie, virtuele reclameborden, simulatie, ondersteuning bij complexe taken of entertainment. Wij hebben gekozen om een applicatie te ontwikkelen in dat laatste domein, meer bepaald gaming. Enerzijds omdat dit voor ons het onderwerp aantrekkelijker maakt, maar anderzijds ook omdat wij er van overtuigd zijn dat dit één van de weinige domeinen is waar je de mensen kunt overhalen om een complete setup aan te trekken en waar de eisen omtrent nauwkeurigheid en realisme een stuk lager liggen dan bij bijvoorbeeld industriële applicaties. Hedendaagse computerspellen trachten de speler onder te dompelen in een andere wereld en proberen met een beklijvende verhaallijn, indrukwekkende graphics en geluidseffecten om hem / haar weg te trekken uit de realiteit. Ondanks alles blijft deze ervaring echter beperkt tot het kijken naar een scherm en intussen commando’s geven via knoppen, joysticks of een muis. De recente opkomst van de Wii console van Nintendo probeert deze ervaring al intenser te maken door de speler voor zijn scherm bewegingen te laten uitvoeren die het personage in het spel nabootst. Wij willen nog een stap verder gaan en met augmented reality technologie de speler het gevoel geven dat hij zich echt in het spel bevindt en dat hij één wordt met het hoofdpersonage. Ook de komst van het Internet heeft een grote impact gehad op computerspelletjes. Dit heeft de deur geopend naar multiplayer games: de speler neemt het niet alleen meer op tegen de computer, maar het is mogelijk om menselijke tegen- en medespelers te hebben in het spel.

INLEIDING

2

Niet alleen zorgt dit voor een grotere uitdaging – artificiële intelligentie kan nog steeds niet tippen aan menselijke gedragingen en het is ook leuker om te winnen van een persoon – er wordt ook een sociaal aspect toegevoegd. Tijdens het spel kunnen de verschillende spelers met elkaar communiceren met tekstberichtjes of zelfs met spraak door een microfoon. Dit sociale aspect komt nog meer naar voor bij augmented reality spellen, aangezien de spelers terug fysiek bij elkaar zijn. In dit werk bespreken we de ontwikkeling van ons augmented reality spel WARGame. In het volgende hoofdstuk vertellen we iets meer over augmented reality, gevolgd door een literatuurstudie van het augmented reality domein in hoofdstuk 3. In hoofdstuk 4 bespreken we ons spel WARGame en de gebruikte hardware en positioneren we het ten opzichte van andere augmented reality spellen. Hoofdstuk 5 behandelt de implementatie van het spel, waarbij we alle componenten overlopen en de gebruikte technieken bespreken. Vervolgens bespreken we onze resultaten in hoofdstuk 6. We analyseren verschillende metrieken en onderzoeken hoe onze applicatie onthaald werd door een aantal testgebruikers. Tot slot lichten we in hoofdstuk 7 nog enkele punten voor verbetering toe en ideeën voor de toekomst om te eindigen met onze conclusies in hoofdstuk 8.

WAT IS AUGMENTED REALITY?

3

Hoofdstuk 2

Wat is Augmented Reality? Augmented Reality (AR) is volgens [Azuma, 1997] een variatie op Virtual Reality. Deze laatste dompelt de gebruiker volledig onder in een synthetische omgeving waar hij de echte fysische wereld niet meer kan zien. In tegenstelling hiermee laat Augmented Reality de gebruiker de fysische wereld zien, gecombineerd met virtuele objecten die er hun eigen plaats innemen. Daarom kunnen we stellen dat AR de werkelijkheid uitbreidt en niet vervangt. Idealiter zou het voor de gebruiker moeten lijken alsof de virtuele en fysische objecten in dezelfde ruimte bestaan. Figuur 2.1 toont hoe dit er zou kunnen uitzien. We zien een tafel, een telefoon, een lamp en twee stoelen. De tafel en telefoon zijn echt, de lamp en de stoelen zijn virtueel. Merk op dat de virtuele objecten gecombineerd zijn in de reële driedimensionale wereld waardoor de virtuele lamp de fysieke tafel deels bedekt en de fysieke tafel op haar beurt de twee virtuele stoelen deels bedekt. Om AR te definiëren zonder afhankelijk te zijn van de manier waarop AR gebracht wordt, kunnen we AR definiëren als een systeem dat de volgende drie kenmerken bezit: 1. Het combineert de reële wereld met de virtuele wereld 2. Het is interactief in real-time 3. Het registreert de wereld in drie dimensies Deze definitie omvat alle essentiële componenten van AR en is dan ook in de gehele literatuur aanvaard als een goede definitie van een AR-systeem.


4

Figuur 2.1: Reële bureautafel met een virtuele lamp en twee virtuele stoelen Een ander interessant concept om AR wat meer te kunnen plaatsen, is dat van het “virtueel continuum” gedefinieerd door [Milgram et al., 1995]. De traditionele kijk op een Virtual Reality (VR) omgeving is er een waarbij de deelnemer compleet ondergedompeld is in een synthetische wereld. Deze wereld kan de eigenschappen van de echte wereld nabootsen, maar het kan hierbij ook de grenzen van de fysieke wereld overschrijden. Zo ontstaat er een virtuele wereld waarbij de wetten van de natuurkunde die ruimte, tijd, mechanica, etc. beschrijven niet langer gelden. De naam “Virtual Reality” wordt echter ook dikwijls geassocieerd met een omgeving die niet volledig synthetisch is, maar die ergens langs een “virtueel continuum” ligt. Dit concept heeft betrekking op de mix van types van objecten die in bepaalde applicaties voorkomen – figuur 2.2 maakt dit duidelijk. De reële omgeving staat aan het ene eind van het continuum, de volledig virtuele of

Figuur 2.2: Het virtueel continuum volgens Milgram synthetische omgeving staat aan het andere eind van het continuum. Een reële omgeving bevat enkel reële objecten en slaat bijvoorbeeld op een videofeed afkomstig van een webcamera. Een virtuele omgeving aan de rechterkant van het continuum bevat enkel virtuele objecten, zoals


5

bijvoorbeeld het geval is in een computerspel. Mixed Reality (MR) bevat volgens Milgram dan zowel reële als virtuele objecten, samen gepresenteerd in een enkel display (meer hierover in hoofdstuk 3.1). AR verhoogt de realiteit terwijl bij Augmented Virtuality reële objecten een virtuele wereld aanvullen. Tegenwoordig worden AR en MR echter vaak als synoniem gebruikt.

STATE OF THE ART

6

Hoofdstuk 3

State of the art In dit hoofdstuk geven we een overzicht van de huidige state of the art. We bespreken de recentste technieken die gebruikt worden in augmented reality en verscheidene applicaties en toolkits. Ook gaat er aandacht naar consortia en commerciële bedrijven die werken rond augmented reality. Om een goed beeld te krijgen van de hedendaagse technologie, zijn we naar de ISMAR’081 conferentie geweest. Dit is de toonaangevende conferentie over mixed en augmented reality die georganiseerd wordt in samenwerking met ACM en IEEE.

3.1

Displays

Een eerste belangrijk onderdeel van een augmented reality setup is een display waarop de beelden kunnen getoond worden. Hiervoor zijn er verschillende uitvoeringen mogelijk waaronder monitor based displays, head mounted displays en handheld displays. We geven een kort overzicht met de belangrijkste voor- en nadelen van elk type display.

3.1.1

Monitor based displays

Een eerste klasse van displays zijn de monitor based displays [Milgram et al., 1995]. Virtuele objecten worden bovenop live of opgenomen videobeelden getoond op een scherm. De meest gebruikte techniek hiervoor is chroma-keying. Hiervoor wordt het welbekende groen of blauw scherm zoals in opnamestudio’s gebruikt. Door kleurenfilters te gebruiken kan het gefilmde 1

meer informatie is te vinden op http://ismar08.org/

3.1 Displays

7

object weergegeven worden voor een andere achtergrond. Een ander courant voorbeeld van monitor based displays zijn de annotaties op het scherm bij voetbaluitzendingen, waar de score of de lijn van buitenspel bovenop de live beelden worden weergegeven. Ook kan men de illusie van dieptezicht wekken door gebruik te maken van stereoscopie [Drascic et al., 1993].

3.1.2

Head mounted displays

Een head mounted display (HMD) wordt op het hoofd gedragen als een bril. Er zijn 2 soorten HMDs: video see-through en optical see-through [Azuma, 1997]. Bij optical see-through kan men door de display heen kijken zodat de objecten weergegeven op het display automatisch samengevoegd worden met de realiteit. Video see-through displays maken gebruik van camera’s die de ogen vervangen. De videobeelden van deze camera’s worden dan samengevoegd met de virtuele objecten en op het display weergegeven.

(a) Mono video see-through

(b) Stereo video see-through

(c) Optical see-through

Figuur 3.1: Links: de i-Visor HMD met één webcam om een monoscopische video see-through setup te bekomen. Midden: dezelfde i-Visor HMD, nu met 2 camera’s ter hoogte van de ogen om een stereoscopische video see-through setup te bekomen. Rechts: de Advisor 150 optical see-through HMD ontwikkeld door SAABTech.

Beide soorten hebben hun voor- en nadelen [Rolland and Fuchs, 2000]. Bij optical see-through is het samenvoegen van de virtuele en reële wereld eenvoudiger. Daarnaast is bij video see-through de gebruiker afhankelijk van de resolutie en de stand van de camera’s om een goede ervaring te hebben. Video see-through heeft ook het probleem dat de gebruiker blind wordt als er een defect is, wat onaanvaardbaar kan zijn voor de veiligheid in sommige toepassingen. Een voordeel van video see-through is wel dat de applicatie meer controle heeft bij het samenvoegen van de beelden en het ook gemakkelijker is om de virtuele objecten aan te passen aan de lichtinval van de werkelijkheid. Bovendien kan de videostroom die binnenkomt, gebruikt worden als extra bron

3.2 Tracking

8

van informatie over de locatie van de gebruiker. Het ontwikkelen van HMDs is zeer complex en haast een vakgebied op zich geworden zoals te lezen in [Cakmakci and Roll, 2006]. Afhankelijk van de eisen van de applicatie zou er idealiter telkens een nieuwe HMD moeten ontwikkeld worden. Recente ontwikkelingen streven naar lichte en comfortabele HMDs [Cakmakci et al., 2008] en technieken om virtuele objecten beter in de realiteit samen te voegen zodat de grens tussen de reële en virtuele wereld steeds verder blijft vervagen [Liu et al., 2008] [Klein and Murray, 2008a].

3.1.3

Handheld displays

Tot slot zijn er ook de handheld displays, die de laatste tijd steeds meer aan belangstelling winnen [Wagner, 2007]. De nieuwste mobiele telefoons beschikken bijna allemaal over een ingebouwde camera en hun rekenkracht neemt steeds toe, wat hen een ideaal platform maakt voor augmented reality applicaties. Het grote voordeel van dit platform is dat vele mensen erover beschikken en het daardoor augmented reality applicaties toegangelijker maakt voor de grote massa. De benodigde hardware is ook goedkoop ten opzichte van een setup met een HMD. Het voornaamste nadeel is de beperkte schermgrootte waardoor men eerder een venster op de wereld creëert in plaats van een totaalervaring waarin je volledig wordt meegetrokken. Daarnaast heeft men ook te kampen met de beperkte kracht van de hardware, al wordt deze grens steeds weer verlegd. Vooral het team van Daniel Wagner levert uitstekend werk op het gebied van marker-based (tracking op basis van barcodes) [Wagner et al., 2008a] en marker-less (tracking zonder externe hulpmiddelen) [Wagner et al., 2008b] tracking op mobiele telefoons. Op het Internet zijn er reeds verschillende augmented reality applicaties te vinden op onder andere iPhone en Androidgebaseerde toestellen. Het hoeft niet uitsluitend over mobiele telefoons te gaan. Het bedrijf Metaio ontwikkelde voor het Louvre een augmented reality museum gids op een speciaal ontwikkelde UMPC (Ultra Mobile Personal Computer) [Miyashita et al., 2008].

3.2

Tracking

In een augmented reality applicatie worden virtuele objecten gecombineerd met de realiteit. Om de illusie te creëren dat de virtuele objecten zich in de reële wereld bevinden moeten deze correct weergegeven worden en zich gedragen als reële objecten. Daarvoor is een nauwkeurige registratie

3.2 Tracking

9

van de realiteit nodig: men moet weten waar de gebruiker naar kijkt en welke virtuele objecten voor hem zichtbaar zijn. Dit proces wordt ook wel tracking genoemd.

3.2.1

Tracking m.b.v. sensoren

Een eerste manier om informatie te weten te komen over de gebruiker en zijn omgeving is met behulp van sensoren. Veel gebruikte sensoren zijn GPS, inertiaalsensoren, gyroscopen, accelerometers, magnetische sensoren, akoestische sensoren enz. Een overzicht van tracking technieken met sensoren vindt u in [Rolland et al., 2001]. De verschillende types sensoren hebben allen hun voor- en nadelen en hun eigen applicatiedomeinen. GPS is bijvoorbeeld enkel bruikbaar als men een GPS signaal kan ontvangen. Dit maakt het goed voor locatiebepaling buitenshuis, maar onbruikbaar binnenshuis. Ook is de nauwkeurigheid van een GPS signaal typisch slechts 10 meter. Alle sensoren hebben te maken met een zekere onnauwkeurigheid en drift. Daardoor streven nieuwe technologiën er steeds meer naar om informatie van verschillende sensoren te combineren. Fong et al. zijn er bijvoorbeeld in geslaagd meerdere GPS signalen te combineren om een nauwkeurigheid van 10 centimeter te verkrijgen [Fong et al., 2008]. Ook [Newman et al., 2004] en [Pustka and Klinker, 2008] proberen om data van mobiele en statische sensoren te combineren om een hogere nauwkeurigheid te verkrijgen.

3.2.2

Vision-based tracking

Bij vision-based tracking wordt gebruik gemaakt van de videostroom van een camera om de positie en oriëntatie van de camera te schatten. Een eerste techniek is om 2D markers te verspreiden in de ruimte en wanneer deze in de beelden gedetecteerd worden kan men de de positie van de camera ten opzichte van deze markers bepalen. Aan de hand van deze gegevens kan men dan bepalen welke positie en oriëntatie een virtueel object moet hebben om het op de plaats van de marker te laten staan. Dit is precies wat de ARToolkit software bibliotheek doet en wordt zeer vaak gebruikt in augmented reality toepassingen [Kato and Billinghurst, 1999]. In het spoor van ARToolkit zijn dan andere marker gebaseerde systemen ontwikkeld zoals ARlib [Umlauf et al., 2002] en ARTag [Fiala, 2005]. ARToolkitPlus [Wagner and Schmalstieg, 2007] dat overgegaan is in Studierstube Tracker [Wagner et al., 2008a] gebruikt een aangepaste methode zodat deze ook voor mobiele telefoons gebruikt kan worden.

3.2 Tracking

10

(a) ARToolkit

(b) ARToolkitPlus

Figuur 3.2: Links: ARToolkit [Kato and Billinghurst, 1999] schat de positie van de camera en rendert een virtueel object op de 2D marker zichtbaar door de HMD. Rechts: ARToolkitPlus [Wagner and Schmalstieg, 2007] doet hetzelfde maar dan op een mobiele telefoon .

Een andere techniek is om geen gebruik te maken van 2D markers, maar van herkenningspunten in de reële wereld. Dit kunnen bijvoorbeeld hoekpunten zijn, scherpe randen of oppervlakken met een duidelijke textuur [Comport et al., 2003] [Vacchetti et al., 2004]. In [Park et al., 2008] wordt beschreven hoe men meerdere objecten kan tracken op basis van herkenningspunten en contourdetectie. Wagner et al. heeft zo’n methode ontwikkeld voor mobiele telefooons [Wagner et al., 2008b]. Deze technieken vereisen echter nog steeds a priori kennis van de omgeving. We moeten op voorhand weten welke herkenningspunten er aanwezig zijn om ze te tracken. Om ook in een a priori onbekende omgeving te kunnen werken wordt SLAM (Simultaneous Localization And Mapping) toegepast [Montemerlo et al., 2003]. Dit algoritme is afkomstig uit de robotica om robots hun weg te laten vinden in een onbekende omgeving. Klein en Murray hebben dit aangepast om te gebruiken in augmented reality applicaties [Klein and Murray, 2007] [Klein and Murray, 2008b]. Voor een meer uitgebreide survey over vision based tracking en de gebruikte technieken verwijzen we naar [Lepetit and Fua, 2005].

3.2.3

Hybride tracking technieken

Het grootste nadeel van de vision based technieken is dat zij erg afhankelijk zijn van de kwaliteit van de videobeelden. Markers of features kunnen op grote afstanden of bij snelle camerabewe-

3.3 Software frameworks voor augmented reality

(a) Feature point tracking

(b) SLAM

11

(c) AR with SLAM tracking

Figuur 3.3: Links: feature point tracking van meerdere objecten [Park et al., 2008]. Midden: SLAM: er worden feature points gezocht (links) en een map van gecreëerd (rechts) [Klein and Murray, 2007]. Rechts: AR applicatie met behulp van SLAM tracking: virtuele objecten worden in de wereld geplaatst [Klein and Murray, 2007].

gingen niet meer gedetecteerd worden. Daarom probeert men om deze technieken te combineren met sensoren om zo hybride trackingsystemen te ontwikkelen [You et al., 1999]. Het gebruiken van data van verschillende tracking methoden om een robuuster systeem te verkrijgen wordt ook wel sensor fusion genoemd. Toepassingen van hybride tracking systemen worden beschreven in [Klein and Drummond, 2002], [Reitmayr and Drummond, 2006], [Foxlin et al., 2004] en [Bleser and Stricker, 2008].

3.3 3.3.1

Software frameworks voor augmented reality Toolkits voor 3D visualisatie

OpenInventor - OpenInventor is een object-geöriënteerde 3D toolkit met als doel een hoger niveau API aan te bieden bovenop OpenGL. Het werd oorspronkelijk ontwikkeld door SGI (Silicon Graphics, Inc) onder de naam IRIS Inventor [Strauss, 1993] met als doel het ontwikkelen van 3D applicaties te vergemakkelijken. OpenInventor stelt de virtuele wereld voor in een scenegraph, dit is een boomstructuur bestaande uit knopen die de objecten voorstellen. Deze manier van werken wordt ook gebruikt in de meeste vector gebaseerde grafische programma’s zoals bijvoorbeeld AutoCAD. OpenInventor werd gereleased onder een opensource licentie in 2000. In ongeveer dezelfde periode ontwikkelde Systems In Motion de Coin3D toolkit. Deze biedt dezelfde API aan als OpenInventor, maar met een eigen implementatie. Coin3D is beschikbaar onder een dual license. De oorspronkelijke OpenInventor is nu in handen van TGS (Template


12

Graphics Software). Beiden zijn nog steeds in actieve ontwikkeling. De OpenInventor API wordt gebruikt in het augmented reality framework Studierstube. OpenSceneGraph - Het OpenSceneGraph project startte in 1998 als hobby van Don Burns. Een jaar later kreeg hij het gezelschap van Robert Osfield en werd het project opensource gemaakt. Het is gebaseerd op Performer, een ander project van SGI, waar de focus meer lag op performantie in plaats van gebruiksgemak. In 2001 maakte Don van zijn hobby zijn beroep en stichtte het bedrijf Andes Computer Engineering om commerciële support te leveren en OpenSceneGraph verder te ontwikkelen. De dag van vandaag wordt OpenSceneGraph gebruikt in tal van applicaties zoals games, virtual reality, wetenschappelijke visualisatie en dus ook augmented reality. Onder andere het OSGART project gebruikt OpenSceneGraph. OpenSG - Net als OpenSceneGraph is het OpenSG ontstaan uit de eerste generatie van scenegraph toolkits in de jaren ’90. Het heeft extra features voor clustering en multithreading support en is gereleased onder een LGPL licentie. Het werd gebruikt in OpenSG PLUS, een project gesponserd door de Duitse regering voor onderzoek naar augmented en virtual reality. VRML en X3D - In tegenstelling tot de andere drie is VRML (Virtual Reality Markup Language) geen toolkit, maar een taal die gebruikt wordt om driedimensionale objecten weer te geven. Het is een ISO standaard en de beschreven objecten kunnen weergegeven worden in een browser met behulp van een VRML plugin. VRML kan dus gezien worden als de standaard om scenegraphs op te slaan, maar is nooit echt doorgebroken. VRML is onlangs opgevolgd door de nieuwe X3D standaard. X3D voorziet ook features voor augmented reality zoals tekst overlays, audio en video.

3.3.2

Abstractie lagen voor tracking devices

VRPN - Het VRPN (Virtual Reality Peripheral Network) systeem is een set van klassen die zorgen voor een netwerktransparante interface tussen applicaties en verschillende devices (bijvoorbeeld sensoren voor tracking) gebruikt in virtual en augmented reality [Ii et al., 2001]. Het abstraheert de devices zodat het voor de applicatie niet uitmaakt welk device gebruikt wordt. Het ondersteunt een grote variëteit aan hardware waaronder verscheidene inertiaalsensoren en gyroscopen. De VRPN source code is gereleased in het publieke domein en dus vrij te gebruiken. OpenTracker - OpenTracker is net als VRPN een device abstraction layer voor tracking devices. Het biedt echter niet alleen een interface aan, door middel van een XML configuratiefile kan een


13

hele data flow graaf gemaakt worden die data van verschillende bronnen verwerkt, transformeert, samenvoegt en aanbiedt aan de applicatie [Reitmayr and Schmalstieg, 2001]. Bovendien kan het zelf ook connectie maken met VRPN interfaces. Opentracker wordt gebruikt in het Studierstube platform [Schmalstieg et al., 2000]. Ook OpenTracker is open source.

3.3.3

Augmented reality frameworks

ARToolkit - ARToolkit was de eerste echte toolkit die kon gebruikt worden voor de ontwikkeling van augmented reality applicaties.

Het maakt gebruik van 2D barcodes om de

positie van de camera te schatten en 3D objecten te renderen als het ware op de marker [Kato and Billinghurst, 1999]. Veel applicaties maken gebruik van deze toolkit of gebruiken een andere bibliotheek met dezelfde functionaliteit. Deze paper over ARToolkit is dan ook de meest geciteerde paper in het domein van augmented reality. Studierstube - Studierstube is een open source augmented reality framework dat gebouwd is bovenop OpenInventor [Fuhrmann, 1999] [Schmalstieg et al., 2000]. Het heeft onder andere eigen modules toegevoegd voor 2D marker tracking en gebruikt OpenTracker om te interageren met devices.

Het wordt gebruikt in tal van projecten en naar voor geschoven als

een platform voor wetenschappelijke visualisatie en multi-user games in augmented reality [Fuhrmann and Purgathofer, 2001]. Naast het Studierstube framework is er ook de Studierstube ES library die bestemd is voor mobiele telefoons [Wagner, 2007]. Deze is echter nog niet vrij beschikbaar. DWARF - Distributed Wearable Augmented Reality Framework is een framework dat als doel heeft snel prototypes te kunnen ontwikkelen van augmented reality applicaties [Bauer et al., 2001]. De verschillende componenten van een applicatie worden ge¨ımplementeerd als services die gedistribueerd kunnen zijn over het netwerk op heterogene machines. De services worden met elkaar verbonden door de onderliggende CORBA middleware. DWARF componenten kunnen ook gebruikt worden in het eerder vernoemde Studierstube framework zoals beschreven in [Bauer et al., 2003]. DART - DART is een set uitbreidingen op het vroegere Macromedia Director (nu Adobe Director) om augmented reality applicates te ontwikkelen [MacIntyre et al., 2004]. Director is een multimedia authoring tool die vooral gebruik wordt voor user interfaces van DVDs en spelletjes. DART is dan ook vooral bedoeld voor artiesten en designers om AR toepassingen te maken.

3.4 Bedrijven en consortia

14

Het gebruikt de ARToolkit voor marker tracking en VRPN als interface met tracking devices. Het gebruikt Director’s scriptingtaal Lingo om interactie mogelijk te maken. OSGART - De OSGART bibliotheek combineert OpenSceneGraph met de ARToolkit om een augmented reality framework te vormen [Looser et al., 2006]. OpenSceneGraph biedt dus eigenlijk een hoger niveau API bovenop de marker tracking technologie van ARToolikt. Tinmith - Het Tinmith project focust zich op outdoor augmented reality en richt zich op zowel software als hardware [Piekarski and Thomas, 2002b]. Het gebruikt een op maat gemaakte backpack PC uitgerust met onder andere een accurate GPS ontvanger (50 cm precisie), Wi-Fi, Bluetooth en draadloze video output. Daarnaast gebruikt het ook een helm met een ingebouwde camera, HMD en oriëntatiesensoren en draadloze input devices zoals speciale wireless handschoenen. Applicaties worden gebouwd op het Tinmith software platform [Piekarski and Thomas, 2001a]. De voornaamste zijn Metro, een applicatie die de gebruiker in staat stelt om met handschoenen 3D modellen te bouwen in de wereld [Piekarski and Thomas, 2001b] en ARQuake, dat het Quake spel geport heeft naar een AR applicatie [Piekarski and Thomas, 2002a]. Goblin XNA - Het Goblin XNA is een laag bovenop het Microsoft XNA platform, dat bedoeld is voor het ontwikkelen van 3D games voor PC en Xbox. Goblin breidt dit uit met ARTag marker tracking en interfaces voor inertiaalsensoren. Dat moet het mogelijk maken om gemakkelijk augmented reality games te ontwikkelen [Oda et al., 2007].

3.4

Bedrijven en consortia

Ook al staat de technologie nog in zijn kinderschoenen, toch is er ook vanuit de bedrijfswereld interesse naar augmented reality applicaties. Verschillende bedrijven investeren in onderzoek naar mogelijke toepassingen. Zo zijn er verscheidene consortia opgericht zoals ARTESAS, AVILUS en AVILUS+ waarin bedrijven zoals BMW, Siemens en Airbus actief zijn. Daarnaast zijn er enkelen die het aandurven om van augmented reality hun core business te maken. Zo is er Total Immersion dat zich toelegt op het verzorgen van augmented reality presentaties, interactieve kiosken en augmented video. Een ander bedrijf, Metaio, heeft Unifeye ontwikkeld. Dit is een commercieel platform dat gebruikt kan worden om AR toepassingen op te ontwikkelen en wordt aangeboden als een SDK aan andere bedrijven. Zo heeft men een AR museum gids ontwikkeld voor het Louvre [Miyashita et al., 2008].

3.4 Bedrijven en consortia

15

Nog andere bedrijven zoals Intersense en ART spitsen zich toe op het ontwikkelen van tracking hardware. Intersense is bekend om zijn Inertia inertiaalsensoren en ART biedt een robuust tracking systeem aan op basis van speciale targets en infraroodcameras. Deze systemen worden naast augmented reality ook gebruikt in andere toepassingen zoals robotica of motion capture.

WARGAME

16

Hoofdstuk 4

WARGame In dit hoofdstuk leggen we kort uit wat we onder het concept van WARGame verstaan en wat onze doelstellingen ermee zijn. Vervolgens onderzoeken we kort welke andere Augmented reality games er nog bestaan en hoe ze de interactie met de gebruiker aanpakken. Als laatste geven we een overzicht van alle componenten die er nodig zijn om onze doelstelling met WARGame te behalen.

4.1

Wat is WARGame?

WARGame staat voor Wearable Augmented Reality Game. We hebben deze naam zo gekozen omdat het een spel moet zijn waarbij de spelers vrij kunnen rondlopen met een draagbare setup terwijl ze met augmented reality-elementen kunnen interageren. Het doel is om een first-person shooter (FPS) ervaring te creëren tussen twee spelers in de reële wereld. Het moet dus mogelijk zijn om de omgeving te zien net zoals men gewoon vrij zou rondlopen, maar anderzijds moet men ook virtuele elementen kunnen zien die afhankelijk zijn van de toestand van het spel. De spelers moeten elkaar kunnen herkennen en op elkaar kunnen richten en schieten. Een waarschuwing moet worden gegeven wanneer een vijandelijke speler in de buurt is. Het richten en schieten moet gebeuren met een input device dat dit zo eenvoudig mogelijk maakt. Als gameplay concept hebben we gekozen voor een Capture The Flag spel. Iedere speler heeft zijn/haar eigen kamp met zijn/haar eigen vlag. De bedoeling is om de vlag van de tegenstander te veroveren en naar het eigen kamp te brengen waarmee er punten kunnen gescoord worden. Dit kan enkel als de eigen vlag nog in het kamp staat. Als dit niet het geval is, moet de tegenstander – die jouw

4.2 Augmented reality games

17

vlag bezit – gedood worden waardoor de vlag terug in het eigen kamp komt. Om het spel wat uitdagender te maken, hebben we een aantal virtuele items toegevoegd die invloed hebben op de capaciteiten van de speler. Een aantal voorbeelden zijn meer kogels, een krachtiger wapen of meer leven. Er is dus nood aan een manier om deze virtuele items te integreren in de reële wereld en te presenteren aan de spelers.

4.2

Augmented reality games

Het idee van virtuele objecten in de realiteit is een schitterend concept voor computerspellen. Het breekt met de speler die achter zijn scherm een fantasiewereld doorkruist en maakt de reële wereld tot de wereld waarin het spel zich afspeelt. Het is dan ook niet verwonderlijk dat er reeds heel wat onderzoek is verricht naar augmented reality gaming. Een eerste klasse van augmented reality spellen zijn bordspellen. Hierbij bestaat het bord uit een mix van echte en virtuele objecten. De spelers kijken naar het bord door een HMD of een smartphone. Zo is er The Invisible Train [Wagner et al., 2006] waar de speler met een PDA een virtuele trein over een houten spoorlijn laat rijden. De speler kan de snelheid van de trein aanpassen en de wissels van de sporen controleren. In [Cooper et al., 2004] wordt een volledig virtueel chinees schaakspel op de tafel geplaatst.

(a) The Invisible Train

(b) Monkey Bridge

Figuur 4.1: Augmented reality bordspellen met The Invisible Train (links) en Monkeybridge (rechts)

[Lee et al., 2005] maakt gebruik van een setup met een glazen tafel en spiegel om virtuele objecten te voorschijn te toveren. Markers worden aan de onderkant van spelkaarten bevestigd en kunnen in de spiegel door een camera gedetecteerd worden, terwijl ze niet zichtbaar zijn voor de


18

spelers. Monkey bridge laat de spelers een brug bouwen waarover virtuele apen van het ene punt naar het andere kunnen wandelen [Barakonyi et al., 2005]. Oda et al. ontwikkelden een racespel waarbij de spelers hun auto door de augmented reality omgeving sturen [Oda et al., 2007]. Een stap verder zijn de spelletjes waar de speler zich effectief in de spelruimte bevindt, maar nog niet volledig vrij kan rondlopen. Voorbeelden hiervan zijn AR Bowling waar de speler met een echte bal virtuele kegels kan omgooien [Matysczok et al., 2004] of AR ping-pong waar de rackets getracked worden en er met een virtuele bal wordt gespeeld [Knoerlein et al., 2007].

(a) AR Bowling

(b) AR Ping pong

Figuur 4.2: Meer actieve Augmented reality spellen zoals bowling of ping pong.

De meest bekende vorm van augmented reality gaming is ongetwijfeld EyeToy van Sony. Deze spellen gebruiken een USB camera met microfoon als input voor de Playstation 2 console van Sony. De speler ziet zichzelf op het scherm samen met virtuele objecten. Om de speler te laten interageren met de objecten, wordt gebruik gemaakt van bewegings- en geluidsdetectie, kleurherkenning of gezichtsdetectie. Voorbeelden van zo’n spelletjes zijn Pom Pom Party of Kinetic Combat (zie figuur 4.3 ). Nog meer tot de verbeelding sprekend zijn de augmented reality spellen waarbij de speler vrij kan rondlopen in een spelomgeving en kan interageren met allerlei virtuele objecten. De speler draagt dan meestal een computer met zich mee op de rug. Voorbeelden van dit type spel zijn Human Pac-Man [Cheok et al., 2003], NetAttack [Lindt and Broll, 2004] en ARQuake [Piekarski and Thomas, 2002a]. Human Pac-Man is een variant op het klassieke Pac-Man arcade spel. Eén van de spelers is Pac-Man en moet virtuele koekjes verzamelen die verspreid liggen in de omgeving. De andere speler is het spook dat moet proberen Pac-Man te vangen. Human Pac-Man bestaat uit een


(a) Pom Pom Party

19

(b) EyeToy: Kinetic Combat

Figuur 4.3: Met EyeToy heeft Sony al augmented reality games op de Playstation. Links: de speler moet met felgekleurde pomponnetjes de aangeduide bewegingen nadoen. Rechts: Kinetic Combat laat de speler het opnemen tegen virtuele tegenstanders.

centraal server systeem en draagbare client systemen. De communicatie tussen clients en server gebeurt via een Wi-Fi netwerk. Het gebruikt GPS voor locatiebepaling en is dus bedoeld om buiten te spelen. De positie van het hoofd van de spelers wordt gemeten met inertiaalsensoren in een helm en speciale sensoren detecteren of de spelers elkaar aanraken. NetAttack wordt gespeeld tussen twee teams van twee personen. Elk team bestaat uit een speler met een laptop, stereoscopische HMD, GPS en oriëntatiesensoren die in de spelomgeving verschillende objecten moet zoeken. De andere speler volgt van binnenuit op een computerscherm en kan zijn teamgenoot tips geven en coachen. Er wordt gebruik gemaakt van grote markers om virtuele objecten voor te stellen.

(a) Human Pac-Man

(b) NetAttack

Figuur 4.4: De meest tot de verbeelding sprekende AR games zijn ongetwijfeld diegene waar de speler vrij rondwandelt in een augmented reality spelomgeving.

4.3 WARGame setup

20

ARQuake tot slot is een FPS waarbij virtuele vijanden en items in de realiteit worden geplaatst. De speler heeft naast GPS en oriëntatiesensoren ook een input device waarmee hij kan schieten. Het is volledig gebaseerd op de code van het bekende Quake spel. Van alle AR spellen leunt dit het dichtst aan bij WARGame. Bij ARQuake zijn de vijanden wel virtueel, terwijl WARGame gedistribueerd is en gespeeld wordt tegen menselijke tegenstanders.

Figuur 4.5: ARQuake leunt qua concept het dichtst aan bij WARGame, maar is niet gedistribueerd. Links ziet u het beeld in het spel, rechts de hardware setup die de speler draagt.

4.3

WARGame setup

Om alle functionaliteit en de volledige ervaring te kunnen aanbieden die WARGame belooft, hebben we een behoorlijk uitgebreide setup nodig. Alle benodigde componenten zijn te zien op figuur 4.6. De hardware setup van WARGame bestaat uit een video see-through configuratie zoals beschreven in hoofdstuk 3.1.2. We gebruiken een webcam die gemonteerd is op een helm die de ruimte rondom de speler vastlegt. Deze beelden worden naar een laptop doorgestuurd die de beelden verwerkt en het resultaat op zijn beurt doorstuurt naar een head-mounted display (HMD). Deze HMD zet men op als een gewone bril samen met de oortjes aan de HMD die voor het geluid moeten zorgen. Om de conversie van het VGA-signaal naar een geschikt PAL-formaat te voorzien, maken we gebruik van een converter die we tussen de laptop en de HMD plaatsen. Om interactie met de speler mogelijk te maken, gebruiken we een Wii Remote die we in een Wii Gun plaatsen. Zo lijkt het net alsof je met een echt geweer kunt rondlopen en schieten. Met de Wii Remote kan de speler de cursor op het scherm besturen en andere acties uitvoeren zoals schieten, herladen, scores opvragen, ... De Wii Remote is draadloos verbonden via bluetooth

4.3 WARGame setup

21

met de laptop. Alle hardware componenten (webcam, converter, HMD, bluetooth-dongle en geluidskabel) komen samen en worden aangestuurd door een draagbare computer waarop onze software draait. We stoppen dit allemaal in een normale rugzak die de speler moet aantrekken zodat de bewegingsvrijheid toch groot blijft. Enkel de webcam en de HMD zijn dan nog via een kabel met de laptop in de rugzak verbonden, de Wii Remote is immers draadloos. Een ander zeer belangrijk onderdeel van de WARGame setup is het gebruik van een gekleurd truitje om de spelerdetectie mogelijk te maken. We hebben gekozen voor fluorescerend geel en oranje truitjes die de speler over de rugzak kan aantrekken zodat de detectie ook op de achterkant van de speler optimaal blijft.

Figuur 4.6: De setup van WARGame

IMPLEMENTATIE

22

Hoofdstuk 5

Implementatie In dit hoofstuk geven we een overzicht van de volledige implementatie van WARGame. We beginnen met het verantwoorden van een aantal high-level ontwerpbeslissingen. Daarna geven we een kort overzicht van de softwareplatformen en -bibliotheken waar we gebruik van maken en op welke manier we deze integreren. Vervolgens presenteren we de architectuur van WARGame en geven we een uitgebreide beschrijving van de verschillende modules en algoritmes die nodig zijn om alles succesvol te implementeren.

5.1

Ontwerpbeslissingen

Om tot het concept van WARGame te komen, zijn er een aantal beslissingen die we hebben moeten nemen in het begin van de ontwerpfase. Een eerste belangrijke beslissing betreft het integreren van de augmented reality-elementen in het spel. Dit kan gebeuren met of zonder markers, waarbij beide methodes voor- en nadelen hebben. Een tweede aspect betreft de gedistribueerde kant van het spel: we kunnen dit implementeren op basis van een client-server model of door peer-to-peer te werken. Een laatste beslissing gaat over de hardware setup van de speler. Dit kan gaan om een thin client met een server back-end ofwel een thick client die alles integreert. Hierna volgt wat meer uitleg over deze afwegingen en de keuzes die we uiteindelijk gemaakt hebben.

5.1 Ontwerpbeslissingen

5.1.1

23

Marker-based versus marker-less

Zoals reeds aangehaald is het grootste probleem bij augmented reality de registratie van de 3D wereld. We hebben reeds verscheidene tracking technieken besproken in onze state of the art en moesten een keuze maken voor onze applicatie. Omdat we niet beschikken over een heel arsenaal aan sensoren beperken we ons tot de vision-based technieken. De belangrijkste keuze die we dan moeten maken is of we gebruik maken van markers of niet. Het gebruik van markers heeft heel wat voordelen. Eerst en vooral zijn er vele open source bibliotheken vrij beschikbaar voor marker gebaseerde tracking. Het is vrij nauwkeurig en vergt weinig rekenkracht. Het grootste nadeel is natuurlijk dat er markers aangebracht moeten worden. Daarnaast is het gebruik van markers steeds meer verleden tijd en richt huidig onderzoek zich vooral op technieken zonder markers. Marker-less technieken zijn een hot topic in de augmented reality wereld maar hebben vaak nog tal van nadelen. Technieken die gebruik maken van randdetectie of op zoek gaan naar herkenbare features hebben als grote nadeel dat er voorkennis van de omgeving nodig is en er voldoende herkenbare randen en/of texturen aanwezig moeten zijn. Methoden die geen voorkennis vereisen zoals SLAM of andere structure-from-motion gebaseerde technieken zijn vaak onderhevig aan drift. Dit is wanneer vele kleine fouten zich opstapelen en uiteindelijk leiden tot een waarneembare fout. Bovendien falen deze methoden ook bij snelle camerabeweging. In onze toepassing is de camera gemonteerd op het hoofd van de gebruiker. Deze bevindt zich in een actiespel dus snelle camerabewegingen zijn zeker niet uitgesloten. Hoewel bijna alle technieken gebaseerd op camerabeelden falen door veel motion blur, is het wel belangrijk dat het systeem goed herstelt eens de camera weer langzaam beweegt. Voor onze applicatie is het ook minder kritisch om markers te vermijden dan bijvoorbeeld in een industriële of medische applicatie. Integendeel, juist omdat de spelers weten dat er een interessant item te vinden valt in de buurt van de markers zullen ze automatisch de camera stil houden om het item te kunnen zien en er mee te interageren. Voor onze applicatie is het gebruik van markers dus zeker te verantwoorden. De huidige status van marker-less tracking technieken is nog niet matuur genoeg om aan al onze eisen te voldoen. Recente ontwikkelingen boeken echter wel steeds meer vooruitgang en naar de toekomst toe zal er zeker potentieel inzitten voor applicaties. Zeker wanneer ze gebruikt worden in hybride technieken waarbij inertiaalsensoren gebruikt worden om het falen bij snelle camerabeweging op

5.1 Ontwerpbeslissingen

24

te vangen.

5.1.2

Client-server versus peer-to-peer

Om de verschillende clients met elkaar te laten communiceren hebben we de keuze tussen het client-server model of het peer-to-peer model. Bij het client-server model fungeert één computer als server waarmee alle clients een verbinding maken. De server zorgt voor afhandeling van alle communicatie. Alles blijft dus gecentraliseerd, wat als gevolg heeft dat de server de bottleneck kan vormen voor het programma. In het peer-to-peer model worden alle computers als gelijken (peers) behandeld en moeten ze onderling maar zorgen dat de communicatie vlot verloopt. Het peer-to-peer model kent een groot succes voor toepassingen zoals distributie van omvangrijke bestanden. Voor games is het echter gemakkelijk als alle spelinformatie centraal verwerkt wordt. Wij gebruiken dus het client-server model dat in bijna alle online games zijn nut al bewezen heeft.

5.1.3

Thick client versus thin client

De dag van vandaag zijn thin clients populair. Concepten als “cloud computing” en “software as a service” worden door veel bedrijven als de toekomst gezien. In plaats van iedereen een computer te geven wordt alles door een server afgehandeld en gebruikt iedereen enkel nog een access terminal. De grootste voordelen die naar voor geschoven worden zijn dat het veel goedkoper is, makkelijker is om het softwareplatform te onderhouden en los staat van de locatie van de eindgebruiker. Desondanks is dit voor onze toepassing niet haalbaar. Aangezien bij ons de inputs niet bestaan uit toetsenbord- en muisevents, maar spelevents, Wii input, locatie-informatie en realtime video is al veel bandbreedte vereist om dit over het netwerk naar een server te sturen. Bovendien moet deze server er dan nog in slagen om al deze informatie te verwerken en het resultaat terug te sturen binnen een acceptabele tijdsmarge om realtime operatie mogelijk te maken. Het argument dat thin clients goedkoper zijn vergaat ook in het niets als je weet dat input devices zoals een HMD, inertiaalsensoren, of andere tracking devices doorgaans duurder zijn dan de computer die nodig is om alles te verwerken. Bovendien worden CPUs steeds goedkoper en krachtiger, waardoor een hedendaagse smartphone al bijna als thick client kan fungeren.

5.2 Software platform en bibliotheken

5.2

25

Software platform en bibliotheken

Er bestaan al heel wat oplossingen voor zaken die we nodig hebben in WARGame, zoals het renderen van 3D objecten, de tracking van en interactie met externe devices, het gebruik van realtime videobeelden, netwerkintegratie, audio-integratie, ... Het zou onmogelijk en onverstandig zijn om dit allemaal vanaf nul zelf te schrijven, dus hebben we zo goed mogelijk gebruik gemaakt van bestaande software platformen en bibliotheken die dit voor ons doen. Hierna volgt een overzicht van de gebruikte componenten.

5.2.1

Studierstube

Als basisplatform voor WARGame hebben we gekozen voor het Studierstube onderzoeksproject [Schmalstieg et al., 2000]. Dit framework heeft zijn diensten al bewezen in tal van applicaties [Schall et al., 2008] [Sareika and Schmalstieg, 2007] [Kaufmann, 2003] en is goed getest. Daarnaast is het erg modulair opgebouwd en dus makkelijk uitbreidbaar en biedt het reeds vele features die nuttig voor ons zijn. Door de integratie van ARToolkit+ voorziet het marker tracking, OpenTracker [Reitmayr and Schmalstieg, 2001] biedt een device abstractielaag met interfaces voor bijvoorbeeld de Wii Remote en OpenInventor geeft ons een high level interface om 3D modellen in te brengen. Dit alles maakt het uitgebreider dan bijvoorbeeld OSGART [Looser et al., 2006] of DWARF [Bauer et al., 2001]. Een andere doorslaggevende factor is het feit dat het open source is en vrij te gebruiken voor onderzoeksdoeleinden. Dit geeft het een meerwaarde op het Tinmithproject [Piekarski and Thomas, 2002b] of commerciële oplossingen zoals Unifeye of Virtools. Het meer op games gerichte framework Goblin XNA [Oda et al., 2007] was nog niet beschikbaar toen wij onze keuze maakten. Om inzicht te krijgen in onze applicatie is het nodig om vertrouwd te zijn met de architectuur en concepten van Studierstube. Hieronder volgt een kort overzicht, een meer uitgebreide beschrijving is te lezen in [Reitmayr, 2004]. Open Inventor Open Inventor is een bibliotheek die zorgt voor het renderen van 3D objecten. De scene in de ruimte wordt voorgesteld door een zogenaamde scenegraph. Dit is een boomstructuur bestaande uit verschillende soorten knopen. Een knoop is het basistype in Open Inventor en bijna alle andere klassen erven hiervan over. Knopen bestaan uit een aantal velden die waarden bevatten


26

zoals tekst, integer of floating point getallen, vectoren etc. Om de boomstructuur op te bouwen is er een speciaal type knoop, de SoGroup knoop, die een lijst bijhoudt naar kindknopen. De scenegraph wordt recursief overlopen door acties die elk een bepaalde methode van de knoop triggeren. De belangrijkste actie is waarschijnlijk de GLRenderAction, die de knopen overloopt en rendert. Door een functie te registreren om opgeroepen te worden bij een bepaalde actie kan een knoop zijn gedrag bepalen. Naast de acties is er nog een ander mechanisme om de scenegraph te benaderen. Verschillende velden van knopen kunnen onderling geconnecteerd worden om zo updates te krijgen van elkaar. Op die manier kunnen de velden onderling een eigen data flow netwerk vormen. Daarenboven is er nog een speciale klasse van objecten, de engines, die deze update events kunnen verwerken en nieuwe waarden berekenen voor de update van de geconnecteerde velden. Deze objecten maken echter geen deel uit van de scenegraph, enkel van de graaf van velden. Via de Open Inventor API kan men zelf knopen, engines, acties etc. aanmaken. Het Studierstube framework bestaat grotendeels uit een verzameling Open Inventor componenten: knopen die een videostroom weergeven, engines die data van andere componenten in de scenegraph sturen enzovoort. Open Inventor biedt ook de mogelijkheid om de hele scene te serialiseren en op te slaan in ASCII formaat. Zo’n bestand kan ook opnieuw ingelezen worden. Op die manier kunnen nieuwe componenten toegevoegd worden aan de scenegraph zonder dat hercompilatie nodig is. Meer informatie over het gebruiken en uitbreiden van Open Inventor kan gevonden worden in “The inventor mentor” [Wernecke, 1993] en “The inventor toolmaker” [Wernecke, 1994]. OpenTracker OpenTracker [Reitmayr and Schmalstieg, 2001] zorgt voor een abstractielaag voor alle tracking devices en verwerking van de gegenereerde tracking data. Het framework is geheel opgebouwd volgens het pipe-and-filter pattern. Er wordt een gerichte graafstructuur opgebouwd van verschillende knopen. Er zijn 3 soorten knopen: • Als eerste zijn er de source- of bronknopen. Deze communiceren met het device en pushen de data naar hun opvolgers in de OpenTracker graaf. Een voorbeeld is de WiiSource die gegevens van de Wii Remote in de graaf pusht. • Vervolgens zijn er sink- of eindknopen. Deze zijn de punten waar data de graaf verlaat


(a) Scenegraph diagram

27

(b) Render

Figuur 5.1: Links: de scenegraph diagram dat een watermolecule voorstelt. Rechts: de 3D weergave van de molecule

en naar andere modules worden gestuurd. Zo is er bijvoorbeeld een EventSink die de binnenkomende data doorstuurt naar Open Inventor engines. • Tussenin bevinden zich de filterknopen. Deze kunnen de data verwerken en eventueel

gewijzigd doorsturen. Ze kunnen ook gegevens van verschillende knopen combineren en doorsturen. Het eenvoudigste voorbeeld van een filterknoop is er één die de binnenkomende gegevens enkel doorstuurt als er voldaan wordt aan een bepaald criterium.

De hele configuratie van de OpenTracker graaf gebeurt door middel van een XML bestand. Op die manier is het eenvoudig om nieuwe tracking informatie op te nemen en te verwerken. Men kan ook eigen knopen definiëren voor eigen data verwerking of om te interageren met nieuwe devices of modules. Zoals reeds gezegd voorziet OpenTracker in interfaces voor tal van devices en modules. Zo kan het interfacen met tracking devices zoals inertiaalsensoren van Intersense of GPS toestellen, maar ook met traditionele input devices zoals een muis of toetsenbord en met andere software modules zoals ARToolkitPlus. OpenVideo Naast sensoren worden ook vaak videobeelden gebruikt als input, bijvoorbeeld voor het detecteren van barcodes. Voor een video see-through setup is video al helemaal onontbeerlijk. Om overweg te kunnen met verschillende webcams op verschillende platformen is er OpenVideo. Dit zorgt voor een abstractie van de camera en zorgt ervoor dat de videoframes naar de juiste componenten kunnen gestuurd worden.

5.3 Architectuur

28

Studierstube kernel De kernel vormt de lijm tussen al deze componenten. Ook de kernel wordt geconfigureerd door een XML bestand waar bepaald wordt welke componenten gebruikt moeten worden. Hier wordt ook de applicatiespecifieke data bij het Studierstube framework gelinkt door middel van een Dynamic Link Library (DLL).

5.2.2

ACE

ACE staat voor de Adaptive Communication Environment en is een cross-platform C++ framework voor verschillende communicatietaken. Het is volgens de gangbare objectgeoriënteerde design patterns opgebouwd en biedt klassen voor communicatie over TCP/UDP, event handling, threading en nog veel meer. ACE is vrij beschikbaar onder een open soure license, maar wordt wel gesteund door verschillende bedrijven.

5.2.3

OpenCV

OpenCV is een bibliotheek voor Computer Vision die oorspronkelijk ontwikkeld is door Intel. Deze cross-platform C/C++ bibliotheek legt de focus op real-time beeldverwerking en is open source verkrijgbaar onder een BSD license. OpenCV implementeert tal van algoritmen in domeinen als gezichtsherkenning, human computer interface (HCI), segmentatie, stereopsis en structure from motion (SFM). Een goed boek over OpenCV is [Bradski and Kaehler, 2008]

5.2.4

FMOD

FMOD is de belangerijkste bibliotheek voor afspelen van audio. Het wordt enorm veel gebruikt in de games industry zowel voor pc als console. Het is vrij beschikbaar voor niet-commerciële applicaties.

5.3

Architectuur

Onze applicatie bouwt verder op het Studierstube platform en dus is ook onze architectuur een uitbreiding op dat platform.

5.3 Architectuur

Figuur 5.2: De architectuur van WARGame gebouwd op het Studierstube platform

29

5.4 Virtuele objecten met ARToolKitPlus

30

De implementatie bestaat vooral uit het configureren van reeds bestaande OpenTracker modules zoals de Wii input module en de ARToolKitPlus module en het toevoegen van eigen modules zoals de VideoAnalyzer, LocationTracker en de GameEngine. Al deze modules zullen gegevens in OpenTracker pushen, die door het Studierstube event systeem uiteindelijk onze data in de Application DLL zullen aansturen. Daarnaast is er nog de GameServer, die communiceert met de GameEngine modules van alle spelers. In wat volgt gaan we dieper in op de configuratie en ontwikkeling van de verschillende modules en hoe ze met elkaar interageren.

5.4 5.4.1

Virtuele objecten met ARToolKitPlus ARToolkitPlus

Voor het samenvoegen van virtuele objecten met de realiteit hebben we gekozen voor een marker gebaseerde aanpak. We gebruiken de ARToolKitPlus bibliotheek [Wagner and Schmalstieg, 2007] die vervat zit in het Studierstube project. Deze werd speciaal ontwikkeld voor mobiele telefoons, wat ervoor zorgt dat we ons weinig zorgen moeten maken qua performantie. We bespreken kort de methode van marker gebaseerde tracking.

Figuur 5.3: De verschillende stappen voor augmented reality op basis van markers zoals toegepast in ARToolkit en consoorten [Kato and Billinghurst, 1999] Alles begint bij het detecteren van de markers. In een eerste stap worden het videoframe omgezet naar een zwart/wit bitmap. Om te kunnen omgaan met verschillen in omgevingslicht


31

werkt ARToolKitPlus met een heuristiek om de beste threshold te bepalen. Eens de bitmap gegenereerd is worden hierin vierhoeken ge¨ıdentificeerd. Na het verwijderen van te grote of te kleine vierhoeken zijn de mogelijke markers gevonden. Vervolgens wordt het binnenste van elke vierhoek geanalyseerd om te weten te komen welke marker in beeld komt. Dit kan door simpele template matching of door het gebruiken van geëncodeerde id’s. Dat laatste werkt beter aangezien bij het encoderen error-correctie kan gebruikt worden. Wij gebruiken 9 bit codes geëncodeerd in een 6x6 array. De 9 bits worden 4 maal herhaald en door elkaar gehaald met een XOR masker. Dit geeft ons 512 verschillende markers die robuust gedetecteerd kunnen worden.

Figuur 5.4: De gebruikte markers: de 9 bit code wordt geëncodeerd in een 6x6 array Als laatste stap moet nog de positie en oriëntatie van de marker ten opzichte van de camera geschat worden (of de positie en oriëntatie van de camera ten opzichte van de marker). Eens we dat weten kunnen we een virtueel object op de plaats van de marker laten verschijnen. Hiervoor gebruikt ARToolkitPlus een C++ implementatie van het algoritme van Schweighofer [Schweighofer, 2006]. Hiermee is echter de kous nog niet af. Om pixelposities in een frame correct te laten overeenstemmen met posities uit de ruimte en omgekeerd moet men ook rekening houden met de intrinsieke parameters van de camera. Daarom bespreken we in wat volgt het gebruikte cameramodel en hoe we de intrinsieke parameters van onze camera kunnen schatten.

5.4.2

Cameramodel

We vertrekken van het ideale pinhole cameramodel. Om een beeld te vormen moet eerst een punt O gekozen worden, het centrum van de projectie en een projectievlak B. Een willekeurig punt Q in de ruimte wordt dan afgebeeld op B door het snijpunt van B met de rechte OQ. Kiezen we ons assenstelsel zodanig dat het centrum van projectie O samenvalt met de oorsprong en het projectievlak B parallel is met het XY -vlak, dan wordt onze camera volledig bepaald door één parameter: f , de zogenaamde focale lengte. De rechte door het centrum van projectie


32

en loodrecht op het projectievlak noemen we de optische as.

Figuur 5.5: Het punt Q = (X, Y, Z) wordt geprojecteerd op het projectievlak resulterend in het punt q = (x, y, f ) We vinden dus x=f

X Z

y=f

Y Z

(5.1)

Deze co¨ ordinaten stemmen wel nog niet overeen met de pixel coördinaten van de beelden van onze camera. Bij een CCD camera zal de vorm van de pixels een rol spelen alsook de positie van de CCD chip. Een punt Q = (X, Y, Z) zal dan als volgt op het scherm geprojecteerd worden op pixel co¨ ordinaten (xscherm , yscherm ). xscherm = fx

X + cx Z

yscherm = fy

Y + cy Z

(5.2)

Omdat het praktisch onmogelijk is het centrum van de chip perfect op de optische as te hebben is er steeds een verplaatsing die gemodelleerd wordt door cx en cy . Daarnaast zijn de pixels op de CCD niet perfect vierkante, maar eerder rechthoekig. Daardoor krijgen we twee verschillende focale lengten fx en fy . De focale lengte fx is dan gelijk aan de fysische focale lengte f gedeeld door de breedte van een pixel px . Analoog voor fy . In matrixnotatie krijgen we dan      x fx 0 cx X           λ y  =  0 fy cy   Y       1 0 0 1 Z

(5.3)


33

waarbij de gelijkheid geldt op een schaalfactor λ na. Dit is intu¨ıtief in te zien door het feit dat men uitgaande van een beeld nooit de ware grootte kan weten van de voorgestelde objecten zonder voorkennis. De 3x3 matrix met de parameters fx , fy , cx en cy is de intrinsieke camera matrix zoals ook beschreven in [Heikkila and Silven, 1997]. Nu hebben we een wiskundig model voor een pinhole camera. Om echter voldoende lichtstralen te laten invallen op de CCD wordt een lens gebruikt. Hoewel het in theorie mogelijk is een perfecte lens te ontwerpen, is het in praktijk onmogelijk en treden er bijkomende distorties op. De voornaamste zijn de radiale en de tangentiële distorties. Radiale distorties worden veroorzaakt door lichtstralen aan de rand van de lens die teveel worden afgebogen. Tangentiële distorties zijn dan weer te wijten aan het feit dat de lens niet perfect parallel staat met de CCD chip. Deze distorties worden gemodelleerd met nog eens 5 parameters volgens [Brown, 1971] en [Fryer and Brown, 1986]. In ons geval hebben we te maken met een vast object (de marker) en een bewegende camera. Om nu het verband te kennen tussen een beeldpunt p = (x, y) en een punt in het object coördinatenstelsel P = (X, Y, Z) moeten we eerst een coördinatentransformatie uitvoeren die de coördinaten van P geeft in het assenstelsel van de camera. Deze transformatie wordt bepaald door een 3x3 rotatiematrix R en een translatievector t.

Figuur 5.6: Om over te gaan van het objectcoördinatenstelsel naar het cameracoördinatenstelsel wordt een rotatie en translatie van het assenstelsel uitgevoerd In matrixnotatie geeft dit

λq = K[R|t]Q

(5.4)


34

waar K de intrinsieke matrix voorstelt en [R|t] de camera pose is. De 3x4 matrix P = K[R|t] wordt ook de projectiematrix genoemd en geeft het verband weer tussen een punt in het object assenstelsel en zijn corresponderende beeldpunt. De meeste tracking applicaties gaan er van uit dat de intrinsieke parameters gekend zijn en schatten op basis van de beelden de camera pose.

5.4.3

Camera kalibratie

Om de intrinsieke camera parameters te bepalen vertrekken we van een kalibratie object. Van dit object kennen we van verschillende punten hun coördinaten in het object assenstelsel. Als we de corresponderende punten vinden in het beeld dan kunnen we hun verband uitdrukken via de projectiematrix. Op die manier kunnen we dan de waarden van de projectiematrix en dus de intrinsieke parameters en camera pose, schatten. Om onze camera te kalibreren gebruikten we de vrij beschikbare Camera Calibration Toolbox for Matlab [Bouguet, 2008], een implementatie gebaseerd op [Zhang, 1999]. Als kalibratie object wordt een schaakbordpatroon gebruikt (zie figuur 5.7). In een eerste stap worden de hoekpunten gedetecteerd. Lensdistorties kunnen worden geschat uitgaande van het feit dat de uiterste hoekpunten op twee rechten liggen die loodrecht op elkaar staan. Met 4 intrinsieke parameters en de 6 ( 3 rotatiehoeken en 3 componenten van de translatievector) externe parameters moeten er nog 10 parameters geschat worden. Het omvormen van een vierkant in het object assenstelsel naar een willekeurige vierhoek op het beeld levert ons 8 vergelijkingen op (4 (x,y) correspondenties). We hebben dus nog 2 vergelijkingen te kort. Een tweede beeld genomen vanuit een ander standpunt geeft ons 6 nieuwe onbekenden van de camera pose, maar ook 8 vergelijkingen. Met twee beelden hebben we dus voldoende om de parameters te schatten. Voor de nauwkeurigheid van de schatting is het echter beter om meerdere afbeeldingen in rekening te brengen.

Figuur 5.7: Voor de kalibratie worden afbeeldingen genomen van een schaakbordpatroon.


5.4.4

35

Spelobjecten

Wij gebruiken ARToolkitPlus om virtuele spelobjecten aan de realiteit toe te voegen. Wij hebben verschillende spelobjecten ge¨ımplementeerd waaronder een healthpack, ammopack, power-up en vlag.

(a) Healthpack

(b) Ammopack

(c) Power-up

(d) Vlag

Figuur 5.8: De verschillende spelobjecten in WARGame.

Wanneer de speler geraakt wordt door vijandige kogels daalt zijn health. Bij de start heeft de speler 100 health en wanneer deze 0 bereikt is de speler dood. Om tijdens het spel zijn health op te krikken kan de speler een healthpack zoeken. Hij kan het healthpack nemen door er vanaf een kleine afstand naar te kijken. Eens opgepikt zal de healthpack op die locatie verdwijnen voor een bepaalde tijdspanne. De verschillende spelers hebben uiteraard geen oneindig arsenaal aan kogels. Wanneer zijn kogels dreigen uitgeput te geraken kan de speler op zoek gaan naar een ammopack. Net als het healthpack kan de ammopack opgepikt worden door er van dichtbij naar te kijken. Eens opgepikt zal de ammopack op die locatie verdwijnen voor een bepaalde tijdspanne. Door power-up’s te verzamelen kan de speler de kracht van zijn geweer laten verhogen. Hierdoor zal hij meer healthpoints van zijn tegenstrever afsnoepen indien hij deze raakt. Naarmate de speler schiet zal de kracht van zijn geweer weer afnemen. De huidige kracht van het geweer wordt weergegeven door het aantal brandende LEDs op de Wii Remote. Ook de power-up verdwijnt voor een tijdje nadat hij door een speler is opgepikt. De vlag is de thuisbasis van de speler. Elk team heeft zijn eigen vlag. Het is de bedoeling om in het vijandig kamp door te dringen, daar de vijand zijn vlag op te pikken en deze dan naar jouw eigen kamp met vlag terug te brengen. De tegenstrever kan een gestolen vlag terugkrijgen door degene die de vlag draagt neer te schieten.

5.5 Wii input

36

Door in de spelomgeving de markers te plaatsen, zullen voor de speler op die plek onze objecten verschijnen.

Figuur 5.9: De powerup (links) en vlag (rechts) zoals de speler ze in het spel ziet.

5.5

Wii input

In een augmented reality applicatie waar de gebruiker vrij is om te bewegen in de ruimte schieten traditionele input devices zoals toetsenbord of muis tekort. Anderen probeerden dit probleem op te lossen door gebruik te maken van een augmented panel [Szalavári, 1999] , het tracken van speciale handschoenen [Thomas and Piekarski, 1993] of allerhande 3- en 6-DOF muizen en trackballs [Hand, 1997] [Goebel and Friesdorf, 2002]. De Wii Remote bevat 3 accelerometers die elk de versnelling meten door de gebruiker uitgeoefend op één van de drie assen. Dat wil zeggen dat in rust de controller een versnelling opwaarts zal rapporteren die de zwaartekracht tegenwerkt. In vrije val is de gerapporteerde versnelling nul. In de driedimensionale ruimte zijn er echter 6 vrijheidsgraden (3 rotaties en 3 translatiecomponenten) waardoor het met onze 3 gegevens onmogelijk is de volledige positie en oriëntatie van de Wii Remote in de ruimte te kennen. De Wii console lost dit probleem op door gebruik te maken van de sensor bar. Deze zendt infrarood licht uit dat opgevangen wordt door de infraroodcamera op de Wii Remote. Met deze extra informatie kan dan wel bepaald worden naar waar de Wii Remote gericht is. We kunnen onderstellen dat de Wii Remote slechts kleine acceleraties zal ondervinden ten gevolge van de beweging van de speler in vergelijking met diegene veroorzaakt door de zwaartekracht.

5.6 VideoAnalyzer

37

Figuur 5.10: De Wii Remote heeft 6 vrijheidsgraden (3 translaties in X-,Y-,Z-richting en 3 rotatiehoeken pitch, roll en yaw), maar geeft slechts de 3 waarden van acceleratie in de X-,Yen Z-richting Dat zorgt ervoor dat de sensoren ons meteen zeggen welke richting “boven” is en kunnen we de pitch en roll hoek berekenen. We weten echter niks over de yaw hoek, wat het moeilijk maakt om op een intuitieve manier een crosshair te bedienen. Daarom gebruiken we de roll hoek om de crosshair links of rechts te laten gaan. Na enige oefening is het zo mogelijk vrij nauwkeurig de crosshair te richten. De verschillende knoppen van de Wii Remote gebruiken we voor allerlei acties die de speler kan uitvoeren zoals schieten of herladen. Daarnaast kan hij ook een kaart van de omgeving op het scherm toveren of de scores weergeven. We geven de speler ook feedback via de LEDs en trilfunctie van de controller. Het aantal LEDs dat oplicht geeft de sterkte aan van zijn wapen en de Wii Remote geeft een trilling wanneer de speler geraakt wordt door een vijand.

5.6

VideoAnalyzer

Om WARGame te kunnen spelen is het vanzelfsprekend dat we in staat moeten zijn om de andere speler(s) te detecteren. Bovendien is het niet voldoende om te weten of de crosshair op een speler staat, maar we moeten ook weten om welke speler het gaat. We moeten dus de

5.6 VideoAnalyzer

38

gedetecteerde speler ook kunnen identificeren. Hiervoor gebruiken we felgekleurde truitjes die de spelers aantrekken. Op basis van de camerabeelden gaan we dan op zoek naar deze kleuren en dus potentiële spelers.

5.6.1

Kleurdetectie

Om de kleuren te herkennen zetten we de beelden eerst om van de RGB-kleurenruimte naar de HSV-kleurenruimte. Dit omdat pixels van eenzelfde kleurentint qua waarden wel ver uit elkaar kunnen liggen in de RGB-ruimte (bv. donker t.o.v. licht), maar in de HSV-ruimte allen eenzelfde H-waarde (Hue) hebben.

(a) RGB

(b) HSV

Figuur 5.11: Links: de RGB kleurenruimte. Rechts: de HSV kleurenruimte; kleuren met eenzelfde tint hebben eenzelfde Hue-waarde.

Om voor elke pixel van het beeld te bepalen of hij de kleur heeft van een truitje, verzamelen we vooraf enkele afbeeldingen van het desbetreffende truitje. De verschillende afbeeldingen worden genomen op verschillende plaatsen in de omgeving. Van al deze afbeeldingen wordt dan een 3-dimensionaal histogram berekend en genormaliseerd. Al deze histogrammen worden dan samengeteld en opnieuw genormaliseerd. Elke pixel wordt nu vervangen door de waarde die die (H,S,V)-waarde heeft in het histogram. Deze waarde kan gezien worden als de probabiliteit dat deze pixel voorkomt in het truitje. Een hoge waarde betekent immers dat deze kleur vaak voorkwam in de op voorhand genomen afbeeldingen van het truitje. Op die manier wordt een grijswaardebeeld gecreëerd waarbij de heldere pixels een hoge probabiliteit hebben om een speler voor te stellen.

5.6 VideoAnalyzer

39

(a) Input beeld

(b) Grijswaarden beeld

Figuur 5.12: Links: het input beeld. Rechts: het gegenereerde grijswaardenbeeld. Op beide afbeelding is ook de bounding box weergegeven berekend door het Camshift algoritme.

5.6.2

Camshift

Dit beeld gebruiken we dan als input voor het Camshift (Continuously Adaptive Mean Shift) algoritme [Allen et al., 2004], een variant op het Meanshift algoritme [Comaniciu et al., 2002]. Het Meanshift algoritme werkt als volgt: 1. Kies een zoekvenster van een bepaalde grootte op een bepaalde locatie. 2. Bereken het massamiddelpunt van de witte pixels in het zoekvenster. 3. Verplaats het midden van het zoekvenster naar het massamiddelpunt. 4. Ga terug naar stap 2 Op die manier zal het algoritme het zoekvenster verplaatsen naar plaatsen waar zich hoge concentraties witte pixels en dus mogelijk een speler bevindt. Het Camshift algoritme breidt het Meanshift algoritme uit voor goed gesegmenteerde beelden. Het past dan zodaning de grootte van het zoekvenster aan zodat dit overeenkomt met het te detecteren segment. Voor ons spelerdetectiealgoritme laten we de Camshift tracker los op ons zwart/wit beeld met als initiële grootte van het zoekvenster het ganse beeld. De gebruikte Camshift implementatie is deze uit OpenCV. Als er een speler in beeld is zal het zoekvenster vrij snel convergeren naar de speler. Indien niet dan zullen er vaak nog witte pixels optreden ten gevolge van ruis of objecten

5.6 VideoAnalyzer

40

Figuur 5.13: Het Meanshift algoritme in actie: het zoekvenster wordt verplaatst zodat het naar de locatie gaat met hoge concentratie punten. Bron: [Bradski and Kaehler, 2008]

5.6 VideoAnalyzer

41

waarin de te zoeken kleur ook voorkomt. Om deze niet te detecteren leggen we bijkomende grenzen op. Om een speler te kunnen zijn moet het gedetecteerde segment voldoende groot zijn en voor het grootste deel bestaan uit witte pixels. Indien dit niet het geval is laten we het zoekvenster weer vergroten. Uiteraard is dit geen 100% waterdichte methode. Indien er in de omgeving voldoende grote objecten zijn met dezelfde kleur als één van de truitjes zal dit object verkeerdelijk ook gedetecteerd worden als zijnde een speler. Aangezien er in een doorsnee omgeving niet al te veel grote fluo oranje of groene objecten voorkomen stelt dit probleem zich niet meteen. Wanneer dit toch het geval is moet men zelf ingrijpen in de omgeving. Andere oplossingen zouden misschien zijn om ook locatie-informatie te gebruiken om over het al dan niet detecteren van een speler te beslissen. Wanneer een andere speler gedetecteerd wordt, wordt dit aangeduid met een bounding box rond deze speler. Ook wordt zijn naam aangegeven en wordt een bijhorend geluid afgespeeld. Door met de crosshair binnen de bounding box te mikken kan op de tegenspeler geschoten worden.

Figuur 5.14: Wanneer er een speler gedetecteerd wordt, tekenen we een bounding box op het scherm samen met zijn naam.

5.7 Game engine

5.7

42

Game engine

De Game engine – de naam zegt het zelf – bevat alle spellogica. Deze module zorgt dat de binnenkomende events, hetzij van de input devices, hetzij via netwerkberichten, de nodige veranderingen aanbrengen in de toestand van de speler en deze informatie indien nodig over het netwerk verstuurd wordt. Daarnaast zorgt de Game engine ook dat de toestand van het spel en de speler via het Studierstube Event System wordt doorgestuurd naar OpenInventor. Dit zal dan de waarden van onze toestand invullen in de scenegraph en de correcte toestandsinformatie renderen op het scherm. Onderaan ziet de speler zijn health en aantal kogels, evenals de kleur van het vestje dat hij draagt. Bovenaan staat centraal de overblijvende tijd dat het spel nog duurt en links daarvan komen berichten over het spelverloop. In het midden verschijnen soms berichten die betrekking hebben op de connectie met de server.

Figuur 5.15: De speler kan zijn toestand steeds zien door middel van overlays op zijn beeld.

5.8 Game server

5.8

43

Game server

Onze server applicatie zorgt voor de registratie van de verschillende spelers en de communicatie tussen de verschillende clients. Voor de implementatie van het ontvangen en versturen van berichten wordt – zowel aan de client als aan de server zijde – gebruik gemaakt van de ACE bibliotheek. Aangezien bij het connecteren van de server het belangrijk is voor het verloop van het spel dat alle spelers hiervan correct op de hoogte gesteld worden en de juiste kleuren detecteren, gebeurt het registreren over TCP. Hoewel het trager is dan UDP geeft dit ons de zekerheid dat de verstuurde berichten wel degelijk aankomen. Voor ons protocol gebruiken we steeds eenzelfde structuur. Alle berichten zijn opgebouwd als command; arg1; arg2; ..., waarbij command een sleutelwoord is dat het type bericht aangeeft, gevolgd door de verschillende argumenten gescheiden door ;. De registratieprocedure gaat als volgt: 1. De client stuurt een bericht naar de server Register; P layer;, waarbij Register aangeeft dat hij wil registreren en P layer de naam is van de speler. 2. Bij ontvangst zal de server eerst opzoeken of er nog een kleur beschikbaar is om te detecteren. Indien dat het geval is slaat hij de speler, zijn naam, IP adres en toegekende kleur op. 3. De server laat de client weten dat het registreren succesvol gelukt is en deelt hem ook de kleur mee met het RegisterOK; colorID; bericht. 4. Daarna laat de server ook aan de spelers die op dat moment reeds geconnecteerd waren weten dat een nieuwe speler in het spel gekomen is en deze te herkennen is aan een bepaalde kleur. 5. Op dezelfde manier laat hij de client weten welke spelers er reeds aanwezig waren. Om te deregistreren stuurt de client een U nRegister bericht waardoor de server deze speler uit de lijst zal verwijderen en dit te kennen geven aan de andere spelers in het spel. Voor spelberichten wordt gekozen voor het snellere, maar minder betrouwbare UDP. Verstuurde spelberichten zijn bijvoorbeeld het oppikken van een item, het veroveren van een vlag, het

5.8 Game server

44

Figuur 5.16: Het protocol om te registreren en te deregistreren.

5.8 Game server

45

schieten naar een andere speler, enzovoort. Ook hier gebruiken we korte tekstberichten bestaande uit een sleutelwoord en argumenten gescheiden door ;. Bij wijze van voorbeeld geven we het protocol bij een schiet event. Als de speler mis schiet dan wordt er een shoot; bericht naar de server gestuurd wat wordt doorgestuurd naar de andere spelers samen met de naam van de speler die schoot. Wanneer de speler raak schiet dan gebeurt het volgende: 1. De client stuurt het bericht hit; colorID; naar de server met colorID de kleur die hij geraakt heeft. 2. De server identificeert de geraakte speler aan de hand van de kleur. 3. Naar de speler die geraakt is stuurt de server een hit; P layer; power; bericht, dat hem te kennen geeft welke speler hem geraakt heeft en hoeveel kracht er achter de kogel zit. 4. Naar de andere spelers wordt een shoot; P layer; bericht gestuurd dat hen enkel vertelt dat er ergens geschoten is. 5. De speler die geraakt is en het hit bericht van de server krijgt vermindert zijn health en als hij dood is stuurt hij een dead; Client2; P layer; bericht. Dit geeft aan dat speler Client2 gedood is door speler Player. 6. De server stuurt dit bericht door naar de andere clients die nu een melding krijgen van de dood van Client2. Naast het ontvangen en doorsturen van berichten is de server ook verantwoordelijk voor enkele spelelementen. Zo beslist de server wanneer een spel start en eindigt en stuurt elke 5 seconden een bericht uit met de resterende tijd. Dit is ook een manier voor de clients om te controleren of ze nog verbinding hebben met de server. De timer functionaliteit van de server wordt ook gebruikt om een opgepikt item te deactiveren en na een tijd weer een bericht te sturen naar iedereen als het item terug actief wordt. Tot slot houdt de server ook de scores bij van de verschillende clients. De clients kunnen deze opvragen door een score; bericht te sturen naar de server. Deze stuurt dan een bericht terug met de verschillende scores wat dan wordt weergegeven op het scherm.

5.9 LocationTracker

46

Figuur 5.17: Het protocol bij een schiet event.

5.9

LocationTracker

Het weten van de locatie van de speler opent de deur naar tal van nieuwe features. Zo kan er een kaart weergegeven worden waarbij de locatie van de speler aangeduid wordt. Er kunnen ook aanwijzingen gegeven worden aan de speler hoe hij naar een bepaalde plaats kan gaan. Tot nu toe kunnen we enkel de locatie schatten van de speler wanneer er een 2D marker in zicht is. Dit is een enorme beperking en in sommige omgevingen zelfs ontoelaatbaar. Wanneer we ten alle tijde de exacte locatie van de speler kunnen bepalen kunnen we evolueren naar augmented reality zonder 2D markers. Ook om meer interactie mogelijk te maken met virtuele voorwerpen of zelfs virtuele mede- of tegenspelers te creëren is nauwkeurige localisatie een absolute must. Daarom dat we ook hierrond enig onderzoek gedaan hebben. Ons doel was om in WARGame een kaart te voorzien waarop de speler de locatie van de verschillende items en spelers kan zien. Dit alweer met beperkte middelen, want we beschikken niet over GPS toestellen, inertiaalsensoren of infraroodtrackers.

5.9 LocationTracker

5.9.1

47

Vision-based locatiebepaling

Een eerste manier om onze locatie te bepalen is op basis van de camerabeelden. We hebben reeds uitgelegd hoe we de locatie en oriëntatie van de camera ten opzichte van een gedetecteerde barcode kunnen bepalen. Wanneer we dus de coördinaten van de barcode kennen in een wereldcoördinatenstelsel, weten we bijgevolg ook de locatie van de camera in de wereld en dus ook van de speler. Het enige probleem is dat er een barcode in beeld moet zijn en dat het beeld ook voldoende stabiel moet zijn zodat de barcode correct gedetecteerd wordt. De meest evidente oplossing is natuurlijk om zodanig veel markers op te hangen dat er zo goed als altijd minstens één in beeld is. Dit is de aanpak die gebruikt wordt in [Reitmayr and Schmalstieg, 2003], waarbij een groot aantal markers gebruikt wordt, samen met gegevens van een interiaalsensor om robuust te zijn tegen snelle camerabewegingen. Het grote probleem met deze techniek is uiteraard dat de omgeving moet volgehangen worden met markers. Bovendien moet van elk deze markers de exacte locatie opgemeten worden en opgeslagen worden. Zoals reeds besproken in onze state of the art kunnen we om dit probleem op te lossen gebruik maken van natuurlijke features zoals hoeken, contouren etc., maar ook hier blijft het probleem dat dit niet bestand is tegen bruuske bewegingen. We blijven dus achter met een schatting van de locatie enkel wanneer de speler in de buurt van een spelobject komt.

5.9.2

Wi-Fi localisatie

Een andere manier om de locatie te schatten hebben we gevonden in de robotica. Daar wordt onderzoek gedaan naar locatiebepaling op basis van de Wi-Fi signaalsterkte van verschillende access points. Wi-Fi is de dag van vandaag in bijna alle grote steden beschikbaar en in vele kantoren en universiteitsgebouwen zijn er zelfs meerdere access points beschikbaar. Er zijn twee methodologiën die gevolgd worden: het radiopropagatiemodel methode en de machine-learning methode. De eerste methode probeert een model op te bouwen van de propagatie van de signaalsterkte. Gegeven de positie van het access point en een plattegrond van het gebouw, bepaalt het op elke locatie de verwachte signaalsterkte [Bahl and Padmanabhan, 2000] [Bahl et al., 2000]. Het grote nadeel van deze methode is dat het haast onmogelijk is een nauwkeurig signaal propagatie model op te stellen dat rekening houdt met alle factoren, wat de nauwkeurigheid niet ten goede komt.

5.9 LocationTracker

48

De machine-learning methoden starten met een trainingsfase waarbij op verschillende locaties metingen worden gedaan. In een tweede fase worden metingen vergeleken met de trainingdata en op basis daarvan de locatie geschat [Bahl and Padmanabhan, 2000] [Ladd et al., 2002] [Haeberlen et al., 2004]. Het grote nadeel van deze technieken is dat er een grote hoeveelheid trainingdata nodig is en ze niet goed presteren in regio’s waar geen trainingdata van beschikbaar is. Meer recente technieken proberen de eigenschappen van beide methoden te combineren door gebruik te maken van hiërarchische bayesiaanse netwerken [Letchner et al., 2005] of gaussiaanse processen [Ferris et al., 2006]. Wij hebben gekozen voor een machine-learning methode die gebruik maakt van Monte Carlo localisatie [Thrun et al., 2000] [Howard et al., 2003]. De redenen daarvoor zijn dat we een particle filter implementatie beschikbaar hebben in OpenCV, we deze particle filter ook kunnen gebruiken voor sensor fusion en de door Howard gerapporteerde nauwkeurigheid (0.55 ± 0.12m

voor 2 access points) ver boven onze verwachtingen was. Deze cijfers waren wel na training met een robot met een erg kleine granulariteit van metingen. Daarnaast ging het om metingen in slechts 1 gang en was de positie van de access points manueel gekozen. Dit heeft waarschijnlijk wel een grote positieve invloed gehad op de nauwkeurigheid. In een vergelijkende studie van andere methoden [Elnahrawy et al., 2004] vinden we nauwkeurigheden van 3 tot 5 meter gemiddeld met uitschieters van 10 tot 12 meter.

5.9.3

Wi-Fi signal strength maps

In een eerste fase gaan we op verschillende punten metingen doen van de signaalsterkte van verschillende accesspoints. De door ons gekozen locatie is de faculteit Ingenieurswetenschappen van de Universiteit Gent. Naast accesspoints van de UGent kunnen in de gangen ook signalen opgevangen worden van draadloze netwerken van de omliggende koten. Om de signaalsterkte te meten gebruiken we de RSSI (Received Signal Strenght Indicator) zoals beschreven in de IEEE 802.11 protocollen. We gaan actief scannen naar access points door P robeRequest frames uit te sturen. De ontvangen P robeResponse frames van de access points bevatten dan onder andere de SSID (Service Set Identifier) van het netwerk en de RSSI. Deze worden voor elk access point opgeslagen samen met het punt van de meting. Om aan de RSSI waarden te geraken maken we gebruik van de WlanApi in de Windows SDK. Die geeft de signaalsterkte terug in een waarde tussen 0 en 100.

5.9 LocationTracker

49

Op elk trainingspunt nemen we 20 metingen en nemen het gemiddelde als eigenlijke trainingswaarde. [Bahl and Padmanabhan, 2000] gaven aan dat de gemeten waarde afhangt van de oriëntatie van de persoon, aangezien het menselijk lichaam ook signalen absorbeert. Wij vonden niet zo’n correlatie tussen oriëntatie en gemeten RSSI, maar stelden sowieso soms vrij grote variaties in metingen vast. Waarschijnlijk omdat we nooit alleen zijn in het gebouw en er op elk moment (soms veel) mensen aanwezig zijn die ook hun invloed uitoefenen. Bij het verzamelen van de metingen hebben we dus zelf ook onze oriëntatie steeds aangepast om deze invloed uit te middelen. Omdat wij niet beschikken over een robot om onze metingen uit te voeren was een fijne granulariteit van metingen onmogelijk. Bovendien stelden we vast dat de variantie van de metingen vrij groot was zodat een meting een meter verder een weinig afwijkend resultaat zou opgeleverd hebben. We hebben ons voor de locatiebepaling beperkt tot de gangen en metingen uitgevoerd die 5 tot 15 meter uit elkaar konden liggen. Op die manier hebben we op 26 plaatsen metingen uitgevoerd wat ongeveer een anderhalf uur in beslag nam. Om tenslotte onze signal strength maps te genereren gebruiken we een simpele lineaire interpolatie. We zochten voor elk punt in de gangen de twee dichtsbijzijnde meetpunten en namen een gewogen gemiddelde van de twee waarden. Hierbij is het gewicht omgekeerd evenredig met de afstand tot het meetpunt. Op die manier genereren we zo’n een map voor elk access point. Om het aantal maps te beperken leggen we als bijkomende voorwaarde op dat we van een bepaald access point op een bepaald meetpunt een gemiddelde RSSI moeten hebben van meer dan 30. Op die manier houden we 15 netwerken over met een bijhorende signal strength map.

5.9.4

Sequenti¨ ele Monte Carlo methode

De sequentiële Monte Carlo methode is een vorm van Bayes filter. Het Bayes filter probeert de toestand van een object te schatten aan de hand van metingen onderhevig aan ruis. De toestand in ons geval is de locatie van de speler. Het filter houdt op elk tijdstip t de probabiliteitsdistributie P rob(xt ) bij. Deze probabiliteit interpreteren we als het geloof dat op tijdstip t de locatie van de speler xt is. Het updaten van P rob(xt ) gebeurt telkens in 2 stappen.

P rob(xt ) ←

at0

Z

P rob(xt |xt0 , at0 )P rob(xt0 )dxt0

(5.5)

5.9 LocationTracker

50

(a) Plattegrond

(b) UGentNet Signal Strength Map

Figuur 5.18: Links: de plattegrond van het gebouw van de faculteit Ingenieurswetenschappen. Rechts: de kaart van signaalsterkte voor het UGentNet Wi-Fi netwerk. Hoe witter de kleur, hoe hoger de gemeten signaalsterkte.

P rob(xt ) ←

mt

Z

P rob(mt |xt )P rob(xt )

(5.6)

In de eerste stap wordt de nieuwe toestand geschat aan de hand van de actie at0 op moment t0 < t. Vervolgens wordt de schatting aangepast op basis van meting mt op tijdstip t. Normalizatiefactoren zijn weggelaten voor de duidelijkheid. De termen P rob(xt |xt0 , at0 ) en P rob(mt |xt ) noemen we respectivelijk het actiemodel en het sensormodel.

De sequentiële Monte Carlo methode, ook bekend als condensatie-algoritme of deeltjesfilter, implementeert dit door de distributie voor te stellen als een gewogen set van deeltjes. Tijdens de eerste stap wordt voor elk deeltje zijn nieuwe toestand geschat volgens het actiemodel. Tijdens de tweede stap wordt aan elk deeltje met behulp van het sensormodel een gewicht toegekend. Hoe hoger de probabiliteit dat de toestand van het deeltje de werkelijke toestand is, hoe hoger het toegekende gewicht. De set van deeltjes wordt dan hersampled volgens de gewichten. Er zullen dus meer deeltjes komen in gebieden met hoge probabiliteit. Wij gebruikten een set van 1000 deeltjes voor onze deeltjesfilter wat ons goede resultaten opleverde. Dit is niet de enige mogelijke implementatie van het Bayes filter. Andere technieken zijn het Kalman filter , multi-hypothese tracking, gridgebaseerde en topologische methoden [Fox et al., 2003].

5.9 LocationTracker

51

Onze keuze ging naar het deeltjesfilter omdat deze het meest flexibel is en weinig overhead vergt. Voor het actiemodel maken we de assumptie dat de speler niet erg veel beweegt tussen opeenvolgende metingen. Daarom gebruiken we de locatie op t0 tevens als schatting voor deze op tijdstip t. Voor het sensormodel veronderstellen we dat de ruis op het signaal normaal verdeeld is. Met mit de gemeten signaalsterkte voor access point i op tijdstip t en Mi (xt ) de waarde van de signal strength map geëvalueerd op positie xt , berekenen we volgende waarde.

P robi (mit |xt ) = exp(−

(mit − Mi (xt ))2 ) σ2

(5.7)

Als σ nemen we de verwachtte variantie in de trainingsmetingen. Om de overhead te beperken gebruiken we hiervoor een vaste waarde van 20. Voor P rob(mt |xt ) vinden we dan: P rob(mt |xt ) =

Y i

P robi (mit |xt )

(5.8)

Deze waarden gebruiken we dan als gewichten om de deeltjes te hersamplen. We houden ook rekening met het feit dat de speler zich enkel in de gangen kan voortbewegen en zetten de gewichten voor deeltjes die buiten de gang vallen steeds op nul. Initieel is er natuurlijk nog geen informatie beschikbaar omtrent de locatie van de speler en hebben we dus ook geen schatting voor P rob(xt ). We starten het algoritme door willekeurig deeltjes te kiezen volgens een uniforme distributie.

5.9.5

Sensor fusion

In een laatste stap hebben we getracht om de informatie die we krijgen van het Wi-Fi localisatie algoritme te combineren met de locatiegegevens die we hebben als er een marker in beeld is. Het combineren van data van verschillende bronnen wordt ook wel sensor fusion genoemd. Om de informatie van de positie ten opzichte van de marker in rekening te brengen houden we voor elke marker de co¨ ordinaten bij in de wereld. Wanneer we een marker in beeld zien, gaan we het deeltjesfilter updaten volgens een ander sensormodel. In dit geval gaan we deeltjes die dicht bij de markerlocatie gelegen zijn een hoog gewicht geven en naarmate ze verder van de locatie gelegen zijn een lager gewicht.

5.9 LocationTracker

52

P rob(mt |xt ) =

Y

e−

(mt −xt )2 i i 2σ 2

(5.9)

i

Nu stelt mt de locatie voor gemeten op basis van de gekende locatie van de marker. mti en xti stellen dan de i-de component van de vector voor, in ons geval een 2-dimensionale vector, aangezien we enkel ge¨ıntresseerd zijn in de locatie op het kaartje. De factor σ 2 bepaalt hoe snel de probabiliteit afneemt in functie van de afstand van het deeltje tot de gemeten locatie. Opnieuw gebruiken wij een waarde van 20, die ons goede resultaten oplevert. Op die manier worden de deeltes hersampled en komt de distributie rondom de markerlocatie te liggen.

5.9.6

Locatiegegevens in WARGame

Nu we een schatting van de locatie hebben moeten we deze gegevens nog kunnen tonen aan de speler. Deze kan met een druk op de knop een kaart tevoorschijn toveren van de omgeving. Hij kan kiezen tussen een grote kaart die bijna het volledige scherm in beslag neemt en een kleine kaart in de rechterbovenhoek. Op de grote kaart zijn de locaties van de spelers zichtbaar net als de locaties van de verschillende items in het spel en verschillende annotaties bij de verschillende ruimtes. De kleine kaart toont enkel de locaties van de spelers.

(a) Kaart groot

(b) Kaart klein

Figuur 5.19: Links: de grote kaart met daarop de plaatsen van de items en de geschatte locatie van de speler. Rechts: de kleine kaart rechtsbovenaan het scherm. De speler bevindt zich aan de bibliotheek.

RESULTATEN

53

Hoofdstuk 6

Resultaten 6.1

Performantie

Voor de performantie focussen we op twee zaken. Eerst en vooral gaan we na of we voldoen om een realtime applicatie te maken. Dit doen we door het meten van de latentietijd om de responsiveness van het systeem te meten: bijvoorbeeld hoe lang duurt het vooraleer iets gebeurt wanneer de speler op een knop duwt. In een tweede sectie meten we de nodige resources om onze applicatie te draaien: hoeveel geheugen/CPU tijd is nodig om WARGame vlot te laten draaien. Om het systeem te testen gebruiken we 2 laptops als clients en een desktop als server PC. Alle drie de machines zijn verbonden met een lokaal Wi-Fi netwerk. Client 1 is een Dell XPS M1330 laptop, met een Intel T7500 Core 2 Duo CPU geklokt aan 2,20 GHz. Daarnaast is deze voorzien van 2 GiB geheugen, een nVidia GeForce 8400M grafische kaart en een Intel Wireless-N 802.11a/b/gdDraft-n netwerkkaart. Client 2 is een Apple Macbook Pro, voorzien van een Intel T7500 Core 2 Duo CPU aan 2,20 Ghz, 2GiB geheugen en een nVidia 8600M grafische kaart. De desktop pc is uitgerust met een Intel Core2Duo aan 3Ghz, 4GiB geheugen en een AMD Radeon 4850 grafische kaart. De gebruikte HMDs zijn de i-Glasses 920HR met een resolutie van 920000 pixels per LCD en een 35◦ C diagonaal field of view. Als webcam maakten we gebruik van de Logitech Quickcam pro 9000.

6.1 Performantie

6.1.1

54

Latentietijd

Eén van de belangrijkste factoren die een grote invloed heeft op de spelervaring bij een multiplayer spel is de latentietijd. Bij een militaire simulatie wordt een maximale latentie van 100 ms toegelaten [Neyland, 1997]. Dit is dan ook een goede richtlijn voor onze applicatie. Vermits al onze clients en de server aangesloten zijn op eenzelfde WLAN, verwachten we dat de vertraging te wijten aan het netwerk miniem zal zijn en zelfs te verwaarlozen. De grootste bottleneck zal dus onze software zelf zijn. We bestuderen onze applicatie wanneer één van de spelers schiet. We meten de tijd tussen het aanhalen van de trekker van de Wii Remote en het horen van het geluid op de andere client. Om tijdsintervallen te meten maken we gebruik van de GetTickCount(void) functie van de Windows API. Deze geeft het aantal milliseconden terug sinds het opstarten van het systeem. Het eerste tijdsinterval dat we meten is de tijd tussen het aanhalen van de trekker tot het verzenden van het bericht op client 1. De Wii Remote communiceert via Bluetooth met onze software. Deze stuurt elke 10 ms een bericht uit met de waarden van alle knoppen en sensoren. Onze software leest telkens dit bericht uit en pusht het verder in ons framework. Om de start van dit interval te meten, schrijven we een timestamp weg wanneer de Wii Remote een bericht uitstuurt waaruit blijkt dat de B-knop (de trekker) is ingedrukt. We schrijven opnieuw een timestamp weg wanneer het UDP pakket naar de server verzonden is. Het verschil tussen deze twee geeft ons het gezochte interval. Voor de verwerkingstijd op client 1 bekomen we een gemiddelde tijd van 64 ms na 60 metingen. Zoals u ziet op figuur 6.1 ligt het maximum wel boven de 200 ms. Dit hoeft echter niet te betekenen dat er geen realtime ervaring meer mogelijk is. Het overhalen van de trekker gebeurt immers mechanisch en de tijd dat deze ingedrukt wordt gehouden, varieert van 100 tot 400 ms - wat nog altijd een stuk minder is dan de 200ms. Dat wil zeggen dat de speler zelf nog altijd het gevoel heeft alsof het schieten realtime gebeurt. Om de tijd te meten dat het bericht onderweg is van client 1 naar client 2, meten we de round trip time naar de server. Dit doen we door het opvragen van de scores. We starten de meting op het moment dat het pakket om de score op te vragen verzonden wordt en eindigen op het moment dat we de score terug krijgen. Onze metingen blijven zoals verwacht bijna altijd onder de milliseconde. Enkele uitschieters van 15 ms zijn waarschijnlijk te wijten aan het feit dat een

6.1 Performantie

55

Figuur 6.1: Verwerkingstijd op client 1, netwerktijd en verwerkingstijd op client 2. andere thread aan het werk is op het moment dat het bericht aankomt. Dit wil ook zeggen dat de verwerkingstijd op de server zelf bijna verwaarloosbaar is. Dit is ook logisch aangezien de meeste logica op de clients zit, uitgezonderd het bijhouden van de score en activatie van items. Ook pingen naar de server levert ons waarden onder de milliseconde. Het laatste deeltje van het interval is de tijd tussen het aankomen van het bericht op client 2 en het afspelen van het geluid op client 2. Vermits dit slechts enkele functie oproepen zijn, verwachten we dat ook deze tijd verwaarloosbaar is. Inderdaad, we meten opnieuw meestal 0 ms en enkele uitschieters die waarschijnlijk te wijten zijn aan context switches. We kunnen dus besluiten dat de latentietijd voldoende laag is om te voldoen aan de realtime applicatie die we voor ogen hadden. De grootste bottleneck zit hem in de tijd tussen het pushen van de Wii Remote data en het moment waarop wij het bericht kunnen versturen. Dit wordt echter voornamelijk afgehandeld door het framework dat voor ons grotendeels is afgeschermd. Daarnaast is het enkel in deze situatie dat de delay van het netwerk verwaarloosd kan en mag worden omdat alle systemen in een lokaal netwerk verbonden zijn. Wanneer er echter voor gekozen wordt om bijvoorbeeld de server machine op een andere locatie - verder in het netwerk - te zetten, dan moet men hiermee rekening houden. De tijd die er dan bijkomt is de round trip time tussen het draadloze toeganspunt en de server.

6.2 Schaalbaarheid server

6.1.2

56

Resources

Wanneer we kijken naar het geheugenverbruik dan zien we dat onze applicatie ongeveer 60 MB geheugen nodig heeft.

Figuur 6.2: Het vrije geheugen van de client in verloop van de tijd. Ook het percentage van de tijd dat de CPU in gebruik is valt goed mee: we hebben pieken van amper 70 %.

Figuur 6.3: Het % CPU tijd van de client in verloop van de tijd.

6.2

Schaalbaarheid server

Om naar de toekomst toe het spel uit te breiden naar meerdere spelers is het nuttig de schaalbaarheid van de server te kennen: hoeveel berichten kan de server maximaal verwerken per tijdseenheid en wat is de benodigde bandbreedte? Door onze keuze voor thick clients wordt bijna alle spellogica op de client machine afgehandeld. Onze server machine houdt enkel de verschillende geregistreerde spelers bij, de scores en zorgt


57

voor het correct forwarden van de berichten.

6.2.1

Aantal berichten per seconde

Een eerste metric die van belang is voor het schaalgedrag van de server is het aantal berichten dat per tijdseenheid verwerkt moet kunnen worden. Wanneer we het huidige protocol bekijken zijn er verschillende soorten berichten: • Een bericht met de locatie van de speler. Dit wordt in de huidige setup 1 maal per seconde uitgestuurd door elke speler.

• Een shoot of hit bericht dat aangeeft dat een speler schiet en al dan niet een andere speler raakt.

• Een dead bericht om te antwoorden dat de speler gedood is. • Een inactivate bericht dat verzonden wordt wanneer een speler een item oppikt en bijgevolg een tijdje inactief maakt.

• Een score bericht om te score op te vragen aan de server. • Time berichten die de server zelf uitstuurt om de klokken gesynchroniseerd te houden. • Registratieberichten voor nieuwe spelers die willen meespelen of stoppen. We laten in onze berekening de registratieberichten buiten beschouwing. Het time bericht is niet echt een binnenkomend bericht dat verwerkt moet worden, maar een timer die elke 5 seconden afloopt en een bericht naar alle clients verstuurd. We behandelen dit als 1 bericht dat eens elke 5 seconden verwerkt moet worden. Daarnaast stuurt elke client per seconde 1 locatiebericht uit dat verwerkt moet worden. De overige berichten zijn afhankelijk van het aantal spelers dat op dat moment bepaalde handelingen uitvoeren. Om te berekenen hoeveel berichten de server per seconde moet aankunnen kijken we naar de piekbelasting. Dit is wanneer elke speler zoveel mogelijk berichten verstuurt in die seconde. De berichten voor het oppikken van een item, opvragen van de score of zeggen dat men dood is zullen daarbij geen rol spelen, aangezien deze maximaal 1 maal per seconde kunnen verstuurd worden. Het schiet bericht daarentegen kan wel meermaals per seconde verstuurd worden. We zetten een


58

bovengrens van 5 op het aantal schietberichten, aangezien het haast onmogelijk is om meer dan 5 maal per seconde de trekker over te halen. Onze piekbelasting is dan het (onwaarschijnlijke) geval dat elke speler 5 keer schiet in 1 seconde. We krijgen dus

#berichten = 1tijd + 1 · #spelerslocatie + 5 · #spelersschieten

(6.1)

Wanneer we onze metingen bekijken in het geval van 2 spelers, dan zien we inderdaad dat het overgrote deel van de tijd slechts de 2 locatieberichten verwerkt moeten worden, met elke 5 seconden 1 tijd bericht. Sporadisch wordt er een item genomen of de score opgevraagd. Pas wanneer de spelers elkaar in het vizier hebben en op elkaar schieten merken we een piek zoals verwacht.

Figuur 6.4: Het aantal berichten aankomend op de server bij het spelen van WARGame met 2 spelers. Het overgrote deel van de tijd komen er enkel 2 berichten van de locatie update binnen. Enkel wanneer de spelers interageren met een item of naar elkaar schieten krijgen we pieken tot 6 berichten per seconde.

6.2.2

Verwerkingstijd

Hierboven hebben we reeds gezien dat de verwerkingstijd op de server zeer klein is, althans voor 2 spelers. Om het schaalgedrag van de server te onderzoeken willen we dit ook schatten voor meer dan twee spelers. Hiertoe voegen we enkele dummy spelers toe aan de serverkant en analyseren de verwerkingstijden. Aangezien het extra werk dat de server dan moet doen hem zit in het forwarden naar extra spelers, verwachten we een lineaire stijging van de verwerkingstijd met het aantal spelers.


59

Vermits we te maken hebben met verwerkingstijden van kleiner dan 1 ms, voldoet de resolutie van GetTickCount(void) niet meer om metingen te doen. Daarom gebruiken we Wireshark, een packetsniffer die timestamps heeft in microseconden. Als verwerkingstijd nemen we dan het interval tussen het aankomen van het bericht aan de server tot het verzenden van het bericht naar de laatste client. We meten de verwerkingstijden van shoot-berichten. Om deze te verwerken moeten eerst score statistieken geupdate worden en vervolgens wordt het bericht geforward naar alle clients. In het geval van 2 spelers vinden we een gemiddelde verwerkingstijd van 105 microseconden en een maximale verwerkingstijd van 168 microseconden. Zoals verwacht stijgt deze met toenemend aantal spelers. Voor 5, 10 en 20 spelers vinden we respectievelijk gemiddelde verwerkingstijden van 139, 195 en 342 microseconden. De maximale gemeten verwerkingstijden bedragen 190, 247 en 410 microseconden.

Figuur 6.5: De gemiddelde, minimale en maximale verwerkingstijden op de server voor een shoot-bericht in het geval van 2, 5, 10 en 20 spelers. Door middel van lineaire regressie vinden we een lineaire trendlijn die het schalingsgedrag kenmerkt.

T = 0, 013 · #spelers + 0, 073ms De correlatiecoëfficient R2 = 0, 995 duidt zoals verwacht op een sterk lineair verband.

(6.2)


60

Wanneer we het aantal berichten voor 20 spelers in piekbelasting berekenen dan vinden we 121 berichten op 1 seconde. Dit geeft een gemiddelde totale verwerkingstijd van 41 ms of bijna niets. Dit betekent niet dat deze analyse zinloos is. Wanneer bijvoorbeeld gebruik gemaakt wordt van gyroscopen of inertiaalsensoren voor locatiebepaling ligt de update rate misschien veel hoger. Om de vergelijking te maken hebben we enerzijds het maximaal aantal berichten dat verwerkt kan worden per seconde uitgezet ten opzichte van de verwachte aankomende berichten per seconde. Voor het aantal verwachte berichten gebruiken we vergelijking 6.1, met respectievelijk 1, 10 en 100 locatieberichten per seconde.

Figuur 6.6: De schaalbaarheid van de server. We zien dat gerekend dat op 1 seconde elke speler maximaal 1 locatiebericht uitstuurt en 5 andere berichten, dat we een aantal spelers van 110 kunnen toelaten. Wanneer we echter de frequentie van de locatieberichten opdrijven tot 100Hz daalt het aantal toegelaten spelers tot 24.

6.2.3

Bandbreedte

Een laatste aspect is de benodigde bandbreedte. De gemiddelde grootte van de verstuurde datagrammen is ongeveer 60 bytes (mede afhankelijk van de lengte van de spelersnamen enzovoort). Dat betekent dat we voor 20 spelers voldoende hebben aan 48kbps. Ook hier geldt dezelfde opmerking als hierboven. Dit lijkt weinig maar stijgt enorm wanneer

6.3 Gebruikersstudie

61

bijvoorbeeld de update frequentie van de locatie toeneemt. Nemen we hetzelfde voorbeeld met een updatefrequentie van 100 Hz dan hebben we al 1 Mbps nodig voor 20 spelers te laten spelen.

6.3

Gebruikersstudie

Om de usability van onze applicatie te testen, hebben we gepeild naar de mening van testgebruikers. Voor onze gebruikerstest hebben we een zaal ingericht waardoor iedereen in dezelfde spelomgeving kan spelen. Iedere testpersoon krijgt eerst een korte uitleg waarna hij 1 spel (ongeveer 10 minuten) speelt. Nadien vult hij een vragenlijst in die de verschillende aspecten van de applicatie evalueert. We evalueren 3 aspecten: de invloed van de hardware setup, de verschillende spelfeatures en de totale spelervaring. Bij elk aspect stellen we een 4 a 5 tal vragen waarbij de gebruiker een score tussen 1 en 5 aanduidt. Een score van 5 is positief voor de applicatie, een score van 1 negatief. Daarnaast zijn er ook nog enkele open vragen die de gebruikers konden beantwoorden.

Figuur 6.7: We vroegen testgebruikers om WARGame te spelen en achteraf een evaluatieformulier in te vullen.

Aan onze gebruikersstudie namen 25 personen deel tussen de 19 en de 31 jaar. Onder hen waren 21 mannen en 4 vrouwen.

6.3.1

Hardware setup

Om de hardware setup te evalueren werden volgende vragen gesteld:


62

1. Had u last van duizeligheid? 2. Had u last van hoofdpijn? 3. Had u last van storende vertraging? 4. Had u last van de warmte op uw rug? 5. Vond u de last op uw rug te zwaar? Een score van 5 staat dus voor “helemaal geen last”, een score van 1 voor “heel veel last”. De gemiddelde scores zijn samengevat in figuur 6.8.

Figuur 6.8: De scores voor de vragen in verband met de hardware setup. We merken dat onze applicatie op al deze vragen vrij goed scoort. Bijna niemand had last van hoofdpijn of het gewicht op de rug. Ook had niemand last van de warmte op de rug, ook al werden de laptops zelf wel zeer warm. Enkele mensen hadden achteraf wel last van duizeligheid. Enkel de delay leverde een lagere score op. Het is een feit dat beide laptops ontzettend warm werden tijdens het spelen van WARGame. Bij één van de laptops (de Dell XPS M1330), bereikte de CPU zelfs temperaturen van 98◦ C. De maximum temperatuur die de Core 2 Duo CPU aankan bedraagt volgens Intel 100◦ C. Wanneer de CPU dicht bij deze grens komt, zal de CPU zichzelf onderklokken ten einde de temperatuur terug naar beneden te krijgen. Dit is ook de oorzaak dat na verloop van tijd er zeer storende delay optrad op de laptop in kwestie. Bij mensen die in het begin speelden met een koele laptop werd de delay vaak nog goed geëvalueerd (score 4), terwijl bij anderen slechts een 1 of een 2 gescoord werd.


6.3.2

63

Spelfeatures

In het tweede deel van de vragenlijst stellen we gericht vragen om de verschillende features te evalueren. 1. Werd de andere speler steeds correct gedetecteerd? 2. Wat vond u van de locatiebepaling? 3. Wat vond u van de interactie met de barcodes? 4. Kon u gemakkelijk richten op de andere speler? 5. Kon u zich gemakkelijk voortbewegen? Ook hier werden scores van 1 tot 5 gegeven waarbij 1 staat voor “nooit”/“erg moeilijk”/“slecht” en 5 voor “altijd”/“erg makkelijk”/“goed”. De resultaten zijn samengevat in figuur 6.9.

Figuur 6.9: De scores voor de vragen in verband met de verschillende features. De interactie met de markers krijgt de hoogste score. Iedereen vond het intu¨ıtief om een item op te pakken door in de buurt te komen en er naar te kijken. Slechts in het geval van de vlaggen die een marker op de grond bevestigd hadden verliep het niet perfect. De andere features zijn allemaal “ok”, maar hebben telkens wat minpunten zodat hun score rond de 3 ligt. De spelerdetectie bleek erg afhankelijk van de belichting. Sommigen gaven de hoogste score, anderen de laagste. Het feit dat we geen controle hadden over de lichten binnen en de zonnewering maakte dat we hieraan niet veel konden veranderen.


64

Aangezien onze demoruimte te klein was om noemenswaardige verschillen in de Wi-Fi signaalsterkte te meten gebeurde de locatiebepaling enkel aan de hand van barcodes. Vele mensen hadden dit amper of niet opgemerkt en dus zijn de gegevens daaromtrent niet echt relevant. Anderen hadden er wel op gelet en vonden het handig om een idee te hebben waar ongeveer de tegenstander zich bevond. Zelf hadden we op andere locaties vrij goede ervaringen met de Wi-Fi bepaling, zij het wel met een geschatte nauwkeurigheid van 5 a 10 meter. We beschikten ook niet over de meetinstrumenten om een nauwkeurige evaluatie van ons Wi-Fi algoritme te doen. Het richten werd door iedereen als moeilijk ervaren. Dit komt waarschijnlijk omdat het richten be¨ınvloed wordt door beweging van zowel de Wii Remote als de webcam. Daarbij komt nog eens het feit dat de crosshair bewegen naar links en rechts minder intu¨ıtief is met de Wii Gun dan in het geval van een echt pistool. Al deze dingen samen zorgen ervoor dat het toch even wennen is vooraleer je goed kan richten. Ook het voortbewegen in de ruimte ging niet altijd even vlot. Door het gebrek aan dieptezicht is het moeilijk in te schatten hoeveel afstand er zich bevindt tussen jezelf en de muur. Dit maakte dat er al snel restauratiewerken nodig waren aan onze papieren muren.

6.3.3

Spelervaring

Tot slot waren er nog enkele vragen omtrent de totale spelbeleving: 1. Wat vond u van het spel? 2. Biedt dit een meerwaarde ten opzichte van huidige computerspellen? 3. Zou u ervoor betalen? 4. Zou u ervoor betalen wanneer de technologie meer op punt staat? Een score van 1 staat hier voor “slecht”/“helemaal niet” en 5 staat voor “goed”/“zeker wel”. De resultaten worden weergegeven in figuur 6.10. Iedereen was tevreden over de spelervaring en vond dat augmented reality games een meerwaarde bieden ten opzichte van hedendaagse videospellen. We kunnen dus stellen dat we in ons opzet geslaagd zijn. Ook de vraag of men er voor zou willen betalen werd positief beantwoord, vooral wanneer de technologie meer op punt staat en de kinderziekten uit onze applicatie zijn weggewerkt.


65

Figuur 6.10: De scores voor de vragen in verband met de totale spelervaring.

6.3.4

Open vragen

Tot slot waren er nog enkele open vragen die de gebruikers konden beantwoorden: 1. Wat vond u positief? 2. Wat kan er beter? 3. Hebt u ideeën voor extra mogelijkheden? Welke? Vooral de augmented reality ervaring werd positief onthaald. Iedereen was enthousiast over het samensmelten van de realiteit en typische spel elementen. Qua negatieve punten kwamen vooral de delay en de hardwarebeperkingen naar boven. Hetgeen men vooral extra zou willen zien is een uitbreiding naar meerdere spelers en teams.

MOGELIJKE UITBREIDINGEN

66

Hoofdstuk 7

Mogelijke uitbreidingen We zijn er van overtuigd dat we met onze WARGame applicatie het onderste uit de kan hebben gehaald met de beschikbare apparatuur en tijd. Dit betekent niet dat hier het verhaal moet eindigen. Er zijn nog tal van uitbreidingen of verbeteringen denkbaar.

7.1

Hardware

Een eerste grote beperking was de beschikbare hardware. De grootste tekortkoming is waarschijnlijk het gebrek aan dieptezicht. Hierdoor wordt interactie met de reële wereld veel moeilijker. Om dit te verhelpen moeten we evolueren naar een setup met stereo camera’s en ook een HMD die in staat is links en rechts andere beelden te tonen. Misschien moeten we zelfs naar een see-trough setup gaan.

Figuur 7.1: De Vuzix Wrap 920 see-through HMD. Bron: Vuzix

7.1 Hardware

67

Een veelbelovende HMD is de Vuzix Wrap 920 AV. Deze bril heeft een see-trough lens waardoor het aanvoelt als een zonnebril, maar waarmee tegelijk video en dus virtuele objecten kunnen weergegeven worden. Ondanks deze indrukwekkende features heeft deze HMD toch nog de form factor van een gewone zonnebril. Deze HMD wordt verwacht eind 2009 en bovendien maakt de Vuzix website al melding van enkele zeer interessante features voor augmented reality: een 6-DOF hoofd tracker en een stereo camera uitbreiding die op de bril gemonteerd kunnen worden.

Figuur 7.2: Vuzix voorziet ook interessante accesoires voor de Wrap 920 zoals een 6-DOF tracker en een stereo camera rig. Bron: Vuzix Een ander gadget om de spelervaring intenser te maken is bijvoorbeeld een 3rd Space Gaming vest van TN Games. Deze vest ziet eruit als een kogelvrije vest, maar geeft de speler force feedback door middel van pneumatische impact cellen. De speler voelt als het ware de impact van kogels wanneer hij of zij geraakt wordt. Voor wie dat nog niet genoeg is staat ook een force feedback helm op de roadmap van TN Games. Plezier (of pijn) verzekerd!

Figuur 7.3: De 3rd Space Gaming vest ziet eruit als een kogelvrije vest, maar is voorzien van speciale cellen zodat je de impact van kogels in het spel kan voelen. Bron: TN Games Ook voor de locatiebepaling kan extra hardware nuttig zijn. Voor locatiebepaling in openlucht kan bijvoorbeeld een GPS sensor gebruikt worden. De onnauwkeurigheden van bijvoorbeeld

7.2 Platform

68

GPS of Wi-Fi locatiebepaling kunnen verbeterd worden door gegevens te gebruiken van inertiaalsensoren. In combinatie met algoritmen gebaseerd op natural feature points kunnen op termijn misschien zelfs virtuele objecten toegevoegd worden zonder dat er 2D markers nodig zijn.

7.2

Platform

Het Studierstube platform waarop onze applicatie gebouwd is heeft zeker zijn nut bewezen. Zonder zouden we er waarschijnlijk nooit in geslaagd zijn van WARGame te maken wat het nu is. Zeker als leken in augmented reality was een platform dat veel zaken voor jou doet onontbeerlijk. Maar hoe meer we vorderden met onze applicatie, hoe meer we stootten op de beperkingen van het platform. Studierstube richt zich vooral op het verwerken van input informatie van alle devices, deze naar de juiste objecten te sturen en die objecten dan te visualiseren. Het is vooral eenrichtingsverkeer, met een stikte scheidingslijn tussen het verwerken van input en visualiseren van de objecten. Dit maakt het onmogelijk om de spel objecten een status te geven die ook een invloed heeft op de verwerking van de input. Wij moeten dus de status van de objecten bijhouden aan de inputverwerkingszijde. Dit maakt dat voor het toevoegen van een nieuw object er dubbel werk moet gedaan worden. Daarnaast is het op dit moment onmogelijk om at runtime nieuwe objecten aan te maken. Elk object dat op het scherm moet kunnen verschijnen moet voor opstarten vast gecodeerd worden in de scenegraph. Het is ook een feit dat door het ontbreken van goede documentatie en de grootte van het Studierstube project het bijna onmogelijk is om het platform te doorgronden en ten volle gebruik te maken van zijn potentieel. Studierstube is ook al 10 jaar in ontwikkeling en dat laat zijn sporen na. We hebben de indruk dat er in de loop der tijd features zijn toegevoegd waarvoor het eigenlijk niet ontworpen was, maar dan via een achterpoortje ge¨ımplenteerd zijn. Het is dus misschien geen slecht idee om zelf een nieuw augmented reality platform op te bouwen, rekening houdend met de huidige requirements van augmented reality toepassingen en de huidige state of the art.

7.3 WARGame

7.3

69

WARGame

Tot slot zijn er ook nog tal van uitbreidingen voor het spel zelf. De belangerijkste is waarschijnlijk wel het uitbreiden naar meer dan twee spelers. Omdat het noodzakelijk is om elke speler uniek te identificeren, hebben we het probleem van beperkt aantal gekleurde truitjes. Mogelijke oplossingen zijn het gebruiken van meerdere kleuren per truitje, of het combineren van locatiebepaling en kleur van truitje om een speler te identificeren. Verbeteringen aan de spelervaring gaan hand in hand met extra hardware. Het gebruik van hoofd tracking zou bijvoorbeeld het richten met de Wii Remote meer intu¨ıtief kunnen maken. Stereo camerabeelden geven de speler dieptezicht en inertiaalsensoren kunnen de positionering van virtuele objecten en locatiebepaling verbeteren. Daarnaast zijn er ook de traditionele onderzoeksonderwerpen in de augmented reality die ons spel kunnen verbeteren. Populaire onderzoeksonderwerpen zoals natural feature tracking en SLAM (Simultanuous Localization And Mapping) kunnen de markers overbodig maken. Post processing van de weergave van virtuele objecten kan ze beter laten blenden met de reële wereld. Het detecteren van vlakken en objecten in de wereld in combinatie met een physics engine maakt het mogelijk om niet alleen statische virtuele objecten toe te voegen maar ook dynamische, bijvoorbeeld een virtuele tegenstander. Uiteindelijk is de enige grens voor het bedenken van uitbreidingen de grens van je eigen verbeelding.

CONCLUSIE

70

Hoofdstuk 8

Conclusie In dit werk werd WARGame voorgesteld, een augmented reality first person shooter waarbij twee spelers het tegen elkaar opnemen. Met een video see-through setup krijgt de speler het gevoel dat hij echt in het spel zit. Hij krijgt spelinformatie door middel van een overlay op het beeld en virtuele objecten worden toegevoegd in de realiteit door middel van 2D markers. De speler kan interageren met de applicatie door middel van een Wii Remote in een Wii Gun en krijgt langs die weg ook feedback door de LEDs en trilfunctie. WARGame is gedistribueerd, waardoor twee spelers het tegen elkaar kunnen opnemen. De tegenstander wordt gedetecteerd door detectie van felgekleurde truitjes die de spelers aantrekken. Tot slot hebben we ook onderzoek gedaan naar locatiebepaling door middel van sensor fusion van marker locatie-informatie en gemeten Wi-Fi signaal sterktes. Die informatie gebruikten we om de locatie van de spelers in het spel aan te geven op een kaartje van de spelomgeving. WARGame is de eerste augmented reality FPS waarbij 2 spelers het tegen elkaar kunnen opnemen. De grootste bijdragen van deze thesis zijn – volgens ons – het omzetten van een leuk idee naar technische requirements, het creatief zoeken naar technische oplossingen voor praktische problemen en het combineren van technieken en algoritmen uit de state-of-the-art van verschillende domeinen om onze applicatie tot leven te wekken. Zo hebben we bijvoorbeeld het praktische probleem van het detecteren van de tegenstander vertaald naar een probleem van kleurdetectie en gebruik gemaakt van een aanpassing van een algoritme voor gezichtsdetectie. Uit onze evaluatie, zowel technisch als op het gebied van usability, kunnen we concluderen dat augmented reality gaming zeker iets is wat de mensen aanspreekt en technisch gezien meer en meer haalbaar wordt. Het is een domein dat de komende jaren in de gaten gehouden moet

CONCLUSIE

71

worden en een mooie toekomst heeft. Toch zijn er de dag van vandaag nog tal van problemen, zowel op het vlak van hardware (HMD, PC in de rugzak) als software (spelerdetectie, delay), waar nog verbetering nodig is om echt door te breken.

BIBLIOGRAFIE

72

Bibliografie [Allen et al., 2004] Allen, J. G., Xu, R. Y. D., and Jin, J. S. (2004). Object tracking using camshift algorithm and multiple quantized feature spaces. In VIP ’05: Proceedings of the PanSydney area workshop on Visual information processing, pages 3–7, Darlinghurst, Australia, Australia. Australian Computer Society, Inc. [Azuma, 1997] Azuma, R. T. (1997). A survey of augmented reality. Presence, 6:355–385. [Bahl et al., 2000] Bahl, P., Balachandran, A., and Padmanabhan, V. (2000). Enhancements to the radar user location and tracking system. [Bahl and Padmanabhan, 2000] Bahl, P. and Padmanabhan, V. N. (2000).

Radar: an in-

building rf-based user location and tracking system. volume 2, pages 775–784 vol.2. [Barakonyi et al., 2005] Barakonyi, I., Weilguny, M., Psik, T., and Schmalstieg, D. (2005). Monkeybridge: autonomous agents in augmented reality games. In ACE ’05: Proceedings of the 2005 ACM SIGCHI International Conference on Advances in computer entertainment technology, pages 172–175, New York, NY, USA. ACM. [Bauer et al., 2001] Bauer, M., Bruegge, B., Klinker, G., MacWilliams, A., Reicher, T., Riss, S., Sandor, C., and Wagner, M. (2001). Design of a component-based augmented reality framework. In Proceedings of the International Symposium on Augmented Reality (ISAR). [Bauer et al., 2003] Bauer, M., Hilliges, O., Macwilliams, A., Newman, J., Reitmayr, G., Fahmy, T., S, C., Wagner, M., Klinker, G., Pintaric, T., and Schmalstieg, D. (2003). Integrating studierstube and dwarf. In In Proc. STARS 2003, pages 1–5. [Bleser and Stricker, 2008] Bleser, G. and Stricker, D. (2008). Advanced tracking through efficient image processing and visual-inertial sensor fusion. In VR, pages 137–144. IEEE.

BIBLIOGRAFIE

73

[Bouguet, 2008] Bouguet, J. Y. (2008). Camera calibration toolbox for matlab. [Bradski and Kaehler, 2008] Bradski, G. R. and Kaehler, A. (2008). Learning OpenCV. O’Reilly Media. [Brown, 1971] Brown, D. (1971). Close-range camera calibration. Photogrammetric Engineering, 37:855–866. [Cakmakci and Roll, 2006] Cakmakci, O. and Roll, J. (2006). Head-worn displays: A review. Journal of Display Technology, 2. [Cakmakci et al., 2008] Cakmakci, O., Vo, S., Vogl, S., Spindelbalker, R., Ferscha, A., and Rolland, J. P. (2008). Optical free-form surfaces in off-axis head-worn display design. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 29–32. [Cheok et al., 2003] Cheok, A. D., Fong, S. W., Goh, K. H., Yang, X., Liu, W., and Farzbiz, F. (2003). Human pacman: a sensing-based mobile entertainment system with ubiquitous computing and tangible interaction. In NetGames ’03: Proceedings of the 2nd workshop on Network and system support for games, pages 106–117, New York, NY, USA. ACM. [Comaniciu et al., 2002] Comaniciu, D., Meer, P., and Member, S. (2002). Mean shift: A robust approach toward feature space analysis. IEEE Transactions on Pattern Analysis and Machine Intelligence, 24:603–619. [Comport et al., 2003] Comport, A. I., ric March, and Chaumette, F. (2003). A real-time tracker for markerless augmented reality. In In ACM/IEEE Int. Symp. on Mixed and Augmented Reality, ISMAR03, pages 36–45. [Cooper et al., 2004] Cooper, N., Keatley, A., Dahlquist, M., Mann, S., Slay, H., Zucco, J., Smith, R., and Thomas, B. H. (2004). Augmented reality chinese checkers. In ACE ’04: Proceedings of the 2004 ACM SIGCHI International Conference on Advances in computer entertainment technology, pages 117–126, New York, NY, USA. ACM Press. [Drascic et al., 1993] Drascic, D., Grodski, J. J., Milgram, P., Ruffo, K., Wong, P., and Zhai, S. (1993). Argos: a display system for augmenting reality. In CHI ’93: Proceedings of the INTERACT ’93 and CHI ’93 conference on Human factors in computing systems, page 521, New York, NY, USA. ACM.

BIBLIOGRAFIE

74

[Elnahrawy et al., 2004] Elnahrawy, E., Li, X., and Martin, R. P. (2004). The limits of localization using signal strength: a comparative study. pages 406–414. [Ferris et al., 2006] Ferris, B., Hähnel, D., and Fox, D. (2006). Gaussian processes for signal strength-based location estimation. In In Proc. of Robotics Science and Systems. [Fiala, 2005] Fiala, M. (2005). Artag, a fiducial marker system using digital techniques. In CVPR ’05: Proceedings of the 2005 IEEE Computer Society Conference on Computer Vision and Pattern Recognition (CVPR’05) - Volume 2, pages 590–596, Washington, DC, USA. IEEE Computer Society. [Fong et al., 2008] Fong, W. T., Ong, S. K., and Nee, A. Y. C. (2008). A differential gps carrier phase technique for precision outdoor ar tracking. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 25–28. [Fox et al., 2003] Fox, D., Hightower, J., Liao, L., Schulz, D., and Borriello, G. (2003). Bayesian filtering for location estimation. IEEE Pervasive Computing, 02(3):24–33. [Foxlin et al., 2004] Foxlin, E., Altshuler, Y., Naimark, L., and Harrington, M. (2004). Flighttracker: A novel optical/inertial tracker for cockpit enhanced vision. Mixed and Augmented Reality, IEEE / ACM International Symposium on, 0:212–221. [Fryer and Brown, 1986] Fryer, J. G. and Brown, D. C. (1986). Lens distortion for close-range photogrammetry. Photogrammetric Engineering and Remote Sensing, 52:51–58. [Fuhrmann, 1999] Fuhrmann, A. (1999). Studierstube: a Collaborative Virtual Environment for Scientific Visualization. PhD thesis, Institute of Computer Graphics and Algorithms, Vienna University of Technology, Favoritenstrasse 9-11/186, A-1040 Vienna, Austria. [Fuhrmann and Purgathofer, 2001] Fuhrmann, A. and Purgathofer, W. (2001). Studierstube: An application environment for multi-user games in virtual reality. Technical report, GIJahrestagung. [Goebel and Friesdorf, 2002] Goebel, M. and Friesdorf, W. (2002). Evaluation of input devices for 3d-navigation in medical applications. In Proceedings of the 6th International Scientific Conference on Work With Display Units., pages 435–437.

BIBLIOGRAFIE

75

[Haeberlen et al., 2004] Haeberlen, A., Flannery, E., Ladd, A. M., Rudys, A., Wallach, D. S., and Kavraki, L. E. (2004). Practical robust localization over large-scale 802.11 wireless networks. In MobiCom ’04: Proceedings of the 10th annual international conference on Mobile computing and networking, pages 70–84. ACM. [Hand, 1997] Hand, C. (1997). A survey of 3d interaction techniques. In Computer Graphics Forum, volume 16, pages 269–281. [Heikkila and Silven, 1997] Heikkila, J. and Silven, O. (1997). A four-step camera calibration procedure with implicit image correction. In CVPR ’97: Proceedings of the 1997 Conference on Computer Vision and Pattern Recognition (CVPR ’97), page 1106, Washington, DC, USA. IEEE Computer Society. [Howard et al., 2003] Howard, A., Siddiqi, S., and Sukhatme, G. (2003). An experimental study of localization using wireless ethernet. In Proceedings of the International Conference on Field and Service Robotics. [Ii et al., 2001] Ii, R. M. T., Hudson, T. C., Seeger, A., Weber, H., Juliano, J., and Helser, A. T. (2001). Vrpn: A device-independent, network-transparent vr peripheral system. [Kato and Billinghurst, 1999] Kato, H. and Billinghurst, M. (1999). Marker tracking and hmd calibration for a video-based augmented reality conferencing system. In Proceedings of the 2nd International Workshop on Augmented Reality (IWAR 99), San Francisco, USA. [Kaufmann, 2003] Kaufmann, H. (2003). Collaborative augmented reality in education. In Proc. Imagina 2003 Conf. (Imagina03. [Klein and Drummond, 2002] Klein, G. and Drummond, T. (2002). Tightly integrated sensor fusion for robust visual tracking. In In Proc. British Machine Vision Conference (BMVC02, pages 787–796. [Klein and Murray, 2007] Klein, G. and Murray, D. (2007). Parallel tracking and mapping for small ar workspaces. In Proc. Sixth IEEE and ACM International Symposium on Mixed and Augmented Reality (ISMAR’07), Nara, Japan. [Klein and Murray, 2008a] Klein, G. and Murray, D. (2008a). Compositing for small cameras. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 57–60.

BIBLIOGRAFIE

76

[Klein and Murray, 2008b] Klein, G. and Murray, D. (2008b). Improving the agility of keyframebased SLAM. In Proc. 10th European Conference on Computer Vision (ECCV’08), pages 802–815. [Knoerlein et al., 2007] Knoerlein, B., Székely, G., and Harders, M. (2007). Visuo-haptic collaborative augmented reality ping-pong. In ACE ’07: Proceedings of the international conference on Advances in computer entertainment technology, pages 91–94, New York, NY, USA. ACM. [Ladd et al., 2002] Ladd, A. M., Bekris, K. E., Rudys, A., Kavraki, L. E., and Wallach, D. S. (2002). Robotics-based location sensing using wireless Ethernet. Wireless Networks, 11(1). [Lee et al., 2005] Lee, W., Lee, J., and Woo, W. (2005). Tarboard: Tangible augmented reality system for table-top game environment. 2nd International Workshop on Pervasive Gaming Applications. [Lepetit and Fua, 2005] Lepetit, V. and Fua, P. (2005). Monocular model-based 3d tracking of rigid objects. Found. Trends. Comput. Graph. Vis., 1(1):1–89. [Letchner et al., 2005] Letchner, J., Fox, D., and LaMarca, A. (2005). Large-scale localization from wireless signal strength. In In Proc. of the National Conference on Artificial Intelligence. [Lindt and Broll, 2004] Lindt, I. and Broll, W. (2004). Netattack - first steps towards pervasive gaming. ERCIM News, (57):49–50. [Liu et al., 2008] Liu, S., Cheng, D., and Hua, H. (2008). An optical see-through head mounted display with addressable focal planes. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 33–52. [Looser et al., 2006] Looser, J., Grasset, R., Seichter, H., and Billinghurst, M. (2006). Osgart a pragmatic approach to mr. In International Symposium of Mixed and Augmented Reality (ISMAR 2006), ISMAR. [MacIntyre et al., 2004] MacIntyre, B., Gandy, M., Dow, S., and Bolter, J. D. (2004). Dart: a toolkit for rapid design exploration of augmented reality experiences. In UIST ’04: Proceedings of the 17th annual ACM symposium on User interface software and technology, pages 197–206, New York, NY, USA. ACM. [Matysczok et al., 2004] Matysczok, C., Radkowski, R., and Berssenbruegge, J. (2004). Arbowling: immersive and realistic game play in real environments using augmented reality. In

BIBLIOGRAFIE

77

ACE ’04: Proceedings of the 2004 ACM SIGCHI International Conference on Advances in computer entertainment technology, pages 269–276, New York, NY, USA. ACM. [Milgram et al., 1995] Milgram, P., Takemura, H., Utsumi, A., and Kishino, F. (1995). Augmented reality: A class of displays on the reality-virtuality continuum. In Proceedings of the SPIE Conference on Telemanipulator and Telepresence Technologies, volume 2351 of Proceedings of SPIE, pages 282–292. [Miyashita et al., 2008] Miyashita, T., Meier, P., Tachikawa, T., Orlic, S., Elbe, T., Scholz, V., and Gapel, A. (2008). An augmented reality museum guide. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 125–134. [Montemerlo et al., 2003] Montemerlo, M., Thrun, S., Koller, D., and Wegbreit, B. (2003). Fastslam 2.0: An improved particle filtering algorithm for simultaneous localization and mapping that provably converges. In In Proc. of the Int. Conf. on Artificial Intelligence (IJCAI, pages 1151–1156. [Newman et al., 2004] Newman, J., Wagner, M., Bauer, M., MacWilliams, A., Pintaric, T., Beyer, D., Pustka, D., Strasser, F., Schmalstieg, D., and Klinker, G. (2004). Ubiquitous tracking for augmented reality. Mixed and Augmented Reality, IEEE / ACM International Symposium on, 0:192–201. [Neyland, 1997] Neyland, D. L. (1997). Virtual Combat: A Guide to Distributed Interactive Simulation. Stackpole Books. [Oda et al., 2007] Oda, O., Lister, L. J., White, S., and Feiner, S. (2007). Developing an augmented reality racing game. In INTETAIN ’08: Proceedings of the 2nd international conference on INtelligent TEchnologies for interactive enterTAINment, pages 1–8. ICST (Institute for Computer Sciences, Social-Informatics and Telecommunications Engineering). [Park et al., 2008] Park, Y., Lepetit, V., and Woo, W. (2008). Multiple 3d object tracking for augmented reality. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 117–120. [Piekarski and Thomas, 2001a] Piekarski, W. and Thomas, B. H. (2001a). Tinmith-evo5 – an architecture for supporting mobile augmented reality environments. volume 0, page 177, Los Alamitos, CA, USA. IEEE Computer Society.

BIBLIOGRAFIE

78

[Piekarski and Thomas, 2001b] Piekarski, W. and Thomas, B. H. (2001b). Tinmith-metro: New outdoor techniques for creating city models with an augmented reality wearable computer. In ISWC ’01: Proceedings of the 5th IEEE International Symposium on Wearable Computers, page 31, Washington, DC, USA. IEEE Computer Society. [Piekarski and Thomas, 2002a] Piekarski, W. and Thomas, B. H. (2002a). Arquake: the outdoor augmented reality gaming system. Commun. ACM, 45(1):36–38. [Piekarski and Thomas, 2002b] Piekarski, W. and Thomas, B. H. (2002b). The tinmith system: demonstrating new techniques for mobile augmented reality modelling. In AUIC ’02: Proceedings of the Third Australasian conference on User interfaces, pages 61–70, Darlinghurst, Australia, Australia. Australian Computer Society, Inc. [Pustka and Klinker, 2008] Pustka, D. and Klinker, G. (2008). Dynamic gyroscope fusion in ubiquitous tracking environments. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 13–20. [Reitmayr, 2004] Reitmayr, G. (2004). On Software Design for Augmented Reality. PhD thesis, Vienna University of Technology. [Reitmayr and Drummond, 2006] Reitmayr, G. and Drummond, T. W. (2006). Going out: Robust tracking for outdoor augmented reality. In Proc. ISMAR 2006, pages 109–118. IEEE and ACM, IEEE CS. [Reitmayr and Schmalstieg, 2001] Reitmayr, G. and Schmalstieg, D. (2001). Opentracker- an open software architecture for reconfigurable tracking. [Reitmayr and Schmalstieg, 2003] Reitmayr, G. and Schmalstieg, D. (2003). Location based applications for mobile augmented reality. In AUIC ’03: Proceedings of the Fourth Australasian user interface conference on User interfaces 2003, pages 65–73. Australian Computer Society, Inc. [Rolland et al., 2001] Rolland, J. P., Davis, L., and Baillot, Y. (2001). A survey of tracking technology for virtual environments. In Fundamentals of wearable computers and augmented reality, pages 67–112.

BIBLIOGRAFIE

[Rolland and Fuchs, 2000] Rolland, J. P. and Fuchs, H. (2000).

79

Optical versus video see-

through head-mounted displays in medical visualization. Presence: Teleoper. Virtual Environ., 9(3):287–309. [Sareika and Schmalstieg, 2007] Sareika, M. and Schmalstieg, D. (2007). Urban sketcher: Mixed reality on site for urban planning and architecture. Mixed and Augmented Reality, 2007. ISMAR 2007. 6th IEEE and ACM International Symposium on, pages 27–30. [Schall et al., 2008] Schall, G., Mendez, E., and Schmalstieg, D. (2008). Virtual redlining for civil engineering in real environments. Mixed and Augmented Reality, 2008. ISMAR 2008. 7th IEEE/ACM International Symposium on, pages 95–98. [Schmalstieg et al., 2000] Schmalstieg, D., Fuhrmann, A., Hesina, G., Szalavári, Z., Encarna¸c˜ ao, L. M., Gervautz, M., and Purgathofer, W. (2000). The studierstube augmented reality project. Technical Report TR-186-2-00-22, Institute of Computer Graphics and Algorithms, Vienna University of Technology. [Schweighofer, 2006] Schweighofer, G. (2006). Robust pose estimation from a planar target. IEEE Trans. Pattern Anal. Mach. Intell., 28(12):2024–2030. [Strauss, 1993] Strauss, P. S. (1993). Iris inventor, a 3d graphics toolkit. SIGPLAN Not., 28(10):192–200. [Szalav´ ari, 1999] Szalav´ ari, Z. (1999). The Personal Interaction Panel - a two-handed Interface for Augmented Reality. PhD thesis, Institute of Computer Graphics and Algorithms, Vienna University of Technology, Favoritenstrasse 9-11/186, A-1040 Vienna, Austria. [Thomas and Piekarski, 1993] Thomas, B. H. and Piekarski, W. (1993). Glove based user interaction techniques for augmented reality in an outdoor environment. Virtual Reality: Research, Development, and Applications, 6:2002. [Thrun et al., 2000] Thrun, S., Fox, D., Burgard, W., and Dellaert, F. (2000). Robust monte carlo localization for mobile robots. Artificial Intelligence, 128(1-2):99–141. [Umlauf et al., 2002] Umlauf, E. J., Piringer, H., Reitmayr, G., and Schmalstieg, D. (2002). Arlib: The augmented library. In on Digital Media Servers - Cable Labs Inc.

BIBLIOGRAFIE

80

[Vacchetti et al., 2004] Vacchetti, L., Lepetit, V., and Fua, P. (2004). Combining edge and texture information for real-time accurate 3d camera tracking. Mixed and Augmented Reality, IEEE / ACM International Symposium on, 0:48–57. [Wagner, 2007] Wagner, D. (2007). Handheld Augmented Reality. PhD thesis, Graz University of Technology. [Wagner et al., 2008a] Wagner, D., Langlotz, T., and Schmalstieg, D. (2008a). Robust and unobtrusive marker tracking on mobile phones. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 121–124. [Wagner et al., 2006] Wagner, D., Pintaric, T., Ledermann, F., and Schmalstieg, D. (2006). Towards massively multi-user augmented reality on handheld devices. Third International Conference on Pervasive Computing. [Wagner et al., 2008b] Wagner, D., Reitmayr, G., Mulloni, A., Drummond, T., and Schmalstieg, D. (2008b). Pose tracking from natural features on mobile phones. In 7th IEEE/ACM International Symposium on Mixed and Augmented Reality, 2008. ISMAR 2008., pages 125– 134. [Wagner and Schmalstieg, 2007] Wagner, D. and Schmalstieg, D. (2007). Artoolkitplus for pose tracking on mobile devices. In Proceedings of 12th Computer Vision Winter Workshop. [Wernecke, 1993] Wernecke, J. (1993). The Inventor Mentor: Programming Object-Oriented 3D Graphics with Open Inventor. Addison-Wesley, 2 edition. [Wernecke, 1994] Wernecke, J. (1994). The Inventor Toolmaker: Extending Open Inventor. Addison-Wesley, 2 edition. [You et al., 1999] You, S., Neumann, U., and Azuma, R. (1999). Hybrid inertial and vision tracking for augmented reality registration. pages 260–267. [Zhang, 1999] Zhang, Z. (1999). Flexible camera calibration by viewing a plane from unknown orientations. In The Proceedings of the Seventh IEEE International Conference on Computer Vision, 1999., volume 1, pages 666–673 vol.1.

LIJST VAN FIGUREN

81

Lijst van figuren 2.1

Reële bureautafel met een virtuele lamp en twee virtuele stoelen . . . . . . . . .

4

2.2

Het virtueel continuum volgens Milgram . . . . . . . . . . . . . . . . . . . . . . .

4

3.1

Links: de i-Visor HMD met één webcam om een monoscopische video see-through setup te bekomen. Midden: dezelfde i-Visor HMD, nu met 2 camera’s ter hoogte van de ogen om een stereoscopische video see-through setup te bekomen. Rechts: de Advisor 150 optical see-through HMD ontwikkeld door SAABTech. . . . . . .

3.2

7

Links: ARToolkit [Kato and Billinghurst, 1999] schat de positie van de camera en rendert een virtueel object op de 2D marker zichtbaar door de HMD. Rechts: ARToolkitPlus [Wagner and Schmalstieg, 2007] doet hetzelfde maar dan op een mobiele telefoon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3.3

10

Links: feature point tracking van meerdere objecten [Park et al., 2008]. Midden: SLAM: er worden feature points gezocht (links) en een map van gecreëerd (rechts) [Klein and Murray, 2007]. Rechts: AR applicatie met behulp van SLAM tracking: virtuele objecten worden in de wereld geplaatst [Klein and Murray, 2007]. . . . .

4.1

11

Augmented reality bordspellen met The Invisible Train (links) en Monkeybridge (rechts) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17

4.2

Meer actieve Augmented reality spellen zoals bowling of ping pong. . . . . . . . .

18

4.3

Met EyeToy heeft Sony al augmented reality games op de Playstation. Links: de speler moet met felgekleurde pomponnetjes de aangeduide bewegingen nadoen. Rechts: Kinetic Combat laat de speler het opnemen tegen virtuele tegenstanders.

19

LIJST VAN FIGUREN

4.4

82

De meest tot de verbeelding sprekende AR games zijn ongetwijfeld diegene waar de speler vrij rondwandelt in een augmented reality spelomgeving. . . . . . . . .

4.5

19

ARQuake leunt qua concept het dichtst aan bij WARGame, maar is niet gedistribueerd. Links ziet u het beeld in het spel, rechts de hardware setup die de speler draagt. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.6

De setup van WARGame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

21

5.1

Links: de scenegraph diagram dat een watermolecule voorstelt. Rechts: de 3D weergave van de molecule . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

5.2

De architectuur van WARGame gebouwd op het Studierstube platform

29

5.3

De verschillende stappen voor augmented reality op basis van markers zoals toe-

. . . . .

gepast in ARToolkit en consoorten [Kato and Billinghurst, 1999] . . . . . . . . .

30

5.4

De gebruikte markers: de 9 bit code wordt geëncodeerd in een 6x6 array . . . . .

31

5.5

Het punt Q = (X, Y, Z) wordt geprojecteerd op het projectievlak resulterend in het punt q = (x, y, f ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.6

32

Om over te gaan van het objectcoördinatenstelsel naar het cameracoördinatenstelsel wordt een rotatie en translatie van het assenstelsel uitgevoerd . . . . . . . . . . .

33

5.7

Voor de kalibratie worden afbeeldingen genomen van een schaakbordpatroon. . .

34

5.8

De verschillende spelobjecten in WARGame. . . . . . . . . . . . . . . . . . . . . .

35

5.9

De powerup (links) en vlag (rechts) zoals de speler ze in het spel ziet. . . . . . .

36

5.10 De Wii Remote heeft 6 vrijheidsgraden (3 translaties in X-,Y-,Z-richting en 3 rotatiehoeken pitch, roll en yaw), maar geeft slechts de 3 waarden van acceleratie in de X-,Y- en Z-richting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

37

5.11 Links: de RGB kleurenruimte. Rechts: de HSV kleurenruimte; kleuren met eenzelfde tint hebben eenzelfde Hue-waarde. . . . . . . . . . . . . . . . . . . . . .

38

5.12 Links: het input beeld. Rechts: het gegenereerde grijswaardenbeeld. Op beide afbeelding is ook de bounding box weergegeven berekend door het Camshift algoritme. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

LIJST VAN FIGUREN

83

5.13 Het Meanshift algoritme in actie: het zoekvenster wordt verplaatst zodat het naar de locatie gaat met hoge concentratie punten. Bron: [Bradski and Kaehler, 2008]

40

5.14 Wanneer er een speler gedetecteerd wordt, tekenen we een bounding box op het scherm samen met zijn naam. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

41

5.15 De speler kan zijn toestand steeds zien door middel van overlays op zijn beeld. .

42

5.16 Het protocol om te registreren en te deregistreren. . . . . . . . . . . . . . . . . .

44

5.17 Het protocol bij een schiet event. . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.18 Links: de plattegrond van het gebouw van de faculteit Ingenieurswetenschappen. Rechts: de kaart van signaalsterkte voor het UGentNet Wi-Fi netwerk. Hoe witter de kleur, hoe hoger de gemeten signaalsterkte. . . . . . . . . . . . . . . . .

50

5.19 Links: de grote kaart met daarop de plaatsen van de items en de geschatte locatie van de speler. Rechts: de kleine kaart rechtsbovenaan het scherm. De speler bevindt zich aan de bibliotheek. . . . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6.1

Verwerkingstijd op client 1, netwerktijd en verwerkingstijd op client 2. . . . . . .

55

6.2

Het vrije geheugen van de client in verloop van de tijd. . . . . . . . . . . . . . . .

56

6.3

Het % CPU tijd van de client in verloop van de tijd. . . . . . . . . . . . . . . . .

56

6.4

Het aantal berichten aankomend op de server bij het spelen van WARGame met 2 spelers. Het overgrote deel van de tijd komen er enkel 2 berichten van de locatie update binnen. Enkel wanneer de spelers interageren met een item of naar elkaar schieten krijgen we pieken tot 6 berichten per seconde. . . . . . . . . . . . . . . .

6.5

58

De gemiddelde, minimale en maximale verwerkingstijden op de server voor een shoot-bericht in het geval van 2, 5, 10 en 20 spelers. . . . . . . . . . . . . . . . .

59

6.6

De schaalbaarheid van de server. . . . . . . . . . . . . . . . . . . . . . . . . . . .

60

6.7

We vroegen testgebruikers om WARGame te spelen en achteraf een evaluatieformulier in te vullen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

61

6.8

De scores voor de vragen in verband met de hardware setup. . . . . . . . . . . .

62

6.9

De scores voor de vragen in verband met de verschillende features. . . . . . . . .

63

LIJST VAN FIGUREN

84

6.10 De scores voor de vragen in verband met de totale spelervaring. . . . . . . . . . .

65

7.1

De Vuzix Wrap 920 see-through HMD. Bron: Vuzix . . . . . . . . . . . . . . . .

66

7.2

Vuzix voorziet ook interessante accesoires voor de Wrap 920 zoals een 6-DOF tracker en een stereo camera rig. Bron: Vuzix . . . . . . . . . . . . . . . . . . . .

7.3

67

De 3rd Space Gaming vest ziet eruit als een kogelvrije vest, maar is voorzien van speciale cellen zodat je de impact van kogels in het spel kan voelen. Bron: TN Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

67

WARGame: creëren van een gedistribueerde augmented reality spelomgeving door het toevoegen van virtuele content aan de fysische wereld

Recommend Documents