2 Grundlagen der Arbeit

Transcrição

Entwicklung eines Augmented
Reality-Spiels
Studienarbeit
vorgelegt von
Tobias Daniel Kammann
Matrikelnr: 119920326
Institut für Computervisualistik
Arbeitsgruppe Computergraphik
Betreuer und Prüfer:
Prof. Dr.-Ing. Stefan Müller
September 2003
Inhaltsverzeichnis
1 Einleitung
2.1 Verwendung vorhandener Komponenten . . .
2.2 Funktionsweise des AR-Toolkits . . . . . . .
2.2.1 Übersicht . . . . . . . . . . . . . . .
2.2.2 Programmablauf . . . . . . . . . . .
2.2.3 Kameraposition . . . . . . . . . . . .
2.2.4 Installation des AR-Toolkits . . . . .
2.2.5 Anmerkung zur verwendeten Version
9
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
11
11
11
11
11
16
17
19
3 Entwicklung des Spiels
3.1 Planung eines interessanten Spiels . . . . . . . . . . . . . . . . . .
3.2 Angestrebtes Spielkonzept . . . . . . . . . . . . . . . . . . . . . .
3.3 Implementation des Spielprinzips . . . . . . . . . . . . . . . . . . .
3.3.1 Koordinatenbestimmung für Raumschiffe und Levelobjekte
3.3.2 Raumschiffsteuerung . . . . . . . . . . . . . . . . . . . . .
3.3.3 Joystick . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.4 Tor-Objekte . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.5 Kollisionserkennung . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
21
21
22
27
28
33
35
36
36
4 Ergebnisse
4.1 Das Spiel . . . . . . . . . . . . . . . . . . . . . . . . .
4.1.1 Spielkonzept . . . . . . . . . . . . . . . . . . .
4.1.2 Interaktionsmöglichkeiten . . . . . . . . . . . .
4.2 Umgesetzte Optimierungen . . . . . . . . . . . . . . . .
4.2.1 Schatten . . . . . . . . . . . . . . . . . . . . . .
4.2.2 Kollision mit realen Objekten . . . . . . . . . .
4.2.3 Automatische Höhenanpassung des Raumschiffs
4.2.4 Benutzererfahrungen . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
41
41
41
43
45
46
47
48
49
5 Fazit und Ausblick
5.1 Abgeschlossene Umsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Optimierungsansätze und Erweiterungen . . . . . . . . . . . . . . . . . . . . .
5.2.1 Erkennung der Markerposition . . . . . . . . . . . . . . . . . . . . . .
51
51
51
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
Inhaltsverzeichnis
5.2.2 Verdeckung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3 Fortführung des Spielkonzepts, Optimierung . . . . . . . . . . . . . .
Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
52
53
6 Anhang
6.1 Beispielprogramm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 Systemkonfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
55
55
60
5.3
6
Abbildungsverzeichnis
2.1
2.2
2.3
2.4
2.5
2.6
2.7
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
Prinzipielle Arbeitsweise des AR-Toolkits in mehreren Schritten . . . . . . . .
Objektstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Markerstruktur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Vergleich der gefundenen mit den gespeicherten Mustern . . . . . . . . . . . .
Kamera-Viewport und zwei Marker (schwarze Balken) im Blickfeld der Kamera
mit Positionsänderung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Marker-Informationsdatei . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Beispieldatei zu einem 3D-Modell . . . . . . . . . . . . . . . . . . . . . . . .
Der Benutzer trägt ein HMD und arbeitet mit Markern – der PC verschwindet
c
aus dem Blickfeld (Foto HITLab[9])
. . . . . . . . . . . . . . . . . . . . . .
Skizzen zur Brettspiel-Metapher-Erweiterung in die dritte Dimension . . . . .
Der Marker dient als Eingabegerät und die reale Physik soll nachgebildet werden
Konzeptskizzen zum Rennspiel . . . . . . . . . . . . . . . . . . . . . . . . . .
erste Studie zum Spielkonzept (Montage) . . . . . . . . . . . . . . . . . . . .
Objektpositionen sind relativ zum Zentrum des Bezugsmarkers . . . . . . . . .
Bestimmung der absoluten Objektposition zur Darstellung im Kamerakoordinatensystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bei Ausfall des linken Markers wird der Offset bestimmt. . . . . . . . . . . . .
Im Anschluss wird der neue Marker als Bezugspunkt verwendet. . . . . . . . .
Schritt 1: Sollte zum gegenwärtigen Zeitpunkt noch kein Marker als Referenz
benutzt werden, wird der erste sichtbare als Marker gewählt (der weiß umrahmte
Marker ist der Bezugsmarker). . . . . . . . . . . . . . . . . . . . . . . . . . .
Schritt 2: Kommen weitere Marker ins Bild, ändert sich der Referenz-Marker
zunächst nicht. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Schritt 3: Befinden sich mehr als ein Marker im Zentrum des Bildes, ändert
sich die Referenz nicht. Sollte jedoch der derzeitig gewählte Marker das Zentrum verlassen, wird der neue Referenzmarker der Marker, der dem Zentrum am
nächsten und sichtbar ist. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Bestimmung der neuen Objektposition bei Eigenbewegung . . . . . . . . . . .
Richtungswechsel des Raumschiffs . . . . . . . . . . . . . . . . . . . . . . . .
Bounding Box-Ausrichtung am obj-Koordinatensystem – nicht an cam . . . .
Kollisionsprüfung an Toren über outside_hit und inside_hit . . . . . . . . . . .
Punktabstand zu einem Polygon: abovePolygon() . . . . . . . . . . . . . . . .
12
14
14
15
16
18
18
23
24
24
25
27
29
29
30
31
32
32
33
34
35
37
38
39
7
Abbildungsverzeichnis
8
4.1
4.2
4.3
4.4
4.5
4.6
4.7
4.8
4.9
4.10
Das Heads-Up-Display im Spiel . . . . . . . . . . . . . . . . . .
Navigationshilfe mit Pfeilen . . . . . . . . . . . . . . . . . . . .
Gegnerische Drohnen stören den Spieler . . . . . . . . . . . . . .
Menüsteuerung über Handrückenmarker . . . . . . . . . . . . . .
Werkzeug-Marker zur Manipulation: Modellauswahl per Drehung
Drehen des Werkzeugs zum Anpassen der Tor-Größe . . . . . . .
optimierte Orientierung durch Schlagschatten . . . . . . . . . . .
Kollisionserkennung mit realen Objekten . . . . . . . . . . . . .
Kollision mit realen Objekten, die unter dem Marker stehen . . . .
Optische Verzerrung der Kamera . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
42
42
43
44
45
45
46
47
48
49
5.1
Verdeckung der augmentierten Objekte durch reale Gegenstände (Montage) . .
52
1 Einleitung
Augmented Reality (AR) bedeutet soviel wie „erweiterte Realität“. Dabei handelt es sich um die
Überlagerung realer Bilder (Fotos oder Videos) mit computergenerierten Bildern, welche sich
abhängig von Position und Blickwinkel des Betrachters perspektivisch korrekt in die reale Szene
einpassen. Meistens wird Echtzeit angestrebt, so dass für den Betrachter der Eindruck entsteht,
die aus dem Rechner stammenden Bilder wären Teil der realen Welt.1
Ziel der Arbeit soll es sein, diese Technologie in einer konkreten Umsetzung kennenzulernen und zur Realisierung einer eigenen Applikation zu benutzen. Die Wahl fiel hierbei auf ein
AR-Spiel. Das Konzept soll geplant, realisiert und verschiedene Interaktionsmöglichkeiten untersucht werden.
1
Nähere Informationen zu dieser Technologie und zu verwendeten Termini werden in dieser Ausarbeitung nicht
gegeben. Die im Anhang genannten Quellen sollten als Referenz genügen.
9
1 Einleitung
10
2.1 Verwendung vorhandener Komponenten
Die Realisierung einer Augmented-Reality-Anwendung, die mit optischen Markern arbeitet,
benötigt viele Komponenten. Neben der Darstellung der computergenerierten Bilder und dem
Capturen des Kamerabildes muss die komplette Bildverarbeitung zur Erkennung und Verarbeitung der Musterfelder implementiert werden. Da es unmöglich wäre, all diese Komponenten
im vorgegebenen Zeitraum selbst zu entwickeln, wurde beschlossen, auf vorhandene Software
aufzubauen.
Verschiedene Pakete bieten die nötige Funktionalität: etwa das Programm der Gruppe „The
Essex Virtual Applications, Systems and Environments Laboratory“ [1] oder das „AR-Toolkit“
des „Human Interface Technology Labs Washington“ [2]. In dieser Arbeit wird letzteres verwendet.
2.2 Funktionsweise des AR-Toolkits
2.2.1 Übersicht
Das Programmpaket ist in C++ geschrieben, für verschiedene Plattformen (Windows, Linux,
SGI, MacOS, MatLab) erhältlich und komplett mit den Quellcodes für wissenschaftliche Zwecke
kostenlos herunterlad- und einsetzbar[3].
Es umfasst alle grundlegenden Funktionen zur Umsetzung einer markerbasierten Augmented
Reality-Anwendung – sowohl für optical als auch für video-see-through Head Mounted Displays
(HMDs). Mitgelieferte Kalibrierungstools (auch mit Quellcode) erleichtern die Anpassung an
verwendete Hardware (Kamera, HMD, Markermuster).
2.2.2 Programmablauf
Die wichtigsten Arbeitsschritte sollen kurz erläutert werden. Diese werden bei jedem Durchlauf
der Programmschleife wiederholt.
Zunächst wird der nächste verfügbare Videoframe eingelesen und mit einem definierbaren
Schwellwert binarisiert. Nach dieser Farbreduktion wird das Bild nach Rechtecken durchsucht
und eine Liste aus allen gefundenen Elementen erstellt (Abb. 2.1 (rot markiert)). Dabei muss es
sich aber nicht nur um den gewünschten Marker handeln - sämtliche Gegenstände im Bild, die
eine „Rechteck-verwandte“ Form besitzen, können erkannt werden. Selbst eine geballte Faust
oder Schattenwürfe an der Tastatur liefern gelegentlich Rechteck-Informationen. Diese fehlerhafte Erkennung stört jedoch im Normalfall nie, wie sich im Folgenden zeigen wird.
11
Für all diese gefundenen Rechtecke werden die Translation und Rotation abhängig zum Kamerakoordinatensystem bestimmt und gespeichert. Im Anschluss vergleicht das AR-Toolkit die
Muster, die vortrainiert sind und die es erkennen soll, mit den vermeintlichen Mustern, die im
aktuellen Frame in den Rechtecken liegen. Sind mehrere Übereinstimmungen vorhanden, entscheidet der Grad der Ähnlichkeit, welches Rechteck letztlich ausgewählt wird. Das heißt, ein
Musterfeld darf nur einmal im Sichtbereich der Kamera vorkommen bzw. wird nur einmal erkannt. Eine zufällige rechteckige Form wird also an dieser Stelle aussortiert, da die Ähnlichkeit
zu den gespeicherten Mustern selten groß genug ist.
Zu den Rechtecken wird jeweils die Marker-ID gespeichert, sofern es eine Übereinstimmung
gibt.
Während des Programmabschnitts, in dem die Darstellung abläuft, kann aus der pro Rechteck gespeicherten Information die entsprechende Transformationsmatrix ausgelesen und zum
Ausrichten der 3D-Objekte verwendet werden. Das AR-Toolkit zeichnet zunächst den aktuellen Videoframe als Hintergrund (bei optical-see-through fällt dieser Schritt weg) und überlagert
diesem im Anschluss alle weiteren gerenderten 3D-Graphiken, deren Position und Rotation mit
der gespeicherten Matrix multipliziert wird.
Abbildung 2.1: Prinzipielle Arbeitsweise des AR-Toolkits in mehreren Schritten
12
Der Ablauf für jeden Frame eines einfachen Beispielprogramms beinhaltet dann nach der
Initialisierung mindestens folgende Aufrufe des AR-Toolkits (Punkt 5 wird weiter unten exemplarisch vorgestellt, die Methoden sind ohne Parameter aufgeführt):
1. camera.grabFrame()
liefert das aktuelle Bild
2. argDrawMode2D()
„schaltet um“ in den Zeichenmodus für das Videobild
3. argDispImage()
der aktuelle Frame wird angezeigt
4. arDetectMarker()
Rechtecke werden gefunden und mit den vortrainierten Markern verglichen
5. Auswahl der richtigen Matrix (Vergleich der gespeicherten Marker-IDs)
6. argDrawMode3D()
Umschalten in den OpenGL-Modus
7. argDrawCamera()
Festlegen des glViewPorts
8. Laden der Matrizen und Zeichnen der 3D-Objekte
9. argSwapBuffers()
am Ende der Programmschleife wird der neue Frame gezeichnet und der FrameBuffer
gewechselt
Die Speicherung der Marker-Informationen und der Matrizen erfolgt in AR-Toolkit eigenen
Typen (Typedefs). An dieser Stelle sollen nur die wichtigsten Variablen und Methoden des ARToolkits erwähnt werden. Eine ausführliche Dokumentation über die verbleibenden Elemente
liegt zwar leider auch beim HITLab nicht vor, doch liefern die Header-Dateien meist genügend
Auskunft über die Funktionen. Zusätzlich ist das komplette Listing eines einfachen Beispielprogramms in Abschnitt 6.1 angefügt.
Die zwei wichtigsten Strukturen des Toolkits sind in Abbildung 2.2 und 2.3 aufgeführt. Sie
werden zum Verwalten der Marker- und Objekt-Informationen verwendet. ARMarkerInfo
speichert die aktuellen Werte für einen im Bild gefundenen Marker (Ähnlichkeitswert (cf),
Marker-ID (id), 3D-Koordinaten der Rechteck-Eckpunkte, ...). ObjectData_T enthält für
jedes vordefinierte 3D-Objekt unter anderem die aktuelle Matrix zur Positionierung, die assoziierte Marker-ID (id), sowie einen als Boolean verwendeten Integer-Wert „visible“. Dieser gibt
an, ob das Objekt derzeitig im Bild zu sehen ist (d.h. ob zur Zeit der mit dem Objekt verknüpfte
Marker sichtbar ist). Verwendet man mehr als einen Marker in seinem Programm, kann man
jeweils ein Array für obige Strukturen verwenden.
Um in jedem Frame die aktuellen Werte geliefert zu bekommen, muss zunächst die Methode
13
typedef struct {
char
name[256];
int
id;
int
visible;
double
marker_coord[4][2];
double
trans[3][4];
double
marker_width;
double
marker_center[2];
} ObjectData_T;
Abbildung 2.2: Objektstruktur
typedef struct {
int
area;
int
id;
int
dir;
double cf;
double pos[2];
double line[4][3];
double vertex[4][2];
} ARMarkerInfo;
Abbildung 2.3: Markerstruktur
arDetectMarker(dataPtr, thresh, &marker_info, &marker_num)
aufgerufen werden. Ihr wird die Bildinformation (dataPtr), der zu benutzende Schwellwert
für die Binarisierung (thresh im Bereich von [0,255]), sowie eine Referenz auf das
ARMarkerInfo-Array und einen Integer-Wert marker_num übergeben.
Nach dem Beenden dieser Methode enthält das Array die aktuellen Marker-Werte, und
marker_num gibt an, wie viele Muster im aktuellen Frame gefunden wurden.
Es kann mit einer Schleife geprüft werden, ob die gefundenen Muster zu den verwendeten
Objekten gehören (Abb. 2.4). Man vergleicht die Objekt-Marker-ID mit der in marker_info
gespeicherten ID. Werden mehrere Übereinstimmungen gefunden, entscheidet der höchste Ähnlichkeitswert (cf). Kann keine Übereinstimmung gefunden werden, wird das Objekt als nicht
sichtbar definiert (object[i].visible = 0).
Wurde ein Objekt hingegen erfolgreich entdeckt, wird die Methode arGetTransMat()
bzw. arGetTransMatCont() aufgerufen, welche die Objektdaten (u.a. die Transformationsmatrix) aktualisiert.
Nach diesem Update kann man die gespeicherten Matrizen nutzen, um die 3D-Objekte korrekt
auszurichten.
Anzumerken ist hier, dass ein Objekt die zuletzt erkannten Koordinaten behält, sollte es nicht
gefunden werden; nimmt man etwa einen Marker aus dem Bild, so ist die aktuelle Position
14
for( i = 0; i < objectnum; i++ ) {
k = -1;
for( j = 0; j < marker_num; j++ ) {
if( object[i].id == marker_info[j].id ) {
if( k == -1 ) k = j;
else {
if( marker_info[k].cf < marker_info[j].cf ) k = j;
}
}
}
if( k == -1 ) {
object[i].visible = 0;
continue;
}
}
if( object[i].visible == 0 ) {
arGetTransMat( &marker_info[k], object[i].marker_center,
object[i].marker_width, object[i].trans);
} else {
arGetTransMatCont(&marker_info[k], object[i].trans,
object[i].marker_center,
object[i].marker_width, object[i].trans);
}
object[i].visible = 1;
number_of_visible_markers++;
}
Abbildung 2.4: Vergleich der gefundenen mit den gespeicherten Mustern
15
stets die veraltete. Eine Prüfung über (object[i].visible != 0) ist daher nötig, um
nur gültige Werte abzufragen.
2.2.3 Kameraposition
Das AR-Toolkit selbst setzt die Kamera stets in den Ursprung des internen Koordinatensystems.
Sobald in der Methode argDrawMode3D() in den 3D-Modus geschaltet wird, wird auch die
Kamera eingestellt. Der OpenGL-Viewport definiert sich durch die Größe des Kamerabildes
(gImYsize und gImXsize) und einen Vergrößerungsfaktor (gZoom). Die Position der Kamera bleibt dabei unverschoben im Koordinatenursprung, wodurch sich eine Blickrichtung entlang der positiven z-Achse ergibt (siehe Abb. 2.5).
void argDraw3dCamera( int xwin, int ywin ){
...
glViewport(0, gWinYsize-(int)(gZoom*gImYsize),
(int)(gZoom*gImXsize), (int)(gZoom*gImYsize));
...
Abbildung 2.5: Kamera-Viewport und zwei Marker (schwarze Balken) im Blickfeld der Kamera
mit Positionsänderung
Bewegt der Anwender die Marker im Blickfeld der Kamera, ändern sich erwartungsgemäß
auch deren Koordinaten. Wird stattdessen die Kamera selbst bewegt, während die Marker ihre
Position behalten, ändern sich allerdings auch die Koordinaten selbiger. Alle im Bild befindlichen Marker verändern ihre Koordinaten in der Welt, auch wenn sie sich nicht bewegen. Die
Position wird immer relativ zur Kamera neu bestimmt.
Ein anderes Vorgehen wäre mit dem AR-Toolkit auch gar nicht möglich, da die Marker die
einzigen Bezugspunkte zur realen Welt sind (die Kamera selbst wird nicht zusätzlich getrackt,
16
die Positionsbestimmung ist also nur über die Marker „inside-out“ möglich). Diese Tatsache
spielt eine entscheidende Rolle beim Design des Spiels (Kapitel 3).
2.2.4 Installation des AR-Toolkits
Im Folgenden sollen so knapp wie möglich die ersten Programmierschritte beschrieben werden. Die Arbeit ist Performance- und Kompatibilitätsgründen nur auf der Microsoft WindowsPlattform in C++ entwickelt worden und es wird daher nur auf diese eingegangen.
Das Toolkit gibt es auf der Webseite des HITLabs [2] in allen bisher erschienen Versionen zum
Download. Für Windows gibt es zwei Varianten. Eine greift auf das Microsoft VisionSDK und
eine auf Microsofts DirectX zurück. Da das VisionSDK nicht mehr weiterentwickelt wird und
die aktuellsten Versionen des AR-Toolkits stets auf DirectX aufsetzen, verwendet das Spiel letztere Variante. Zum Ausführen und Kompilieren benötigt man folglich das kostenlose DirectXSDK [6].
Jedes AR-Toolkit-Paket enthält neben einigen Beispiel- und den erwähnten Kalibrierungsprogrammen den kompletten Satz aller Quell- und Headerdateien sowie der einzubindenden
Bibliotheken (Diese können selbstverständlich auch selbst aus den Quellen erstellt werden).
Zur Verwendung der Toolkit-Funktionalität muss man in seinem Projekt einiges einbinden:
1. Das Include-Verzeichnis muss auf den mitgelieferten „include“-Ordner des Pakets und auf
die DirectX-SDK Headerdateien verweisen
2. Als zusätzliche Bibliotheksordner muss der „lib“-Ordner des Pakets deklariert werden
3. Je nach AR-Toolkit-Version können die einzubindenden Bibliotheken variieren. Essentiell
sind folgende:
strmiids.lib, glu32.lib, glut32.lib, opengl32.lib, ARFrameGrabber.lib, libAR32.lib,
libARgsub32.lib, dxguid.lib
4. Zum Ansteuern der 3D-Schnittstelle wird die GLUT verwendet, die mitgeliefert wird. Per
Präprozessor-Befehl müssen folgende Headerdateien inkludiert werden:
windows.h, GL/gl.h, GL/glut.h, AR/gsub.h, AR/ARFrameGrabber.h,
AR/param.h, AR/ar.h
Beim Toolkit sind bereits einige Marker als Bilddateien mitgeliefert, die man ausdrucken und
mit den Beispielprogrammen direkt verwenden kann.
Die VRML unterstützende Version des Toolkits benötigt neben einer Datei für die Kamerakonfiguration und den Dateien für die Marker weitere Dateien. Eine vrml_data speichert die
Anzahl der zu erkennenden Marker und für jedes Muster einen Verweis auf eine weitere Datei für das 3D-Modell, sowie die Angabe über die zu verwendende Musterdatei, die Größe des
Markers in Millimetern und einen Offset vom Mittelpunkt (zur Darstellung des 3D-Modells).
Die Dateien, die zu den 3D-Modellen gehören, enthalten die Angabe über die zu verwendende VRML-Datei, sowie Informationen über eine zu benutzende Translation, Rotation und
Skalierung. Zusätzlich werden Beleuchtungswerte gespeichert, die nur für das jeweilige Modell
angewandt werden.
17
########################################
# Anzahl der zu registrierenden Muster
2
#pattern 1
VRML Wrl/3dmodell1.dat
# Extradatei für das VRML-Modell
Data/pattern1.patt
# dem Modell zugeordnetes Muster
40.0
# Kantenlänge des Markers in mm
0.0 0.0
# Offset zum Mittelpunkt
#pattern 2
VRML Wrl/3dmodell2.dat
Data/pattern2.patt
70.0
0.0 0.0
########################################
Abbildung 2.6: Marker-Informationsdatei
########################################
Wrl/model.wrl
# Angabe über die zu verwendende VRML-Datei
0.0 0.0 0.0
# Translation - x,y,z vom Mittelpunkt des Markers
0.0 0.0 0.0 0.0 # Rotation Winkel + Achse, zB. 90.0 1.0 0.0 0.0
2.5 2.5 2.5
# Skalierung x,y,z
LIGHT DIR
# gerichtete Lichtquelle
0.5
# Ambient
1.0
# Intensität
1.0 1.0 1.0
# RGB
0.0 0.0 1.0
# Richtung
########################################
Abbildung 2.7: Beispieldatei zu einem 3D-Modell
18
Das Vorgehen bei der nötigen Kamerakalibrierung und beim Erstellen eigener Marker ist ausreichend in der Dokumentation des HITLabs beschrieben.
2.2.5 Anmerkung zur verwendeten Version
Begonnen wurde die Studienarbeit mit der Version 2.52, die bereits die Darstellung von VRMLModellen ermöglicht. Jedoch ist hier die Auflösung der Kamera auf 320x240 Pixel beschränkt.
In einer späteren (inoffiziellen) Nachfolge-Version, die von der Technischen Universität Wien[7]
online zur Verfügung gestellt wird, ist diese Beschränkung aufgehoben, so dass aus diesen zwei
unterschiedlichen Versionen eine eigene entwickelt wurde. Dies war nötig, da die Variante der
Virtual Reality Group in Wien keine VRML-Graphiken verarbeiten konnte.
19
20
3.1 Planung eines interessanten Spiels
Zunächst soll kurz untersucht werden, was Computerspiele im Allgemeinen interessant macht
und den Benutzer motiviert.
Da die Leistungsfähigkeit der PCs und der Spielekonsolen stetig wächst, steigen die Erwartungen der Spieler vor allem gegenüber der Graphik nahezu linear an. Vergleicht man aufwendig
produzierte, kommerzielle Spiele mit Spielen eines älteren Jahrgangs, fallen zum Beispiel stets
graphische Innovationen auf, die dem Spieler ein Anreiz sein sollen, das Programm zu spielen - respektive zu kaufen. Selbst für den Spielfluss uninteressante Änderungen (realistischerer
Schatten, Detailgrad bei Gegenständen, die nichts zum Spielgeschehen beitragen) werden bestaunt und als motivierendes Element angegeben1 .
Neben dieser Effektshow mit „noch besserer Graphik als in der letzten Version“ sind andere
Möglichkeiten Interesse zu wecken beispielsweise ein völlig neuartiges Spielkonzept, was bereits durch seine Einzigartigkeit anziehend wirkt, oder umgekehrt ein bekanntes (an die reale
Welt angelehntes) Thema umsetzt. Da bei Letzterem ein Abbild der realen Welt simuliert wird,
ist das Prinzip und das Spielziel meist bekannt und eine Eingewöhungszeit nicht so lang, wie es
bei einem neuen Spielkonzept der Fall wäre.
Ist der Spieler begeistert an das Spiel herangegangen, kann es dennoch passieren, dass das
Interesse an dem Werk schnell nachlässt. Das kann zum einen technische Gründe haben – etwa
als zu schlecht empfundene Graphik, Programmfehler, unkomfortable Bedienung – oder auch
am Konzept des Spiels oder der Story selber liegen. Neben technischen Aspekten sind also
verschiedene inhaltliche Punkte zu beachten:
• wird die Storyline gut fortgeführt?
• gibt es unerwartete Wendungen?
• existiert eine Steigerung im Spielverlauf?
• kann der Spieler in die Welt eintauchen?
• ist ein guter Spannungsbogen/Cliffhanger vorhanden?
• wird der Spieler für seine Aktionen belohnt?
• gibt es humoristische Einlagen oder andere unterhaltende Elemente in ausreichender Anzahl?
1
nicht-repräsentative Umfrage des Autors
21
• gibt es genügend andere motivierende Faktoren im Spiel? (z.B. Geschwindigkeitsrausch
oder die Befriedigung des „Jäger und Sammler“-Prinzips)
Gibt es im Spielverlauf keine Veränderungen, geht der Spielspaß verloren, und das gesamte
Programm war eine Eintagsfliege. Der Aufwand dürfte sich kaum gerechtfertigt haben. Bei der
Frage, waelche Art Spiel die Augmented Reality-Technologie am besten in Szene setzen würde,
mussten neben obigen Überlegungen zusätzlich verschiedene weitere Aspekte berücksichtigt
werden:
1. das Spiel soll nicht zu komplex sein – es muss den Benutzer schnell in seinen Bann ziehen
können und unterhalten (zunächst soll die Technologie im Vordergrund stehen und nicht
eine komplexe, große Geschichte)
2. es soll die Vermischung der virtuellen und der realen Welt gut realisieren und sie im Spielprinzip und bei der Interaktion möglichst effektiv ausnutzen
3. die Kosten sollen möglichst gering sein, bzw. eine Benutzung ohne teure Head-MountedDisplays u.ä. ist wünschenswert
4. es soll trotzdem noch genügend Raum bieten, um eine interessante Spielgestaltung (verglichen mit „normalen“ Computer-Arcade-Spielen) zu ermöglichen
5. der Spielfluss sollte möglichst stabil sein – auch wenn das Tracking für Bruchteile vorübergehend aussetzt
3.2 Angestrebtes Spielkonzept
Das Augenmerk bei der Entwicklung der Spielidee lag vor allem auf den letztgenannten fünf
Punkten. Die Technologie soll möglichst effektiv genutzt werden. Ein durchschnittliches Computerspiel, das nur zufällig auf Marker projiziert wird (statt auf den Bildschirm) und die reale
Umgebung gar nicht mit einbezieht, wäre nur die zweite Wahl.
Da durch die Benutzung des AR-Toolkits die Kosten fest eingegrenzt waren (vorerst das Arbeiten mit einer einfachen Webcam, den selbst ausgedruckten Papier-Markern und später die
Benutzung eines HMDs) klärt sich Punkt 3 von selbst. Mir waren von den übrigen Punkten die
Einbeziehung des realen Raums und die Einfachheit des grundlegenden Spielprinzips am wichtigsten. Die ersten Ideen beschränkten sich meist auf nur einen Marker, der entweder vor dem
Spieler auf dem Tisch liegen sollte oder den der Spieler in die Hand nehmen muss. Die Metapher eines normalen Brettspiels, welches man am Wohnzimmertisch mit Freunden spielen kann,
sollte benutzt werden, um ein AR-Erlebnis aufzubauen. Der Vorteil dieses Systems liegt in der
Sicherheit des Trackings, da nur ein großer Marker benötigt wird und auch keine Verwechslungen beim Tracking entstehen. Die Position ist fest und der Betrachter sitzt etwa immer im
selben Winkel zum Marker. Gelegentliches Annähern oder Herumgehen, um das Spielfeld aus
einem anderen Blickwinkel zu betrachten, stören nicht. Das Bild bleibt stabil und ermöglicht die
Konzentration auf das eigentliche Spielgeschehen.
22
Somit könnte man ein klassisches Brettspiel ins Dreidimensionale erheben (Spielfelder können sich in den Himmel erstrecken und so mit normalen Brettspiel-Materialien normalerweise
niemals konstruierbare Welten entstehen lassen) und zusätzlich mit Anweisungen, Musikeffekten und Animationen anreichern. Gleichzeitig kann eine KI eingebunden werden, oder man hat
die Möglichkeit über das Internet mit einem Freund zu spielen, der zu Hause vor seinem „Brettspiel“ sitzt. Der Benutzer trägt dann bestenfalls nur noch das HMD mit Kopfhörern und schiebt
einige Marker auf dem Tisch hin und her. Der dahinter rechnende PC verschwindet bestenfalls
ganz aus der Wahrnehmung des Benutzers. Monitor, Tastatur und Maus sollen bei der Bedienung
überflüssig sein (Abb. 3.1).
Abbildung 3.1: Der Benutzer trägt ein HMD und arbeitet mit Markern – der PC verschwindet
c
aus dem Blickfeld (Foto HITLab[9])
Für die Studienarbeit fiel die Wahl aber gegen die Brettspiel-Variante, da diese Idee zu viel
Gamedesign enthalten hätte und zu wenig Tracking benötigt, welches aber ausführlicher untersucht werden wollte. Die Einbeziehung der realen Welt in das Spielgeschehen ist auch nicht sehr
groß. Der einzige Vorteil läge tatsächlich darin, nicht vor dem Rechner sitzen zu müssen und die
Blickposition durch reale Kopfbewegung vorzugeben (statt durch Maus, Joystick, Tastatur).
Die nächste Variante bietet mehr Immersion. Ein Labyrinth-Spiel soll auf einem großen Marker dargestellt werden. Durch diese erscheinenden Räume muss der Benutzer eine Kugel steuern, indem er den Marker in die Richtung neigt, in die die Kugel rollen soll. Dadurch erreicht
man eine äußerst intuitive Eingabe. Das Murmel-Labyrinth-Prinzip weckt Erinnerungen (an das
Holzlabyrinth aus der Kindheit), ist vertraut und kann gut durch verschiedene Level, Animationen und Sounds zu einem spannenden Erlebnis werden. Allerdings wäre hier der einzige Vorteil
von AR die intuitive Eingabe gewesen. Das Spiel selber erscheint immer auf dem Marker, den
man direkt vor sich hält. Der restliche reale Raum wird gar nicht mit einbezogen und auch
nicht mehr wahrgenommen. Hätte man beispielsweise einen Joystick mit Trägheitssensor, wäre
das Ganze sogar eleganter, da das Tracking bei Verdeckung oder schlechten Lichtverhältnissen
nicht ausfallen könnte. Die Benutzung der optischen Marker bietet keinen Vorteil.
23
Abbildung 3.2: Skizzen zur Brettspiel-Metapher-Erweiterung in die dritte Dimension
Abbildung 3.3: Der Marker dient als Eingabegerät und die reale Physik soll nachgebildet werden
Das angestrebte Spielprinzip versucht daher, vor allem den realen Raum, in dem gespielt wird,
in das Spielgeschehen zu integrieren. Es musste eine alles beeinflussende Entscheidung getroffen werden: Soll der Benutzer die Marker frei positionieren dürfen oder sollen sie im Raum fest
fixiert angebracht werden? Beides hat gewisse Vor- und Nachteile. Letztere Variante würde es
etwa ermöglichen, den realen Raum in der 3D-Welt nachzubilden und die Position des Spielers
in dieser virtuellen Welt über das Tracking zu bestimmen. Man würde also die reale Welt im
Rechner modellieren und feste Punkte definieren, wo Marker in dieser Welt zu liegen haben.
Erscheint dann ein Marker im Sichtfeld der Kamera, ist die Position des Betrachters eindeutig
bestimmt. Gleichzeitig könnte man so eine sehr genaue Reaktion auf die realen Objekte simulieren. Modelliert man einmalig den realen Raum im Computer und speichert die Informationen im
Programm, können z.B. Verdeckungen und Kollisionen mit realen Objekten sehr gut realisiert
werden.
24
Der Nachteil an dieser Version ist natürlich, dass die Informationen über den realen Raum
vorab einmal gespeichert werden müssen. Der Benutzer kann nicht in jedem beliebigen Raum
das Spiel benutzen und somit den „Level-Aufbau“ nicht variieren.
Eine Möglichkeit zur Veränderung des Spielfelds wäre allerdings denkbar. Der Benutzer verteilt im mit Markern (die zur Positionsbestimmung des Spielers dienen) bestückten Raum weitere Musterfelder, die am Anfang des Spiels registriert werden und entsprechende Objekte an den
übergebenen Koordinaten in der virtuellen Welt erscheinen lassen. Nach der Initialisierungsphase des Spiels könnte der Benutzer also alle selbst verteilten Marker wieder entfernen, da die
3D-Koordinaten dem Programm nur einmal mitgeteilt werden müssen. Danach genügen die fest
installierten Felder zur Blickpunktbestimmung. Auf diese Art könnte der Benutzer dem Programm neue reale Gegenstände im Raum „beibringen“ und speichern lassen.
Wegen dieser beschriebenen Komplexität bzw. Unhandlichkeit und dem Wunsch nach einem
komplett frei bestimmbaren Spielfeld, fiel die Wahl auf die andere Version. Der reale Raum ist
dem Programm nicht bekannt. Als Referenz dienen nur die Marker, die aber teilweise Aufschluss
über Objekte im realen Raum liefern können (z.B. liegt ein Marker immer auf einer Fläche, woraus folgt, dass auf selber Höhe eine Kollision erfolgen muss – eine Bezug zur realen Grundlage
wird dadurch also letztlich doch hergestellt).
Nach dieser Entscheidung war das Konzept relativ schnell gefunden. Die Marker sollen eine
Rennstrecke definieren, indem über ihnen eine verbindende Bahn aufgespannt wird oder auf
jedem Marker ein Tor erscheint, welches der Spieler durchqueren muss.
Abbildung 3.4: Konzeptskizzen zum Rennspiel
Die Rennstrecke, die aufgespannt wird, hätte für den Benutzer einen starken Wiedererkennungswert, da das Spiel wie eine Carrera-Bahn funktionieren würde – mit dem Vorteil, dass
man das Fahrzeug komplett frei steuern könnte und die Strecke nicht zusammensteckt, sondern
durch Verschieben der Marker festläge.
Das einzige Problem bei dieser sonst sehr interessanten Idee ist die Beschränkung durch das
optische Tracking. Ist ein Marker nicht im Bild, fällt sofort ein Teil der Strecke aus, da die Bahn
zwischen je zwei Markern aufgespannt wird.
25
Um dieses Problem zu umgehen, hätte man sicherlich die letzte Position (in Relation zu den
noch sichtbaren Markern) zwischenspeichern können, um so ein stabiler arbeitendes Programm
zu erhalten. Interessant wäre an dieser Version auch das dynamische „Verbiegen“ der Strecke
durch das Verschieben der Marker. Die aufgespannte Bahn könnte mit Kurven (Bezierkurven,
Splines) umgesetzt werden, und das Bewegen der Muster hätte eine in Echtzeit realisierte Anpassung zur Folge.
Doch da diese erste Variante wieder weitere Probleme nach sich ziehen würde (zu schnelle
Kopfbewegungen, Latenz bei der Darstellung und dadurch bedingter Ausfall von Streckenabschnitten), wurde die zweite ausgewählt: auf je einem Marker erscheint ein einzelnes Tor. Der
Spieler muss alle Tore im Level in vorgegebener Reihenfolge durchqueren. Fällt ein Marker aus,
verschwindet nur der eine Streckenposten, der unabhängig von den anderen funktioniert. Der
einzige Nachteil beim Ausfall ist, dass der Spieler das nicht sichtbare Objekt nicht ansteuern
bzw. durchqueren kann.
Als Szenario wurde ein Weltraumrennen festgelegt, bei dem ein Raumschiff gesteuert werden
muss. Dies passt zum einen besser zu der neuen verwendeten Technologie und ermöglicht es
auch, sich frei im 3D-Raum zu bewegen (anstatt nur auf dem Boden). Der Spielspaß mit dem
ferngesteuerten Auto wird so im 21. Jahrhundert zum Vergnügen mit dem eigenen, ferngesteuerten Raumschiff.
Im Spielprinzip vorgesehen ist, dass der Spieler zu Beginn alle Marker im Raum verteilt, so
dass stets zwei im Blickfeld der Kamera liegen (siehe unten). Die Musterfelder auf denen später
Tore erscheinen sollen, können auf Tischen, Gläsern, an der Wand, der Decke, usw. angebracht
werden. Der Spieler bestimmt so individuell bei jedem Neustart die Strecke durch sein Wohnzimmer, seine Küche, etc.
Das Spiel umfasst verschiedene Marker. Einige stecken die Rennstrecke ab, andere haben eine
spezielle Funktion und definieren beispielsweise die Startposition der Raumschiffe.
Nach dem Verteilen beginnt die Partie (es ist keine zusätzliche Konfiguration nötig, der Spieler
muss nur die Startposition im Blickfeld haben).
Um eine Runde abzuschließen, muss der Spieler alle Tore durchqueren. Raumschiffe – vom
Computer oder von menschlichen Personen gesteuert – treten im Rennen gegeneinander an, und
der schnellste Spieler gewinnt nach einer festen Anzahl von Runden.
Zusätzlich soll es Gegenstände geben, die abseits der Strecke erscheinen. Sammelt man sie
ein, erhält man Punkte oder Upgrades (schnelleres, wendigeres Schiff, ...) als Belohnung.
Im Arcade-Modus wird umgekehrt nicht nach Runden gespielt sondern auf Zeit. Der Spieler
versucht, möglichst viele Runden zu fliegen und Punkte zu sammeln. Die verbleibende Zeit läuft
stetig ab und kann nur durch das Abschließen einer Runde oder das Einsammeln von Gegenständen wieder aufgestockt werden.
Neben den Raumschiffen der anderen Spieler verhindern herumschwirrende Drohnen das einfache Abfliegen der Strecke. Bei Kontakt mit dem Schiff verursachen sie Schaden, so dass je
nach Kapazität der Schilde der Spieler schon nach wenigen Treffern aus dem Rennen sein kann.
Neben (hoffentlich) nervenaufreibenden Ausweichmanövern kann man die Drohnen auch mit
seinem Laser in Vakuum auflösen. Je nach Ausstattung des Raumschiffs verursacht der Laser
mehr oder weniger Schaden und kann häufiger oder seltener abgefeuert werden.
26
3.3 Implementation des Spielprinzips
Abbildung 3.5: erste Studie zum Spielkonzept (Montage)
Bestimmte Punkte-Grenzen bringen Extraleben oder verbessern das Raumschiff in seiner
Wendigkeit, Stabilität oder Geschwindigkeit. Die gespeicherte Highscore lässt die Motivation
entstehen, besser als andere spieler sein zu wollen.
Während der Implementation des Spiels mussten viele verschiedene, unabhängige Problemstellungen betrachtet werden. Nach der Einarbeitungsphase in das AR-Toolkit galt es die einzelnen
Module umzusetzen.
Näher beleuchtet werden hier nur die Raumschiffsteuerung mit Joystick-Integration, die Positionsbestimmung bei mehreren Markern und die Kollisionserkennung – mit der jeweils nötigsten
Mathematik.
Die Modellierung der Spielobjekte (es wurde 3DSMax benutzt bzw. zwei Raumschiff-Modelle
aus dem Internet „geliehen“ und angepasst), die Integration von Soundausgabe (DirectMusic),
viele kleinere Probleme und das generelle Klassen-Design werden nicht näher beschrieben.
27
3.3.1 Koordinatenbestimmung für Raumschiffe und Levelobjekte
Vorgehensweise
Wie in Kapitel 2.2.3 beschrieben, legt das AR-Toolkit die Kamera stets in den Ursprung des
OpenGL-Koordinatensystems. Es galt zu klären, wie Objektveränderungen in der Welt - durch
das Verschieben der Marker durch den Benutzer oder die Änderung des Blickwinkels und der
Kameraposition - zu behandeln sein sollen.
Mehrere Möglichkeiten ein Koordinatensystem für das Spiel aufzustellen mussten verglichen
werden. Die erste Idee beruht auf dem Prinzip eines Referenz-Markers2 , der immer im Bild
sein muss, um die Kameraposition im Weltkoordinatensystem zu ermitteln. In diesem Fall wäre
der Ursprung der Welt im Referenz-Marker und die Kameramatrix würde sich durch den Blickwinkel auf diesen ermitteln. Alle auf weiteren Markern erscheinenden Objekte wären dann in
Abhängigkeit vom ersten Marker zu setzen.
Vorteilhaft an dieser Variante ist die Unabhängigkeit von der Kamera. Die Welt liegt in ihrem
eigenen Koordinatensystem und der Blickwinkel auf die Welt wird zusätzlich durch die Beziehung zwischen Referenz-Marker und Kameraposition festgelegt. Der große Nachteil hierbei ist
allerdings, dass dieser Bezugspunkt niemals verdeckt sein darf. Ist dies doch der Fall, „fällt die
ganze Welt aus“. Auf der anderen Seite würde dieses Konzept es wiederum ermöglichen, alle
zusätzlichen Marker nach der Aufbauphase des Levels – nachdem das Programm die Positionen
der einzelnen Objekte registriert hat – vom Tisch zu nehmen und somit weniger störende reale
Objekte (d.h. Marker) im Blickfeld zu sehen.
Zwei Aspekte haben mich dazu bewogen, nicht obiges, sondern das im Folgenden beschriebene Prinzip anzuwenden. Der erste Grund, der dagegen spricht, ist technischer Natur, der zweite
entsteht durch das Spielkonzept. Technisch problematisch ist die „Ein-Marker-Variante“, da die
Erkennung der Muster auf größere Distanz sehr ungenau werden kann, was oft zum Ausfall
oder zu falscher Positionsbestimmung führen würde. Sollte in einem recht großen, realen Raum
gespielt werden, könnten die virtuellen Objekte (nach der Aufbauphase) immer nur an einem
Marker ausgerichtet werden. Das jedoch würde bedeuten, dass eventuell bei variierender Kameraposition die weiter entfernten virtuellen Objekte ihre vorbestimmte Position nicht mehr
genau halten. Da der Referenz-Marker fälschlicherweise um ein paar Grad gedreht erkannt werden könnte, was sich bei größeren Entfernungen bereits zu einem recht unangenehmen Fehler
aufsummieren würde, misslänge die Positionierung des virtuellen Objektes.
Neben diesem wichtigen Aspekt muss auch noch das Spielprinzip berücksichtigt werden. Die
Idee sieht vor, dass der Benutzer mit einem HMD und dort integrierter Kamera die Szene betrachtet und folglich die Kameraposition variieren kann. Der Spieler soll die Möglichkeit haben
sich frei umzusehen und den Level durch seinen realen Raum zu legen – auch über so große
Distanzen, dass nicht immer alle Marker im Bild liegen müssen.
Genau dieser Ansatz führt jedoch dazu, dass das Referenz-Marker-Prinzip scheitern muss.
Möchte der Benutzer etwa einen Kreisparcours aus den Markern abstecken und in deren Mitte
stehen, sind vermutlich die meiste Zeit nur zwei oder drei Marker im Bild (der Betrachter lässt
seinen Blick langsam im Kreis schweifen). Dies würde bedeuten, dass man mehrere Referenz2
oder mehrerer, was die Stabilität und Genauigkeit steigern könnte
28
Marker benötigen würde, deren Positionen zu Beginn komplett ermittelt werden müssten. Im
Anschluss kann bei Ausfall der Bezugspunkt auf den neu erkannten wechseln.
Um diese zusätzlichen Marker (als Weltkoordinaten-Referenz) zu vermeiden und das angesprochene Spielprinzip einfach umsetzen zu können, werden die Objekt-Marker direkt benutzt,
um die Positionen der Raumschiffe über wechselnde Bezugsmarker gleich zu halten.
Neben dem OpenGL-Koordinatensystem cam, welches an der Kamera ausgerichtet ist (siehe
Abschnitt 2.2.3), wird ein zweites Objektkoordinatensystem obj zur Positionsbestimmung der
Spielobjekte benutzt. Für alle sich in der Welt bewegenden Gegenstände (Raumschiff, Gegner,
Raketen, usw.) werden die Positionen mit Koordinaten (~r) in diesem Koordinatensystem verwaltet (Abbildung 3.6). Dabei sind in diesem die z-Achse die senkrechte und die x- und y-Achsen
die waagerechten.
Abbildung 3.6: Objektpositionen sind relativ zum Zentrum des Bezugsmarkers
Abbildung 3.7: Bestimmung der absoluten Objektposition zur Darstellung im Kamerakoordinatensystem
Erst bei der Darstellung wird für jedes Objekt auf die gespeicherten Koordinaten die Transformationsmatrix m
~ 1 des Markers aufaddiert (Abbildung 3.7). Für die Kollisionen untereinander
werden nur die obj-Koordinaten verwendet, während für die Prüfung mit den Toren die camWerte miteinander verglichen werden müssen (Näheres hierzu in 3.3.5).
29
rabsolut
~
=m
~ 1 + ~r
Sollte ein Marker ausfallen, muss eine „Übergabe“ stattfinden, so dass die Objekte weiterhin
an derselben Position stehen bleiben: m
~ 1 wird zum Zeitpunkt des Ausfalls durch einen neuen
Vektor m
~ 2 ersetzt.
Da aber die Position der Objekte relativ zum Ursprung des neuen Markers liegen würde, muss
ein Offset mof~f set bestimmt werden.
Um diesen zu ermitteln, wird die Differenz zwischen alten und neuen Marker-Vektor bestimmt
und auf den neuen Vektor addiert. Der Offset wird stets mitgeführt, so dass die verwendete
Formel zur Bestimmung der absoluten Koordinaten wie folgt aussieht (Abb. 3.8 und 3.9):
mof~f set = m
~1 − m
~2
rabsolut
~
=m
~ 2 + ~r + mof~f set
m
~ 1 steht hier generell für den alten und m
~ 2 für den neu verwendeten Marker.
Bewegt sich das Objekt, wird nur der Vektor ~r verändert. Bleibt es hingegen stehen, kann sich
– solange kein Marker-Wechsel stattfindet – nur der Vektor m
~ 2 ändern. Die Position bleibt also
immer in Relation zum gewählten Marker.
Vorteilhaft an dieser Variante ist neben dem angestrebten Freiheitsgrad (ein Marker im Bild
genügt bereits, um das Spiel zu bedienen und Punkte zu sammeln) die erhöhte Stabilität. Fällt ein
Marker aus, weil beispielsweise der Benutzer mit der Hand im Bild ist und genau einen Marker
verdeckt, bleiben die Objekte stets an der richtigen Stelle - natürlich nur solange wie mindestens
ein Marker übrig ist.
Abbildung 3.8: Bei Ausfall des linken Markers wird der Offset bestimmt.
30
Abbildung 3.9: Im Anschluss wird der neue Marker als Bezugspunkt verwendet.
Verfeinerung
Startet das Spiel, wird die Anfangsposition des Raumschiffs automatisch in Relation zum ersten
erkannten Marker gesetzt. Dieser bleibt vorerst der Bezugspunkt – auch wenn weitere Marker
im Bild erscheinen sollten. Erst wenn der derzeitig verwendete Marker ausfällt, wird die oben
beschriebene Neuberechnung des Offsets durchgeführt.
Um die Sicherheit bei der Erkennung und somit die Stabilität des Programms zu erhöhen,
wird zusätzlich geprüft, ob der Bezugsmarker das Zentrum des Kamerabildes verlässt. Ist dies
der Fall, findet ein Wechsel statt, sofern ein anderer Marker weiter im Zentrum liegt.
Dieses Prinzip wurde integriert, da bei einigen Kameras die Linsenverzerrung am Rand des
Bildes bereits so deutlich ausgeprägt war, dass das AR-Toolkit bei der Postionsbestimmung sehr
ungenau wurde. Die nachfolgenden Bilder veranschaulichen die Idee (Abb. 3.10 bis 3.12).
31
Abbildung 3.10: Schritt 1: Sollte zum gegenwärtigen Zeitpunkt noch kein Marker als Referenz
benutzt werden, wird der erste sichtbare als Marker gewählt (der weiß umrahmte Marker ist der Bezugsmarker).
Abbildung 3.11: Schritt 2: Kommen weitere Marker ins Bild, ändert sich der Referenz-Marker
zunächst nicht.
32
Abbildung 3.12: Schritt 3: Befinden sich mehr als ein Marker im Zentrum des Bildes, ändert sich
die Referenz nicht. Sollte jedoch der derzeitig gewählte Marker das Zentrum
verlassen, wird der neue Referenzmarker der Marker, der dem Zentrum am
nächsten und sichtbar ist.
3.3.2 Raumschiffsteuerung
Die Steuerung des Raumschiffs stellt die wesentliche Komponente für ein angenehmes, intuitives und unterhaltsames Spiel dar. Ist die Bedienung zu ungenau oder entspricht sie nicht den
Erwartungen des Benutzers, so wird dieser schnell aufgeben und das Interesse an dem Spiel
verlieren. Die Steuerung wurde daher so umgesetzt, dass der Benutzer selbst wählen kann, wie
er navigieren möchte: die „normale“ Flugsimulator-Bedienung, die der Benutzer evtl. schon aus
anderen Computerspielen kennt, in denen er meist die Sicht aus dem Cockpit einnimmt oder
aber die Kamera immer hinter dem Schiff herfliegt, führt gelegentlich zu Irritationen beim Benutzer. Da man – wie bei einem ferngesteuerten Auto – meist von derselben Position aus auf das
Schiff schaut, hat man als Orientierung nur die Raumschiffgraphik selbst. Es muss erkennbar
sein, welche Richtung „vorne“ ist und wo es folglich bei Beschleunigung hinfliegen wird.
Der Spieler soll das Raumschiff per Tastatur oder Joystick steuern können, wobei man zunächst vier Tasten (oder zwei Achsen) zur Raumschiffausrichtung und weitere zum Einstellen
der Beschleunigung besitzen soll. Die Steuerung im Dreidimensionalen stellt eine zusätzliche
Herausforderung dar, bei der der Benutzer die Übersicht schnell verlieren kann, wenn er nicht
nur parallel zum Boden fliegt, sondern zusätzlich die Richtung des Raumschiffs um ein paar
Grad nach oben oder unten lenkt. Die Nase des Schiffs neigt sich und in diesem Fall würde
dann eine Rechtsdrehung – relativ zur Raumschifforientierung zwar korrekt, aber für den Benutzer eher unerwartet – eine Richtungsänderung nach oben oder unten bewirken können. Mathematisch zusammengefasst: je mehr sich der Up-Vektor des Raumschiffs von der senkrecht
stehenden Achse der Welt unterscheidet, desto mehr wird der unerfahrene Benutzer verwirrt.
Um dieses Problem zu umgehen und neuen Spielern einen schnellen Einstieg zu ermöglichen, wurde neben der üblichen Raumschiff/Flugzeug-Bedienung die Möglichkeit integriert, das
Schiff mit zwei weiteren Tasten entlang der senkrechten Achse steigen und fallen zu lassen. Jetzt
kann der Anwender einfacher (sozusagen im Zweidimensionalen) steuern und nur bei Bedarf die
33
Abbildung 3.13: Bestimmung der neuen Objektposition bei Eigenbewegung
Höhe anpassen, sofern es der Parcours erfordert. Dies ermöglicht ein schnelleres Verstehen der
Bedienung, da vermutlich jeder Anwender schon einmal ein ferngesteuertes Auto bedient haben
dürfte (bzw. diese Art der Navigation intuitiv genug ist).
Um die Steuerung des Schiffs interessanter zu gestalten, gibt es verschiedene Faktoren, die
den Spielspaß erhöhen sollen. Zum ersten den Trägheits- bzw. Wendigkeitsfaktor des Schiffs,
zum zweiten Reibung (die natürlich im Weltraum eigentlich nicht existiert) und zum dritten
(optional) Gravitation. Die Prinzipien, die zur Implementation angelegt wurden, werden die folgenden Graphiken erläutern.
Die Neupositionierung und Beschleunigung des Raumschiffs erfolgt über einen Richtungsvektor d~ und vier Skalare: die aktuelle Geschwindigkeit vcur , die vom Spieler vorgegebene Geschwindigkeit vset , den konstanten Beschleunigungswert des Raumschiffs acc und die Reibung
f r. Zusätzlich ist natürlich der Positionsvektor ~r des Objekts nötig (Abb. 3.13).
Die Folgeposition rneu
~ wird bestimmt:
rneu
~ = ~r + d~ ∗ vcur
Bei jedem Durchlauf wird die Geschwindigkeit nachreguliert: zum einen bedingt durch die
Geschwindigkeitsvorgaben des Spielers vset und zum anderen durch die Reibung f r. Die Variable sign wird auf 1 gesetzt, sofern vset positiv ist; andernfalls erhält sie den Wert −1.
vcur = vcur + (acc − f r) ∗ sign
Bremst der Spieler, nimmt die Beschleunigungsvorgabe einen negativen Wert an und das
Raumschiff bremst ab – bzw. fliegt rückwärts sobald vcur selbst negativ wird. Im Anschluss
muss die Beschleunigung vcur noch in den Bereich vset geclippt werden, da das Schiff maximal
so schnell fliegen darf, wie es der Benutzer vorgegeben hat.
Dieses Prinzip ermöglicht bereits eine natürlich wirkende, lineare Beschleunigung, die für
unsere Raumschiffsimulation völlig ausreichend ist.
Möchte der Benutzer das Raumschiff in andere Bahnen lenken, wird zur Richtungsänderung
folgende Rechnung verwendet. Benötigt wird hier noch der Up-Vektor des Schiffs (up),
~ ein
Wendigkeitswert (ag), sowie der Wert set, um den der Benutzer das Raumschiff gelenkt haben
34
Abbildung 3.14: Richtungswechsel des Raumschiffs
möchte (zwischen -1 und 1 (0 = keine Richtungsänderung)).
~ wird ermittelt (Abb. 3.14):
Die neue Richtung des Raumschiffs dneu
~ = d~ × up
dir
~
~ = dir
~ + (1 − ag ∗ set) ∗ (d~ − dir)
~
dneu
Da der Wendigkeitswert ag im Spiel zwischen 0.005 und 0.020 liegt, wird das Raumschiff
maximal um ein paar Grad pro Aufruf weitergedreht. Diese Änderung kann natürlich so lange anhalten, wie der Benutzer die Vorgaberichtung abweichend von der aktuellen Flugrichtung
angibt.
Durch die zusätzliche Neubestimmung der Raumschiffposition bei jedem Programmdurchlauf
beschreibt das Schiff beim Lenken einen Bogen und fliegt keine „Ecken“.
Die Gravitation bewirkt bei jedem Durchlauf zusätzlich eine Positionsverschiebung des Objekts entlang der senkrechten Achse im Weltkoordinatensystem, die der Spieler durch ein Ansteigen kompensieren muss – andernfalls fällt das Schiff so lange bis sich in der Welt eine Kollision
zwischen Schiff und anderen Levelobjekten ereignet (siehe Kapitel 3.3.5).
3.3.3 Joystick
Durch die einfache Skalierung der Lenkung und die Geschwindigkeitsvorgabenvariable (set)
war es einfach, die digitale Steuerung per Tastatur um eine analoge mit einem Joystick zu erweitern. Die Joystick-Integration wurde über die in der „windows.h“-Bibliothek vorhandenen
Joystick-Methoden realisiert. Angesprochen werden können nur Standard-Joysticks (maximal
zwei Stück, über den Midi-Port der Soundkarte bzw. einen extra Game-Port) mit drei Achsen
und bis zu vier Knöpfen.
Die Variablen vom Typ JOYCAPS und JOYINFO liefern Informationen über die Minima und
Maxima der Achsen, sowie den aktuellen Status (x-, y- und z-Wert, Buttons).
Nach dem Aufruf von joyGetDevCaps() und joyGetPos(), liegen in der JOYINFO-Variable
die aktuellen Werte vor. Die x, y und z-Werte liegen dabei im int-Bereich von [0, 65535], und
werden von mir in den float-Bereich zwischen -1 und 1 abgebildet. Dies ermöglicht die einfache
35
Erweiterung der digitalen Raumschiffsteuerung per Tastatur (dort waren nur die Werte -1, 0 und
1 möglich). Joystick benutzende Spieler sind dadurch natürlich eindeutig im Vorteil.
3.3.4 Tor-Objekte
Für jedes Tor müssen neben Informationen für das Auswerten der Spiel-Ereignisse (Tor-Nummer
(für die Reihenfolge im Level), Punkte, ...) auch Werte für die Realisierung einer effizienten Kollisionsprüfung gespeichert werden. Die kollisionsrelevanten Daten sind folgende:
• innerer und äußerer Radius des Tores (2 Skalare)
• Rechteck-Koordinaten für die Bodenplattform des Tors (4 Vektoren)
• Rechteck-Koordinaten für eine weitere Plattform (4 Vektoren)
• 3 Vektoren zur Ausrichtung des Tores (Up, Front, Left)
Jedes Tor hat eine definierte Bodenplattform, da es stets auf einem Marker steht und somit eine
Kollisionsfläche fest vorgegeben ist. Spezielle Tore wie die Startfläche können weitere Ebenen
definieren, die über der Bodenfläche liegen.
Für jedes Tor werden die Vektor-Daten jeweils zwei Mal gespeichert. Zunächst werden sie in
relativen Angaben definiert, bei denen der Mittelpunkt des Tores im Koordinatenursprung liegt.
Diese Daten werden nur ein einziges Mal im Programm festgelegt. Die zweite Version sind diese
Vektoren ungewandelt in das Koordinatensystem cam der Kamera: auf die relativen Werte wird
die jeweilige Matrix des Markers, auf dem das Tor erscheint, aufmultipliziert.
Diese Aktualisierung geschieht leider zwangsläufig bei jedem Darstellungsdurchlauf und wird
für die Kollisionsprüfung benötigt.
3.3.5 Kollisionserkennung
Ein in fast allen 3D-Anwendungen sehr wichtiger Teil ist die Kollisionserkennung zwischen den
virtuellen Objekten. In der Augmented Reality sollte es aber zusätzlich Kollisionen mit realen
Objekten geben, um den Eindruck zu stärken, dass die Computer generierten Objekte mit der
realen Welt interagieren. Im Folgenden werden zunächst die Ansätze zur Kollision unter den virtuellen Gegenständen und danach kurz die Ansätze zur Erkennung realer Objekte beschrieben.
Da das Spiel recht objekt- bzw. polygonarm ist, sind aufwendige Hierarchien zum Testen der
Kollision unnötig. Das Spielprinzip sieht zudem nur vor, dass sich die Raumschiffe bewegen und
keine physikalischen Rückmeldungen für die Level-Objekte untereinander berechnet werden
müssen. Wird zunächst der Abstand der Raumschiffe zu jedem sichtbaren Marker getestet. Ist
ein Schwellwert unterschritten – was noch keine Objektkollision bedeutet –, wird eine mögliche
Berührung zwischen Tor und Objekt wie folgt (am Beispiel Tor und Raumschiff) ermittelt.
Das Raumschiff besteht – je nach Modell – aus bis zu 43000 Polygonen, was eine Überprüfung auf unterster Ebene mit den Dreiecken der Tore vom Aufwand her doch ausschließt. Problematisch ist zusätzlich die Kapselung der VRML-Darstellung des AR-Toolkits. Man gelangt
zwar letztlich an die Vertices der VRML-Graphiken, doch hätte dies ein Umschreiben mehrerer
AR-Toolkit-Klassen bedeutet.
36
Abbildung 3.15: Bounding Box-Ausrichtung am obj-Koordinatensystem – nicht an cam
Die gewählte Variante verwendet eine einfache Bounding Box für das Raumschiff, deren Größe zur Zeit fest vorgegeben ist und jeweils bei der Wahl eines anderen Raumschiff-Objekts „von
Hand“ angepasst werden muss.
Diese Bounding Box wird durch acht (Eckpunkt-)Vektoren beschrieben, die sich bei Drehungen des Raumschiffs auch korrekt mitdrehen: auf eine Achsenausrichtung (axis aligned bounding box (AABB)) an cam wurde bewusst verzichtet. Da die Kameraposition am Ursprung
der OpenGL-Welt liegt, verändert beispielsweise das Bewegen des Raumschiffs in horizontaler Richtung nicht nur die x- oder y-Werte unseres Objektes. Eine AABB würde sich aber am
Koordinatensystem der Kamera ausrichten müssen und somit unser Raumschiff stets ungenau
einrahmen (Abb. 3.15).
Im Kollisionstest mit dem Tor werden zwei verschiedene Verfahren angewandt – für die Plattformen und für die Ringe je eins. Die Prinzipien der Prüfungen sowie die Implementierungen
der Schnitt-Tests werden im Folgenden erklärt.
Plattformen
Ob es eine Berührung zwischen Plattform-Ebene und Raumschiff gegeben hat, wird getestet, indem zunächst für alle 8 Bounding Box-Punkte der Abstand zur Ebene bestimmt wird. Ist ein Abstand zur Ebene kleiner als ein vorgegebener Mindestabstand (distanceToPlane()), liegt
eine Kollision vor, sofern der Punkt zum aktuellen Zeitpunkt überhaupt oberhalb der Ebene liegt.
Hierzu wird die Methode abovePolygon() angewandt. Um die Kanten der Plattform erfolgreich zu überprüfen, werden alle 6 Flächen der Bounding Box mit quad_quad_intersect()
gegen das Plattform-Viereck auf einen Schnittpunkt getestet.
Ist eine der obigen Bedingungen wahr, erfolgt der Abprall des Raumschiffs. Der Geschwindigkeitsvektor wird invertiert, halbiert und die Position auf die vorherige zurückgesetzt. Zusätzlich
wird ein entsprechender Sound als Feedback ausgegeben.
37
Abbildung 3.16: Kollisionsprüfung an Toren über outside_hit und inside_hit
Ringe
Zur Bestimmung, ob das Raumschiff durch das Tor durchfliegt oder mit dem Rand kollidiert,
musste eine etwas andere Methode angewandt werden, da nicht auf Polygon-Ebene alle VRMLDreiecke des Tors verglichen werden konnten.
Ein vereinfachtes repräsentatives Polygon-Gitter zum Test wäre vermutlich der nächst beste Ansatz, doch erschien er zunächst unnötig, da die im Folgenden vorgestellte Variante am
zweckmäßigsten zum Ziel führt. Allerdings gibt es einige Probleme, die hoffentlich in einer
nachfolgenden Version mit dem Polygon-Gitter-Modell eliminiert werden können.
Die gegenwärtige Version testet in mehreren Schritten, ob eine Kollision vorliegt und gleichzeitig, ob das Raumschiff durch das Tor durchgeflogen ist. Dazu benötigt man die oben genannten Informationen für ein Tor: einen äußeren und einen inneren Radius (zwischen diesen Radien
liegt der Tor-Rahmen, an dem eine Kollision auftritt), sowie die Gleichung für die Ebene, die im
Tor liegt, und einen Wert zum Speichern der Dicke des Tors.
Zunächst wird für alle Bounding Box-Eckpunkte getestet, ob sie nahe genug an der Ebene
des Tors liegen (nicht weiter weg als die angegebene Dicke). Ist dies für mindestens einen der
Eckpunkte der Fall, wird geprüft, ob sie innerhalb des äußeren Radius liegen. Befindet sich ein
Punkt innen, erhöhen wir eine Zählvariable outside_hit, die die Anzahl der Treffer speichert. Eine zweite Variable inside_hit sammelt die Werte für den inneren Radius. Sollten
outside_hit und inside_hit verschiedene Werte haben, muss eine Kollision mit der Außenhülle vorliegen, da outside_hit stets mit erhöht wird, wenn inside_hit seinen Wert
ändert. Das Raumschiff befindet sich folglich innerhalb des inneren Radius, wenn die beiden
Variablen denselben Wert besitzen und ungleich Null sind. Sind die Werte verschieden, liegt
mindestens ein Eckpunkt nicht im Inneren und eine Kollision wird ausgelöst (Abb. 3.16).
Um das Tor als „passiert“ zu markieren, wird zusätzlich der Abstand zum Tor vorher und
nachher gemessen: fand ein Vorzeichenwechsel statt, bekommt der Spieler einen Punkt für diesen Streckenposten.
38
Abbildung 3.17: Punktabstand zu einem Polygon: abovePolygon()
Kollisionen zwischen dem Spieler, den gegnerischen Drohnen und den Laser-Geschossen
werden komplett über Bounding Sphere-Verfahren geprüft.
Algorithmen
Die in diesem Abschnitt benötigten Methoden und deren Funktionsweisen sollen kurz vorgestellt
werden.
double distanceToPlane(double point[3], double planePoint[3],
double normVector[3]);
Diese Methode bestimmt den Abstand eines Punktes zu einer Ebene, die in Normalform angegeben wird. Die Differenz zwischen dem ersten Punkt und dem Punkt der Ebene wird gebildet
und aus ihr und dem Normalenvektor der Ebene das Skalarprodukt gebildet. Dieser Rückgabewert liefert abhängig von der Normalenausrichtung einen positiven oder negativen Abstand.
int abovePolygon(double point[3], double norm[3],
double plane[4][3]);
Um zu bestimmen, ob ein beliebiger Punkt über einem Polygon liegt, wird diese Methode
verwendet, die als Rückgabewert 1 oder 0 liefert. Übergeben werden der zu prüfende Punkt
ptest , die Normale der Ebene ~n und die vier Eckpunkte des Polygons p~0 , p~1 ,p~2 , p~3 . Es werden
39
die in der Ebene liegenden, auf den Seiten senkrecht stehenden Vektoren pn~lot errechnet, indem
jeweils die Differenz aus zwei aufeinander folgenden Punkten bestimmt wird. Das Kreuzprodukt
zwischen diesen „Kantenvektoren“ und dem Normalenvektor ~n liefert die senkrecht stehenden
(Abb. 3.17). Im Anschluss werden die Punkte pn+1,n
~ half ermittelt und die Vektoren von diesen
Koordinaten zu ptest bestimmt. Die Prüfung, ob letzterer über der Ebene liegt, erfolgt, indem für
jeden dieser Vektoren das Skalarprodukt mit dem jeweiligen pn~lot gebildet wird: sind alle vier
Ergebnisse größer oder gleich Null, haben alle vier Winkel einen Wert, der kleiner als 90◦ ist.
Der zu prüfende Punkt liegt zwangsläufig oberhalb des Polygons.
int quad_quad_intersect(double quad0[4][3],
double quad1[4][3]);
Zur Bestimmung, ob sich zwei Vierecke schneiden, werden die Ebenen in je zwei Dreiecksflächen aufgeteilt und erst dann der Schnitttest in tri_tri_intersect() ausgeführt.
int tri_tri_intersect(double V0[3], double V1[3],
double V2[3], double U0[3],
double U1[3],double U2[3]);
Übergeben werden zwei Bündel von je drei Vektoren für je ein Dreieck. In der Methode
wird die Ebenengleichung für das Dreieck v~0 , v~1 , v~2 in Normalform aufgestellt. Danach werden
die Eckpunkte des zweiten Dreiecks eingesetzt und der vorzeichenbehaftete Abstand zur Ebene
bestimmt (du0 , du1 , du2 ). Sind alle Vorzeichen identisch und die Abstände größer als Null, kann
keine Kollision vorliegen.
Umgekehrt wird dieser Vergleich mit der Fläche u~0 , u~1 , u~2 und v~0 , v~1 , v~2 getestet (dv0 , dv1 ,
dv2 speicheren die Abstände) und bei obiger Bedingung 0 zurückgegeben.
Andernfalls wird die Schnittlinie aus dem Kreuzprodukt der zwei Normalenvektoren der Ebenen ermittelt. Die größte Komponente dieses Vektors wird bestimmt und deren Index verwendet,
um projizierte Vektoren v~p und u~p zu erhalten. Dann werden die Intervalle für die zwei Dreiecke
mit diesen Aufrufen berechnet:
COMPUTE_INTERVALS(vp0,vp1,vp2,dv0,dv1,dv2,dv0*dv1,dv0*dv2,
isect1[0],isect1[1])
COMPUTE_INTERVALS(up0,up1,up2,du0,du1,du2,du0*du1,du0*du2,
isect2[0],isect2[1])
isect1 und isect2 werden in COMPUTE_INTERVALS initialisiert. An erster ArrayPosition liegt stets der kleinere Wert, so dass wir im Anschluss ein letztes Mal prüfen, ob kein
Schnittpunkt vorliegt. Andernfalls geben wir 1 zurück:
...
if(isect1[1]<isect2[0] || isect2[1]<isect1[0]) return 0;
return 1;
40
4 Ergebnisse
4.1 Das Spiel
Im vorgegebenen Zeitraum konnte eine funktionsfähige AR-Anwendung entwickelt werden.
Das AR-Toolkit wurde erfolgreich integriert und die wichtigsten Ideen vom Spielkonzept realisiert, welche hier vorgestellt werden sollen. Darüber hinaus wurden verschiedene Interaktionsmöglichkeiten mit dem Benutzer angedacht und zum Teil implementiert. Sie werden in diesen
Kapitel ebenfalls beschrieben.
Leider war kein HMD vorhanden, so dass komplett mit einer stationären Kamera und einem
Monitor gearbeitet werden musste. Folglich war es nicht möglich, die bei einer See-ThroughUmgebung enstehenden Probleme, Vorteile und Beschränkungen zu erforschen. Interessant wäre
eine Untersuchung zur Stabilität des AR-Toolkits bei einer solchen Immersionsvariante gewesen. Viele Fragen dazu mussten leider offen bleiben. Sind Ausfälle tolerierbar? Wie gut gelingt
die Vermischung der realen und virtuellen Welt? Ist das vorgestellte Spielkonzept wirklich geeignet für Augmented Reality unter Benutzung eines HMDs?
Spielbeginn
Vor dem Programmstart muss eine Kamera angeschlossen sein und die zu verwendenden Marker
sollten im Raum verteilt die Strecke abstecken. Startet der Benutzer im Anschluss die Anwendung, befindet er sich sogleich in der Spielansicht. Die Marker werden erkannt und die Tore erscheinen entsprechend. Vorerst wird die Highscore-Liste eingeblendet und der Anwender muss
das Spiel per Tastatureingabe starten (Einspieler-/Zweispieler-Modus). Zu Beginn erscheint das
Raumschiff dann mit einer weiß leuchtenden Schutzhülle, die den Benutzer in dieser Zeit vor
Schaden bewahrt und nach einigen Sekunden verschwindet. Der Spieler muss gegen die Zeit
antreten und möglichst schnell Runde um Runde abfliegen. Dabei bekommt er über ein HeadsUp-Display (Abb. 4.1) im Sichtfeld die verbleibende Zeit und die Beschädigung am Raumschiff
als Balkengraphik visualisiert. Der „schrumpfende“ Balken für die Zeitangabe kann auch im
Bildrand gut wahrgenommen werden ohne dass der Benutzer explizit hinsehen muss1 . Zusätzlich werden der Punktestand und die verbleibenden Leben angezeigt.
4.1.1 Spielkonzept
Die Umsetzung des angestrebten Konzepts beschränkt sich auf den vorgestellten „Arcade-Modus“.
Die Spieler (maximal zwei) können ihre Raumschiffe per Joystick und Tastatur steuern und die
1
Die schlechtere Wahl wäre eine Angabe in Sekunden – hier müsste man genau hinsehen, um ein Gefühl für die
verbleibende Zeit zu bekommen.
41
4 Ergebnisse
Abbildung 4.1: Das Heads-Up-Display im Spiel
auf den Markern erscheinende Strecke abfliegen. Dabei muss die richtige Reihenfolge der Tore
eingehalten und eine Runde in der vorgegebenen Zeit vollendet werden. Um es dem Benutzer
zu erleichtern, erscheint über dem aktuell anzufliegenden Tor eine Pfeil-Markierung (Abb. 4.2)
und das Ablaufen der Zeit wird fünf Sekunden vor Schluss akustisch signalisiert. Beim Beenden einer Runde erhält der Spieler Bonus-Zeit, die je nach Schwierigkeit und Level aber immer
weiter abnimmt.
Abbildung 4.2: Navigationshilfe mit Pfeilen
Das Raumschiff besitzt zusätzlich einen Energiewert, der abnimmt, wenn gegnerische Objekte
kollidieren oder den Spieler unter Beschuss nehmen. Eine Kollision mit den Toren, Wänden und
Bodenplattformen führt nur zu einem Abprall bzw. einer Geschwindkeitsreduzierung, jedoch
nicht zu einem Schaden.
42
4.1 Das Spiel
Erschwerend kommt in jeder dritten Runde2 ein weiterer Gegner ins Spielfeld: Drohnen steuern stets auf den Spieler zu bzw. versuchen vor ihn zu gelangen und dann zu rammen (Abb.
4.3). Neben Ausweichmanövern können diese aber auch per Knopfdruck mit dem Laser abgeschossen werden, der in einem Raumschiff natürlich nicht fehlen darf. Sind alle gegnerischen
Drohnen ausgeschaltet, tauchen sie frühestens in der nächsten Runde (im nächsten Level) wieder auf. Der Benutzer kann – vorübergehend ungestört – die Strecke in der verbleibenden Zeit
vollenden.
Abbildung 4.3: Gegnerische Drohnen stören den Spieler
4.1.2 Interaktionsmöglichkeiten
Grundlagen
Zunächst wurde die „klassische“ Bedienung einer Software bzw. eines Spiels implementiert:
der Anwender benutzt die Tastatur, wählt mit Funktionstasten die Optionen an und steuert per
Cursor-Tasten. Als erste Optimierung wurde ein Joystick eingebunden, der drahtlos und in Verbindung mit einem HMD bereits einen hohen Komfort und Freiheitsgrad bieten würde. Die
analoge Steuerung hat sich als unabdingbar herausgestellt. Die Tasturabfrage der GLUT ist eher
mäßig, so dass der Keyboard-Spieler mit unangenehm, ewig währendem „Hacken“ auf das Eingabegerät beschäftigt ist. Der Benutzer muss allerdings auch unter Verwendung des Joysticks
auf die Tastatur zurückgreifen, um etwa das Spiel neu zu starten.
Markerbasierte Steuerung
Die erste Variante der Marker basierten Bedienung des Spiels ist im Spielkonzept verankert.
Verschiebt der Anwender die Pappfelder auf denen die Tore erscheinen, verändert sich die abzufliegende Strecke. Auf diese Art und Weise kann die Strecke selbst zur Laufzeit verändert
und interessant gehalten werden. (Ein Tor könnte etwa auf einem sich drehenden Plattenspieler
liegen.) Ist sie zu schwer, hat man etwa die Option die Abstände zu verringern.
2
je nach Schwierigkeitsgrad
43
4 Ergebnisse
Menüs
Weitere Ideen sahen die Eingabe über spezielle Musterfelder vor. Der Benutzer soll sämtliche
Eingaben über den Joystick und die Marker realisieren können. Dazu schnallt sich der Spieler
zwei bestimmte Muster an die Handrücken. Während des Spiels sind sie durch das Umfassen
des Joysticks nicht sichtbar. Sollte eine der beiden Hände gedreht und einer der Menü-Marker
im Bild erkannt werden, schaltet das Spiel auf Pause und der Anwender kann mit dem Pfeil, der
auf dem linken Musterfeld erscheint, die Menüeinträge, die auf der rechten Hand erscheinen,
auswählen (Abb. 4.4). Hierzu wird intern die Pfeilspitzen-Position im 3D-Raum bestimmt und
die Nähe zu einem Menü-Punkt berechnet. Ist der Abstand unter einem ersten Schwellwert, wird
der Eintrag markiert, fällt die Distanz unter einen zweiten Wert, wird der Befehl ausgeführt.
Problematisch war bei dieser Steuerung jedoch die 3D-Positionierung. Der Benutzer glaubte,
den Menüeintrag ausgewählt zu haben, doch befand sich der Pfeil weit hinter dem Menüobjekt,
was jedoch in der Perspektive des Betrachters schlecht zu erkennen war. Würde man zur Abstandsbestimmung alle einbezogenen Marker auf dieselbe Distanz zur Kamera abbilden, wäre
in dieser Art der Steuerung viel Potential enthalten: der Pfeilmarker stellt dabei letztlich eine Art
Maus-Cursor dar. Auswählen könnte man dann wie angedacht durch die geringe Distanz zum
Objekt oder durch eine schnelle Drehung des Markers.
Abbildung 4.4: Menüsteuerung über Handrückenmarker
Werkzeuge
Eine intuitive Manipulation des Spiels ermöglicht ein weiterer Ansatz, bei dem wieder spezielle
Muster benutzt werden müssen: sie dienen zur Anpassung der Level-Elemente. Hält man während des Spiels etwa den Marker mit dem Schraubenschlüssel-Symbol in die Nähe eines Tores,
so erscheint eine Markierung um das ausgewählte Element. Der Benutzer kann durch Drehen
des Werkzeug-Markers das Tor in seiner Größe verändern und so den Schwierigkeitsgrad der
Strecke individuell anpassen (Abb. 4.5 und 4.6).
44
4.2 Umgesetzte Optimierungen
Ein anderer Werkzeug-Marker wird zum Beispiel verwendet, um ein Levelobjekt auszutauschen. So kann der Benutzer die Graphiken der Tore selbst bestimmen oder spezielle Elemente
einbinden (z.B. ein Tor durch eine Startplattform oder ein anderes Hindernis ersetzen).
Dieses Prinzip der Werkzeug-Marker ist beliebig erweiterbar und durch die verwendeten Muster für den Benutzer leicht verständlich.
Abbildung 4.5: Werkzeug-Marker zur Manipulation: Modellauswahl per Drehung
Abbildung 4.6: Drehen des Werkzeugs zum Anpassen der Tor-Größe
Neben den Optimierungen im Spielprinzip und Überlegungen, möglichst interessante Extras
einzubinden, die das Spielgeschehen dauerhaft unterhaltsam gestalten, sind andere wichtige
Aspekte zu berücksichtigen, die dazu dienen sollen, dem Benutzer eine bessere Immersion zu er-
45
4 Ergebnisse
möglichen. Drei implementierte Verbesserungen sollen im Folgenden herausgestellt werden: die
Einbindung von Schatten, Kollision mit realen Objekten, sowie die Optimierung der Steuerung.
4.2.1 Schatten
Ein Hauptproblem bei der Steuerung des Raumschiffs war die Abschätzung der Höhe im realen
Raum. Der Benutzer sieht letztlich alles nur in 2D (das AR-Toolkit kann nur ein Kamerabild
verarbeiten). Das Fehlen der räumlichen Tiefe ermöglicht eine Orientierung nur über die Größenverhältnisse und über Überschneidungen von Objekten. Dass diese zwei Möglichkeiten für
eine Orientierung nicht ausreichen würden, wurde bei ersten Tests schnell klar.
Es wurden für die sich bewegenden virtuellen Objekte Schlagschatten eingebunden, die die
Orientierung erleichtern sollen. Da das Programm nicht die Lichtverhältnisse des realen Raums
kennt, sitzt die virtuelle Lichtquelle senkrecht über der Szene, so dass alle Schatten senkrecht
nach unten projiziert werden (Abb. 4.7). Nach wenigen Tests wurde der große Vorteil dieses
Abbildung 4.7: optimierte Orientierung durch Schlagschatten
Ansatzes bereits deutlich. Allerdings hat man so dennoch mit einer Einschränkung zu kämpfen.
Da das Programm den realen Raum nicht kennt und somit nicht weiß, wo reale Objekte unter
dem Spielfeld liegen, ist nicht immer klar, in welcher Höhe der Schatten zu erscheinen hat. Die
implementierte Variante verfolgt daher die Idee, dass Schatten nur gezeichnet werden, wenn die
Objekte über Markern stehen bzw. in unmittelbarer Nähe sind.
Für jeden Marker wird das Bodenplattform-Rechteck verwendet, um vom Objekt aus einen
Strahl senkrecht nach unten auf die Basis zu schießen. Existiert ein Schnittpunkt, so zeichnen
wir den Schatten. Andernfalls schweben die Objekte ohne Schatten im Raum.
Da der Benutzer aber in kürzeren Abständen Marker um Marker ansteuert, schaltet sich der
Schatten somit immer wieder ein und verschwindet kurze Zeit später wieder. Zur Positionsbestimmung für den Benutzer reicht dieser wechselnde Schatten völlig aus, auch wenn ein dauerhafter Schatten optisch selbstverständlich wünschenswerter wäre.
Zwei andere Varianten wären noch denkbar, die allerdings auch gewisse Nachteile besitzen.
Zum einen könnte man den im realen Raum am tiefsten liegenden Marker benutzen, um in
46
seiner Höhe eine Ebene aufzuspannen, die die unterste Schicht der Welt darstellt. Sofern kein
höherer Marker als Schattenbezugspunkt benutzt wird, erscheint der Schatten auf dieser Ebene.
Der Nachteil dieser Variante ist, dass etwa „Abgründe“ zwischen zwei Schreibtischen nicht registriert würden, da die unterste Ebene die beiden Schreibtischplatten verbindet. Das Raumschiff
würde im realen Raum seinen Schatten in die Luft projizieren.
In der zweiten Variante sollten immer drei Marker, die im Bild zu sehen sind, eine Ebene aufspannen und somit dynamisch weitere Bezugsebenen für den Schatten generieren. Vorteilhaft ist
hier das Aufspannen auch schiefer Ebenen. Das Problem der „Abgründe“ greift hier allerdings
auch und zusätzlich fällt die Ebene aus, sobald sich nur noch zwei Marker im Bild befinden.
Um dennoch öfters Schattenwürfe zu erhalten, werden zusätzliche Kollisionsebenen verwendet, die flach auf dem Boden liegen, um weitere Bezugsflächen zu ermitteln.
4.2.2 Kollision mit realen Objekten
Um weitere Verbesserungen für den Spieler zu erhalten, die die Immersion weiter stärken und
die Grenze zwischen Realem und Virtuellem weiter verwischen, wurde mit einer extra Sorte
Markern eine Möglichkeit integriert, reale Objekte als „undurchlässig“ zu markieren. Man kann
beispielsweise einen Marker an eine Wand oder eine Tischplatte kleben und das Programm wird
in Zukunft über diesem Marker intern eine Ebene aufspannen, die für die Kollisionstests und
den Schattenwurf genutzt wird. Der Clou ist dabei, dass auf dem Marker kein virtuelles Objekt
erscheint. Nachdem der Benutzer ggf. noch die Größe der Ebene skaliert hat, wird diese nie
gezeichnet, da dass Raumschiff für den Betrachter dann mit dem realen Objekt, an dem der
Marker angebracht ist, zu kollidieren scheint und auch hierauf der Schatten projiziert wird.
Während der Aufbau-Phase (vor dem eigentlich Spiel) hat der Benutzer die Möglichkeit, die
unsichtbaren Kollisionswände einzublenden, um ihre Höhe und Breite anzupassen (Abb. 4.8,
links).
Abbildung 4.8: Kollisionserkennung mit realen Objekten
Neben diesen extra Kollisionsmarkern besitzt jedes Tor von sich aus die untere Plattform als
Kollisionsfläche. Zusätzlich definiert je ein Quader unter jedem Tor weitere Wände. Stellt der
47
4 Ergebnisse
Benutzer einen Marker etwa auf eine Flasche o.ä., fliegt das Raumschiff gegen die unter dem
Papierfeld stehende Flasche (Abb. 4.9).
Abbildung 4.9: Kollision mit realen Objekten, die unter dem Marker stehen
4.2.3 Automatische Höhenanpassung des Raumschiffs
Da die Bildverzerrung bei den verwendeten Kameras doch unangenehm groß ist, erkennt das
Toolkit Marker im Randbereich in einer falschen Höhe und Ausrichtung. Tore, die auf demselben realen Grund stehen, werden im Spiel als unterschiedlich hoch positioniert registriert (Abb.
4.10). Dies ergibt natürlich einige Probleme, die es auszugleichen gilt. Zu nennen wäre vor allem die dadurch erschwerte Steuerung durch den Benutzer. Durchquert das Raumschiff ein Tor
und steuert ein zweites an, welches sich eigentlich auf derselben Höhe wie das erste befindet,
aber durch die Verzerrung anders positioniert wird, stößt es dennoch unerwartet am Rand an.
Da diese Beschränkungen nicht zu umgehen waren, ist eine automatische Höhenregulierung
für das Raumschiff integriert worden. Zunächst wird der Abstand zu allen sichtbaren Toren
ermittelt. Ist das nächstliegende Tor bestimmt und ein Schwellwert unterschritten, wird die Höhe
des Raumschiffs automatisch nachreguliert. Langsam gleitet das Raumschiff höher oder tiefer
– so als ob der Benutzer selbst die Anpassung vorgenommen hätte. Ist das Schiff auf Höhe des
Ring-Zentrums stoppt die Regulierung.
Dieser Eingriff zerstört zwar die totale dreidimensionale Steuerungsfreiheit des Spielers, erhöht aber die Spielbarkeit enorm, da in Tests die beschriebene Verzerrung doch zu stark war, als
dass man sie hätte ignorieren können.
Neben dieser Höhenanpassung für die Position wurde gleichzeitig eine automatische LaserSchussausrichtung integriert. Da gegnerische Objekte nicht immer auf Spielerhöhe fliegen, fiel
48
dem Benutzer das Anvisieren der Objekte recht schwer. Nur die Richtung muss stimmen und
der Feind wird – egal auf welcher Höhe er sich befindet – getroffen3 .
Sollte eine andere Kamera weniger verzerren oder der Benutzer eine größere Herausforderung
suchen, kann die Funktion deaktiviert werden. Sie ist also nur als aktivierbare Hilfe zu verstehen.
Abbildung 4.10: Optische Verzerrung der Kamera
4.2.4 Benutzererfahrungen
Wie bereits erwähnt, konnte die Benutzung eines HMDs nicht erprobt werden, wodurch wichtige
Aspekte undokumentiert bleiben müssen.
Handhabung
Ansonsten zeigte sich das Spiel in der Benutzung recht stabil, wenn auch bei zu großer Kameraentfernung oder schlechteren Lichtverhältnissen schnell Marker ausfielen oder „hin- und
hersprangen“. Meistens war dies kein Problem, da der Marker, an dem das Rauchschiff ausgericht wurde, oft im vorderen Bereich der Kamera lag und somit stabil getrackt werden konnte.
Gelegentlich ergab es sich jedoch, dass der aktuelle Bezugspunkt ungenau zitterte und die Raumschiffposition diesem Fehler folgte. So kam es vor, dass der Benutzer mit seinem Schiff in Toren
oder Plattformen „feststeckte“, da eine unplanmäßige Koordinatenverschiebung die Kollisionsprüfung ausgetrickst hatte. Zwar konnte sich der Spieler schnell behelfen, indem er einfach eine
Hand vor den blockierten Marker gehalten hat (so verschwand das entsprechende Tor und die
Kollision wurde deaktiviert), doch wäre hier eine Verfeinerung der Prüfung wichtig.
Ebenso kam es vor, dass das Schiff im Tor hängen blieb, wenn es – während es im Torbogen stand – nach oben oder unten fliegen sollte. Die automatische Höhensteuerung des Schiffs
eliminierte dieses Problem jedoch (siehe Abschnitt 4.2.3).
3
Da in der Testumgebung die Marker meist auf derselben Höhe waren, fiel das „eigentliche Vorbeischießen“ nie
auf. Sollte man mit einem HMD einen größeren Raum verwenden, könnte diese Art der Hilfe eher störend oder
unrealistisch wirken
49
4 Ergebnisse
Die angesprochene Verzerrung (Abb. 4.10) erschwerte die Navigation ein wenig und das Erkennen von rechteckigen Bereichen, die gar keine Marker waren, führte gelegentlich zu Problemen: wurde etwa ein Bildbereich fälschlicherweise als Werkzeugmarker erkannt, konnte es
vorkommen, dass auf einmal ein Tor die Größe änderte oder das Modell wechselte. Eine zusätzliche Sicherung könnte hilfreich sein.
Spielspaß
Das Spielkonzept kam allgemein gut an, wobei die Neuheit der Augmented Reality ein großes
Stück zur Faszination beitrug. Testpersonen nahmen, drehten, neigten und vertauschten Marker
während des Spiels, um die verschiedenen Effekte betrachten zu können. Die Langzeitmotivation des Spiels war zwar im Moment eher gering, doch sollten die vorgeschlagenen (nicht umgesetzten) Spielideen und der (zur Zeit nur rudimentär vorhandene) Mehrspieler-Modus diese
immens steigern.
Joysticksteuerung
Die analoge Joystick-Raumschiffsteuerung erwies sich nach einigen Minuten als sehr angenehm
und als fast zu einfach – dadurch, dass das Raumschiff keinem seitlichen „Drift“ erlag, konnte
präzise gesteuert werden. Eine verbesserte Flug-/Fahrphysik wurde vermisst.
Marker
Da das Spiel den erstbesten Marker zur Ausrichtung verwendet, kam es zudem zu einer schrägen Spielwelt, wenn das erste erkannte Musterfeld nicht waagerecht auf einem Untergrund lag.
Alle folgenden Übergaben der Koordinaten mussten diese schräge Positionierung übernehmen.
Wichtig ist daher, dass der „Startmarker“ immer auf einer waagerechten Unterlage liegt. Dies ist
ebenfalls für die korrekte Bestimmung des Schattens wichtig. Ansonsten kann der Spieler Musterfelder beliebig verteilen und auch kopfüber an der Decke anbringen (um etwa einen Looping
fliegen zu müssen).
50
5.1 Abgeschlossene Umsetzung
Die zum Zeitpunkt der Abgabe vorliegende Version der Software war voll einsatzfähig und beinhaltete die wesentlichen Elemente, mit denen man bei der Entwicklung einer AR-Applikation
in Kontakt treten muss: die Planung einer stabilen und immersiven Anwendung, die Koordinatenauswertung und -umsetzung (die das Toolkit über die Marker liefert) und die Grundlagen
einer Kollisionsprüfung mit angedachten und teilweise integrierten Methoden zur Steigerung
des Immersionsgefühls. Das Toolkit stellt hierfür eine gute Grundlage. Es ist nach der Einarbeitungsphase ein mächtiges Werkzeug. Leider war die Bildqualität der Kameras nicht sehr gut,
so dass offen bleibt, ob bei Verwendung präziserer Kameras eine stabilere Erkennung möglich
gewesen wäre.
5.2 Optimierungsansätze und Erweiterungen
Vor allem die zeitliche Begrenzung hat zwangsläufig dazu geführt, dass einige geplante Ideen
nicht umgesetzt werden konnten. Neben technischen Feinheiten (eine verbesserte Kollisionserkennung, direkt aus den VRML-Modellen abgeleitete Bounding-Boxes, Integration von 3DSound und Mehrkanalton mit Musik, aufwendigere Graphiken, Erweiterungen der Interaktionsmöglichkeiten mit Markern), gibt es aber doch einige spezielle Verbesserungen, die kurz aufgezählt und beschrieben werden sollen.
5.2.1 Erkennung der Markerposition
Um eine bessere Vermischung der realen und virtuellen Welt zu erhalten, wäre es sinnvoll, die
Ausrichtung der einzelnen Marker untereinander zu berücksichtigen. Der Benutzer müsste einen
speziellen Marker auf eine ebene Fläche legen und das Toolkit kann im Bezug zu diesem Muster
die Ausrichtung aller anderen bestimmen. Hilfreiche wäre dies zum Beispiel für die Projektion
des Schattens. Ist dem Toolkit durch den Bezug zum genannten Marker bekannt, dass ein weiteres Muster kopfüber angebracht ist, wird kein Schatten projiziert und etwaige Partikeleffekte
(o.ä.) des Modells müssten der Schwerkraft folgend fallen (in relativen Koordinaten zum Tor
dann nach oben!).
Derzeitig sind spezielle Marker vorgesehen, um diese Eigenschaften mitzuteilen. Spezielle
Musterfelder, etwa für Wände, werden verwendet, um eine Kollision auszulösen, aber keinen
Schatten auf sich zu projizieren.
51
5.2.2 Verdeckung
Auf der Suche nach weiteren Möglichkeiten, die Immersion in das Spiel und die Vermischung
der realen und virtuellen Welt weiter voranzutreiben, kam die Idee auf, neben der Kollision mit
realen Objekten auch noch Verdeckung zu integrieren. Die Informationen hierfür liefern bereits
die Marker (siehe Kapitel 4.2.2). Jetzt müssten diese normalerweise nicht gezeichneten Kollisionsebenen nur noch in den Depth-Buffer geschrieben werden, um die Raumschiff-Bereiche
wegzuclippen, die hinter dieser Ebene liegen. Ist der Color-Buffer dabei deaktiviert, wird man
die Kollisionsebene nachher nicht im Bild sehen.
Abbildung 5.1: Verdeckung der augmentierten Objekte durch reale Gegenstände (Montage)
5.2.3 Fortführung des Spielkonzepts, Optimierung
Neben dem umgesetzten Arcarde-Modus sollte auch noch die beschriebene Variante mit Computer-Gegnern umgesetzt werden. Eine Erweiterung um einen Karriere-Modus mit der Möglichkeit, bessere Raumschiffe zu kaufen und vorhandene zu modifizieren, wäre erstrebenswert.
Prinzipiell könnte jeder Benutzer auch eigene Graphiken integrieren (eigene VRML-Modelle
einladen) und so das Spiel besser personalisieren. Bessere Graphiken, Partikel-Systeme und mit
der Zeit aufwendigere Effekte im Spiel könnten den Benutzer länger „bei der Stange halten“
(siehe Kapitel 3.1).
Das Spiel sinnvoll und spannend mehrspielerfähig zu gestalten, ist jedoch schwierig: wird
mit HMDs gespielt, muss jeder Spieler ein eigenes tragen und eine Synchronisation über das
Netzwerk wäre notwendig.
Trägt nur ein Spieler ein HMD, muss der zweite Spieler immer durch die Augen des anderen
steuern. Ist hingegen nur ein Monitor angeschlossen, verliert das Spiel zwar einen Teil seines
AR-Charakters, kann aber fair von mehreren Spielern gleichzeitig bedient werden.
Eine etwas andere Mehrspieler-Variante ist an das MagicBook-Konzept des HITLabs[2] angelehnt. Der zweite Spieler sitzt vor einem Bildschirm und sieht die Spielwelt aus Sicht des
52
5.3 Ausblick
Raumschiffs. Er betritt die virtuelle Welt und steuert aus der Ego-Perspektive weitere Raumschiffe, die Bordkanone, etc., um dem ersten Spieler zu assistieren oder gegen ihn anzutreten.
Denkbar wäre eine Kooperation, bei der der zweite Spieler Hilfsaufgaben übernimmt. Da der
erste Spieler den zweiten als Avatar oder Raumschiff, etc. in seiner augmentierten Sicht eingeblendet bekommen würde, könnte er ihm Hinweise geben, z.B. wo er hinfliegen soll. (Spieler
1 hat die totale Übersicht über das Spielfeld, während Spieler 2 nur einen kleinen Ausschnitt
sieht.)
Die einzige störende Einschränkung wäre hier, dass der zweite Spieler nicht die reale Umgebung sehen kann, sondern nur die virtuellen Objekte am Bildschirm sieht. (Um dieses Problem
zu beheben, müsste man mehrere Kameras verwenden, um etwa dem zweiten Spieler eine Skybox1 aus dem realen Raum um die virtuelle Welt zu legen.)
5.3 Ausblick
Das vorgestellte Toolkit bietet einen günstigen Einstieg in die AR-Technologie, da das Marker
basierte Tracking neben einem Bildschirm und einer Kamera nur die Musterfelder benötigt, die
schnell selbst erstellt werden können.
Sind die Begrenzungen und Möglichkeiten des Inside-Out-Prinzips erkannt, wird der SoftwareEntwickler nach der vermutlich am längsten währenden Konzept-Phase die meiste Zeit damit
verbringen, die Funktionalitäten des eigenen Programmes zu implementieren – das Toolkit selbst
tritt in den Hintergrund und liefert unkompliziert die neuen Matritzen der definierten Muster.
Leider ist die Stabilität des Trackings nur in unmittelbarer Nähe und ruhiger Kameraposition
sehr hoch. Sobald der Anwender schnelle Bewegungen ausführt, sich weiter entfernt, sich die
Beleuchtung verändert oder Marker teilweise unter Schatten verschwinden, verliert das Toolkit
an Präzision. Sollte es sich um kritische Anwendungen handeln, bei denen eine millimetergenaue Visualisierung vonnöten ist, kann das Toolkit noch nicht zum Einsatz kommen.
Da diese Technologie so jung ist, sind viele Fragen noch zu klären. Es gibt genug Potential für weitere Forschungen. Die Bildverarbeitung und perspektivische Bestimmung der Marker zum Positionstracking ist ein eigenes, umfangreiches Feld für Studien- und Diplomarbeiten
(– anzustreben wäre ohnehin ein Tracking, welches komplett ohne vordefinierte Musterfelder
auskommt).
Ebenso dürften sich bei der Verwendung von Head-Mounted- oder Head-Coupled-Displays
weitere Bereiche anschließen, die sich mit der Handhabbarkeit der Geräte, der Anpassung vorhandener und Entwicklung neuer, besser geeigneter Eingabegeräte und der Kalibrierung beschäftigen werden. Gerade der letzte Punkt ist zur Zeit die größte Hürde, um Geräte unkompliziert in den Consumer-Bereich zu bringen. Ohne eine Automatisierung muss der Anwender bei
nur leichtem Verrutschen des Displays die AR-Anwendung neu kalibrieren, um die virtuellen
mit den realen Bildern auf Deckung zu bringen.
1
Die virtuelle Welt des 2. Spielers ist natürlich endlich. Sie liegt letztlich in einem Würfel, deren Innenflächen normalerweise eine Landschaft-, Weltraum- oder Himmelstextur zeigen würden, um die Immersion in die Spielumgebung zu steigern. In diesem Fall müsste man jedoch genaugenommen in Echtzeit aktualisierte Kamerabilder
als Texturen verwenden, so dass der 2. Spieler den realen Raum des 1. Spielers als Umgebung eingeblendet bekommt. Eine genaue Abbildung wäre allerdings sehr aufwendig, da eine Kamera – sollte überhaupt eine an der
aktuellen Spielerposition existieren – ihre Position real verändern müsste, sollte sich Spieler 2 virtuell bewegen.
53
Gelänge es, HMDs leicht und stromsparend genug zu entwickeln, leistungsstarke, mobile Geräte für den Endverbraucher günstig anzubieten und das Tracking zu optimieren, stünde einem
umfangreichen Einsatz der AR-Technologie im Alltag nichts mehr im Wege. Ob als Navigationshilfe für Touristen, für den Museumsbesuch, die multimediale Bedienungsanleitung, das
moderne Brettspiel, das Einblenden wichtiger, unterstützender Informationen bei Operationen
oder das virtuelle Einrichten des Wohnzimmers vor der Kaufentscheidung – mit der richtigen
Umsetzung dürfte die Augmented Reality in einigen Jahren ein normaler Bestandteil des technologischen Alltags sein.
54
6 Anhang
6.1 Beispielprogramm
#ifdef _WIN32
#include <windows.h>
#endif
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include
#include
#include
#include
#include
#include
char
int
int
int
char
ARParam
char
int
int
double
double
<GL/gl.h>
<GL/glut.h>
<AR/gsub.h>
<AR/param.h>
<AR/ar.h>
<AR/ARFrameGrabber.h>
*vconf = "";
xsize, ysize;
thresh = 100;
count = 0;
// die Kameraparameter müssen vorher mit dem
// mitgeliefertem Tool bestimmt und gespeichert werden
*cparam_name
= "Data/camera_para.dat";
cparam;
// die Musterfeld-Datei, die verwendet werden soll
*patt_name
= "Data/patt.wrench";
patt_id;
// Größe des Markers in Millimetern
patt_width
= 80.0;
// Offset zur Positionierung
patt_center[2] = {0.0, 0.0};
// Transformationsmatrix: sie wird vom Toolkit
// aktualisiert
patt_trans[3][4];
55
6 Anhang
static
static
static
static
static
void
void
void
void
void
init(void);
cleanup(void);
keyEvent( unsigned char key, int x, int y);
mainLoop(void);
draw( void );
ARFrameGrabber camera;
int main()
{
CoInitialize(NULL);
// Initialisierung der Anwendung
init();
//Video-Capture starten
camera.Init(0);
camera.DisplayProperties();
camera.SetFlippedImage(true);
//die main event loop starten
argMainLoop( NULL, keyEvent, mainLoop );
CoUninitialize();
return 0;
}
static void
keyEvent( unsigned char key, int x, int y)
{
// Programm beim Drücken von ESCAPE verlassen
if( key == 0x1b ) {
cleanup();
exit(0);
}
}
/* main loop */
static void mainLoop(void)
{
ARUint8
*dataPtr;
ARMarkerInfo
*marker_info;
int
marker_num;
int
j, k;
56
// Videoframe capturen
camera.GrabFrame();
if( (dataPtr = (ARUint8 *)camera.GetBuffer()) == NULL ) {
arUtilSleep(2);
return;
}
if( count == 0 ) arUtilTimerReset();
count++;
// Umschalten in den 2D-Modus
argDrawMode2D();
// Zeichnen des Frames als Hintergrund
argDispImage( dataPtr, 0,0 );
// Marker im aktuellen Frame finden
if( arDetectMarker(dataPtr, thresh, &marker_info, &marker_num) < 0 ) {
cleanup();
exit(0);
}
// Prüfen, ob Objekte sichtbar sind
k = -1;
for( j = 0; j < marker_num; j++ ) {
if( patt_id == marker_info[j].id ) {
if( k == -1 ) k = j;
else if( marker_info[k].cf < marker_info[j].cf ) k = j;
}
}
if( k == -1 ) {
argSwapBuffers();
return;
}
// die Transformationsmatrix zwischen Kamera und Marker bestimmen und
// speichern
arGetTransMat(&marker_info[k], patt_center, patt_width, patt_trans);
// 3D-Objekte werden gezeichnet
draw();
// Buffer wechseln und danach von oben anfangen
argSwapBuffers();
}
57
6 Anhang
static void init( void )
{
ARParam wparam;
xsize = 320; ysize = 240;
// Kameraparameter setzen
if( arParamLoad(cparam_name, 1, &wparam) < 0 ) {
printf("Camera parameter load error !!\n");
exit(0);
}
arParamChangeSize( &wparam, xsize, ysize, &cparam );
arInitCparam( &cparam );
if( (patt_id=arLoadPatt(patt_name)) < 0 ) {
printf("Muster konnte nicht geladen werden.\n");
exit(0);
}
// Graphikfenter öffnen
argInit( &cparam, 2.0, 0, 0, 0, 0 );
}
// Aufräumen am Ende der Anwendung
static void cleanup(void)
{
argCleanup();
}
static void draw( void )
{
double
gl_para[16];
argDrawMode3D();
argDraw3dCamera( 0, 0 );
glClearDepth( 1.0 );
glClear(GL_DEPTH_BUFFER_BIT);
glEnable(GL_DEPTH_TEST);
glDepthFunc(GL_LEQUAL);
// Laden der Transformationsmatrix
argConvGlpara(patt_trans, gl_para);
glMatrixMode(GL_MODELVIEW);
58
glLoadMatrixd( gl_para );
glMatrixMode(GL_MODELVIEW);
glTranslatef( 0.0, 0.0, 25.0 );
glutSolidCube(50.0);
glDisable( GL_DEPTH_TEST );
}
59
6 Anhang
6.2 Systemkonfiguration
Entwicklungsplattform
• Pentium 4, 2,4 GHz
• 512 MB RAM
• GeForce 4 TI 4200
• Logitech Quickcam Pro USB 1.1
• Logitech Quickcam Express USB 1.1
• FireWire iBot
• Analogjoystick, 4 Buttons, 2 Achsen
• Microsoft Windows XP Professional, Service Pack 2
• Microsoft DirectX 9.0a
Eingesetzte Software
• Microsoft Visual Studio.net 7.0
• 3DSMax Version 5.0
• Adobe Photoshop 6.01
CD-ROM
Die beigefügte CD-ROM enthält einige Videos, die das Toolkit und das entwickelte Programm in
Aktion zeigen. Zusätzlich sind dort die Modelle, Beispielprogramme, dieser Text als PDF, ARToolkit-Versionen, Bilder und das AR-RACE (als binaries) gespeichert. Der Quellcode wird auf
Anfrage gerne zugesandt1 .
1
[email protected]
60
Literaturverzeichnis
[1] http://vase.essex.ac.uk/
[2] http://www.hitl.washington.edu
[3] http://www.hitl.washington.edu/research/shared_space/download/
[4] http://www.gamasutra.com
[5] http://www.gamedev.net
[6] http://www.microsoft.com
(Download -> DirectX -> DirectX 9.0 Software Development Kit with DirectX 9.0a Runtime)
[7] TU Wien, AR Toolkit-Bereich von Thomas Pintaric
http://www.ims.tuwien.ac.at/∼thomas/artoolkit.php
[8] Woo, M.; Neider, J.; Davis, T. OpenGL Programming Guide Third Edition, OpenGL Architecture Review Board
[9] Billinghurst, M., Kato, H., Weghorst, S. and Furness, T. A. (1999). A Mixed Reality 3D
Conferencing Application (Technical Report R-99-1). Seattle: Human Interface Technology Laboratory, University of Washington.
[10] Kevin Hawkins; Dave Astle OpenGL Game Programming Prima Tech
[11] Müller, S.; Computergraphik 2; Universität Koblenz, 2002-2003
http://www.uni-koblenz.de/∼cg/veranst/ws0203/cg2.html
[12] Müller, S.; Virtuelle Realität und Augmented Reality; Universität Koblenz, 2003
http://www.uni-koblenz.de/∼cg/veranst/ss03/vrar.html
61

2 Grundlagen der Arbeit

Transcrição

Documentos relacionados

Urban War Turnier

Wie sich der Gehirntumor verrät

ACRYL ACRYL - Bettags Malschule

Tischtennis Game - Tischtennis

Die Affen sind los!

Browser Games

Aktuell - PC leicht gemacht

Spielregeln „Zicke Zacke Hühnerkacke“ (1101)

summer #07 - Elbtunnel

Hallo Jungs, die Feierlichkeiten zum 90