Design einer Bedienschnittstelle für die multimodale Navigation in ...

Technische Universität München
Lehrstuhl für
Mensch-Maschine-Kommunikation
Prof. Dr. rer. nat. M. Lang
Diplomarbeit
Design einer Bedienschnittstelle
für die multimodale Navigation
in virtuellen 3D Welten
Verfasser: Herbert Stocker
Goldbachstr. 40
83620 Vagen
Matrikelnummer 1615084
Betreuer TUM: Dipl.-Inform. Frank Althoff
Betreuende Firma: blaxxun interactive AG
Elsenheimer Str. 61-63
D-80687 München
Abgabetermin: 04.02.2002

München, den 04.02.2002
Ich versichere, daß ich diese Diplomarbeit
selbständig verfaßt und nur die
angegebenen Quellen und Hilfsmittel
verwendet habe.
Herbert Stocker

Inhaltsverzeichnis
1 Einleitung .................................................................................. 1
2 Benutzungsinterfaces ............................................................... 4
2.1 Verfügbare Modalitäten .......................................................................... 4
2.2 Entwicklung von Benutzungsinterfaces ..................................................... 6
2.3 Forderungen an ein 3D Benutzungsinterface ............................................. 7
3 VR Anwendungen ..................................................................... 9
3.1 Beispiele ............................................................................................. 9
3.2 Applikationsstruktur ............................................................................ 11
3.3 Interaktionsparadigmen ....................................................................... 12
3.3.1 Navigation ............................................................................... 12
3.3.2 Manipulation ............................................................................ 13
3.3.3 Kommunikation ........................................................................ 14
3.4 Kategorisierung von Eingabegeräten ...................................................... 14
3.5 Das multimodale Bediensystem MIVIS ................................................... 16
4 Die VRML Technologie ............................................................. 18
4.1 Sprachmodell ..................................................................................... 18
4.2 Ausführungsmodell .............................................................................. 23
4.3 Konzept für Benutzerinteraktion ............................................................ 24
4.3.1 Manipulation ............................................................................ 24
4.3.2 Navigation ............................................................................... 25
5 Anpassbare Navigation ........................................................... 28
5.1 Zugrundeliegende Formalismen ............................................................ 28
5.1.1 Bewegungsarten ....................................................................... 29
5.1.2 Koordinatensysteme ................................................................. 29
5.1.3 Richtungssysteme ..................................................................... 31
5.2 Bewegungen ....................................................................................... 33
5.2.1 Darstellung .............................................................................. 33
5.2.2 Filterung .................................................................................. 34
5.3 Möglichkeiten in existierendem VRML ..................................................... 35
5.3.1 Ein typischer Browser ................................................................ 35
5.3.2 Anpassbare Navigation .............................................................. 36
5.4 Lösungsansatz .................................................................................... 37
5.4.1 Zielsetzung .............................................................................. 38
5.4.2 Konzept ................................................................................... 38

6 Repräsentation von Eingabegeräten ....................................... 41
6.1 Anforderungen .................................................................................... 41
6.2 Überblick ............................................................................................ 42
6.3 Knoten-Spezifikation ........................................................................... 43
6.4 Erläuterungen ..................................................................................... 44
6.4.1 Aktivierungslogik ...................................................................... 44
6.4.2 Standardisierung von Geräten .................................................... 45
6.5 Diskussion .......................................................................................... 46
6.5.1 Eingabefokus in Multitasking Systemen ....................................... 46
6.5.2 Flexibilität durch Rückgriff auf Proto Mechanismus ........................ 46
6.5.3 Methoden für den Gerätezugriff .................................................. 47
6.5.4 DeviceSensor als bindbarer Knoten ............................................. 48
6.6 Typische Geräte und deren Implementierung .......................................... 50
6.6.1 Implementierung der Basisfunktionalität ..................................... 50
6.6.2 Spacemouse ............................................................................ 50
6.6.3 Joystick ................................................................................... 52
6.6.4 Maus und Tastatur .................................................................... 54
6.6.5 TCP Verbindungen .................................................................... 56
7 Steuerung der Navigation ....................................................... 59
7.1 Anforderungen an Knoten für die Navigation ........................................... 59
7.1.1 Unterstützung geschwindigkeitsorientierter Eingabegeräte .............. 59
7.1.2 Unterstützung positionsorientierter Eingabegeräte ........................ 60
7.1.3 Unterstützung referenzierender Navigation .................................. 60
7.1.4 Unterstützung diskreter Navigation ............................................. 61
7.1.5 Kontrolle über grundlegende Navigationsparameter ...................... 61
7.2 Knotenspezifikation ............................................................................. 62
7.2.1 Der Knoten NavigationInfo2 ....................................................... 63
7.2.2 Der Knoten NavigationSensor ..................................................... 64
7.2.3 Der Knoten Navigator ................................................................ 65
7.2.4 Abbrechbarkeit von Viewpoint-Animationen ................................. 68
7.3 Kombination der Bewegungsdaten ......................................................... 70
7.3.1 Darstellung als Signalflußplan .................................................... 70
7.3.2 Darstellung als Pseudocode ........................................................ 74
8 Multimodale Interaktion ......................................................... 77
8.1 Existierende Software .......................................................................... 77
8.1.1 Formale Funktionsmodellierung .................................................. 77
8.1.2 Aufbau des ursprünglichen MIVIS Systems .................................. 80
8.2 Designentscheidungen ......................................................................... 83
8.2.1 Kommunikationskanal für zeitkontinuierliche Werte ...................... 83
8.2.2 Navigationsmodi ....................................................................... 83
8.2.3 Haptische Interpreter ................................................................ 84
8.2.4 Kontinuierlicher Integrator ......................................................... 85
8.2.5 Feedback an Benutzer ............................................................... 85

8.3 Systemarchitektur ............................................................................... 86
8.3.1 Systemüberblick ....................................................................... 86
8.3.2 Eingabemodule ........................................................................ 87
8.3.3 Kommunikationskanäle ............................................................. 88
8.3.4 Diskreter Integrator .................................................................. 89
8.3.5 Navigator ................................................................................ 89
8.3.6 Kontinuierlicher Integrator ......................................................... 90
8.3.7 Feedback-Modul ....................................................................... 90
8.4 Erweiterung des Funktionsumfangs ....................................................... 90
8.4.1 Quasikontinuierlichen Navigation ................................................ 91
8.4.2 Referenzierende Navigation ....................................................... 92
8.4.3 Steuerkommandos .................................................................... 95
8.4.4 Formalismus für Status Anzeigen ................................................ 97
8.5 Implementierung ............................................................................... 99
8.5.1 Verwendung von VRML/VrmlScript ............................................ 100
8.5.2 Kommunikationskanäle ........................................................... 101
8.5.3 Diskreter Integrator ................................................................ 102
8.5.4 Kontinuierlicher Integrator ....................................................... 102
8.5.5 Navigator .............................................................................. 102
8.5.6 Die haptischen Interpreter ....................................................... 103
9 Weiterführende Arbeiten ...................................................... 104
9.1 Anwendungsbeispiele ......................................................................... 104
9.2 Ausbau der Systemstruktur ................................................................ 105
9.2.1 Rückgängig machen haptisch gesteuerter Bewegungen ................ 105
9.2.2 Kontinuierliche Zeigegesten ..................................................... 106
9.3 Ausbau der Funktionalität ................................................................... 107
9.3.1 Zugriff der Anwendung ............................................................ 107
9.3.2 Referenzieren beweglicher Objekte ............................................ 108
9.3.3 Multimodale und dreidimensionale Umsetzung des Kontextmenüs .... 110
9.4 Ausbau auf das Paradigma Manipulation ................................................ 111
9.4.1 Systemarchitektur .................................................................. 112
9.4.2 Funktionalität ......................................................................... 113
9.4.3 Anwendungen ........................................................................ 114
10 Zusammenfassung .............................................................. 115

Verzeichnisse ........................................................................... 117
Abbildungsverzeichnis ............................................................................. 117
Referenzen ............................................................................................ 118
Internet Seiten ....................................................................................... 119
Anhang A Konventionen ............................................................ 120
Anhang B Beispielszenarios für angepaßte Navigation .............. 121
Anhang C Erweiterter Kommunikationsformalismus ................. 124
Anhang D DeviceSensor SDK für blaxxun Contact ..................... 127

1 Einleitung
Kapitel 1, Einleitung
Menschen kommunizieren sowohl untereinander als auch mit einem technischen System
besonders effektiv, wenn ihnen dazu möglichst viele Interaktionsformen zur Verfügung
stehen. Jede Eingabemodalität hat ihre besonderen Stärken und Schwächen. Beispielsweise
können mit gesprochener Sprache abstrakte Zusammenhänge sehr gut ausgedrückt
werden, und Handgesten eignen sich gut zum Beschreiben von Positionen und
Richtungen. In der Kombination eignen sich beide Modalitäten hervorragend, um auf ein
Objekt zu zeigen und anzugeben, was damit passieren soll.
Computersysteme haben im Laufe der Zeit eine starke Verbreitung gefunden. Während
Anfang der 50er Jahre Rechenmaschinen noch ausschließlich von Experten bedient wurden,
hat in den 90er Jahren mit den Personal Computern (PC) der Einzug in den Büroalltag
begonnen, und in letzter Zeit eroberten Computer durch die Verbreitung des Internets
und der mobilen Kommunikationsmöglichkeiten das Alltagsleben auch im privaten
Bereich. Während sich das bei den durchschnittlichen Benutzern vorhandene Fachwissen
über Computersysteme immer weiter verringert hat, wurden die Einsatzgebiete immer
umfangreicher und damit die Bedienung immer komplexer. Dadurch waren auch die Bedienschnittstellen
einem starken Wandel unterworfen und nahmen an Komplexität zu. Die
ersten Systeme wurden mit Lochkarten programmiert. Heute sind zweidimensionale,
grafische Benutzungsoberflächen weit verbreitet.
Für die Zukunft zeichnet sich eine Entwicklung in Richtung dreidimensionaler Bediensysteme
ab, die der real erfahrbaren Welt nachempfunden sind. Anwendungen der virtuellen
Realität erlauben die unmittelbare Wechselwirkung des Menschen mit der computergenerierten
Darstellung. Die bei grafischen Benutzungsoberflächen typischen Bedienelemente
Window, Icon, Menü und Zeigegerät (WIMP) werden durch dreidimensionale Einund
Ausgabeverfahren ersetzt. Neben visueller Darstellung können auch richtungsabhängige
akustische Signale und taktile Reize einbezogen werden.
Obwohl die Kommunikationsfähigkeit des Menschen von einem intensiven Gebrauch
möglichst vieler Kommunikationskanäle (Multimodalität) abhängt, wurde bei der Kommunikation
mit dem Computer meistens nur ein Eingabegerät, die Tastatur eingesetzt.
Erst in letzter Zeit kam die Maus als Zeigegerät hinzu, wodurch sich erste Ansätze von
Multimodalität abzeichneten. Dreidimensionale (3D) Benutzungsschnittstellen bieten einen
flexiblen und intuitiven Zugang zu komplexen Systemen. Während sich beispielsweise
semantisch höherwertige Modalitäten wie natürliche Sprache und Gestik gut eignen,
um abstrakte Zusammenhänge auszudrücken und deshalb von großer Bedeutung für die
Bedienung komplexer Systeme sind, können erst mit haptischen Eingabekanälen präzise
räumliche Informationen schnell weitergegeben werden.
Aber auch haptische Eingabegeräte haben ihre Stärken und Schwächen: An einem bildschirmorientierten
3D Arbeitsplatz eignet sich ein Joystick beispielsweise sehr gut, um
weite Strecken zurückzulegen, die Spacemouse hat ihre Stärken bei der exakten Positionierung
in allen Freiheitsgraden, benötigt aber im Umgang viel Übung und Erfahrung.
Eine Maus eignet sich gut zum Referenzieren von Objekten.
Zielsetzung
Am Lehrstuhl für Mensch-Maschine-Kommunikation wird ein multimodales Bediensystem
für 3D Applikationen (MIVIS) entwickelt, mit dem ein Benutzer mittels semantisch höherwertigen
Modalitäten Interaktionsaufgaben in dreidimensionalen Umgebungen durchführen
kann. Ziel dieser Diplomarbeit ist es, dieses System so zu erweitern, daß darauf
basierende Anwendungen auch mit haptischen Eingabegeräten intuitiv und effizient bedient
werden können. Dabei soll der Benutzer die Möglichkeit haben, zur Erledigung einer
Aufgabe aus semantisch höherwertigen Modalitäten und mehreren haptischen Eingabegeräten
frei zu wählen und diese kombinieren zu können. Die Arbeit orientiert sich an der
Domäne der Navigation in virtuellen 3D Umgebungen.
Seite 1

Kapitel 1, Einleitung
In einem ersten Schritt werden Sprachkonstrukte in der 3D Szenenbeschreibungssprache
VRML entwickelt, die es dem Autor einer Anwendung ermöglichen, das Navigationsparadigma
an die Bedürfnisse einer Anwendung und deren Nutzerkreis anzupassen, sowie
beliebige Eingabegeräte dabei zu berücksichtigen. Darauf aufbauend wird die Architektur
des bestehenden MIVIS Systems um die Unterstützung mehrerer haptischer Eingabegeräte
erweitert, so daß ein System für hochgradig multimodale Bedienung entsteht.
Wenn eine umfangreiche Funktionsvielfalt die Kopplung zwischen Mensch und Maschine
intensiviert, kann das Benutzungsinterface in der Wahrnehmung des Benutzers verschwinden
und den Blick auf die eigentliche Aufgabe freigeben. Daher wird der Funktionsumfang
des MIVIS Systems substantiell erweitert und die Kommunikation zwischen den
einzelnen Systemkomponenten ausgedehnt.
Durchführung
Das ursprüngliche MIVIS System basiert auf dem als freie Software verfügbaren VRML
Browser FreeWRL unter Linux. Da sich der kommerzielle Browser blaxxun Contact in einem
wesentlich fortgeschrittenerem Entwicklungsstadium befindet, wird das System im
Zuge dieser Diplomarbeit auf diesen Browser umgestellt. Zunächst wird der Browser um
eine modulare Schnittstelle zur Anbindung beliebiger Eingabegeräte und die Sprachkonstrukte
für anpassbare Navigation ergänzt. Die erweiterte Infrastruktur des MIVIS Systems
wird in der Sprache VRML und JavaScript implementiert, damit das System nach
Beendigung dieser Diplomarbeit leicht modifizierbar bleibt. Darauf aufbauend wird die
ausgebaute Funktionalität und die Anbindung der haptischen Eingabegeräte implementiert.
Um die bestehenden Module der semantisch höherwertigen Modalitäten und der
Modellierung der Benutzerintention einzubinden, wird die anfangs entwickelte Erweiterungsarchitektur
des Browsers dazu benutzt, um diese Module über Netzwerkverbindungen
anzukoppeln.
Gliederung
In Kapitel 2 wird zunächst ein Überblick über die Modalitäten gegeben, welche dem Menschen
zur Kommunikation zur Verfügung stehen, und die geschichtliche Entwicklung von
Benutzungsinterfaces aufgezeigt. Anschließend werden die zentralen Forderungen motiviert,
welche dieser Diplomarbeit zugrunde liegen.
Kapitel 3 gibt einen groben Überblick über existierende Virtual Reality (VR) Anwendungen.
Zunächst werden exemplarisch die umfangreichen Anwendungsgebiete von VR Anwendungen
aufgezeigt. Danach werden zentrale Bestandteile der Architektur von VR Anwendungen
identifiziert, die möglichen Interaktionsparadigmen erläutert und haptische
Eingabegeräte bezüglich ihrer Eignung für Interaktionsaufgaben kategorisiert. Abschließend
wird ein Überblick über das bestehende MIVIS System gegeben.
In Kapitel 4 wird VRML als eine Technologie für Internet basierte VR Anwendungen vorgestellt.
Es wird ein Überblick über das Sprachmodell gegeben, da dieses die Grundlage
für wesentliche Teile dieser Diplomarbeit darstellt. Anschließend wird die Architektur von
VRML erläutert und die Konzepte für Benutzerinteraktion werden beschrieben.
Die in dieser Diplomarbeit entwickelten Konzepte für flexible Interaktion werden in
Kapitel 5 erarbeitet. Zunächst werden die mathematischen Grundlagen und Konzepte zur
Beschreibung von Navigation in 3D Umgebungen identifiziert, auf die sich die gesamte
weitere Arbeit stützt. Ferner wird VRML dahingehend analysiert, inwiefern es, ohne verändert
zu werden, im aktuellen Zustand bereits Möglichkeiten zur Anpassung der Navigation
bietet. Anschließend wird ein Konzept entwickelt, nach dem VRML in den Kapiteln
6 und 7 auf eine echte Anpassbarkeit des Navigationsparadigmas erweitert wird. Abschließend
wird das Konzept für die Erweiterung des MIVIS Systems auf haptische Eingabegeräte
ausführlich diskutiert.
Seite 2

Kapitel 1, Einleitung
Kapitel 6 schlägt ein Sprachkonstrukt vor, mit dem sich beliebige haptische Eingabegeräte,
aber auch semantisch höherwertige Modalitäten in der Szenenbeschreibung formal
einheitlich darstellen lasen. Nach der Definition der Zielsetzung für dieses Sprachkonstrukt
und einer Diskussion seiner generellen Eigenschaften wird das Konstrukt als VRML
Knoten deklariert. Anschließend wird diese Deklaration erläutert und seine Besonderheiten
diskutiert. Das Kapitel schließt mit einer Diskussion ausgewählter Beispiele für die
Repräsentation von Eingabegeräten, die im Rahmen dieser Diplomarbeit implementiert
wurden.
Kapitel 7 widmet sich der Steuerung der Navigation durch die Szene. Es werden aus den
Eigenheiten der möglichen Navigationsarten und der verschiedenen Arten von Eingabegeräten
eine Anzahl von Attributen und Signalen abgeleitet, die eine Anwendung kontrollieren
bzw. erzeugen muß, damit sich der Benutzer auf vielfältige Weise durch die virtuelle
Welt bewegen kann. Anschließend werden die aus dieser Diskussion abgeleiteten
Sprachkonstrukte spezifiziert und erläutert. Den Abschluß dieses Kapitels bildet ein Überblick
über die zugrunde liegende Implementierung.
Kapitel 8 beschreibt die Erweiterung des Bediensystems MIVIS auf haptische Modalitäten
und die Erweiterung des Funktionsumfangs. Nach einem Überblick über die technische
Realisierung des MIVIS Systems werden die für die Erweiterung der Infrastruktur getroffenen
Designentscheidungen herausgearbeitet. Darauf aufbauend wird die erweiterte
Modulstruktur und der gesteigerte Funktionsumfang detailliert erläutert. Abschließend
erfolgt eine Darstellung einiger Besonderheiten der Implementierung.
In Kapitel 9 werden nach Hinweisen auf Arbeiten, welche auf die Ergebnisse dieser Arbeit
aufbauen, Anstöße für die Weiterführung dieser Arbeit gegeben. Unter anderem wird ein
Vorschlag zur Erweiterung des Interaktionsparadigmas der Navigation auf das Paradigma
der Manipulation gegeben. Ferner werden die auftretenden Probleme, z.B. bei der Referenzierung
beweglicher Objekte diskutiert und ein Vorschlag zu deren Lösung angegeben.
Die Zusammenfassung dieser Diplomarbeit erfolgt abschließend in Kapitel 10.
Im Anhang A werden die in dieser Arbeit verwendeten Formatierungskonventionen erläutert.
Anhang B gibt einige Beispiele für VRML Code, der das Navigationsparadigma an
die Bedürfnisse einer Anwendung anpaßt. Die in dieser Arbeit entwickelte Grammatik,
welche die Funktionalität des erweiterten multimodalen Bediensystems beschreibt, ist in
Anhang C zusammengefaßt. Anhang D enthält schließlich eine Kopie der Dokumentation,
welche die Erweiterungsarchitektur beschreibt, mit der unabhängige Programmierer den
Browser um die Repräsentation zusätzlicher Eingabegeräte erweitern können.
Seite 3

2 Benutzungsinte rfaces
Kapitel 2, Benutzungsinterfaces
Interagiert ein Mensch mit einem technischen System, und ist er nicht der Konstrukteur
oder Wartungsingenieur, so hat er es immer mit einer Schnittstelle zu tun, die Information
zwischen dem Menschen und den technischen Vorgängen innerhalb der Maschine
austauscht. Diese Schnittstelle stellt das Benutzungsinterface dar. Für die Menschen, die
kein Verständnis der Technik der Maschine haben, ist das Benutzungsinterface der einzige
Zugang zum System. In der Vergangenheit bestand das Benutzungsinterface aus
Schaltern, Hebeln und Anzeigen, die sehr stark an die technischen Gegebenheiten der
Maschine gebunden waren. Seit der Entwicklung der Computertechnik können Benutzungsinterfaces
durch das hohe Maß an Flexibilität, welche diese Technik mit sich bringt,
von den Gegebenheiten in der Maschine sehr stark abstrahiert gestaltet, und an die Bedürfnisse
des Menschen angepaßt werden. Dies ist wichtig, da so ein intuitiver Umgang
mit der Maschine ermöglicht wird, ohne daß langwierige Einarbeitungs- oder Umlernphasen
beim Wechsel auf ein anderes System nötig werden. Auch ist der Mensch in Streßsituationen
eher in der Lage, richtig zu reagieren, wenn dies durch intuitive Handlungen
geschehen kann, da mühsam angelernte Vorgehensweisen leicht bei einer durch Streß
hervorgerufenen Blockade verlorengehen[3].
2.1 Verfügbare Modali täten
Dem Menschen stehen eine Vielzahl von Kanälen zur Verfügung, über die er sich äußern
und auf seine Umgebung einwirken kann. Die wichtigsten davon sollen hier kurz erläutert
werden. Diese Zusammenstellung ist Henning[4] entnommen.
• Die gesprochene Sprache ist von allen Modalitäten das augenfälligste und wichtigste
Kommunikationsmittel. Mit ihr können sehr abstrakte Inhalte vermittelt werden.
Dafür eignet sie sich nicht sehr gut, um schnell exakte Positionsangaben zu übermitteln.
Die gesprochene Sprache wird überwiegend bewußt eingesetzt, und wird vom
Menschen auf natürliche Weise erlernt.
• Die Hände eignen sich durch die Möglichkeit zu gestikulieren ebenso zum Vermitteln
abstrakter Inhalte, jedoch wird dies im Alltag nicht so umfassend eingesetzt wie die
gesprochene Sprache. An eine bestimmte Problemdomäne angepaßte Zeichensprachen
sind jedoch leicht erlernbar. Die von Gehörlosen verwendete Zeichensprache
zeigt, daß diese Zeichensprachen die Komplexität von gesprochener Sprache erreichen
kann. Eine besondere Stärke des Gestikulierens mit den Händen ist die Fähigkeit,
positionsbezogene Information zu vermitteln. Dies kann sehr intuitiv beim Zeigen
auf Objekte verwendet werden, oder wenn Menschen einander beim Einparken
eines PKWs in eine enge Parklücke einweisen.
• Die Mimik ist ein weitgehend unbewußt eingesetztes Kommunikationsmittel. Sie gibt
Aufschluß über den Gemütszustand einer Person, und wird häufig ergänzend zur gesprochenen
Sprache eingesetzt. Im Bezug auf die Kommunikation mit einer Maschine
kann dieser Kanal Aufschluß über innere Zustände und Emotionen des Benutzers geben,
etwa wenn er mit der falschen Ausführung eines Befehls unzufrieden ist.
• Kopfbewegungen setzt der Mensch nur spärlich bewußt ein. Häufigstes Beispiel ist
das Nicken oder Schütteln des Kopfes, das „ja” bzw. „nein” bedeutet. Es lassen sich
jedoch einige wenige Kopfgesten für die bewußte Kommunikation vereinbaren. Allerdings
stoßen diese sehr leicht auf Ablehnung. Es hat sich jedoch gezeigt, daß Menschen
durch die Kopfhaltung instinktiv Information preisgeben, etwa wenn nach dem
Kommando an eine 3D Anwendung, die Blickrichtung zu ändern der Kopf schräg gehalten
wird, weil das Kommando zu stark oder zu schwach ausgeführt wurde[19].
Seite 4

Kapitel 2, Benutzungsinterfaces
• Die Blickrichtung der Augen gibt Aufschluß über die Aufmerksamkeit eines Benutzers.
Der anvisierte Punkt kann dazu benutzt werden, um über andere Modalitäten
gegebene Kommandos mit einem Objekt in Beziehung zu setzen. Der Sehsinn ist eine
rein sensorische Aktivität. In der natürlichen Umgebung ist ein Einwirken auf die Umwelt
durch bloßes Anschauen nicht möglich. Daher wirkt es irritierend für Benutzer
eines Computersystems, wenn über die Blickrichtung Aktionen ausgelöst werden oder
sich die Darstellung ändert[3].
Diesen Kanälen ist gemeinsam, daß sie dem Menschen von Natur aus zur Übermittlung
von Bewußtseinsinhalten gegeben sind. Da sie überwiegend abstrakte Inhalte transportieren,
werden sie semantisch höherwertige Modalitäten, oder kurz SHM genannt. Ihre
Verwendung zur Kommunikation mit der Maschine ist zur Zeit noch Gegenstand der Forschung.
Um auf seine physikalische Umgebung einzuwirken benutzen Menschen hauptsächlich
die Hände. Für die Mensch-Maschine-Kommunikation wird eine Vielzahl von Eingabegeräten
eingesetzt, die darauf beruhen, daß sie physikalisch mit den Händen, teilweise
auch mit anderen Körperteilen manipuliert werden. Man nennt dies haptische Modalitäten.
Abgesehen von alphanumerischen Tastaturen eignen sich haptische Modalitäten
besonders gut, um exakte, mehrdimensionale Größen eines kontinuierlichen Wertebereiches
einzugeben, und um schnell auf Ereignisse in der Anwendung zu reagieren.
Manche Eingabegeräte haben eine Möglichkeit, Informationen an den Benutzer zurückzugeben,
meist in Form von Kräften, die auf den Körper des Benutzers wirken. Damit können
Ereignisse, die in einer Anwendung auftreten, z.B. die Beschränkung eines Bewegungsbereiches
dem Benutzer auf sehr intuitive Weise signalisiert werden.
• Die am häufigsten eingesetzten Eingabegeräte sind Tastaturen zur Texteingabe oder
um Kommandos abzusetzen, und die Maus als zweidimensionales Zeigegerät. Mit der
Maus kann sehr präzise auf bestimmte Positionen in einem zweidimensionalen Koordinatensystem
gezeigt werden, jedoch geschieht dies durch einen mehrschrittigen
Vorgang, bei dem die Position einer auf dem Bildschirm dargestellten Positionsmarke
korrigiert wird. Dadurch sind besonders schnelle Eingaben exakter Positionen nicht
ohne weiteres möglich.
• Joysticks sind im Zusammenhang mit Computerspielen sehr populär geworden, da
sie billig hergestellt werden können, und mit ihnen eine flüssige Steuerung von Bewegungsabläufen
möglich ist. Es gibt Joysticks in vielfältigen Ausführungen, von einfachen
Steuerknüppeln mit nur zwei Freiheitsgraden und zwei Druckknöpfen bis hin
zu aufwendigen Nachbildungen realer Flugzeugsteuerknüppel mit vielen einzelnen
Bedienelementen und Kraftrückkopplung.
Manche Eingabegeräte sind speziell für die Eingabe von dreidimensionalen Bewegungen
oder Positionen geschaffen. Wenn diese Eingabegeräte alle sechs Freiheitsgrade des
dreidimensionalen Raumes – drei unabhängige Richtungen der Verschiebung und drei
unabhängige Richtungen der Drehung – unterstützen, werden sie als 6DOF Geräte (six
degrees of freedom – sechs Freiheitsgrade) bezeichnet.
• Ein Beispiel für 6DOF Geräte ist die Spacemouse der Firma 3DConnexion[25]. Sie
besteht aus einer Kappe, die vom Benutzer in alle sechs Richtungen gedrückt werden
kann. Es wird die in jede Richtung wirkende Kraft separat gemessen. Diese Geräte
eignen sich besonders, um Objekte virtuell im Raum frei zu bewegen, oder um die
Position und die Orientierung, aus der man eine simulierte 3D Szene sieht, frei zu
verändern.
• Tracker sind Sensoren, welche die Position und die Orientierung eines Objektes im
Raum berührungslos messen. Sie werden besonders effektiv in Verbindung mit einem
Datenhandschuh eingesetzt. Ein Datenhandschuh mißt die Beugung der Finger einer
Hand. In Verbindung mit einem Tracker kann das Manipulieren von Objekten und
das Zeigen realisiert werden. Mißt man mit einem Tracker die Position und Orientierung
des Kopfes, läßt sich auf diese Weise der darzustellende Bildschirmausschnitt
bestimmen.
Seite 5

2.2 Entwicklung von B enutzungsinterfaces
Kapitel 2, Benutzungsinterfaces
Die Entwicklung von Schnittstellen für die Mensch-Maschine-Kommunikation (MMK) stellt
schon seit langem ein eigenes Forschungsgebiet dar, insbesondere da durch die wachsende
Funktionalität von Computer Systemen diese sehr komplex werden können. Bisher
mußte zumeist der Benutzer sich an die Systeme anpassen und den Umgang mit ihnen
lernen. Viel Aufwand wurde und wird getrieben, um diese Hürde zu minimieren, und die
Schnittstellen intuitiver zu gestalten, so daß die Systeme auch von Laien benutzt werden
können.
Im Laufe der Zeit war die Beschaffenheit von Benutzungsschnittstellen einem Wandel
unterworfen. Nach Henning[4] kann diese Entwicklung in die folgenden sechs Generationen
eingeteilt werden. Jeder Generation kann eine Anzahl Dimensionen zugeordnet werden,
in der Interaktionen möglich sind. Es läßt sich ein eindeutiger Trend mit der Zeit
ansteigender Dimensionalität feststellen, der den wachsenden Interaktionsspielraum veranschaulicht.
1) Rein physikalische Mensch-Maschine-Schnittstellen
Die allerersten Systeme, die als programmierbare Rechner bezeichnet werden konnten,
existierten hauptsächlich im Zeitalter der Röhrentechnologie. Rechenmaschinen dieser
Generation bestanden vollständig aus unveränderlichen mechanischen und elektromechanischen
Bauteilen. Das Programm zu ändern bedeutete eine Umstrukturierung der
Maschine. Der Benutzer mußte daher tiefgreifende Kenntnisse der Systemarchitektur der
Maschine haben. Diese Maschinen wurden hauptsächlich von Experten zum Durchführen
komplexer Berechnungen benutzt. Es war mit diesen Maschine keine Interaktion möglich.
2) Batch Systeme – nulldimensional
Batch Systeme waren die ersten Systeme, die sich vollständig mittels Software bedienen
ließen. Der Benutzer benötigte Programmierkenntnisse über die spezielle Maschine. Der
Umgang mit der Maschine gestaltete sich in drei Phasen: Man erstellt ein Programm –
typischerweise auf Lochkarten – das die Lösung der gestellten Aufgabe beschreibt, übergibt
es einem Operator, der die Programme der einzelnen Benutzer nacheinander der
Maschine zuführt, und wartet auf das Ergebnis. Der gravierendste Nachteil dieser Methode
ist die fehlende Rückkopplung vom System. Das Ergebnis einer Berechnung ist erst
nach Beendigung des Programms bekannt. Tritt ein Fehler während der Programmausführung
auf, z.B. ein fehlender Parameter, kann der Benutzer nicht korrigierend in den
Programmablauf eingreifen. Somit ergab sich auch bei diesen Systemen keine Möglichkeit
der Interaktion.
3) Zeilenorientierte Schnittstellen – eindimensional
Mit alphanumerischen Terminals – oder umgebauten Fernschreibern – hat die Wandlung
des Computers in ein Werkzeug des Alltags begonnen. In einem klassischen Frage –
Antwort Dialog fragt die Maschine den Benutzer nach Parametern, oder welche Aufgabe
sie erledigen soll. Wenn genügend Information gesammelt ist, führt sie die Berechnungen
durch und präsentiert die Ergebnisse dem Benutzer. Die Dialoge sind einfach gehalten
und nach einer strikten Hierarchie organisiert. Der Benutzer kann die Dialoge zwar selbständig
anstoßen, ist dann aber im Dialogschema gefangen und kann das Geschehen
nicht mehr direkt kontrollieren.
4) Bildschirmorientierte Schnittstellen – zweidimensional
Bildschirmorientierte Schnittstellen verschieben die Kontrolle über die Interaktion schon
mehr in Richtung des Benutzers. Eingabemasken, die an auszufüllende Formulare angelehnt
sind, eine Menüstruktur und eine Kommandosprache sind die kennzeichnenden
Merkmale solcher Systeme. Der Benutzer kann mit der Menüstruktur Eingabemasken
oder Befehle aufrufen und innerhalb einer Eingabemaske zwischen den einzelnen Eingabefeldern
wechseln. Hat der Benutzer eine Reihe von anstehenden Teilaufgaben zu lösen,
kann er seine Aktionen besser planen, um ein bestimmtes Ziel zu erreichen.
Seite 6

Kapitel 2, Benutzungsinterfaces
5) Graphische Schnittstellen – zweieinhalbdimensional
Graphische Benutzungsoberflächen bilden die Grundlage für die heute üblichen Arbeitsplatzrechner.
Sie erweitern die bildschirmorientierten Oberflächen um das WIMP Paradigma
(WIMP = Window, Icon, Menu, Pointing) und die direkte Manipulation[20]. Auf
dem Bildschirm werden zweidimensionale graphische Objekte plaziert, die sich gemäß
ihrer Reihenfolge in der dritten Dimension verdecken können. Mit einem Zeigegerät kann
der Benutzer auf diese Objekte zeigen, sie auswählen oder manipulieren. Ein Eingabefokus
legt fest, an welches Element Tastatureingaben gerichtet sind. Graphische Elemente
werden zu Fenstern (Windows) zusammengefaßt. Diese dienen als Schnittstelle zu Anwendungen.
Ein Icon ist ein Sinnbild, das für eine Anwendung, einen Befehl, ein Dokument,
usw. stehen kann.
Direkte Manipulation bedeutet, daß mit dem Zeigegerät die dargestellten Objekte direkt
verändert werden können, um über entsprechende Metaphern Aktionen auszulösen, ohne
daß dazu über ein Menü oder über direkte Kommandoeingabe ein Befehl abgesetzt werden
müßte. Diese Form der Bedienung kann sehr intuitiv gestaltet werden. Da graphische
Benutzungsschnittstellen meist mit einer Tastatur und einem Zeigegerät bedient werden,
beinhalten sie schon frühe Formen multimodaler Mensch-Maschine-Kommunikation.
6) Virtual Reality Systeme – dreidimensional
Systeme für Virtuelle Realität (VR) stellen den modernsten Ansatz für Benutzungsoberflächen
dar. Dreidimensionale, aber auch zweidimensionale Objekte werden in einem dreidimensionalen
Raum plaziert und dem Benutzer zur Manipulation angeboten. Durch die
hohe Ähnlichkeit mit der gewohnten Umgebung des Menschen können diese Schnittstellen
sehr stark auf intuitive Fertigkeiten des Benutzers bauen, was für ungeübte Personen
besonders wichtig ist. Erstmalig erlauben diese Systeme die Immersion – das vollständige
Eintauchen in die simulierte Umgebung, so daß diese an die Stelle der realen Welt
tritt. Dies wird dadurch erreicht, daß dem Benutzer z.B. über vor den Augen positionierten
kleinen Bildschirmen der visuelle Eindruck einer künstlichen Welt vermittelt wird,
während Sensoren die Position des Betrachters messen und das generierte Bild entsprechend
aktualisieren. Aber auch Desktop Systeme, die eine 3D Szene auf einem Monitor
darstellen und vom Benutzer beeinflussen lassen, gehören zur Domäne der VR Anwendungen.
Der Umgang mit solchen Systemen umfaßt das Navigieren (sich bewegen) in der
simulierten Welt und das Manipulieren der simulierten Objekte.
2.3 Forderungen an ei n 3D Benutzungsinterface
Menschen kommunizieren sowohl untereinander als auch mit einem technischen System
besonders effektiv, wenn ihnen dazu möglichst viele Interaktionsformen zur Verfügung
stehen. Jede Eingabemodalität hat ihre besonderen Stärken und Schwächen. Beispielsweise
können mit gesprochener Sprache abstrakte Zusammenhänge sehr gut ausgedrückt
werden, und Handgesten eignen sich gut zum Beschreiben von Positionen und
Richtungen. In der Kombination eignen sich beide Modalitäten hervorragend, um auf ein
Objekt zu zeigen und anzugeben, was damit passieren soll.
Ebenso haben im Bezug auf die Interaktion mit technischen Systemen haptische Eingabegeräte
ihre Stärken und Schwächen: An einem bildschirmorientierten Arbeitsplatz eignet
sich ein Joystick gut, um weite Strecken zurückzulegen, die Spacemouse hat ihre
Stärken bei der exakten Positionierung in allen Freiheitsgraden, benötigt aber im Umgang
viel Erfahrung und Übung. Eine Maus eignet sich gut zum Referenzieren von Objekten.
Zudem sind Benutzer individuell verschieden. Je nach Vorgeschichte haben Benutzer unterschiedliches
Wissen über das konkrete System, über Computer an sich oder die Domäne
der Anwendung[3]. Manche Benutzer haben ein ausgeprägtes räumliches Vorstellungsvermögen,
manche sind geübt im Umgang mit bestimmten Eingabegeräten, und
andere wiederum können sich gut Tastenkombinationen merken. Besonders Anfänger
benutzen gerne semantisch höherwertige Modalitäten und geben dabei redundante Information
über verschiedene Kanäle, während Experten eher zur Benutzung der Tastatur
tendieren[6].
Seite 7

Kapitel 2, Benutzungsinterfaces
Bietet man dem Benutzer zur Steuerung eines Computersystems möglichst viele haptische
Eingabegeräte und semantisch höherwertige Modalitäten gleichzeitig an, ergibt sich
für ihn ein breiter Zugang zum System, so daß er seinen Fähigkeiten und Präferenzen
zufolge die für ihn geeignetste und für die zu erledigende Teilaufgabe effektivste Form
der Interaktion wählen kann. Im Gegensatz zu einem System, das dem Benutzer eine
Interaktionsform aufzwingt, verstärkt sich durch den breiten Freiraum an Interaktionsmöglichkeiten,
aus denen der Benutzer wählen kann, das Gefühl, die Kontrolle über das
System inne zu haben. Durch die erhöhte Zufriedenheit mit dem System steigt die Effektivität
in der Bedienung des Benutzungsinterfaces weiter[3].
� Ein gutes Benutzungsinterface muß viele haptische und semantisch höherwertige
Modalitäten unterstützen und dem Benutzer erlauben, aus diesen frei auszuwählen
und zu kombinieren.
Ferner haben unterschiedliche Anwendungen unterschiedliche Benutzerkreise, die ihre
eigenen Anforderungen an ein Benutzungsinterface stellen. Eine interaktive Lernumgebung
für Kinder braucht z.B. eine besonders einfach zu benutzende Schnittstelle und an
die spielerische Art, wie Kinder die Welt entdecken, angepaßte Metaphern. Aber auch für
andere Anwendungsdomänen muß die Sprache der Anwendung an deren Zielgruppe angepaßt
werden. Dies betrifft sowohl den Kulturkreis der Anwender als auch durch die
Anwendungsdomäne gegebene Fachsprachen, als auch beim Benutzerkreis zu erwartendes
Wissen und Fertigkeiten[3].
� Der Autor einer Anwendung benötigt eine Möglichkeit, die verwendeten Interaktionsparadigmen
an die Anwendung und an deren Benutzerkreis anzupassen.
Wegen der geringen Eignung konventioneller Eingabemethoden bei VR Anwendungen und
wegen des hohen Maßes an Flexibilität und Komplexität, das sich mit VR Anwendungen
realisieren läßt, muß diesen beiden Forderungen bei dreidimensionalen Benutzungsschnittstellen
ganz besondere Bedeutung zugemessen werden. Dies ist das Ziel dieser
Diplomarbeit.
Seite 8

3 VR Anwendunge n
Kapitel 3, VR Anwendungen
VR Anwendungen stellen die bisher höchste Stufe der Entwicklung von Benutzungsinterfaces
dar. Dieses Kapitel gibt einen Überblick über dies Anwendungsklasse und identifiziert
wesentliche Konzepte. Abschließend wird das am Lehrstuhl entwickelte Bediensystem
MIVIS vorgestellt.
3.1 Beispiele
Die unüberschaubare Bandbreite an VR Anwendungen, die es schon heute gibt, zeigt das
enorme Potential, das hinter dieser Anwendungsdomäne steckt. VR Anwendungen können
grob in folgende Kategorien eingeteilt werden, wobei teilweise keine klaren Grenzen
zwischen den einzelnen Kategorien gelten.
• Simulation
• Datenvisualisierung
• Computergestütztes Lernen
• Telepräsenz
• Kollaboration
• Kommunikation
• Unterhaltung
• Kunst
• Augmented Reality
Im Folgenden werden einige dieser Einsatzgebiete kurz angesprochen. Viele dieser Beispiele
sind [4] entnommen.
Simulation
Es scheint naheliegend, daß mit der VR Technologie Dinge simuliert werden können, deren
Umgang in der Realität zu riskant, zu teuer oder zu aufwendig wäre. In der Medizin
werden komplizierte chirurgische Eingriffe vor der Operation an einem virtuellen Modell
des Patienten geübt. Der Arzt verwendet Nachbildungen chirurgischer Werkzeuge, die
ihm taktiles Feedback geben.
Eine Simulation des Prototyps eines Produktes mit dem Computer aus CAD Daten kann
sehr viel schneller und billiger erreicht werden, als es mit einem physikalischen Modell
möglich wäre. Zudem kann durch die Simulation der physikalischen Eigenschaften die
Funktionsweise überprüft und das Design verändert werden. So simuliert die NASA die
aerodynamischen Eigenschaften von nur im Rechner existierenden Flugzeugen in einem
virtuellen Windkanal. Während der Simulation können die Eigenschaften des Modells verändert
und deren Auswirkungen auf das Strömungsverhalten studiert werden.
Der Showroom von Matsushita ist ein virtueller Verkaufsraum, in dem der Kunde mit
einem Verkäufer aus rund 10 000 Einzelteilen eine Kücheneinrichtung zusammenstellen
kann. Diese kann er dann sofort in Originalgröße begutachten. Aber nicht nur voll immersive
Systeme mit Datenhelm und -handschuh sind für e-Commerce interessant. Durch
die rasante Entwicklung des Internets könnten Online Shops bald in der Lage sein, Produkte
dem Kunden in einer 3D Umgebung zu präsentieren.
Datenvisualisierung
Abstrakte Zusammenhänge lassen sich mit VR Systemen ebenso gut darstellen wie sich
reale Umgebungen simulieren lassen. Dem Benutzer kann sogar die Möglichkeit gegeben
werden, auf diese Zusammenhänge einzuwirken. Dabei können die Fähigkeiten des Menschen
zur Orientierung im realen Raum und das Wissen über den Umgang mit realen
Objekten auf abstrakte Zusammenhänge angewendet werden.
Die Firma infobyte hat mit „Balance Sheet City” ein System zur Darstellung der Bilanzen
eines Unternehmens entwickelt. In einer über den Wolken schwebenden Stadt repräsentiert
jedes Gebäude eine finanzielle Einheit. Die Gebäude befinden auf Plattformen, die
über Treppen verbunden sind, welche die Größe und die Art des Finanzflusses ausdrükken.
Ganz oben schweben die imposanten Gebäude des Bruttoeinkommens, welche durch
abfallende Treppen auf die deutlich niedrigeren Plattformen des Nettoeinkommens zurückgeführt
werden. Durch Betreten der Gebäude kann man Diagramme einsehen, die
über die Besonderheiten der finanziellen Einheit informieren.
Seite 9

Kapitel 3, VR Anwendungen
Nach den Vorstellungen von A.J. West et al. könnte in einem VR basierten Flugleitsystem
der Kurs eines Flugzeuges durch eine Röhre dargestellt werden, in der sich das Flugzeug
befindet. Fluglotsen könnten den Kurs eines Flugzeuges ändern, indem sie eine Röhre
greifen und verschieben.
Computer gestütztes Lernen
Die Disziplinen Simulation und Datenrepräsentation kann beim Computer gestützten Lernen
(CBT, computer based training) genutzt werden. Flugsimulationen, Simulationen der
Schiffahrt und Fahrsimulationen sind Beispiele für VR Anwendungen, die den Umgang mit
teuerem Gerät ohne Unfallrisiko trainiert werden kann. Die Darstellung von physikalischen
Feldern, mathematischen Zusammenhängen, Molekülstrukturen in der Chemie,
usw. macht diese Lernstoffe für den Lernenden greifbar. Durch die Manipulation der Objekte
werden Wirkungszusammenhänge direkt erfahrbar, die sonst nur durch abstrakte
Darstellungen vermittelt werden können. Die Firma infobyte hat ein System entwickelt, in
dem Studenten die Eigenschaften des elektromagnetischen Feldes in einer VR Umgebung
studieren können.
Kommunikation
Gerade die Möglichkeit, Computer zu vernetzen birgt ein enormes Potential für VR Anwendungen.
Menschen müssen nicht mehr zusammenkommen wenn sie sich über etwas
austauschen wollen. Sie sparen so Zeit und Geld für Flug und Unterkunft. Zudem sind
virtuelle Treffen viel spontaner organisierbar. Virtuelle Konferenzen sind die natürliche
Fortführung der Videokonferenz und der Telefonkonferenz.
Kommunikation hat auch im Unterhaltungssektor große Bedeutung. Die virtuelle Stadt
Cybertown ist das Standardbeispiel für ein Chat System im Internet, das in Form einer
verteilten VR Anwendung aufgebaut ist. Jedem Benutzer wird ein Avatar zugeordnet, mit
dem er sich in einer 3D Umgebung bewegt. Benutzer können über die Avatare Gesten
austauschen, an virtuellen Spielen teilnehmen, sich in Clubs organisieren, mit virtuellen
Gegenständen handeln, eine eigene Wohnung einrichten, und dort wie in einer konventionellen
Homepage Informationen ablegen und den persönlichen Geschmack vermitteln.
Ferner sind Möglichkeiten zum Chatten, Versenden von Kurznachrichten und Diskussionsforen
vorhanden.
Die Firma jobfair24 GmbH bietet im Internet regelmäßig Kontaktmessen für Arbeit suchende
Hochschulabsolventen an. In einer 3D Umgebung können Firmen in einer der
Messehallen einen Stand mieten und Informationen über die Firma, offene Stellen, usw.
zur Verfügung stellen. Während eines Messetermins sind Vertreter der Firmen anwesend
und können sich mit den Messebesuchern austauschen. Außerhalb dieser Termine können
Messebesucher an den Ständen digitale Bewerbungsmappen abgeben oder die von
den Firmen bereitgestellte Information abrufen. Einzelne Firmen oder Personen können
zu angekündigten Terminen Sprechstunden abhalten und Fragen beantworten. Die Anwendung
ist als Webseite konzipiert, in der in einem Fenster die Messehallen und Info
Stände als 3D Umgebung dargestellt werden. Alle Messeteilnehmer können sich dort frei
bewegen, gegenseitig sehen und Gesten austauschen. Die Grundlage bietet der Internet
Standard VRML. Er wird in Kapitel 4 vorgestellt. Die von den Firmen angebotene Information
wird in einem 2D Fenster als Hypertext (HTML) angezeigt. Die Kommunikation
der Teilnehmer findet über einen Text Chat statt.
Kollaboration
Das Anwendungsgebiet der Kollaboration faßt Elemente der Kommunikation, Simulation,
Telepräsenz und Visualisierung zusammen. Obwohl Entwickler über dem Globus verteilt
sind, können sie gemeinsam an einem Projekt arbeiten. Die Firma Ford will in dem Projekt
„Global Studio” alle ihre Designzentren über VR Systeme miteinander vernetzen.
Dies ermöglicht den gezielten Einsatz von Fachleuten und das weltumspannende Arbeiten
an einzelnen Prototypen rund um die Uhr. Die Entwicklungszeit kann so bis auf ein Drittel
zusammenschrumpfen.
Seite 10

Kapitel 3, VR Anwendungen
Telepräsenz
Die NASA arbeitet zusammen mit der russischen Raumfahrtbehörde an einem Projekt,
das ein Fahrzeug auf dem Mars fernsteuern soll. Da die Laufzeit der Funksignale zwischen
Mars und Erde etwa eine halbe Stunde beträgt, ist eine direkte Steuerung des Gefährts
über Kammeras nicht möglich. Deshalb wird das Gelände auf dem Mars von den
Scannern des Fahrzeugs erfaßt und auf der Erde in einer VR Umgebung nachgebildet. In
dieser Umgebung wird das Fahrzeug virtuell gesteuert. Die Signale, die der Fahrer dabei
an das Fahrzeug sendet, werden zum Mars übertragen, und steuern dort zeitverzögert
die Motoren des echten Gefährts....
3.2 Applikationsstrukt ur
Bei Anwendungen mit einem 3D Benutzungsinterface lassen sich drei wesentliche Bestandteile
identifizieren:
• Szene
Die Szene ist das, was der Benutzer wahrnimmt, und worauf er Einfluß nehmen
kann. Die Beschreibung der Szene definiert somit das äußere Erscheinungsbild der
Anwendung. Sie ist ein wesentlicher Bestandteil des Benutzungsinterfaces.
Sie umfaßt:
- das optische Erscheinen und die Position aller Objekte der Szene
- das akustische Erscheinen und evtl. das Erscheinen für alle anderen Sinne
- Bewegungen der Objekte (z.B. sich drehende Windmühlenflügel)
- die Art und Weise, wie Objekte vom Benutzer manipuliert werden, können
- die den Objekten innewohnende Logik. (z.B. Ein Druckknopf, der leuchtet,
wenn man ihn drückt)
- für die Objekte geltende physikalische Gesetze, sofern diese simuliert werden
Darüber hinaus legt die Szenenbeschreibung fest, auf welche Weise der Benutzer
durch die Szene navigieren kann. Dies kann unter Umständen ortsabhängig sein.
Erreicht der Benutzer z.B. einen See, paßt sich die Navigation an die Gegebenheiten
im Wasser (Schwimmen oder Tauchen) an. Kommt er in einer Stadt an einem
Kunstwerk vorbei, kann er es vielleicht von allen Seiten betrachten, insbesondere
auch von oben. Besonders große Welten könnten über ein Transportsystem
für weite Strecken verfügen, das in Form einer Landkarte realisiert ist, auf
der man eine Position auswählt und an diese dann „teleportiert” wird.
• Anwendungslogik
Die Anwendungslogik umfaßt die gesamte Logik, welche die Anwendung definiert.
Sie ordnet durch ihre Implementierung den Objekten in der Szene eine Bedeutung
zu. Wenn der Benutzer mit der Szene interagiert, löst er Ereignisse aus, auf welche
die Anwendungslogik reagiert. Hat die Anwendungslogik dem Benutzer Information
mitzuteilen, tut sie dies, indem sie die Szene modifiziert. Möglicherweise
wird hierfür eine Schnittstelle benutzt, welche die Szene aus der Sicht der Anwendungslogik
abstrahiert. Die Anwendungslogik hat Zugriff auf Betriebsmittel des
Systems, wie Dateisystem, Netzwerkverbindungen, etc.
• Präsentationseinheit
Die Präsentationseinheit interpretiert die Szenenbeschreibung und stellt sie dar.
Sie verwaltet den Zustand der Szene, der sich während der Laufzeit einer Anwendung
ständig ändern wird. Deshalb muß die Darstellung der Szene laufend aktualisiert
werden. Die Präsentationseinheit verarbeitet die Eingaben des Benutzers
und interpretiert sie entsprechend den Paradigmen Navigation und Manipulation
und gemäß den Vorgaben aus der Szenenbeschreibung, um daraus Modifikationen
an der Szene oder der Position des Benutzers abzuleiten. Dadurch ausgelöste Er-
Seite 11

Kapitel 3, VR Anwendungen
eignisse sendet die Präsentationseinheit an die Anwendungslogik. Befehle von der
Anwendungslogik, die Szene zu modifizieren werden von der Präsentationseinheit
ausgeführt.
In dieser Arbeit werden die beiden anwendungsspezifischen Teile Szene und Anwendungslogik
häufig unter dem Begriff Anwendung zusammengefaßt. Anstelle von Szene
wird mehrmals der Begriff Welt benutzt, wobei mit Szene der technische Charakter im
Sinne eines Szenengraphen (siehe Kapitel 4) betont wird und bei Welt die Wahrnehmung
des Benutzers der simulierten Umgebung im Vordergrund steht.
3.3 Interaktionsparadi gmen
Die Interaktion mit VR Anwendungen kann in drei große Interaktionsparadigmen eingeteilt
werden: Navigation, Manipulation und Kommunikation. Diese können zwar auch
schon bei graphischen Benutzungsinterfaces identifiziert werden, ihre große Bedeutung
wird aber erst in simulierten dreidimensionalen Umgebungen augenfällig, da sie dort weniger
von der Domäne der jeweiligen Anwendung abhängen.
3.3.1 Navigation
Die Sicht auf eine simulierte Welt wird hauptsächlich von der Position, an der sich ein
Betrachter virtuell befindet und von seiner Blickrichtung bestimmt. Der Benutzer sieht
meist nur einen geringen räumlichen Ausschnitt der gesamten Simulation. Navigation
kann als die Veränderung dieser Position und Blickrichtung durch den Benutzer definiert
werden. Eine mehr an den immersiven Charakter von VR Anwendungen angelehnte Definition
bezeichnet Navigation als die benutzergesteuerte Bewegung des Menschen innerhalb
der von der Anwendung simulierten Welt. Beide Definitionen sind identisch. Da Navigation
zentrales Thema dieser Arbeit ist, wird die Kombination aus Position und Blickrichtung
im folgenden Text mit dem Begriff Viewpoint bezeichnet.
Ein wichtiges Konzept bezüglich Navigation ist der Avatar. Ein Avatar repräsentiert einen
Benutzer in der virtuellen Welt. Technisch gesehen ist das ein geometrisches Objekt, das
an der Position des Benutzers in der virtuellen Welt dargestellt wird. Im Fall von Mehrbenutzersystemen
können sich so die Benutzer gegenseitig wahrnehmen und miteinander
interagieren. Aber unabhängig von der Mehrbenutzerfähigkeit einer Anwendung kann die
Darstellung eines Avatars für den eigenen Benutzer von Vorteil sein, da sie ihm so seine
virtuelle Präsenz deutlich macht und seine Relation zu anderen Objekten der Szene zeigt.
Abb. 1: Sicht auf die Szene im First Person Modus (links)
und im Third Person Modus (rechts)
Man spricht in diesem Zusammenhang von First Person Modus und Third Person Modus.
Im First Person Modus wird kein Avatar dargestellt, und der Benutzer sieht die Szene aus
Seite 12

Kapitel 3, VR Anwendungen
der Position seines Avatars. Im Third Person Modus wird auch für den lokalen Benutzer
ein Avatar dargestellt und der Benutzer sieht von ausserhalb auf diesen Avatar. Die Terminologie
stammt aus dem Szenario einer Mehrbenutzerumgebung. Aus der Sicht eines
Benutzers ist er selbst die „erste Person” und ein anderer Benutzer, mit dem er interagiert
die „zweite Person”. Im Third Person Modus sieht der Benutzer die Simulation aus
der Perspektive einer nicht vorhandenen „dritten Person”. In Abb. 1 ist die Szene
dargestellt, wie sie dem Benutzer in beiden Modi präsentiert wird.
3.3.2 Manipulation
Manipulation, wie sie hier beschrieben wird, ist keine Besonderheit von VR Anwendungen.
Auch bei graphischen Benutzungsschnittstellen treten diese Konzepte auf. Während sich
dort im Lauf der Zeit ein allgemein anerkannter Standard für Bedienelemente herauskristallisiert
hat, steht diese Entwicklung bei VR Anwendungen noch bevor.
Manipulation bedeutet, daß Objekte in der Simulation verändert werden. Diese Objekte
werden dem Benutzer präsentiert und können einen Teil der Anwendung, z.B. einen inneren
Zustand repräsentieren. Manipulierbare Objekte sind sensitiv gegenüber Benutzereingaben
und ihre Veränderung kann Vorgänge in der Anwendung auslösen oder Zustände
ändern. Die Art und Weise, wie Objekte manipuliert werden können, kann vielfältig
sein und wird von der Anwendung festgelegt. Objekte können bewegt und gedreht
werden, in der Form und Größe verändert, sie können aktiviert werden, es können andere
den Objekten innewohnenden Aktionen ausgeführt werden und so weiter. Aber vor
Allem können sie mit anderen Objekten in Beziehung gebracht werden.
Direkte Manipulation bezeichnet den Umstand, daß der Benutzer Objekte in einer Art und
Weise manipuliert, wie er es in der realen Welt mit ähnlichen Objekten auch machen
würde. Jedoch können hier leichte Abstriche in der originalgetreuen Nachbildung des
realen Vorganges gemacht werden. Zum Einen, weil die Möglichkeiten des verwendeten
Eingabegerätes begrenzt sind, und zum Anderen, weil in einer simulierten Umgebung
Manipulationsvorgänge definiert werden können, die in der realen Welt so gar nicht vorkommen.
Zum Beispiel bedeutet das Verschieben eines Objektes, daß es angefaßt werden
muß, bevor es bewegt werden kann. Wie dieses Anfassen zum Ausdruck gebracht
wird, hängt vom Eingabegerät ab. Es kann beispielsweise durch Drücken einer Taste geschehen.
Wenn ein Objekt sowohl verschiebbar als auch in der Größe änderbar sein soll,
dann müssen auf irgendeine Weise diese beiden Interaktionsformen unterschieden werden.
Beispielsweise wird in graphischen Benutzungsoberflächen diese Unterscheidung
häufig über den Ort des Anfassens getroffen: Faßt der Benutzer das Objekt am Rand an,
ändert er dessen Größe, während er das Objekt verschiebt, wenn er es an seiner Titelleiste
anfaßt.
Metaphern erhöhen die Intuitivität einer Anwendung, indem sie die abstrakten Konzepte
der Anwendung in Konzepte der dem Benutzer vertrauten Welt abbilden. Beispielsweise
wird häufig das Konzept des Freigebens von Daten zum Löschen durch ein Papierkorbsymbol
repräsentiert. Daten, die in das Symbol gelegt werden (eine weitere Metapher)
werden zur Löschung vorgemerkt. Diese Löschung wird zu einem späteren Zeitpunkt
durchgeführt. Stellt der Benutzer fest, daß er die Daten doch noch braucht, kann er sie
aus dem Papierkorbsymbol wieder herausnehmen, falls sie noch nicht gelöscht wurden.
Genauso verhält es sich mit einem realen Papierkorb. Schriftstücke, die darin abgelegt
werden, werden regelmäßig vom Reinigungspersonal der Vernichtung zugeführt. Bevor
dies passiert, kann man noch auf die Dokumente zugreifen.
Seite 13

3.3.3 Kommunikation
Kapitel 3, VR Anwendungen
Kommunikation umfaßt die Äußerungen des Benutzers, die von der Anwendung zwar
verarbeitet, jedoch nicht interpretiert werden. Dies bedeutet, daß die übermittelte Information
angezeigt, gespeichert, zu anderen Benutzern übertragen oder analysiert werden.
Es handelt sich hier um Informationsaustausch zwischen Menschen mit Hilfe der Maschine,
nicht aber zwischen Mensch und Maschine. Dieser Unterschied wird am Beispiel von
Text deutlich, der in eine Textverarbeitung eingegeben wird, und dem, der in einen Interpreter
für eine Kommandosprache eingegeben wird.
Beispiele für Äußerungen des Kommunikationsparadigma sind:
• Text, der mit einer Tastatur, über ein Spracherkennungssystem, ein Handschrifterkennungssystem
oder anderen Methoden eingegeben wird.
• Zeichnungen, die erstellt werden.
• Alle Größen der dem Menschen verfügbaren Modalitäten, die sich sensorisch erfassen
lassen. Diese können als reine Sequenz physikalischer Meßwerte vorliegen,
z.B. als Audio oder Video Signal, oder verschieden stark abstrahiert werden, z.B.
in Phoneme oder Viseme. Die Umwandlung in Text ist nur eine besondere Form
dieser Abstrahierung.
• Ein Benutzer kann in einer Mehrbenutzerumgebung seinen Avatar anweisen, bestimmte
Gesten auszuführen.
Eine allgemeine Beschreibung des Kommunikationsparadigmas erscheint wegen seiner
Vielfältigkeit wenig sinnvoll. Ausserdem ist die Verarbeitung solcher Information genau
der Zweck einer Anwendung. Möglicherweise stellt aber die Bestrebungen der Human
Markup Language Initiative[22] die eine standardisierte Beschreibung menschlicher
Kommunikation anstrebt genau eine solche Standardisierung dar.
3.4 Kategorisierung vo n Eingabegeräten
Haptische Eingabegeräte sind so unterschiedlich wie die semantisch höherwertigen Modalitäten.
Darüber hinaus lassen sich beliebige neue Eingabegeräte oder Abwandlungen
von bestehenden Eingabegeräten konstruieren. In diesem Abschnitt werden Kategorien
für Eingabegeräte identifiziert, die für deren softwaretechnische Behandlung maßgeblich
sind.
Eingabegräte bestehen aus einer physikalischen Vorrichtung, die vom Benutzer manipuliert
wird. Klassisches Beispiel sind Tastatur und Maus. Die von der Software durchgeführte
Interpretation der durch die Manipulation variierenden physikalischen Größen geschieht
in weit weniger abstrahierender Weise als dies bei semantisch höherwertigen
Sensoren der Fall ist. Aufgrund der physikalischen Vielfalt der Geräte können diese bezüglich
der Information, die sie erzeugen in die Kategorien Relative Geräte, Positionale
Geräte und Zeigegeräte eingeteilt werden. Da Eingabegeräte oft aus mehreren Bedienelementen
bestehen, gilt diese Kategorisierung genaugenommen nur für einzelne
Bedienelemente.
• Relative Geräte
Ein relatives Eingabegerät liefert Daten, die als Abweichung von einem Ruhezustand
gewertet werden. Diese Abweichung wird meist im Verhältnis zu einer maximalen
Auslenkung gemessen. Typischerweise besitzt ein solches Gerät ein Bedienelement,
das nur in einen kleinen Bereich um eine Nullage beweglich ist, und das vom Benutzer
in eine bestimmte Richtung gedrückt wird. Das Eingabegerät liefert dann die Stärke
und die Richtung der Auslenkung an den Computer. Häufig wird diese Information
in eine Geschwindigkeit des Avatars oder eines sich bewegenden Objektes umgesetzt.
Beispiele sind der Joystick, die Spacemouse und das Gaspedal in einem Fahrsimulator.
Seite 14

Kapitel 3, VR Anwendungen
Oft haben relative Eingabegeräte eine Rückholvorrichtung, die das Bedienelement
beim Loslassen in die Ausgangslage versetzt. Jedoch sind auch solche Geräte möglich,
die eine eingestellte Position halten. Schieberegler, z.B. der Trimmungsregler auf
einem Joystick sind solche haltenden Bedienelemente.
• Positionale Geräte
Ein positionales Eingabegerät mißt die Position eines Objektes. Diese Position ist nicht
notwendigerweise als Position im 3D Raum zu interpretieren, jedoch können Bewegungen
am Eingabegerät direkt in Bewegungen in der Szene übertragen werden. Dies
ist typisch für positionale Eingabegeräte. Ein Beispiel ist das in Laptops verwendete
Touchpad. Es mißt auf einer kleinen Fläche die Position einer Berührung mit dem Finger.
Wird der Finger bewegt, überträgt sich diese Bewegung auf einen Zeiger am
Bildschirm. Der von einem positionalen Gerät gemessenen Position muß nicht notwendigerweise
ein ebenes Koordinatensystem zugrunde liegen. Das auf Mäusen häufig
vorhandene Scroll-Rad mißt zum Beispiel rotatorische Bewegungen, die der Computer
in Verschiebungen eines Bildschirminhaltes übersetzt.
• Zeigegeräte
Zeigegeräte sind Eingabegeräte, die durch eine Position mit direktem Bezug zur 3D
Szene und evtl. eine Richtung repräsentiert werden. Die Position kann eine 3D Position
im Raum, aber auch eine 2D Position auf einer Ebene, z.B. der Ebene des Bildschirmes,
sein. Im Fall einer 2D Position ist eine Richtungsangabe notwendig, um
durch Test auf Schnittmengenbildung zwischen dem so aufgespannten Strahl und der
Geometrie der Szene eine Interaktion erkennen zu können. Um eine leichte Bedienbarkeit
zu erreichen, ist es zweckmäßig, die Position des Zeigegerätes mit einem Cursor
zu visualisieren. Bei manchen Zeigegeräten, insbesondere wenn sie für graphische
Benutzungsschnittstellen konzipiert sind, ist der Cursor eine kleine Grafik, die auf
dem Bildschirm eine Position markiert. Bei anderen Zeigegeräten ermöglicht ein geometrisches
Objekt innerhalb der Szene die Visualisierung einer Position. Im Fall eines
Datenhandschuhs wird häufig das Modell einer Hand als Cursor verwendet. Ein weiteres
typisches Zeigegerät für VR Anwendungen ist der Zeigestab.
Das auf Desktop-System dominante Eingabegerät ist die 2D Maus (oder Maus). Sie
wird durch einen Cursor auf dem Bildschirm repräsentiert. Bei der Projektion einer 3D
Szene auf einen 2D Bildschirm ergeben sich Projektionslinien, die alle Punkte des 3D
Raumes beschreiben, welche auf den selben Punkt in der 2D Ebene projiziert werden.
Die durch den Punkt des Maus Cursors gehende Projektionslinie definiert somit den
Strahl, der zur Interaktion mit den Objekten der Anwendung herangezogen wird.
Die Zuordnung eines Eingabegerätes zu einem dieser Typen basiert nicht allein auf der
physikalischen Ausprägung des Gerätes. Häufig kann mit Hilfe von Software ein anderer
Typ emuliert werden. Beispielsweise ist eine Maus ein positionales Gerät, aber durch die
Verknüpfung mit einem Cursor wird daraus ein Zeigegerät. Ein Datenhandschuh kann
durch die Geste des ausgestreckten Fingers zu einem Zeigegerät werden, oder durch
eine andere Geste zu einem relativen Gerät, das einen Flug durch die simulierte Welt
steuert, in dem die Orientierung der Hand die Richtung des Fluges vorgibt.
Ferner können Eingabegeräte noch danach unterschieden werden, ob sie Information an
den Benutzer zurückliefern können. Solche Feedback-Geräte können dem Benutzer intuitiv
Information geben, etwa über die Oberflächenbeschaffenheit von Objekten, oder einfach
nur, ob ein Bewegungsbereich durch ein Hindernis eingeschränkt wird. Jedoch ist die
Technik für Feedback-Geräte, die echte taktile Reize übermitteln noch nicht ausgereift
oder sehr teuer.
Seite 15

Kapitel 3, VR Anwendungen
Während manche Eingabegeräte universell eingesetzt werden können, sind andere auf
eine bestimmte Anwendungsdomäne zugeschnitten. So stellt die Nachbildung eines
Lenkrades ein relatives Eingabegerät für Fahrsimulationen dar. In der Medizin verwendet
man bei der Simulation von Operationen der minimalinvasiven Chirurgie Nachbildungen
endoskopischer Geräte[4].
Tastaturen
Tastaturen lassen sich nicht in die Kategorien relative Geräte, positionale Geräte, und
Zeigegeräte einordnen. Viel mehr müßte für Tastaturen eine eigene Kategorie der diskreten
Eingabegeräte geschaffen werden. Davon wird aber abgesehen, da im Hinblick auf
das Interaktionsparadigma Navigation in virtuellen 3D Umgebungen Tastaturen je nach
Ausprägung ein Eingabegerät der ersten drei Kategorien emulieren oder semantisch höherwertige
Kommandos auslösen.
Alphanumerische Tastaturen sind primär auf das Interaktionsparadigma Kommunikation
ausgelegt. Es sind jedoch einige Tasten vorhanden, die zur Navigation in Texten oder
anderen zweidimensionalen Objekten vorgesehen sind. Die Funktionen dieser Tasten
können in ähnliche Funktionen der Navigation in 3D Umgebungen umgesetzt werden.
Während für Pfeiltasten eine Emulation eines relativen Eingabegerätes naheliegt, entsprechen
andere Tasten eher semantisch höherwertigen Kommandos, etwa wenn die
Tasten „Bild auf” und „Bild ab” mit der Funktion „nächster” bzw. „vorheriger Aussichtspunkt”
belegt wird. Wird mit Pfeiltasten die Bewegung eines Cursors gesteuert, dann
entspricht dies einem Zeigegerät.
Für Tasten auf anderen Eingabegeräten oder auf dedizierten Tastaturen für 3D Anwendungen,
wie sie im Zusammenhang mit Spielekonsolen tatsächlich vorkommen, gilt
ebenfalls, daß diese entweder semantisch höherwertigen Kommandos zugeordnet sind,
oder einer der drei Kategorien für haptische Eingabegeräte zugeordnet sind.
3.5 Das multimodale B ediensystem MIVIS
Dieser Abschnitt stellt das am Lehrstuhl für Mensch-Maschine-Kommunikation entwikkelte
multimodale Bediensystem MIVIS vor. Genauere Information über das MIVIS System
kann in Abschnitt 8.1 und in [6][7][8][9][12] nachgelesen werden.
Am Lehrstuhl für Mensch-Maschine-Kommunikation wird im Rahmen des MIVIS-Projekts
(Multimodal Interface for Virtual Scenarios)[5] ein Bediensystem für VR Anwendungen
entwickelt, das ohne Wissen über die konkrete Anwendung zu beinhalten dem Benutzer
erlaubt, in einer virtuellen 3D Umgebung zu navigieren und diese zu manipulieren. Dabei
kann der Benutzer zur Lösung seiner Aufgaben aus mehreren Modalitäten frei wählen und
diese kombinieren. Die Darstellung der Szene erfolgt mit Hilfe der 3D Technologie
VRML (siehe Kapitel 4).
Für den Anwender ergeben sich folgende Vorteile eines multimodalen Benutzungsinterfaces:
• Die Bedienung des Systems ist an die Kommunikationsgewohnheiten des Menschen
angepaßt und dadurch intuitiver und leichter erlernbar als bei herkömmlichen
Benutzungsoberflächen.
• Die Effizienz einzelner Modalitäten hängt von der Situation im Bedienprozeß und
von den Präferenzen, den Gewohnheiten und dem Wissen des Benutzers ab. Der
Benutzer hat die Möglichkeit, bei Schwierigkeiten mit einzelnen Modalitäten auf
andere auszuweichen.
Die Kernkomponente des Bediensystems ist ein multimodaler Integrator, der sowohl redundante
als auch komplementäre als auch konkurrierende Informationen von verschiedenen
Eingabemodalitäten auswertet, um die Intention des Benutzers zu modellieren.
Die Integration der Modalitäten soll unter anderem die Robustheit multimodaler Bedien-
Seite 16

Kapitel 3, VR Anwendungen
systeme verbessern, indem Fehlentscheidungen einzelner Modalitäten durch die Ergebnisse
anderer Modalitäten kompensiert werden. Darüber hinaus verspricht man sich eine
Verbesserung der Erkennungsleistung von Eingabegeräten mit hoher Fehl-Erkennungsrate,
wenn während des Erkennungsprozesses auch Informationen von anderen Modalitäten
berücksichtigt werden.
Die Architektur des multimodalen Integrators ist generisch konzipiert, das heißt, sie ist
auch für andere Anwendungsdomänen und weitere Eingabemodalitäten verwendbar. Die
Informationen der einzelnen Modalitäten werden durch einen einheitlichen abstrakten
Formalismus beschrieben, der auf einer kontextfreien Grammatik basiert. (siehe Abschnitt
8.1.1)
Die Entwicklung und Evaluierung des multimodalen Integrators erfolgt anhand des Navigationsparadigmas,
soll aber mittelfristig auch auf das Manipulationsparadigma erweitert
werden.
Gegenwärtig werden die folgenden Modalitäten unterstützt:
• natürliche Sprache
• eine Kommandosprache
• Handgesten
• Kopfgesten
• Graphisches Benutzungsinterface
• die im Browser vorhandene Maus- und Tastaturnavigation
Die im Browser vorhandene Maus- und Tastaturnavigation ist in den multimodalen Interaktionsprozeß
nur unvollständig einbezogen. Im Rahmen dieser Arbeit wird das MIVIS
System um die vollständige Unterstützung haptischer Modalitäten, die über Maus und
Tastatur hinausgehen, erweitert.
Seite 17

4 Die VRML Techn ologie
Kapitel 4, Die VRML Technologie
Dieses Kapitel gibt einen Überblick über die VRML Technologie, mit der Internet basierte
VR Anwendungen realisiert werden können. Eine detailliertere Beschreibung von VRML ist
unter [1] zu finden.
Das Akronym VMRL steht für Virtual Reality Modeling Language und bringt zum Ausdruck,
daß VRML eine Sprache ist, mit der die in einer VR Anwendung dargestellte Szene
beschrieben werden kann. Hinter VRML verbirgt sich aber auch eine Technologie, welche
diese Szene darstellen kann und dem Benutzer erlaubt, mit dieser Szene zu interagieren.
Zu dieser Technologie gehört auch eine Möglichkeit, externe Module anzubinden, welche
die Anwendungslogik enthalten. Um Mehrdeutigkeiten zu vermeiden, werden in dieser
Arbeit die Ausdrücke „die Sprache VRML” und „die Technologie VRML” verwendet.
VRML wurde als offener Standard für den Gebrauch im Internet konzipiert. Daher kann
ein Browser, der VRML Welten darstellt, diese über das Internet laden und Teile davon
nachladen. VRML greift auf andere im Internet etablierte Technologien wie HTML, HTTP,
Java, JavaScript, JPG, PNG, URN, usw. zurück. VRML Welten können so auch verlinkt
werden, d.h. Es kann ähnlich einem Hypertext Dokument von einer VRML Welt in eine
andere gesprungen werden.
VRML ist ein von der International Standardization Organization (ISO)[2] unter der
Nummer 14772 definierter Standard. Dieser Standard befindet sich (zur Zeit, als diese
Arbeit entsteht) in der Weiterentwicklung. Der direkte Nachfolgestandard heißt X3D.
MPEG4 ist ein Standard, der den Sprachschatz von VRML beinhaltet. X3D basiert auf der
Sprache XML 1 , und macht starken Gebrauch von Profilen. Ein Profil ist ein definierter Teil
des gesamten Funktionsumfanges von X3D, den ein dem Profil genügender Browser unterstützen
muß. MPEG4 ist ein Standard für interaktive, gestreamte 2 2D und 3D Multimedia
Inhalte. Er verwendet zur Beschreibung der dargestellten Szene eine binäre Repräsentation
einer Obermenge von VRML.
4.1 Sprachmodell
Die Sprache VRML ist eine deklarative Sprache, die auf einem Szenengraphen beruht und
Ereignisse zwischen den Knoten austauschen kann. Sie wird als UTF8 Text notiert. Für
imperatives Anwendungsverhalten kann Script Code eingebettet oder externe Anwendungslogik
angebunden werden. Es existiert ein Mechanismus, mit dem der Sprachumfang
erweitert werden kann.
Hierarchische Knotenstruktur
3D Inhalte werden in VRML in einem Graphen, der Szenengraph genannt wird, dargestellt.
Konzeptionell besteht der Szenengraph aus einem oder mehreren nicht zusammenhängenden
Bäumen. Gemäß dieser Baumstruktur werden Knoten als Vater oder Kind
Knoten bezeichnet. Durch ein spezielles Konstrukt können Teilbäume an mehr als einer
Stelle verwendet werden, so daß der Szenengraph im Allgemeinen ein gerichteter, zyklenfreier
Graph ist. Die Knoten des Graphen beschreiben das optische Aussehen von
Objekten, deren geometrische Form, akkustische Signale oder das Verhalten von Objekten.
1 XML ist eine Sprache zur Darstellung strukturierter Information in für Menschen lesbarer Form.
2 "streamen“ bedeutet, daß die Übertragung der Inhalte während der Präsentation stattfindet, und
weniger Wert auf die Übertragung aller Datenpakete als auf deren rechtzeitigen Übertragung legt.
Seite 18

Kapitel 4, Die VRML Technologie
Neben der Darstellung von allgemeinen Beziehungen zwischen Knoten dient der Szenengraph
dazu, eine Transformationshierarchie aufzubauen. Für jeden Knoten existiert ein
Koordinatensystem, in dem der Knoten beschrieben wird. Dieses wird das lokale Koordinatensystem
des Knotens genannt, und wird von dem in der Hierarchie des Szenengraphen
übergeordneten Knoten geerbt. Einige Knoten modifizieren das geerbte Koordinatensystem
und vererben dieses weiter. Sie beschreiben dadurch Koordinatentransformationen.
Dadurch können Objekte unabhängig von ihrer Verwendung modelliert und zu
größeren Objekten kombiniert werden. Die Bewegung von Objekten findet als zeitabhängige
Änderung dieser Koordinatentransformationen statt.
Deklarative Beschreibung der Knoten
Jeder Knoten besitzt Felder, die Eigenschaften des Knotens beschreiben, auf andere
Knoten verweisen und so den Szenengraphen aufbauen, oder Information mit anderen
Knoten austauschen. Für Felder existiert ein Typsystem, das neben Standardtypen wie
Integer, 3D Vektoren, oder Farbwerten Referenzen auf andere Knoten umfaßt. Fast jeder
Typ existiert in einer einfachen und einer Array Version. Die Array Version enthält ein
Array von Werten des einfachen Typs.
Einige ausgewählte Typen:
SFFloat Fließkomma-Zahl mit einfacher Genauigkeit
SFInt32 Integerzahl mit 32 Bit
SFVec3f drei Fließkomma-Zahl, die einen dreidimensionalen Vektor repräsentieren
SFRotation vier Fließkomma-Zahl, die eine Drehung als Richtungsvektor einer Drehachse
und einen Drehwinkel beschreiben
SFColor drei Fließkomma-Zahl zwischen 0 und 1, die einen Farbwert spezifizieren
SFNode eine Referenz auf einen anderen Knoten, oder NULL, um auf keinen Knoten
zu zeigen.
SFBool ein boolscher Wert. entweder TRUE oder FALSE
SFString ein in Anführungszeichen " eingeschlossener String.
Die Namen dieser Typen beginnen mit SF, da sie nur einen Wert enthalten. Die Array
Typen sind davon abgeleitet und beginnen mit MF: MFFloat, MFInt32, MFVec3f, ...
Ereignisbasierter Informationsaustausch
Neben dem Szenengraphen existiert ein zweiter, gerichteter Graph, der Routengraph. Er
verbindet die Felder der Knoten, so daß Information zwischen den Knoten ausgetauscht
werden können. Der Routengraph ist mit einem Signalflußgraphen vergleichbar. Eine
Kante des Routengraphen wird Route genannt. Sie verbindet jeweils zwei Felder gleichen
Typs und definiert eine Übertragungsrichtung für die über die Route übertragenen Ereignisse.
Felder können in vier Arten vorkommen:
field: Sein Wert ist in der Szenenbeschreibung fest vorgegeben und kann während
der Ausführung der Anwendung nicht verändert werden.
eventOut: Es sendet im Knoten auftretende Ereignisse über eine oder mehrere Routen.
eventIn: Es kann Ereignisse über eine oder mehrere Routen empfangen und ändert so
seinen Wert.
exposedField: Vereinigt field, eventOut und eventIn. Es kann dadurch einen, in der
Szenenbeschreibung festgelegten Anfangswert besitzen und sowohl als
eventOut als auch als eventIn benutzt werden, wodurch es seinen Wert ändern
kann.
Eine Route verbindet immer ein eventOut mit einem eventIn, wobei beide durch ein
exposedField ersetzt sein können. Tritt in einem Knoten ein Ereignis auf, so drückt sich
das durch einen Wert aus, der an einem eventOut angezeigt wird. Ist an das eventOut
Seite 19

Kapitel 4, Die VRML Technologie
eine Route angeschlossen, überträgt sie den Wert an das eventIn eines anderen Knoten.
Dieser ändert dadurch seinen Zustand, wodurch auch in diesem Knoten ein Ereignis entstehen
kann. Wird dieses Ereignis über weitere Routen übertragen, entsteht eine Event
Kaskade. Neben dem Ändern interner Zustände kann das Empfangen von Ereignissen
Änderungen am Szenengraphen bewirken.
Reaktion auf äußere Einflüsse
Sogenannte Sensor Knoten stehen am Anfang einer Event Kaskade. Sie reagieren auf
äußere Einflüsse wie Benutzereingaben, das Verstreichen von Zeit, oder die Bewegung
des Benutzers in der dargestellten Welt und erzeugen daraus Ereignisse.
Anwendungsspezifisches Verhalten
Anwendungsspezifisches Verhalten wird mit dem Script Knoten beschrieben. Dies ist ein
Knoten, dessen Felder anders als bei anderen Knoten nicht fest vorgegeben sind, sondern
vom Autor definiert werden können. Über ein Feld namens url vom Typ MFString
kann dem Script Knoten imperativer Code zugeordnet werden. Dieser reagiert auf Ereignisse
an eventIn Feldern und kann Ereignisse an eventOut Feldern senden. Als Script
Sprache wird typischerweise JavaScript und Java verwendet, es können aber vom Browser
beliebige andere Sprachen unterstützt werden. Dialekte von JavaScript sind EcmaScript
oder VrmlScript.
Als Alternative zu Script Knoten steht für komplexere Anwendungslogik eine Programmierschnittstelle
für externe Programme zur Verfügung, das External Authoring Interface
(EAI). Damit können Anwendungen einen VRML Browser laden und als Modul zur Darstellung
von 3D Inhalten benutzen. Über das EAI kann die Anwendung auf den Szenengraphen
zugreifen, und Ereignisse an Knoten senden.
Generik durch PROTO Mechanismus
VRML Code kann modularisiert aufgebaut werden. Das PROTO Statement erlaubt es, einen
neuen Knotentyp mit eigenen Feldern zu definieren. Es besteht aus zwei Teilen: Der Deklarationsteil
definiert die Felder, die der neue Knotentyp besitzen soll. Dazu wird für
jedes Feld die Art des Feldes, der Datentyp Der Implementierungsteil enthält einen Szenengraphen,
der die Funktion des neuen Knoten beschreibt. Mit dem IS Statement wird
eine Beziehung zwischen Feldern aus dem Szenengraphen und den Feldern im Deklarationsteil
hergestellt. Nach dem PROTO Statement kann der neue Knoten – man spricht hier
von einem Proto – auf die gleiche Weise wie alle anderen Knoten verwendet werden.
Dieser Vorgang wird Instantiierung des Protos genannt.
Soll der Proto in einer anderen Datei verwendet werden, als in derjenigen, in der er definiert
ist, muß die verwendende Datei ein EXTERNPROTO Statement enthalten. Dieses enthält
genauso wie das PROTO Statement einen Deklarationsteil und einen Implementierungsteil,
nur daß der Implementierungsteil auf die Datei mit der Definition des Protos
verweist. Dadurch, daß das EXTERNPROTO Statement die Beschreibung aller Felder des
Knotens wiederholt, wird der Unzuverlässigkeit des Internets Rechnung getragen: Kann
die Proto Definition nicht aus der definierenden Datei geladen werden, kann die verwendende
Datei trotzdem geparst und angezeigt werden.
Knoten mit globalem Charakter
Einige Knoten beschreiben globale Eigenschaften, welche die gesamte dargestellte Szene
betreffen. Zum Beispiel beschreibt der Viewpoint Knoten die Perspektive, aus der die
simulierte Welt dargestellt wird, oder der Background Knoten legt fest, welche Farben
hinter allen Objekten dargestellt werden.
Da VRML eine modularisierbare Sprache ist, und diese globalen Eigenschaften an unterschiedlichen
Orten in der Welt unterschiedlich sein können, existiert ein Mechanismus,
Seite 20

Kapitel 4, Die VRML Technologie
der in jedem Moment einen dieser Knoten auswählt und aktiviert: Für jeden dieser Knoten
wird ein Stack angelegt, und der oberste Knoten des Stacks ist aktiv. Mit Hilfe des
Routengraphen kann ein Knoten auf den Stack gelegt und dadurch aktiviert werden, z.B.
wenn der Benutzer einen bestimmten Bereich betritt. Diesen Vorgang nennt man das
Binden eines Knotens. Auf die gleiche Weise kann ein Knoten vom Stack genommen werden,
wodurch er deaktiviert wird. Es wird dann der als nächstes auf dem Stack liegende
Knoten aktiv. Das ist in der Regel derjenige, der vorher gebunden war.
Beispiel: Szenengraph und Routengraph
VRML Darstellung:
Transform
{
translation 3.4 1.3 0.0
rotation 0.0 0.6 0.4 1.57
scale 1.0 0.1 0.5
children Shape
{
appearance DEF Movie MovieTexture
{
url "http://www.server.de/directory/movie.mpg"
}
geometry Sphere
{
radius 1.45
}
}
}
Hier wird mit dem Transform Knoten ein lokales Koordinatensystem aufgespannt. Die
Felder translation, rotation und scale geben als Vektoren bzw. Rotationswert die Verschiebung,
Drehung und Skalierung des Koordinatensystems für Kindknoten an. Das Feld
children beinhaltet eine Referenz auf Knoten. Ihm wird ein Shape Knoten zugeordnet,
der ein sichtbares Objekt beschreibt. Shape enthält zwei Felder, die Referenzen auf einen
Knoten enthalten, der das Aussehen des Objektes beschreibt, und einen Knoten, der die
geometrische Form beschreibt. Dem appearance Feld ist ein MovieTexture Knoten zugeordnet
– hier wurde gegenüber realem VRML etwas vereinfacht – der festlegt, daß auf die
Oberfläche des Objektes ein MPEG Video projiziert werden soll. Mit dem Statement DEF
Movie wird diesem Knoten der Name Movie zur späteren Referenzierung zugeordnet. Die
Form des Objekts wird mit dem geometry Feld als Kugel festgelegt. Durch das Koordinatensystem
des umgebenden Transform Knoten wird diese Kugel zu einem aus dem Ursprung
verschobenen und gedrehten Elipsoid verformt.
Diese Struktur ist auf der rechten Seite von Abb. 2 als Szenengraph dargestellt.
Seite 21

TouchSensor
Script
touchTime
touched
url "
var state;
function touched(t)
{
if(state)
startMovie= t;
else
stopMovie= t;
state= !state;
}
"
startMovie
stopMovie
Transform
Kapitel 4, Die VRML Technologie
translation 3.4 1.3 0.0
rotation 0.0 0.6 0.4 1.57
scale 1.0 0.1 0.5
children
Shape
appearance geometry
MovieTexture
url "http://x.mpg"
startTime
stopTime
Sphere
radius 1.45
Abb. 2: Szenengraph (schwarz) und Routengraph (rot) in
VRML
Soll das Video durch den Benutzer angehalten und fortgesetzt werden können („Pause”
Funktion) , muß ein TouchSensor Knoten in die Szene eingefügt werden. Dieser ist mit
dem oben beschriebenen oder einem anderen Objekt verknüpft und signalisiert an seinen
Ausgangsfeldern, wenn der Benutzer mit der Maus – oder anderem Zeigegerät – auf das
Objekt klickt. Diese Ereignisse werden mit ROUTE Statements an einen Script Knoten
gesendet, der daraus entsprechende start und stop Ereignis generiert.
... DEF Toucher TouchSensor {} ...
DEF Worker Script
{
eventIn SFTime touched
eventOut SFTime startMovie
eventOut SFTime stopMovie
url "vrmlscript:
}
"
var state= false;
function touched(t)
{
if(state)
startMovie= t;
else
stopMovie= t;
}
state= !state;
ROUTE Toucher.touchTime TO Worker.touched
ROUTE Worker.startMovie TO Movie.startTime
ROUTE Worker.stopMovie TO Movie.stopTime
Dieser Code ist in Abb. 2 auf der linken Seite dargestellt.
Seite 22

4.2 Ausführungsmode ll
Kapitel 4, Die VRML Technologie
Der VRML Standard beschreibt zum Einen eine Sprache, mit der sich VR Anwendungen
modellieren lassen, und umfaßt zum Anderen eine Architektur, die diese ausführt. Letztere
wird in diesem Abschnitt kurz umrissen.
Ähnlich wie bei der 2D Technologie HTML werden auch bei VRML 3D Inhalte typischerweise
auf einem Server im Internet abgelegt und es existieren als „Browser” bezeichnete
Programme, die diese Inhalte über das WWW laden und dem Benutzer präsentieren.
Browser werden von unabhängigen Firmen oder Personen entwickelt. Gemäß der in Abschnitt
3.2 getroffenen Kategorisierung sind diese Browser der Präsentationseinheit zuzuordnen,
da sie die anwendungsunabhängige Logik enthalten. Die Szene wird durch die
auf dem Server vorhandene Szenenbeschreibung in VRML Dateien und davon referenzierten
Texturen, Audio und Videodateien definiert. Browser besitzen eine Programmierschnittstelle
für externe Module. Diese Programmierschnittstelle wird EAI (External
Authoring Interface) genannt und erlaubt den externen Modulen, die Szene zu verändern,
oder auf Ereignisse zu reagieren, die in der Szene auftreten. Diese Module stellen
somit die Applikationslogik dar. Auf Webseiten werden dafür häufig Java Applets verwendet,
da diese wie die Szenenbeschreibung heruntergeladen werden können. Abb. 3 verdeutlicht
dieses Schema.
VRML Datei
Java Applet
Applikationslogik
E A I
Browser
Parser
• eingebaute
Knoten
Szenengraph
• PROTOs
Audiovisuelle
Präsentation
Benutzer
Navigation
• WALK
• FLY
• EXAMINE
Simulationseinheit
• Sensoren
aktualisieren
• Routen
aktualisieren
• Scripts
ausführen
Abb. 3: Ausführungsmodell von VRML
Die bekanntesten Browser sind der „Cosmo Player”, „Cortona” und „blaxxun Contact”.
Alle drei Browser sind als Freeware verfügbar. Der Cosmo Player wurde von der Firma
SGI[27] zu der Zeit, als VRML standardisiert wurde, entwickelt, und gilt als der zum
Standard am meisten konforme Browser. Er läuft sowohl auf der Windows Plattform, als
auch auf Mac und UNIX Derivaten. SGI hat die Entwicklung dieses Browsers eingestellt,
Seite 23

Kapitel 4, Die VRML Technologie
aber kürzlich wurden der Quellcode von der Firma Nexternet[29] aufgekauft, so daß der
Browser unter dem Namen „Pivoron” weiterentwickelt wird. Cortona ist der Browser der
englischen Firma Parallel Graphics[28]. Er ist auf Mac und Windows verfügbar. Der Browser
verfügt über Erweiterungen gegenüber dem VRML Standard und implementiert zusätzlich
zu EAI eine vom Standard abweichende Schnittstelle für externe Programmodule.
Blaxxun Contact wird von der Firma blaxxun interactive[23] entwickelt. Zusätzlich zu der
Funktion als VRML Browser dient er als Multimedia Client für die Kommunikationsplattformen
der Firma. Der Browser ist auf der Windows Plattform ausführbar und unterstützt
gegenüber dem VRML Standard einige Erweiterungen für fortgeschrittene Darstellungstechniken.
Er implementiert die Programmierschnittstelle EAI in Form von Aufrufen der
Komponententechnologie COM[32]. Im Rahmen dieser Diplomarbeit wird dieser Browser
um Knoten für anpassbare Navigation erweitert.
Neben diesen Browsern existieren noch weitere, z.B. Blendo von Sony[31], der im Source
Code verfügbare FreeWRL[26], oder Java Applets, die VRML Inhalte auf Webseiten darstellen,
ohne auf dem Clientrechner installiert werden zu müssen. Dafür bieten diese einen
weit geringeren Funktionsumfang.
4.3 Konzept für Benutz erinteraktion
In VRML existieren Konzepte für die beiden Interaktionsparadigmen Navigation und Manipulation.
Für das Paradigma der Kommunikation wird auf bestehende externe Technologien
verwiesen. So kann auf einer Web Seite ein Java Applet die Eingabe von Texten
übernehmen.
4.3.1 Manipulation
Das Manipulation Paradigma wird in VRML durch eine Reihe von Sensor Knoten abgedeckt.
Ein Sensor Knoten wird mit einem Objekt der Szene verknüpft, und erfaßt Benutzereingaben,
die an dieses Objekt gerichtet sind. Es gibt die Gruppe der Geometrie Sensoren,
den TouchSensor und den Anchor. Alle Sensoren sind auf die Benutzung mit einem
Zeigegerät ausgelegt, das auf Objekte de Szene zeigen kann. Die Geometrie Sensoren
erfassen Benutzereingaben, die das verknüpfte Objekt bewegen und geben diese in Form
von variierenden Koordinaten an die Szene weiter, die diese meist einem Transform
Knoten zuweist, wodurch das Objekt erst beweglich wird.
Es existieren folgende Geometrie Sensoren:
• CylinderSensor
• PlaneSensor
• SphereSensor
Der CylinderSensor überträgt Bewegungen des Eingabegerätes auf die Rotation um eine
vorgegebene Achse und ist somit ein Sensor, der eindimensionale Bewegungen erzeugt.
Der PlaneSensor wandelt erzeugt Bewegungen in einer Ebene, und ist somit ein zweidimensionaler
Sensor. Er kann durch Einschränken einer Achse zu einem eindimensionalen,
linearen Sensor gemacht werden. Mit dem SphereSensor lassen sich Rotationen um einen
Punkt erfassen. Es besteht keine Einschränkung bezüglich der Achsen, um welche die
Drehung ausgeführt werden kann, so daß der SphereSensor als dreidimensionaler Sensor
Knoten gewertet werden kann. Alle drei Sensor Knoten sind für die Benutzung mit einem
Zeigegerät ausgelegt, da sie erst durch Zeigen auf Objekte, die mit einem Sensor Knoten
verknüpft sind, aktiviert werden. Sollen Bewegungen in mehr als den durch die Sensor
Knoten unterstützten Freiheitsgraden möglich sein, müssen diese kombiniert werden. Es
muß ein Mechanismus geschaffen werden, der festlegt, wann welcher der Sensoren aktiv
wird. Selbst wenn ein dreidimensionales Zeigegerät verfügbar ist, können Bewegungen in
nur zwei lineare Freiheitsgrade gleichzeitig erlaubt sein, da zu einem gegebenen Zeitpunkt
immer nur ein Sensor knoten aktiv sein kann.
Seite 24

Kapitel 4, Die VRML Technologie
Der TouchSensor hat die primäre Aufgabe, ein binäres Signal auszulösen, ähnlich einem
Schalter, den man aktivieren kann. Wird das Zeigegerät aktiviert, während es auf das
dem TouchSensor zugeordnete Objekt zeigt, sendet der TouchSensor ein entsprechendes
Signal an die Szene. Zudem „fühlt” dieser Sensor Knoten das Zeigen auf sein zugeordnetes
Objekt auch dann, wenn das Zeigegerät nicht aktiviert wird. Diese Information wird
in Form von 3D Koordinaten, die einen Punkt auf der Oberfläche des Objektes beschreiben,
an die Szene weitergegeben. Ein boolsches Feld isOver zeigt an, wann das Zeigegerät
auf das Objekt ausgerichtet ist.
Der Anchor Knoten führt keine neue Interaktionsmöglichkeit ein. Er ist vielmehr ein
Komfortknoten, der die Schalter Funktionalität des TouchSensor Knotens mit der Möglichkeit,
einen Hyperlink im WWW aufzurufen, oder einen Aussichtspunkt anzuspringen, verbindet.
Ferner existieren Sensoren, die durch die Navigation des Benutzers durch die virtuelle
Welt ausgelöst werden. Der Collision Knoten stellt fest, wenn der Avatar mit Objekten
der Szene kollidiert. Es kann dabei angegeben werden, welche Objekte sensitive gegenüber
Kollisionen sind. Mit dem ProximitySensor kann die Position und die Orientierung
des Avatars festgestellt werden. Das Gebiet, in dem sich der Avatar befinden muß, damit
der ProximitySensor diese Information liefert, kann angegeben werden. Zudem zeigt der
ProximitySensor an, wann der Avatar in diesen Bereich eintritt, oder ihn verläßt. Der
VisibilitySensor zeigt zwar an, wann ein Objekt sichtbar ist, jedoch ist die Definition
dieses Knoten so geschaffen, daß er nur für Optimierungsaufgaben benutzt werden kann,
nicht aber zur Interaktion. Denn der VisibilitySensor muß nur verläßlich angeben,
wann ein Objekt sichtbar ist. Ist das Objekt nicht sichtbar, darf der Sensor trotzdem
Sichtbarkeit anzeigen, so daß Browser eine effiziente Implementierung benutzen können.
4.3.2 Navigation
Der VRML Standard macht keine Angaben über die konkrete Ausgestaltung des Interaktionsparadigmas
Navigation. Dadurch wird dem Browser große Freiheit gegeben, diese
möglichst komfortabel für den Benutzer zu gestalten. Leider läßt sich dadurch die Navigation
von der Szenenbeschreibung aus nicht an die Bedürfnisse einer Anwendung anpassen.
Dafür sind die vorhandenen Sprachkonstrukte sehr gut durchdacht und legen die Rahmenbedingungen
für die Navigation fest. Neben der Möglichkeit zur Beschränkung der
Bewegungsfreiheit durch unsichtbare Geometrie stehen im wesentlichen zwei Knoten zur
Verfügung: Der Viewpoint Knoten erlaubt es, den Benutzer an feststehende oder variable
Positionen zu transportieren und das Koordinatensystem festzulegen, bezüglich dessen
Navigation stattfindet. Der NavigationInfo Knoten erlaubt die Angabe von Eckdaten für
die Navigation.
Der Viewpoint Knoten zeichnet ein Koordinatensystem als dasjenige aus, bezüglich dessen
der Browser die Navigation durchführt. In diesem Abschnitt wird dieses Koordinatensystem
kurz Navigationskoordinatensystem genannt. Das Navigationskoordinatensystem
ist das Koordinatensystem, in dem sich der momentan gebundene Viewpoint aufgrund
seiner Position im Szenengraphen befindet. Von diesem Koordinatensystem sind zwei
Größen wichtig: Die Richtung der negativen y-Achse definiert die Richtung, entlang der
Gravitation simuliert wird, und die Skalierung des Koordinatensystems definiert einen
Maßstab für die Bewegungsgeschwindigkeit des Avatars. Dadurch können Welten erzeugt
werden, bei denen „Unten” nicht überall gleich ist, etwa auf einer Raumstation oder auf
Asteroiden. Durch die Manipulation des Maßstabes des Navigationskoordinatensystems
kann die Navigation den Größenverhältnissen in der Welt angepaßt werden. Wird dieser
Maßstab dynamisch geändert, können interessante Effekte erzeugt werden, wie etwa ein
Seite 25

Kapitel 4, Die VRML Technologie
Puppenhaus, in dem man sich als verkleinerter Avatar mit entsprechend kleinen Geschwindigkeiten
bewegen kann, während man sich entsprechend schneller bewegt, wenn
man sich außerhalb des Puppenhauses befindet.
In Abschnitt 5.1.2 werden Koordinatensysteme definiert, bezüglich derer Navigation beschrieben
werden kann. Das dort ‚Welt lokales Koordinatensystem’ genannte Koordinatensystem
ist mit dem durch den Viewpoint Knoten definierte Navigationskoordinatensystem
identisch.
Durch zwei Felder am Viewpoint Knoten können Position und Blickrichtung relativ zum
Navigationskoordinatensystem angegeben werden, so daß der Benutzer an bestimmte
Positionen „teleportiert” werden kann. Durch Animation dieser Felder kann der Avatar
auch auf festgelegten Bahnen durch die Welt transportiert werden. Wird das Navigationskoordinatensystem
animiert, bleibt es dem Benutzer frei, sich relativ zu diesem Koordinatensystem
zu bewegen. So können Effekte geschaffen werden wie etwa ein schwimmendes
Floß, auf dem sich der Benutzer frei bewegen kann, wobei er sich gleichzeitig mit
dem Floß mit bewegt.
Einem Browser ist es frei gestellt, eine Liste aller verfügbaren Viewpoints anzuzeigen und
den Benutzer daraus wählen zu lassen. Es besteht auch die Möglichkeit, Tasten mit den
Funktionen vorheriger/nächster/erster Viewpoint zu belegen. Diese Funktion wird mit
einem Feld, das dem Viewpoint einen beschreibenden Text zuordnet unterstützt.
Mit den Sensor Knoten für Manipulation, insbesondere dem TouchSensor hat der Autor die
Möglichkeit, dem Benutzer über ein Head Up Display 3 ein Interface anzubieten, über das
der Benutzer Positionen – auch dynamisch berechnete – anspringen kann. Ebenso kann
er eine Teleportierstation 4 einrichten. Diese Möglichkeiten sind jedoch sehr begrenzt. Eine
genaue Analyse wird Abschnitt 5.2.2 im Zusammenhang mit einem Lösungsansatz gegeben.
Der NavigationInfo Knoten bietet dem Autor die Möglichkeit, einige Eckdaten zur Navigation
festzulegen: die Avatargröße, die nominelle Navigationsgeschwindigkeit und den
Navigationsmodus. In der Avatargröße sind die Abmessungen enthalten, die der Browser
bei der Kollisionserkennung für den virtuellen Benutzer annehmen soll. Neben der Höhe
und Breite wird hier eine Höhe festgelegt, ab der Objekte ein Hindernis darstellen – eine
Stufe soll überwindbar sein, aber ein Tisch z.B. nicht mehr. Die nominelle Navigationsgeschwindigkeit
ist die, die der Browser als Standardgeschwindigkeit verwenden soll. Der
Benutzer bringt also zum Ausdruck, ob er sich schneller oder langsamer als diese fortbewegen
will. Die Avatargröße und nominelle Navigationsgeschwindigkeit werden relativ
zum Navigationskoordinatensystem interpretiert.
Als Navigationsmodus legt der VRML Standard die Randbedingungen für die drei Modi
WALK, FLY und EXAMINE fest. Im WALK Modus kann eine Welt zu Fuß oder in einem
Fahrzeug durchwandert werden. Der Browser sollte nach Möglichkeit Maßnahmen ergreifen,
die bewirken, daß der Avatar auf dem (virtuellen) Boden bleibt. Der FLY Modus ist
dem WALK Modus ähnlich, jedoch versucht der Browser nicht, den Avatar auf dem Boden
zu halten. Zweck des EXAMINE Modus ist es, Objekte zu betrachten. Typische Bewegungsarten
sind das sich Drehen um das Objekt und das Heranholen oder Wegschieben
des Objekts.
3
Ein Head Up Display (HUD) ist Geometrie, die immer so positioniert wird, daß der Benutzer sie jederzeit
im Blickfeld hat.
4
Eine Teleportierstation ist ein Interaktionsobjekt, an dem der Benutzer einen Ort auswählen kann, an
den er anschließend transportiert wird.
Seite 26

Kapitel 4, Die VRML Technologie
Die konkrete Ausgestaltung der Navigationsmodi, und damit die Komplexität und Komfortabilität
der Navigation bleibt dem Browser Programmierer überlassen, ohne daß der
Autor darauf Einfluß nehmen könnte. Der Browser Programmierer hat allerdings die Möglichkeit,
über die drei Standard Modi hinausgehende eigene Modi zu implementieren. Der
Autor kann angeben, welche Navigationsmodi er in seiner Anwendung erlauben will, und
welcher der als erstes aktive sein soll.
Durch Setzen der nominellen Navigationsgeschwindigkeit auf den Wert 0 kann ein Navigationsmodus
auf rein rotatorische Bewegungen eingeschränkt werden, so daß sich der
Benutzer zwar umsehen, aber nicht fortbewegen kann.
Seite 27

5 Anpassbare Nav igation
Kapitel 5, Anpassbare Navigation
In Abschnitt 2.3 wurden die beiden grundlegenden Forderungen an ein Benutzungsinterface,
nach der Möglichkeit zur multimodalen Interaktion und nach der Möglichkeit zur
Anpassung der Interaktionsparadigmen an die Anwendungsdomäne und deren Benutzerkreis
herausgearbeitet. Die durch das Internet weite Verbreitung findende Technologie
für Anwendungen mit 3D Benutzungsinterface VRML erfüllt in der Standardform keine
dieser beiden Anforderungen. Ziel dieser Arbeit ist es daher, speziell für das Interaktionsparadigma
Navigation:
1) eine Erweiterung des Sprachumfanges von VRML zu erarbeiten, die einem Autor die
Anpassung des Navigationsparadigmas sowohl an die Anwendung als auch an deren
Benutzerkreis erlaubt, sowie
2) eine Systemarchitektur zu entwickeln, die einen VRML Browser so erweitert, daß der
Benutzer mehrere Modalitäten zur Navigation verwenden kann, und dabei aus diesen
frei wählen und sie frei kombinieren kann.
In diesem Kapitel werden grundlegende Voraussetzungen erarbeitet, die zum Erreichen
beider Ziele notwendig sind. Nach der Schaffung einer mathematischen Basis zur Beschreibung
von Navigationskonzepten und einer Analyse der Schwächen von VRML bezüglich
anpassbarer Navigation wird ein Konzept entwickelt, das den Sprachumfang von
VRML gemäß dem ersten Ziel dieser Diplomarbeit erweitert. Dieses Konzept wird in den
nächsten beiden Kapiteln umgesetzt: Das Kapitel 6 diskutiert ein Sprachkonstrukt, das
die Modellierung von beliebigen Eingabegeräten in VRML ermöglicht. Kapitel 7 entwickelt
Sprachkonstrukte, mit denen die Bewegungen des Avatars kontrolliert werden können.
Am Lehrstuhl für Mensch-Maschine-Kommunikation der TU München wurde bereits ein
System für multimodale Interaktion in 3D Umgebungen mit semantisch höherwertigen
Modalitäten entwickelt. Dieses wird im zweiten Teil dieser Arbeit um haptische Modalitäten
erweitert. Dazu wird die Infrastruktur ausgedehnt, durch die haptischen Modalitäten
möglich werdende Funktion werden eingeführt, und die Kommunikation zwischen den
Systemkomponenten wird intensiviert. Die zur Validierung des Systemkonzepts erstellte
Testimplementierung erfolgt unter Verwendung der im ersten Teil erarbeiteten Sprachkonstrukte
und validiert somit auch diese. Kapitel 8 beschreibt nach einer Diskussion der
zugrundeliegenden Designentscheidung die Erweiterung dieses Bediensystems um haptische
Modalitäten.
5.1 Zugrundeliegende F ormalismen
Das Konzept der Navigation in virtuellen Welten beinhaltet, daß sich der Benutzer frei in
der Welt bewegen kann, sich an bestimmte Orte begeben und seine Blickrichtung wählen
kann. Das kann einerseits dadurch geschehen, daß er fortlaufend eine Geschwindigkeit
und eine Richtung vorgibt, in die er sich bewegen oder drehen will. Im Folgenden wird
diese Art der Bewegung kontinuierliche Navigation genannt. Eine Abwandlung davon ist
die diskrete Navigation, bei welcher der Benutzer Befehle absetzt, die ihn jeweils um
einen Schritt in eine bestimmte Richtung weiterbewegen. Die Schrittweite ist ein Größe,
auf die der Benutzer Einfluß nehmen können soll. Andererseits kann Navigation dadurch
erreicht werden, daß der Benutzer einen Punkt vorgibt, auf den er sich zu bewegen oder
in dessen Richtung er blicken will. In diesem Fall sei von referenzierender Navigation die
Rede. Ergänzend dazu besteht die Möglichkeit, daß der Designer einer 3D Anwendung
bestimmte Positionen als charakteristisch markiert, und der Benutzer diese aus einer
Liste auswählt.
Seite 28

5.1.1 Bewegungsarten
Kapitel 5, Anpassbare Navigation
Bei kontinuierlicher Navigation reichen die drei Modi WALK, FLY und EXAMINE aus, um
Navigation grob zu beschreiben. Die folgende Definition ist der VRML Spezifikation [1]
angelehnt.
• WALK
Der WALK Modus dient zum Durchwandern einer Welt, wobei der Benutzer von der
Software durch Maßnahmen wie Terrainverfolgung und Gravitationssimulation auf
dem Boden gehalten wird.
• FLY
Der FLY Modus dient zum Durchwandern einer Welt, ohne daß der Benutzer von
der Software auf dem Boden gehalten wird. Der Benutzer erhält zusätzlich zum
WALK Modus die Möglichkeit, sich nach oben oder unten zu bewegen.
• EXAMINE
Mit dem EXAMINE Modus kann ein Objekt aus unterschiedlichen Richtungen und
Entfernungen betrachtet werden. Das betrachtete Objekt kann entweder die ganze
simulierte Welt ausmachen oder ein Teilobjekt aus einer größeren Welt sein.
WALK und FLY sind sich sehr ähnlich, sie unterscheiden sich hauptsächlich darin, ob die
Effekte der Gravitation simuliert werden. Jedoch kann die Software im FLY Modus die
Eingaben des Benutzers in leicht geänderter Weise interpretieren als im WALK Modus,
wenn sie dadurch der unterschiedlichen Konzeption des FLY Modus Rechnung tragen
kann.
5.1.2 Koordinatensysteme
Um Navigation formal und mathematisch exakt beschreiben zu können, müssen zwei
Koordinatensysteme definiert werden. Darauf aufbauend werden zwei Richtungssysteme
definiert, die Bewegungen des Benutzers beschreiben.
z A
z W
y A
x A
y W
x W
Blickfeld des Avatars
Abb. 4: Avatar lokales und Welt lokales Koordinatensystem ☞3D
Ein Avatar lokales Koordinatensystem wird durch die Vektoren xA, yA und zA festgelegt. Es
beschreibt die Position und Orientierung des Avatars, und damit die Perspektive, aus
welcher der Benutzer die Szene sieht. Das Welt lokale Koordinatensystem, bestehend aus
Seite 29

Kapitel 5, Anpassbare Navigation
xW, yW und zW ist dasjenige, in dem die Szene beschrieben ist. Normalerweise steht der
Betrachter senkrecht und yA ist parallel zu yW. Im Allgemeinen aber sind beide Koordinatensysteme
unabhängig voneinander, wie in Abb. 4 dargestellt.
Ohne daß damit eine Einschränkung verbunden wäre, kann festgelegt werden, daß yW
immer die Richtung sei, die nach „oben” zeigt. Da diese Richtung für die Navigation eine
Sonderstellung gegenüber allen anderen Richtungen hat, wird sie im folgenden Text als
Lot-Vektor bezeichnet. Im WALK Modus wirkt die simulierte Gravitation entgegen dieser
Richtung. Auch erweist es sich sowohl im WALK als auch im FLY Modus als sehr hilfreich,
wenn die Ausrichtung des Avatars an diese Richtung angeglichen wird, d.h. wenn yA parallel
zu yW eingestellt wird, oder wenn die Abweichung von dieser Stellung von der Software
konstant gehalten wird, solange der Benutzer deren Änderung nicht ausdrücklich
wünscht.
Eine weitere Hilfestellung besteht darin, daß die Abweichung der Blickrichtung von der
Horizontalen nach oben oder unten auf einen bestimmten Winkel, der kleiner als 90° ist,
beschränkt wird. Denn wenn der Benutzer annähernd senkrecht nach oben oder unten
schaut, sieht er nur noch den Himmel bzw. den Boden. Versucht er sich durch seitliche
Drehbewegungen aus dieser Lage zu befreien, entstehen ungewollt Drehungen um die
Sichtachse, da seitliche Drehungen häufig um den Lot-Vektor ausgeführt werden (siehe
nächsten Abschnitt). Ferner wird durch diese Begrenzung auf weniger als 90° verhindert,
daß der Avatar auf dem Kopf steht, wodurch sich die Navigation noch schwieriger gestalten
kann.
Aufgrund dieser Sonderstellung der Richtung des Lot-Vektors erweist sich die Beschreibung
des Avatar lokalen Koordinatensystems durch eine Vorwärtsrichtung und eine
Schräglage als Abweichung vom Lot-Vektor als hilfreich. Die Vorwärtsrichtung wird durch
den Richtungsvektor v →
beschrieben, der immer senkrecht zum Lot-Vektor steht und deshalb
in die Waagerechte entlang der durch xw und zw aufgespannten Ebene zeigt. Die
Schräglage läßt sich durch zwei Winkel α und β als Abweichung von yA zu yW beschreiben.
Der Winkel α mißt die Neigung nach vorne, und β Die Neigung zur Seite. Eine Festlegung,
in welcher Weise diese beiden Winkel kombiniert werden, ist nicht notwendig, und kann
der konkreten Implementierung der Software überlassen werden.
Lot-
Vektor
α
v
β
Lot-
Vektor
Abb. 5: Problem bezogene Parametrisierung des
Avatar lokalen Koordinatensystems
→→→→
Diese Sonderstellung von yW trifft allerdings nicht auf alle Welten zu, so daß zusätzlich zu
den Modi WALK/FLY/EXAMINE noch eine Auswahl getroffen werden muß, ob yW dieser
Sonderbehandlung unterliegen soll oder nicht. Welten, wie etwa Weltraum Simulationen,
oder abstrakte Simulationen wie die dreidimensionale Darstellung von Computer Netzwerken
haben keine inhärente Richtung für „oben” oder „unten”. Hingegen ist bei der
Simulation realer Welten immer ein ausgeprägtes „oben” vorhanden.
Seite 30

5.1.3 Richtungssysteme
Kapitel 5, Anpassbare Navigation
Es lassen sich zwei Richtungssysteme definieren, um Bewegungen zu beschreiben. Das
SixDof Richtungssystem definiert Bewegungen im WALK und FLY Modus, die sich im wesentlichen
nur durch die Simulation der Gravitation unterscheiden. Das Examine Richtungssystem
beschreibt Bewegungen für den EXAMINE Modus. Dieser Modus wird bestimmt
durch einen als Drehzentrum ausgezeichneten Punkt im Raum, um den sich der
Benutzer dreht. Obwohl im EXAMINE Modus hauptsächlich Drehungen vorkommen, machen
translatorische Bewegungen durchaus Sinn, da sie das Zentrum der Drehung im
Blickfeld des Betrachters positionieren.
roll pitch
up
yaw
forward
right
Bildschirm
Sichtachse
Blickrichtung
a) SixDof Richtungssystem ☞3D b) Examine Richtungssystem ☞3D
ω ρ
φ
c) Rotierende Examine Richtungen d) Translatorische Examine Richtungen
Abb. 6: Das SixDof und das Examine Richtungssystem
Bewegungen im SixDof Richtungssystem werden in m/s bzw. rad/s gemessen. Sie geben
an, wie sich der Benutzer bewegt. Up, right und forward bewegen den Benutzer entlang
der Richtungen des Avatar bezogenen Koordinatensystems, wobei bei aktivierter Gravitation
entsprechende Einschränkungen entlang des Lot-Vektors gelten. Da die Definition
der Koordinatensysteme in Abb. 4 an VRML angelehnt ist, das die z-Achse nach hinten
definiert, bewegt die Richtung forward den Avatar in negativer zA-Richtung. Die Richtungen
right, up und forward ergeben somit ein Linkssystem.
R
B
ω ρ
A
φ
Seite 31

Kapitel 5, Anpassbare Navigation
Yaw und pitch drehen die Blickrichtung nach rechts und oben, während roll den Benutzer
seitlich nach links kippt. Pitch und roll erzeugen Drehungen um die entsprechenden Achsen
des Avatar lokalen Koordinatensystems. Sie beeinflussen dadurch die Schräglage
gegenüber dem Lot-Vektor. Würde yaw auch um die yA-Achse des Avatar lokalen Koordinatensystems
drehen, dann hätte das neben der gewollten seitlichen Drehung eine Änderung
dieser Schräglage zur Folge. Daher dreht yaw um die yW-Achse des Welt lokalen
Koordinatensystems, wenn der Richtung des Lot-Vektors in der Welt eine besondere Bedeutung
zukommt. Ist dies nicht der Fall, dreht yaw ähnlich wie die anderen Drehrichtungen
um die yA-Achse des Welt lokalen Koordinatensystems.
Die Examine Richtungen beschreiben Bewegungen eines Objektes, das betrachtet wird.
Diese Bewegungen können so interpretiert werden, daß der Viewpoint um einen vorgegebenen
Punkt gedreht wird. Dieser Punkt kann vom Benutzer vorgegeben sein, oder von
der Software automatisch gewählt werden. Die Bewegungen des Objektes können dadurch
realisiert werden, daß der Benutzer in entgegengesetzter Richtung bewegt wird.
Deshalb können Bewegungen beider Richtungssysteme zur gleichen Zeit ausgeführt werden.
Abb. 6 b) zeigt das Konzept des Examine Richtungssystems. Die Sichtachse ist die
Verbindungsgerade vom Viewpoint zum Drehzentrum. Sie deckt sich nicht
notwendigerweise mit der Blickrichtung des Benutzers. Diese Richtungen decken sich
nur, wenn das Drehzentrum exakt auf die Bildschirmmitte projiziert wird.
Die Richtungen φ und ω drehen das Objekt um die x- bzw. y-Achse des Avatar lokalen
Koordinatensystems. Hingegen dreht ρ um die Sichtachse. Alle drei Richtungen werden in
rad/s gemessen. Abb. 6 c) zeigt diese Richtungen aus der Sicht des Benutzers. Auf den
ersten Blick scheint ρ gleichbedeutend mit roll aus dem SixDof Richtungssystem zu sein.
Da der Avatar nicht notwendigerweise genau auf das Drehzentrum schauen muß, decken
sich die Richtung –zA und die Sichtachse nicht notwendigerweise. Die Definition von ρ
erreicht, daß das Objekt dem Betrachter nach einer Drehung in ρ-Richtung an der selben
Stelle erscheint wie vorher.
A, B und R sind translatorische Richtungen. Sie sind in Abb. 6 d) dargestellt. Aber anders
als die translatorischen Richtungen des SixDof Richtungssystems werden diese nicht in
m/s gemessen, sondern relativ zum Abstand zwischen Viewpoint und Drehzentrum definiert.
Das heißt, sie werden mit dem Abstand zwischen Avatar und Objekt multipliziert.
So wird erreicht, daß sich das Objekt mit gleicher Geschwindigkeit über den Bildschirm
bzw. das Gesichtsfeld des Betrachter bewegt, unabhängig davon, wie weit es von ihm
entfernt ist. A und B wirken entlang der xA- und yA-Achse des Avatar orientierten Koordinatensystems.
Sie dienen zum Verschieben des Objektes auf dem Bildschirm bzw. innerhalb
des Gesichtsfeldes des Betrachters.
R hingegen bewegt das Objekt entlang der Sichtachse, so daß sich die Richtung, unter
der das Objekt zu sehen ist, nicht verändert. Die Richtungen A, B und R definieren daher
im Allgemeinen kein Orthogonalsystem. Mit R kann ein Effekt ähnlich dem Zoomen realisiert
werden. dadurch, daß auch R relativ zum Abstand definiert wird, bewegt sich das
Objekt um so schneller, je weiter entfernt vom Avatar es sich befindet.
Für den erfolgreichen Einsatz des EXAMINE Modus sind nicht alle Richtungen des Examine
Richtungssystems von gleicher Bedeutung. Insbesondere können A, B und ρ im Sinne
einfacher Softwareimplementierung vernachlässigt werden. Für das SixDof Richtungssystem
trifft diese Regel in abgeschwächter Form auch zu. Hier kann vor allem roll weggelassen
werden.
Seite 32

5.2 Bewegungen
Kapitel 5, Anpassbare Navigation
Navigation in virtuellen Umgebungen heißt, sich zu bewegen. Dieser Abschnitt diskutiert
zwei Arten der Darstellung von Bewegungen und führt den Gedanken, Bewegungen zu
filtern, ein.
5.2.1 Darstellung
Es werden in dieser Arbeit zwei Arten unterstützt, Bewegungen darzustellen: als Geschwindigkeiten,
und positionsbezogen. Diese sind an die Kategorisierung von Eingabegeräten
in Relative und Positionale Geräte angelehnt. Eingaben von Zeigegeräten können
auf diese beiden Arten abgebildet werden.
Bewegungen, die von Relativen Eingabegeräten rühren, werden in der Regel als Geschwindigkeit
angegeben. Wird eine solche Angabe gemacht, gilt die Geschwindigkeit bis
eine neue Geschwindigkeit – die eventuell null sein kann – angegeben wird.
Positionale Eingabegeräte erzeugen eine Serie von Positionen. Diese können genauso gut
als eine Serie von Positionsdifferenzen repräsentiert werden. Positionsdifferenzen haben
gegenüber reinen Positionen den Vorteil, daß mehrere solcher Ströme, die von verschiedenen
Quellen stammen, durch einfache Addition zu einem Strom vereinigt werden können.
Es besteht auch keine Notwendigkeit, Bezugspunkte zu definieren. Ebenso wie Geschwindigkeiten,
sind Positionsdifferenzen nicht an eine feste Abtastrate gebunden.
In Abb. 7 ist die Addition zweier Bewegungen dargestellt, die als eine Serie von Positionsdifferenzen
dargestellt werden. Die Bewegung in Diagramm a) wird zu diskreten,
nicht äquidistanten Zeitpunkten abgetastet und ergibt die Folge p1. Daraus wird die Folge
∆p1 gebildet, indem jeweils die Differenz eines Wertes aus der Folge p1 und seinem Vorgänger
gebildet wird. Die in Diagramm b) dargestellte Bewegung wird zu den selben
Zeitpunkten abgetastet und ebenfalls in eine Folge von Positionsdifferenzen ∆p2 umgerechnet.
Beide Folgen mit Positionsdifferenzen werden addiert, so daß die Folge ∆p1+∆p2
entsteht. Diese wird schließlich in eine Folge p1+p2+C absoluter Positionen umgewandelt,
indem rekursiv zum jeweils letzten Wert der Folge der aktuelle Wert der Folge ∆p1+∆p2
addiert wird. Bei dieser Operation ist die vertikale Verschiebung unbestimmt. Diese ist
durch die Konstante C angedeutet, und muß aus einer Anfangsbedingung hergeleitet
werden.
p 1
t
a) b)
c)
p 2
t
d)
∆p 1
∆p 2
t
Σ
t
∆p 1 +∆p 2
t
e) f)
+Cp 1 +p 2 +C
Abb. 7: Addition von nicht äquidistanten Positionsdifferenzen
t
Seite 33

5.2.2 Filterung
Kapitel 5, Anpassbare Navigation
Ein paar am Rande durchgeführte Experimente haben den Verfasser zu Überlegungen
veranlaßt, die hier geschildert werden sollen, da einige Stellen dieser Arbeit davon beeinflußt
werden.
Ein testweises Einfügen eines linearen Filters erster Ordnung in den Signalweg, der die
Bewegungen des Avatars beschreibt, gibt Grund zu der Vermutung, daß generell ein Filter
mit Tiefpaß Charakteristik die Bewegungen der Navigation natürlicher und angenehmer
erscheinen lassen. Möglicherweise ist damit sogar eine Abschwächung der Effekte
der Simulatorkrankheit (motion sickness) verbunden.
Typischerweise werden mit haptischen Eingabegeräten Bewegungsgeschwindigkeiten
erzeugt, die sich sehr schnell ändern können, wenn der Benutzer das Eingabegerät manipuliert.
Insbesondere beim Beenden einer Bewegung geht die mit dem Eingabegerät erzeugte
Geschwindigkeit sehr schnell gegen null, so daß die resultierende Bewegung abrupt
endet. Bei positionalen Eingabegeräten, tritt dieser Effekt stärker auf, wie bei relativen
Eingabegeräten, da je nach Typ des Eingabegerätes eine Manipulation eine hohe
Geschwindigkeit für nur kurze Zeit hervorruft.
Wegen der schnellen Geschwindigkeitsänderungen erscheinen die erzeugten Bewegungen
abrupt und im EXAMINE Modus entsteht der Eindruck eines masselosen Objekts. Ein in
den Signalweg eingesetztes Tiefpaßfilter verleiht den Bewegungen des Avatars eine gewisse
Trägheit, wodurch natürlicher wirkendere Bewegungen entstehen. Möglicherweise
werden diese nicht nur vom Verfasser als angenehmer empfunden.
Eingabegerät..
Interpreter Tiefpaßfilter
Integrator
Geschwindigkeit v(t)
v(t) v'(t)
t
~
geglättete
Geschwindigkeit v'(t)
Abb. 8: Sanfte Bewegungen durch Tiefpaßfilter
Das eingesetzte Filter realisiert die Impulsantwort
={ e
h(t)
0
-(t-t 0 ) / τ 0A
A
t > t0
t ≤ t 0
wobei
t0: Bezugszeitpunkt
τ0: Zeitkonstante des Filters
t
∫
ungeglättete Position 'p'(t)
geglättete Position p'(t)
Das Ausgangssignal des Filters nähert sich dem Eingangssignal exponentiell asymptotisch
an. Die charakteristische Größe des Filters ist die Zeitkonstante τ0, welche die Geschwindigkeit
des Einschwingens beschreibt. Bei der Wahl der Zeitkonstante muß abgewägt
werden zwischen dem Glättungseffekt und der verzögerten Reaktion auf Benutzereingaben.
Variationen der Zeitkonstante haben gezeigt, daß die Glättung ab etwa 0,05 s bemerkbar
wird, und ab etwa 0,3 s als träge empfunden wird. Bei größeren Werten entsteht
ein Effekt ähnlich dem von Massenträgheit, die eine angestoßene Bewegung noch
einige Zeit aufrechterhält, bis die Bewegung durch Reibungseffekte abgeklungen ist.
p(t)
p'(t)
t
Seite 34

Kapitel 5, Anpassbare Navigation
Es wäre denkbar, daß andere Filter, z.B. Lineares Filter 2. Ordnung im aperiodischen
Grenzfall oder ein Mittelwert der letzten 0,3 Sekunden den Effekt der Glättung bei gleicher
Reaktionsdauer noch stärken und so noch natürlichere Bewegungen erzeugt werden
können.
5.3 Möglichkeiten in ex istierendem VRML
Dieser Abschnitt untersucht VRML dahingehend, ob es einem Autor Möglichkeiten bietet,
das Paradigma der Navigation an die Bedürfnisse der Anwendung anzupassen.
5.3.1 Ein typischer Browse r
In VRML wird die Navigation vom Browser implementiert. Der Browser erhält Ereignisse
von der Maus und Tastatur. Diese beschreiben Mausbewegungen, Mausklicks und Tastendrücke.
Der Browser verarbeitet sie nach einem festen Schema zu Bewegungen des
Avatars bzw. zu Manipulationen von Objekten der Szene. In Abb. 9 ist dieser Vorgang
schematisch dargestellt. Diese Grafik dient als Diskussionsgrundlage. Sie bedeutet nicht,
daß ein konkreter Browser dieser Struktur folgt.
Maus
Tastatur
Interpreter
Manipulation
Navigation
Browser Szene
Abb. 9: Typische Struktur eines VRML Browsers
Sensor
Knoten
Bewegung
des Avatars
Signale aus
der Szene
Signale von den Eingabegeräten werden zunächst im Modul Interpreter daraufhin untersucht,
ob der Benutzer zu navigieren beabsichtigt, oder ein Objekt manipulieren will.
Diese Entscheidung hängt z.B. davon ab, ob sich bei einem Mausklick ein manipulierbares
Objekt unter dem Mauszeiger befindet. Fällt die Entscheidung auf Manipulation, werden
die Signale in diesem Sinne interpretiert und an das Modul Manipulation gesendet. Dieses
aktualisiert Sensor Knoten entsprechend der erhaltenen Signale.
Entscheidet sich das Interpreter Modul jedoch dafür, daß der Benutzer navigieren will,
wandelt es die Signale der Eingabegeräte in Bewegungen um und sendet sie an das Modul
Navigation. Das Modul Navigation wertet diese Bewegungen aus und aktualisiert die
Szene entsprechend. Es berücksichtigt dabei die Gegebenheiten der Szene und verhindert,
daß der Benutzer durch Objekte läuft (Kollisionserkennung) und auf dem Boden
bleibt (Gravitationssimulation). Ferner führt dieses Modul Viewpoint-Animationen aus,
wenn der Benutzer einen Aussichtspunkt anwählt, oder ein Signal aus der Szene dies
auslöst.
Seite 35

Kapitel 5, Anpassbare Navigation
Da die Anwendung durch die Szenenbeschreibung definiert ist, erhält sie bei dieser
Struktur keine Möglichkeit, auf die Art und Weise Einfluß zu nehmen, wie Maus und Tastatur
Eingaben in Bewegungen des Avatars umgesetzt werden. Es fehlt außerdem die
Möglichkeit, das System um weitere Eingabegeräte zu erweitern, die den Umgang mit
dem System erleichtern würden.
5.3.2 Anpassbare Navigati on
In VRML besteht prinzipiell die Möglichkeit, die Browser interne Navigation zu deaktivieren
und durch einen Umweg über die Manipulation Benutzereingaben auszuwerten und
daraus Bewegungen des Avatars zu berechnen. Dadurch kann zwar die browsereigene
Navigation durch den vom Autor einer 3D Anwendung gestalteten Mechanismus ersetzt
werden, jedoch hat diese Vorgehensweise schwerwiegende Nachteile.
Die Sensor Knoten in VRML sind auf das Manipulationsparadigma ausgelegt. So geben sie
Benutzereingaben nur dann weiter, wenn diese auf einer Interaktion mit einem Objekt
der Szene beruhen. Außerdem reduzieren die Sensor Knoten die Benutzereingaben auf
nur maximal zwei unabhängige Freiheitsgrade und interpretieren diese mit Bezug auf die
3D Szene. Ferner sind Sensor Knoten für Zeigegeräte ausgelegt. Tastaturen, Relative und
Positionale Eingabegeräte werden damit nicht abgedeckt.
Um trotzdem für Navigation taugliche Benutzereingaben zu erhalten, sind zwei Techniken
denkbar. Beide beruhen auf einem sogenannten Head Up Display. Das ist ein mittels
ProximitySensor 5 und Transform Knoten erzeugtes Koordinatensystem, das in jedem
Augenblick mit dem Avatar lokalen Koordinatensystem übereinstimmt. In diesem Koordinatensystem
entsprechend plazierte Objekte sind immer im Blickfeld des Benutzers, unabhängig
davon, wie sich dieser bewegt. Diese Objekte können mit Sensor Knoten kombiniert
werden.
Sichtbare Bedienelemente
Objekte, die als Druckknopf fungieren, führen Bewegungen nach vorwärts, rückwärts,
links oder rechts herbei, wenn der Benutzer mit der Maus darauf klickt. Die Geschwindigkeit
der Bewegung wäre dabei fest vorgegeben. Alternativ kann ein bewegliches Objekt
wie ein virtueller Joystick funktionieren. Verschiebt der Benutzer das Objekt von seiner
Ruhelage weg, bewegt sich der Avatar mit einer der Entfernung der Verschiebung proportionalen
Geschwindigkeit. Die Richtung der Bewegung entspricht der Richtung der
Verschiebung. Läßt der Benutzer das Objekt los, fällt es auf seinen Ausgangspunkt zurück.
In einer Variation davon ist der bewegliche Teil des Objektes gar nicht sichtbar, so
daß nur eine für Bewegungen sensitive Fläche erscheint.
Mit jeder dieser drei Art von Objekten ist immer sichtbare Geometrie nötig, und der Benutzer
muß zur Navigation immer auf eines dieser Objekte klicken. Dies lenkt ihn aber
von der Interaktion mit der Szene ab.
Simulation roher Mauseingaben
Die andere Technik besteht darin, ein transparentes, rechteckiges Objekt in das Koordinatensystem
des Head Up Displays zu positionieren und mit einem TouchSensor zu kombinieren.
Da das Rechteck transparent ist, versperrt es dem Benutzer nicht den Blick auf
die Szene. Ist das Rechteck so groß, daß es den ganzen Bildschirm ausfüllt, liefert der
TouchSensor an seinem hitTexCoord_changed Feld die Position des Mauszeigers und am
isActive Feld, ob die Maustaste gedrückt ist. Abgesehen davon, daß man bei der Suche
nach der korrekten Größe des Rechteckes die zur Darstellung der Szene im Browser ver-
5 zeigt die Position und Orientierung des Avatars an.
Seite 36

Kapitel 5, Anpassbare Navigation
wendete Projektion berücksichtigen muß, und daß diese Technik nur mit Bildschirm orientierten
Zeigegeräten funktioniert – d.h. mit der Maus – ergibt sich hier der gravierende
Nachteil, daß dieses Rechteck den Zugriff auf dahinter liegende Objekte für die Manipulation
versperrt. Denn manipulative Mauseingaben werden immer auf das nächstliegende
Objekt angewandt.
Aus den durch diese beiden Methoden gewonnenen Benutzereingaben müßte man Bahnen
berechnen, welche die gewünschte Bewegung des Avatars beschreiben, und die Felder
position und orientation am Viewpoint Knoten entsprechend animieren. Dies erfordert
jedoch fundierte Kenntnisse in analytischer Geometrie, welche nicht der Denkweise
entspricht, die sonst zum Erstellen von 3D Welten notwendig ist. Somit ergibt sich eine
echte Hürde, anpassbare Navigation mit VRML zu entwickeln.
Ein Vorteil kommt diesen Methoden jedoch zu gute. Denn es wird damit automatisch jedes
vom Browser unterstützte Eingabegerät verwendet. Dies ist jedoch gleichzeitig ein
Nachteil, denn andere Eingabegeräte können nicht unterstützt werden, und die Spezifika
eines unterstützten Eingabegerätes gehen verloren.
Ein weiterer großer Nachteil stellt der fehlende Zugriff auf die Browser Funktionen Kollisionserkennung
und Terrain Following dar. Das bedeutet, daß der Browser nicht die Möglichkeit
hat, die Fortbewegung durch Objekte zu verhindern, oder horizontale Bewegungen
an Steigungen des simulierten Geländes anzupassen, da er den Positionen, die am
Viewpoint Knoten angegeben werden folgen muß.
5.4 Lösungsansatz
Der letzte Abschnitt 5.2.2 macht die Einschränkungen bei VRML deutlich, die einen Autor
daran hindern, das Navigationsparadigma an die Bedürfnisse einer Anwendung und deren
Nutzer anzupassen:
• Entweder müssen immer sichtbare Bedienelemente eingeblendet werden, oder der
manipulative Zugriff auf die Szene wird verhindert.
• Der Zugriff auf Benutzereingaben beschränkt sich auf zweidimensionale Zeigegeräte.
• Es sind intensive Kenntnisse in analytischer Geometrie notwendig.
• Der Browser hat keine Möglichkeit, Bewegungen durch Objekte zu verhindern, oder
im WALK Modus den Avatar auf dem Boden zu halten.
In diesem Abschnitt wird ein Konzept erarbeitet, das die Szenenbeschreibungssprache
VRML erweitert und versucht, diese Hindernisse zu eliminieren. In den Kapiteln 6 und 7
wird die Umsetzung dieses Konzepts detailliert beschrieben.
Seite 37

5.4.1 Zielsetzung
Kapitel 5, Anpassbare Navigation
Die neuen Knoten für anpassbare Navigation sollen folgenden Forderungen genügen:
• Die in VRML definierten Knoten zur Navigation sollen durch die neuen Knoten nicht
überflüssig werden. Sie sollen weiterhin die Rahmenbedingungen der Navigation beschreiben.
Durch die neuen Knoten soll lediglich das in einem konventionellen Browser
existierende Navigationsmodul, das in diesen Rahmenbedingungen operiert, für
die Anwendung zugänglich gemacht werden, so daß der Autor mehr Kontrolle darüber
erhält.
• Dem Autor soll mit dem hinter den neuen Knoten stehenden Konzept ein mächtiges
Werkzeug zur Verfügung stehen. Er soll ein Eingabegerät übernehmen und die Navigation
dafür selbst implementieren können. Er soll dies für alle vom DeviceSensor
unterstützten Eingabegeräte tun können, und so das Navigationsparadigma selbst
implementieren und dadurch an die Anwendung und deren Benutzerkreis anpassen
können.
• Mit Hilfe des EXTERNPROTO Mechanismus, der in VRML die Erstellung wiederverwendbarer
Module erlaubt, sollen Module entwickelt werden können, welche die Navigationsmodi
WALK, FLY, EXAMINE, sowie weitere, nicht standardisierte Modi unabhängig
von einer konkreten Anwendung implementiert werden können. Diese können dann in
verschiedenen Anwendungen hinzugeladen werden und die Defaultnavigation des
Browsers ersetzen.
5.4.2 Konzept
Damit ein Autor eigene Navigationsparadigmen gestalten kann, muß die in Abb. 9 dargestellte
starre Verbindung zwischen Eingabegeräten und dem Navigation Modul aufgebrochen
werden. Es muß einen Knoten geben, der die Signale eines Eingabegerätes innerhalb
der Szene repräsentiert und einen Knoten, der Bewegungen aus der Szene empfängt
und an das Navigation Modul weitergibt. Ferner muß ein Knoten existieren, der die
Angabe von grundlegenden Navigationsparametern ermöglicht, und einen Sensor Knoten,
der Information vom Navigation Modul an die Szene liefert. Der Autor kann dann einen
Script Knoten schreiben, der die Signale eines Eingabegerätes in Bewegungen des
Avatars umwandelt. Die Struktur eines so erweiterten VRML Browsers ist in Abb. 10 dargestellt.
Wenn der Autor es wünscht, kann die Verbindung von einem Eingabegerät zum Interpreter
unterbrochen werden und mit Hilfe des DeviceSensor und Navigator Knotens
durch die Szene geroutet werden. Der DeviceSensor dient zur Repräsentation eines Eingabegerätes.
Für jedes Eingabegerät, das der Autor anpassen will, muß er einen Device-
Sensor in die Szene einfügen. Er kann dabei angeben, ob die im Interpreter Modul vorhandene
Default Navigation für das Eingabegerät deaktiviert werden soll.
Fügt der Autor einen Navigator Knoten in die Szene ein, kann er mit diesem Avatarbewegungen
an das Navigation Modul senden. Diese werden mit den Bewegungen anderer
Navigator Knoten und den nicht deaktivierten Bewegungen des Interpreter Moduls überlagert.
Am Navigator Knoten ist ein Flag vorhanden, das der Autor setzen kann, wenn er
die im Browser eingebaute Navigation vollständig deaktivieren will. Das Interpreter Modul
wird dann nur noch für die Manipulation wirksam.
Der DeviceSensor kann neben reinen Eingabegeräten auch Feedback-Geräte unterstützen
und Ausgaben an diese senden. Dadurch ergibt sich für den Autor zusätzlich die Möglichkeit,
dem Benutzer über das Eingabegerät Rückkopplung zu geben.
Seite 38

Tastatur
Maus
Joystick
DeviceSensor
device
"JOYSTICK"
signalisiert Benutzereingaben
Interpreter
Script
Kapitel 5, Anpassbare Navigation
Manipulation
function stick(s) {
var tmp=
new SFVec3f();
tmp.x= s.x*speed;
tmp.z= -s.y*speed;
xyz= tmp;
}
Navigation
verarbeitet Benutzereingaben
zu Navigationswerten
Browser
Szene
Navigator
Bewegung
des Avatars
Signale aus
der Szene
bewegt den
Avatar
Abb. 10: Struktur eines VRML Browsers, der anpassbare Navigation unterstützt
Dem Autor steht mit diesem Konzept ein mächtiges Werkzeug zur Verfügung. Er kann ein
Eingabegerät übernehmen und die Navigation dafür selbst implementieren. Abb. 10 zeigt
diesen Vorgang. Der Autor kann das für alle vom DeviceSensor unterstützten Eingabegeräte
tun, und kann so das Navigationsparadigma selbst implementieren und an die
Anwendung und deren Benutzerkreis anpassen. Mit Hilfe des EXTERNPROTO Mechanismus,
der in VRML die Erstellung wiederverwendbarer Module erlaubt, können Module erstellt
werden, welche die drei Navigationsmodi WALK, FLY und EXAMINE unabhängig von einer
konkreten Anwendung implementieren. Diese können dann in verschiedenen Anwendungen
hinzugeladen werden und die Defaultnavigation des Browsers ersetzen.
Abgesehen von dem Ziel, ein Navigationsparadigma zu gestalten, können noch weitere
Effekte erzeugt werden. Benutzt man einen DeviceSensor, verzichtet aber auf den Navigator
Knoten, können in begrenztem Umfang auch Objekte in der Szene manipuliert
werden. In einer Golf Simulation könnte ein Schieberegler auf einem Eingabegerät die
Stärke des Schlages bestimmen. In anderen Welten könnte eine Taste auf dem Eingabegerät
das Öffnen von Türen oder eine andere objektspezifische Aktion auslösen, je nachdem,
in der Nähe welches Objektes sich der Benutzer befindet. Es müßte dazu ein DeviceSensor
in die Szene eingefügt werden, bei dem das Flag, das die Defaultnavigation
deaktiviert, nicht gesetzt ist.
Seite 39

Kapitel 5, Anpassbare Navigation
Ein Navigator Knoten, der nicht von einem DeviceSensor, sondern von einem Interpolator
oder einem Script gespeist wird, könnte für Effekte wie einen Stoß von hinten benutzt
werden, der den Benutzer ein Stück nach vorne bewegt. Anders als bei einer Animation
mit dem Viewpoint Knoten bleibt bei Verwendung des Navigator Knotens die Kollisionserkennung
aktiv, so daß der Benutzer durch den Stoß nicht in z.B. eine Wand gedrückt
werden kann. Außerdem ist es beim Navigator Knoten nicht erforderlich, die Eckpunkte
eines Interpolators abhängig von der aktuellen Position des Avatars und der
Richtung des Stoßes zu berechnen, da beim Navigator Knoten die Bewegung als solches
spezifiziert werden kann. Der visuelle Eindruck von Erdbeben kann ebenso durch eine
Auf- und Abbewegung erzeugt werden.
Seite 40

6 Repräsentation von Eingabegeräten
Kapitel 6, Repräsentation von Eingabegeräten
Die Unterstützung des Navigationsparadigmas bedeutet für eine Anwendung, Benutzereingaben
zu verarbeiten und in Navigationsbefehle umzuwandeln, um diese an den
Browser zur Ausführung zu senden. Dieses Kapitel entwickelt ein Sprachkonstrukt, das
Eingabegeräte innerhalb des Szenengraphen von VRML darstellt. Das Sprachkonstrukt
kann dabei so allgemein gehalten werden, daß es sowohl reine Eingabegeräte, als auch
solche mit Möglichkeit, Rückkopplung an den Benutzer zu geben, als auch beliebige andere
Geräte modellieren kann. Es wird daher in diesem Kapitel häufiger von „Geräten”
die Rede sein, als von „Eingabegeräten”. Der Name DeviceSensor des Sprachkonstrukts
ist an diesen Umstand angepaßt.
6.1 Anforderungen
Es werden folgende Anforderungen an ein Sprachkonstrukt zur Repräsentation von Eingabegeräten
gestellt:
• Unterstützung sowohl von reinen Eingabegeräten als auch von solchen mit Feedback-Möglichkeit
• Forcierung leicht wartbaren VRML Codes
• Interoperabilität
• Einfache Implementierbarkeit in einem Browser
Der Proto Mechanismus, der es in VRML erlaubt, neue Knoten zu definieren, wird sämtlichen
oben genannten Forderungen gerecht. Dies wird nachstehend erläutert.
Unterstützung von reinen Eingabegeräten und solchen mit Feedback-Möglichkeit
Wird das Eingabegerät durch eine Proto realisiert, modellieren Felder der Art eventOut
Bedienelemente, die vom Benutzer manipuliert werden können. Da diese Felder Information
an die Szene weitergeben, müssen sie eventOut Felder sein. Information, die der
DeviceSensor aufnehmen und an das Eingabegerät weitergeben soll, werden durch
eventIn Felder modelliert.
Forcierung leicht wartbaren VRML Codes
Andere Ansätze, z.B. [18] verwenden einen Knoten, der jeweils nur ein Bedienelement
des Eingabegerätes modelliert, bzw. das ganze Eingabegerät als ein großes Array von
Fließkomma-Zahlen repräsentiert. Beides führt zu schlecht wartbarem Code, da entweder
durch eine Vielzahl von Knoten die Lesbarkeit des Codes verringert wird, oder da ein
Array wenig über die Bedeutung der einzelnen Elemente des Arrays aussagt. Deshalb
wird in dieser Arbeit ein Ansatz verfolgt, der ein Gerät vollständig modelliert, und der
ähnlich dem Script Knoten die Definition von Feldern mit geräteabhängigen Namen erlaubt.
Zudem können diesen Feldern Datentypen gegeben werden, die dem Bedienelement,
das die Felder repräsentieren, gerecht werden. Der Proto Mechanismus, der in
VRML erlaubt, neue Knoten zu definieren, ist dafür gut geeignet.
Interoperabilität
Interoperabilität ist einer der Grundsätze, der das Design von VRML bestimmt hat. Interoperabilität
bedeutet, daß eine Anwendung, die unter Verwendung des einen Browsers
entwickelt wurde, auch auf anderen Browsern ausführbar ist. Unterstützt ein Browser ein
Feature, und ein anderer nicht, dann ist die Anwendung trotzdem auf beiden Browsern
ausführbar, wobei auf dem zweiten Browser nur dieses eine Feature nicht funktioniert.
Für die Modellierung von Eingabegeräten soll der selbe Grundsatz gelten. Eingabegeräte
können mit der Zeit weiterentwickelt werden, so daß neue Eingabegeräte Features anbieten,
die von einigen VRML Browsern noch nicht unterstützt werden. Verwendet eine
Anwendung die neuen Features, muß sie trotzdem auf älteren Browsern ausführbar bleiben.
Andersherum darf ein Browser auch nicht darauf bestehen, daß die in einer Anwendung
verwendete Modellierung eines Eingabegerätes die neuen Features einschließt.
Seite 41

Kapitel 6, Repräsentation von Eingabegeräten
einfache Implementierbarkeit in einem Browser
Für einen Programmierer, der einen existierenden VRML Browser um die Unterstützung
des DeviceSensor Knoten erweitern will, soll der damit verbundene Aufwand möglichst
gering sein. Deshalb darf kein neues Konzept in die Sprache VRML eingeführt werden,
sondern es muß auf bestehende Konzepte zurückgegriffen werden. Aufgrund der speziellen
Syntax von VRML müssen Parser Wissen über die an jedem Knotentyp vorhandenen
Felder und über deren Datentypen enthalten[1]. Mit dem PROTO Statement kann der
Knoten, der das Eingabegerät modelliert, vor seiner Verwendung deklariert werden.
VRML Parser erhalten dadurch das nötige Wissen, das sie benötigen, um diesen Knoten
zu parsen. Sie müssen daher nicht verändert werden.
6.2 Überblick
Der DeviceSensor basiert auf dem Proto Mechanismus und erfordert daher zur Implementierung
keine Änderung an bestehenden Parsern für VRML Code. Durch den Rückgriff
auf den Proto Mechanismus steht der volle Sprachumfang von VRML zur Modellierung
eines Gerätes zur Verfügung.
Genaugenommen wird das Gerät nicht durch den DeviceSensor Knoten repräsentiert,
sondern durch eine Proto Instanz, die dem DeviceSensor als Kind Knoten im Szenengraph
zugeordnet ist. Diese Proto Instanz wird im Folgenden Event Knoten genannt. Zweck des
DeviceSensor Knotens ist es, das Gerät zu benennen und den Event Knoten zu aktivieren
oder zu deaktivieren. Zudem kann am DeviceSensor festgelegt werden, ob der Browser
selbst auf Ereignisse am Gerät reagieren bzw. eigene Information an das Gerät schicken
darf. In der Szenenbeschreibung ist dem Proto keine Implementierung in Form von VRML
Knoten zugeordnet, da die Felder des Event Knoten vom Browser gesetzt werden.
DeviceSensor
device "JOYSTICK"
Event Knoten
event
eventOut SFVec2f stick
eventOut SFBool button1
eventOut SFBool button2
Abb. 11: Typische Struktur eines
DeviceSensor Knoten
Es muß für jedes Gerät, das in mehr als einem Browser funktionieren soll, eine Art Ministandard
existieren, der den Namen des Gerätes, die möglichen Felder am Event Knoten
und deren Bedeutung festlegt.
Mit dem DeviceSensor können sowohl reine Eingabegeräte als auch solche mit einem
Feedback-Kanal, oder reine Ausgabegeräte unterstützt werden. Am Event Knoten drückt
sich das durch die Art des Feldes aus. Ein eventOut liefert Information über ein Eingabe-
Seite 42

Kapitel 6, Repräsentation von Eingabegeräten
gerät an die Szene, während ein eventIn Information aus der Szene an ein Ausgabegerät
sendet. 6
Da DeviceSensor und Event Knoten so eng zusammen gehören, wird im Folgenden mit
dem Begriff DeviceSensor (als eingeführter Begriff formatiert) beides bezeichnet, während
DeviceSensor (als VRML Knoten formatiert) den Knoten an sich bezeichnet.
6.3 Knoten-Spezifikati on
In diesem Abschnitt wird der DeviceSensor Knoten deklariert und die Bedeutung seiner
Felder spezifiziert. Eine ausführliche Diskussion wichtiger Konzepte folgt im nächsten
Abschnitt.
DeviceSensor
{
exposedField SFBool enabled TRUE
field SFString device "" # "device" oder "device[nummer]"
field SFString parameter ""
exposedField SFNode event NULL
exposedField SFBool disableDefault FALSE
eventOut SFBool isActive
}
Das device Feld benennt das Gerät, das durch den DeviceSensor repräsentiert werden
soll. Es enthält Strings wie etwa "JOYSTICK" oder "DATAGLOVE[2]". Eine optionale Zahl
erlaubt die Auswahl eines von mehreren vorhandenen gleichartigen Geräten. Beispielsweise
könnte so zwischen einem Datenhandschuh für die linke und einem für die rechte
Hand unterschieden werden. Ist diese Zahl nicht gegeben, wird dem Browser freigestellt,
welches von den vorhandenen Geräten er dem DeviceSensor zuordnet. Jedoch muß der
Browser für alle Instanzen des DeviceSensor Knoten, die das selbe Gerät benennen und
keine Gerätenummer angeben, das selbe Gerät zuordnen.
Das event Feld enthält eine Referenz auf den Event Knoten. Dieser Event Knoten ist eine
Proto Instanz und enthält die Felder, die das Gerät beschreiben. Daten können mittels
des ROUTE Statements von oder zu den Feldern des Event Knotens geroutet werden.
Dadurch kann die Anwendung auf die Änderung jedes Feldes einzeln reagieren. Nach
jeder Änderung an einem Feld des Event Knotens sendet der eventOut Teil von event die
Referenz auf den Event Knoten, so daß der Knoten als Ganzes in einem Script Knoten
verarbeitet werden kann.
Um Mehrdeutigkeiten zu vermeiden, sollte jede DeviceSensor Instanz eine eigene Instanz
des Event Knotens enthalten, es sei denn, dies ist durch die Spezifikation für das Gerät
ausdrücklich erlaubt. Diese Forderung vereinfacht die Implementierung von VRML Browsern,
da sonst Sonderfälle provoziert werden könnten, die eine extra Behandlung erfordern
würden.
6 Diese Zuordnung scheint auf den ersten Blick unlogisch. Macht man sich aber bewußt, daß die Anwendung
ein Eingabegerät von der anderen Richtung sieht – nicht aus der Sicht des Benutzers,
sondern aus der Sicht des Computers – wird klar, daß zu einem Eingabegerät Felder mit der Funktion
eines Ausgangs gehören.
Seite 43

Kapitel 6, Repräsentation von Eingabegeräten
Mit parameter können Initialisierungsparameter an die Implementierung des Gerätes
übergeben werden. Die Bedeutung dieses Feldes ist geräteabhängig. Für manche Geräte
bedeutet dies eine Auswahl an Ereignissen, die für das Gerät angezeigt werden.
Ist enabled nicht gesetzt, ist der DeviceSensor inaktiv. Wenn enabled hingegen gesetzt
wird, wird der DeviceSensor in den aktiven Zustand gesetzt, falls das ihm zugeordnete
Gerät vom Browser unterstützt wird und physikalisch vorhanden ist. An isActive zeigt
der DeviceSensor seinen Aktivierungszustand an. Ist isActive gesetzt, ist der DeviceSensor
aktiv. Mit anderen Worten ausgedrückt, erzwingt ein nicht gesetztes enabled einen
inaktiven DeviceSensor und dadurch ein nicht gesetztes isActive, während ein gesetztes
enabled den DeviceSensor, sofern möglich, aktiviert und möglicherweise ein gesetztes
isActive bewirkt. Das isActive Feld sendet seinen Zustand immer dann, wenn sich der
Aktivierungszustand des DeviceSensor Knoten ändert. Wenn ein Wert an enabled empfangen
wird, sendet es seinen Wert auch dann, wenn dies keine Änderung von isActive
bewirkt. Dadurch kann ein Script Knoten auf ein Fehlschlagen der Aktivierung eines DeviceSensors
reagieren. Aus ähnlichen Gründen sollte das isActive Feld auch seinen initialen
Wert senden, nachdem der Browser festgestellt hat, ob das angeforderte Gerät
unterstützt werden kann.
Mit dem disableDefault Feld läßt sich steuern, ob der Browser selbst das Gerät abfragen
und darauf reagieren darf, z.B. um es zur Navigation zu verwenden. Ist für ein bestimmtes
Gerät mindestens ein DeviceSensor in der Szene vorhanden, dessen enabled
Feld und disableDefault Feld gesetzt sind, darf der Browser an diesem Gerät gemachte
Eingaben nicht mehr selbst verarbeiten. Er darf auch keine Ausgaben an das Gerät senden
– z.B. um Force-Feedback bei Kollisionen mit Geometrie zu erzeugen. Dadurch liegt
die komplette Kontrolle über das Eingabegerät beim Autor der Anwendung.
6.4 Erläuterungen
6.4.1 Aktivierungslogik
In seinem inaktiven Zustand bleiben die Felder des Event Knotens unverändert, wenn ein
Ereignis im zugeordneten Gerät auftritt oder sich dessen Zustand ändert. Weder die
eventOut Felder am Event Knoten noch das event Feld des DeviceSensor senden Ereignisse
über angeschlossene Routen. Lediglich exposedFields am Event Knoten dürfen
Werte, die sie über eine Route aus der Szene erhalten haben, an abgehenden Routen
weitersenden. Enthält der Event Knoten eventIn Felder oder exposedFields, die Information
an das Eingabegerät senden, werden diese Werte ignoriert.
Ist der DeviceSensor jedoch aktiv, zeigen eventOut Felder am Event Knoten Zustände
des zugeordneten Gerätes und dort auftretende Ereignisse an. Ändert sich eines oder
mehrere Felder am Event Knoten, so sendet anschließend auch das event Feld des
DeviceSensor eine Referenz auf den Event Knoten. Ereignisse, die über eventIn Felder
und exposedFields aus der Szene empfangen werden, gibt der Browser an das Gerät
weiter. Sind mehrere DeviceSensor Instanzen für ein Gerät aktiv, so senden alle Instanzen
Information über das Gerät auf die hier angegebene Weise. Falls die Spezifikation für
ein Gerät nichts anderes vorsieht, werden bei Ausgabegeräten die Ereignisse, die über
verschiedene Instanzen empfangen werden, nach den selben Regeln vereinigt, die gelten
wenn alle Routen auf das selbe eventIn Feld nur eines einzigen DeviceSensors zeigen
würden. In [1] werden diese Regeln unter dem Stichwort „Fan-In” erläutert. Im wesentlichen
sagen diese Regeln aus, daß bei gleichzeitig erhaltenen Ereignissen die Resultate
undefiniert sind, und der Autor diese Situation vermeiden sollte.
Seite 44

Kapitel 6, Repräsentation von Eingabegeräten
Damit ein DeviceSensor aktiv ist, müssen folgende Bedingungen erfüllt sein:
• Das enabled Feld am DeviceSensor muß gesetzt sein.
• Der Browser muß das im device Feld angegebene Gerät unterstützen.
• Das Gerät muß physikalisch vorhanden sein.
In dem Moment, in dem ein DeviceSensor deaktiviert wird, dürfen sich die Felder des
Event Knoten nicht so ändern, daß sie den Ruhezustand des Eingabegerätes beschreiben,
es sei denn, das Eingabegerät ist tatsächlich in seinem Ruhezustand. Mit Ruhezustand sei
hier der Zustand des Eingabegerätes verstanden, der entsteht, wenn weder eine Taste
gedrückt ist, noch ein Bedienelement ausgelenkt ist. Diese Regel bewirkt, daß die Felder
beim Übergang in den inaktiven Zustand aufhören, Werte über angeschlossene Routen zu
senden und die Szene daher in dem Zustand belassen, der in dem Moment der Deaktivierung
gültig war. Soll die Szene dennoch bei einem deaktivierten DeviceSensor in einen
Ruhezustand versetzt werden, kann dies durch einen Script Knoten erreicht werden, der
das isActive Feld des DeviceSensor Knotens auswertet und gegebenenfalls entsprechende
Werte an diejenigen eventIn Felder sendet, die mit den Feldern des Event Knoten
verbunden sind. Erst wenn der DeviceSensor wieder aktiviert wird, dürfen Felder am
Event Knoten, die einen Zustand des Gerätes anzeigen neuen Werte annehmen und diese
in angeschlossene Routen senden.
6.4.2 Standardisierung von Geräten
Eines der Ziele von VRML ist, daß Autoren 3D Welten erstellen können, die von allen
Browsern korrekt ausgeführt werden, auch wenn die Browser von unterschiedlichen Herstellern
stammen. Dieses Ziel der Interoperabilität soll auch mit dem DeviceSensor erreicht
werden.
Damit eine Szenenbeschreibung unabhängig vom verwendeten Browser auf ein Gerät
zugreifen kann, müssen die Felder des Event Knoten für ein Gerät standardisiert werden.
Durch die Forderung an einen Browser, nicht unterstütze Felder am Event Knoten zu akzeptieren,
und unterstützte, aber am Event Knoten fehlende Felder zu ignorieren, kann
dieser „Ministandard” leicht erweitert werden.
Für einen bestimmten Gerätetyp muß festgelegt werden:
• Der Name des Gerätetyps.
• Die Namen und Typen der Felder am Event Knoten.
• Die Bedeutung der Felder.
Der Name des Gerätetyps muß eindeutig sein, da er im device Feld des DeviceSensor zur
Auswahl des Gerätes dient. Benötigt das Gerät Initialisierungsparameter, müssen diese
als mögliche Werte des parameter Feldes festgelegt werden.
Der Standard für ein Gerät kann für bestimmte Felder festlegen, daß diese nicht notwendigerweise
von einem Browser unterstützt werden. Zum Beispiel kann so der Gerätetyp
„JOYSTICK” um eine Schnittstelle für Force-Feedback erweitert werden, ohne daß jeder
Browser diese neue Funktionalität unterstützen muß, und ohne daß dafür ein eigener
Gerätetyp mit eigenem Namen definiert werden müßte.
Seite 45

Kapitel 6, Repräsentation von Eingabegeräten
Damit Browser Programmierer die Möglichkeit haben, eigene, nicht standardisierte Geräte
zu implementieren, sollte ein Präfix definiert werden, der in Namen standardisierter
Geräte nicht vorkommt. Dieser könnte, z.B. in Anlehnung an die Mime Types 7 „x-” lauten.
Für die Namen von Feldern am Event Knoten sollte ebenfalls ein solcher Präfix definiert
werden, damit Browser über den Standard hinausgehende Felder definieren können.
6.5 Diskussion
In diesem Abschnitt werden einige Konzepte diskutiert, die einen reibungslosen und
mächtigen Einsatz des Konzepts DeviceSensor ermöglichen.
6.5.1 Eingabefokus in Mult itasking Systemen
Oft ist der Browser nur eine Anwendung von vielen, die auf einem System gleichzeitig
ausgeführt werden und um die Betriebsmittel des Systems konkurrieren müssen. Solche
Systeme werden Multitasking Systeme genannt. Im Allgemeinen wird diese Konkurrenz
bei Tastatureingaben dadurch gelöst, daß immer nur einem Anwendungsfenster der sogenannte
Eingabefokus zugeordnet wird. Über die Tastatur gemachte Eingaben werden
vom Betriebssystem nur an das Fenster gesendet, das den Eingabefokus hat.
Im Sinne eines konsistenten und nachvollziehbaren Benutzungsinterfaces[3] sollte die
selbe Logik auch für 3D Eingabegeräte gelten, z.B. dann wenn auf einem System mehrere
Browser mit verschiedenen Anwendungen ausgeführt werden. Dem Browser, dem
die Tastatur momentan zugeordnet ist, sollten auch alle anderen Eingabegeräte zugeordnet
sein.
Ausgehend von dem Gedanken, daß eine (3D) Anwendung ohne Eingabefokus so reagieren
sollte, als ob der Benutzer keine Eingaben machen würde, können folgende Regeln
für den DeviceSensors aufgestellt werden:
Verliert der Browser den Eingabefokus, dann ändert das nicht den Aktivierungszustand
des DeviceSensors, er liefert aber trotzdem keine Benutzereingaben an die 3D Szene
weiter und ignoriert Signale von der 3D Szene an eine Feedback-Möglichkeit im Eingabegerät.
Das bedeutet, daß das isActive gesetzt bleibt, wenn die in Abschnitt 6.4.1 genannten
Bedingungen für einen aktiven DeviceSensor zutreffen. Diejenigen Felder am
Event Knoten, die den Zustand eines Bedienelements am Eingabegerät anzeigen, nehmen
jeweils den Wert an, der dem Ruhezustand des Bedienelements entspricht. Dieser
Wert ist der letzte, den diese Felder in die 3D Szene senden solange der Browser keinen
Eingabefokus hat.
6.5.2 Flexibilität durch Rüc kgriff auf Proto Mechanismus
Der Rückgriff auf das Sprachkonstrukt des Protos beim Event Knoten macht das Konstrukt
des DeviceSensors im Bezug auf Erweiterungen der Modellierung eines Gerätes
extrem flexibel, wenn erlaubt wird, daß der Event Knoten nicht alle für das Gerät vorgesehenen
Felder enthalten muß, dafür aber andere, nicht vorgesehen Felder enthalten
darf.
Da der Autor in der Szenenbeschreibung die Felder des Event Knoten mit einem PROTO
Statement deklarieren muß, dokumentiert er implizit, welche Felder er verwenden will.
7 Mime Types ist ein Internet Standard, der Dateitypen benennt.
Seite 46

Kapitel 6, Repräsentation von Eingabegeräten
Der Browser muß dann nur diejenigen Werte berechnen, welche die Szene wirklich verarbeitet.
Felder, die der Browser nicht unterstützt, kann er ignorieren.
Wenn ein bestimmter Umfang an Feldern für einen bestimmten Gerätetyp festgelegt
wurde, und später erweitert werden soll, da z.B. der Funktionsumfang solcher Geräte
wächst, so bleiben für ältere Browser geschriebene Anwendungen auch auf neueren
Browsern lauffähig. Im umgekehrten Fall bleibt eine für einen neueren Browser geschriebene
Anwendung auf einem älteren Browser lauffähig, wenn die Anwendung den Fall
berücksichtigt, daß einige Felder keine Werte liefern.
Existiert keine definierte Obergrenze der Anzahl an einem Gerät vorhandener Bedienelemente
eines bestimmten Typs, so kann dies durch Anhängen einer Nummer an den Feldnamen
gelöst werden. Beispielsweise könnten Felder button1, button2, ... genannt werden.
Der Autor erwähnt in der Proto Deklaration für den Event Knoten so viele dieser
Felder, wie er benutzen will, und der Browser unterstützt davon so viele, wie auf dem
Gerät tatsächlich vorhanden sind. Durch ein Feld numButtons könnte dann die Anzahl der
tatsächlich vorhandenen Bedienelemente angezeigt werden.
6.5.3 Methoden für den Ge rätezugriff
Der DeviceSensor unterstützt zwei Methoden, um auf den Zustand eines Eingabegerätes
zuzugreifen. Man kann die Felder des Event Knotens einzeln über Routen mit anderen
Knoten verbinden, oder den Event Knoten als ganzes über nur eine Route an einen Script
Knoten senden. Bei Ausgabegeräten ergeben sich die selben beiden Möglichkeiten, nur in
umgekehrter Richtung. Je nach Typ des Eingabegerätes kann die Ausrichtung des Event
Knoten für eine von beiden Methoden naheliegender sein.
DeviceSensor
device "JoyStick"
event
Event Knoten
button1Time
button2Time
stick
TimeSensor
startTime
Script
next
direction
DeviceSensor
device "SpaceMouse"
event
Event Knoten
position
rotation
buttonBits
Script
event
a) b)
Abb. 12: Zugriff a) auf einzelne Felder, oder b) auf den Event Knoten als Ganzes
Bei der Methode a), welche die Felder des Event Knotens einzeln mit den Feldern anderer
Knoten zu verbindet, kann die Anwendung auf Änderungen der Werte einzelner Felder
spezifischer reagieren, da der empfangende Knoten nicht nur Information über den Zustand
der Felder erhält, sondern auch darüber, wann sich welches Feld ändert. Eventuell
kann ein Script Knoten sogar ganz überflüssig werden, wenn die Datentypen der Felder
des Event Knoten mit denen der Felder anderer Knoten übereinstimmen. Zwischengeschaltete
Interpolator Knoten 8 können den Wertebereich anpassen, oder nichtlineare
8 Interpolator Knoten realisieren stückweise stetige Kennlinien, die einen eindimensionalen Wertebereich
in einen anderen ein- oder mehrdimensionalen Wertebereich transformieren. Der Zielwertebereich
kann einer der VRML Datentypen SFFloat, SFVec3f, SFRotation, SFColor, MFVec3f sein.
Interpolator Knoten werden hauptsächlich bei Key Frame Animationen eingesetzt.
Seite 47

Kapitel 6, Repräsentation von Eingabegeräten
Übertragungskennlinien realisieren. Ein Nachteil dieser Methode ist, daß möglikcherweise
viele Routen nötig sind, um einen Event Knoten mit einem Script Knoten zu verbinden.
Methode b), den Event Knoten als Ganzes an einen Script Knoten zu senden, wenn sich
eines seiner Felder geändert hat, hat diesen Nachteil nicht. Da hier die Information
mehrerer Felder auf einmal übertragen wird, kann so komplexere Information codiert
werden. Möglicherweise kann ein type Feld angeben, welche Art von Ereignis im Eingabegerät
aufgetreten ist, und implizit ausdrücken, welche Felder des Event Knoten gültig
sind. Der empfangende Script Knoten erhält Information über die genaue Reihenfolge
dieser Ereignisse und kann eine Programmstruktur ähnlich der Dialogfunktion in 2D GUI
basierten Anwendungen aufbauen. Die Dialogfunktion ist in 2D GUI Systemen die Funktion,
an die das Betriebssystem Nachrichten über Benutzereingaben oder Systemmeldungen
sendet. Erhält ein Script Knoten Ereignisse, die er nicht selbst verarbeitet, kann er
sie auf einfache Weise an andere Knoten übergeben.
6.5.4 DeviceSensor als bin dbarer Knoten
Der DeviceSensor wurde so gestaltet, daß zu einem bestimmten Gerät mehr als ein DeviceSensor
existieren und zur selben Zeit aktiv sein können. Dieser Sachverhalt wird im
Folgenden mit kooperativer DeviceSensor umschrieben. Die Alternative zu diesem Konzept
wäre, den DeviceSensor zu einem bindbaren Knoten zu machen, d.h. einen Stack
mit allen DeviceSensor Knoten anzulegen, und nur denjenigen Knoten zu aktivieren, der
sich an oberster Stelle des Stacks befindet. Beide Konzepte unterstützen die Modularisierung
von VRML Code auf ihre eigene Art und Weise:
Ein bindbarer DeviceSensor würde es erlauben, eine Welt zu modellieren, die in einer
größeren Welt eingebettet ist, und im Sinne wiederverwendbarer Softwaremodule kein
Wissen über die enthaltende Welt verfügt. Etwa ein Gebäude, das man betreten kann,
innerhalb einer Stadt. Wenn der Benutzer das Gebäude betritt, wird ein dem Gebäude
zugeordneter DeviceSensor gebunden, der Teil des Gebäude Modells ist. Dadurch würde
dieser Benutzereingaben an ein Script senden, welches einen an die Gegebenheiten enger
Räume angepaßten Navigationsmodus implementiert. Außerhalb des Gebäudes würde
ein anderer DeviceSensor als Teil des Stadtmodells auf die gleiche Weise ein Script
versorgen, das eine für weiträumiges Gelände besser taugliche Navigation implementiert.
Auf die gleiche Weise könnte mit einem bindbaren DeviceSensor die Funktionen bestimmter
Bedienelemente auf dem Eingabegerät geändert werden. Beispielsweise schaltet
ein bestimmter Knopf innerhalb des Gebäudes das Licht ein und aus, und außerhalb
des Gebäudes dient er zum Anhalten eines Taxis, das eine Metapher zum schnellen
Sprung an entfernte Orte darstellt. Das Modell des Gebäudes könnte das Umschalten auf
den eigenen DeviceSensor beim Betreten und das Zurückschalten auf den vorherigen
DeviceSensor – sofern vorher einer gebunden war – selbst übernehmen, ohne daß es
Zugriff auf den externen DeviceSensor haben müßte, denn dies würde bedeuten, daß das
Gebäudemodell Wissen über das Modell der Stadt verfügen würde.
Mit einem bindbaren DeviceSensor würde das Gebäudemodell lediglich den eigenen
DeviceSensor auf den Stack legen wenn der Benutzer das Gebäude betritt und ihn wieder
vom Stack nehmen, wenn der Benutzer das Gebäude wieder verläßt. Die Logik des
Stacks würde dann den DeviceSensor des Stadtmodells wieder aktivieren, da dieser an
die oberste Stelle des Stacks gerutscht wäre.
Sollte der DeviceSensor ein bindbarer Knoten sein, so würde das bedeuten, daß, anders
als bei anderen bindbaren Knoten, ein eigener Stack für jedes durch einen DeviceSensor
verwendete Gerät existieren müßte. Bei nur einem Stack für alle DeviceSensoren könnte
beispielsweise das Binden eines mit einem Joystick verknüpften DeviceSensor einen mit
einer Spacemouse verknüpften DeviceSensor deaktivieren. Das Konzept mehrerer Stacks
Seite 48

Kapitel 6, Repräsentation von Eingabegeräten
würde nicht nur die Implementierung im Browser komplexer gestalten, da die Stacks
dynamisch während des Parsens der Szene generiert werden müßten, es würde auch das
Sprachkonstrukt des DeviceSensors schwerer verständlich machen.
Zudem ist die Stack-Logik für bestimmte Arten von Eingabegeräten nicht angebracht. Hat
eine Szene mehrere Bedienelemente, die alphanumerische Eingaben von einer Tastatur
erwarten, und ist jedes Bedienelement als eigenständiges Softwaremodul in einem eigenen
Proto realisiert, dann würde auch jedes Bedienelement seine eigene Instanz des DeviceSensors
besitzen. In diesem Fall deckt sich die Stack-Logik eines bindbaren Device-
Sensors nicht mit der bei konventionellen, graphischen Benutzungsoberflächen üblichen,
und als zweckmäßig erachtete Logik für den Eingabefokus (Der Eingabefokus legt fest,
welches Bedienelement Tastatureingaben erhält): Ein Bedienelement, das aktiviert wird,
würde seinen DeviceSensor auf den Stack legen, und dadurch einen eventuell vorher
aktiven DeviceSensor deaktivieren, so daß dieses Bedienelement in korrekter Weise den
Eingabefokus erhält. Wenn aber ein Bedienelement explizit deaktiviert wird, worauf es
seinen DeviceSensor vom Stack nimmt, dann würde durch die Stack-Logik, das vorher
aktive Bedienelement den Eingabefokus wiedererlangen. Dies würde der Benutzer nicht
erwarten. Korrekt wäre, daß in diesem Fall der Eingabefokus keinem Bedienelement wird.
Das Konzept des kooperativen DeviceSensors unterstützt eine andere Form von Modularisierung
als dies bei einem bindbaren Knoten der Fall ist: Voneinander unabhängige Module
können bestimmte Teile des Eingabegerätes verarbeiten. Bei einem Joystick könnte
z.B. ein Proto mit seinem DeviceSensor die Auslenkung des Knüppels abfragen und zur
Navigation verwenden, während ein anderer, unabhängiger Proto mit seinem gleichzeitig
aktiven DeviceSensor die Zustände der Feuerknöpfe abfrägt und damit das Abfeuern von
Waffen auslöst. Bei einer alphanumerischen Tastatur könnte ein DeviceSensor zur Eingabe
von Chat Text dienen, während ein anderer DeviceSensor in einem unabhängigen
Programmodul den numerischen Tastenblock zur Navigation verwendet.
Mit dem kooperativen DeviceSensor ergibt sich zudem die Möglichkeit, den Stack Mechanismus
zu emulieren. Macht man es zu einer Konvention, in einer Anwendung das enabled
Feld mit dem isBound eventOut eines bestimmten bindbaren Knotentyps durch
eine Route zu verbinden, dann wäre immer nur derjenige DeviceSensor aktiv, der mit
dem gerade gebundenen bindbaren Knoten verknüpft ist. Als bindbarer Knoten bietet
sich die NavigationInfo an.
Ein dedizierter Stack Knoten wäre eine sinnvolle Erweiterung für den VMRL Standard, da
dieser Knoten für den DeviceSensor Stack-Logik verfügbar macht, ohne dies zu erzwingen.
Dieser Knoten hätte ein Feld field SFString name, das einen Namen für einen Stack
definiert. Zusätzlich besitzt der Knoten die für einen bindbaren Knoten üblichen Felder
eventIn SFBool set_bind und eventOut SFBool isActive. Der Browser würde für jeden
genannten Namen einen Stack anlegen, in dem alle Stack Knoten, die den selben Namen
nennen, verwaltet würden. Dieser Mechanismus wäre viel mächtiger, als ein bindbarer
DeviceSensor, denn der Stack Knoten könnte auch die Aktivierung anderer Knoten als die
des DeviceSensors regulieren, z.B. die von Script Knoten, die eine bestimmte Art von
Aufgaben erlegen. Ferner könnten andere Knotentypen andere Regeln implementieren –
z.B. die der Logik für den Eingabefokus – und mit dem DeviceSensor verknüpft werden.
Seite 49

Kapitel 6, Repräsentation von Eingabegeräten
6.6 Typische Geräte un d deren Implementierung
Dieser Abschnitt diskutiert einige Besonderheiten des dem DeviceSensor zugrunde liegenden
Ansatzes anhand von vier ausgesuchten Beispielen, für die eine Repräsentation
als DeviceSensor programmiert wurde.
6.6.1 Implementierung der Basisfunktionalität
Die Implementierung des generischen Teils des DeviceSensors wurde in Form einer erweiterbaren
Architektur realisiert. Nur die Implementierung für das Gerät „STANDARD”,
das Maus und Tastatur vereinigt, ist aus technischen Gründen im Browser blaxxun Contact
selbst implementiert. Die Implementierungen aller anderen Geräte sind nachladbare
Module nach dem COM[32] Standard. Dadurch können auch andere Programmierer dem
Browser Unterstützung für ein Eingabegerät hinzufügen.
Der generische Teil der DeviceSensor Implementierung wertet die Felder am DeviceSensor
Knoten aus, und sendet Änderungen an das Erweiterungsmodul. Wenn ein Device-
Sensor aktiviert werden soll, wertet der Browser das device Feld aus und stellt fest, ob
ein entsprechendes Modul auf dem Rechner installiert ist. Ist das der Fall, wird es geladen
und bekommt den Wert des evenType Feldes und eine Referenz auf den Event Knoten
mitgeteilt. Anschließend wird eine Methode des Moduls in jedem Simulationsschritt aufgerufen,
so daß das Modul Rechenzeit erhält.
Die Referenz auf den Event Knoten verwendet das Modul dann, um herauszufinden, welche
Felder am Event Knoten tatsächlich vorhanden sind, und um diese entsprechend der
Benutzereingaben am Eingabegerät zu setzen. Handelt es sich um ein Eingabegerät mit
Feedback-Möglichkeit wird mit Hilfe der Referenz auf den Event Knoten auf Signale aus
der Szene reagiert und diese an das Eingabegerät weitergegeben. Die Kommunikation
mit den Feldern des Event Knoten basiert auf der im VRML Standard definierten Schnittstelle
EAI, die im verwendeten Browser schon vorhanden war. Genauere Details über die
der Implementierung der dem DeviceSensor zugrunde liegenden Erweiterungsarchitektur
können unter [24] nachgelesen werden. Anhang D enthält eine Kopie dieses Dokuments.
6.6.2 Spacemouse
Die Spacemouse ist ein speziell für 3D Anwendungen entwickeltes Eingabegerät[25]. Sie
besteht aus einer federnd gelagerten Kappe, die vom Benutzer in allen sechs Freiheitsgraden
des dreidimensionalen Raumes ausgelenkt werden können. Das Gerät mißt die
Stärke dieser Auslenkung in Form dreier translatorischer Werte und dreier Drehwinkel um
die Hauptachsen des Gerätes. Zusätzlich befinden sich auf der Spacemouse je nach Ausprägung
bis zu elf Druckknöpfe. Die Auslenkungen werden mit sehr hoher Präzision gemessen
und als Verhältnis zur Maximalen Auslenkung angegeben.
Abb. 13: Spacemouse
Die Spacemouse ist in die Kategorie der relativen Eingabegeräte einzuordnen, da sie nur
Richtungen, aber keine absoluten Position beschreibt.
Seite 50

Kapitel 6, Repräsentation von Eingabegeräten
Modellierung und Diskussion
Soll die Spacemouse mit einem DeviceSensor modelliert werden, ist folgendes Interface
für den Event Knoten zu empfehlen:
PROTO SixDOF
[
eventOut SFVec3f position
eventOut SFRotation rotation
eventOut SFVec3f rotationYPR
eventOut SFBool button1
eventOut SFBool button2
... ... ...
eventOut SFTime button1Time
eventOut SFTime button2Time
... ... ...
eventOut SFInt32 buttonBits
eventOut SFInt32 numButtons
] {}
Die in sechs Freiheitsgraden möglichen Auslenkungen werden in den Feldern position
und rotation angezeigt. Der an position signalisierte Wert ist ein Vektor mit drei Komponenten
im Wertebereich [-1 .. +1] und gibt die translatorische Auslenkung der Kappe
als Verhältnis zur maximalen Auslenkung an. Das Feld rotation hingegen gibt die rotatorische
Auslenkung in Achse-Winkel Form an. Die Drehachse der Auslenkung wird als
Normalenvektor repräsentiert, und der Drehwinkel wird als Verhältnis zur maximalen
Auslenkung im Wertebereich [-1 .. +1] angegeben.
Bei rotation ist der verwendete Datentyp SFRotation zwar derjenige, der in VRML typischerweise
zur Beschreibung von Rotationen verwendet wird, aber für einige Berechnungen
wäre eine komponentenweise Darstellung der Drehwinkel um die drei Achsen praktikabler.
Aus diesem Grund werden diese Komponenten an rotationYPR angezeigt. Da es
sich nicht um Winkel, sondern um Verhältnisse zu einer sehr geringen Maximalauslenkung
handelt, gilt folgende Beziehung:
rotation = (Axis, Angle), mit
Axis = rotationYPR 0
Angle = ||rotationYPR||
Die Druckknöpfe auf der Spacemouse werden durch je ein boolsches eventOut Feld der
Form buttonN dargestellt, wobei N eine ganze Zahl ist. Es sei M die Anzahl der tatsächlich
auf dem Gerät vorhandenen Knöpfe. Dann sind nur die Felder button1 bis buttonM
aktiv, die Felder ab buttonM+1 bleiben stumm. Es werden über diese Felder nur dann
Werte an die Szene gesendet, wenn diese sich ändern. Der Wert TRUE bedeutet, daß ein
Knopf gedrückt wurde, und FALSE kennzeichnet das Loslassen eines Knopfes. Mit diesen
Feldern kann mit einem Script auf eine Änderung jedes einzelnen Knopfes reagiert werden.
Es ist aber auch möglich, diese Felder direkt an einen anderen Knoten mit einem
boolschen eventIn zu routen. Am Feld numButtons wird die Anzahl M der vorhandenen
Knöpfe angezeigt. Dieses Feld sendet seinen Wert nur in der Initialisierungsphase des
DeviceSensors, d.h. wenn das enabled Feld den Wert TRUE erhält.
Da zu erwarten ist, daß häufig Animationen mit einem Druckknopf ausgelöst werden, und
da diese über ein Feld vom Typ SFTime angestoßen werden müssen, existieren die Felder
buttonNTime. Diese senden die aktuelle Zeit, wenn ihre zugehörigen Druckknöpfe gedrückt
werden. Sie senden jedoch nicht, wenn der Druckknopf wieder losgelassen wird.
Seite 51

Kapitel 6, Repräsentation von Eingabegeräten
Ist für eine Anwendung nur der Zustand einiger Knöpfe wichtig, kann mit buttonBits ein
Bitmuster der Zustände aller Knöpfe abgefragt werden, ohne daß eine Vielzahl von Routen
angelegt werden muß.
Es zeigt sich hier, daß eine Vielzahl von Feldern für den Event Knoten nötig wird, wenn
der Event Knoten so gestaltet wird, daß er bequem verwendet werden kann, d.h. wenn
ein dazwischen geschalteter Script Knoten möglichst vermieden werden soll. Dies ist
jedoch keine Schwäche des DeviceSensor Ansatzes, sondern eine von VRML an sich. Eine
angebrachte Lösung wäre hier eine Erweiterung des ROUTE Statements z. B um arithmetische
Ausdrücke, so daß Typkonvertierungen ohne Zwischenknoten möglich wären. Dieser
Ansatz würde die Mächtigkeit von VRML generell erhöhen, und dessen Lesbarkeit und
bequeme Nutzung steigern. Die Wirkung der buttonNTime Felder könnte dann durch folgendes
ROUTE Statement erzeugt werden:
ROUTE timestamp(SM.button3) TO Anim.startTime IF SM.button3 == TRUE
Anwendungsbereich
Ursprünglich für die Fernsteuerung von Raumfahrzeugen an der DLRG (Deutsche Luft
und Raumfahrtgesellschaft) entwickelt, wird die Spacemouse vorwiegend im CAD Bereich
(Computer Aided Design) und zur Modellierung von 3D Objekten verwendet. Hier bietet
sie geübten Anwendern ein exzellentes Werkzeug, um Objekte in allen Freiheitsgraden zu
bewegen, oder um auf einfache Weise das Modell aus allen Richtungen betrachten zu
können. Wegen ihres durch die präzise Technik verursachten hohen Preises hat sich dieses
Eingabegerät im Konsumerbereich nicht durchgesetzt.
Implementierung
Es liegt eine Implementierung dieses Event Knotens für die Spacemouse vor. Jedoch
werden die Felder buttonNTime aus Zeitgründen nicht unterstützt.
Es hat sich bei dem Versuch, ein Objekt mit der Spacemouse zu bewegen, gezeigt, daß
obwohl die Achse-Winkel Form die in VRML native Form der Repräsentation von Rotationen
ist, die separierten Winkel von rotationYPR leichter in andere Koordinatensysteme
transformiert werden können. Es kann auf rotationYPR die selbe Matrix-Vektor Multiplikation
angewendet werden, die position von einem Koordinatensystem in ein anderes
transformiert.
6.6.3 Joystick
Unter dem Begriff Joystick wird die vermutlich vielfältigste Gruppe von Eingabegeräten
zusammengefaßt. Es soll daher nur eine minimale Knotenbeschreibung gegeben werden,
dafür wird eine Möglichkeit aufgezeigt, wie die für diese Geräte typische Art, Rückkopplung
an den Benutzer zu geben, modelliert werden könnte.
Joysticks gibt es in allen Variationen für nur wenig Geld zu kaufen, da diese durch den
Markt an Computerspielen weite Verbreitung finden. Einfache Joysticks bestehen aus
einem Knüppel, der in zwei Achsen ausgelenkt werden kann, und aus zwei oder vier
Druckknöpfen. Komplexere Ausprägungen sind in der Bauform einem Steuerknüppel eines
bestimmten Flugzeugtyps nachempfunden, und bestehen aus einer Vielzahl von Bedienelementen,
zu denen ein „Hat Switch” für die Wahl der Blickrichtung unabhängig von
der Bewegungsrichtung, entriegelbare Feuerknöpfe, und diverse Schieberegler, z.B. für
die Schubregelung, zählen. Andere Geräte sind an die Domäne der Fahrsimulationen angelehnt
und bestehen aus einem Lenkrad mit Ganghebel, und Pedalen für Kupplung,
Bremse, Gas. Das „Gamepad”[33] ist eine Bedieneinheit, die anstelle eines Steuerknüppels
über vier Taster zur Richtungssteuerung verfügt. Weitere Tasten dienen zum Auslösen
von Programmfunktionen.
Seite 52

Kapitel 6, Repräsentation von Eingabegeräten
Aufwendige Joysticks verfügen über eine Möglichkeit, dem Benutzer Rückkopplung zu
geben. Diese wird oft durch Motoren realisiert, die über ein Getriebe eine Kraft auf den
Knüppel ausüben. Durch Kombination zweier orthogonal angeordneter Motoren kann die
Richtung der erzeugten Kraft kontrolliert werden. Das „Rumblepad”[34] besteht aus zwei
Motoren mit je einer Unwucht, deren Drehungen getrennt voneinander gesteuert werden
können. Dadurch lassen sich Vibrationen erzielen. Aufgrund der Realisierungsform mit
Motoren können zwar keine genauen taktilen Reize wiedergegeben werden, dafür sind
diese Geräte auf dem Konsumermarkt erhältlich.
Modellierung und Diskussion
Die folgende Proto Deklaration beschreibt den Event Knoten für einen Joystick, von dem
nur minimale Eingabemöglichkeiten erwartet werden, der aber eine Möglichkeit für Force-
Feedback besitzt.
PROTO JoyStick
[
eventOut SFVec2f stick
eventOut SFBool button1
eventOut SFBool button2
eventOut SFTime button1Time
eventOut SFTime button2Time
field MFString FF_url
eventIn SFString FF_effect
eventIn SFVec2f FF_amplitude
] {}
Mit den ersten fünf Feldern wird der klassische Joystick mit zwei Freiheitsgraden und zwei
Feuerknöpfen modelliert. Für stick gilt der Wertebereich [-1 .. +1]. Alle mit button beginnenden
Felder sind in Abschnitt 6.6.2 sinngemäß beschrieben.
Die Steuerung des Drehmoments der Motoren eines Joysticks geschieht in Form von Effekten,
die in das Gerät hinuntergeladen und dann ausgelöst werden. Ein Effekt kann
eine abzuspielende Wellenform sein, etwa eine Sägezahn Schwingung, oder ein Satz Parameter
für eine Differentialgleichung. Während mit der Wellenform Vibrationen erzeugt
werden, erzeugen die Parameter der Differentialgleichung die Effekte von Reibung,
Dämpfung und Trägheit. Dieser Mechanismus wird im Zusammenhang mit Joysticks als
Force-Feedback bezeichnet.
Die mit FF_ beginnenden Felder der Art eventIn werden in folgender Weise benutzt, um
derartige Effekte zu erzeugen: Das FF_url Feld enthält einen Verweis auf die entsprechende
Effekt Dateien. Der Browser lädt diese Dateien auf den lokalen Rechner herunter,
so daß die Effekte zur Verfügung stehen, wenn sie ausgelöst werden sollen. In jeder dieser
Dateien sind ein oder mehrere Effekte enthalten, denen jeweils ein Name zugeordnet
ist. Erhält der Event Knoten am FF_effect einen String mit einem gültigen Effektnamen,
so wird dieser Effekt in den Joystick hinuntergeladen und ausgelöst. Werte, die an
FF_amplitude empfangen werden, geben die aktuelle Amplitude des Effektes in den beiden
möglichen Richtungen an.
Anwendungsbereich
Joysticks werden hauptsächlich für Computerspiele verwendet, da mit ihnen die Spielerfigur
sehr leicht durch die Welt des Spieles gesteuert werden kann und Aktionen leicht und
schnell ausgelöst werden können. Das galt schon zu Zeiten, als Spiele noch auf 2D Grafik
basierten. Gerade wegen dieser Echtzeitfähigkeit stellt der Joystick ein exzellentes Hilfsmittel
auch für ernsthafte VR Anwendungen dar. Denn mit dem Joystick können große
Entfernungen sehr leicht zurückgelegt werden, und teilweise verfügen diese über eine
Vielzahl von Bedienelementen für eine vielseitige Steuerung der Navigation.
Seite 53

Kapitel 6, Repräsentation von Eingabegeräten
Implementierung
Die Implementierung des Gerätes „JOYSTICK” wurde exemplarisch für die Felder stick
und button1 bis button4 durchgeführt. Diese Implementierung reicht schon aus, um das
im Kapitel 8 erläuterte Konzept zu evaluieren, das es erlaubt, mehr Freiheitsgrade als auf
dem Eingabegerät vorhanden sind durch Umschalten der Übersetzung von Gerätefreiheitsgraden
auf Bewegungsrichtungen zu kontrollieren. Ein entsprechender Script Knoten
verarbeitet die Signale von stick, button1 und button2 so, daß durch Drücken von
nur zwei Taster mit dem Joystick Bewegungen in allen sechs Freiheitsgraden komfortabel
erzeugt werden können, obwohl das Gerät nur über zwei Freiheitsgrade verfügt.
Der Beweis, daß mit einem DeviceSensor auch Ausgaben erzeugt werden können, wird
mit dem im Rahmen des zweiten Teils dieser Diplomarbeit implementierten Gerät „TCP”
erbracht.
6.6.4 Maus und Tastatur
Das wahrscheinlich älteste Eingabegerät nach der Pionierzeit der Entwicklung der Computer
ist die alphanumerische Tastatur. In den letzten zehn Jahren ist die Maus als zweidimensionales
Zeigegerät hinzugekommen. Da beide Eingabegeräte heute in Verbindung
mit Arbeitsplatzrechnern weit verbreitet sind, werden VRML Browser typischerweise mit
diesen beiden Geräten bedient.
Die typische Konstruktion einer Maus besteht aus einem handtellergroßen Gehäuse, das
über die Schreibtischoberfläche geschoben wird. An der Unterseite befindet sich eine
Kugel, deren Rollbewegungen gemessen und an den Computer gesendet werden. Dort
werden die Bewegungen auf einen Zeiger übertragen, der eine Position auf dem Bildschirm
markiert. Zusätzlich hat die Maus eine oder mehrere Tasten. Wenn diese gedrückt
werden, wird das Objekt, das sich unter dem Zeiger befindet, aktiviert, markiert, oder
eine andere Aktion wird ausgeführt.
Die alphanumerische Tastatur besteht zum Einen aus Tasten, die Buchstaben erzeugen,
so daß Texte geschrieben werden können. Zur Korrektur von Fehlern und zur Navigation
in Texten existieren Funktionstasten, welche die Einfügemarke bewegen oder Steuerfunktionen
auslösen. Sogenannte Umschalttasten ändern die Funktionsweise anderer
Tasten, wenn sie gedrückt sind, während andere Tasten gedrückt werden.
Modellierung und Diskussion
Da Eingaben per Maus und Tastatur sehr stark korreliert sind, werden sie zu einem Gerät
zusammengefaßt. In Anlehnung an die Tatsache, daß beide Eingabegeräte standardmäßig
in einem typischen Computersystem verfügbar sind, wird dieses kombinierte Gerät
„STANDARD” genannt. Da Ereignisse, die mit diesen Beiden Eingabegeräten erzeugt werden,
oft mehr Information enthalten, als mit den Datentypen von VRML ausgedrückt
werden kann, verwendet das Gerät „STANDARD” die zweite der unter 6.5.3 Methoden,
die den Event Knoten als Ganzes vom event Feld des DeviceSensors wegroutet.
Seite 54

Der Event Knoten wird folgendermaßen deklariert:
PROTO Event
[
field SFString type
eventIn SFBool returnValue
field SFVec2f position
field SFVec2f client
field SFInt32 button
field SFInt32 keyCode
field SFString character
field SFBool shiftKey
field SFBool ctrlKey
field SFBool altKey
fieldfield
] {}
Kapitel 6, Repräsentation von Eingabegeräten
Bei jedem Ereignis, das mit der Maus oder der Tastatur ausgeführt wird, sendet der DeviceSensor
an seinem event Feld eine Referenz auf den Event Knoten. Das type Feld
dieses Knotens zeigt den Typ des Ereignisses an, das aufgetreten ist. Abhängig davon
sind die Felder position bis data gültig. Über das Feld parameter des DeviceSensor Knotens
kann eine Liste von Ereignissen angegeben werden, die eine Anwendung erhalten
möchte. Der DeviceSensor sendet nur dann Ereignisse, wenn der zugehörige Wert für das
type Feld in dieser Liste enthalten ist. Ist das Feld parameter leer, erhält die Anwendung
alle Ereignisse.
Das Feld returnValue ist als einziges ein eventIn Feld. Wenn der DeviceSensor den Event
Knoten sendet, hat dieses den Wert TRUE. Die Anwendung kann für jedes Ereignis, das
sie erhält, separat entscheiden, ob sie dem Browser erlaubt, dieses zu verarbeitet. Dadurch
können ganz gezielt bestimmte Funktionen des Browsers deaktiviert werden.
Die Folgenden Tabelle geben an, welche Ereignisse für das Gerät „STANDARD” generiert
werden.
Maus:
„mousedown” Maustaste wurde gedrückt
„mouseup” Maustaste wurde losgelassen
„dblclick” Maustaste wurde zweimal kurz hintereinander gedrückt
„mousemove” Maus wurde bewegt
„mousewheel” Das Mausrad wurde gedreht
Bei diesen Ereignissen sind die Felder position, client und button gültig. In position
steht die Position des Mauszeigers zu dem Zeitpunkt, als das Ereignis erzeugt wurde. Die
Angabe ist auf den Wertebereich [-1 .. +1] normiert. Der Koordinatenursprung befindet
sich in der Mitte des Fensters des VRML Browsers, und die positiven Richtungen zeigen
nach rechts und oben. Das Feld client enthält ebenfalls die Koordinaten des Mauszeigers,
jedoch sind diese Angaben nicht normierte Pixel Koordinaten. Diese eignen sich
besser, wenn ein Navigationsparadigma implementiert werden soll, da ihr Maßstab nicht
von der Fenstergröße abhängt. Der Koordinatenursprung von client liegt in der linken
oberen Ecke des Fensters, und die Werte wachsen nach rechts beziehungsweise nach
unten. Das Feld button gibt in Form eines Bitmusters an, welche Maustaste gedrückt
wurde. Die Linke Maustaste wird mit dem Wert 1 markiert, die rechte mit 2, die mittlere
mit 4, usw.
Seite 55

Kapitel 6, Repräsentation von Eingabegeräten
Tastatur:
„keydown” Taste wurde gedrückt
„keyup” Taste wurde losgelassen
„character” Taste, die ein druckbares Zeichen erzeugt, wurde gedrückt
Erhält eine Anwendung das Ereignis „keydown” oder „keyup”, dann ist das Feld keyCode
gültig. Dieses Feld enthält einen Tastencode nach der DOM Spezifikation[21]. Das „keydown”
Ereignis zeigt an, wann eine Taste gedrückt wird, und „keyup” zeigt an, wann eine
Taste losgelassen wird. Diese Ereignisse zeigen sowohl alphanumerische Tasten als auch
Tasten mit Steuerfunktion als auch Umschalttasten an.
Sollen Texte in die VRML Anwendung eingegeben werden, eignen sich diese beiden Ereignisse
nicht. Zum einen gibt der Code einer Taste keinen Aufschluß darüber, welchem
Zeichen diese Taste zugeordnet ist, und zum Anderen werden diese Tasten durch Umschalttasten
nicht modifiziert. Für diesen Fall existiert das Ereignis „character”. Es wird
nur für solche Tasten gesendet, die ein druckbares Zeichen ergeben. Erhält eine Anwendung
dieses Ereignis, ist das Feld character gültig und enthält das eingegebene Zeichen
in Stringform. Zudem wird dieses Ereignis wiederholt gesendet, wenn eine Taste längere
Zeit gedrückt wird.
Die Felder shiftKey, ctrlKey und altKey enthalten bei allen Ereignissen gültige Werte.
Sie geben den Zustand der Umschalttasten ‚Shift’, ‚Strg’, bzw. ‚Alt’ an. Diese werden in
graphischen Benutzungsoberflächen häufig zur Modifikation auch der Mausfunktionen
verwendet. Durch diese drei Felder ist diese Funktion auch für VRML Anwendungen verfügbar.
Implementierung
Die Unterstützung für Maus und Tastatur wurde von Blaxxun Mitarbeitern selbst (Thomas
Volk und Holger Grahn) entworfen und implementiert, nachdem der erste Teil dieser Diplomarbeit
abgeschlossen war. Da das Betriebssystem Windows Maus- und Tastaturereignisse
nur direkt an das Fenster einer Anwendung sendet, wurde das Gerät „Standard”
als fester Bestandteil des Browsers programmiert.
6.6.5 TCP Verbindungen
Das Gerät „TCP” zeigt, daß mit dem DeviceSensor neben Ein- und Ausgabegeräten auch
abstrakte Geräte modelliert werden können. Es modelliert eine Netzwerkverbindung zu
einem anderen Rechner. Eine Implementierung dieses Gerätes liegt vor, da sie im zweiten
Teil dieser Arbeit zur Anbindung existierender Programmodule benötigt wird. Abschnitt
8.5.3 beschreibt seine Verwendung.
Seite 56

Kapitel 6, Repräsentation von Eingabegeräten
Modellierung und Diskussion
Folgende Felder seien für die Modellierung einer Netzwerkverbindung vorgeschlagen:
PROTO TCP
{
eventOut SFString lineReceived
eventOut MFString wordsReceived
eventIn SFString lineToSend
eventIn MFString wordsToSend
}
DeviceSensor
{
device "TCP"
parameter "listen=1234" # oder "connect=hostname:1234"
}
Mit dem Feld parameter des DeviceSensor wird festgelegt, ob der DeviceSensor als Server
oder als Client fungieren soll. Hat parameter einen Wert der Form "listen=1234", so
übernimmt der DeviceSensor die Rolle des Servers und wartet auf dem Port mit der angegebenen
Nummer auf eine eintreffende Verbindung. Bei einem Wert der Form "connect=hostname:1234"
übernimmt der DeviceSensor die Rolle des Client und versucht,
eine Verbindung zu dem angegebenen Host Namen auf dem angegebenen Port aufzubauen.
Das isActive Feld des DeviceSensor Knoten zeigt an, ob eine Verbindung zu einem Client
bzw. Server besteht, und mit dem enabled Feld am DeviceSensor kann eine bestehende
Verbindung abgebrochen und neu aufgebaut werden.
Das TCP Gerät unterstützt textbasierte Verbindungen. Jede empfangene Zeile erzeugt ein
Ereignis an lineReceived und eines an wordsReceived. Erhält der Event Knoten ein Ereignis
an lineToSend oder an wordsToSend, wird daraus eine Textzeile gebildet und über die
Verbindung gesendet.
Bei jeder empfangenen Zeile Text wird die Zeichenkombination CR LF, die im Internet
üblicherweise das Ende einer Zeile markiert, entfernt und der Text der Zeile an
lineReceived in die Szene gesendet. Zusätzlich wird eine Liste aller durch White Spaces
getrennten Worte erzeugt und über wordsReceived an die Szene weitergegeben, so daß
die Zeile in der Szene als Array von Worten erscheint. Somit kann die Anwendung die aus
der Verbindung erhaltene Information als Folge von Zeilen verarbeiten, wenn sie
lienReceived auswertet, oder auch ein Protokoll implementieren, das zusammengehörige
Information als eine Gruppe von Worten innerhalb einer Zeile darstellt, ohne daß sich der
VRML Code mit dem Parsen solcher Zeilen beschäftigen muß.
In der Sende-Richtung sind ebenfalls beide Formen der Verarbeitung von Information
möglich. Strings, die an lineToSend von der Szene an den Event Knoten gesendet werden,
werden um die Zeichenkombination CR LF zu einer vollständigen Zeile erweitert und
in die Verbindung geschrieben. Ein an wordsToSend aus der Szene erhaltenes Array von
Strings wird mit Leerzeichen zwischen jedem Wort und mit CR LF am Ende zu einer Zeile
kombiniert und in die Verbindung gesandt.
Seite 57

Kapitel 6, Repräsentation von Eingabegeräten
Anwendungsbereich
Das „TCP” Gerät wird hauptsächlich in dem in Kapitel 8 entwickelten Prototypen eines
Multimodalen Bediensystems zur Anbindung der semantisch höherwertigen Modalitäten
und der Integrator Komponente verwendet. Generell könnte das „TCP” Gerät in zwei
Szenarios verwendet werden:
• zwei VRML Welten miteinander verbinden, und so den Mechanismus der Route erweitern
• von einer VRML Welt direkten Zugriff auf Netzwerkserver zu erlangen
Das Szenario, den Mechanismus der Route zu erweitern ist in der vorliegenden Form mit
dem Nachteil behaftet, daß Netzwerkadressen in der VRML Welt fest angegeben werden
müssen. Für eine generelle Einsetzbarkeit müßte das „TCP” Gerät um ein abstraktes
Adressierungsschema, sowie um ein Sicherheitskonzept erweitert werden.
an dieser Stelle erweitert werden, sowie
Implementierung
Die Implementierung des „TCP” Gerätes unterstützt die Felder lineReceived, wordsReceived
und lineToSend, jedoch nicht wordsToSend.
Seite 58

7 Steuerung der N avigation
Kapitel 7, Steuerung der Navigation
Navigation in virtuellen 3D Szenarien zu implementieren bedeutet für eine Anwendung,
Benutzereingaben zu verarbeiten und in Navigationsbefehle umzuwandeln, um diese an
den Browser zur Ausführung zu senden. Der Zugriff auf Benutzereingaben ist durch den
im letzten Kapitel behandelten DeviceSensor geregelt. In diesem Kapitel wird ein Satz
von Knoten entwickelt, die geeignet sind, Navigationsinformation mit dem Browser auszutauschen.
7.1 Anforderungen an Knoten für die Navigation
Soll die Implementierung von Navigationsparadigmen ermöglicht werden, die an die
Bedürfnisse einer Anwendung anpassbar sind, muß ein Browser folgende Funktionalitäten
anbieten:
• Unterstützung geschwindigkeitsorientierter Eingabegeräte
• Unterstützung positionsorientierter Eingabegeräte
• Unterstützung referenzierender Navigation
• Unterstützung diskreter Navigation
• Kontrolle über grundlegende Navigationsparameter
• Kontrolle des Third Person Modus
Damit durch die Navigationsknoten ein hohes Maß an Mächtigkeit erzielt wird, sollen folgende
Designkriterien zugrunde liegen:
• Die neuen Knoten sollen sich mit der Wirkungsweise bestehender Knoten nicht
widersprechen. Durch diese Forderung können Navigationsmodule programmiert
werden, die unabhängig von den im NavigationInfo Knoten festgelegten Rahmenbedingungen,
und dadurch unabhängig von der Welt, in der sie eingesetzt
werden, funktionieren.
• Es soll ein modulares Programmierschema unterstützt werden. Diese Forderung
erlaubt, Navigationsmodule für verschiedene Eingabegeräte unabhängig voneinander
zu programmieren und zu benutzen.
• Die zur Verfügung gestellte Funktionalität soll in Form von elementaren Funktionen
angeboten werden, die vom Autor kombiniert werden können. Das erhöht die
Mächtigkeit der zur Verfügung gestellten Funktionalität.
7.1.1 Unterstützung gesch windigkeitsorientierter Eingabegeräte
Die Unterstützung geschwindigkeitsorientierter Eingabegeräte erfordert eine Möglichkeit,
Bewegungsgeschwindigkeiten in beiden Richtungssystemen anzugeben. Ein Script Knoten
kann die Auslenkungen des Eingabegerätes interpretieren und in Geschwindigkeitswerte
umrechnen. Diese Umrechnung umfaßt das Skalieren mit einem Faktor und die
Übersetzung der Freiheitsgrade des Eingabegerätes in die entsprechenden Richtungen.
Da Geschwindigkeiten von dem aktuellen Zustand eines Eingabegerätes abhängen, können
diese nicht vorab gesetzt werden, so daß Felder der Art eventIn vorhanden sein
müssen. Da jedes der beiden Richtungssysteme sechs Freiheitsgrade umfaßt, müssen
zwölf Werte auf das Typsystem von VRML übertragen werden:
eventIn SFVec3f speedXYZ
eventIn SFVec3f speedYPR
eventIn SFVec3f speedOPR
eventIn SFVec3f speedABR
Seite 59

Kapitel 7, Steuerung der Navigation
Die Felder speedXYZ und speedYPR akzeptieren Geschwindigkeiten des SIXDOF Richtungssystems,
und speedOPR und speedABR akzeptieren Geschwindigkeiten aus EXAMINE. Setzt
man eine oder mehrere ihrer Komponenten auf einen von 0 verschiedenen Wert, so wird
der Avatar mit der angegebenen Geschwindigkeit in die entsprechenden Richtungen bewegt,
bis diese Werte geändert oder auf 0 gesetzt werden. Im Folgenden werden diese
Felder mit Geschwindigkeitsfelder bezeichnet.
7.1.2 Unterstützung positio nsorientierter Eingabegeräte
Positionsorientierte Eingabegeräte erzeugen eine Serie von Positionen. Diese können
genauso gut als eine Serie von Positionsdifferenzen repräsentiert werden. Positionsdifferenzen
haben gegenüber reinen Positionen den Vorteil, daß mehrere solcher Ströme, die
von verschiedenen Quellen stammen, durch einfache Addition zu einem Strom vereinigt
werden können. Es besteht auch keine Notwendigkeit, Bezugspunkte zu definieren.
eventIn SFVec3f stepXYZ
eventIn SFVec3f stepYPR
eventIn SFVec3f stepOPR
eventIn SFVec3f stepABR
Diese Felder akzeptieren Positionsdifferenzen entlang der Richtungen beider Richtungssysteme
(stepXYZ, stepYPR für SIXDOF und stepOPR, stepABR für EXAMINE). Ereignisse, die
an diesen Feldern empfangen werden, bewegen den Avatar um die angegebenen
Schrittweiten in die jeweilige Richtungen. Im Gegensatz zu den Geschwindigkeitsfeldern,
gelten diese nicht, bis sie durch neue Werte widerrufen werden, sondern jeder Wert, den
sie als VRML Ereignis erhalten, wird einmal in der zugehörigen Richtung zur aktuellen
Avatarposition hinzuaddiert. Diese Felder werden im Folgenden mit positionsorientierte
Felder bezeichnet.
7.1.3 Unterstützung refere nzierender Navigation
Referenzierende Navigation bedeutet, daß der Benutzer einen Punkt in der Szene auswählt
und eine Bewegung dorthin auslöst. Die Interpretation der vom Eingabegerät erhaltenen
Signale ist geräte- und anwendungsabhängig. Deshalb muß sie von der Anwendung
durchgeführt werden. Ein Navigationsknoten sollte Felder enthalten, die eine Viewpoint-Animation
auslösen, wenn sie ein Ereignis mit einer Position als Wert erhalten:
eventIn SFVec3f moveTo
eventIn SFVec3f orientTo
eventIn SFVec3f beamTo
exposedField SFFloat duration 2
eventOut SFBool isAnimating
Die Felder moveTo und orientTo lösen eine verschiebende und eine drehende Viewpoint-
Animation aus, die überlagert werden können. Wenn moveTo eine Position erhält, wird der
Avatar an diese Position verschoben. Erhält orientTo eine Position, wird der Avatar so
gedreht, daß er auf den angegebenen Punkt blickt. beamTo kann anstelle von moveTo und
orientTo verwendet werden. Eine an beamTo gesandte Position verschiebt und dreht den
Avatar so, daß der angegebene Punkt gut sichtbar wird. Die entsprechende Position und
Orientierung muß der Browser selbst finden.
Die Dauer der Animationen wird mit duration festgelegt. Damit die Anwendung auf das
Ende einer Animation warten kann, zeigt isAnimating an, wann eine Animation gestartet
und beendet wird.
Seite 60

7.1.4 Unterstützung diskre ter Navigation
Kapitel 7, Steuerung der Navigation
Diskrete Navigation bedeutet, daß sich der Avatar um eine gewisse Schrittweite in eine
bestimmte Richtung bewegt. Dieser Effekt kann mit den Feldern für positionsorientierte
Eingabegeräte erzeugt werden. Da aber eine sprunghafte Bewegung dem Immersionseffekt
wegen seiner Unnatürlichkeit entgegen wirkt und für den Benutzer als Bewegung
schwer erkennbar ist, sollten Bewegungen der diskreten Navigation als kontinuierliche
Bewegungen für eine kurze Zeit ausgeführt werden. Dies kann mit den Feldern für geschwindigkeitsorientierte
Eingabegeräte erreicht werden, indem eine Bewegungsgeschwindigkeit
gesetzt wird, und nach kurzer Zeit – etwa einer Sekunde – wieder zurück
genommen wird. Aus diesen Gründen sind zusätzliche Felder für diskrete Navigation nicht
notwendig.
7.1.5 Kontrolle über grund legende Navigationsparameter
Der NavigationInfo Knoten (siehe Abschnitt 4.3.2) erlaubt die Angabe einiger Rahmenbedingungen
zur Navigation. Beispielsweise ist es wünschenswert, ein Drehzentrum für
den EXAMINE Modus vorzugeben, da eine automatisierte Suche danach keine triviale
Aufgabe darstellt. Es sollte auch ein Feld geben, das die Kontrolle des Dritte Person Modus
erlaubt, und es sollte angegeben werden können, ob in der Welt dem Lot-Vektor eine
besondere Bedeutung zukommt.
Neben dem Setzen von Werten müssen Module, die Navigation implementieren, über
einige Werte informiert werden. Deshalb sollte ein Sensor Knoten diese zur Verfügung
stellen. Hier interessieren insbesondere der momentan eingestellte Navigationsmodus,
Information über auftretende Kollisionen des Avatars mit Geometrie und die Position der
virtuellen Kamera im Third Person Modus. Der momentan eingestellte Navigationsmodus
erlaubt es anwendungsunabhängigen Modulen, den mittels NavigationInfo oder über das
Benutzungsinterface des Browsers eingestellten Navigationsmodus zu implementieren.
Hat die Anwendung Information über Kollisionen zur Verfügung, kann sie diese an den
Benutzer weitergeben. Mit der Information über den Ort der Kamera können On-Screen-
Displays 9 oder andere von der Blickrichtung abhängige Effekte erzeugt werden. Im Gesichtsfeld
feststehende Geometrie wird bisher mit Hilfe des ProximitySensors realisiert.
Da der ProximitySensor die Position des Avatars widerspiegelt, wird an den
ProximitySensor gekoppelte Geometrie im Third Person Modus in der Nähe des Kopfes
des Avatars plaziert.
Eine hilfreiche Funktion, die ein Navigationsinterface dem Benutzer zur Verfügung stellen
sollte ist die Möglichkeit, sich einfach aufrichten zu können, wenn sich der Benutzer in
eine ungewollte Schräglage gebracht hat. Ebenso sollte das Drehzentrum für den
EXAMINE Modus wählbar sein, was durch eine Zeigegeste realisiert werden könnte. Die
Beispielimplementation eines Navigationsmoduls für die Spacemouse hat gezeigt, daß für
manche Eingabegeräte die Sonderbehandlung des Lot-Vektors nachteilig ist. Deshalb
sollte diese Eigenschaft, obwohl eine Eigenschaft der Welt, auch für jedes Navigationsmodul
individuell einstellbar sein.
Wenn bei der Fortbewegung in realen Umgebungen ein Hindernis den Weg versperrt,
dann erfährt man das sofort durch einen entsprechenden taktilen Sinnesreiz. Meistens
9 Ein On-Screen-Display besteht aus Objekten, die sich immer an einer festen Position des Bildschirms
(bzw. des Gesichtsfeldes des Benutzers) befinden. Auf diese Weise kann ein graphisches
Benutzungsinterface realisiert werden.
Seite 61

Kapitel 7, Steuerung der Navigation
wird man das Objekt schon vorher sehen und den Zusammenstoß vermeiden. In virtuellen
Umgebungen können Kollisionen optisch nicht so leicht erkannt werden, weil die Darstellungsqualität
das Einschätzen von Entfernungen erschwert, und weil insbesondere bei
bildschirmorientierten Arbeitsplätzen das Blickfeld stark eingeschränkt ist. Ohne einen
anderen Hinweis auf den Umstand einer Kollision mit einem Objekt wirkt eine Kollision
genauso, als ob überhaupt keine Bewegung möglich wäre. Daher sollte der oben genannte
Sensor Knoten das Auftreten einer Kollision anzeigen, so daß diese Information
an den Benutzer weitergegeben werden kann. Ungeübte Benutzer, die mit dem Umgang
eines Eingabegerätes noch nicht vertraut sind, werden davon besonders profitieren.
7.2 Knotenspezifikatio n
Die erläuterten Forderungen ergeben eine Anzahl von Feldern, die in drei Kategorien eingeteilt
werden können:
• Felder, welche die Welt beschreiben, und somit globalen Charakter haben.
Solche Felder sollten Teil eines bindbaren Knotens sein, da dies der Mechanismus
ist, der in VRML globale Eigenschaften einer Szene verwaltet.
• Felder, die Information vom Browser an die Szene liefern.
Solche Felder machen einen Knoten zu einem Sensor Knoten. Für einen Sensor
Knoten ist der Mechanismus des Bindens nicht adäquat. Er sollte von der Anwendung
durch ein boolsches Feld je nach Bedarf aktivierbar sein.
• Felder, die von einem Navigationsmodul benutzt werden, um Befehle an den
Browser zu senden. Diese Felder kommunizieren dynamische Werte, die sich
schnell ändern und nicht vorhersagbare Ereignisse zum Browser. Da mehrere
voneinander unabhängige Module die Möglichkeit haben sollten, diese Felder
gleichzeitig zu benutzen, sollten diese Felder nicht Teil eines bindbaren Knotens
sein.
Gemäß dieser Kategorien werden drei Knoten definiert:
• NavigationInfo2
Die NavigationInfo2 ist eine Erweiterung des NavigationInfo Knotens. Die Felder
sollten eigentlich der NavigationInfo hinzugefügt werden. Da ein Nachträgliches
Hinzufügen von Feldern zu VRML Knoten eine Anwendung daran hindern würde,
auf älteren Browsern ausgeführt zu werden, und da Interoperabilität 10 eines der
Designziele von VRML ist, muß ein zweiter Knoten definiert werden.
• NavigationSensor
Der NavigationSensor liefert Ereignisse der Navigation an die Szene. Er kann von
der Welt selbst benutzt werden, oder von einem Navigationsmodul, um auf bestimmte
Zustände zu reagieren.
• Navigator
Die letzte Kategorie enthält die größte Anzahl von Feldern. Da sich aber keine Anwendungsfälle
identifizieren lassen, in denen einige dieser Felder verwendet werden,
die in anderen Anwendungsfällen nicht benutzt werden, ergeben sich keine
scharfen Grenzen für eine Gruppierung, die ein Aufteilen dieser Felder auf mehrere
Knoten sinnvoll machen würde. Die Felder der letzten Kategorie werden daher
alle zum Navigator Knoten zusammengefaßt.
10 Interoperabilität bedeutet, daß eine in VRML Anwendung so geschrieben werden kann, daß sie auf
Browsern unterschiedlicher Hersteller, und auf älteren Versionen eines Browsers ausgeführt wird. In
der Praxis ist dieses Ziel jedoch nicht erreicht.
Seite 62

7.2.1 Der Knoten Navigatio nInfo2
Kapitel 7, Steuerung der Navigation
Der NavigationInfo2 Knoten erweitert den NavigationInfo Knoten um einige wichtige
Felder, die globale Aspekte der Welt bezüglich Navigation beschreiben.
NavigationInfo2
{
exposedField SFBool free FALSE
exposedField SFVec3f examineCenter 0 0 0
exposedField SFBool autoExaCenter TRUE
exposedField SFVec3f cameraOffset 3 0 -0.1
exposedField SFBool thirdPersonMode FALSE
eventIn SFBool set_bind
eventOut SFBool isBound
und alle anderen Felder von NavigationInfo
}
free:
Das Feld free gibt an, ob in der Welt ein ausgeprägter Lot-Vektor vorhanden ist. Wenn
free gesetzt ist, sind alle Richtungen gleichberechtigt. In den meisten Welten kann free
jedoch auf seinem Defaultwert FALSE belassen werden.
examineCenter und autoExaCenter:
Mit autoExaCenter wird kontrolliert, ob sich der Browser bei Bewegungen im EXAMINE
Modus das Drehzentrum selbst suchen soll (TRUE) oder ob er den in examineCenter angegebenen
Wert verwenden soll (FALSE). Diese beiden Felder werden immer dann ausgewertet,
wenn die NavigationInfo2 gebunden wird, und wenn eines von beiden Feldern
ein Ereignis erhält. Unabhängig von autoExaCenter wird ein neues Drehzentrum gesetzt,
wenn das set_examineCenter Feld des Navigator Knotens ein Ereignis erhält. Das Bezugskoordinatensystem
für examineCenter ist das lokale Koordinatensystem der NavigationInfo2.
cameraOffset und thirdPersonMode:
Das Flag thirdPersonMode schaltet in den Third Person Modus um, wenn es gesetzt ist. In
diesem Fall wird ein Avatar angezeigt, und die virtuelle Kamera wird aus dem Avatar
herausbewegt. Abgesehen vom NavigationSensor, dem VisibilitySensor 11 und dem
LOD 12 wird die Szene weiterhin von der Position des Avatars beeinflußt, und nicht von der
Position der virtuellen Kamera. Die Position der virtuellen Kamera wird relativ zum Avatar
mit cameraOffset angegeben. Die Angabe erfolgt im Avatar lokalen Koordinatensystem in
Form von Kugelkoordinaten. Die erste Komponente ist der Abstand von der Avatar Position,
die anderen beiden sind Azimut und Elevation, gemessen in rad. Die virtuelle Kamera
sei immer so ausgerichtet, daß sie in Richtung des Avatars sieht. Die angegebenen Werte
sind Richtwerte. Der Browser kann diese variieren, wenn z.B. ein Objekt die Sicht auf den
Avatar verhindert, oder um eine gleichmäßige Kameraführung zu erreichen. Unterstützt
der Browser den Third Person Modus nicht, kann er beide Felder ignorieren und sich so
verhalten als wäre thirdPersonMode immer FALSE.
11
Stellt fest ob ein Objekt sichtbar ist.
12
LOD = Level of Detail. Der LOD Knoten schaltet entfernungsabhängig zwischen unterschiedlich detaillierten
Repräsentationen eines Objektes um.
Seite 63

Kapitel 7, Steuerung der Navigation
set_bind, isBound, ...:
Die NavigationInfo2 ist ein bindbarer Knoten, da sie globale Aspekte der Welt beschreibt.
Weil sie eine Erweiterung der NavigationInfo ist, sollten beide Knoten auf dem
selben Stack verwaltet werden. Damit die NavigationInfo2 eine NavigationInfo ersetzen
kann, enthält sie alle Felder, die auch an NavigationInfo vorhanden sind. Ist der Stack
leer, oder ein NavigationInfo Knoten gebunden, werden für die Felder der NavigationInfo2
deren Defaultwerte.
7.2.2 Der Knoten Navigatio nSensor
Der NavigationSensor Knoten zeigt Ereignisse an, welche die Navigation betreffen.
NavigationSensor
{
exposedField SFBool enable
eventOut MFString navigationType
eventOut SFBool collided
eventOut SFBool cameraPositon
eventOut SFBool cameraOrientation
}
enable:
Dieses Flag kontrolliert den Aktivierungszustand des NavigationSensor. Die anderen Felder
des Knotens senden nur dann Werte, wenn enabled gesetzt ist.
navigationType:
Das Feld navigationType zeigt in seinem ersten Arrayelement den momentan verwendeten
Navigationsmodus an. Falls der Browser über die Standardmodi "WALK", "FLY",
"EXAMINE" und "NONE" hinausgehende Navigationsmodi unterstützt, und ein solcher aktiv
ist, enthält das erste Arrayelement diesen Namen, und das zweite den diesem Modus am
nächsten kommenden Modus. Ist dieser Modus auch kein Standard Modus, setzt sich
diese Regel fort, bis das letzte Element einen der vier Standard Modi enthält. Folglich ist
das erste Arrayelement von navigationType immer einer der im type Feld der aktiven
NavigationInfo oder NavigationInfo2 enthaltenen Modi, es sei denn type enthält den
Pseudomode "ANY". Das Feld navigationType kann seinen Wert senden, wenn eine
NavigationInfo oder NavigationInfo2 gebunden wird, wenn am Benutzungsinterface des
Browsers ein Navigationsmodus gewählt wird, oder wenn der NavigationSensor aktiviert
wird.
collided:
An collided wird angezeigt, wenn der Avatar bei seiner Bewegung durch die Szene mit
Objekten zusammenstößt. Es sendet bei jedem Zusammenstoß einen später näher erläuterten
Wert. Versucht der Benutzer über eine gewisse Zeitperiode hinweg, sich in ein
Objekt hinein zu bewegen, sendet das collided Feld laufend Werte. Der Wert, den dieses
Feld sendet, ist dazu geeignet, einen Force-Feedback Effekt zu erzeugen. D.h. es ist ein
der Bewegung entgegengesetzter Vektor. Das kann die negative Bewegungsrichtung im
Augenblick der Kollision sein, der Normalenvektor der Oberfläche des Objektes am Ort
der Berührung, oder ein berechneter Reflektionsvektor. Steht solche Information nicht
zur Verfügung, kann auch der Null Vektor (0, 0, 0) gesendet werden. Bezugskoordinatensystem
für dieses Feld ist das Avatar lokale Koordinatensystem. Ist die Kollisionserkennung
deaktiviert, sendet auch collided keine Werte.
Seite 64

Kapitel 7, Steuerung der Navigation
cameraPosition und cameraOrientation:
Diese Felder zeigen die Position und die Ausrichtung der virtuellen Kamera an. Im First
Person Modus ist das die Position und Orientierung, die auch ein ProximitySensor liefert.
Im Third Person Modus zeigen diese Felder die Position und Orientierung der Virtuellen
Kamera an. Wenn sich der Browser nicht genau an die im cameraOffset Feld des NavigationInfo2
Knotens angegebenen Werte hält, werden an diesen Feldern die tatsächlichen
Positionen angezeigt. Bezugssystem ist das lokale Koordinatensystem des
NavigationSensor.
7.2.3 Der Knoten Navigato r
Der Navigator Knoten stellt eine Vielzahl von Feldern zur Verfügung, die es der Anwendung
ermöglichen, die Bewegungen des Avatars durch die virtuelle Welt zu steuern. Der
Knoten ist bewußt kein bindbarer Knoten, weil dadurch Navigationsmodule geschrieben
werden können, die unabhängig von der sonstigen Welt agieren und als EXTERNPROTO
zu einer Welt hinzugeladen werden können. Es können mehrere Navigator Knoten gleichzeitig
aktiv sein. Deren Bewegungen werden additiv überlagert und bei Viewpoint-
Animationen ersetzen die später ausgelösten die vorhergehenden, wenn diese noch nicht
beendet sind.
Navigator
{
exposedField SFBool enabled TRUE
exposedField SFBool disableDefault FALSE
eventIn SFVec3f speedXYZ eventIn SFVec3f stepXYZ
eventIn SFVec3f speedYPR eventIn SFVec3f stepYPR
eventIn SFVec3f speedOPR eventIn SFVec3f stepOPR
eventIn SFVec3f speedABR eventIn SFVec3f stepABR
exposedField SFBool free FALSE
eventIn SFVec3f set_examineCenter
eventIn SFVec3f moveTo
eventIn SFVec3f orientTo
eventIn SFVec3f beamTo
exposedField SFFloat duration 2
eventOut SFBool isAnimating
eventIn SFTime straighten
eventIn SFTime balance
exposedField SFFloat enableFiltering TRUE
}
Die Wirkungsweise des Navigator Knoten wird von dem in NavigationInfo eingestellten
Navigationsmodus nicht beeinflußt. Jedoch ist es die Aufgabe des den Navigator steuernden
Script Knotens, diesen mit einem NavigationSensor abzufragen und die Signale vom
Eingabegerät entsprechend zu interpretieren. Insbesondere wenn der Modus "NONE" eingestellt
wurde, bleibt die Wirkungsweise des Navigator Knoten erhalten. Die Bedeutung
von "NONE" ist, daß jegliche Browser spezifische Navigation abgeschaltet wird, und die
Navigation von der Anwendung übernommen wird.
enabled und disableDefault:
Wenn enabled den Wert TRUE hat, ist der Navigator aktiviert, andernfalls deaktiviert. Ein
deaktivierter Navigator ignoriert alle Ereignisse, die er an seinen Feldern erhält und sendet
keine Information an isAnimating. Ein aktivierter Navigator reagiert auf seine Felder
wie nachfolgend beschrieben.
Seite 65

Kapitel 7, Steuerung der Navigation
speedXYZ, speedYPR, speedOPR und speedABR:
Die mit speed beginnenden Felder stellen die Gruppe der Geschwindigkeitsfelder dar. Sie
akzeptieren Geschwindigkeitswerte in den Richtungssystemen SIXDOF (speedXYZ,
speedYPR) und EXAMINE (speedOPR, speedABR). Als Grundlage für die Richtungssysteme
dient das Koordinatensystem, in dem sich der aktuell gebundene Viewpoint befindet.
Setzt man eine oder mehrere ihrer Komponenten auf einen von 0 verschiedenen Wert, so
wird der Avatar mit der angegebenen Geschwindigkeit in die entsprechenden Richtungen
bewegt, bis diese Werte geändert oder auf 0 gesetzt werden. Die Bewegungen unterliegen
den Begrenzungen und Modifikationen durch Kollisionserkennung und Gravitationssimulation,
sofern diese aktiviert sind.
speedXYZ: Die Komponenten x, y, z dieses Feldes definieren die Bewegungsgeschwindigkeit
entlang der Richtungen right, up und (gemäß einem Rechtssystem) der negativen
forward Richtung. Die Werte werden mit dem im NavigationInfo Knoten angegebenen
speed Wert, der die durchschnittliche Fortbewegungsgeschwindigkeit angibt multipliziert.
Als Maßeinheit wird m/s verwendet.
speedYPR: Dieses Feld definiert Drehungen um die eigene Achse. Die ersten beiden
Komponenten drehen in die Richtungen d und pitch und ändern so die Blickrichtung. Die
dritte Komponente dreht in roll Richtung und verändert die seitliche Neigung der Sicht
auf die Szene. Die Maßeinheit ist rad/s.
speedOPR: Damit kann in einem EXAMINE Modus das Objekt gedreht werden. Die Komponenten
drehen in ω, φ und ρ. Die ersten beiden Komponenten steuern so die Richtung,
aus welcher der Benutzer das Objekt sieht, während die dritte Komponente das Objekt
auf dem Bildschirm bzw. im Gesichtsfeld ausrichtet. Alle drei Komponenten werden in
rad/s gemessen.
speedABR: Dieses Feld beschreibt die translatorischen Richtungen A, B und R des
EXAMINE Richtungssystems. Damit kann das Objekt auf dem Bildschirm bzw. im Gesichtsfeld
verschoben werden, um es z.B. zu zentrieren, oder es kann näher herangeholt
oder weiter entfernt werden. Alle drei Geschwindigkeiten werden als Faktor angegeben,
der mit dem Abstand vom Avatar zum Drehzentrum multipliziert wird. Ist der Avatar z.B.
10 Meter vom Drehzentrum entfernt, und hat speedABR den Wert (0,1 0,2 0,3), so bewegt
sich das Objekt mit einer Geschwindigkeit von 1 m/s nach rechts, 2 m/s nach oben
und 3 m/s auf den Avatar zu. Die Maßeinheit ist 1/s.
stepXYZ, stepYPR, stepOPR und stepABR:
Felder, deren Name mit step beginnt werden zur Gruppe der Positionalen Felder zusammengefaßt.
Ihre Semantik ist ähnlich den Geschwindigkeitsfeldern. So wirken beispielsweise
die Komponenten von stepXYZ nach rechts, oben und hinten, und die Komponenten
von stepOPR wirken rotierend in die Richtungen ω, φ und ρ. Aber anders als diese erhalten
die positionalen Felder keine Geschwindigkeitswerte, sondern Positionsdifferenzen, die zu
der gegenwärtigen Position und Orientierung des Avatars in der jeweiligen Richtung hinzuaddiert
werden. Während Ereignisse, die an Geschwindigkeitsfeldern erhalten werden,
so lange gelten, bis diese durch ein neues Ereignis widerrufen werden, stellen an den
positionalen Felder erhaltene Ereignisse eine einmalige Verschiebung dar. Die Maßeinheiten
der positionalen Felder sind die mit 1 s multiplizierten Einheiten der entsprechenden
Geschwindigkeitsfelder:
[stepXYZ] = m; [stepYPR] = rad; [stepOPR] = rad; [stepABR] = 1;
free:
Das Feld free dient dazu, die Einstellung des gleichnamigen Feldes am NavigationInfo2
Knoten für den Navigator Knoten zu überschreiben. Ist free nicht gesetzt, gilt der Wert
des momentan gebundenen NavigationInfo2 Knoten. Wenn free gesetzt ist, gilt für den
Navigator Knoten, an dem es gesetzt ist keine besondere Behandlung des Lot-Vektors.
Seite 66

Kapitel 7, Steuerung der Navigation
set_examineCenter:
Mit set_examineCenter wird das Drehzentrum gesetzt, das für die Richtungen des
Examine Richtungssystems gilt. Obwohl mehrere Navigator Knoten aktiv sein können,
existiert immer nur ein Drehzentrum für alle Navigator Knoten und für die Default Navigation
des Browsers. Das gesetzte Drehzentrum bleibt so lange gültig, bis ein neues
Drehzentrum an einem aktiven Navigator oder mit Hilfe einer NavigationInfo2 gesetzt
wird. Beim Setzen eines Drehzentrums wird die Blickrichtung nicht verändert. Bei nachfolgenden
Drehungen um das Drehzentrum bleibt der Winkel zwischen der Blickrichtung
und der Richtung, unter der das Drehzentrum zu sehen ist, erhalten. Soll mit dem Navigator
Knoten ein Navigationsmodus implementiert werden, bei dem der Benutzer immer
auf das Drehzentrum schaut, muß orientTo die selben Ereignisse wie set_examineCenter
erhalten.
moveTo, orientTo, beamTo und duration:
Mit den drei Feldern moveTo, orientTo und beamTo können Viewpoint-Animationen ausgelöst
werden, und mit duration wird die Dauer der Animationen bestimmt. Es können die
Position und Orientierung unabhängig von einander geändert werden. Mit moveTo wird der
Benutzer an eine vorgebbare Position transportiert, ohne daß die Blickrichtung geändert
wird. Mit orientTo hingegen kann ein Punkt angegeben werden, worauf sich der Avatar
so dreht, daß er in Richtung zu diesem Punkt schaut. Die seitliche Neigung (β) wird dadurch
nicht verändert. Findet gleichzeitig eine durch moveTo und eine durch orientTo
ausgelöste Animation statt, soll der Benutzer am Ende beider Animationen auf das angegebene
Ziel blicken. Dadurch können beide Felder dazu benutzt werden, den Avatar so zu
bewegen, daß er von einem bestimmten Ort aus auf einen bestimmten Punkt schaut.
Das Feld beamTo dient als Alternative zu moveTo und orientTo. Während mit moveTo eine
Position angegeben werden kann, an der sich der Avatar nach der Animation befindet,
beschreibt beamTo eine Position, die der Avatar nach der Animation im Blickfeld haben
soll. Es ist die Aufgabe des Browsers, eine geeignete Position in der Nähe des angegebenen
Punktes und eine passende Orientierung zu finden.
Mit duration wird bestimmt, wie lange die Animationen dauern und ob diese abgebrochen
werden dürfen. Ist duration 0, wird keine Animation ausgeführt und der Avatar
nimmt sofort die neue Position oder Orientierung an. Ist duration von 0 verschieden, gibt
dessen Betrag die Dauer der Animation in Sekunden an und das Vorzeichen bestimmt, ob
diese Animationen abgebrochen werden können. Bei einem positiven Wert werden die
Animationen durch ein anderes Navigationsereignis – d.h. ein nicht verschwindender
Wert eines Geschwindigkeitsfeldes, ein Ereignis an einem positionalen Feld oder das
Auslösen von straighten oder balance – abgebrochen, so daß dieses neue Ereignis ausgeführt
werden kann. Bei negativem duration werden die durch moveTo, orientTo oder
beamTo ausgelösten Animationen fortgesetzt und andere Navigationsereignisse während
dessen ignoriert. Dabei spielt es keine Rolle, ob diese Ereignisse an Feldern eines anderen
Navigator Knotens oder des selben Navigator Knotens auftreten.
Ob eine Viewpoint-Animation abgebrochen wird, bestimmt das Vorzeichen des duration
Feldes an demjenigen Navigator Knoten, an dem die Animation ausgelöst wurde. Unabhängig
von duration jedoch können Ereignisse an moveTo eine laufende moveTo Animation
und Ereignisse an orientTo eine laufende orientTo Animation abbrechen und durch
eine Animation zum neuen Ziel ersetzen. Ebenso können beide Arten von Animation
durch ein Ereignis an beamTo abgebrochen werden. Das Binden oder Unbinden eines
Viewpoint Knoten beendet beide Animationen, wenn der Viewpoint Knoten so
konfiguriert ist, daß damit eine Positionsänderung des Avatars verbunden ist, d.h. wenn
das jump Feld des Viewpoint Knoten gesetzt ist.
Seite 67

Kapitel 7, Steuerung der Navigation
isAnimating:
Das Feld isAnimating zeigt an, wann eine Viewpoint-Animation durchgeführt wird. Am
Anfang der Animation wird TRUE gesendet, und am Ende FALSE. Wenn eine eine laufende
Animation durch eine weitere Animation ersetzt wird, sended isAnimating nur den Wert
TRUE. Es werden nur dann Werte gesendet, wenn der Navigator Knoten aktiviert ist. Das
Feld isAnimating reagiert unabhängig davon, an welchem Navigator Knoten eine Viewpoint-Animation
ausgelöst wird, oder ob sie in Zusammenhang mit einem anderen Mechanismus,
wie z.B. mit dem Viewpoint Knoten, ausgeführt wird. Am Anfang oder Ende
einer Viewpoint-Animation, senden die isAnimating Felder aller aktiver Navigator Knoten
entsprechende Werte.
straighten und balance:
Mit straighten und balance kann eine schräge Lage des Viewpoints wieder ausgerichtet
werden. Gemäß Abb. 5 kann die Abweichung des Avatars von der senkrechten Ausrichtung
durch zwei Winkel α Und β ausgedrückt werden. Ein Ereignis an straighten dreht
den Avatar so, daß beide Winkel 0 werden, und ein Ereignis an balance dreht den Avatar
so, daß nur β zu 0 wird. Durch balance erscheint der Horizont wieder waagerecht, ohne
daß die vertikale Blickrichtung geändert wird. Ein Browser muß die durch beide Felder
ausgelösten Bewegungen ohne Animation ausführen, wenn duration den Wert 0 hat. Ist
duration von 0 verschieden, kann der Browser eine Animation durchführen. Für die Dauer
der Animation soll aber nicht duration verwendet werden, da dies in der Regel eine
viel längere Zeit angibt, als für eine straighten oder balance Animation sinnvoll wäre.
Die Animation soll nicht durch andere Navigationsereignisse wie Setzen einer Geschwindigkeit
oder moveTo beendet werden. Nur das Binden eines Viewpoint, der eine Positionsänderung
des Avatars bewirkt, kann die durch straighten oder balance angestoßenen
Animationen abbrechen.
enableFiltering:
Ein Browser kann möglicherweise die Bewegungen des Avatars mittels einer Filterung
leicht modifizieren, um z.B. weichere Bewegungen zu erzeugen. Wird das enableFiltering
Flag zurückgesetzt, muß diese Funktion für den Navigator Knoten, an dem es gesetzt
ist, abgeschaltet werden.
7.2.4 Abbrechbarkeit von V iewpoint-Animationen
Der Navigator Knoten führt zwei neue Typen von Viewpoint-Animationen ein, so daß
diese in folgende Gruppen eingeteilt werden können:
Typ A: ausgelöst durch das Binden eines Viewpoint Knoten
Typ B: ausgelöst durch die Felder moveTo, orientTo oder beamTo
Typ C: ausgelöst durch die Felder straighten und balance
An jeden dieser Typen werden verschiedene Anforderungen gestellt, ob eine solche Animation
abgebrochen werden soll, wenn während deren Durchführung eine neue Animation
des selben oder eines anderen Typs ausgelöst wird. Wird eine Animation nicht abgebrochen,
bedeutet das ein Ignorieren der zweiten Animation.
Da eventuell auch die durch kontinuierliche Navigation ausgelöste Bewegung eine Viewpoint-Animation
beenden kann, werden solche Bewegungen hier als Typ D „Animationen”
bezeichnet:
Typ D: durch speedXXX und stepXXX ausgelöste kontinuierliche Bewegungen
Seite 68

Kapitel 7, Steuerung der Navigation
Typ A Animationen:
Durch den Viewpoint Knoten ausgelöste Animationen werden häufig von der Anwendung
selbst, d.h. als Reaktion auf bestimmte Bedingungen ausgeführt, oder vom Benutzer
ausgelöst, wenn er eine von der Anwendung vorgegebene Position anwählt. Mit solchen
Animationen sind neben der Positionsänderung noch die Änderung anderer Parameter für
die Navigation verbunden, etwa wenn sich der neu gebundene Viewpoint innerhalb eines
skalierten oder sich bewegenden Koordinatensystems befindet. Aus diesem Grund sollten
solche Typ A Animationen nicht unterbrechbar sein. Da bei Viewpoint-Animationen immer
die vollständige Position und Orientierung festgelegt ist, sollten diese Animationen Vorrang
vor allen anderen Typen von Animationen haben und diese abbrechen.
Typ B Animationen:
Über den Navigator ausgelöste Animationen werden typischerweise vom Benutzer initiiert,
beispielsweise wenn er auf ein Objekt zeigt. Das kann genauso wie die kontinuierlichen
Bewegungen Teil eines rückgekoppelten Systems sein: Der Benutzer reagiert auf
das Gesehene und gibt ein Kommando, das in einer Viewpoint-Animation resultiert. Wenn
diese Animation ausgeführt wird, ändert sich die Darstellung der Welt, worauf der Benutzer
ein neues Kommando gibt. Sei es, daß er es sich anders überlegt hat, oder sein erstes
Kommando korrigiert. In diesem Fall sollte die Ausführung der ersten Animation
durch die Ausführung der zweiten Animation ersetzt werden. Es kann aber auch sein, daß
Typ B Animationen von der Anwendung programmatisch ausgelöst werden, und es für die
Anwendung wichtig ist, daß der Benutzer das Ziel der Animation erreicht. In diesem Fall
kann der Programmierer durch Setzen eines negativen Vorzeichens für duration anzeigen,
daß er den Navigator Knoten für diese Art von Animationen verwendet.
Typ C Animationen:
Das Charakteristische an straighten und balance Animationen ist, daß sie zeitlich sehr
kurz sind, und konzeptionell eine in sich abgeschlossene Funktion des Browsers darstellen.
Etwa in der Form „Richte mich auf!”. Sie sollten deshalb in jedem Fall bis zu ihrem
Ende durchgeführt werden, wenn die nachfolgende Animation den Typen B oder D zuzuordnen
ist. Im Idealfall kann der Browser Typ C Animationen und Typ B oder D Animationen
überlagert ausführen, so daß diese voneinander unabhängig betrachtet werden können.
Folgt auf eine Typ C Animation eine weitere Typ C Animation, entscheidet deren
Kombination, ob die erste fortgesetzt oder durch die zweite ersetzt wird. Denn die balance
Operation ist in der straighten Operation enthalten. Wenn während einer balance
Animation eine straighten Animation ausgelöst wird, so muß als Resultat eine straighten
Animation durchgeführt werden. Bei allen anderen Kombinationen reicht es, die erste
fortzuführen.
Typ D Animationen:
Bewegungen aufgrund kontinuierlicher Navigation sind zwar keine Animationen in dem
Sinne, daß sie nach ihrer Initiierung selbständig ablaufen, doch ist mit der Möglichkeit,
durch solche Bewegungen vorher ausgelöste Viewpoint-Animationen abzubrechen, ein
Problem verbunden, da diese Bewegungen einer Filterung unterliegen können. Zweck
einer solchen Filterung könnte sein, Bewegungsausklänge ein wenig zu glätten, und dadurch
realistischer zu gestalten. Filterung bedeutet aber, daß eine Bewegung nach dem
sie ausgelöst wurde, noch kurze Zeit nachwirkt. Die Simulation von Trägheit 13 kann durch
eine extrem starke, glättende Filterung erreicht werden. Zudem ist es möglich, daß Bewegungen
der diskreten Navigation implementiert werden, indem nach einem Kommando
13 Physikalisch gesehen ist dies aber keine korrekte Berechnung von Trägheit, da diese zum Einen
geschehen müßte, nachdem die Geschwindigkeiten der beiden Richtungssysteme zu Geschwindigkeiten
in den realen sechs Freiheitsgraden vereinigt wurden, und zum Anderen, da für Massenträgheit
andere Differentialgleichungen gelten.
Seite 69

Kapitel 7, Steuerung der Navigation
des Benutzers für kurze Zeit Bewegungen über die Geschwindigkeits- und positionalen
Felder des Navigator Knotens ausgelöst werden.
Da dies dazu führen kann, daß ungewollt Typ B Animationen abgebrochen werden können,
existiert am Navigator ein eventOut isAnimating, das anzeigt, wann eine Typ B
Animation durchgeführt wird. Die Anwendung kann so auf diesen Umstand reagieren,
indem sie das durch Filterung ausgelöste Nachwirken von Bewegungen unterdrückt und
die Erzeugung von Bewegungen der diskreter Navigation beendet, sofern diese Bewegungen
vor der Typ B Animation ausgelöst wurden. Durch diesen Mechanismus wird erreicht,
daß Benutzer Bewegungen sowohl der kontinuierlichen, der diskreten als auch der
referenzierenden Navigation zu jeder Zeit auslösen können, auch wenn noch eine vorher
ausgelöste Bewegung einer anderen Navigationsart durchgeführt wird, und daß dabei
immer die zuletzt ausgelöste Bewegung wirksam wird. Denn das Auslösen einer Bewegung
während noch eine andere Bewegung ausgeführt wird, bedeutet mit hoher Wahrscheinlichkeit,
daß der Benutzer die vorher ausgelöste Bewegung widerrufen oder ändern
möchte.
Haptische Eingabegeräte können sehr empfindlich sein, und schon kleine, unbeabsichtigte
Auslenkungen können dazu führen, daß von 0 verschiedene Geschwindigkeiten erzeugt
werden, die Typ B Animationen abbrechen. Deshalb sollte eine Anwendung, die
solche Eingabegeräte abfrägt, bei gesetztem isAnimating nur Bewegungen an den Navigator
weitergeben, die einen Schwellwert überschreiten.
7.3 Kombination der B ewegungsdaten
In einer Szene können mehrere Navigator Knoten gleichzeitig aktiv sein, deren Bewegungsdaten
der Browser in eine einzige Bewegung des Avatars umwandeln muß. Da Bewegungen
als Geschwindigkeiten und als Positionsdifferenzen angegeben werden können,
und da zwei Felder am Navigator Knoten die Wirkungsweise dieser Angaben beeinflussen
können, muß eine große Anzahl an verschiedenartiger Information zusammengeführt
werden. Der in dieser Arbeit verfolgte Lösungsweg wird im Folgenden dargestellt.
Die im Rahmen dieser Diplomarbeit durchgeführte Implementierung basiert auf einer
Simulationsschleife, die in kurzen Zeitabständen die Bewegungsdaten aller aktiven Navigator
Knoten sammelt und in eine leicht geänderte Position und Orientierung des Avatars
umrechnet. Jeder Schleifendurchlauf entspricht einem Simulationsschritt. Die Zeit zwischen
zwei Simulationsschritten ist nicht konstant, kann aber als klein angenommen
werden und liegt abhängig von der im Augenblick verfügbaren Rechenleistung und der
Komplexität des darzustellenden Teils der Szene in der Regel zwischen 10 und 100 ms.
Dadurch wird der Eindruck einer flüssigen Bewegung erreicht. Die dem Browser eigene
Implementierung der Maus- und Tastaturnavigation wird jeweils als ein zusätzlicher, Bewegungsdaten
liefernder Navigator Knoten realisiert.0,08
7.3.1 Darstellung als Signalflußplan In Abb. 14 ist der Signalfluß dargestellt, der die Bewegungsdaten der Navigator Knoten
in eine Avatarbewegung umwandelt. Jeder aktive Navigator liefert zwei mal sechs Fließkomma-Zahlen,
die eine Bewegung in den beiden Richtungssystemen SixDof und Examine
beschreiben. Diese müssen addiert, gefiltert und teilweise unter Berücksichtigung des
Lot-Vektors in die sechs Freiheitsgrade des dreidimensionalen Raumes umgewandelt
werden.
Seite 70

von Navigator Knoten mit
enableFiltering = FALSE
+ +
Glättungsfilter
~
von Navigator Knoten mit
enableFiltering = TRUE
Gf1 Pf1 Gf2 Pf2 Gf3 Pf3 Gd4 Pd4 Gf5 Pd5 Gd6 Pd6 G f
P f
Geschwindigkeiten
mit Positionen
kombinieren ∫
P f '
G d
+
P d
Geschwindigkeiten
mit Positionen
kombinieren ∫
P d '
P f ' * P''
Kapitel 7, Steuerung der Navigation
Interpretation
der Richtungssysteme
14 Geschwindigkeitswerte (6 x SixDof + 6 x Examine + 2 x free yaw & pitch)
14 Positionsdifferenzen (6 x SixDof + 6 x Examine + 2 x free yaw & pitch)
6 Freiheitsgrade des dreidimensionalen Raumes
Abb. 14: Informationsfluß in der Navigator Implementierung von Contact
Berücksichtigung des Flags free
Das Flag free des Navigator Knotens bedeutet, daß je nachdem, ob es gesetzt ist, die
Geschwindigkeiten und Positionsdifferenzen dieses Knotens unter Berücksichtigung des
Lot-Vektors oder ohne dessen Berücksichtigung verarbeitet werden müssen. Für die meisten
Richtungen ergibt sich aber kein Unterschied, so daß nur die Angaben in die Richtung
yaw und pitch abhängig vom Flag free separat verwaltet werden müssen. Es werden
daher pro Navigator Knoten ein Vektor G mit 14 Geschwindigkeitswerten verarbeitet,
die sich aus vier von free unabhängigen Werten des SixDof Richtungssystem, zweimal
yaw, zweimal pitch und sechs von free unabhängigen Werten des Examine Richtungssystems
zusammensetzen. Nach dem selben Prinzip ergibt sich pro Navigator Knoten
ein 14 dimensionaler Vektor P mit Positionsdifferenzen. Es muß jedoch angemerkt
werden, daß die meisten Komponenten dieser Vektoren den Wert 0 haben. Insbesondere
ist die Wahrscheinlichkeit, daß beide Richtungssysteme gleichzeitig aktiv sind, sehr gering.
Daher ist es vertretbar, wenn eine Implementierung diesen Fall nicht oder nur ineffizient
unterstützt.
Berücksichtigung des enableFiltering Flags
Für Navigator Knoten mit gesetztem enableFiltering Flag und solche mit nicht gesetztem
enableFiltering Flag werden die Vektoren G und P in zwei separaten Addiergliedern
jeweils komponentenweise aufsummiert.
→ →
G f = Σ G d
f
→ →
P = f Σ Pf f
→ →
G = Σ G d d
d
→ →
P d = Σ P d
d
wobei
Gf: Summe der nicht zu filternden Geschwindigkeitsvektoren
Pf: Summe der nicht zu filternden Positionsdifferenz Vektoren
Gd: Summe der nicht zu filternden Geschwindigkeitsvektoren
Pd: Summe der nicht zu filternden Positionsdifferenz Vektoren
Seite 71

Kapitel 7, Steuerung der Navigation
Anschließend werden die Geschwindigkeitsvektoren Gf und Gd mit der Zeit zwischen dem
letzten und dem aktuellen Simulationsschritt multipliziert, und ergeben so jeweils einen
Vektor mit Positionsdifferenzen, die der Bewegung seit dem letzten Simulationstick entsprechen.
Diese Positionsdifferenzen werden zu den Vektoren Pf bzw. Pd mit den von den
Navigator Knoten stammenden Positionsdifferenzen hinzuaddiert, so daß nachfolgend
nur noch Positionsdifferenzen (Vektoren Pf’ und Pd’) verarbeitet werden müssen.
→ → → .
Pf ' = Pf + Gf (tn - tn-1 )
Pd ' = Pd + G .
d (tn - tn-1 )
wobei
tn: Zeitpunkt des aktuellen Simulationsschritt
tn-1: Zeitpunkt des vorausgehenden
Simulationsschritt
Filterung der Bewegungsdaten
Die im Vektor Pf’ zusammengefaßten Bewegungsdaten aller Navigator Knoten mit gesetztem
enableFiltering Flag werden komponentenweise mit einem linearen Tiefpaßfilter
erster Ordnung gefiltert, um eine gleichmäßigere Bewegung zu erreichen. Die Spezifikation
des enableFiltering Feldes in Abschnitt 7.2.3 erlaubt dem Browser, jede beliebige,
aber geeignete Methode zur Filterung der Bewegungsdaten einzusetzen, wenn das
enableFiltering Feld an einem Navigator Knoten gesetzt ist. Dies umfaßt auch den Fall,
daß ein Browser gar keine Filterung einsetzt. Abschnitt 5.2.2 diskutiert die Motivation für
ein solches Filter. In dieser Arbeit wurde aus Gründen der einfachen Implementierung ein
lineares Filter erster Ordnung eingesetzt. Seine Funktionsweise soll im Folgenden kurz
skizziert werden.
Obwohl die Simulationsschleife zeitdiskret arbeitet, muß das System zeitkontinuierlich
betrachtet werden, da die zeitlichen Abstände zwischen zwei Simulationsschritten variieren
können. Das Filter implementiert die kausale Impulsantwort
={ e
h(t) -(t-t 0 ) / τ t > 0A
t0
0
t ≤ t0 Diese führt zur Sprungantwort
wobei
t0: Bezugszeitpunkt
τ0: Zeitkonstante des Filters
={ 1 - e
s(t)
0
-(t-t 0 ) / τ 0
Daraus ergibt sich der Ausgangsvektor Pf’ * des Filters aus dem Eingangsvektor Pf’ zu
→
P' [n] =
f *
∞
Σi = 1
→
A
A
A
t > t 0
t ≤ t 0
P' [n-i] . s(t[n] - t[n-i])
f
wobei
Pf’ * [n]: Vektor Pf’ * zum aktuellen Simulationsschritt
Pf’[n-i]: Vektor Pf’ vor i Simulationsschritten
s[n]: Zeitstempel des aktuellen Simulationsschritt
s[n-i]: Zeitstempel vor i Simulationsschritten
Abb. 15 stellt eine Komponente einer kontinuierlichen Bewegung dar, die in unregelmäßigen
Zeitabständen abgetastet, in eine Folge von Positionsdifferenzen konvertiert und
mit einem linearen Filter erster Ordnung gefiltert wird. Obwohl zur Veranschaulichung der
Funktionsweise des Filters eine gleichmäßig ansteigende kontinuierliche Bewegung dar-
Seite 72

Kapitel 7, Steuerung der Navigation
gestellt wird, sind Bewegungen, die mit einem haptischen Eingabegerät erzeugt werden
in der Realität oft weniger gleichmäßig, so daß eine Filterung tatsächlich lohnt (siehe
Abschnitt 5.2.2).
Gemäß Abb. 15 a) wird eine kontinuierliche Bewegung zu unregelmäßigen Zeitabständen
abgetastet. Die Differenzen zwischen jeweils zwei Abtastwerten stellt eine Folge von
Sprungfunktionen dar. (Der Maßstab auf der p-Achse in Abb. 15 b) wurde im Vergleich zu
Abb. 15 a) vergrößert.) Würde man diese Sprungfunktionen aufsummiert, würden sie die
Originalbewegung als Treppenfunktion approximieren. Abb. 15 c) zeigt die Antwort s(t)
des Filters auf jede dieser Sprungfunktionen. Gemäß dem Überlagerungsprinzip bei linearen
Filtern müssen diese Antworten aufsummiert werden, um das Ausgangssignal zu
erhalten.
a)
p
p
t
p
c)
t
b)
Abb. 15: Filterung von Positionsdifferenzen
a) Abtastung einer kontinuierlichen Bewegung mit variabler Abtastrate
b) Differenz der Abtastwerte als Sprungfunktion
c) Sprungantworten, die überlagert werden müssen
Der Wert der Zeitkonstante τ0 des in Abb. 15 dargestellten Filters entspricht in etwa der
durchschnittlichen Zeitspanne zwischen zwei Abtastwerten. In dem implementierten realen
System hat die Zeitspanne mit 0,08 s einen vergleichsweise größeren Wert, wodurch
sich am Ausgang des Filters eine Funktion ergibt, die der ursprünglichen kontinuierlichen
Bewegung langsam folgt. Zudem kommen Bewegungen wegen der asymptotischen Eigenschaften
von s(t) erst allmählich zum Stehen, schießen dennoch nicht über das Ziel
hinaus. Da die Simulationsschleife für jeden Abtastwert einmal aufgerufen wird, muß sie
zu diesen Zeitpunkten eine Überlagerung aller in der Vergangenheit hervorgerufenen
Sprungantworten berechnen. Damit wieder eine Folge von Positionsdfferenzen am Ausgang
des Filters entsteht, muß eine Differenz des aktuell berechneten Wertes mit dem im
letzten Schleifendurchlauf berechneten Wert gebildet werden.
Dies bedeutet zunächst einen immensen Verwaltungsaufwand. Jedoch ergibt sich wegen
der Selbstähnlichkeitseigenschaft der e-Funktion 14 eine Vereinfachung, so daß aus der
Summe aller bisher ausgegebenen Positionsdifferenzen und der Summe aller bisher
empfangenen Positionsdifferenzen die aktuell auszugebende Positionsdifferenz ermittelt
werden kann.
14 e t = A�e (t - t0) bei entsprechend gewähltem A und t0
t
Seite 73

Kapitel 7, Steuerung der Navigation
Kombination von gefilterten mit ungefilterten Bewegungen
Der Ausgangsvektor Pf’ * des Filters beschreibt Positionsdifferenzen, die mit den nicht zu
filternden Positionsdifferenzen Pd’ addiert werden müssen:
P'' = P'* + P'
f d
Ausführung der resultierenden Bewegung
Das Ergebnis dieser Berechnungen ist der Vektor P’’, der die durchzuführende Bewegung
des Avatars für den aktuellen Simulationsschritt, basierend auf den beiden Richtungssystemen
beschreibt. Seine 14 Komponenten beziehen sich auf die beiden Richtungssysteme
SixDof und Examine, wobei die Richtungen yaw und pitch zweimal vorkommen, da
sie vom Flag free abhängen. Diese 14 Werte werden mit der aktuellen Position und Orientierung
des Avatars entsprechend ihrer Definition in 5.1.3 zu einer neuen Position und
Orientierung verknüpft. Diese Bewegung kann mit der Geometrie der Szene verglichen
werden, und bei Auftreten einer Kollision wird die Bewegung entsprechend verkürzt.
7.3.2 Darstellung als Pseud ocode
Der oben erläuterte Vorgang ist zur besseren Veranschaulichung noch einmal als Pseudocode
dargestellt. Es wird eine leicht lesbare, an die Programmiersprache Visual Basic
angelehnte Darstellung verwendet. Damit die Darstellung prägnant bleibt, wird der Inkrementoperator
+= verwendet, der sein linksseitiges Argument um den Wert des
rechtsseitigen Arguments erhöht. Variablendeklarationen werden durch Nennung des
Typs vor den deklarierten Variablen notiert.
Anders als der Signalflußplan in Abb. 14 verwendet die Pseudocode Darstellung den fiktiven
Datentyp vector, der mit dem VRML Datentyp SFVec3f kompatibel ist und einen
dreidimensionalen Vektor enthält. Zur Erhöhung der Lesbarkeit wird eine farbliche Codierung
der auf diesem Datentyp basierenden Variablen verwendet. Die Zuordnung zwischen
Variablen und den 14-dimensionalen Vektoren des Signalflußgraphen ist als Kommentar
gekennzeichnet.
vector speedFiltXYZ, speedFiltYPR, speedFiltOPR, speedFiltABR; // G f
vector stepFiltXYZ, stepFiltYPR, stepFiltOPR, stepFiltABR; // P f
vector speedXYZ, speedYPR, speedOPR, speedABR; // G d
vector stepXYZ, stepYPR, stepOPR, stepABR; // P d
vector speedFiltFreeYPR, stepFiltFreeYPR; // für die vom Flag free abhängigen Werte
vector speedFreeYPR, stepFreeYPR; // für die vom Flag free abhängigen Werte
In einem ersten Schritt werden die Bewegungsdaten aller aktiven Navigator Knoten gesammelt
und abhängig vom Flag enableFiltering zu den Variablen für Gf und Pf bzw.
Gd und Pd hinzuaddiert. Aus Übersichtlichkeitsgründen wurde auf eine Behandlung des
Flags free in diesem Teil des Pseudocodes verzichtet. Korrekterweise müßten die Zeilen
für die Zuweisungen an speedFiltYPR, stepFiltYPR, speedYPR und stepYPR abhängig
vom Flag free mittels einer if Anweisung durch eine Zuweisung an speedFiltFreeYPR,
stepFiltFreeYPR, speedFreeYPR und stepFreeYPR ersetzt weden.
Seite 74

Kapitel 7, Steuerung der Navigation
// alle Bewegungen von den Navigator Knoten sammeln:
for int I= 1 to NumberOfNavigatorNodes
do
if Navigator[I].enabled then
if Navigator[I].enableFiltering then
speedFiltXYZ+= Navigator[I].speedXYZ; stepFiltXYZ+= Navigator[I].stepXYZ;
speedFiltYPR+= Navigator[I].speedYPR; stepFiltYPR+= Navigator[I].stepYPR;
speedFiltOPR+= Navigator[I].speedOPR; stepFiltOPR+= Navigator[I].stepOPR;
speedFiltABR+= Navigator[I].speedABR; stepFiltABR+= Navigator[I].stepABR;
else
speedOPR+= Navigator[I].speedOPR; stepOPR+= Navigator[I].stepOPR;
speedYPR+= Navigator[I].speedYPR; stepYPR+= Navigator[I].stepYPR;
speedXYZ+= Navigator[I].speedXYZ; stepXYZ+= Navigator[I].stepXYZ;
speedABR+= Navigator[I].speedABR; stepABR+= Navigator[I].stepABR;
end if
end if
end if
done
Die Geschwindigkeitswerte werden mit der Zeit zwischen dem aktuellen und dem letzten
Simulationsschritt multipliziert und ergeben so eine Bewegung während dieser Zeitspanne,
der zu den Positionsdifferenzen hinzuaddiert werden kann. Nach diesem Schritt muß
nur noch mit den Variablen stepFiltXYZ bis stepFiltABR und stepXYZ bis stepABR,
sowie der entsprechenden *FreeYPR Versionen weiter gerechnet werden.
// kombiniere speed mit step Werten:
float DeltaTime= TimeOfThisFrame – TimeOfLastFrame;
stepFiltXYZ+= speedFiltXYZ * DeltaTime; stepXYZ+= speedXYZ * DeltaTime;
stepFiltYPR+= speedFiltYPR * DeltaTime; stepYPR+= speedYPR * DeltaTime;
stepFiltOPR+= speedFiltOPR * DeltaTime; stepOPR+= speedOPR * DeltaTime;
stepFiltABR+= speedFiltABR * DeltaTime; stepABR+= speedABR * DeltaTime;
stepFiltFreeYPR+= speedFiltFreeYPR * DeltaTime;
stepFreeYPR+= speedFreeYPR * DeltaTime;
Für Werte, die von Navigator Knoten mit gesetztem enableFiltering Flag stammen, ist
es dem Browser freigestellt, ein Filter anzuwenden. Dieses sei in der Funktion ApplyFilter(�)
realisiert, die ihre Parameter verändert. Die im Rahmen dieser Diplomarbeit
durchgeführte Implementierung verwendet ein lineares Filter erster Ordnung mit der
Zeitkonstante τ0 = 0.08 s. Dies bewirkt eine leichte Glättung der Bewegungen, wodurch
die Navigation angenehmer erscheint. Die Funktion ApplyFilter(�) hält interne Zustandsdaten,
die den vergangenen Verlauf der Eingangsdaten zusammenfassen.
// filtern:
ApplyFilter(stepFiltXYZ, stepFiltYPR, stepFiltOPR, stepFiltABR);
Die gefilterten Positionsdifferenzen können nun mit den ungefilterten zusammengefaßt
werden, so daß nach diesem Schritt nur noch die Variablen stepXYZ bis stepABR weiter
verarbeitet werden müssen.
// kombiniere die gefilterten zu den ungefilterten Werten:
stepXYZ+= stepFiltXYZ;
stepYPR+= stepFiltYPR; stepFreeYPR+= stepFiltFreeYPR;
stepOPR+= stepFiltOPR;
stepABR+= stepFiltABR;
An dieser Stelle sind alle Richtungen der beiden Richtungssysteme in jeweils nur einem
Wert – einer Komponente einer Variablen vom Typ vektor – zusammengefaßt. Es können
hier die in der NavigationInfo oder NavigationInfo2 festgelegten Rahmenbedingungen
für die Navigation berücksichtigt werden. Die Variable CurrentBound_Navigation-
Info sei eine Referenz auf einen dieser beiden Knotentypen. Zunächst werden die Richtungen
x, y und z mit der nominellen Navigationsgeschwindigkeit multipliziert. Ist die
Seite 75

8 Multimodale Int eraktion
Kapitel 8, Multimodale Interaktion
In Abschnitt 3.5 wurde das am Lehrstuhl entwickelte multimodale Bediensystem MIVIS
vorgestellt. MIVIS ermöglicht die Bedienung einer VR Anwendung unter Verwendung von
semantisch höherwertigen Modalitäten. Maus und Tastaturbedienung ist zwar möglich,
wird aber in den multimodalen Integrationsprozeß nicht einbezogen. Andere VR Eingabegeräte
werden nicht unterstützt.
Die in diesem Kapitel beschriebene Arbeit erweitert dieses Bediensystem um die Möglichkeit
zur Bedienung mit beliebigen haptischen Eingabegeräten. Abschnitt 8.1 gibt einen
Überblick über den technischen Aufbau des ursprünglichen MIVIS Systems und Abschnitt
8.2 bis 8.5 beschreiben die in dieser Arbeit durchgeführten Erweiterungen.
8.1 Existierende Softw are
Dieser Abschnitt gibt zuerst einen Überblick über den Formalismus der Grammatiken und
beschreibt darauf aufbauend die Realisierung des existierenden MIVIS Systems.
8.1.1 Formale Funktionsmo dellierung
In diesem Kapitel wird an mehreren Stellen der im MIVIS System verwendete Formalismus
mittels einer Grammatik beschrieben. In diesem Absatz soll ein kurzer Überblick
über den formalen Hintergrund gegeben werden. Der Abschnitt basiert auf der in [12]
gegebenen formalen Definition. Die Grundlagen können in [10] und [11] nachgelesen
werden.
Ausgehend von einem Alphabet, das die Menge aller in einer Sprache erlaubten Symbole
definiert, kann eine formale Sprache als die Menge aller erlaubten Worte über diesem
Alphabet definiert werden, wobei ein Wort eine erlaubte Kombination der Symbole aus
dem Alphabet ist. Umfaßt das Alphabet z.B. die Symbole Σ = {a, b, c}, dann ist Σ * = {ε, a,
b, c, aa, ab, ac, ba, bb, bc, ca, cb, cc, aaa, aab, ...} die Menge aller möglichen Worte.
Hier bezeichnet ε das leere Wort, das aus null Symbolen besteht. Eine Sprache über dem
Alphabet Σ ist eine Teilmenge von Σ * , z.B. L = { ab, abba, bac }.
Eine Grammatik ist ein Satz von Regeln (Produktionen), die definieren, auf welche Weise
gültige Worte der Sprache L gebildet werden können. Variablen werden aus Symbolen
des Alphabets und aus anderen Variablen zusammengesetzt. Um zu überprüfen, ob ein
gegebenes Wort zu einer Sprache gehört, müssen Teile des Wortes solange mit Hilfe der
Produktionen durch Variablen ersetzt werden, bis das Wort vollständig durch eine bestimmte
Variable dargestellt wird. Diesen Vorgang nennt man Parsen. Die Variable, die
ein gültiges Wort definiert, heißt Startsymbol und wird meist mit S bezeichnet.
Der Umgekehrte Vorgang zum Parsen ist die Produktion oder Generierung eines Wortes.
Dazu wird das Startsymbol solange mit Hilfe der Produktionen durch andere Variablen
oder durch Symbole ersetzt werden, bis nur noch Symbole in dem Ausdruck auftreten.
Oft werden Variablen als nicht terminale Symbole und die Symbole aus dem als terminale
Symbole bezeichnet, da Variablen so lange mit Hilfe der Produktionen ersetzt werden, bis
nur noch Symbole des Alphabets vorhanden sind.
Seite 77

Kapitel 8, Multimodale Interaktion
Beispiel:
Es sei Σ1 = {der, die, das, Vater, Mutter, Kind, Bruder, Schwester, lacht, spielt, singt,
und} das Alphabet, dann kann die Sprache L1 durch die folgenden Regeln definiert
werden:
::=
::=
::=
::= der | die | das
::= Vater | Mutter | Kind | Bruder | Schwester
::=
::=
::= lacht | spielt | singt
::= und
Mögliche Sätze aus dieser Sprache sind:
die Mutter lacht
das Kind lacht und singt
In dieser Arbeit wird die Backus-Naur-Form[10] verwendet. Diese definiert das Zeichen
::= als das Zuweisungszeichen. Variablen auf der linken Seite werden durch die
Ausdrücke auf der rechten Seite ersetzt. Das Zeichen | dient zur Kennzeichnung von
Alternativen – z.B. wird die Variable durch der, die oder durch das ersetzt. In
dieser Arbeit werden ferner Variablen in spitze Klammern gesetzt, um sie von terminalen
Symbolen zu unterscheiden. Der Konvention, diejenige Variable, welche die gültigen
Worte der Sprache definiert, mit zu bezeichnen wird Folge geleistet.
Nach Chomsky[13] lassen sich Grammatiken unter anderem in kontextfreie und kontextsensitive
Grammatiken einteilen. Eine kontextfreie Grammatik besteht nur aus Regeln,
die eine Variable unabhängig von der Umgebung, in der die Variable ersetzt werden soll,
definieren. Auf der linken Seite einer Produktion taucht nur die zu definierende Variable
auf. Das oben angegebene Beispiel einer Grammatik für einfache deutsche Sätze ist eine
kontextfreie Grammatik.
Eine kontextsensitive Grammatik hingegen ist eine Grammatik, bei der zur Bildung einiger
Variablen bestimmte Symbole in der Umgebung der Variablen vorhanden sein müssen.
Auf der linken Seite einer kontextsensitiven Bildungsregel stehen weitere Symbole,
welche die Gültigkeit der Regel beschreiben. Im obigen Beispiel könnte die Regel für
durch die folgenden kontextsensitiven Regeln ersetzt werden, um auszudrücken,
daß bestimmte Nomen bestimmte Artikel voraussetzen:
der ::= Vater | Bruder
die ::= Mutter | Schwester
das ::= Kind
Auf der linken Seite einer Regel können sowohl links als auch rechts von der zu definierenden
Variable kontextspezifizierende Symbole auftreten. Da kontextfreie Grammatiken
algorithmisch und systemtheoretisch leichter zu handhaben sind als kontextsensitive,
und da sie für die Modellierung der Systemfunktionen ausreichen, werden in dieser Arbeit
nur kontextfreie Grammatiken verwendet.
Kontextsensitivität
In diesem Abschnitt wurden Grammatiken in kontextfreie und kontextsensitive Grammatiken
eingeteilt. Es gibt noch eine weitere Form der Kontextabhängigkeit: Kommandos,
die der Benutzer an ein System abgibt, können sich auf andere Kommandos beziehen,
die vor oder nach dem aktuellen Kommando oder über eine andere Modalität abgegeben
wurden. Um Mehrdeutigkeiten zu vermeiden, werden in dieser Arbeit Kontextabhängigkeiten
mit dem Zusatz „im Sinne der Funktionalität” bzw. „im Sinne formaler Sprachen”
gekennzeichnet. Meistens jedoch ist von Kontextsensitivität im Sinne der Funktionalität
Seite 78

Kapitel 8, Multimodale Interaktion
die Rede, und nur der Begriff kontextfreie Grammatik bezeichnet Kontextfreiheit im Sinne
formaler Sprachen, so daß in solchen Fällen auf den Zusatz verzichtet wird.
Konventionen zur Darstellung
Um die Übersichtlichkeit der Darstellung zu erhöhen, werden folgende Konventionen in
dieser Arbeit zur Darstellung kontextfreier Grammatik verwendet:
Bei einer kontextfreien Grammatik beschreiben die Bildungsregeln, wie eine Variable
durch andere Variablen unter Verwendung von Terminalsymbolen ersetzt werden. Diese
Abhängigkeit zwischen den Variablen wird durch eine Einrückung gekennzeichnet. Eine
Regel wird wenn möglich von solchen Regeln gefolgt, welche diese Regel benötigt. Diese
unterstützenden Regeln werden um eine Ebene weiter eingerückt, als die Regel, durch
die sie benutzt werden.
Ein Teil der Regeln dient dazu, die terminalen Symbole zu Wertebereichen zu gruppieren.
So definiert die Regel ::= on | off | toggle eine Variable, welche die terminalen
Symbole on, off und toggle zu einem Wertebereich kombiniert, der zur Kontrolle boolscher
Parameter benutzt werden kann. Solche Variablen und die Regeln, durch die sie
definiert werden, sind in grüner Farbe dargestellt. Damit diese Kennzeichnung auch auf
Schwarzweiß Ausdrucken erkennbar ist, werden Wertebereich definierende Regeln am
linken Rand mit Punkten markiert.
Eine spezielle Art von Variablen umfaßt einen allgemeingültigen Wertebereich oder Datentyp.
Da diese als allgemein bekannt vorausgesetzt werden können, und deren exakte
Definition von sekundärer Bedeutung für die Funktionsmodellierung ist, werden sie mit
kursiver Schrift notiert und nicht näher durch Produktionen definiert. Folgende Variablen
werden verwendet:
• : bezeichnet Ganzzahlen der Form 1234 oder -5678
• : bezeichnet Fließkomma-Zahlen der Form 10.23 oder –5.2e+20
• : bezeichnet beliebige Zeichenketten, die in Anführungszeichen stehen
Da in diesem Kapitel eine Grammatik entwickelt wird, die im Sinne der Funktionalität
sowohl kontextsensitive als auch kontextfreie Kommandos beschreibt, und da an bestimmten
Stellen nur kontextfreie Kommandos erlaubt sind, werden kontextsensitive
Kommandos mit dunkelroter Farbe gekennzeichnet. Zusätzlich werden diese durch einen
Strich am linken Rand, beziehungsweise mit einer punktierten Unterstreichung markiert.
Um die Lesbarkeit der Grammatik zu erhöhen, sind in der elektronischen Form dieser
Arbeit alle Variablen sensitiv gegenüber Mausklicks. Wird eine Variable angeklickt, springt
der Cursor an die Definition der Variable. Die Brauchbarkeit dieses Mechanismus hängt
jedoch vom verwendeten Dateiformat ab.
Die Namen von Variablen für Richtungsangaben werden in Anlehnung an das Avatar lokale
Koordinatensystem aus Abb. 4 aus Abschnitt 5.1.2 gewählt. Beschreibt z.B. eine
dieser Variablen horizontale und vertikale Richtungsangaben, wird sie XY genannt, da
horizontale Bewegungen entlang der x-Achse und vertikale Bewegungen entlang der y-
Achse wirken. Vorwärts- Rückwärtsbewegungen sind demgemäß dem Buchstaben Z zugeordnet.
Seite 79

Kapitel 7, Steuerung der Navigation
Welt eine solche, in der dem Lot-Vektor keine besondere Bedeutung zukommt, dann wird
dies durch ein gesetztes Flag free der NavigationInfo2 ausgedrückt. In diesem Fall müssen
unabhängig von den Flags free an den Navigator Knoten alle Bewegungen unabhängig
vom Lot-Vektor verarbeitet werden. Dies wird durch ein Verschieben der Bewegungsdaten
von stepYPR nach stepFreeYPR gewährleistet.
// Aktiven NavigationInfo Knoten beachten:
stepXYZ*= CurrentBound_NavigationInfo.speed;
if CurrentBound_NavigationInfo.free then
stepFreeYPR+= stepYPR;
stepYPR= (0, 0, 0);
end if
Nun sind die Bewegungen in einer Weise spezifiziert, in der sie direkt ausgeführt werden
können. Dieser Vorgang ist extrem Browser abhängig und soll hier nur schematisch dargestellt
werden. Die Variable AvatarMatrix sei eine Variable, welche die Position und
Orientierung des Avatars enthält. Manche Browser könnten hier eine Transformationsmatrix
verwenden, andere eine parametrisierte Darstellung, welche in Anlehnung an
Abschnitt 5.1.2 die Orientierung in Form eines Richtungsvektors v →
und der Winkel α und
β beschreibt. Letztere könnten eine ähnliche parametrisierte Darstellung für das Examine
Richtungssystem definieren und abhängig davon, welches Richtungssystem aktiv ist, eine
der beiden Darstellungen verwenden. Sind jedoch beide Richtungssysteme aktiv, muß ein
solcher Browser laufend zwischen beiden Darstellungen umrechnen. Dieser Fall ist jedoch
sehr unwahrscheinlich.
// Richtungswerte in echte Bewegungen umwandeln:
SupplySixDof (AvatarMatrix, stepXYZ, stepYPR, stepFreeYPR);
SupplyExamine(AvatarMatrix, stepOPR, stepABR, CurrentExamineCenter);
Die Variable AvatarMatrix enthält nun die aufgrund der von den Navigator Knoten und
der im Browser eingebauten Navigationsmechanismen erzeugte neue Position des
Avatars. Diese muß nun noch in einem letzten Schritt mit der Geometrie der Szene verglichen
werden, wodurch eventuell ein Teil der berechneten Bewegung zurückgenommen
werden muß. Dieser Schritt der Kollisionserkennung ist extrem browserabhängig und
wird hier nicht dargestellt. Die daraus resultierende Position in AvatarMatrix kann zur
Darstellung der Szene aus der neuen Position verwendet werden.
Seite 76

8.1.2 Aufbau des ursprüng lichen MIVIS Systems
Kapitel 8, Multimodale Interaktion
Dieser Abschnitt stellt die Funktionsweise des unveränderten multimodalen Bediensystems
MIVIS dar, auf welche diese Arbeit aufbaut.
Struktur der Systemkomponenten
Eine Reihe Erkennermodule für semantisch höherwertige Modalitäten analysiert die Signale
der angeschlossenen Sensoren und extrahiert daraus diskrete Kommandos an die
Anwendung. Das System enthält einen Spracherkenner, der sowohl natürlichsprachliche
Äußerungen als auch eine Kommandosprache versteht. Ein Erkennermodul für dynamische
Handgesten erhält das Videosignal einer Kamera, die von oben auf die Hand des
Benutzers gerichtet ist, und extrahiert daraus mit der Hand durchgeführte Gesten. Eine
zweite Kamera betrachtet von vorne den Kopf des Benutzers und speist mit seinem Videosignal
ein Erkennermodul für Kopfgesten. In [6][7][8] können die Details zu den Erkennermodulen
nachgelesen werden. Abb. 16 zeigt den Versuchsaufbau im Usability Labor
des MIVIS Projekts. Die Konzeption des Systems erlaubt, weitere Erkennermodule
anzuschließen. So existiert ein sogenanntes Button GUI, welches in einem auf dem Bildschirm
dargestellten 2D Fenster für jeden der möglichen Befehle einen Druckknopf darstellt
und mit der Maus bedient werden kann.
Abb. 16: Usability Labor des MIVIS Projekts
In Abb. 17 ist der Aufbau des MIVIS Systems schematisch dargestellt. Da die Kommandos,
die über die verschiedenen Modalitäten abgesetzt werden, miteinander in Beziehung
stehen und nicht notwendigerweise eindeutig sind, existiert ein Integrator Modul, das die
Intention des Benutzers modelliert. Der Integrator verwendet dazu unter anderem kontextsensitive
Zeitfenster und einen Speicher, der die zuletzt erhaltenen Kommandos enthält.
Genaueres über seinen Aufbau ist in [9] und [6] beschrieben.
Spracherkenner
Handgestenerkenner
Kopfgestenerkenner
Integrator
VRML Browser
FreeWRL
Maus Tastatur
3D Szene
Abb. 17: Struktur des Multimodalen Bediensystems MIVIS
Seite 80

Kapitel 8, Multimodale Interaktion
Die Darstellung der 3D Szene übernimmt der als freie Software verfügbare VRML Browser
FreeWRL[26]. Dieser wurde um einige für die Navigation mit semantisch höherwertigen
Modalitäten zweckmäßigen Funktionen erweitert. Aufgrund der bei den Erkennermodulen
noch langen Latenzzeit kann noch keine direkte Rückkopplung über ausgeführte Kommandos
gegeben werden. Deshalb wurde FreeWRL um die Funktion, Bewegungen in einzelnen
Schrittweiten auszuführen, erweitert, wobei die Schrittweite vom Benutzer gesteuert
werden kann. Eine ‚Wiederhole’ Funktion und ein Puffer, der es erlaubt, die letzten
n Befehle rückgängig zu machen, erhöhen die Benutzbarkeit des Systems weiter.
Damit der Browser vom Integrator gesteuert werden kann, wurde eine Schnittstelle auf
der Basis von TCP Sockets eingeführt. Die ursprünglich in FreeWRL enthaltenen Funktionalität
zur Navigation mit Maus und Tastatur wurde nicht verändert, so daß diese Navigationsmöglichkeit
weiterhin direkt auf die Position des Avatars in der Szene wirkt, jedoch
wurde ein Rückkanal an den Integrator geschaffen, so daß dieser über derartige
Ereignisse informiert wird.
Die Module laufen auf verschiedenen Plattformen: Der Spracherkenner ist ein kommerzielles
Produkt von Lernout & Hauspie[30], das auf der Windows Plattform läuft. Die
Handgesten werden auf SGI Rechnern klassifiziert, und die Kopfgesten auf mit Linux betriebenen
Rechnern. FreeWRL und der Integrator laufen ebenfalls unter Linux. Die Kommunikation
der Module basiert auf den Netzwerkprotokollen TCP/IP.
Kommunikationsformalismus
Zur Repräsentation der Äußerungen des Benutzers und seiner Intentionen wird ein auf
einer kontextfreien Grammatik basierender Formalismus verwendet. Diese Grammatik
wird hier kurz vorgestellt. Im Anhang C ist die vollständige Grammatik angegeben.
Die Serie an Kommandos, die der Benutzer erzeugen kann setzt sich aus der Gruppe der
Kommandos zur diskreten Navigation und die der Steuerkommandos zusammen. Die
diskreten Navigationskommandos können in vollständiger oder unvollständiger Form vorliegen.
S ::=
::= |
::= | |
Die vollständigen Navigationskommandos sind in der Form
angegeben. Die Komponente gibt den Navigationsmodus (WALK,
FLY oder EXAMINE) an. Die zweite Komponente nennt die Bewegungsart (translatorisch,
rotatorisch, roll) und die dritte Komponente nennt die Bewegungsrichtung, z.B. forward.
Eine rotatorische Bewegungsart ist eine solche, welche die Blickrichtung verändert, während
roll Drehungen um die optische Achse, d.h. seitliches Neigen des Körpers nach
links oder rechts bezeichnet.
::= walk | fly | examine
::= trans | rot
::= trans | rot | roll
::= trans | rot | roll
: ::= |
: ::= |
:
: ::= lfwd | rfwd | lbwd | rbwd
:
: ::= | |
: ::= |
: ::= |
:
: ::= left | right
: ::= up | down
: ::= forward | backward
Seite 81

Kapitel 8, Multimodale Interaktion
Die mit diesen Regeln erzeugbaren Kommandos können direkt in Bewegungen der in
Abschnitt 5.1.3 definierten Richtungssysteme umgesetzt werden. Diese Zuordnung ist in
Anhang C angegeben.
Es wurde auf eine konsistente Interpretation der Richtungsangaben geachtet. Denn die
Angabe einer Bewegung kann zum einen so interpretiert werden, daß sich der Avatar in
die angegebene Richtung bewegt, und zum anderen so, daß die Szene in die angegebene
Richtung bewegt wird. Interpretiert man eine Richtungsangabe als avatarbezogen, entsteht
für die Szene der Eindruck der Bewegung in die entgegengesetzte Richtung. Da im
WALK und FLY Modus die Bewegung des Benutzers das zentrale Element der Navigation
ist, werden Richtungsangaben in diesen Modi avatarbezogen interpretiert. Im EXAMINE
Modus steht das zu rotierende Objekt im Mittelpunkt, so daß hier die Szene in die angegebene
Richtung gedreht bzw. verschoben wird. Untersuchungen haben gezeigt, daß
Benutzer Angaben meistens nach diesem Schema machen. Aber insbesondere beim Kippen
des Avatars nach links oder rechts, was eine unnatürliche Bewegung darstellt, wird
dieses Schema von fast der Hälfte der Benutzer verletzt[19].
Die unvollständige Form der Navigationskommandos wird durch einen Präfix ks gekennzeichnet,
der für kontextsensitiv (im Sinne der Funktionalität) steht. Kontextsensitive
Kommandos basieren ebenfalls auf der Form , hier können
jedoch eine oder zwei der drei Komponenten weggelassen werden. Es ist die Aufgabe des
Integrators, diese Kommandos zu eliminieren und durch vollständige Kommandos zu
ersetzen.
| ::= ks
| ::= | | |
|
| ::= walk | fly | examine
|
| ::= trans | trans
| ::= rot | rot
| ::= roll | roll
|
| ::=
Die Gruppe der Steuerkommandos enthält Befehle zum Aktivieren der Standardbeleuchtung
15 , zum Durchwandern der in der Szene definierten Aussichtspunkte, eine „Wiederhole”
und eine „Rückgängig” Funktion, sowie ein Kommando zum Beenden der Anwendung.
::= control
::= stepsize
::= light
::= viewpoint
| ::= repeat
::= undo
::= quit
: ::= inc | dec
: ::= on | off
: ::= prev | next
Das MIVIS System wird ausführlich in [12] beschrieben.
15 Das Headlight ist ein Konzept in VRML, das im Browser eine standardmäßige Beleuchtung für
Welten definiert, die keine besonderen Anforderungen an die Ausleuchtung der Szene stellen. Das
Headlight leuchtet immer in Blickrichtung des Benutzers, ähnlich der Stirnlampe eines Bergarbeiters.
Seite 82

8.2 Designentscheidun gen
Kapitel 8, Multimodale Interaktion
Dieser Abschnitt diskutiert die wesentlichen Entscheidungen, worauf die Erweiterung des
MIVIS System beruht.
8.2.1 Kommunikationskana l für zeitkontinuierliche Werte
Semantisch höherwertige Modalitäten erzeugen Befehle, die als separate Ereignisse mittels
einer kontextfreien Grammatik dargestellt werden können. Im Gegensatz dazu erzeugen
haptische Eingabegeräte hauptsächlich einen Strom von Werten eines kontinuierlichen
Wertebereichs, der sich schnell in Reaktion auf die Darstellung der Szene ändern
kann. Es entsteht ein rückgekoppelter Regelkreis, wenn der Benutzer mit einem haptischen
Eingabegerät in der Szene navigiert oder ein Objekt bewegt:
• Der Benutzer drückt das Eingabegerät in eine bestimmte Richtung.
• Die Darstellung der Szene ändert sich entsprechend.
• Der Benutzer sieht die Änderung der Szene, vergleicht sie mit dem Zustand,
den er erreichen will und korrigiert seine Manipulation am Eingabegerät entsprechend.
Daher muß für haptische Eingabegeräte ein eigener Kanal geschaffen werden, der anders
als der Kanal für die kontextfreie Grammatik numerische Werte hoher Änderungsrate
weiterleitet, damit sie ohne wahrnehmbarer Verzögerung auf die Szene einwirken können.
8.2.2 Navigationsmodi
Im ursprünglichen MIVIS System liegen der Navigation die drei Modi WALK/FLY/EXAMINE
zu Grunde. In Verbindung mit haptischen Eingabegeräten scheint zunächst eine feinere
Unterteilung naheliegend, da viele Eingabegeräte weit weniger Freiheitsgrade zur Verfügung
stellen, als zur vollständigen Unterstützung dieser drei Modi notwendig wären. Eine
Aufgliederung dieser drei Modi in Untermodi mit weniger Freiheitsgraden kann jedoch
nicht vorgenommen werden, da diese Aufteilung vom Eingabegerät abhängt. Ein Gerät
mit drei Freiheitsgraden bräuchte z.B. einen SLIDE Modus für translatorische Bewegungen
in den Richtungen x, y und z, während für ein Eingabegerät mit nur zwei Freiheitsgraden
zwei SLIDE Modi notwendig wären: Einer für horizontale Bewegungen in x und z
Richtung, und einer für vertikale Bewegungen in x und y Richtung. Zudem würde dies
bedeuten, daß diese Untermodi separat für jedes Eingabegerät eingestellt werden müßten.
Das würde die Komplexität des Benutzungsinterfaces sowohl in der Implementierung,
als auch für den Benutzer unzulässig erhöhen.
Es wird deshalb das MIVIS System nicht um weitere Navigationsmodi ergänzt, sondern
die Module, welche die Signale eines Eingabegerätes interpretieren (siehe nächster Abschnitt)
müssen eine Methode implementieren, welche die Freiheitsgrade des Eingabegerätes
auf die Freiheitsgrade des aktiven Navigationsmodus abbilden. Für einen Joystick
bedeutet das, daß die verfügbaren Freiheitsgrade grundsätzlich auf die am meisten benutzten
Bewegungsrichtungen abgebildet werden, wobei sich diese Abbildung zugunsten
weniger häufig benutzter Bewegungsrichtungen ändert, wenn einer der Feuerknöpfe am
Joystick gedrückt wird. Gemäß des Usability Grundsatzes, ein Benutzungsinterface möglichst
modusfrei zu halten, erfolgt diese Umschaltung nur so lange, wie die entsprechende
Taste gedrückt ist. Für ein Eingabegerät, das keine solche Umschaltung ermöglicht,
bedeutet das, daß mit diesem Eingabegerät nicht alle Freiheitsgrade der Navigation erreicht
werden können, und daß der Benutzer gegebenenfalls auf andere Modalitäten ausweichen
muß.
Seite 83

Kapitel 8, Multimodale Interaktion
Es kann allerdings vorkommen, daß man beim Design einer Anwendung zu dem Schluß
kommt, daß sich die Benutzbarkeit des Systems erhöht, wenn man bestimmte Freiheitsgrade
einschränkt. Denn dadurch kann verhindert werden, daß der Benutzer an unvorhergesehene
Orte oder in schwierig zu handhabende Situationen gerät. Beispielsweise
könnte bei einer Unterhaltungsanwendung der Benutzer von einer Erzählerfigur durch die
Welt geführt werden, sich aber selbständig umsehen können. Das bedeutet technisch,
daß die Position des Benutzers von der Anwendung festgelegt wird, und nur die rotatorischen
Freiheitsgrade zur benutzergesteuerten Navigation zur Verfügung stehen. Hilfesysteme
könnten eine ähnliche Funktion bieten. In bestimmten Situationen möchte vielleicht
der Autor verhindern, daß im EXAMINE Modus ein auf dem Bildschirm zentriertes
Objekt aus dieser Position weg bewegt wird. D.h. er möchte Bewegungen in den Richtungen
A und B unterdrücken. In einer mehrbenutzerfähigen Kunstgalerie könnte zwar das
Betrachten einzelner Objekte im EXAMINE Modus erlaubt sein, jedoch möchte man nicht,
daß die Avatare über den Kunstgegenständen schweben, oder im Boden versinken. Eine
Einschränkung der Bewegung in ω, ρ und yaw Richtung würde das verhindern.
Um diese Art von Anwendungen zu unterstützen, wird die Funktion, einzelne Freiheitsgrade
zu unterdrücken eingebaut. Diese Funktion wird primär von der Anwendung selbst
ausgelöst, sie steht aber auch für Module, die Benutzereingaben signalisieren, zur Verfügung.
Dadurch können Szenarien geschaffen werden, in denen der Benutzer durch den
Satz „Ich will mich nur drehen können.” Unterstützung beim Halten einer Position anfordert.
8.2.3 Haptische Interprete r
Abschnitt 3.4 verdeutlicht, wie vielfältig haptische Eingabegeräte sein können. Zusätzlich
muß in Betracht gezogen werden, daß die genaue physikalische Ausprägung eines Eingabegerätes
einen wesentlichen Einfluß auf die Interpretation der vom Eingabegerät gelieferten
Werte hat. Ein einfacher Joystick mit zwei Achsen und eine Spacemouse unterscheiden
sich auf den ersten Blick nur in der Anzahl an Freiheitsgraden. Jedoch ist es bei
einer Spacemouse nicht möglich, eine Auslenkung in nur einer Richtung zu erzeugen ohne
eine geringe Auslenkung in den anderen Richtungen zu bewirken. Bei einem Joystick
ist das mühelos möglich und die Software kann ein entsprechendes Navigationsparadigma
implementieren. Eine 2D Maus und ein Touchscreen sind beides bildschirmorientierte
Zeigegeräte. Doch ist bei der Maus eine Positionsinformation immer vorhanden, während
der Touchscreen diese nur liefert, wenn er berührt, d. h. aktiviert ist.
Es ist nicht möglich, ein Modul zu erzeugen, das alle möglichen Eingabegeräte in generischer
Weise unterstützt und daraus Bewegungen des Avatars erzeugt. Das erweiterte
Framework enthält daher für jeden Typ von Eingabegeräten ein Modul, das die Signale
dieses Gerätes interpretiert und daraus Geschwindigkeiten und Positionsdifferenzen in
den beiden Richtungssystemen erzeugt.
Da haptische Eingabegeräte zusätzlich zu Bewegungsinformation in begrenztem Umfang
auch diskrete Kommandos absetzen können, z.B. mittels eines Druckknopfes, sind haptische
Interpreter mit dem Integrator für semantisch höherwertige Modalitäten verbunden
und können diesem den selben Umfang an Kommandos senden, wie die Erkennermodule
für semantisch höherwertige Modalitäten.
Die Interpretation der Signale eines Eingabegerätes und Umsetzung in Bewegungsinformation
muß abhängig vom eingestellten Navigationsmodus und der aktuellen nominellen
Navigationsgeschwindigkeit geschehen. Deshalb hat ein haptischer Interpreter einen Eingang,
über den es den Zustand von solchen Parametern erfährt, welche die Navigation
bestimmen.
Seite 84

8.2.4 Kontinuierlicher Inte grator
Kapitel 8, Multimodale Interaktion
Ähnlich dem Integrator bei semantisch höherwertigen Modalitäten müssen die Ströme
von Geschwindigkeitswerten und Positionsdifferenzen, die jeder haptische Interpreter
emittiert, auf eine bestimmte Weise vereinigt werden. Beim diskreten Integrator geschieht
das, indem die Befehle der verschiedenen Modalitäten miteinander in Beziehung
gebracht werden und die Intention des Benutzers daraus abgeleitet wird. Bei den kontinuierlichen
Bewegungsinformationen haptischer Eingabegeräte ist es nicht ratsam, diese
miteinander in Beziehung zu setzen, da diese viel enger mit der Bewegung des Avatars
verknüpft sind. Außerdem würde dies die Komplexität sowohl der Implementierung als
auch der Sicht des Benutzers auf das System stark erhöhen. Daher wurde als kontinuierlicher
Integrator ein Addierglied gewählt, das alle Geschwindigkeiten und Positionsdifferenzen
für jede Richtung aufsummiert.
8.2.5 Feedback an Benutze r
Ein wichtiger Bestandteil eines Benutzungsinterfaces ist die Rückkopplung an den Benutzer.
Der Kanal, der die Parameter der Navigation (hauptsächlich Modus und Geschwindigkeit)
an die haptischen Interpreter sendet, transportiert daher auch Information über
solche Ereignisse, die den Benutzer interessieren könnten. Haptische Interpreter können
diese Informationen je nach Fähigkeit des zugehörigen Eingabegerätes an den Benutzer
weitergeben.
Es besteht zudem die Möglichkeit, dedizierte Feedback-Module an diesen Kanal anzuschließen.
Diese geben ausschließlich Information an den Benutzer weiter. Ein solches
Feedback-Modul ist das im MIVIS Projekt verwendete Fenster, das als konventionelles 2D
GUI in Textfeldern den aktuellen Navigationsmodus, die eingestellte Schrittweite und
aufgetretene Ereignisse anzeigt.
Der Kanal für solche Ereignisse überträgt die Information ebenfalls mittels einer kontextfreien
Grammatik. Das ist ausreichend für semantisch höherwertiges Feedback, jedoch
können damit keine Materialeigenschaften wie z.B. die Oberflächenstruktur simuliert
werden.
Seite 85

8.3 Systemarchitektur
Kapitel 8, Multimodale Interaktion
Gemäß den im letzten Abschnitt diskutierten Designentscheidungen wird sowohl die Infrastruktur
als auch die Funktionalität des multimodalen Bediensystems erweitert. Dieser
Abschnitt gibt einen kurzen Überblick über das erweiterte System und diskutiert anschließend
detailliert die einzelnen Komponenten. Teilweise läßt es sich nicht vermeiden,
daß auf Kommandos des erweiterten Funktionsumfangs Bezug genommen werden muß,
die erst im nächsten Abschnitt erläutert werden. Um solche Situationen möglichst zu
vermeiden, werden kommandospezifische Funktionen der einzelnen Module im nächsten
Abschnitt bei den entsprechenden Kommandos erläutert.
8.3.1 Systemüberblick
Aufgrund der im Abschnitt 8.2 getroffenen Designentscheidungen ergibt sich die in Abb.
18 dargestellte Infrastruktur für das auf haptische Modalitäten erweiterte multimodale
Bediensystem MIVIS.
Semantisch höherwertige
Modalitäten
Haptische
Modalitäten
status
display
Spracherkenner
Handgestenerkenner
Kopfgestenerkenner
Maus
Interpreter
Joy Stick
Interpreter
Space Maus
Interpreter
Benutzer
Feedback
Diskreter
Integrator
Geschwindigkeitswerte und
Positionsdifferenzen
Kontinuierlicher Integrator
Benutzer Eingaben
Status Änderungen
kontextfreie Navigationskommandos
Navigator
Begrenzer
(Kollisionserkennung
&
Gravitation)
Abb. 18: Auf haptische Modalitäten erweiterte Struktur des multimodalen
Bediensystems MIVIS
Modifikation
der Szene
Zustand der
Szene
Bewegungen
des Avatars
Seite 86

Kapitel 8, Multimodale Interaktion
Die Infrastruktur des erweiterten Bediensystems besteht aus den folgenden Systemkomponenten:
• Eine Reihe von Erkennermodulen für semantisch höherwertige Modalitäten senden
Kommandos an den Diskreten Integrator. Diese Module werden im Folgenden kurz
SHM Erkenner genannt.
• Eine Reihe von haptischen Interpretern setzen die Manipulationen des Benutzers an
den haptischen Eingabegeräten in Bewegungsinformationen um. Sie erhalten den
aktuellen Navigationsmodus und andere wichtige Informationen vom Navigator mitgeteilt.
• Der Integrator des unveränderten Systems wurde in ‚Diskreter Integrator’ umbenannt.
Er modelliert die Intention des Benutzers und löst kontextsensitive Kommandos
in kontextfreie Kommandos auf.
• Das Navigator Modul erhält die kontextfreien Kommandos des diskreten Integrators
und führt sie aus. Treten dabei Ereignisse auf, die für andere Module oder den Benutzer
interessant sind, signalisiert er diese. Wenn der Navigator Kommandos der diskreten
oder quasikontinuierlichen Navigation erhält, erzeugt er entsprechende Bewegungsinformationen
und sendet sie an den kontinuierlichen Integrator.
• Der kontinuierliche Integrator kombiniert die von den verschiedenen haptischen Interpretern
und vom Navigator erhaltenen Bewegungsinformationen und setzt sie in
Bewegungen des Avatars um.
• Drei Kommunikationskanäle transportieren Kommandos von den SHM Erkennern und
den haptischen Interpretern zum Diskreten Integrator (grün), Statusaktualisierungen
vom Navigator Modul zu den haptischen Interpretern (rot) und kontinuierliche Bewegungsinformationen
von den haptischen Interpretern zum kontinuierlichen Integrator
(blau).
8.3.2 Eingabemodule
Die Eingabemodule sind in Abb. 18 auf der linken Seite dargestellt. Sie unterteilen sich in
SHM Erkenner und in haptische Interpreter. Die SHM Erkenner sind in der Regel Mustererkenner,
welche die Äußerungen des Benutzers klassifizieren und kontextfreie oder
kontextsensitive Kommandos an den Integrator senden.
Haptische Interpreter hingegen interpretieren die an ihrem zugeordneten Eingabegerät
durchgeführten Manipulationen vollständig. Sie erzeugen in erster Linie Bewegungsinformationen,
die sie an den kontinuierlichen Integrator senden, und in manchen Fällen
Kommandos, die an den diskreten Integrator gerichtet sind. Um die Signale der Eingabegeräte
in eine Bewegung umwandeln zu können, müssen sie wissen, welcher Navigationsmodus
und welche Navigationsgeschwindigkeit gerade aktiv sind. Diese Information
erhalten haptische Interpreter vom Navigator.
Ein haptischer Interpreter kann über ein entsprechendes Eingabegerät Feedback-
Information an den Benutzer geben. Das kann ein Ereignis sein, das am Eingabegerät
ausgelöst wird, wenn der Benutzer mit Geometrie der Szene kollidiert – ein Vorgang, der
in virtuellen Welten viel häufiger vorkommt als in realen Umgebungen. Diese Information
hilft insbesondere dem unerfahrenen Benutzer zu verstehen, warum er sich nicht bewegen
kann. Denn durch das geringere Gesichtsfeldes bei einer bildschirmorientierten 3D
Anwendung können kleinere Objekte, die dem Benutzer im Weg stehen, oft nicht gesehen
werden. Aber auch alle anderen Signale, die der Navigator aussendet, kann ein Eingabemodul
an den Benutzer weitergeben.
Seite 87

Kapitel 8, Multimodale Interaktion
Wenn ein Eingabegerät die Information eines Zeigegerätes interpretiert, benötigt es Zugriff
auf den Szenengraphen um Zeigegesten mit Objekten in der Szene in Beziehung zu
bringen. So kann man mit einer Maus auf ein Objekt klicken. Die bildschirmbezogene 2D
Position des Mauscursors könnten in eine Ebene des Weltkoordinatensystems und den
dazugehörigen Projektionsstrahl abgebildet werden. Dieser Strahl kann mit der in der
Szene vorhandenen Geometrie verglichen werden, um einen Schnittpunkt zu erhalten.
8.3.3 Kommunikationskanä le
Für die verschiedenen Informationsarten und -richtungen existieren drei Kommunikationskanäle.
Die von den SHM Dekodern erkannten Gesten und sprachlichen Äußerungen
werden als kontextfreie Grammatik über einen Kanal zum diskreten Integrator transportiert,
der in einer Bus-Struktur aufgebaut ist. Alle Eingabemodule sind gleichberechtigt
angeschlossen und können in den Kanal senden. Der diskrete Integrator ist der einzige
Empfänger. Da die genaue Bedeutung von miteinander in Verbindung stehenden Kommandos
davon abhängen kann, von welchen Modalitäten die Teile gesendet werden, wird
jedem auf dem Kanal übertragenen Kommando ein Identifikationscode der Modalität vorangestellt.
Dieser Kanal ist in Abb. 18 bei Farbdarstellung grün dargestellt.
Die Verteilung der Statusänderungen und Ereignisse, die im Navigator Modul auftreten,
werden mit einem zweiten Kanal vom Navigator zu allen haptischen Interpreter und dem
diskreten Integrator transportiert. Dieser Kanal ist ebenfalls als Bus aufgebaut, jedoch
hat er nur einen Sender und eine Vielzahl von Empfängern. Er ist in Abb. 18 rot dargestellt.
Der dritte, in Abb. 18 blau dargestellte, Kommunikationskanal überträgt Bewegungsinformationen
von den haptischen Interpreter und vom Navigator zum diskreten Integrator.
Dieser Kanal ist sternförmig aufgebaut, da die Bewegungen der einzelnen Modalitäten
im diskreten Integrator additiv überlagert werden. In Anlehnung an die Einteilung
von haptischen Eingabegeräten in relative Eingabegeräte, positionale Eingabegeräte und
Zeigegeräte wird dieser Kanal sowohl Geschwindigkeitswerte als auch Positionsdifferenzen
der beiden in Abschnitt 5.1.3 definierten Richtungssysteme transportieren. Zeigegeräte
werden im wesentlichen durch eine Position im Raum repräsentiert. Sie können zur
Navigation nur dann verwendet werden, wenn diese Position in Geschwindigkeitswerte,
Positionsdifferenzen oder Kommandos übersetzt werden.
Eine weitere Verbindung besteht vom diskreten Integrator zum Navigator. Diese transportiert
die vom diskreten Integrator aufgelösten Kommandos. Diese sind eine Teilmenge
der Kommandos, die der diskrete Integrator von den SHG Erkennern und den haptischen
Interpretern erhält.
Die SHG Erkenner können ihre Erkennungsleistung erhöhen, wenn sie Wissen über die
Wahrscheinlichkeit auftretender Äußerungen des Benutzers zur Verfügung haben. Deshalb
lesen auch sie den Kanal für Statusaktualisierungen mit, und der Diskrete Integrator
sendet Information über innere Zustände in diesen Kanal. Diese Kommunikation ist in
Abb. 17 jedoch nicht eingezeichnet, da sie die prinzipielle Funktionsweise des Systems
nicht beeinflußt.
Seite 88

8.3.4 Diskreter Integrator
Kapitel 8, Multimodale Interaktion
Das im ursprünglichen Bediensystem Integrator genannte Modul wurde zu diskreter Integrator
umbenannt, da noch ein kontinuierlicher Integrator für die haptischen Modalitäten
hinzukommt. Der diskrete Integrator erhält alle Kommandos der semantisch höherwertigen
und der haptischen Interpreter. Diese Kommandos beschreiben häufig nicht
ein-eindeutig eine auszuführende Aktion, sondern können mit Kommandos der selben
oder einer anderen Modalität in konkurrierender, komplementärer oder redundanter Weise
in Beziehung stehen. Aufgabe des Integrators ist es, diese Mehrdeutigkeiten aufzulösen
und im eindeutige und vollständige Kommandos an den Navigator zu senden. Damit
er dasselbe Modell der Anwendung wie der Benutzer aufbauen kann, liest er die Statusänderungen
und Navigationsereignisse, die der Navigator signalisiert, mit.
8.3.5 Navigator
Der Navigator führt die Befehle, die der Benutzer der Anwendung erteilt, aus. Zu seinem
Funktionsumfang gehört das Ausführen der Befehle zur diskreten Navigation, das Verwalten
des Navigationsmodus, der Navigationsgeschwindigkeit, des Drehzentrums, der
Viewpointliste, und das Ausführen einer Viewpoint-Animation wenn ein Viewpoint angesprungen
wird. Zudem analysiert er die Bewegungen des Benutzers und gibt relevante
Ereignisse an die Eingabemodule und den diskreten Integrator weiter. Um den Befehl
‚Rückgängig’ implementieren zu können verwaltet der Navigator einen Speicher, der die
letzten Werte von Parametern vor einer Veränderung speichert.
Änderungen von Navigationsparametern wie z.B. des Navigationsmodus können durch
vom diskreten Integrator empfangene Kommandos oder durch Ereignisse aus der Szene
oder der Applikationslogik ausgelöst werden. Diese Änderungen werden vom Navigator
an die haptischen Interpreter und den diskreten Integrator gesandt. Dadurch können
diese Module auf den tatsächlichen Zustand eines solchen Parameters reagieren, unabhängig
davon ob der Parameter von demselben Eingabemodul, einem anderen Eingabemodul
oder der Anwendung verändert wurde. Erhält der Navigator ein Kommando zur
diskreten Navigation, erzeugt er für kurze Zeit entsprechende Bewegungsinformationen
und sendet diese zum kontinuierlichen Integrator.
Das Navigator Modul kann in drei Submodule aufgeteilt werden, die in Abb. 19 dargestellt
sind. Neben dem eigentlichen Navigator, der die Kernfunktionen des Navigators enthält,
existiert ein Undo Puffer und ein diskreter Navigator.
Kommandos vom Integrator
Status Änderungen
undo
Puffer
eigentlicher
Navigator
Diskrete
Navigation
world modification
world state
Abb. 19: Interner Aufbau des Navigator Moduls
velocities to discrete integrator
Das control undo Kommando scheint auf den ersten Blick ein kontextsensitives Kommando
zu sein. Da es zu seiner Ausführung auf Information zurückgreift, die der diskrete
Integrator zu seinem sonstigen Betrieb nicht benötigt, und da das Rückgängig Machen
eines Kommandos in seiner Natur verschieden von gewöhnlichen Kommandos ist, wird
dieses Kommando vom diskreten Integrator nicht aufgelöst sondern direkt an den Navigator
gesandt.
Seite 89

Kapitel 8, Multimodale Interaktion
Der Undo Puffer ist als LIFO Speicher organisiert. In diesen legt der eigentliche Navigator
vor der Ausführung eines Kommandos den Zustand der Werte ab, die das Kommando
verändert. Bei einem Kommando zur diskreten Navigation (z.B. walk trans forward) wird
die aktuelle Position und Orientierung des Avatars abgespeichert. Bei einem control
viewpoint * Kommando legt der Navigator eine Referenz auf den momentan gebundenen
Viewpoint Knoten und die Position und Orientierung des Avatars ab. Die Referenz auf den
Viewpoint Knoten ist wichtig, weil der Viewpoint das Koordinatensystem definiert, bezüglich
dessen die Navigation durchgeführt wird. Die Position und Orientierung des
Avatars ist nötig, da der Benutzer von dem Viewpoint weg navigiert haben könnte, bevor
er das control viewpoint * Kommando abgesetzt hat.
Wenn der Navigator ein control undo Kommando erhält, liest er den als letztes im Undo
Puffer abgelegten Zustand und stellt ihn wieder her. Damit Feedback-Module den Benutzer
über die rückgängig gemachte Aktion oder über ein aufgrund eines leeren Undo Puffers
fehlgeschlagenes control undo Kommando unterrichten können, signalisiert der Navigator
diese Ereignisse am Status Kanal.
Kommandos zur diskreten Navigation werden vom Submodul diskreter Navigator ausgeführt.
Nachdem der Navigator die aktuelle Position des Avatars im Undo Puffer abgespeichert
hat, übergibt er das Kommando an den diskreten Navigator. Dieser erzeugt daraufhin
für kurze Zeit Bewegungsinformationen, die der angegebenen Richtung und der eingestellten
Schrittweite entsprechen, und sendet sie an den kontinuierlichen Integrator.
8.3.6 Kontinuierlicher Inte grator
Der kontinuierliche Integrator ist das haptische Pendant zum diskreten Integrator. Jedoch
ist seine Funktionsweise völlig unterschiedlich. Die Bewegungsinformationen von den
haptischen Interpreter und dem Navigator werden komponentenweise addiert und entsprechend
des aktuell gültigen control mode restrict Kommandos unterdrückt. Obwohl in
Abb. 18 aus Gründen der Übersichtlichkeit nicht eingezeichnet, erhält der kontinuierliche
Integrator vom Navigator entsprechende Steuerinformation, damit er das control mode
restrict Kommando korrekt anwenden kann. Die resultierenden Bewegungsinformationen,
die in den zwölf Richtungen des SIXDOF und EXAMINE Richtungssystems dargestellt
werden, werden in die sechs Freiheitsgrade des dreidimensionalen Raumes umgerechnet
und der Kollisionserkennung und Gravitationssimulation zugeführt.
8.3.7 Feedback-Modul
In Abb. 18 ist ein dediziertes Feedback-Modul angedeutet. Derartige Module geben für
den Benutzer wichtige Information an diesen weiter. Läuft die Anwendung auf einem
Bildschirmarbeitsplatz, könnte dieses Feedback-Modul durch eine konventionelle graphische
Benutzungsoberfläche realisiert werden, die außerhalb des 3D Fensters den Navigationsmodus,
die aktuelle Schrittweite, den Namen des aktiven Aussichtspunktes, usw.
anzeigt. Tritt eine Kollision auf, kann ein akustisches Signal ausgegeben werden. Ein
Sprachausgabemodul wäre eine andere Möglichkeit, die Information, die der Navigator
aussendet an den Benutzer weiterzugeben.
8.4 Erweiterung des Fu nktionsumfangs
Ausgehend von der in Abschnitt 8.1.2 vorgestellten Grammatik wird untersucht, um welche
Funktionen der Befehlsumfang erweitert werden muß, damit die hinzugekommenen
haptischen Modalitäten in den multimodalen Bedienprozeß mit einbezogen werden können.
Zudem wird eine Grammatik beschrieben, mit der die Statusänderungen ausgedrückt
werden können, die der Navigator den haptischen Eingabegeräten und dem dis-
Seite 90

Kapitel 8, Multimodale Interaktion
kreten Integrator mitteilt. Die verwendeten Grammatiken werden in diesem Kapitel
Schritt für Schritt entwickelt. Im Anhang C werden diese noch einmal in zusammenhängender
Form angegeben.
Die Abschnitte 8.4.1 bis 8.4.3 beschreiben wie die Module auf die neuen Befehle reagieren.
Dazu müssen auch Konstrukte aus dem Formalismus für Statusänderungen genannt
werden, die erst in Abschnitt 8.4.4 erläutert werden. Dies sei als allgemeine Vorwärtsreferenz
auf diesen Abschnitt verstanden.
Der Grundsätzliche Aufbau der Grammatik als eine Folge von Kommandos bleibt gleich.
S ::=
::= |
8.4.1 Quasikontinuierlichen Navigation
Wegen der hohen Verzögerungszeiten und der ungenauen Ausdrucksmöglichkeit bei
Richtungs- und Positionsangaben über die natürliche Sprache oder über andere semantisch
höherwertige Modalitäten wurde im ursprünglichen MIVIS System die diskrete Navigation
eingeführt, da mit ihr diese Schwierigkeiten überwunden werden können[12].
Haptische Eingabegeräte bieten prinzipiell die Möglichkeit, Richtungsangaben genau anzugeben
und diese schnell zu ändern.
In Kombination mit semantisch höherwertigen Modalitäten könnte das Szenario etwa so
aussehen, daß der Benutzer, wenn er größere Distanzen zurücklegen möchte, eine Geste
macht, die „Ich will fliegen.” bedeutet. Danach beginnt sich der Avatar zu bewegen, und
der Benutzer kann die Richtung der Bewegung während des Fluges mit einem haptischen
Eingabegerät bestimmen. Die Fluggeschwindigkeit kann der Benutzer mit Hilfe der Kommandos
„Schneller!” und „Langsamer!” steuern. Der Flug dauert solange an, bis der Benutzer
„Stop!” sagt, oder ein anderes, dem Fliegen widersprechendes Kommando absetzt.
Ein Vorteil gegenüber dem rein über das haptische Eingabegerät initiierten Flug ist,
daß alle Freiheitsgrade des Eingabegerätes zur Richtungsangabe zur Verfügung stehen.
Bei einem Eingabegerät mit nur zwei Freiheitsgraden wie der Maus ist der Flugmodus
sonst schwer zu realisieren. Ein anderes Szenario ergibt sich im EXAMINE Modus: Der
Benutzer könnte das Objekt mit einem Sprachkommando in langsame Drehung versetzen,
und die Drehrichtung mit dem Eingabegerät bestimmen.
Erweiterte Grammatik
Diese Vorgänge werden im Folgenden quasikontinuierliche Navigation genannt. Für die
kontextfreie Grammatik bedeutet quasikontinuierliche Navigation, daß den Kommandos
zur diskreten Navigation das Symbol start vorangestellt werden kann, und daß ein
Kommando stop eingeführt wird.
::= | |
::= start
::= stop
Ausführung der Funktion
Erhält der Navigator ein Kommando mit vorangestelltem start, erzeugt er dieselbe Bewegung,
die er ohne diesen Präfix erzeugen würde, hält sie aber bis auf weiteres aufrecht.
Da diese Bewegung mit den Bewegungen anderer Eingabegeräte additiv überlagert
wird, können diese durch Erzeugen von Drehbewegungen die Bewegungsrichtung beeinflussen.
Sind auf einem Eingabegerät genügend Freiheitsgrade vorhanden, können einige
davon translatorische Bewegungen erzeugen, wodurch Objekten leichter ausgewichen
werden kann. Damit die haptischen Interpreter in einen entsprechenden Modus umschalten
können, sendet der Navigator das Signal mode continous on an die Eingabemodu-
Seite 91

Kapitel 8, Multimodale Interaktion
le. Die quasikontinuierliche Bewegung wird beendet, wenn der Navigator ein stop Kommando
oder eine Kommando aus der Gruppe erhält.
8.4.2 Referenzierende Nav igation
Eine ganz besonders natürliche Art der Kommunikation zwischen Mensch und Maschine
ergibt sich, wenn man die besonderen Fähigkeiten einzelner Modalitäten miteinander
kombiniert. Auch im Alltagsleben werden mehrere Modalitäten kombiniert, z.B. wenn
jemand mit der Hand in eine Richtung zeigt und sagt: „Gehen sie diese Straße runter, an
der nächsten Kreuzung rechts, ...”. Mit Zeigegeräten, z.B. einem Touchscreen läßt sich
sehr einfach auf Objekte zeigen, und mit der natürlichen Sprache kann angegeben werden,
was damit passieren soll. Für das Paradigma der Navigation in 3D Welten können
folgende Szenarien identifiziert werden:
Der Benutzer zeigt mit dem Touchscreen auf ein Objekt und sagt...
• ... „Ich will dort hin gehen.”
Das löst eine Viewpoint-Animation aus, die den Avatar an eine Position in die Nähe
des Objekts bringt.
• ... „Ich will das näher anschauen.”
Das schaltet in den EXAMINE Modus und definiert das Objekt als Drehzentrum. Diese
Art der Navigation wäre in einer virtuellen Kunstgalerie, oder in einem Kaufhaus sehr
nützlich.
• ... „Ich will dem folgen.”
Das verbindet den Avatar mit dem angegebenen Objekt, und immer wenn sich das
Objekt bewegt, folgt der Avatar dieser Bewegung, und bleibt dadurch immer in der
Nähe dieses Objektes. Weitere Bewegungen über haptische Eingabegeräte oder durch
diskrete Navigation werden relativ zum Objekt ausgeführt. In mehrbenutzerfähigen
Anwendungen könnte diese Funktion den Benutzern helfen, die Welt gemeinsam zu
durchwandern, wenn ein Benutzer den Avatar des anderen als zu folgendes Objekt
benutzt. Wenn diese Funktion von der Anwendung selbst ausgelöst wird, können vom
Computer gesteuerte Agenten Führungen durch die Welt veranstalten.
Erweiterte Grammatik
Die Erweiterung der Grammatik auf referenzierende Navigation bedeutet, daß eine neue
Gruppe von Kommandos, die Gruppe eingeführt wird. Diese unterteilt sich in
drei Untergruppen: Die Gruppe modelliert, was mit einem Objekt, einer Position
oder einer Richtung passieren soll, und modelliert alle Möglichkeiten
in der eine Zeigegeste vorkommen kann. Beide Gruppen enthalten kontextabhängige
Kommandos. In der Gruppe sind die möglichen Kombinationen der Kommandos
aus diesen beiden Gruppen zu kontextfreien Kommandos zusammengefaßt.
::= | | | |
::= | |
Gemäß den obigen drei Beispielen ergibt sich zu:
| ::= gothere
| ::= lookat
| ::= setexacenter
| ::= follow
Mit gothere und lookat wird ausgedrückt, daß der Benutzer an eine bestimmte Position
bewegt werden will, bzw. daß er in eine bestimmte Richtung schauen will. Das Kommando
setexacenter drückt aus, daß die angegebene Position zum neuen Drehzentrum werden
soll, und follow beschreibt den Wunsch, einem anderen Objekt zu folgen.
Seite 92

Kapitel 8, Multimodale Interaktion
Wenn der Benutzer auf Objekte zeigen kann, und diese Objekte beweglich sein können,
dann wird es erforderlich, daß der Browser und die Anwendung das Konzept definierbarer
Objekte unterstützen muß. Die VRML Technologie unterstützt z.B. kein solches Konzept.
Es können zwar Teile der Szene bewegt werden, diese unterscheiden sich aber technisch
nicht von anderen Teilen der Szene und sind dadurch nicht vom Browser als Objekte erkennbar.
Deshalb wird in diesem Absatz eine Grammatik für die Gruppen
und vorgestellt, die ohne die Unterstützung eines Objekt Konzeptes auskommt.
Die Funktion, einem Objekt zu folgen, kann deshalb nicht unterstützt werden. In
Abschnitt 9.3.2 wird ein Ansatz für eine Erweiterung dieser Grammatik vorgeschlagen,
der das Referenzieren beweglicher Objekte unterstützt.
Die Gruppe setzt sich aus Kommandos, die ein Objekt referenzieren, und
aus solchen, die eine reine Position oder Orientierung im Raum ohne Bezug auf ein Objekt
bezeichnen, zusammen.
| ::= indicated
| ::= indicated geometry
: ::= pos
: ::= ori
: ::= posori
: ::= posdir
: ::= dir
:
: ::=
: ::=
: ::=
Die Kommandos indicated bezeichnen Gesten, mit denen der Benutzer eine
Position im Raum, eine Richtung oder beides angibt. Mit wird ein Punkt im
Raum bezeichnet, beschreibt die Ausrichtung eines Zeigegerätes in Achse-
Winkel Form (Richtungsvektor einer Drehachse und Drehwinkel), und bezeichnet
einen Richtungsvektor. Die Position wird nicht mit einem Objekt der Szene in
Beziehung gebracht. Die Grammatikvariable ist formal gleichbedeutend mit
, denn beide werden durch drei float Zahlen dargestellt. Sie wurde aber eingeführt,
um dem Leser Klarheit über die unterschiedliche Bedeutung zu schaffen. Bezugskoordinatensystem
für alle Angaben ist das Weltkoordinatensystem.
Der diskrete Integrator wird die Positions- und Richtungsangaben nicht auswerten, da sie
Applikationswissen darstellen und die Applikationsunabhängigkeit ein Grundsatz für das
MIVIS System ist. Der diskrete Integrator wird jedoch darüber entscheiden, ob er sie an
den Navigator weitergibt. Insofern sind diese Daten für den diskreten Integrator wie ein
opaquer Datentyp zu betrachten.
Mit dem Kommando indicated geometry wird ausgedrückt, daß der Benutzer
auf ein Objekt der Szene gezeigt hat. Dieses Kommando kann beispielsweise entstehen,
wenn der Benutzer mit der Maus auf einen Punkt einer Wand in der Szene klickt, oder
wenn er mit einem Zeigestab auf ein Objekt zeigt. Die angegebene Position beschreibt
einen Punkt auf dem Objekt in Weltkoordinaten.
Die dritte Gruppe der Kommandos zur referenzierenden Navigation ist die Gruppe
. Sie enthält die kontextfreien Kommandos, die entstehen, wenn Kommandos
aus den ersten beiden Gruppen kombiniert werden.
Seite 93

::= orientto pos
::= orientto dir
::= moveto
::= beamto pos
::= beamto watch
::= exacenter set
Kapitel 8, Multimodale Interaktion
Wenn der Navigator eines dieser Kommandos erhält, startet er eine entsprechende Viewpoint-Animation.
Alle Angaben beziehen sich auf das Weltkoordinatensystem. Die mit
orientto beginnenden Kommandos drehen den Avatar ohne seine Position zu ändern. Bei
orientto pos wird der Avatar so gedreht, daß er auf den angegebenen Punkt
sieht, und bei orientto dir so, daß er in die angegebene Richtung blickt. Beide
Angaben definieren eine Sichtachse, geben aber keine Rotation um diese Achse an. Es
obliegt dem Browser, diese im Sinne der Anwendung günstig zu wählen. Eine manuelle
Korrektur ist mit den weiter unten erläuterten Kommandos straighten und balance oder
mit den Kommandos für diskrete Navigation und mit haptischen Eingabegeräten möglich.
Kommandos, die mit moveto beginnen, beschreiben Bewegungen an eine vollständig spezifizierte
Position oder Richtung. Ist eine Position angegeben, wird der Avatar an diese
Position bewegt, ohne daß die Orientierung des Avatars geändert wird. Bei der Angabe
einer Orientierung dreht sich der Avatar in die angegebene Richtung, ohne sich zu Bewegen.
Der Unterschied zu den mit orientto beginnenden Kommandos liegt darin, daß hier
die Drehung mathematisch vollständig und eindeutig spezifiziert ist. Sind sowohl Position
als auch Orientierung angegeben, bewegt sich der Avatar entsprechend an den angegebenen
Ort und nimmt die angegebene Orientierung ein.
Die beiden mit beamto beginnenden Kommandos beschreiben Bewegungen, die der Navigator
nicht exakt ausführen muß. Bei aktivierter Gravitation bedeutet beamto pos, daß die
angegebene Position so modifiziert wird, daß der Avatar nach der Viewpoint-Animation
wieder auf dem Boden steht. Ist die Gravitation deaktiviert, ist die angegebene Position
das Ziel der Bewegung. Die Orientierung wird durch dieses Kommando nicht verändert.
Diese Regel bezüglich der Gravitation gilt ebenso für das Kommando beamto watch, jedoch
ist hier die angegebene Position ein Punkt der Szene, den der Benutzer aus der Nähe
sehen will. Der Navigator findet einen geeigneten Punkt und eine geeignete Blickrichtung.
Kann der Navigator nicht beide Ziele gleichzeitig erfüllen, z.B. weil die angegebene Position
viel zu weit oberhalb des Bodens liegt, dann hat das Ziel, den angegebenen Punkt
ansehen zu können, Vorrang.
Das Kommando exacenter set setzt das Drehzentrum für Bewegungen des
Examine Richtungssystems auf den angegebenen Punkt. Die Blickrichtung wird dabei
nicht geändert. Dazu muß der diskrete Integrator zusätzlich ein orientto Kommando
auslösen. Für die Funktion, einem sich bewegenden Objekt zu folgen, ist kein Kommando
in der Gruppe vorhanden, da der in diesem Abschnitt diskutierte Formalismus
bewegliche Objekte nicht unterstützt. Eine mögliche Erweiterung des Formalismus
beschreibt Abschnitt 9.3.2.
Ausführung der Funktion
Typischerweise werden Kommandos aus der Gruppe von SHM Erkennern
und Kommandos aus von haptischen Interpretern, die mit einem Zeigegerät
verbunden sind erzeugt. Der diskrete Integrator setzt diese miteinander in Beziehung,
z.B. wenn er Kommandos aus beiden Gruppen zu etwa der gleichen Zeit erhält, und sendet
entsprechende Kommandos aus der Gruppe an den Navigator. Der Navigator
erhält in keinem Fall Kommandos aus oder .
Alle Kommandos aus den Gruppen orientto, moveto und beamto geben entweder eine Position
oder eine Orientierung oder beides an. Sie unterscheiden sich darin, wie genau und
Seite 94

Kapitel 8, Multimodale Interaktion
in welcher Form diese Angaben gemacht werden. Viewpoint-Animationen, welche die
Position ändern, und solche, welche die Orientierung ändern, können getrennt voneinander
betrachtet werden. Unter diesem Gesichtspunkt sollten folgende Regeln gelten, die
auf dem Grundsatz beruhen, daß der Wunsch des Benutzers oberstes Gebot sei:
• Ein Kommando, das eine Positionsangabe erhält, ersetzt eine evtl. noch laufende
Animation der Position, wobei eine evtl. noch andauernde Animation der Orientierung
nicht berührt wird. Dies wird der Situation gerecht, daß der Benutzer zuerst ein
Kommando absetzt, das ihn in eine bestimmte Richtung bewegt, und dann die Orientierung
festlegt.
• Entsprechend dem gegenteiligen Fall, ersetzt ein Kommando, das eine Angabe der
Orientierung enthält ggf. eine bestehende Animation der Orientierung, läßt aber eine
Animation der Position unverändert.
• Kommandos, die beide Angaben enthalten ersetzen ggf. beide Animationen.
• Die nach der Animation resultierende Orientierung ist so zu wählen, daß die geforderte
Bedingung – anzusehender Punkt – bei Beendigung der Animation gelten soll.
Alle durch diese Kommandos ausgelösten Viewpoint-Animationen gelten als Typ B Animationen
im Sinne der in Abschnitt 7.2.4 vorgenommenen Kategorisierung.
8.4.3 Steuerkommandos
Die Grammatik für Steuerbefehle werden um die nachfolgend erläuterten Kommandos
erweitert. Im Unterschied zu den anderen Gruppen haben die Kommandos in der Gruppe
kaum Beziehungen zueinander. Der diskrete Integrator gibt sie meistens nur an
den Navigator weiter.
Die Wertebereiche für die Parameter der Kommandos waren beim ursprünglichen MIVIS
System auf die absoluten Formen beschränkt. Diese werden erweitert, um die möglichen
Äußerungen eines Benutzers genauer modellieren zu können. Beispielsweise wird der
Wertebereich von on | off auf on | toggle | off erweitert. Der diskrete Integrator
gibt die neuen Werte an den Navigator weiter, da dieser den aktuellsten Information über
einen Wert zur Verfügung hat. Es gelten somit folgende Wertebereiche:
: ::= walk | fly | examine
: ::= inc | dec | reset
: ::= on | off | toggle
: ::= prev | next | reset
: ::= all | stepsize | mode | light
: ::= viewpoint | collision | gravity
: ::= | end_list
: ::= x | y | z | yaw | pitch | roll | phi | omega | radius | rho | A | B
Mit wird ein Wertebereich definiert, der eine beliebige Kombination von Richtungen
der beiden Richtungssysteme beschreibt.
Die Gruppe der Kontrollkommandos wird durch einen Präfix control eingeleitet:
::= control
Es werden folgende Kommandos definiert:
::= mode set
::= mode restrict
Damit läßt sich einer der Navigationsmodi einstellen. Wird ein Navigationsmodus gesetzt,
dann wird die Aktivierung der Gravitationssimulation auf den durch den Modus bestimmten
Zustand (aktiv bei WALK, inaktiv bei FLY und EXAMINE) gesetzt, unabhängig von
einem vorausgehenden control gravity * Kommando. Das Kommando control mode
Seite 95

Kapitel 8, Multimodale Interaktion
restrict * gibt eine Reihe von Richtungen an, die unterdrückt werden. Der Benutzer
kann sich in diese Richtungen nicht bewegen. Diese Beschränkung wird aufgehoben,
wenn ein neuer Navigationsmodus mit dem control mode set * Kommando gesetzt wird.
::= stepsize
::= stepsize set
Damit kann die Schrittweite für Bewegungen der diskreten Navigation kontrolliert werden.
Es wird ein Faktor manipuliert, der mit der Grundschrittweite für jede der zwölf
möglichen Bewegungsrichtungen multipliziert wird.
::= speed
::= speed set
In ähnlicher Weise wie oben kann mit diesen Kommandos die nominelle Navigationsgeschwindigkeit
bei kontinuierlicher Navigation beeinflußt werden. Kann in der Applikation
ebenfalls eine nominelle Navigationsgeschwindigkeit definiert werden – in VRML geschieht
dies mit dem type Feld des NavigationInfo Knotens – dann werden die benutzerdefinierte
und anwendungsdefinierte nominelle Navigationsgeschwindigkeit getrennt verwaltet
und miteinander multipliziert.
::= light
Das kontrolliert in einem VRML Browser die Standardbeleuchtung der Szene durch ein
Headlight.
::= viewpoint
::= viewpoint tour
::= viewpoint set
::= viewpoint set
Mit den Kommandos können von der Anwendung definierte Aussichtspunkte angesprungen
werden. Dann kann mit den ersten beiden Formen diese Liste der Aussichtspunkte
vorwärts und rückwärts durchwandert werden und an den Ausgangsaussichtspunkt gesprungen
werden. Mit viewpoint tour wird eine Tour durch die Liste ausgelöst, indem alle
Aussichtspunkte der Liste nacheinander aufgerufen werden. Dieser Vorgang kann mit
dem stop Kommando oder einem anderen Navigationskommando beendet werden. Auch
eine Manipulation an einem haptischen Eingabegerät, die eine Bewegung des Avatars
auslöst, kann die Tour abbrechen. Falls ein Eingabemodul dem Benutzer eine Liste aller
Aussichtspunkte anzeigt, können diese mit control viewpoint set * direkt angesprungen
werden.
::= collision
::= gravity
Diese beiden Parameter erlauben es, die Gravitationssimulation und die Kollisionserkennung
zu aktivieren oder deaktivieren. Da über den Navigationsmodus die Aktivierung der
Gravitationssimulation implizit mitbestimmt wird, kann mit control gravity * dies überschrieben
werden. Die Eingabemodule sollen ihr Verhalten dadurch aber nicht ändern,
d.h. sie sollen nach einem control gravity off Kommando im WALK Modus auf Eingaben
genauso reagieren, wie bei aktivierter Gravitation. Wird der Navigationsmodus mit dem
Kommando control mode set * gesetzt, wird die Simulation der Gravitation wieder in den
durch den Navigationsmodus definierten Zustand gebracht.
::= straighten
::= balance
Das sind zwei Befehle, die den Avatar wieder in eine senkrechte Lage bringen. Mit control
straighten wird der Avatar entlang des Lot-Vektors ausgerichtet. Mit control balance wird
er nur soweit ausgerichtet, daß er weder nach links noch nach rechts geneigt ist. Die
Neigung nach oben oder unten wird dadurch nicht beeinflußt. Gemäß der Kategorisierung
in Abschnitt 7.2.4 gelten diese Bewegungen als Typ C Animationen.
Seite 96

| ::= repeat
::= undo
Kapitel 8, Multimodale Interaktion
Durch diese Kommandos können Befehle wiederholt oder rückgängig gemacht werden.
Da control repeat vom diskreten Integrator aufgelöst werden kann, ist es als kontextsensitives
Kommando eingestuft. Das control undo Kommando muß vom Navigator aufgelöst
werden, da dieser den Undo Puffer mit den in der letzten Zeit veränderten Werten verwaltet.
::= sendstatus
::= quit
Das control sendstatus * Kommando erlaubt einem Modul explizit eine Statusmeldung
vom Navigator anzufordern. Der Navigator signalisiert zwar alle Parameter bei Veränderung
sofort, aber in der Initialisierungsphase oder wenn ein Eingabemodul während des
Betriebes in das System integriert werden kann, haben nicht alle Module alle Statusinformationen
zur Verfügung.
Mit dem control quit Kommando kann die Anwendung beendet werden. Dieses Kommando
sollte der Navigator idealerweise an die Anwendung weitergeben, damit diese
eine Rückfrage beim Benutzer durchführen, nicht gespeicherte Daten speichern und sich
dann beenden kann.
8.4.4 Formalismus für Stat us Anzeigen
Damit die haptischen Interpreter und der diskrete Integrator korrekt funktionieren können,
müssen sie über eine Reihe von Zuständen informiert werden, die im Navigator
auftreten. Außerdem sollte der Benutzer über einige Ereignisse Rückkopplung erhalten,
die auftreten während er durch die Szene navigiert. Auch diese Information steht im Navigator
zur Verfügung. Beide Arten von Information werden über den in Abb. 18 rot dargestellten
Kommunikationskanal übertragen. Sie werden durch folgende Grammatik beschrieben:
S ::=
::= |
Ebenso wie die Grammatik für Benutzerkommandos besteht die Grammatik für Statusinformationen
aus einer Folge von Informationseinheiten.
::= status
Jeder dieser Informationseinheiten wird durch das Symbol status eingeleitet. Dadurch
kann für die Kommunikationskanäle eine Implementierung gewählt werden, die beide
Grammatiken auf nur einem tatsächlichen Kanal transportiert.
Ähnlich wie bei Benutzerkommandos werden Wertebereiche definiert. Diese beschreiben
jedoch nur den tatsächlichen Zustand und enthalten keine Symbole für Zustandsübergänge:
: ::= walk | fly | examine
: ::= on | off
: ::= | end_list
: ::= x | y | z | yaw | pitch | roll | phi | omega | radius | rho | A | B
: ::=
: ::= | end_list
::= mode mode
::= mode continuous
::= mode restricted
Seite 97

Kapitel 8, Multimodale Interaktion
Diese Gruppe beschreibt die Art der Navigation. Die haptischen Interpreter müssen den
Navigationsmodus, der durch status mode mode beschrieben wird, in der
Art, wie sie die Signale der Eingabegeräte interpretieren, verwirklichen. Der Navigator
sendet diese Statusinformation immer dann, wenn eine Modusänderung auftritt.
Das mit status mode continuous übertragene Flag dient als Modifizierer für den
Navigationsmodus. Wird on übertragen, dann hat der Navigator in den Modus der quasikontinuierlichen
Navigation geschaltet und erzeugt eine fortlaufende Bewegung. Haptische
Interpreter sollten die Interpretation des Eingabegerätes an diesen Umstand anpassen
und hauptsächlich Drehbewegungen erzeugen. Der mit status mode mode
definierte Navigationsmodus gilt dabei als Vorlage: Bei WALK und FLY
werden hauptsächlich Bewegungen der Richtungen yaw, pitch und roll erzeugt, und bei
EXAMINE hauptsächlich φ, ω und ρ. Das Signal status mode continuous off schaltet die
haptischen Interpreter wieder in den normalen Navigationsmodus zurück.
Das Signal status mode restricted nennt alle Richtungen, die der Kontinuierliche
Integrator unterdrückt. Eingabegeräte können zwar Bewegungen in diese Richtung erzeugen,
diese führen jedoch zu keiner Bewegung des Avatars. Für manche Eingabegeräte
kann es sinnvoll sein, die Umsetzung der Freiheitsgrade des Eingabegerätes in Bewegungsrichtungen
entsprechend anzupassen. Für ein Eingabegerät mit nur wenigen Freiheitsgraden,
das diese abhängig vom Zustand einiger Schalter auf dem Gerät in Bewegungsrichtung
umsetzt, kann das Signal status mode restricted bedeuten, daß alle
Freiheitsgrade im unmodifizierten Betrieb unterdrückt werden. Dann sollte dieses Eingabegerät
in einen der modifizierten Modi umschalten.
Wenn der Navigator einen neuen Navigationsmodus signalisiert, dann gelten die quasikontinuierliche
Navigation automatisch als abgeschaltet, und alle Bewegungsrichtungen
als erlaubt. Das bedeutet, daß nach dem Signal status mode mode implizit
status mode continuous off und status mode restricted end_list gelten, sofern der Navigator
nicht etwas Gegenteiliges signalisiert. Ebenso wird das im Folgenden beschriebene
status mode gravity * Flag auf den vom eingestellten Modus abhängigen Defaultwert gesetzt.
::= stepsize
::= speed
::= light
::= collision
::= gravity
::= viewpoint activated
::= viewpoint list_changed
Die Signale status stepsize * und status speed * geben den vom Benutzer eingestellten
Faktor für die Schrittweite bei diskreter Navigation bzw. für die Navigationsgeschwindigkeit
bei kontinuierlicher Navigation an. Das Feedback-Modul sollte beide Werte dem Benutzer
anzeigen. Eingabemodule sollten translatorische Bewegungen in den Richtungen
x, y und z mit dem in status speed * angegebenen Faktor multiplizieren.
Mit status light * wird der Zustand des in VRML verwendeten Headlights angezeigt, das
zur standardmäßigen Ausleuchtung einer Szene dient.
Der Aktivierungszustand der Kollisionserkennung und Gravitationssimulation wird mit
status collision * und status gravity * angezeigt. Eingabemodule sollten die Übersetzung
der Freiheitsgrade des Eingabegerätes in Bewegungsrichtung von diesen beiden
Flags nicht abhängig machen. Das mit status gravity * signalisierte Flag wird durch ein
status mode mode * Signal zurückgesetzt.
Wird ein Aussichtspunkt angesprungen, dann signalisiert der Navigator dies mit dem
status viewpoint activated * Signal. Der erste Parameter gibt die Nummer des Aussichtspunktes
in der Liste aller Aussichtspunkte an, der zweite Parameter die Länge dieser Liste
Seite 98

Kapitel 8, Multimodale Interaktion
und der dritte Parameter eine für Menschen lesbare Beschreibung des Aussichtspunktes.
Im Bezug auf VMRL ist der letzte Parameter das description Feld des Viewpoint Knotens,
und das status viewpoint activated * Signal zeigt das Binden eines Viewpoint Knotens
an. Ändert sich in der Anwendung die Liste der Aussichtspunkte, z.B. wenn ein anderer
Raum betreten wird, so wird dies mit dem status viewpoint list_changed * Signal
angezeigt. Dadurch kann ein Eingabemodul mit entsprechenden Möglichkeiten dem Benutzer
eine Liste aller Aussichtspunkte zur Auswahl anzeigen. In bildschirmorientierten
Anwendungen könnte diese Liste z.B. durch ein aufklappbares Menü realisiert werden.
Der erste Parameter gibt die Länge der Liste an. Darauf folgt eine Liste der Beschreibungen
aller Aussichtspunkte.
::= isbeaming
::= collided
::= undoing nothingstored
::= undoing
::= light | collision | gravity | mode | position | viewpoint
Es kann vorkommen, daß ein Eingabegerät Signale erzeugt, die, nachdem sie vom Benutzer
ausgelöst wurden, noch eine kurze Zeit andauern. In Abschnitt 7.2.4 werden solche
Fälle im Zusammenhang mit Typ D Animationen diskutiert. Damit solche Animationen
nicht eine Viewpoint-Animation überdauern und damit der Benutzer nicht versehentlich
eine Viewpoint-Animation wegen eines empfindlichen Eingabegerätes abbricht, kündigt
der Navigator eine Viewpoint-Animation mit dem Signal status isbeaming on an und
sendet nach deren Beendigung das Signal status isbeaming off.
Kollisionen des Avatars mit Objekten der Szene werden mit status collided * angezeigt.
Die mit diesem Signal übertragene Information beschreibt die Kollision. Der Umfang dieser
Information kann von Anwendung zu Anwendung verschieden sein, sollte aber mindestens
einen Vektor beinhalten, der ähnlich dem collided Feld des in Abschnitt 7.2.2
definierten NavigationSensor Knotens eine Richtung angibt, die der Kollision entgegen
wirkt. Die in dieser Arbeit durchgeführte Implementierung überträgt die Information dieses
collided Feldes.
Der Navigator sendet die Signale status undoing * als Reaktion auf ein control undo
Kommando aus. Der Parameter gibt an, welche Art von Aktion rückgängig gemacht wird.
Kommandos der diskreten Navigation werden mit status undoing position rückgängig
gemacht. Ist mit diesem Vorgang eine Viewpoint-Animation verbunden (position oder
viewpoint), dann folgt dem Signal ein status isbeaming on und später ein status isbeaming
off Signal.
8.5 Implementierung
Für die Implementierung des erweiterten MIVIS Systems wird aus folgenden Gründen die
Sprache VRML mit der Script Sprache VrmlScript gewählt:
• Für den Zugriff auf Eingabegeräte und für die Steuerung der Bewegungen des Avatars
stehen die im ersten Teil dieser Arbeit entwickelten VRML Knoten zur Verfügung.
Durch deren Verwendung wird das Konzept, das ihnen zugrunde liegt, validiert.
• Zudem muß insbesondere der kontinuierliche Integrator und der Kommunikationskanal
für die Bewegungsinformationen nicht mehr implementiert werden, da mit dem
Navigator Knoten die entsprechende Funktion des Browsers genutzt wird.
• Dadurch, daß VRML und VrmlScript plattformunabhängige Sprachen sind, ist eine
spätere Erweiterung leicht möglich.
Seite 99

Kapitel 8, Multimodale Interaktion
• Code, der den eingesetzten Formalismus verarbeitet, läßt sich in VrmlScript gut darstellen
16 .
• Die Infrastruktur des erweiterten Systems besteht aus Modulen, die über ereignisbasierte
Kanäle kommunizieren. Dies läßt sich gut auf die VRML Konzepte des Proto Mechanismus
und des Routengraphen abbilden.
8.5.1 Verwendung von VRM L/VrmlScript
Jede der in Abb. 18 dargestellten Systemkomponenten wird, sofern nötig oder möglich
durch eine Proto Instanz in einer eigenen VRML Datei nachgebildet. Ausnahmen hiervon
bilden der kontinuierliche Integrator und die SHM Erkenner. Der kontinuierliche Integrator
ist Teil des Browsers und muß daher nicht in VRML implementiert werden. Näheres
beschreibt Abschnitt 8.5.4. Die SHM Erkenner kommunizieren über TCP Verbindungen
direkt mit dem diskreten Integrator und werden dadurch mit diesem in das System eingebunden.
Eine Hauptdatei namens NavWelder.wrl lädt alle Systemkomponenten mit dem
EXTERNPROTO Statement und stellt den Informationsfluß mittels Routen her. Diese Datei
kann ebenfalls als EXTERNPROTO in eine bestehende Welt geladen werden, wodurch diese
um die Fähigkeit zur Multimodalen Navigation erweitert wird.
Die folgende Tabelle zeigt die Zuordnung von Systemkomponenten zu Dateinamen und
Name des Protos:
Systemkomponente Dateiname Proto Name
Hauptdatei / Kommunikationskanäle: NavWelder.wrl Navigation
Navigator: Navigator.wrl Navigator
diskreter Integrator: Integrator.wrl Integrator
kontinuierlicher Integrator: Teil der Browser Implementierung
Maus und Tastatur Interpreter: Teil der Browser Implementierung
Joystick Interpreter: Joystick.wrl JoystickNavigation
Spacemouse Interpreter: Spacemouse.wrl SpacemouseNavigation
SHM Erkenner: kommunizieren direkt mit dem diskreten Integrator
Undo Puffer: UndoBuffer.wrl UndoBuffer
Diskreter Navigator: DiscreteNavigator.wrl DiscreteNavigator
Abb. 20 faßt die implementierte Struktur zusammen. Die gepunktete Linie trennt Systemkomponenten
des ursprünglichen Systems, die in mehreren Prozessen auf unterschiedlichen
Plattformen laufen, von den Komponenten, die innerhalb des VRML Browsers blaxxun
Contact ausgeführt werden. Während unterhalb der gepunkteten Linie die ohne
Schatten dargestellten Blöcke Systemkomponenten des Browsers darstellen, die schon
existierten oder erweitert wurden, symbolisieren die Blöcke mit Schattierung Teile des in
VRML implementierten Szenengraphen. Die äußeren Blöcke stellen Proto Instanzen dar,
deren innerer Szenengraph angedeutet wird.
16
VrmlScript ist im Wesentlichen eine um die Datentypen von VRML erweiterte Version von
JavaScript.
Seite 100

Maus
Interpreter
Tastatur
Interpreter
JoystickNavigation
JS
Maus
Interpreter
Maus
Interpreter
Maus
Interpreter
S
N
SpacemouseNavigation
SM
S
N
Diskreter
Integrator
DiskreterIntegrator
Kapitel 8, Multimodale Interaktion
TCP
Filter
~
Navigator
externe Prozesse
blaxxun Contact
Navigation
Kollisionserkennung
&
Gravitation
Abb. 20: Struktur der Implementierung des erweiterten MIVIS Systems
8.5.2 Kommunikationskanä le
Es existieren im System zwei Kommunikationskanäle, die zeitdiskrete Kommandos bzw.
Statusaktualisierungen in den beiden in Abschnitt 8.4 definierten kontextfreien Grammatiken
übertragen. Diese werden als Routen, die den Typ MFString transportieren, in der
Datei NavWelder.wrl realisiert. Der Kanal für Kommandos des Benutzers transportiert
Worte (im Sinne einer Grammatik), die der Variable genügen. Jedes Terminalsymbol
wird einem eigenen Arrayelement des Typs MFString zugeordnet. Dadurch vereinfacht
sich das Parsen im Empfänger auf den Zugriff auf Arrayelemente. Der Kanal für
Statusänderungen transportiert ebenfalls Worte einer Grammatik, jedoch genügen diese
der Variablen . Auch hier wird der Typ MFString verwendet, um das Parsen zu
vereinfachen.
Seite 101

Kapitel 8, Multimodale Interaktion
Der dritte Kommunikationskanal transportiert kontinuierliche Bewegungsinformationen.
Dieser ist Teil der Implementierung des Navigator Knotens und damit Teil des Browsers.
Seine Funktionsweise wurde in Abschnitt 7.3 erläutert.
8.5.3 Diskreter Integrator
Der diskrete Integrator ist Teil des ursprünglichen MIVIS Implementierung und kommuniziert
mit dem Rest des Systems über Netzwerkverbindungen mit dem TCP Protokoll. Es
werden ASCII Texte übertragen, die in jeder Zeile genau ein der Variablen entsprechendes
Kommando, bzw. eine der Variablen entsprechende Statusaktualisierung
enthalten. Jeder Zeile wird eine in der Regel drei Zeichen lange Empfängerkennung
und eine ebenfalls meist drei Zeichen lange Senderkennung vorangestellt. Die
Senderkennung hilft dem diskreten Integrator, einzelne Modalitäten in bestimmten Fällen
gesondert zu behandeln. Beide Kennungen ermöglichen eine flexible Erweiterung des
Systems.
Damit der diskrete Integrator mit dem in VRML implementierten System kommunizieren
kann, wurde das in Abschnitt 6.6.5 vorgestellte Gerät „TCP” für den DeviceSensor Knoten
als nachladbares Erweiterungsmodul für den Browser programmiert. Dieses Gerät teilt
aus der TCP Verbindung gelesene Zeilen in durch Leerzeichen getrennte Worte auf und
gibt sie als MFString an die Szene weiter. Ebenso akzeptiert es Werte des Typs MFString
aus der Szene und fügt sie zu einer Zeile zusammen, die es in die TCP Verbindung
schreibt. Dadurch ist die direkte Ankopplung der TCP Verbindungen an die in VRML implementierten
Kommunikationskanäle möglich.
Der Proto DiskreterIntegrator, der den Diskreten Integrator innerhalb des VRML Szenengraphen
repräsentiert, besteht somit nur aus einem DeviceSensor, der das „TCP”
Gerät einbindet. Kommandos, die dieser Proto über sein eventIn Feld für Benutzerkommandos
empfängt, gibt er an den DeviceSensor weiter, und solche, die er vom Device-
Sensor erhält, sendet er über sein eventOut Feld an den Navigator Proto.
8.5.4 Kontinuierlicher Inte grator
Der Kontinuierliche Integrator ist Teil der Implementierung. Die Kollisionserkennung und
Simulation der Gravitation existierte schon in der ursprünglichen Version. Neue Komponenten
sind das Addierglied, das die Bewegungsinformationen von den Navigator Knoten
überlagert, und ein Filter, das gleichmäßigere Bewegungen erzeugt. Beide Komponenten
sind in Abschnitt 7.3 ausführlich beschrieben.
8.5.5 Navigator
Der Navigator ist im gleichnamigen Proto Navigator enthalten. Dieser Proto greift auf die
im Browser existierenden Navigationsfunktionen zurück, und implementiert diejenigen,
die typisch für multimodale Navigation sind, als VRML Code. Funktionen, die vom Browser
ausgeführt werden, sind z.B. Viewpoint-Animationen oder das Verwalten des Navigationsmodus.
Die VRML Implementierung dekodiert die Kommandos, die der Navigator
vom Diskreten Integrator erhält, und gibt solche Kommandos, die diskrete oder quasikontinuierliche
Navigation betreffen an das Modul Diskreter Navigator weiter. Dieses wird
vom Navigator als EXTERNPROTO nachgeladen. Ferner werden die von den Kommandos
veränderten Systemzustände in einem ebenfalls als EXTERNPROTO geladenen LIFO Speicher
festgehalten und bei Erhalt des control undo Kommandos wieder ausgelesen. Da in
VRML keine zusammengesetzten Typen möglich sind, verwendet dieser Speicher dynamisch
erzeugte Proto Instanzen, welche die nötige Information als Werte ihrer Felder
festhalten.
Seite 102

Kapitel 8, Multimodale Interaktion
Das Modul Diskreter Navigator erhält vom Navigator eine Richtungsangabe gemäß den in
5.1.3 definierten Richtungssystemen und ein Flag, das angibt, ob die Bewegung für kurze
Zeit, oder bis auf weiteres ausgeführt werden soll. Es enthält einen eigenen Navigator
Knoten, an den es entsprechende Geschwindigkeitswerte sendet.
Über den NavigationSensor Knoten kann der Navigator Proto auf relevante Informationen
innerhalb des Navigationsmoduls des Browser zurückgreifen. Diese sendet er über
den Kommunikationskanal für Statusaktualisierungen an die haptischen Interpreter und
den Diskreten Integrator. Insbesondere wird es erst durch den NavigationSensor möglich,
daß der Benutzer über das im Browser eingebaute Rechts-Klick Menü einen Navigationsmodus
auswählt, und sowohl die in VRML implementierten Systemkomponenten
darauf entsprechend reagieren.
8.5.6 Die haptischen Inter preter
Zusätzlich zu den im Browser schon vorhandenen haptischen Interpreter für die Maus
und Tastatur werden exemplarisch zwei haptische Interpreter für einen Joystick und die
Spacemouse in VRML implementiert. Diese beiden Module validieren das in Abschnitt 5.4
erarbeitete Konzept, die Signale eines Eingabegerätes mit Hilfe des DeviceSensor Knotens
vom Browser auszukoppeln, in der Anwendung zu verarbeiten und mit dem Navigator
Knoten als Bewegungsinformation wieder in den Browser einzukoppeln.
Ein in VRML implementierter haptischer Interpreter besteht typischerweise aus einem
DeviceSensor, einem Script Knoten und einem Navigator Knoten. Der DeviceSensor
stellt die Signale, die der Benutzer am Eingabegerät erzeugt, als VRML Ereignisse zur
Verfügung. Diese werden an den Script Knoten geroutet, das diese zu Bewegungen verarbeitet.
Diese Bewegungsinformationen werden schließlich an den Navigator Knoten
geroutet, der sie an den als Teil des Browsers implementierten kontinuierlichen Integrator
weiterleitet. Das disableDefault Flag am DeviceSensor ist gesetzt, so daß der Browser
das Eingabegerät nicht selbst verarbeiten kann. Dies ist zwar beim Joystick und bei
der Spacemouse ohnehin nicht der Fall, es wäre aber denkbar, daß eine spätere Version
des Browsers diese Geräte intern unterstützt. Am Navigator Knoten darf das disableDefault
Flag hingegen nicht gesetzt werden, damit die im Browser interne Navigation per
Maus und Tastatur aktiv bleibt. Der Szenengraph eines haptischen Interpreters ist in Abb.
21 dargestellt. Der zugehörige VRML Code ist im Anhang B angegeben.
DeviceSensor
device "JOYSTICK"
disableDefault TRUE
event
Event Proto
stick
button1
button2
signalisiert Benutzereingaben
Script
verarbeitet
Benutzereingaben
zu Bewegungsinformation
Abb. 21: Struktur eines haptischen Interpreters
Navigator
disableDefault
FALSE
sendet Bewegungsinformatin
zum kontinuierlichen
Integrator
Seite 103

9 Weiterführende Arbeiten
9.1 Anwendungsbeisp iele
Kapitel 9, Weiterführende Arbeiten
Dieser Abschnitt stellt zwei Arbeiten vor, die auf das in diesem Kapitel um haptische Modalitäten
erweiterte multimodale Bediensystem MIVIS aufbauen.
Marcus Mörtlbauer bindet das erweiterte Bediensystem in ein von ihm erstelltes virtuelles
Modell des Lehrstuhls für Mensch-Maschine-Kommunikation ein. Darauf aufbauend untersucht
er die Reaktion der Benutzer auf das System. Insbesondere soll festgestellt werden,
wie oft, und unter welchen Umständen die Benutzer die Modalitäten wechseln, und
wie sehr sich dabei die Effizienz des Benutzungsinterfaces steigert. Abb. 22 zeigt einen
Screenshot dieser Arbeit, mit Blick auf den Raum, in dem auch diese Arbeit entstand.
Abb. 22: Das multimodale Bediensystem bei einem virtuellen
Lehrstuhlrundgang.
Jens Peters entwickelt ein VR-Interface zur Steuerung von Komfortapplikationen im Automobil.
Ziel dieser Arbeit ist es, an einem konkreten Beispiel herauszufinden, welche
Vor- und Nachteile die dritte Dimension gegenüber einem herkömmlichen graphischen
Benutzungsinterface mit sich bringt. Auf einem 12" Monitor, der über der Mittelkonsole
eines Autos angebracht ist, erlaubt es die Anwendung, zu telefonieren, Radio zu hören,
im Internet zu surfen (WAP), und die auf CD gebrannte Musiksammlung anzuhören.
Seite 104

Kapitel 9, Weiterführende Arbeiten
Zur multimodalen Kommunikation mit dem System werden auf diese Anwendungsdomäne
angepaßte SHM Erkenner für natürliche Sprache, sowie Hand- und Kopfgesten eingebunden.
Als haptische Eingabegeräte werden ein Touchscreen und ein dafür gefertigtes
Bedienteil mit Knöpfen und einem Drehrad angeschlossen. Diese werden mit den im ersten
Teil dieser Arbeit entwickelten Sprachkonstrukten und dem dort implementierten
„TCP” Gerät in die VRML Szene eingebunden. Die beiden Betriebsarten Radio und WAP
sind in Abb. 23 gezeigt.
Abb. 23: VR Interface im Auto – Radio hören und WAP surfen
Der VRML Games Webring[36] ist eine Seite im Internet, die VRML basierte 3D Spiele
zusammenfaßt. Diese können online und teilweise im Multiuser Betrieb gespielt werden.
Einige benutzen die in dieser Arbeit entwickelte anpassbare Navigation. Das Spiel „Combat”
implementiert einen Navigationsmodus, der sich an das kommerzielle Spiel „Quake”[35]
anlehnt. Mit der Maus kann sich der Benutzer horizontal und vertikal drehen,
ohne eine Maustaste zu drücken. Er wählt so seine Blickrichtung. Die Cursortasten dienen
zum vorwärts und rückwärts Laufen, bzw. um seitlich auszuweichen. Mit der linken und
der rechten Maustaste, oder mit den Tasten „Del” und „End” werden Waffen abgefeuert.
Dem Spieler befindet sich in einem Gebäude. Dort kommen ihm Monster entgegen, die er
besiegen muß.
Bei dem Spiel „Asteroids” bedrohen Asteroiden eine Raumstation, die der Benutzer daher
zerstören muß. Ähnlich wie bei „Combat” bestimmt der Benutzer die Bewegungsrichtung
mit der Maus. Hier ist jedoch die Dynamik an die Situation im Weltraum angepaßt. Mit
den Cursortasten kann der Benutzer beschleunigen und bremsen. Zusätzliche Tasten
schalten einige Zustandsanzeigen des Spiels an und aus.
9.2 Ausbau der System struktur
9.2.1 Rückgängig machen haptisch gesteuerter Bewegungen
Die in Kapitel 8 entwickelte Systemarchitektur implementiert einen Mechanismus zum
Rücknehmen von gegebenen Befehlen. Jedoch funktioniert dieser nur für semantisch
höherwertige Kommandos. Bewegungen, die der Benutzer mit einem haptischen Eingabegerät
erzeugt, werden dadurch nicht erfaßt. Dies ist eine Inkonsistenz im Benutzungsinterface.
Es muß untersucht werden, ob sie behoben werden kann, und inwieweit das
sinnvoll ist.
Diese Inkonsistenz kann Verwirrung stiften. Etwa wenn der Benutzer eine kurze Bewegung
mit der Maus ausführt, dann aber an den Ausgangspunkt dieser Bewegung zurück
Seite 105

Kapitel 9, Weiterführende Arbeiten
möchte. Löst er das ‚Rückgängig’ Kommando aus, wird er möglicherweise an einen ganz
anderen Ort transportiert. Denn es wird das letzte semantisch höherwertige Kommando
rückgängig gemacht, das vielleicht eines war, das einen Aussichtspunkt anspringt.
Dieses Beispiel zeigt, daß es sinnvoll wäre, wenn das Navigator Modul Signale erhalten
würde, die ihm Eckdaten der Bewegungen angeben, die der kontinuierliche Integrator
ausführt. Zumindest der Anfang dieser Begegnungen könnte interessant sein. Der Navigator
könnte dann bei Erhalt eines solchen Signals die aktuelle Position im Undo Puffer
abspeichern, so daß diese wieder hergestellt wird, wenn das ‚Rückgängig’ Kommando
ausgelöst wird.
Doch nur den Anfang einer haptisch ausgelösten Bewegung abzuspeichern, reicht nicht
aus. Bewegt sich der Benutzer über längere Zeit durch eine Welt, möchte er vielleicht nur
den letzten Teil dieser Bewegung rückgängig gemacht haben. Ferner möchte er vielleicht
an markante Stellen dieser Bewegung zurück springen. Eine Analyse der erzeugten Bewegungen
erscheint daher als sinnvoll.
Eine naheliegende Lösung wäre, daß die haptischen Interpreter diese Analyse durchführen.
Das würde jedoch den Implementierungsaufwand für jedes solche Modul erhöhen,
und die Ergebnisse dieser Analyse wären unkorelliert zu anderen haptischen und semantisch
höherwertigen Modalitäten. Die Analyse der Bewegungen sollte daher zentral im
haptischen Integrator stattfinden. Drückt man die Bewegungen, die nach dem Addierglied
auftreten, als Geschwindigkeiten aus, ergibt sich gemäß den in 5.1.3 eingeführten
Richtungssystemen ein zwölfdimensionaler, zeitabhängiger Vektor. Dieser kann mit Methoden
der Signaldarstellung analysiert werden, so daß markante Stellen dem Navigator
signalisiert werden. Es muß auch festgestellt werden, ob die vom Navigator erzeugten
Bewegungen der diskreten oder quasikontinuierlichen Navigation in diese Analyse einbezogen
werden sollen.
9.2.2 Kontinuierliche Zeige gesten
Zeigegesten werden von dem in Kapitel 8 entwickelten multimodalen Bediensystem nur
in einer diskreten Form unterstützt. Der Benutzer muß durch eine Aktion zum Ausdruck
bringen, daß er auf etwas zeigt. Bei der Maus tut er dies durch Drücken einer Taste,
wenn er auf ein Objekt klickt. Der Benutzer kennzeichnet so den exakten Zeitpunkt,
wann eine Zeigegeste wirksam wird. Es existiert jedoch eine andere Form des Zeigens,
die kontinuierliches Zeigen genannt werden kann. Bei der Maus entspricht das dem Bewegen
der Maus, ohne eine Maustaste zu drücken. Ein Datenhandschuh wird zu einem
kontinuierlichen Zeigegerät, wenn der Benutzer den Zeigefinge ausstreckt.
Für die kontinuierliche Navigation muß solches kontinuierliches Zeigen von den haptischen
Interpretern in Bewegungsinformation aus einem der beiden Richtungssysteme
umgewandelt werden. Im Bezug auf die Gruppe , die semantisch höherwertige
Äußerungen mit Zeigegesten kombiniert, würde die Unterstützung kontinuierlichen Zeigens
jedoch höhere Anforderungen an die Implementierung des Bediensystems stellen.
Menschen zeigen gewöhnlich auf Objekte, während sie sagen, was sie im Zusammenhang
mit dem Objekt ausdrücken wollen. Oft gilt die Zeigegeste zu dem Zeitpunkt, während
ein bestimmtes Wort ausgesprochen wird. Beispeilsweise sagt jemand “Stell das da
weg!”. Während er “das” spricht, zeigt er auf einen Gegenstand. Bezogen auf ein System
zur Interaktion mit 3D Umgebungen bedeutet das, daß das System vom Zeigegerät einen
kontinuierlichen Strom von Positions- oder Richtungsangaben erhält. Wenn es ein Kommando
über den Sprachkanal oder eine andere Modalität erhält, muß es aus dem Strom
diejenige Position bzw. Richtung entnehmen, die zeitlich zum erhaltenen Kommando
paßt.
Seite 106

Kapitel 9, Weiterführende Arbeiten
Ein solches System könnte etwa folgendermaßen aufgebaut sein: Die SHG Erkenner geben
zusätzlich zu der erkannten Äußerung einen Zeitstempel an, wann diese Äußerung
gemacht wurde. Der Zeitpunkt zu dem der SHG Erkenner das Kommando ausgibt, ist
dafür nicht geeignet, da der Erkenner einige Zeit zur Analyse des Eingangssignals benötigt.
Idealerweise gibt ein Spracherkenner den Zeitpunkt an, zu dem das für die Zeigegeste
kritische Wort – z.B. „das” oder „dorthin” – ausgesprochen wird. Die Gruppe
müßte dann folgendermaßen geändert werden:
| ::= gothere
| ::= lookat
| ::= setexacenter
| ::= follow
Der diskrete Integrator erhält von jedem angeschlossenen Zeigegerät einen Strom
kontinuierlicher Zeigegesten, die ebenfalls mit Zeitstempeln versehen sind. Diese
speichert er jeweils in einem Puffer, der die in den letzten Sekunden empfangenen
Positionen bzw. Richtungen vorhält. Wenn der diskrete Integrator ein Kommando aus der
Gruppe erhält, stellt er zuerst fest, ob er diesem ein Kommando aus
zuordnen kann. Ist dies nicht der Fall, sucht er sich aus den in der letzten
Zeit empfangenen kontinuierlichen Zeigegesten eine heraus, die im zeitlichen Umfeld des
Zeitstempels im Kommando vom SHG Erkenner liegt. Dabei sollte er vermutlich eine
Geste, die auf ein Objekt zeigt, gegenüber einer solchen bevorzugen, die nicht auf ein
Objekt zeigt aber zeitlich näher am Zeitstempel des Kommandos liegt. Um
die Entscheidung zu treffen, ob eine Zeigegeste auf ein Objekt zielt, muß er die
Zeigegeste mit der Szene vergleichen. Da aber die Szene sich mit der Zeit verändern
kann, ist das im Nachhinein schwierig. Deshalb müssen die Positionen oder Richtungen,
die Zeigegeräte aussenden sofort bei ihrem Aussenden mit der Szene verglichen werden.
Wenn tatsächlich mehr als ein Zeigegerät angeschlossen ist, muß der diskrete Integrator
entscheiden können, welches Zeigegerät der Benutzer meint.
9.3 Ausbau der Funkti onalität
9.3.1 Zugriff der Anwendu ng
Mit dem Navigator Knoten und dem NavigationSensor kann die Anwendung mit dem
Navigator und dem kontinuierlichen Integrator Kommunizieren. Diese Kommunikation ist
jedoch auf die Ausdrucksmöglichkeiten von VRML begrenzt. Die Begrenzung rührt daher,
daß pro Ereignis nur ein Wert eines der VRML Datentypen übertragen werden kann.
Deshalb können am Navigator Knoten mit den Feldern moveTo, orientTo und beamTo nur
drei Arten von referenzierter Navigation durchgeführt werden. Die
Ausdrucksmöglichkeiten der in Abschnitt 8.4 eingeführten sind wesentlich mächtiger.
Würde man die in dieser Arbeit entwickelte Grammatik, oder eine ähnliche Form davon,
standardisieren, könnte der Anwendung direkter Zugriff auf die volle Funktionalität des
Navigator Moduls, oder gar auf den diskreten Integrator gegeben werden. Der Navigator
würde ein Feld
eventIn MFString command
erhalten, über das die Anwendung Kommandos an den Navigator oder den diskreten Integrator
senden kann. Ein entsprechendes Feld
eventOut MFString status
am NavigationSensor würde Statusänderungen des Navigators direkt an die Anwendung
weiterleiten. Ein VRML Browser, der nicht über die Fähigkeit zur multimodalen Bedienung
über einen diskreten Integrator verfügt, würde nur kontextfreie Kommandos verstehen.
Das Konzept der Profiles, welche den Funktionsumfang von VRML Browsern definieren,
könnte bei dieser Unterscheidung helfen.
Seite 107

9.3.2 Referenzieren beweg licher Objekte
Kapitel 9, Weiterführende Arbeiten
Im Abschnitt 8.4.2 wurde eine Grammatik vorgestellt, die für Anwendungen geeignet ist,
welche Zeigegesten auf sich bewegende Objekte nicht unterstützen, bzw. bei denen keine
zeitliche Verzögerung zwischen der Zeigegeste und der Ausführung des zugehörigen
Kommandos auftritt. In diesem Abschnitt wird dieser Teil der Grammatik durch eine solche
ersetzt, welche diese Beschränkungen nicht aufweist.
Im Vergleich zum implementierten Ansatz bleibt die Aufteilung der Gruppe in
drei Untergruppen und die erste dieser drei Gruppen gleich:
Referral> ::= | |
| ::= gothere
| ::= lookat
| ::= setexacenter
| ::= follow
Das Kommando gothere drückt aus, daß der Benutzer an eine bestimmte Position bewegt
werden will, lookat, daß er sich zu einem Objekt hindrehen will, setexacenter, daß die
angegebene Position zum neuen Drehzentrum werden soll, und follow beschreibt den
Wunsch, einem Anderen Objekt zu folgen.
Die Möglichkeit auf ein Objekt zu zeigen, das sich möglicherweise bewegt, und zu etwa
der gleichen Zeit ein Kommando über eine andere Modalität zu äußern, das mit dieser
Zeigegeste in Verbindung steht, macht es erforderlich, daß dem Kommando, das die Zeigegeste
repräsentiert neben der angezeigten Position in Weltkoordinaten auch eine Referenz
auf das Objekt mitgegeben wird. Denn beide Äußerungen des Benutzers werden
nicht zu exakt der selben Zeit gemacht, und gerade bei semantisch höherwertigen Modalitäten
macht die endliche Rechenzeit eines Computersystems ein Kommando erst kurze
Zeit nach dem der Benutzer seine Äußerung gemacht hat verfügbar. Während dieser Zeit
kann sich das Objekt schon weiterbewegt haben, und die in Weltkoordinaten angegebene
Position ist nicht mehr gültig.
Deshalb werden die Kommandos, die eine Zeigegeste repräsentieren, um ein weiteres
Kommando erweitert, das in zwei zusätzlichen Parametern eine Referenz auf das Objekt
und die referenzierte Position in einem objektlokalen Koordinatensystem angibt. Das objektlokale
Koordinatensystem ist das Koordinatensystem, in dem das Objekt modelliert
wurde. Es bewegt sich mit dem Objekt mit. Die Repräsentation einer Referenz auf das
Objekt bleibt dem Browser überlassen. Mögliche Formen sind ein Index in eine Liste aller
Objekte oder eine Objekt ID in Stringform. Wenn das Kommando schließlich im Navigator
ausgeführt wird, müssen die Weltkoordinaten aus der Objektreferenz und den objektlokalen
Koordinaten neu berechnet werden. Das follow Kommando wird erst durch diesen
Mechanismus möglich. Für den diskreten Integrator ist die Objektreferenz genauso wie
die Positionsangaben ein opaquer Datentyp, den er nur durchreicht.
| ::= indicated
| ::= indicated geometry
| ::= indicated objectpos
| ::= indicated obj
Das neue Kommando indicated objectpos * drückt ein Zeigen auf ein Objekt aus, das als
solches vom Autor der Anwendung ausgezeichnet wurde. Es enthält neben der absoluten
Position, auf die gezeigt wurde, die Referenz auf das Objekt und die angezeigte Position
im objektlokalen Koordinatensystem. Das Ursprüngliche Kommando indicated geometry *
wurde beibehalten, da nicht notwendigerweise jedes Objekt von der Anwendung als solches
gekennzeichnet sein muß. Beispielsweise ist das nicht für passive Objekte, wie z.B.
Wände eines Raumes, zu erwarten. Zeigt der Benutzer auf ein solches Objekt, wird das
indicated geometry * Kommando ausgelöst.
Seite 108

Kapitel 9, Weiterführende Arbeiten
Zusätzlich kann mit der Referenz eine vollständig positionslose Zeigegeste realisiert
werden. Erhalten die gekennzeichneten Objekte zusätzlich einen Namen, könnte ein
Spracherkenner, der nicht auf einen konkreten Wortschatz trainiert ist, das Kommando
indicated object auslösen, wenn der Benutzer den Namen eines Objekts nennt.
Ähnlich zu den Aussichtspunkten könnte dem Benutzer eine Liste aller Objekte – oder der
im Blickfeld des Benutzers befindlichen Objekte – präsentiert werden, aus welcher der
Benutzer ein Objekt auswählen kann, bevor er z.B. per Spracheingabe angibt, was mit
dem Objekt passieren soll 17 . In solchen Fällen ist zwar eine Objektreferenz verfügbar,
aber keine Position.
Die Gruppe der kontextfreien Kommandos muß gegenüber der Definition in
Abschnitt 8.4.2 an geeigneten Stellen ebenfalls um eine Objektreferenz und eine objektlokale
Position erweitert werden. Dazu wird der neue Wertebereich eingeführt,
der den Wertebereich ersetzt. Dieser Wertebereich umfaßt sowohl Positionen
im globalen Koordinatensystem, als auch eine Angabe in einem objektlokalen Koordinatensystem
mit einer Objektreferenz als auch eine Objektreferenz ohne Positionsangabe.
Da dieser Wertebereich den Wertebereich enthält, bleiben die alten
Kommandos erhalten. Diese resultieren aus dem Kommando indicated geometry *. Das
Kürzel loc in objloc deutet an, daß eine Position in einem objektlokalen Koordinatensystem
folgt. Positionen, die mit dem Symbol abs eingeleitet werden, sind die absoluten
Positionsangaben, die in der ursprünglichen Grammatik ohne ein einleitendes abs angegeben
wurden. Der Wertebereich wird ebenfalls um objektspezifische Angaben
zu aufgewertet. Hier macht eine Angabe einer objektspezifischen
Position in Verbindung mit einer Orientierung oder Richtung keinen Sinn, so daß nur der
mit pos gekennzeichnete Zweig von auf geändert wird.
: ::= abs
: ::= objloc
: ::= obj
: ::= pos
: ::= ori
: ::= posori
: ::= posdir
: ::= dir
Die Gruppe wird in ihrer Struktur nicht geändert. Lediglich wird
zu und wird zu . Zusätzlich kommt das Kommando
followobject hinzu, das den Navigator anweist, den Avatar in der Nähe des angegebenen
Objektes zu halten. Diese Funktion könnte so gestaltet werden, daß eine Navigation
mit haptischen oder semantisch höherwertigen Modalitäten relativ zum Objekt
möglich bleibt.
::= orientto pos
::= orientto dir
::= moveto
::= beamto pos
::= beamto watch
::= exacenter set
::= followobject
17 Diese Liste könnte sogar automatisch angezeigt werden, wenn der Benutzer ein Kommando aus
gibt, aber keine zugehörige Zeigegeste durchführt. Das wäre dann ein Fall, in dem
das System beim Benutzer nachfragt.
Seite 109

Kapitel 9, Weiterführende Arbeiten
Für den Navigator, der die Kommandos ausführen muß, bedeuten die neuen Positionsangaben
in den meisten Fällen, daß er diese in Angaben der alten Form umrechnen muß.
Dann kann er die Kommandos in bekannter Weise ausführen. Ist eine Objektreferenz und
eine Positionsangabe im objektlokalen Koordinatensystem gegeben, kann er die Position
anhand der Position und Orientierung des Objekts in globale Koordinaten umrechnen. Ist
nur eine Objektreferenz vorhanden, muß er sich vor der Umrechnung eine Standardposition
für das Objekt suchen. Diese Standardposition ist beispielsweise der Objektmittelpunkt,
oder eine im Objekt angegebene Position.
9.3.3 Multimodale und dre idimensionale Umsetzung des Kontextmenüs
Die in Abschnitt 8.4.2 eingeführte Gruppe der Kommandos zur referenzierenden
Navigation definieren einen in der Untergruppe zusammengefaßten
Satz Kommandos für Zeigegesten, einen in zusammengefaßten Satz Kommandos,
die bestimmen, was mit der referenzierten Position oder dem referenzierten
Objekt passieren soll. Die Untergruppe enthält Kommandos, die aus der
Kombination von Kommandos der ersten beiden Gruppen resultieren. Der in dieser Arbeit
definierte Befehlssatz in wurde anwendungsunabhängig gehalten, könnte aber
ebenso anwendungsspezifische Kommandos umfassen.
Beispielsweise könnte in einer Anwendung für die virtuelle Manipulation von Molekülstrukturen
ein Befehl show_mass_number ausdrücken, daß das Atomgewicht eines referenzierten
Atoms oder Moleküls angezeigt werden soll. Die Gruppe RefResolved> müßte entsprechende
Kommandos beinhalten, die solche anwendungsabhängige Aktionen und eine
Positionsangabe kombinieren. Die Erweiterung der Funktionalität auf anwendungsabhängige
Objektbefehle stellt ein sehr mächtiges Konzept dar, zieht aber einen anwendungsabhängigen
Teil der im diskreten Integrator enthaltenen Logik nach sich. Die Erkennermodule,
die Kommandos aus erzeugen, müssen auch angepaßt werden.
Da eine Erweiterung auf anwendungsspezifische Funktionen eine wesentliche Bereicherung
der Interaktionsmöglichkeiten für eine Anwendung darstellt, könnte es sich lohnen,
den auf die Gruppe bezogenen Teil der Logik im Integrator für die Anwendung
erweiterbar zu gestalten. Diese Erweiterung könnte etwa so aussehen, daß der Anwendung
die Möglichkeit gegeben wird, neue Kommandos in die Gruppen und
hinzuzufügen. Ferner muß sie spezifizieren können, welche Kombinationen
aus und gültig sind, und zu welchen Kommandos aus
diese aufgelöst werden. Es müßte ein Kommunikationskanal etabliert werden,
über den der Integrator der Anwendungen mitteilt, wenn eines der anwendungsspezifischen
Kommandos aus ausgelöst wurde.
Während die Erweiterungsarchitektur des Integrators machbar erscheint, ist die Umkonfiguration
der Erkennermodule schon problematischer. Hier wird wahrscheinlich eine von
den Eigenheiten einzelner Modalitäten und von den Spezifika der eingesetzten Erkennermodule
unabhängige Darstellung der Kommandos, welche die Erkennermodule erzeugen
können, schwer möglich sein. Möglicherweise stellt die Einschränkung auf den Spracherkenner
einen akzeptablen Kompromiß dar, denn diese Modalität ist sowieso am besten
dazu geeignet, abstrakte Zusammenhänge auszudrücken.
Betrachtet man das Konzept, eine Zeigegeste mit anwendungsspezifischen Kommandos
zu kombinieren genauer und vergleicht es mit den in konventionellen grafischen Benutzungsoberflächen
verwendeten Kontextmenüs, stellt man fest, daß dieses Konzept die
multimodale und dreidimensionale Umsetzung der Kontextmenüs darstellt. Zwei Unterschiede
existieren jedoch:
• Die Menge verfügbarer Kommandos hängt von dem referenzierten Objekt ab.
• Bei einem Kontextmenü werden die für ein Objekt verfügbaren Kommandos dem Benutzer
visuell zur Auswahl angeboten.
Seite 110

Kapitel 9, Weiterführende Arbeiten
Beide Vorteile der Kontextmenüs können auf den dreidimensionalen Fall übertragen werden.
Die Abhängigkeit verfügbarer Kommandos von dem vom Benutzer referenzierten
Objekt kann durch den in Abschnitt 9.3.2 eingeführten Datentyp , der eine Referenz
auf ein Objekt transportiert, realisiert werden. Wenn der diskrete Integrator ein Kommando
aus an die Anwendung übermittelt, enthält diese Mitteilung auch die
Referenz auf das Objekt und eventuell den Punkt, der auf dem Objekt referenziert wurde.
Erhält die Anwendung ein solches Kommando, gibt sie es an das Objekt weiter, worauf
dieses entscheidet, ob es das Kommando ausführen kann. Da Anwendungen idealerweise
in Form unabhängiger Module aufgebaut sind, kann es zu Kollisionen der Namen für die
Kommandos in und kommen. Diese könnten aufgelöst werden,
wenn sogenannte GUIDs (Globally Unique IDentifier) als anwendungsinterner Name für
Kommandos zugelassen werden.
Die visuelle Auswahl von Kommandos bringt Vorteile für Neulinge, während die direkte
Nennung eines Kommandos für Erfahrene Anwender interessant ist. Nach Hennig[4]
sollte eine Anwendung aus diesem Grund beide Formen implementieren. Ein Kommando
show_menu in und ein entsprechendes Kommando in würde eine
Anwendung anweisen, ein Kontextmenü anzuzeigen. Die Auswahl eines Menüpunktes
könnte die Anwendung durch eine weitere Zeigegeste auf das neu in die Szene eingefügte
Objekt „Menü” realisieren. Das Kommando show_menu wäre dann ein von der Anwendung
unabhängiges Kommando und könnte somit von jedem Erkennermodul für semantisch
höherwertige Modalitäten und von jedem haptischen Eingabegerät, das über
eine „Menütaste” verfügt, erzeugt werden.
Es bleibt natürlich noch zu untersuchen, inwiefern ein Kontextmenü für VR Anwendungen
die Intuitivität eines Interaktionsparadigmas und die Immersionsfähigkeit von Anwendungen
unterstützt oder behindert. Jedoch könnte es ähnlich nützlich sein, wie es das in
konventionellen grafischen Benutzungsoberflächen ist.
9.4 Ausbau auf das Pa radigma Manipulation
Das Interaktionsparadigma Manipulation stellt eine entscheidende Erweiterung des multimodalen
Bediensystems dar. Das Paradigma Navigation umfaßt zwar elementare Interaktionsformen
für 3D Anwendungen, doch bleibt der Benutzer ein passiver Kommunikationspartner.
Er begibt sich an bestimmte Orte und betrachtet die virtuelle Welt aus verschiedenen
Blickrichtungen. Erst durch die Möglichkeit, Objekte der virtuellen Welt zu
manipulieren, kann der Benutzer aktiv Einfluß auf die Anwendung nehmen. In diesem
Abschnitt werden einige Ideen vorgestellt, die eine Erweiterung des multimodalen Bediensystem
MIVIS um das Interaktionsparadigma, insbesondere für haptische Modalitäten,
ermöglicht.
Zentrale Idee dieser Erweiterung ist, daß der Benutzer ein Objekt auswählt, das er manipulieren
will. Anschließend geht das System in einen Modus, in dem alle haptischen Eingabegeräte
dieses Objekt bewegen. Semantisch höherwertige Kommandos, die eine Bewegung
beschreiben und keinen Hinweis auf Navigation enthalten, werden ebenfalls in
Bewegungen dieses Objekts umgesetzt. Eine weitere Funktion ist das Loslassen des Objektes,
worauf das System wieder in einen der drei Navigationsmodi umschaltet. Dieses
Loslassen kann durch eine explizite Äußerung des Benutzers ausgelöst werden, oder
durch ein semantisch höherwertiges Kommando, das sich implizit oder explizit mit der
Manipulation widerspricht. Zudem sollen auch andere Aktionen auf ein Objekt angewendet
werden können.
Alternativ kann mit einem Zeigegerät auch direkt ein Objekt ausgewählt und bewegt
werden, ohne daß ein semantisch höherwertiges Kommando daran beteiligt ist. In existierenden,
unimodalen VRML Browsern findet diese Form der Manipulation standardmäßig
statt.
Seite 111

Kapitel 9, Weiterführende Arbeiten
Eine Anwendung muß die Objekte der Szene, die manipuliert werden können, als solche
auszeichnen, damit sie das System von statischer Geometrie, wie z.B. die Wände in einem
Raum, unterscheiden kann. Zudem muß die Anwendung für jedes Objekt eine Anzahl
Parameter spezifizieren, die kontrollieren, auf welche Weise ein Objekt manipuliert
werden kann.
9.4.1 Systemarchitektur
Für das Manipulationsparadigma ist vermutlich eine ähnliche Struktur nötig, wie für die
Navigation. In einer Systemarchitektur, die beide Paradigmen unterstützt, sind gemeinsame
Komponenten der diskrete Integrator, die SHG Erkenner und die haptischen Interpreter.
Diese werden in der Funktionalität entsprechend erweitert. Parallel zum Navigator
kommt ein Modul Manipulator hinzu, das die kontextfrei aufgelösten Kommandos, welche
die Manipulation betreffen, vom diskreten Integrator erhält und ausführt. Ebenso bekommt
der kontinuierliche Integrator ein Schwestermodul, das Bewegungsinformationen
vereinigt und auf ein Objekt der Szene anwendet. Von den Richtungssystemen scheint
das Examine Richtungssystem besser als das SixDof Richtungssystem für die Manipulation
geeignet zu sein, denn es ist schon von der Idee eines Objekts geleitet, das bewegt
wird. Das in Abschnitt 9.3.2 diskutierte Konzept, Objekte von der Anwendung als solche
auszeichnen zu lassen, ist für die Manipulation sehr hilfreich, denn Manipulation bezieht
sich fast immer auf bestimmte Objekte.
Der diskrete Integrator im bestehenden System baut interne Modelle der Anwendung und
der Intention des Benutzers auf, damit er entscheiden kann, wie er kontextsensitive
Kommandos zu kontextfreien (im Sinne der Funktionalität) kombinieren soll. Ein separater
Integrator für die Manipulation würde separate Modelle aufbauen, die sich möglicherweise
von denen des Integrators für die Navigation widersprechen. Um dies zu verhindern
sollte nur ein diskreter Integrator für beide Paradigmen existieren.
Die haptischen Interpreter müssen neben den drei Navigationsmodi WALK, FLY und
EXAMINE einen weiteren Modus unterstützen, in dem sie Bewegungsinformationen erzeugen,
die geeignet sind, ein Objekt zu bewegen. Möglicherweise werden diese Bewegungen
auf die selbe Weise erzeugt wie das im EXAMINE Modus der Fall ist. Das hätte
den Vorteil für den Benutzer, daß er keine neue Form der Bewegungssteuerung lernen
muß. Jedoch kommt es bei der Manipulation fast immer vor, daß nur bestimmte Bewegungsrichtungen
erlaubt sind. Beispielsweise können Möbel nur in der durch den Fußboden
definierten Ebene bewegt und um die dazu senkrechte Richtung gedreht werden.
Bilder an der Wand können nur verschoben werden. Es können alle Kombinationen der
sechs möglichen Freiheitsgrade vorkommen. Deshalb muß ein Weg gesucht werden, wie
haptische Interpreter trotzdem geeignete Bewegungsinformationen erzeugen.
Das Schwestermodul des kontinuierlichen Integrators könnte kontinuierlicher Integrator
für die Manipulation genannt werden, wodurch der kontinuierliche Integrator konsequenterweise
in kontinuierlicher Integrator für die Navigation umbenannt werden muß.
Der kontinuierliche Integrator für die Manipulation verarbeitet Bewegungsinformation zur
Bewegung eines Objektes. Er muß dazu vom Manipulator eine Referenz auf das Objekt
erhalten, das bewegt werden soll. Zusätzlich braucht er Information, welche Freiheitsgrade
für das Objekt gelten, und in welchen Grenzen diese ausgeführt werden können.
Beispielsweise könnte eine Drehung nur innerhalb eines bestimmten Winkelbereiches
möglich sein, oder ein Objekt, das sich auf einem Tisch befindet, darf sich nur in einem
Bereich bewegen, innerhalb dessen es sich oberhalb der Tischplatte befindet. Ebenso wie
der kontinuierliche Integrator für die Navigation muß der kontinuierliche Integrator für
die Manipulation Kollisionserkennung betreiben können, um Bewegungen durch andere
Objekte zu verhindern. Eine Simulation der Gravitation ist möglicherweise nicht nötig.
Seite 112

9.4.2 Funktionalität
Kapitel 9, Weiterführende Arbeiten
Die Gruppe der Kommandos für die referenzierende Navigation ist der Zentrale
Punkt für die Erweiterung der Funktionalität des Systems auf die Manipulation. Da
manipulierbare Objekte prinzipiell beweglich sind, und da sie von der Anwendung für die
Manipulation gekennzeichnet werden müssen, ist die in Abschnitt 9.3.2 angegebene Form
der Grammatik zu verwenden. Die Gruppe besteht aus drei Untergruppen,
wovon die Gruppe Zeigegesten auf Objekte beschreibt, und die Gruppe
ausdrückt, was mit den Objekten passieren soll. Der Diskrete Integrator
kombiniert Kommandos aus diesen beiden Gruppen zu einem der Kommandos aus der
Gruppe . Diese enthalten sowohl eine Angabe, was passieren soll, als auch
mit welchem Objekt das geschehen soll.
Eine Erweiterung auf die Manipulation würde bedeuten, in die Gruppe weitere
Befehle aufzunehmen, die auf ein Objekt angewendet werden können. Die Gruppe
muß an die neuen Kommandos angepaßt werden. Das wichtigste Kommando
für ist manipulate, mit dem der Benutzer ausdrückt, daß er das Objekt
manipulieren will. Ein Spracherkenner könnte dieses Kommando absetzen, wenn der Benutzer
sagt: „Ich will das bewegen.” Gleichzeitig zeigt der Benutzer auf ein Objekt. Das
System sendet die in dem zugehörigen Kommando aus angegebene
Referenz an den kontinuierlichen Integrator für die Manipulation und schaltet die haptischen
Interpreter in den Manipulationsmodus. Das gegenteilige Kommando zu manipulate
ist release_object. Es drückt aus, daß der Benutzer das Objekt wieder loslassen will. Dies
gehört jedoch nicht in die Gruppe , da es nicht mit einer Zeigegeste kombiniert
wird.
Das Kommando activate stellt ebenfalls eine hervorragende Funktionalität dar. Wendet
der Benutzer dieses Kommando auf ein Objekt an, teilt der Manipulator dies der
Anwendung mit, worauf diese die Standardaktion des Objekts auslöst. In Abschnitt 9.3.3
wurde eine weitere Kategorie Kommandos für vorgestellt. Diese stellen ebenfalls
Kommandos für die Manipulation dar. Sie beschreiben anwendungsabhängige und
objektspezifische Befehle, die auf ein Objekt angewendet werden können.
Die Gruppe beschreibt Kommandos, die nur ein Argument in Form einer Zeigegeste
benötigen. Im Zusammenhang mit dem Manipulationsparadigma sind jedoch
auch komplexere Kommandos denkbar. Der Satz „Stelle das dort hin!” resultiert beispielsweise
in einem Kommando, das sowohl ein indicated obj * als auch ein indicated
Kommando als Argument benötigt.
Die neuen Kommandos bewirken jeweils neue Signale, die der Manipulator in den Kommunikationskanal
für Statusänderungen schreibt. Insbesondere muß der Manipulator die
haptischen Interpreter in den Manipulationsmodus setzen. Dabei muß er diesen mitteilen,
welche Freiheitsgrade für das Objekt verfügbar sind. Das Loslassen eines Objektes
könnte dadurch realisiert werden, daß die haptischen Interpreter ein status mode mode *
Kommando erhalten, das ihnen den nach dem Loslassen gültigen Navigationsmodus
mitteilt. Auch der kontinuierliche Integrator für Manipulation könnte Kommandos in den
Kanal für Statusänderungen schreiben. Beispielsweise wenn ein Freiheitsgrad am Ende
eines Bewegungsbereiches angelangt ist, oder wenn eine Kollision auftritt. Ähnlich wie im
Signal status collided könnte in beiden Fällen eine Richtungsangabe
enthalten sein, die der versuchten Bewegung entgegenwirkt.
Seite 113

9.4.3 Anwendungen
Kapitel 9, Weiterführende Arbeiten
Eine Anwendung, welche die Vorteile des Paradigma Manipulation nutzen will, muß das
explizit unterstützten. Zum Einen muß sie Objekte als manipulierbar auszeichnen und die
Parameter der Manipulierbarkeit angeben. Zum Anderen muß sie den Objekten eine Bedeutung
zuordnen. Das Auszeichnen von Objekten kann über die Szenenbeschreibung
geschehen. Für das Zuordnen von Bedeutungen zu den Objekten muß ein Kommunikaitonskanal
vom Bediensystem zur Anwendung etabliert werden.
In der VRML Technologie sind beide Konzepte schon in Form der Sensor Knoten vorhanden.
Die Szenenbeschreibung verknüpft ein Objekt mit einem Sensor Knoten und drückt
dadurch aus, daß dieses vom Benutzer manipulierbar ist. Der Typ des Sensor Knotens
und die Parameter, die dabei angegeben werden können, spezifizieren die genaue Art,
wie das Objekt manipuliert werden kann. Wenn der Benutzer ein solches Objekt manipuliert,
sendet der zugeordnete Sensor Knoten entsprechende Signale an seinen eventOut
Feldern an die Anwendung, die diese dann verarbeitet.
Der TouchSensor ist ein Sensor Knoten, der vom Benutzer ähnlich wie ein Schalter
aktiviert werden kann. Tritt dieser Fall ein, sendet der TouchSensor an seinem touchTime
Feld ein Ereignis. Diese Funktionalität sollte durch das activate Kommando ausgelöst
werden können. Zusätzlich enthält der TouchSensor Felder die kontinuierliches Zeigen
(siehe Abschnitt 9.2.2) unterstützen. Deren Bedeutung im Zusammenhang mit
semantisch höherwertigen Modalitäten und multimodaler Bedienung muß untersucht
werden.
Die Sensor Knoten PlaneSensor, CylinderSensor und SphereSensor definieren den
Bewegungsbereich, den ein Objekt durchführen kann. Sie interpretieren die Eingaben des
Benutzers als ein- oder zweidimensionale translatorische Bewegungen (PlaneSensor), als
eindimensionale translatorische und Rotation um eine Achse (CylinderSensor) oder als
Rotation um einen Punkt (SphereSensor). Weitere Freiheitsgrade sind nicht vorgesehen.
Da immer nur ein Sensor Knoten zur gleichen Zeit aktiv sein kann, können diese nicht
kombiniert werden. Im Zusammenhang mit echten 3D Eingabegeräten müssen mehrere
Freiheitsgrade gleichzeitig zugelassen werden. Beispielsweise wäre eine translatorische
Bewegung in allen drei Richtungen wünschenswert. Mit der Spacemouse können
beispielsweise Objekte in allen sechs Freiheitsgraden bewegt werden.
Aber nicht nur die Angabe eines Bewegungsbereichs ist für eine reichhaltige Bedienung
einer Anwendung notwendig. Die in den anderen Abschnitten dieses Kapitels vorgestellten
Konzepte sollten durch einen Knoten in die Sprache VRML abgebildet werden. Er
könnte folgende Angaben ermöglichen:
• die darzustellende Geometrie des Objekts
• das objektlokale Koordinatensystem
• das Zentrum des Objekts als Punktkoordinaten im objektlokalen Koordinatensystem
• die objektspezifischen Kommandos, welche das Objekt ausführen kann
• Felder, die kontinuierliches Zeigen erlauben
Das kontinuierliche Zeigen könnte dadurch realisiert werden, daß der Knoten einen
TouchSensor Referenziert, da dieser die entsprechenden Felder schon enthält.
Seite 114

10 Zusammenfassu ng
Kapitel 10, Zusammenfassung
In dieser Arbeit wurde eine Software-Architektur für die multimodale Navigation in virtuellen
3D Umgebungen entwickelt. Das System bindet auf generische Weise sowohl haptische
Eingabegeräte als auch semantisch höherwertige Modalitäten in den Bedienprozeß
ein. Dadurch wird der Benutzer in die Lage versetzt, diese zur Erledigung von Navigationsaufgaben
frei zu wählen und in beliebiger Kombination einzusetzen.
Durch die Möglichkeit, Interaktionsstile an die Profile von speziellen Benutzergruppen
anzupassen, eröffnet sich ein breiteres Anwendungsspektrum für VRML basierte VR Anwendungen.
Aufgrund der Verknüpfung möglichst vieler, sowohl haptischer als auch semantisch
höherwertiger Modalitäten werden die Kommunikationsfähigkeiten an die natürlichen
Kommunikationsformen des Menschen angepaßt. Dadurch entsteht eine ausgesprochen
effiziente Form der Mensch-Maschine-Interaktion.
Ferner wurde die VRML Technologie, mit der Internet basierte VR Anwendungen realisiert
werden, so erweitert, daß das Interaktionsparadigma Navigation in virtuellen 3D Umgebungen
sowohl an die Bedürfnisse der Anwendung, als auch an die Bedürfnisse der Zielgruppe
der Anwendung angepaßt werden kann.
Die in VRML Browsern übliche starre Verbindung von Eingabegerät zu den Bewegungen
des Avatars wurde aufgebrochen und durch die Anwendung geroutet. Das Sprachkonstrukt
‚DeviceSensor’ macht die im System vorhandenen Eingabegeräte für die Anwendung
sichtbar, so daß diese Benutzereingaben von den Eingabegeräten auslesen kann.
Typischerweise interpretiert die Anwendung diese Signale und formt sie in Steuersignale
um, die Bewegungen des Avatars beschreiben. Das Sprachkonstrukt ‚Navigator’ empfängt
diese Steuerinformationen und leitet sie an den Browser weiter. Ferner wurden die
Konstrukte ‚NavigationSensor’ und ‚NavigationInfo2’ definiert, die eine erweiterte Kommunikation
zwischen Anwendung und Browser ermöglichen.
Diese Erweiterungen dienen als technische Basis für die Implementierung eines Prototyps
des multimodalen Bediensystems. Basierend auf dem am Lehrstuhl entwickelten Bediensystem
für semantisch höherwertige Modalitäten (MIVIS) wurden drei Kommunikationskanäle
eingeführt. Ein Kanal transportiert teilweise voneinander abhängige Kommandos
von den haptischen und den semantisch höherwertigen Modalitäten zum Integrator des
bestehenden Systems, der diese zu eindeutigen Kommandos kombiniert. Ein weiterer
Kanal transportiert Statusmeldungen aus dem Navigationsmodul zu den Komponenten,
welche die Signale der haptischen Eingabegeräte interpretieren. Diese können dadurch
die Signale der Eingabegeräte entsprechend dem eingestellten Modus interpretieren und
dem Benutzer mittels Feedback-Geräten Rückkopplung über auftretende Ereignisse geben.
Die Bewegungen, die von den haptischen Eingabegeräten erzeugt werden, überträgt
ein dritter Kanal zu einem kontinuierlichen Integrator, der diese filtert, begrenzt und
überlagert.
Mit dieser Arbeit wurden einige technische Voraussetzungen geschaffen, die neben der
Anpassung des Interaktionsparadigmas Navigation auch das Interaktionsparadigma Manipulation
in virtuellen 3D Umgebungen erlauben. So kann das entwickelte Sprachkonstrukt
‚DeviceSensor’ auch Eingabegeräte repräsentieren, die dazu benutzt werden, Objekte
in der virtuellen Welt zu manipulieren. Die im multimodalen Bediensystem realisierte
Funktionalität, mit welcher der Benutzer auf ein Objekt zeigen kann und mit einer
anderen Modalität angeben kann, in welcher Form er sich bezüglich des Objekts bewegen
will, kann um Befehle erweitert werden, mit denen der Benutzer angibt, was mit dem
Objekt geschehen soll.
Seite 115

Kapitel 10, Zusammenfassung
Abschließend wurden einige potentielle Erweiterungsmöglichkeiten identifiziert, die das
System für das Interaktionsparadigma Navigation in virtuellen 3D Umgebungen komplettieren.
Außerdem wurden einige Vorschläge diskutiert, die das Bediensystem auf das
Interaktionsparadigma Manipulation in virtuellen 3D Umgebungen erweitern.
Seite 116

Verzeichnisse
Abbildungsverzeichnis
Verzeichnisse
Abb. 1: Sicht auf die Szene im First Person Modus (links) und im Third Person Modus (rechts).... 12
Abb. 2: Szenengraph (schwarz) und Routengraph (rot) in VRML ............................ 22
Abb. 3: Ausführungsmodell von VRML ................................................................. 23
Abb. 4: Avatar lokales und Welt lokales Koordinatensystem .................................. 29
Abb. 5: Problem bezogene Parametrisierung des Avatar lokalen Koordinatensystems .... 30
Abb. 6: Das SixDof und das Examine Richtungssystem ......................................... 31
Abb. 7: Addition von nicht äquidistanten Positionsdifferenzen ................................ 33
Abb. 8: Sanfte Bewegungen durch Tiefpaßfilter .................................................... 34
Abb. 9: Typische Struktur eines VRML Browsers ................................................... 35
Abb. 10: Struktur eines VRML Browsers, der anpassbare Navigation unterstützt .......... 39
Abb. 11: Typische Struktur eines DeviceSensor Knoten ............................................ 42
Abb. 12: Zugriff a) auf einzelne Felder, oder b) auf den Event Knoten als Ganzes ........ 47
Abb. 13: Spacemouse ......................................................................................... 50
Abb. 14: Informationsfluß in der Navigator Implementierung von Contact ................ 71
Abb. 15: Filterung von Positionsdifferenzen ........................................................... 73
Abb. 16: Usability Labor des MIVIS Projekts .......................................................... 80
Abb. 17: Struktur des Multimodalen Bediensystems MIVIS ...................................... 80
Abb. 18: Auf haptische Modalitäten erweiterte Struktur des multimodalen Bediensystems MIVIS... 86
Abb. 19: Interner Aufbau des Navigator Moduls .................................................... 89
Abb. 20: Struktur der Implementierung des erweiterten MIVIS Systems ................ 101
Abb. 21: Struktur eines haptischen Interpreters .................................................. 103
Abb. 22: Das multimodale Bediensystem bei einem virtuellen Lehrstuhlrundgang ..... 104
Abb. 23: VR Interface im Auto – Radio hören und WAP surfen ............................... 105
Seite 117

Referenzen
Verzeichnisse
[1] Rikk Carey, Gavin Bell: The Annotated VRML 97 Reference Manual
http://www.best.com/~rikk/Book/, 2001
[2] International Standardization Organization http://www.iso.org, 2002
[3] J. Nielsen: Usability Engineering. Morgan Kaufmann Publishers Inc., 1993
[4] A. Hennig: Die andere Wirklichkeit, Addison Wesley, 1.Auflage, 1997
[5] Dipl.-Inform. Frank Althoff. Internet-Publikation,
http://www.mmk.e-technik.tu-muenchen.de/~alt/, 2001. MIVIS.
[6] F. Althoff, G. McGlaun, and M. Lang: Using Multimodal Interaction to Navigate in
Arbitrary Virtual VRML worlds. In Workshop on Perceptual User Interfaces (PUI),
Nov. 2001, Orlando, USA
[7] B. Schuller, F. Althoff, G. McGlaun, and M. Lang. Navigating in virtual worlds via
natural speech. In 9 th Int. Conf. on HCI, New Orleans, August 2001.
[8] P. Morguet et al. Comparison of approaches to continuous hand gesture recognition
for a visual dialog system. Proc. of ICASSP 99, pages 3549–3552, 1999.
[9] F. Althoff, H. Stocker, G. McGlaun und Manfred K. Lang: A Generic Approach for
Interfacing VRML Browsers to Various Input Devices and Creating Customizable 3D
Applications.
[10] Prof. Uwe Schöning. Theoretische Informatik kurz gefasst. BI-Wissenschaftsverlag,
1993.
[11] Prof. Ipke Wachsmuth. Informatik IV (Theoretische Informatik). Skript zur Vorlesung
im Sommersemester 1994, Universität Bielefeld, 1994.
[12] Gunter Spahn. Natürlichsprachliche Navigation in virtuellen Welten. Diplomarbeit,
Technische Universität München, 2000.
[13] Noam Chomsky. Internet-Publikation,
http://web.mit.edu/afs/athena.mit.edu/org/l/linguistics/www/chomsky.home.html,
2000. MIT Linguistics Faculty.
[14] K.-H. Engelmeier et al: “Virtual reality and multimedia human-computer interaction
in medicine”, IEEE Workshop on Multimedia Signal Processing, Los Angeles, Dec.
1998
[15] V. Pavlovic, G. Berry, T. Huang: BattleView: A Multimodal HCI Research Application.
In Workshop on Perceptual User Interfaces (PUI 98), Nov. 1998, San Francisco, USA
[16] F. Althoff, T. Volk et. al: A Generic User Interface Framework for VR Applications. In
Proceedings of Human Computer Interaction (HCI 2001), New Orleans, USA, Aug.
2001
[17] A. Cheyer, L. Julia et al: Designing and Developing Multimodal applications. In WS
on Pen/Voice Interfaces (CHI 99), Pittsburgh (USA), 1999
[18] Marc Brelot, Jean-Claude Dufourd: Ideas for new BIFS sensors and applications. At
50 th MPEG meeting, Dec 99
[19] F. Althoff, Gregor McGlaun et. al: Combining Multiple Input Modalities for Virtual
Reality Navigation – a User Study. In 9 th Int. Conf. on HCI, August 2001.
[20] B. Shneiderman, “Direct manipulation: A step beyond programming languages”,
IEEE Computer, 16(8):57-69, August 1983
[21] Document Object Model (DOM) Level 2 Specification,
http://www.w3.org/TR/1999/WD-DOM-Level-2-19990304/events.html, 2002
[22] Human Markup Initiative http://www.humanmarkup.org, 2002
Seite 118

Internet Seiten
Verzeichnisse
[23] Firma blaxxun interactive AG. http://www.blaxxun.com, 2002
[24] DeviceSensor SDK der Firma blaxxxun interactive AG.
http://www.blaxxun.com/developer/contact/3d/vrml/ui/devicesensorSDK/index.html,
Januar 2002
[25] Firma 3Dconnexion GmbH. http://www.3Dconnexion.com, 2002
[26] J. Stewart. FreeWRL Homepage. http://www-ext.crc.ca/FreeWRL, 2001.
[27] Firma SGI. http://www.sgi.com, 2002
[28] Firma Parallel Graphics. http://www.parallelgraphics.com, 2002
[29] Firma Nexternet. http://www.nexternet.com, 2002
[30] Firma Lernout &Hauspie. http://www.lhs.com, 2002
[31] Blendo Homepage. http://www.blendomedia.com, 2002
[32] Firma Microsoft Corporation. http://www.microsoft.com, 2002
[33] Firma Gravis. http://www.gravis.com, 2002
[34] Firma Logitech. http://www.logitech.com, 2002
[35] Firma id Software http://www.idsoft.com, 2002
[36] Der VRML Games Webring. http://www.farzone.net, 2002
[41] Ref. auf den USB HID Standard.
Seite 119

Anhang A Konventionen
Anhang A, Konventionen
Es werden in dieser Diplomarbeit einige Begriffe eingeführt, die abstrakte Zusammenhänge
beschreiben oder Systemkomponenten bezeichnen. Zur Kenntlichmachung werden
diese bei ihrem ersten Auftreten in einem Absatz in kursiver Schrift formatiert. An der
Stelle, an der diese Begriffe definiert werden, erhalten sie zusätzlich eine Unterstreichung.
Mathematische Formeln und Formelzeichen erhalten ebenfalls kursive Schrift.
Dieser Text enthält sowohl Auszüge aus VRML-Code, Pseudo-Code und kontextfreier
Grammatik. Um diese zu kennzeichnen werden verschiedene Formatierungen verwendet:
VRML Code wird in Courier New formatiert. Pseudo-Code tritt nur an einer Stelle in Kapitel
7 auf und wird deshalb ebenfalls in Courier New formatiert. Auszüge aus kontextfreier
Grammatik erhalten die Schriftart Lucida Console. Innerhalb des Fließtextes werden
diese zur besseren Unterscheidung punktiert unterstrichen. An einigen Stellen werden
VRML Knoten definiert. Obwohl diese definierenden Charakter haben, werden sie entgegen
der Konvention, Definitionen zu unterstreichen, diese fett formatiert, da sonst
mehrzeilige Abschnitte unterstrichen werden müßten.
In den Graphiken werden häufig Teile eines Szenengraphen von VMRL dargestellt. Diese
bestehen aus Knoten und Routen, die diese verbinden. (Näheres beschreibt Kapitel 4.)
Zudem werden Systemkomponenten einer Softwarearchitektur dargestellt. Sowohl Knoten
als auch Systemkomponenten werden als Rechtecke symbolisiert. Um beide voneinander
zu unterscheiden, erhalten Knoten einen Schatten. Der Typ eines Knoten steht in
der linken oberen Ecke.
VRML Knoten:
Shape
Systemkomponente:
Interpeter
Pfeile symbolisieren Informationsfluß zwischen Systemkomponenten bzw. Routen zwischen
VRML Knoten. Zur Unterscheidung werden unterschiedliche Strichstärken und Farben
benutzt.
Informationsfluß zwischen Systemkomponenten
Routen zwischen VRML Knoten
Seite 120

Anhang B, Beispielszenarios für angepaßte Navigation
Anhang B Beispielszenario s für angepaßte Navigation
Die typische Verwendung des DeviceSensor Knotens und des Navigator Knotens soll anhand
zweier Beispiele verdeutlicht werden. Das erste Beispiel demonstriert die Verwendung
der Geschwindigkeitsfelder des Navigator Knotens um den WALK Modus für ein rein
geschwindigkeitsorientiertes Eingabegerät, den Joystick zu implementiert. Das zweit Beispiel
zeigt, wie die positionsorientierten Felder des Navigator Knotens in Verbindung mit
einem positionalen Eingabegerät verwendet werden.
WALK Modus für Joystick
Der folgende VRML Code implementiert den WALK Modus für den Joystick nach den in
Abschnitt 6.6.3 vorgeschlagenen Proto Feldern.
PROTO JOY_STICK
[
eventOut SFVec2f stick
]
{}
DEF DS DeviceSensor
{
device "JOYSTICK"
event DEF JoyStick JOY_STICK {}
}
DEF JoyNav Script
{
eventIn SFVec2f stick
eventOut SFVec2f speedXYZ
eventOut SFVec2f speedYPR
field SFFloat MaxSpeed 5 # m/s
field SFFloat MaxAngularSpeed 1 # rad/s
url "vrmlscript:
function stick(s)
{
speedYPR= new SFVec3f(s.x * MaxAngularSpeed, 0, 0);
speedXYZ= new SFVec3f(0, 0, s.y * MaxSpeed);
}
"
}
DEF Cam Navigator
{
gravity TRUE
}
ROUTE JoyStick.stick TO JoyNav.stick
ROUTE JoyNav.speedXYZ TO Cam.speedXYZ
ROUTE JoyNav.speedXYZ TO Cam.speedYPR
Dieses VRML Code Fragment entspricht der Struktur DeviceSensor � Script � Navigator
aus Abb. 10. Kernstück ist die Funktion stick(�) des Script Knotens JoyNav, welche die
beiden Freiheitsgrade des Joysticks in eine Vorwärtsbewegung und eine horizontale Drehung
umwandelt. Die x Komponente, von stick, welche die horizontale Auslenkung des
Knüppels angibt, wird mit einem Umrechnungsfaktor multipliziert und der yaw Komponente
des speedYPR Feldes des Navigator Knoten zugewiesen, während die beiden anderen
Komponenten von speedYPR auf 0 gesetzt werden. Die y Komponente von stick wird
ebenso mit einem Umrechnungsfaktor multipliziert und der z Komponente des speedXYZ
Vektors zugewiesen. Eine Vorzeichenumkehr ist nicht notwendig, da bei Joysticks positive
y Werte beim Ziehen am Knüppel üblich sind.
Seite 121

Quake ähnlicher PAN Modus mit der Maus
Anhang B, Beispielszenarios für angepaßte Navigation
Die Maus ist ein positionales Eingabegerät, da sie die Position des Maus Cursors repräsentiert.
Doch anders als in Spielen wird sie in VRML Browsern häufig als Geschwindigkeitsorientiertes
Gerät verwendet. Bei einem Mausklick wird ein Ausgangspunkt definiert.
Wird anschließend die Maus bei gedrückter Maustaste bewegt, wird der Differenzvektor
vom Ausgangspunkt zur aktuellen Position des Mauszeigers gebildet und für die Steuerung
der Navigation verwendet. Das folgende Beispiel soll verdeutlichen, wie dem positionalen
Charakter der Maus Rechnung getragen wird, indem der in Spielen häufig vorkommende
Mausnavigation in VRML implementiert wird. Es demonstriert die Verwendung
des Navigator Knoten mit einem positionalen Eingabegerät und demonstriert die Methode,
auf den Event Knoten als ganzes zuzugreifen (siehe Abschnitt 6.5.3).
PROTO Event
[
field SFString type ""
field SFVec2f pixelPos 0 0
field SFInt32 button 0
] {}
DEF DS DeviceSensor
{
device "STANDARD"
parameter "mousedown mouseup mousemove"
}
DEF MausNav Script
{
eventIn SFNode event
eventOut SFVec3f stepYPR
field SFVec2f lastPos 0 0 # Position des letzten Ereignisses
field SFBool active FALSE # Sind wir aktiv?
url "vrmlscript:
function event(e)
{
if(e.type == 'mousedown')
{
if(button == 1)
{
lastPos= e.pixelPos;
active= true;
}
}else if(e.type == 'mouseup')
{
if(button == 1)
{
active= false;
}
}else if(e.type == 'mousemove')
{
if(active)
{
var deltaX= e.pixelPos.x - lastPos.x;
var deltaY= e.pixelPos.y - lastPos.y;
lastPos= e.pixelPos;
stepYPR= new SFVec3f( deltaX * RadPerPixel
, deltaY * RadPerPixel
, 0
);
}
Seite 122

}
}
"
}
DEF Cam Navigator
{
gravity TRUE
}
Anhang B, Beispielszenarios für angepaßte Navigation
ROUTE DS.event TO MausNav.event
ROUTE MausNav.speedXYZ TO Cam.stepXYZ
ROUTE MausNav.speedXYZ TO Cam.speedXYZ
Der DeviceSensor verwendet das in Abschnitt 6.6.4 vorgestellte Gerät „STANDARD”, um
an Mauseingaben zu gelangen. Diese werden als Ereignisse mit Hilfe eines Event Knoten
repräsentiert, der an den Script Knoten MausNav gesendet wird. Der Event Knoten enthält
ein type Feld, das den Typ des Ereignisses anzeigt, und einige Felder, die abhängig
davon die Parameter des Ereignisses widerspiegeln. Die Funktion event(�) wertet diese
Ereignisse aus, indem sie mit einem großen if - else if Ausdruck je nach Typ des Ereignis
in einen anderen Ausführungszweig verzweigt. Dies ist typisch für Geräte, welche die
Methode, auf den Event Knoten als Ganzes zuzugreifen, verwenden.
Die Maus soll zur Navigation dienen, solange die linke Maustaste gedrückt ist. Deshalb
wird bei Ereignissen vom Typ "mousedown" und "mouseup" das Flag active gesetzt bzw.
gelöscht, wenn das Ereignis von der ersten Maustaste stammt. active zeigt somit den
Zustand der linken Maustaste an.
An dem Zweig, der "mousemove" Ereignisse behandelt, wird die typische Behandlung positionaler
Eingabegeräte deutlich: Die Variable lastPos enthält die Mauszeigerposition
des dem aktuellen Ereignis vorausgehenden Ereignisses. Bei jedem Ereignis wird Differenz
der aktuellen Position zur vorherigen Position berechnet. Da bei einer bewegten
Maus sehr viele Ereignisse erzeugt werden, sind diese Differenzen klein. Sie werden mit
einem Umrechnungsfaktor multipliziert und als yaw bzw. pitch Wert an das positionale
Eingangsfeld stepYPR des Navigator Knotens gesendet. Da der Navigator Knoten die an
einem seiner mit step beginnenden Felder erhaltenen Werte zur aktuellen Position bzw.
Orientierung addiert, entsteht eine kontinuierliche Bewegung, deren Geschwindigkeit
proportional der Geschwindigkeit ist, mit der sich die Maus bewegt. Dazu mußte weder
eine Referenzposition zwischen Skript und Navigator Knoten vereinbart werden, noch
mußte berücksichtigt werden, mit welcher Rate die Mausereignisse erzeugt werden. Im
Prinzip werden Mausbewegungen (der Unterschied zwischen aktueller und letzter Position)
einfach an den Navigator weitergegeben.
Seite 123

Anhang C, Erweiterter Kommunikationsformalismus
Anhang C Erweiterter Kom munikationsformalismus
Dieser Anhang faßt die in Kapitel 8 entwickelte Grammatiken noch einmal zusammen.
Die in Abschnitt 8.1.1 erläuterten Konventionen für die Darstellung der Grammatik
werden hier wiederholt.
Konventionen
Bei einer kontextfreien Grammatik beschreiben die Bildungsregeln, wie eine Variable
durch andere Variablen unter Verwendung von Terminalsymbolen ersetzt werden. Diese
Abhängigkeit zwischen den Variablen wird durch eine Einrückung gekennzeichnet. Eine
Regel wird wenn möglich von solchen Regeln gefolgt, welche diese Regel benötigt. Diese
unterstützenden Regeln werden um eine Ebene weiter eingerückt, als die Regel, durch
die sie benutzt werden.
Ein Teil der Regeln dient dazu, die terminalen Symbole zu Wertebereichen zu gruppieren.
So definiert die Regel ::= on | off | toggle eine Variable, welche die terminalen
Symbole on, off und toggle zu einem Wertebereich kombiniert, der zur Kontrolle boolscher
Parameter benutzt werden kann. Solche Variablen und die Regeln, durch die sie
definiert werden, sind in grüner Farbe dargestellt. Damit diese Kennzeichnung auch auf
Schwarzweiß Ausdrucken erkennbar ist, werden Wertebereich definierende Regeln am
linken Rand mit Punkten markiert.
Eine spezielle Art von Variablen umfaßt einen allgemeingültigen Wertebereich oder Datentyp.
Da diese als allgemein bekannt vorausgesetzt werden können, und deren exakte
Definition von sekundärer Bedeutung für die Funktionsmodellierung ist, werden sie mit
kursiver Schrift notiert und nicht näher durch Produktionen definiert. Folgende Variablen
werden verwendet:
• : bezeichnet Ganzzahlen der Form 1234 oder -5678
• : bezeichnet Fließkomma-Zahlen der Form 10.23 oder –5.2e+20
• : bezeichnet beliebige Zeichenketten, die in Anführungszeichen stehen
Da in diesem Kapitel eine Grammatik entwickelt wird, die im Sinne der Funktionalität
sowohl kontextsensitive als auch kontextfreie Kommandos beschreibt, und da an bestimmten
Stellen nur kontextfreie Kommandos erlaubt sind, werden kontextsensitive
Kommandos mit dunkelroter Farbe gekennzeichnet. Zusätzlich werden diese durch einen
Strich am linken Rand, beziehungsweise mit einer punktierten Unterstreichung markiert.
Um die Lesbarkeit der Grammatik zu erhöhen, sind in der elektronischen Form dieser
Arbeit alle Variablen sensitiv gegenüber Mausklicks. Wird eine Variable angeklickt, springt
der Cursor an die Definition der Variable. Die Brauchbarkeit dieses Mechanismus hängt
jedoch vom verwendeten Dateiformat ab.
Die Namen von Variablen für Richtungsangaben werden in Anlehnung an das Avatar lokale
Koordinatensystem aus Abb. 4 aus Abschnitt 5.1.2 gewählt. Beschreibt z.B. eine
dieser Variablen horizontale und vertikale Richtungsangaben, wird sie XY genannt, da
horizontale Bewegungen entlang der x-Achse und vertikale Bewegungen entlang der y-
Achse wirken. Vorwärts- Rückwärtsbewegungen sind demgemäß dem Buchstaben Z zugeordnet.
Seite 124

Grammatik für Benutzereingaben
Anhang C, Erweiterter Kommunikationsformalismus
S ::=
::= |
::= | | | |
::= start
::= stop
::= walk | fly | examine
::= trans | rot
::= trans | rot | roll
::= trans | rot | roll
: ::= |
: ::= |
:
: ::= lfwd | rfwd | lbwd | rbwd
:
: ::= | |
: ::= |
: ::= |
:
: ::= left | right
: ::= up | down
: ::= forward | backward
| ::= ks
| ::= | | |
|
| ::= trans | trans
| ::= rot | rot
| ::= roll | roll
|
| ::=
::= | |
| ::= gothere
| ::= lookat
| ::= setexacenter
| ::= follow
| ::= indicated
| ::= indicated geometry
::= orientto pos
::= orientto dir
::= moveto
::= beamto pos
::= beamto watch
::= exacenter set
: ::= pos
: ::= ori
: ::= posori
: ::= posdir
: ::= dir
:
: ::=
: ::=
: ::=
Seite 125

::= mode set
::= mode restrict
::= stepsize
::= stepsize set
::= speed
::= speed set
::= light
::= viewpoint
::= viewpoint tour
::= viewpoint set
::= viewpoint set
::= collision
::= gravity
::= straighten
::= balance
| ::= repeat
::= undo
::= sendstatus
::= quit
Anhang C, Erweiterter Kommunikationsformalismus
: ::= walk | fly | examine
: ::= inc | dec | reset
: ::= on | off | toggle
: ::= prev | next | reset
: ::= all | stepsize | mode | light
: ::= viewpoint | collision | gravity
: ::= | end_list
: ::= x | y | z | yaw | pitch | roll | phi | omega | radius | rho
| A | B
Grammatik für Statusänderungen
S ::=
::= |
::= status
::= mode mode
::= mode continous
::= mode restricted
::= stepsize
::= speed
::= light
::= collision
::= gravity
::= viewpoint activated
::= viewpoint list_changed
::= isbeaming
::= collided
::= undoing nothingstored
::= undoing
::= light | collision | gravity | mode | position | viewpoint
: := walk | fly | examine
: ::= on | off
: ::= | end_list
: ::= x | y | z | yaw | pitch | roll | phi | omega | radius | rho | A | B
: ::=
: ::= | end_list
Seite 126

Anhang D, DeviceSensor SDK für blaxxun Contact
Anhang D DeviceSensor SD K für blaxxun Contact
In diesem Abschnitt ist die Programmierschnittstelle beschrieben, mit welcher der VRML
Browser blaxxun Contact um die Unterstützung für neue Eingabegeräte im DeviceSensor
Knoten erweitert werden kann. Die aktuellste Version dieses Software Development Kits
(SDK) ist unter http://www.blaxxxun.de/ zu finden. Es ist von dort unverändert übernommen,
und daher in Englischer Sprache.
To original file on the web.
Blaxxun DeviceSensor SDK
Blaxxun Contact provides a plug-in interface that allows to support further human input and output
devices. Devices like a space mouse or a game pad provide their input data to the VRML Scene using
the DeviceSensor node. See UI customizing documentation to learn more about that node.
A DeviceSensor plug-in is an in process COM object that supports one or more device types. It uses
EAI functions to access the event node and provide input data to its fields or reads output data from
them.
Please see the interface definition files
- blaxxunHID.idl for the interface to implement,
- blaxxunVRML.idl for the COM EAI.
Test.wrl shows how the DeviceSensor works with this sample plug-in. To register the prebuilt plug-in
doubleclick register.bat .
View the README.txt for an introduction about the sample plug-in source.
Table of Contents:
• Overview
• Reference
• IbxxHID::Init(�)
• IbxxHID::AddDeviceSensor(�)
• IbxxHID::RemoveDeviceSensor(�)
• IbxxHID::Tick(�)
• IbxxHID::EnabledChanged(�)
• IbxxHID::FocusChanged(�)
• Registration
Seite 127

Overview
Registration
Anhang D, DeviceSensor SDK für blaxxun Contact
The plug-in must register with Contact by writing its class id and the type of device(s) supported into
the registry.
Functionality
When Contact encounters one or more DeviceSensors that access the device supported by the plugin
Contact loads the plug-in and notifies it of the DeviceSensors. If several DeviceSensors access
different hardware devices of the same type, Contact loads one instance of the plug-in (which is a
COM object) for each hardware device.
When notifying a plug-in of a DeviceSensor Contact provides a pointer to the event Node, a pointer to
the isActive field and an id. The id allows Contact to refer to the DeviceSensor in subsequent calls.
On every simulation tick Contact calls the method Tick(�). The plug-in must use COM EAI to update
the fields on all of the DeviceSensors event nodes. In case of a feedback or output device the plug-in
must use COM EAI to read the event nodes field values.
When the enabled field of the DeviceSensor changes, or when the window that contains Contact
switches between foreground and background Contact notifies the plug-in.
Contact uses an id to refer to a DeviceSensor. This id is a small integer unique for a plug-in instance.
It is always the smallest unused integer value, so you can use this id directly as an array index.The id
0 is reserved for future use.
Semantics
If a DeviceSensor is disabled the plug-in should stop changing fields, not even reset the fields to their
default values. Fields read for output devices must be ignored.
When Contact has no input focus the plug-in must set the fields to their default values, as if there was
no user input during that period.
Fields read for output devices must be ignored.
If the plug-in does not support hot plugging of devices it does not need to set the isActive field of the
DeviceSensor explicitly. Suitable return values in the AddDeviceSensor(�) and EnabledChanged(�)
methods make Contact set the isActive field properly.
If the plug-in does support hot plugging of devices, it must treat an unplugged device the same way as
if the DeviceSensor was disabled, i.e. not change any fields and set isActive to FALSE.
Misc
Field Inversion:
In order to update the event node fields the plug-in must convert eventOuts to eventIns. The reason is
a logical one: To provide data to the world the event node must contain eventOut fields. But EAI defines
methods to set a field value only on eventIns or exposed fields.
Therefore Contact supports the conversion of an eventOut to an eventIn and vice versa through the
QueryInterface(�) mechanism.
Focus Logic:
Contact traces whether it runs in the foreground or background window and notifies the plug-in about
changes. This allows a plug-in that doesn't use DirectX to easily do focus logic, and for DirectX plugins
it ensures that data continues to be supplied to the world if the chat input line has keyboard focus
or a dialog box like the console is open. DirectX plug-ins must set a background cooperative level.
When they need to supply a window handle to SetCooperativeLevel(�) they can optain one from Get-
DesktopWindow().
Seite 128

Reference
Anhang D, DeviceSensor SDK für blaxxun Contact
The plug-in is a COM object that supports the
interface IbxxHID with interface id 4256A70F-7DD7-478F-BC2E-1A84D1B68FAC.
IbxxHID::Init(����)
HRESULT Init( [in] BSTR Device
, [in] int DeviceNo
, [in] Browser* pBrowser
, [out, retval] int *pDeviceNoUsed
);
Device: The name of the device that should be supported by the plug-in object. If the
plug-in supports multiply device types it can decide on this parameter which
device is requested.
DeviceNo: The device number that should be supported, or 0 if no devicenumber was given
in the VRML content.
pIBrowser: This is a COM EAI pointer to the browser object. It is not really needed, but may
be useful for special cases. See the file blaxxunVRML.idl for its methods.
pDeviceNoUsed: On success this must be set to the device number the plug-in will use. On failure
this must be set to 0.
If DeviceNo is not 0 and the initialization succeeds, pDeviceNoUsed must not
differ from DeviceNo.
IbxxHID::AddDeviceSensor(����)
Contact calls AddDeviceSensor(�) to notify the plug-in of a DeviceSensor and its event node.
Please note that DeviceSensors can be added and removed at any time, as inlines are loaded or
nodes are deleted through scripts.
HRESULT AddDeviceSensor( [in] BSTR eventType
, [in] Node* pEventNode
, [in] EventInSFBool* pIsActive
, [in] BOOL Enabled
, [in] int ID
, [out, retval] int *pRetVal
);
eventType: The value of the eventType field. It can be used to define device specific parameters.
pEventNode: A COM EAI pointer to the event node. The plug-in object must use COM EAI to
set the fields of this node in order to provide user input or read their values for
output devices.
pIsActive: A COM EAI pointer to the isActive field of the DeviceSensor. If the plug-in doesn't
support hot swapping, it can ignore this pointer. But if it does, it must set it to
TRUE only if the DeviceSensor is enabled and the device is plugged in.
Enabled: The current value of the DeviceSensors enabled field. The plug-in is notified of
future changes to the enabled field through the EnabledChanged(�) method.
ID: An identifier Contact uses to refer to this DeviceSensor in subsequent method
calls. It is always the smallest unused integer value, so the plug-in can use it as
an array index. The number 0 is reserved for future use.
pRetVal: On failure this should be set to -1. On success this should be set to 0 or 1. On 0
Contact sets the isActive field to FALSE, on 1 to TRUE.
If Enabled is FALSE, Contact sets isActive to FALSE regardless of the returned
value.
Seite 129

IbxxHID::RemoveDeviceSensor(����)
HRESULT RemoveDeviceSensor( [in] int ID );
IbxxHID::Tick(����)
Anhang D, DeviceSensor SDK für blaxxun Contact
ID: The number of the DeviceSensor that should be removed.
Contact calls the Tick(�) method to allow the plug-in object to do some computations. Typically the
plug-in queries the state of the device and updates the fields of all connected event nodes.
HRESULT Tick( [in] double SimTime
, [in] double FrameRate
);
SimTime: This is the time stamp that is currently simulated. Fields that are changed from
inside Tick(�) will get this time stamp.
FrameRate: This is an estimation of the current frame rate. Tick(�) will be called about FrameRate
times per second.
IbxxHID::EnabledChanged(����)
HRESULT EnabledChanged( int ID
, BOOL Enabled
, [out, retval] BOOL* pSetIsActive
);
ID: The identifier for the DeviceSensor whose enabled field has changed.
Enabled: The new value of the enabled field.
pSetIsActive: If Enabled is TRUE, this must be set to what Contact should set the isActive field
to. If Enabled is FALSE, this is ignored.
If the plug-in does not support hot plugging, *pSetIsActive can always be set to
TRUE.
IbxxHID::FocusChanged(����)
Contact tracks whether it runs in the foreground or background application and notifies the plug-in
about changes. (The foreground application is the one the user works with). If the application is in the
background, the plug-in should set the fields of the event node to values that correspond to the home
position of all input elements on the device.
HRESULT FocusChanged( [in] BOOL HasFocusNow
, [out, retval] BOOL *pNeedTickCalls
);
HasFocusNow: TRUE if Contact now runs in the foreground window, FALSE if it runs in a back
ground window.
pSetIsActive: Set this to false if it is not necessary that Contact continues calling the Tick(�)
method in the future. Contact reads this only if HasFocusNow is FALSE.
Seite 130

Registration
Anhang D, DeviceSensor SDK für blaxxun Contact
The plug-in must register with Contact in the registry. It must create a sub key that has the supported
device as key name. This name is the one that the DeviceSensors device field must contain to load
the plug-in. Lookup of this key is done case sensitive.
In the sub key a string value (REG_SZ) named 'CLSID' must contain the class id of the plug-ins COM
object in curly braces.
The place to create this key is
Software\blaxxun interactive\blaxxunCC3D\plugins\device. Contact first looks up this
path below HKEY_CURRENT_USER, then below HKEY_LOCAL_MACHINE.
If the plug-in needs to store some private data in the registry that can be deleted when Contact is
uninstalled, it should create a sub key named 'data' in its key (the one that contains CLSID). Other
names are reserved for future use by Contact.
Example:
A plug-in for a space mouse that needs to store some calibration data would create the key
HKEY_CURRENT_USER\Software\blaxxun interactive\blaxxunCC3D\plugins\device .
Here it creates a REG_SZ value named 'CLSID' that and contains the string “{FB4B5F65-0962-4374-
B223-5CAA21C61317}”. A sub key named 'data' stores the calibration data.
Seite 131