Konzeption und Realisierung der Integration einer ... · Konzept integriert werden kann, befaßt sich der nächste Abschnitt mit Grundlagen der Benutzungsfreundlichkeit und visueller

Konzeption und Realisierung der Integration einer komponentenbasierten virtuellen

Umgebung in ein Trainingssystem

Diplomarbeit von Markus Bork Matrikelnummer: 724412

31. Juli 2000

Technische Universität Darmstadt Fachbereich Informatik

Fachgebiet Graphisch Interaktive Systeme Prüfer: Prof. Dr.-Ing. Dr. h.c. Dr. E.h. José L. Encarnação Betreuer: Dipl.-Inform. Ralf Dörner Dipl.-Inform. Paul Grimm

3

Aufgabenstellung Für die Diplomarbeit von

Herrn cand.-inform. Markus Bork Matrikel-Nummer 724412

Konzeption und Realisierung der Integration einer Komponentenbasierten virtuellen Umgebung in ein Trainingssystem

ETOILE (Environment for Team, Organisational and Individual Learning in Emergencies) ist ein in der Programmiersprache Java implementiertes System, das ein Kommunikationstraining für Notfallsituationen auf Managementebene ermöglicht. Der Trainierende kann dabei mit einer zweidimensionalen graphischen Benutzungsschnittstelle interagieren. Darüberhinaus ist eine über Netzwerk verteilte virtuelle 3D Umgebung für Lernerinteraktionen essentiell. Diese ist als externes Visualisierungssystem über das Java Native Interface an ETOILE angeschlossen. Mit dem Java3D Paket von Sun Microsystems besteht nun die Möglichkeit, eine Visualisierung in ETOILE intern vorzunehmen und den in ETOILE bei der Verhaltensbeschreibung und der Erstellung des 2D GUI verwendeten komponentenbasierten Ansatz auf die virtuelle Umgebung auszudehnen. Auf Java Seite ist dabei das Java Beans Komponentenkonzept von hoher Relevanz, das aber zunächst geeignet auf dreidimensionale Entitäten ausgedehnt werden muß. Ziel der Arbeit ist, die in ETOILE bestehende externe virtuelle Umgebung durch eine intern in Java3D realisierte Visualisierung zu ersetzen. Dabei ist zunächst eine Konzeption derart zu erstellen, daß Ansätze der Komponententheorie umgesetzt und erweitert werden. Darüberhinaus sind die entsprechend konzeptionierten Komponenten mit den bislang bestehenden Komponenten zu integrieren und Vorteile der Komponentenverwendung für den Autoren verfügbar zu machen. An einer prototypischen Beispielszene ist das Konzept zu illustrieren und zu evaluieren. Bei der Evaluierung ist insbesondere anhand zu erarbeitender Kriterien ein Vergleich zwischen der bestehenden und der im Rahmen der Diplomarbeit realisierten Lösung zu ziehen. Betreuer: Dipl.-Inform. Ralf Dörner, Fraunhofer IGD Dipl.-Inform. Paul Grimm, Fraunhofer IGD Darmstadt, den 1. Februar 2000

Wird durch Original ersetzt

4

5

Diplomarbeit von Herrn Markus Bork

Erklärung zur Diplomarbeit gemäß § 19 Abs. 6 DPO/AT Hiermit versichere ich, die vorliegende Diplomarbeit ohne Hilfe Dritter nur mit den angegebenen Quellen und Hilfsmitteln angefertigt zu haben. Alle Stellen, die aus Quellen entnommen wurden, sind als solche kenntlich gemacht worden. Diese Arbeit hat in gleicher oder ähnlicher Form noch keiner Prüfungsbehörde vorgelegen. Darmstadt, den 31. 7. 2000 ________________________________ Unterschrift

6

7

Inhaltsverzeichnis 1 Einleitung .................................................................................................................11

2 Grundlagen ..............................................................................................................13

2.1 Modell der Softwareentwicklung mit wiederverwendbaren Komponenten ......13 2.1.1 Architekturen...............................................................................................17

2.1.1.1 CORBA ................................................................................................17 2.1.1.2 COM / DCOM......................................................................................19 2.1.1.3 JavaBeans .............................................................................................20

2.2 Benutzungsfreundlichkeit und visuelles Programmieren...................................25 2.2.1 Visuelles Programmieren ............................................................................25

2.2.1.1 Visuelle Programmiersprachen ............................................................25 2.2.1.2 Entwicklungsumgebungen für graphische Schnittstellen ....................27 2.2.1.3 Bewertung eines visuellen Systems .....................................................29

2.2.2 Benutzungsfreundliche Entwicklung von VR-Systemen............................29 2.2.3 Schlußfolgerung ..........................................................................................32

2.3 VR-Systeme .......................................................................................................32 2.3.1 VR-Technologien ........................................................................................34 2.3.2 Softwaresysteme..........................................................................................35

2.3.2.1 Komponenten eines Softwaresystems..................................................35 2.3.2.2 OpenGVS .............................................................................................40 2.3.2.3 Java3D..................................................................................................42

2.4 Konzept der dreidimensionalen Beanbox ..........................................................47 2.4.1 Struktur eines Beans der dreidimensionalen Beanbox................................49 2.4.2 Schlußfolgerung ..........................................................................................49

3 Das ETOILE-System...............................................................................................51

3.1 Anwendung von JavaBeans in ETOILE ............................................................52

3.2 Das Kommunikationssystem..............................................................................52

3.3 Das VR-System ..................................................................................................53 3.3.1 Die Systeme des VR-Teils ..........................................................................53 3.3.2 Modellstruktur der Datenbank ....................................................................54 3.3.3 Die Mapping-Table .....................................................................................55 3.3.4 Die Schnittstelle zum ETOILE-System ......................................................56

4 Konzept des komponentenbasierten VR-Systems................................................58

4.1 Eigenschaften der dreidimensionalen Beans......................................................59

4.2 Beschreibung der Architektur ............................................................................61 4.2.1 Aufgaben des VR-Systems..........................................................................61

4.2.1.1 Verwaltung der 3D-Beans....................................................................61 4.2.1.2 Visualisierung der Szene......................................................................62 4.2.1.3 Eingabeverarbeitung.............................................................................62

Inhaltsverzeichnis

8

4.2.1.4 Kommunikation....................................................................................63 4.2.1.5 Simulation ............................................................................................63

4.2.2 Architektur des VR-Systems.......................................................................63 4.2.3 Architektur des Editors................................................................................65

4.3 Überlegungen zur Benutzungsfreundlichkeit.....................................................66 4.3.1 Interaktionsschnittstelle der VR ..................................................................66 4.3.2 Interaktionsschnittstelle des Editors............................................................69

5 Implementierung .....................................................................................................73

5.1 Programmstruktur...............................................................................................73 5.1.1 Implementierung der 3D-Beans ..................................................................73

5.1.1.1 Klassenstruktur.....................................................................................74 5.1.1.2 Die Klasse EtBean3D...........................................................................74 5.1.1.3 Die Klasse EtVrScenario......................................................................75 5.1.1.4 Die Klassen der sichtbaren Beans ........................................................76 5.1.1.5 Die Klassen der nicht sichtbaren Beans ...............................................79

5.1.2 Implementierung des VR-Systems..............................................................81 5.1.2.1 Klassenstruktur.....................................................................................81 5.1.2.2 Die Dateiverwaltung ............................................................................82 5.1.2.3 Die Klassen für die Visualisierung und Navigation.............................85 5.1.2.4 Das Interface EtVrSelectionFeedback .................................................86 5.1.2.5 Die Klasse EtVrCollisionDetection .....................................................86 5.1.2.6 Die Objektverwaltung ..........................................................................87 5.1.2.7 Die Klasse EtVrCommunication..........................................................87 5.1.2.8 Die Klasse EtVrControl .......................................................................88

5.1.3 Implementierung des Editors ......................................................................89

5.2 Schwierigkeiten bei der Implementierung .........................................................90 5.2.1 Serialisierung der 3D-Beans........................................................................90 5.2.2 Verwendung der 3D-Beans in der Beanbox................................................91 5.2.3 Probleme bei Verwendung von Interpolatoren ...........................................92 5.2.4 Realisierung der Kollisionserkennung ........................................................92

5.3 Anwendung der Applikationen ..........................................................................93 5.3.1 Benutzung des VR-Systems als Teilnehmer ...............................................93 5.3.2 Benutzung des VR-Systems als Trainer......................................................94 5.3.3 Bedienung des Mappers ..............................................................................95

6 Evaluierung..............................................................................................................98

6.1 Kriterien zur Evaluierung...................................................................................98

6.2 Ein Beispielszenario...........................................................................................99

6.3 Vergleich der beiden Systeme..........................................................................100 6.3.1 Erstellen des Szenarios..............................................................................100

6.3.1.1 Der Modellierungsprozeß mit dem ursprünglichen System...............100 6.3.1.2 Modellieren mit dem komponentenbasiertem System.......................101 6.3.1.3 Fazit ....................................................................................................105

6.3.2 Bedienung des VR-Systems ......................................................................105 6.3.3 Grad der Immersion ..................................................................................106

9

6.3.4 Erweiterbarkeit und Wiederverwendbarkeit .............................................108

6.4 Ergebnis............................................................................................................109

7 Zusammenfassung und Ausblick .........................................................................111

Anhang: Literaturverzeichnis.................................................................................115

10

11

1 Einleitung In vielen Bereichen, in denen es nötig ist, komplexe Aufgaben zu trainieren oder allgemein Wissen durch praktische Demonstrationen zu vermitteln, werden vermehrt Softwaresysteme angewendet, die diese Trainingssituationen mit Hilfe virtueller Realität simulieren. Ein Vorteil dieser Systeme sind nicht zuletzt die im Vergleich zu konventionellem Training niedrigeren Kosten. Eines dieser Trainingssysteme ist das am Fraunhofer Institut für graphische Datenverarbeitung in Darmstadt entwickelte ETOILE (Environment for Team, Organisational and Individual Learning in Emergencies). Diese Anwendung erlaubt es, Notfallsituationen auf der Organisations- und Kommunikationsebene zu trainieren. Dabei ist es möglich, daß das Training über ein Computernetzwerk verteilt abläuft. Das simulierte Szenario, in dem die Teilnehmer Aktionen ausführen, wird dabei in einer dreidimensionalen virtuellen Welt dargestellt. Weiterhin verwendet das System intelligente Agenten, die als "Mitspieler" die Rolle von weiteren Trainingsteilnehmern übernehmen können. Die Konstruktion von Szenarien ist möglich, ohne daß das System neu programmiert werden muß, das heißt der Anwender kann auch ohne tiefere Kenntnisse des Systems neue Schauplätze und Situationen erstellen, die danach simuliert werden. Motivation Das ETOILE-System besteht aus zwei monolithischen Blöcken, welche durch einen Kommunikationsbus verknüpft sind: das System zur logischen Simulation des Trainings und dem Virtual-Reality-System (VR-System). Obwohl diese objektorientiert realisiert wurden, sind Modifikationen entsprechend aufwendig und eine Änderung an einem Teil des Programms kann sich auf das ganze System auswirken. Ein weiteres Problem betrifft die Erstellung neuer Szenarien. Obwohl hierzu keine Programmierkenntnisse nötig sind, ist dieser Prozeß noch recht umständlich. ETOILE stellt für die logische Beschreibung eines Szenarios und die Erstellung von Skripten für Agenten schon teilweise Editoren zur Verfügung. Die Geometrie der virtuellen Szene muß mit einem externen Modellierungstool erstellt werden. In den logischen Beschreibungen der Trainingssituation und des Agentenverhaltens werden die in der Szene vorkommenden Objekte durch symbolische Namen referenziert. Um diese Namen den dreidimensionalen Objekten des erstellten Modells zuzuweisen, muß mit einem Texteditor schließlich eine Zuordnungstabelle erstellt werden. Im Hinblick auf diese Probleme wird das Konzept der komponentenbasierten Soft-wareentwicklung interessant. Hier soll die Produktivität und Flexibilität von Soft-waresystemen erhöht werden, indem man diese aus vorgefertigten, wiederverwendbaren Softwarekomponenten konstruiert. Eine solche Einheit kann durch andere Komponenten mit ähnlicher Funktionalität ersetzt werden, zudem können Komponenten auch in anderen Systemen wiederverwendet werden [ScAs00]. Ein Komponentenmodell ist in Java schon mit dem Konzept der JavaBeans integriert [Hami00]. Zudem besteht hier die Möglichkeit, diese Beans visuell, in einer

Kapitel 1: Einleitung

12

sogenannten Beanbox, anzupassen und zu neuen Beans zu kombinieren. Dieses Konzept wurde mit einer in Java3D implementierten Beanbox auf dreidimensionale Komponenten ausgedehnt [Rein99]. Ziel dieser Arbeit ist es nun, ein VR-System zu konzeptionieren, das auf einem komponentenbasierten Ansatz aufbaut und die vorhandene Realisierung ersetzt. Die Verwendung von Softwarekomponenten sollte vor allem die Vorteile nutzbar machen, die dieser Aspekt für den Autoren eines Trainingsszenarios mit sich bringt, nämlich die Möglichkeit, Objekte visuell anzupassen und zu Szenen zu kombinieren. Der größte Teil des ETOILE-Systems ist in der Programmiersprache Java [Java00] realisiert worden. Der Teil, der für die Darstellung der virtuellen Szenen zuständig ist, wurde jedoch als ein externes System in C++ implementiert und über das Java Native Interface (JNI) angeschlossen (siehe Bild 1.1).

Bild 1.1: Anbindung des VR-Systems an ETOILE über JNI. Im Gegensatz dazu soll das neue System in ETOILE integriert werden können, also nicht mehr als separater Teil existieren. Da ETOILE in Java implementiert ist und mit JavaBeans schon eine nutzbare Architektur für komponentenbasierte Systeme vorliegt, wird für die Realisierung Java und Java3D verwendet, zumal mit der dreidimensionalen Beanbox schon ein Konzept für 3D-Beans entwickelt wurde. Gliederung der Arbeit In Kapitel 2 werden zunächst die Grundlagen der Konzepte und Technologien behandelt, die für diese Arbeit von Bedeutung sind. Das Trainingssystem ETOILE wird in Kapitel 3 beschrieben. In Kapitel 4 wird dann aufbauend auf den vorhergehenden Kapiteln ein Konzept für das komponentenbasierte VR-System entwickelt werden. Die resultierende Implementierung des Systems wird in Kapitel 5 vorgestellt, in Kapitel 6 soll das Konzept und dessen Umsetzung dann anhand eines Beispielszenarios evaluiert und mit dem ursprünglichen System verglichen werden. Kapitel 7 schließlich faßt die in der Arbeit gewonnenen Erkenntnisse zusammen und gibt einen Ausblick auf mögliche Weiterentwicklungen.

ETOILE

(Java)

VR-System

(C++)

JNI

13

2 Grundlagen In diesem Kapitel sollen einige Grundlagen behandelt werden, die für den zu erstellenden Entwurf des Systems von Bedeutung sind. Zunächst wird auf die komponentenbasierte Softwareentwicklung eingegangen, auf die diese Arbeit zu großen Teilen aufbaut. Dabei wird dieses Konzept erst allgemein vorgestellt und danach das verwendete Modell der JavaBeans beschrieben. Ein Vorteil der Verwendung von Komponenten ist die Tatsache, daß es leicht möglich ist, diese visuell zu bearbeiten. Damit dieser Aspekt sinnvoll in das allgemeine Konzept integriert werden kann, befaßt sich der nächste Abschnitt mit Grundlagen der Benutzungsfreundlichkeit und visueller Programmierung. Ein weiterer Abschnitt geht auf Systeme zur Darstellung von virtueller Realität ein. Dabei sollen zunächst VR-Systeme allgemein beschreiben werden, sowie die Graphikbibliotheken Java3D und OpenGVS. Letztere wurde für die Realisierung des ursprünglichen VR-Systems verwendet, erstere soll Grundlage des hier zu entwickelnden Systems sein. Schließlich wird noch kurz auf die dreidimensionale Beanbox eingegangen, auf deren Konzept der 3D-Beans die in dieser Arbeit verwendeten Komponenten aufgebaut werden sollen.

2.1 Modell der Softwareentwicklung mit wiederverwendbaren Komponenten

Der grundsätzliche Aspekt, der das in dieser Arbeit beschriebene System von der ursprünglichen Realisierung unterscheiden wird, ist die Anwendung von Prinzipien der komponentenbasierten Softwareentwicklung und die Nutzung der sich daraus ergebenden Vorteile. Aus diesem Grund soll in diesem Kapitel eine Definition dieses Konzeptes gegeben und die erwähnten Vorteile geschildert werden. Auch die Unterschiede zu der herkömmlichen Softwareentwicklung werden erläutert. Im Anschluß werden einige wichtige existierende Architekturen beschrieben, wobei auf das Modell der JavaBeans, das für diese Arbeit verwendet werden soll, genauer eingegangen wird. Bei der komponentenbasierten Softwareentwicklung (Component-based software development, CBSD oder auch –engeneering, CBSE) werden große Softwaresysteme durch das Zusammenfügen vorgefertigter Softwaremodule erstellt [Ober00], [Hain00],[BrWa98], [ScAs00], [Lee00]. Eine solche Softwarekomponente ist dabei eine weitgehend unabhängige Einheit des Systems, bestehend aus einem oder mehreren Programmen [BrWa98]. Die Funktionalität, die diese Einheit zu Verfügung stellt, ist durch wohldefinierte Schnittstellen (Interfaces) beschrieben. Nur über diese Schnittstellen wird auf die Komponente zugegriffen, die Implementierung ist für den Benutzter vollständig transparent. Hier liegt also ein noch höherer Abstraktionsgrad

Kapitel 2: Grundlagen

14

vor als zum Beispiel bei der objektorientierten Softwareentwicklung, bei der unter Umständen direkt auf Felder zugegriffen werden kann. Damit kann man eine Komponente in gewissen Grenzen als eine Art "Ersatzteil" für das System ansehen: sie kann bei Bedarf gegen eine andere (verbesserte) Einheit ausgetauscht werden, die nur zu derselben Schnittstelle konform sein muß. Ebenso kann eine Softwarekomponente in anderen Systemen beliebig wiederverwendet werden. Die grundlegende Idee hierbei ist, allgemeine Programmfunktionen nicht immer wieder neu zu programmieren, sondern nur einmal in Form von Softwaremodulen zu implementieren, die dann wiederverwendet werden können. Die Vorteile, die diese Eigenschaften gegenüber der herkömmlichen Systementwicklung mit sich bringen, sind: 1) Das System ist flexibler und leichter zu pflegen. Soll die Funktionalität des

Systems geändert werden, reicht es aus, nur die entsprechenden Komponenten auszutauschen, zu entfernen oder hinzuzufügen.

2) Die Kosten werden reduziert und die Systementwicklung beschleunigt.

Typischerweise werden einige oder alle verwendeten Komponenten von Fremdherstellern entwickelt (sogenannte Commercial-off-the-shelf- oder COTS-Produkte). Die Komponenten sind nicht auf die Verwendung in einem einzigen System beschränkt. Das heißt, anders als bei der Entwicklung herkömmlicher Softwaresysteme, werden die Kosten für Wartung und Entwicklung nicht mehr nur von einem einzelnen Kunden getragen, sondern mit anderen Benutzern geteilt. Auch das Erstellen des Systems beschleunigt sich, da die Komponenten nicht mehr selbst entwickelt, sondern nur noch in das System integriert werden müssen.

Die Philosophie, die hier angewandt wird ist also "kaufen, nicht entwickeln" [Hain00]: der Schwerpunkt hat sich vom Programmieren hin zum Zusammenfügen vorhandener Module verschoben. Ein Beispiel, wie der komponentenbasierte Ansatz sinnvoll angewendet werden kann, findet sich in [Goer97]:

Für die Entwicklung von Benutzerschnittstellen existieren zwei maßgebliche Standards, die dem Entwickler etwa 400 technologieneutral formulierte Regeln bieten. Eine Benutzerschnittstelle zu entwerfen, die jeder dieser Regeln gerecht wird, bedeutet einen enormen Arbeitsaufwand. Die Idee ist nun, sogenannte Dialogbausteine zu verwenden. Dabei handelt es sich um vordefinierte Interaktionselemente graphischer Benutzerschnittstellen, also wiederverwendbare Komponenten wie etwa Knöpfe oder Schiebregler.

Diese einzelnen Elemente lassen sich wesentlich einfacher entsprechend eines Standards implementieren. Solche auf Ergonomie geprüften einfachen Bedienelemente lassen sich wiederum zu größeren kombinieren. Eine Benutzerschnittstelle, die aus solchen Bausteinen aufgebaut ist, ist selbst in höherem Maße konform zu den Richtlinien, als wenn sie komplett neu aufgebaut worden wäre. Dadurch ergibt sich neben dem reduzierten Programmieraufwand auch eine beschleunigte Qualitätssicherung.

2.1. Modell der Softwareentwicklung mit wiederverwendbaren Komponenten

15

Ein weiterer Bereich, in dem der komponentenbasierte Ansatz damit vorteilhaft eingesetzt werden kann, ist die visuelle Erstellung graphischer Benutzungsoberflächen mit speziellen Entwicklungswerkzeugen (GUI Builder) [Bray00]. Da es sich bei den Komponenten um visuelle Objekte wie Knöpfe oder Regler handelt, ist es möglich diese mit der Maus auf der Arbeitsfläche zu plazieren und so die Oberfläche anschaulicher und mit geringerem Zeitaufwand zu erstellen und zu modifizieren. Der Prozeß der komponentenbasierten Softwareentwicklung läßt sich in vier Phasen unterteilen [Hain00]:

1) Komponentenqualifikation. Aus den vorhandenen Komponenten müssen diejenigen ausgewählt werden, die für die Verwendung in dem geplanten System geeignet sind. Dafür müssen erst die Eigenschaften der Komponente ermittelt werden, wie zum Beispiel die Funktionalität oder die Erfüllung eines Standards durch das Interface. Anschließend werden diese Informationen evaluiert und die Eignung für das System festgestellt.

2) Komponentenadaption.

Für die Nutzung in einem neuen System müssen Komponenten oft angepaßt werden. Je nachdem, zu welchem Grad eine Komponente diese Anpassung zuläßt, kann sie einer der folgenden Kategorien zugeordnet werden:

• White box: der Quellcode der Komponente selbst kann beliebig geändert

werden. • Grey box: der Quellcode ist nicht zugänglich, doch die Komponente stellt

eine eigene Programmiersprache oder API (application programming interface) zur Verfügung.

• Black box: weder Quellcode noch eine Programmiersprache oder API sind vorhanden, nur der binäre Code. Die Komponente kann aber zum Beispiel über Funktionen, die sie anbietet, angepaßt werden.

3) Zusammenfügen der Komponenten zu einem oder mehreren Systemen. Die angepaßten Komponenten müssen nun durch eine Infrastruktur integriert werden. Diese dient dabei als der "Klebstoff", der die Komponenten verbindet.

Die Infrastruktur ist für die Koordination und Kommunikation zwischen den Komponenten verantwortlich. Damit sie von den Komponenten benutzt werden kann, unterliegen diese bestimmten Einschränkungen, die ihnen von der Infrastruktur auferlegt werden. Dies kann etwa ein Namensstandard (JavaBeans) oder auch eine vorgegebene binäre Struktur sein (COM / DCOM, [Com00]).

Für die Realisierung der Infrastruktur gibt es mehrere Möglichkeiten, zum Beispiel als Datenbank, Nachrichtenbus oder mittels eines ORBs (Object request broker, siehe auch Kapitel 2.1.1.1).


16

4) Evolution der Komponenten. Das Weiterentwickeln und Verbessern des Systems geschieht durch Ersetzen beziehungsweise Hinzufügen von Komponenten. Neue Komponenten werden sich von ihren Vorgängern unterscheiden, sie müssen daher zuvor ausgiebig getestet und entsprechend angepaßt werden.

Dieser Ansatz der Systementwicklung bringt wiederum neue Probleme mit sich. Anbieter von Komponenten müssen sich bei der Definition ihrer Schnittstellen nicht unbedingt an einen allgemeinen Standard halten. Diese Komponenten sind dann meist nur zu solchen des gleichen Anbieters kompatibel, was die Integration und Evolution erschwert. Daher ist es wichtig, auf derartige Probleme schon in der Qualifikationsphase einzugehen. In diesem Zusammenhang ist die Kombination der Idee von kommerziell beziehungsweise öffentlich verfügbaren Komponenten mit dem Konzept der offenen Systeme (open systems) ein großer Vorteil [Ober00]. Ein offenes System stützt sich hauptsächlich auf die Anwendung von stabilen Standardschnittstellen bei der Konzeption eines Systems und auf die Benutzung solcher Implementierungen, die zu diesen Standards konform sind. Diese Standardschnittstellen sind

• vollständig definiert, und • für jeden zugänglich.

Das heißt jeder hat Zugriff auf die Spezifikationen und kann dazu konforme Produkte (das müssen nicht zwangsläufig Softwarekomponenten sein) erstellen und anbieten. Da alle Anbieter sich nach den gleichen Schnittstellen richten, gibt es weniger Konflikte bei der Integration fremder Komponenten in ein System. Die Verwendung dieser Standards erhöht also die Wiederverwendbarkeit der Komponenten und die Stabilität der Systeme, in denen sie verwendet werden. Neben der Sicht der Komponenten als kommerziell erhältliche Softwarebausteine zur Systementwicklung gibt es noch die Sicht der komponentenbasierten Entwicklung als Designphilosophie. Dies ist auch der Ansatz, der bei der vorliegenden Arbeit von primärer Bedeutung sein wird. Unabhängig von der Wiederverwendbarkeit einzelner Komponenten liegt der Schwerpunkt hier auf dem Aspekt der Flexibilität und Erleichterung der Pflege des Systems. Komponenten sind hier mehr als applikationsspezifische Daten anzusehen, da diese in Hinblick auf eine spezielle Anwendung oder ein Anwendungsgebiet entworfen werden. Der Systementwurf konzentriert sich auf die Ausarbeitung der Schnittstellen, die durch eine Infrastruktur verknüpft werden. Das System setzt sich dann aus zu diesen Spezifikationen konformen Implementierungen zusammen. Einzelne Komponenten können dann wiederum von neueren Versionen ersetzt, beziehungsweise innerhalb des System oder bei neuen Projekten wiederverwendet werden. Während bei COTS-Produkten die Komponenten vorwiegend nach dem Black-Box Prinzip zu Systemen zusammengefügt werden, sind hier auch White-Box bezie-hungsweise Grey-Box Ansichten denkbar.


17

2.1.1 Architekturen Wie schon erwähnt, ist die verwendete Infrastruktur untrennbar mit den Komponenten verbunden. Sie erlaubt die Kommunikation zwischen Komponenten, gibt Auskunft darüber, welche Komponenten vorhanden sind und liefert Referenzen auf diese zurück. Die Komponenten müssen "wissen", wie die Infrastruktur zu benutzen ist, um mit anderen Komponenten zu kommunizieren und sich daher an vorgegebene Konventionen halten. Dabei kann es sich etwa um einen Namensstandard für Operationen handeln. Eine andere Möglichkeit ist die Verwaltung von Metainformationen über die Komponenten in einem sogenannten Repository. Hier finden sich alle Informationen über die Schnittstellen und wo die entsprechend konforme Komponenten zu finden sind. Der Benutzer einer Komponente braucht nur die gewünschte Schnittstelle anzugeben und erhält eine Referenz auf eine passende Komponente. Obwohl das Konzept der Komponentenorientierung auf den ersten Blick dem der Objektorientierung ähnelt (Kapselung von Informationen, Wiederverwendung von Programmcode), ist "Objekttechnologie [...] weder nötig noch ausreichend für [die komponentenbasierte Softwareentwicklung]" [BrWa98]. Einerseits lassen sich komponentenorientierte Systeme durchaus auch ohne Objektorientierung verwirklichen. Andererseits bedeutet die Anwendung von strikter objektorientierter Programmierung noch lange nicht, daß der nötige Abstraktionsgrad erreicht wird [Lee00]. Das soll heißen, während sich der Systementwickler bei der Benutzung von CBSE allein auf die Verwendung der Schnittstellen konzentriert, kann es bei objektorientierter Entwicklung nötig sein, auch die innere Arbeitsweise der Objekte zu kennen. Ein weiteres Beispiel ist das Konzept der Vererbung (oft sogar Mehrfachvererbung), das häufig in der objektorientierten Entwicklung angewandt wird. Eine Änderung, die an einer Klasse vorgenommen wird, wirkt sich auf sämtliche Unterklassen aus. Bei komplexen Systemen kann dies unter Umständen problematisch werden, um so mehr in Hinblick auf austauschbare Komponenten. Deshalb wird für Komponenten auch meistens statt Mehrfachvererbung das Konzept der mehrfachen Schnittstellen angewandt [Lee00]. Trotzdem kann die Objektorientierung durchaus als Grundlage für die komponentenbasierte Softwareentwicklung genutzt werden, solange man sich der genannten Probleme bewußt ist. So gibt es derzeit drei Technologien für Komponenteninfrastrukturen, die als Quasistandard angesehen werden können: CORBA, JavaBeans und COM/DCOM. Alle diese Technologien sind objektorientiert.

2.1.1.1 CORBA Mit CORBA (Common Object Request Broker Architecture) bietet die Object Management Group (OMG) [Omg00] eine Architektur zur Integration von Softwarekomponenten. Die sogenannte Middleware, welche die Interaktion zwischen Objekten erlaubt, ist der ORB (Object Request Broker) [Corb99]. Er erlaubt es einer Applikation, einen Dienst einer anderen Komponente aufzurufen: der ORB findet ein Objekt, das die gewünschte Methode implementiert, übermittelt die Parameter und liefert das Ergebnis zurück (siehe Bild 2.1).


18

Bild 2.1: Eine Anfrage wird über den ORB gesendet [Corb00] Dabei bleibt es für die Applikation völlig transparent, wo sich das Objekt im Netzwerk befindet, wie es implementiert wurde und welche Programmiersprache benutzt wurde. Für die Definition der Schnittstellen zu den Objekten gibt es zwei Möglichkeiten [Corb00]. Mithilfe der OMG Interface Definition Language (OMG IDL) lassen sich statische Schnittstellen beschreiben. Diese enthalten die Art der möglichen Operationen und die benötigten Parameter. Der Zugriff erfolgt über sogenannte IDL Stubs, die der ORB für jede Schnittstelle bereitstellt. Alternativ kann eine Schnittstelle in einem Repository registriert werden, das diese als Objekt verwaltet. Für den Zugriff werden die Objekte dynamisch zur Laufzeit erzeugt und die gewünschte Operation ausgeführt. Welche Zugriffsmethode verwendet wurde, bleibt für den Client wiederum transparent.

Bild 2.2: Schnittstellen- und Implementierungs-Repositories [Corb00] Wurde von einem Client eine Anfrage an den ORB gesendet, werden die Parameter an die Implementierungen übermittelt. Dies geschieht je nach Schnittstellentyp über ein IDL- oder ein aus einem Repository dynamisch erzeugtes "Skelett", eine

Client Objekt -Implementierung

Anfrage ORB

IDL

Definitionen

Schnittstellen-Repository Stubs Skelette

Implementierungs- Repository

Implementierungs- installation

Client Objektimplementierung


19

Schnittstelle, über die der ORB mit der Implementierung interagieren kann (siehe auch Bild 2.2). Über einen oder mehrere Objektadapter kann die Implementierung wiederum auf vom ORB bereitgestellte Dienste zugreifen.

2.1.1.2 COM / DCOM COM (Component Object Model) von Microsoft stellt ebenfalls einen Rahmen für die Integration von Komponenten zur Verfügung [MoLi00]. Die Erweiterung DCOM (Distrubuted COM) erlaubt zusätzlich die Verwendung von über ein Netzwerk verteilten Komponenten. DCOM und COM stellen eine Reihe von Diensten für die Interaktion von Komponenten zur Verfügung. Damit diese miteinander kommunizieren können, ist von COM eine binäre Struktur für die Schnittstelle zwischen einem Client und einem Objekt vorgegeben. Solange diese eingehalten wird, kann die zur Implementierung der Komponente gewählte Programmiersprache beliebig gewählt sein. Die von COM definierte binäre Repräsentation stellt einen Kontaktpunkt dar, über den eine Komponente ihre Dienste anbietet. Die Interaktion von Komponenten findet ausschließlich über diese Schnittstellen statt (siehe Bild 2.3). Dabei kann eine Komponente beliebig viele Schnittstellen implementieren.

Bild 2.3: Aufruf eines COM Objektes über einen Schnittstellenzeiger [MoLi00] Für die Kommunikation vom Objekt zur Applikation, kann das Objekt ebenfalls eine Schnittstelle definieren, welche dann von der Applikation implementiert werden muß. COM Objekte und Schnittstellen werden über MS IDL (Microsoft Interface Definition Language) definiert. Jedes Objekt und jede Schnittstelle muß dabei einen eindeutigen Namen erhalten. Sämtliche COM Objekte sind in einer Komponentendatenbank erfaßt. Möchte eine Applikation ein neues COM Objekt erzeugen, ruft es die COM API (Application programming interface) auf, um es zu instanziieren. COM findet die entsprechende Implementierung in der Datenbank und erzeugt für das Objekt einen Prozeß. Dieser wiederum erzeugt das Objekt und liefert einen Zeiger auf die Schnittstelle, über den die Applikation auf das Objekt zugreifen kann. Greift eine Applikation auf ein Objekt zu, das sich innerhalb eines anderen Prozesses, oder gar auf einem anderen Rechner befindet, generiert COM im Prozeß der Applikation einen Zwischenspeicher für Funktionsaufrufe (einen sogenannten Proxy)

Applikation

Objekt Zeiger auf die Schnittstelle


20

und im Prozeß des Objektes einen Stub1. Der Stub erhält den Zeiger auf die Schnittstelle des Objekts, der Proxy stellt einen Schnittstellenzeiger für die Applikation bereit. Der Proxy übermittelt alle Anfragen der Applikation via RPC (remote procedure call) an den Stub, der wiederum das Objekt aufruft. Aufbauend auf COM und DCOM existieren noch die Technologien OLE und ActiveX [Com00]. OLE (Object linking and embedding) ermöglicht die Erstellung von zusammengesetzten Dokumenten, die Komponenten verschiedener Anwen-dungen enthalten. ActiveX schließlich erlaubt die Einbettung von Komponenten in Internetseiten.

2.1.1.3 JavaBeans Das Komponentenmodell JavaBeans von Sun wurde für die Programmiersprache Java entwickelt [Java00], [Hami00], [Chov98]. Ebenso wie normale Java-Klassen, sind auch diese Komponenten, im folgenden Beans genannt, plattformunabhängig. Diese Architektur soll für die hier vorgestellte Arbeit verwendet werden. Deshalb sollen in diesem Kapitel auch die Aspekte der Entwicklung von JavaBeans betrachtet werden. Das Modell wurde im Hinblick auf die visuelle Komposition von Komponenten entwickelt. In der JavaBeans API Spezifikation [Hami00] wird ein Bean deshalb auch als "wiederverwendbare Software-Komponente, die visuell in einer Entwicklungsum-gebung manipuliert werden kann" definiert. Beispiele für solche Entwicklungsumge-bungen sind etwa die Beanbox, die von Sun zusammen mit dem BDK (Beans Development Kit) ausgeliefert wird, oder der JBuilder von Borland [Jbui00], der auch für den Programmierteil dieser Arbeit verwendet wurde. Ein typisches Bean kann durch fünf Punkte charakterisiert werden:

• Anders als bei COM oder CORBA, werden die Schnittstellen der Beans nicht separat verwaltet. Für die Analyse der Arbeitsweise eines Beans, bietet JavaBeans die Funktion der Introspection, mit der die zur Verfügung stehenden Methoden und Eigenschaften herausgefunden werden können.

• Für das visuelle Bearbeiten ist auch der Aspekt der Customization von

Bedeutung, also die Möglichkeit, Eigenschaften und Verhalten der Beans anpassen zu können. Da es sich bei JavaBeans um "Black-Box" Komponenten handelt, muß das Bean dem Anwender diese Funktion zur Verfügung stellen.

• Zu diesen Zweck besitzt ein Bean unter anderem eine Reihe von Properties,

das heißt Eigenschaften, die ausgelesen beziehungsweise geändert werden können.

• Für die Kommunikation, über die Beans miteinander verbunden werden

können, wird das in Java 1.1 eingeführte Event-Modell benutzt.

1 Dies ist der Programmteil eines Objektes, der für die Kommunikation mit anderen Objekten zuständig ist. Vergleiche auch mit Kapitel 2.1.1.1.


21

• Schließlich ist es möglich, die Persistenz eines Beans zu erhalten, das heißt ein angepaßtes Bean kann gespeichert und später in demselben Zustand wieder hergestellt werden.

Struktur eines Beans In der aktuellen Version des Modells der JavaBeans, ist ein Bean eine Java-Klasse1. Diese muß weder ein bestimmtes Interface implementieren, noch ist es nötig, eine bestimmte Klasse zu erweitern (obwohl visuelle Beans meistens von der Klasse java.awt.Container erben). Eine Klasse, die als JavaBean verwendet werden soll, muß sich vielmehr an bestimmte Namenskonventionen halten (von Sun auch als Design Patterns bezeichnet). Diese betreffen die Eigenschaften (Properties), Methoden und Ereignisse (Events), die das Bean definieren. Properties Eigenschaften sind äußerlich identisch mit einem Feld einer Klasse, das heißt sie werden durch einen Namen und einen Klassentyp identifiziert (intern muß die Eigenschaft aber keineswegs als Feld realisiert sein). Der Zugriff auf eine Eigenschaft xxx erfolgt jedoch nicht direkt, sondern über entsprechende getXxx() und setXxx() Methoden. Beispiel: in dem Bean existiert die Eigenschaft status vom Typ String. Die Schnittstelle der entsprechenden Methoden sieht dann wie folgt aus: public String getStatus();

public void setStatus(String s);

Es ist auch möglich, entweder nur die get- oder die set-Methode zu implementieren, zum Beispiel für Eigenschaften, die zwar ausgelesen, aber nicht verändert werden können sollen. Für eine boolesche Eigenschaft kann des weiteren statt getXxx() auch isXxx() verwendet werden. Neben den einfachen Eigenschaften gibt es noch die Indexed Properties: diese besitzen als Datentyp ein Array. Außer den bekannten getXxx() und setXxx() Methoden, die das gesamte Array auslesen, gibt es auch welche, die auf ein einzelnes Element des Arrays zugreifen. Diese haben als zusätzlichen Parameter den Index des entsprechenden Elements. Beispiel: unsere Eigenschaft history ist diesmal ein String-Array, also vom Typ String[]. Die Methoden für den Zugriff sehen dann so aus: public String[] getHistory();

public String getHistory(int index);

public void setHistory(String[] histoy);public void setHistory(int index, String value);

1 Für kommende Versionen ist es geplant, ein Bean auch als Kollektion von Klassen implementieren zu können [Hami97].


22

Es gibt weiterhin die Möglichkeit, anderen Beans mitzuteilen, daß eine Eigenschaft verändert wurde. Eine solche Bound Property, wird dadurch realisiert, daß in der setXxx() Methode an alle registrierten Beans ein PropertyChangeEvent geschickt wird. Dieses Objekt enthält den Namen der geänderten Eigenschaft, den ursprünglichen und den neuen Wert. Damit sich andere Beans als interessierte Empfänger an- und abmelden können, muß das Bean, das die Eigenschaft enthält, entsprechende Methoden zur Verfügung stellen: addPropertyChangeListener(PropertyChangeListner l);

removePropertyChangeListener(PropertyChangeListener l); Ein Bean wiederum, welches die Nachricht empfangen möchte, muß das Interface PropertyChangeListener implementieren. Ähnlich kann eine Eigenschaft auch als eine Constrained Property realisiert sein. Hier sendet die setXxx() Methode erst an alle registrierten Beans die Absicht, den Wert zu ändern. Ein Bean, das mit der Änderung nicht einverstanden ist, kann dies mit einem Veto kundtun. Dies ist über den Exception-Mechanismus von Java möglich: die setXxx() Methode ruft bei allen registrierten Beans die Methode vetoableChange() auf, die durch das Interface VetoableChangeListener spezifiziert ist. Ist ein Bean mit der Änderung nicht einverstanden, löst es in dieser Methode eine PropertyVetoException aus, die von der set-Methode abgefangen werden kann. Analog gibt es auch wieder die entsprechenden Methoden, um Beans als Empfänger an- und abzumelden:

addVetoableChangeListener(VetoableChangeListener l);

removeVetoableChangeListener(VetoableChangeListener l);

Methoden Außer setXxx() und getXxx() kann ein Bean der Außenwelt auch beliebige andere Methoden zur Verfügung stellen. Dafür müssen diese nur als public deklariert werden. Events Zur Kommunikation von Beans wird das Java Ereignismodell verwendet [Ecke98], [Flan99]. Für die Versendung von Ereignissen (Events) gibt es eine ähnliche Namenskonvention. Versendet das Bean ein Event, muß es Methoden geben, mit denen andere Beans sich als Empfänger an- oder abmelden können. Empfänger kann jedes Bean sein, welches das entsprechende Listener-Interface implementiert. Beispiel: ein Bean kann Events verschicken, die vom Interface ReadyListener bearbeitet werden können. Andere Beans, die dieses Interface implementieren, können sich über folgende Methoden als Empfänger registrieren lassen, oder wieder abmelden:


23

public void addReadyListener(ReadyListener l);

public void removeReadyListener(ReadyListener l); Normalerweise handelt es sich bei den Ereignissen um Multicast Events, das heißt es können sich beliebig viele Beans als Empfänger eintragen. Es ist aber auch möglich, ein Unicast Event zu definieren, für das es höchstens einen Empfänger gibt. In diesem Fall muß die Methode add<ListenerName>() eine TooManyListenersException auslösen, sobald sich mehr als ein Bean registrieren lassen will. Introspection Mithilfe des obigen Namenschemas ist es möglich, die Methoden, Eigenschaften und Ereignisse eines JavaBeans zur Laufzeit in Erfahrung zu bringen. Dieser Prozeß nennt sich Introspection. Dabei wird der Reflection Mechanismus von Java benutzt, der unter anderem die Namen der Methoden einer Klasse zurückliefert. Ein Bean kann zusätzlich noch selbst explizit beschreiben, welche Methoden, Eigenschaften und Ereignisse es unterstützt. Dafür muß es eine weitere Klasse zur Verfügung stellen, die das Interface BeanInfo implementiert. Für ein Bean <BeanName> muß diese Klasse <BeanName>BeanInfo benannt werden. BeanInfo definiert Methoden zur Beschreibung der Ereignisse, Eigenschaften und Methoden durch sogenannte Deskriptorklassen. Für das Bean oder eine einzelne Eigenschaft kann hier auch eine Klasse angegeben werden, die zur Anpassung (Customization) benutzt werden kann. Schließlich lassen sich noch globale Informationen festlegen (zum Beispiel ein Icon, das in einer visuellen Entwicklungsumgebung angezeigt wird). Eine BeanInfo Klasse muß dabei nicht das gesamte Verhalten eines Beans beschreiben, die fehlenden Informationen werden durch die Introspection erlangt. Customization Eine graphische Entwicklungsumgebung, die JavaBeans unterstützt, stellt für die Bearbeitung von Eigenschaften eines Beans Editoren (Customizers) zur Verfügung. Es ist aber auch möglich, daß ein Bean seine eigenen Editoren bereit stellt. Eine solche Klasse muß das Customizer Interface implementieren und erweitert in den meisten Fällen die Klasse Component. Um den Editor einer Eigenschaft oder einem Bean zuzuordnen, gibt es mehrere Möglichkeiten. Zuerst besteht die Möglichkeit, den Editor in einer BeanInfo Klasse (siehe oben) festzulegen. Ein Editor kann so dem gesamten Bean oder einer bestimmten Eigenschaft zugeordnet werden. Soll der Editor nicht für eine bestimmte Eigenschaft, sondern für alle Eigenschaften eines bestimmten Typs <TypeName> benutzt werden, reicht es aus, wenn er als


24

Klasse <TypeName>Editor im selben Package1 oder im Package java.beans.editors zu finden ist.

Persistenz Um ein Bean für die Verwendung in einem Softwaresystem anzupassen, werden, wie oben gesehen, die Eigenschaften des Beans verändert. Dieser veränderte Zustand muß nun zur Laufzeit des Programms wieder rekonstruiert werden. Hierfür gibt es zwei mögliche Vorgehensweisen. Die benutzte visuelle Entwicklungsumgebung kann zum einen Code erzeugen, der das Bean über die entsprechenden set-Methoden mit den neuen Werten initialisiert. Alternativ kann der Serialization Mechanismus von Java benutzt werden. Dieser ermöglicht es, den internen Zustand von Java Objekten zu speichern (serialisieren) und zu einem späteren Zeitpunkt wieder herzustellen (deserialisieren). Aus diesem Grund sollte jedes Bean die Objektserialisierung unterstützen, also das Interface Serialization2 implementieren. Archivierung von Beans Damit ein fertig erstelltes Bean später in einer visuellen Entwicklungsumgebung verwendet werden kann, muß es in einem geeigneten Format abgespeichert werden. Dafür werden alle benötigten Klassen (in Form von Klassendateien oder auch in serialisierter Form) in einem JAR-Archiv3 zusammengefaßt. Zusätzlich enthält das Archiv eine sogenannte Manifestdatei, in der angegeben wird welche Klasse ein Bean darstellt. Erweiterungen Enterprise Java Beans (EJB) ist ein Multiplattform-Komponentenmodell, das Java Beans um die Unterstützung von Serverkomponenten erweitert [Thom98]. InfoBus ist eine Erweiterung, die einen dynamischen, asynchronen Datenaustausch zwischen Beans erlaubt [Cola00]. Zur Kommunikation wird hierzu ein Informationsbus benutzt, an den sich jedes Bean ankoppeln kann, welches die entsprechenden Schnittstellen implementiert. Statt über Namen oder Parametern von Ereignissen findet der Datenfluß über Datenobjekte statt, die über diese Schnittstellen auf den Bus gelangen beziehungsweise von dort ausgelesen werden können.

1 Ein Package ist eine logische Gruppierung von Java Klassen. Packages sind hierarchisch aufgebaut und als Verzeichnisbaum organisiert; als Separator dient der Punkt. Der vollständige Name einer Java Klasse setzt sich daher aus Package- und Klassenname zusammen, zum Beispiel java.awt.Color. 2 Diese Interface definiert keine Methoden, es dient nur als Markierung, daß diese Klasse serialisiert werden kann. 3 Java ARchive ist ein auf ZIP basierendes Komprimierungs- und Archivierungsformat zum Verwalten von Java Klassen [Flan99].


25

2.2 Benutzungsfreundlichkeit und visuelles Programmieren

Ein großer Vorteil, den das Komponentenkonzept im allgemeinen und JavaBeans im speziellen zur Verfügung stellen, ist die Möglichkeit die Eigenschaften der Komponenten in einer graphischen Umgebung anpassen zu können. Diese soll in der vorliegenden Arbeit vor allem dazu dienen, den Prozeß des Erstellens eines neuen Trainingsszenarios benutzungsfreundlicher zu machen. Aus diesem Grund soll im folgenden Kapitel auf die wichtigsten Aspekte der visuellen Programmierung eingegangen werden. Es werden beispielhaft die verschiedenen Arten von visuellen Programmiersprachen und Programmsystemen vorgestellt, außerdem wird auf Kriterien zur Bewertung eines graphischen Systems eingegangen. Aber auch die Benutzungsfreundlichkeit des VR-Systems selbst, beziehungsweise seiner Interaktionsschnittstellen, ist für die Arbeit mit dem Trainingssystem wichtig. Darum sollen im zweiten Abschnitt Ansätze beschrieben werden, diesen Gesichtspunkt in die Konzeption mit aufzunehmen.

2.2.1 Visuelles Programmieren Ein Anwender eines Computersystems ist heutzutage meist kein professioneller Programmierer, der Computer hat vielmehr die Rolle eines Assistenten. Im Idealfall möchte sich der Benutzer auf die Lösung eines Problems konzentrieren und die technischen Details dem System überlassen [Posw96]. Das Denken der meisten Menschen spielt sich in Form von Bildern ab, die Benutzung von graphischen Metaphern bei der Beschreibung eines Problems ist daher auch sehr viel intuitiver als die Verwendung von Text [BoDo97]. Die visuelle Programmierung versucht nun, die Notwendigkeit, visuelle Ideen in textuelle Repräsentationen umzuwandeln, zu reduzieren oder ganz zu eliminieren. Die Erwartungshaltung eines Endanwenders ist gegenüber einem graphischen System besonders hoch: die Energie soll ganz auf die Lösung eines Problems gerichtet werden, wobei das System dafür sorgt, daß man sich nicht mit lästigen technischen Details befassen muß. In der Praxis ist dies jedoch nicht immer in diesem Maße realisierbar, weshalb es nötig ist, einen geeigneten Kompromiß zwischen dem technisch Machbaren und der Akzeptanz des Benutzers zu finden.

2.2.1.1 Visuelle Programmiersprachen Im Laufe der Zeit wurden einige Systeme entwickelt, die den Anwender bei der Lösung komplexer Programmieraufgaben durch die Anwendung einfach zu verstehender graphischer Eingabemetaphern unterstützen sollten. Die heute existierenden visuellen Programmiersprachen und Entwicklungssysteme lassen sich in fünf Kategorien einteilen [BoDo97]:


26

• Ausschließlich visuelle Programmiersprachen.

Diese Sprachen ermöglichen die Erstellung eines Programms allein durch die Verwendung von Ikonen und ähnlichen graphischen Repräsentationen. Der Anwender kann diese Elemente mit der Maus plazieren und miteinander verbinden. Das Programm wird direkt aus dieser Repräsentation kompiliert, ohne vorher noch in eine höhere Programmiersprache übersetzt werden zu müssen. Beispiele von rein visuellen Programmiersprachen sind VIPR, Prograph und PICT. Bild 2.4 zeigt eine Repräsentation eines mit Prograph erstellten Programms. In Bild 2.5 sind die graphischen Repräsentationen einiger Kontrollkonstrukte in VIPR dargestellt.

Bild 2.4: Darstellung von Programm und Klassenabhängigkeiten in Prograph [Prog00]

Bild 2.5: Kontrollkonstrukte in VIPR [BoDo97]

• Textuelle und visuelle Hybridsysteme. Diese Variante der visuellen Programmiersprachen verwendet Text- und graphische Elemente zur Programmentwicklung. Dies sind unter anderem Systeme, die visuell erstellte Programme in eine höhere, textuelle Programmiersprache wie etwa Smalltalk oder C++ übersetzen. Andere Systeme versuchen, bestehende Sprachen um graphische Elemente zu erweitern.

2.2. Benutzungsfreundlichkeit und visuelles Programmieren

27

• Beispielorientierte Systeme.

Hier werden Programme erstellt, indem man versucht, dem System durch die Manipulation graphischer Objekte, eine Aufgabe beizubringen. Der Benutzer führt dabei die Lösung der Aufgabe in einem speziellen Fall vor und das System benutzt dies, um eine allgemeine Lösung zu entwickeln (Programming-by-example).

• Einschränkungsorientierte Systeme. Diese Systeme finden sich besonders im Bereich Simulation und graphische Benutzerschnittstellen. Der Programmierer hat die Möglichkeit, visuelle Objekte zu erstellen, die bestimmten Einschränkungen unterliegen (zum Beispiel physikalische Gesetze).

• Formularbasierte Systeme. Einige Systeme lehnen sich an Spreadsheets an. Der Programmierer verbindet Gruppen von Zellen, die über einen Zeitraum verschiedene Zustände annehmen können.

2.2.1.2 Entwicklungsumgebungen für graphische Schnittstellen

Neben den visuellen Programmiersprachen sind Systeme entstanden, die den Entwickler vor allem bei der Erstellung der graphischen Benutzerschnittstelle (Graphical User Interface, GUI) unterstützen. Die Realisierung des Programms erfolgt dabei in einer gebräuchlichen Programmiersprache, wie zum Beispiel C, C++ oder Java. Das Entwicklungswerkzeug ermöglicht dabei die visuelle Komposition der graphischen Schnittstellenelemente wie Knöpfe oder Textfenster auf einfache Weise mit der Maus. Generell kann man hier zwei Kategorien betrachten [Bray00]. Die einfachen Entwicklungswerkzeuge (Interface Development Tools, IDTs) ermöglichen nur die Erstellung einer Schnittstelle. Ein UIMS (User Interface Management System) erweitert das IDT noch um die automatische Generation von Programmcode. Obwohl diese Systeme sehr graphikorientiert sind, sind sie keine visuellen Programmiersprachen, da die Realisierung in der unterliegenden Programmiersprache für den Benutzter keinesfalls transparent bleibt. Im Gegenteil, die Einbindung der Schnittstellen in das System erfordert meist noch manuelle Anpassungen, und auch die Entwicklung der übrigen Funktionalität geschieht mit konventionellen Methoden. Wie wir in Kapitel 2.1 gesehen haben, kann durch einen komponentenbasierten Ansatz (zum Beispiel mit JavaBeans) der Grad der Visualisierung zwar noch erhöht werden, da auch nicht graphische Programmelemente visuell angepaßt und verknüpft werden können. Doch auch hier kann die zusätzliche textbasierte Programmierung noch möglich beziehungsweise notwendig sein.


28

Bild 2.6 Entwicklungsumgebung von Delphi [Delp00]

Bild 2.7: Designermodus des Jbuilder 3.0 Dennoch bieten diese Werkzeuge große Vorteile, wie etwa eine beschleunigte Programmentwicklung und eine Verminderung des Programmcodes. Gerade die Erstellung der graphischen Benutzerschnittstelle macht nämlich einen Großteil der


29

Programmentwicklung aus: circa 48% des Programmtextes und 50% der Entwick-lungszeit [Bray00]. Beispiele von Entwicklungsumgebungen mit UIMS-Werkzeugen sind Borlands Delphi [Delp00] (siehe Bild 2.6) und Microsofts Visual Basic [Visu00]. Ein auf JavaBeans aufbauendes System ist der JBuilder von Borland [Jbui00] (siehe Bild 2.7)

2.2.1.3 Bewertung eines visuellen Systems Generell läßt sich eine visuelle Programmiersprache charakterisieren durch den Anwendungsbereich, den Formulierungsaufwand und den Grad der Visualisierung [Posw96]. Dabei ist es das Ziel, den Formulierungsaufwand zu reduzieren und den Visualisierungsgrad zu erhöhen. Diese Sichtweise läßt sich auch auf andere graphische Systeme verallgemeinernd ausdehnen. Im Bereich der Benutzerinteraktion läßt sich dies unter anderem durch die Vermeidung von verschiedenen Eingabemodi erreichen. Die Notwendigkeit, erst eine bestimmte Aktion ausführen zu müssen, um eine gewünschte Eingabe zu machen, ist wenig intuitiv. Eine weitere Möglichkeit, den Formulierungsaufwand zu senken, ist die Bereitstellung einer Funktion mit der Eingaben wieder rückgängig gemacht werden. Auf der Darstellungsebene ist die Benutzung von Ikonen hilfreich, um den Grad der Visualisierung zu erhöhen. Dabei muß aber die Anzahl der verwendeten Elemente relativ gering bleiben. Statt dessen sollten Farben und Schattierungen benutzt werden, um Informationen auf intuitive Art zu kodieren. Es ist auch möglich, Meta-Ikonen zu verwenden, also Ikonen, die mit einem Piktogramm überlagert werden (siehe Bild 2.8)

Bild 2.8: Beispiel für Meta-Ikonen Schließlich ermöglicht es eine kontextsensitive Hilfsfunktion, die Benutzbarkeit eines graphischen Systems zu erhöhen.

2.2.2 Benutzungsfreundliche Entwicklung von VR-Systemen

Gerade im Bereich der Virtuellen Realität beziehungsweise Virtuellen Umgebungen (Virtual Environment, VE) wird bei der Entwicklung einer Applikation der

Ikone für ein Objekt

Meta-Ikonen: Objekt ist benannt

Objekt ist mit einem anderen verknüpft


30

Schwerpunkt vor allem auf die graphische Qualität und die Performanz des Systems gelegt. Der Aspekt der Benutzungsfreundlichkeit der Interaktionskomponente hingegen wird noch sehr vernachlässigt. Diese ist meist schlecht entworfen und selten unter Einbeziehung von Anwendern entwickelt. Viele visuell ansprechende System sind daher schlecht benutzbar [Gabb99]. Für die Entwicklung eines bedienfreundlichen interaktiven Systems aber muß die Sicht des Benutzers (das heißt die Benutzerinteraktionen) und die Sicht des Entwicklers (also das System im ganzen) gleichermaßen beachtet werden. Dabei lassen sich die Methoden zur Evaluierung und Entwicklung einer normalen graphischen Benutzerschnittstelle nur bedingt auf VR Systeme anwenden. Hier ist nämlich nicht die Benutzerschnittstelle, sondern die Benutzerinteraktionskompo-nente entscheidend. Diese ist nicht allein von graphischen Bedienelementen abhängig, sondern auch von Faktoren wie Eingabegeräten und -mechanismen, der Art der Manipulation von Daten, Systeminformationen und Feedback. Die in [Gabb99] vorgestellte Methode zum benutzerorientierten Entwurf und Evaluierung von VE Benutzerinteraktionen gliedert sich in vier Schritte (siehe auch Bild 2.9): 1.) Benutzeraufgabenanalyse.

Der erste Schritt besteht in der vollständigen Bestimmung aller Aufgaben, die ein Benutzer des System ausführen muß, sowie der dafür benötigten Ressourcen. Das Ergebnis der Analyse liefert eine Beschreibung aller Aufgaben sowie Informationen über deren Reihenfolge, Beziehungen zu- und Abhängigkeiten voneinander.

2.) Auf vorgegebenen Richtlinien basierende Expertenevaluierung.

Hierbei handelt es sich um eine analytische Evaluierung, bei der ein Experte einen vorliegenden prototypischen Entwurf einer Benutzerinteraktionsschnittstelle (der etwa aus der Aufgabenanalyse hervorgegangen ist) mit bestehenden Designrichtlinien vergleicht. Der Experte stellt fest, welche Richtlinien der Entwurf erfüllt oder verletzt werden und stellt dementsprechend Empfehlungen zur Verbesserung auf. Typischerweise wird diese Analyse von mehreren Experten durchgeführt, die erst unabhängig voneinander arbeiten und dann gemeinsam die Ergebnisse kombinieren. Meistens erfolgt die Analyse auch in zwei Durchgängen, hier wird zuerst das generelle Interaktionsschema betrachtet und danach auf spezielle Komponenten eingegangen.

3.) Formende benutzerorientierte Evaluierung Bei diesem iterativen Verfahren wird versucht, durch die frühzeitige Einbeziehung von Benutzern, die Anwendungsfreundlichkeit der Interaktionsschnittstellen zu verbessern. Dazu werden aus den in den vorhergehenden Schritten gewonnenen Informationen Anwendungsszenarien entwickelt, in denen von den Benutzern mit dem System verschiedene Aufgabenstellungen bearbeitet werden. Die Benutzer werden bei ihrer Tätigkeit von mehreren Experten beobachtet, die qualitative und quantitative Daten sammeln. Qualitative Daten sind dabei


31

"kritische Ereignisse", welche die Leistung oder Zufriedenheit der Benutzer erhöhen beziehungsweise beeinträchtigen. Die quantitativen Daten beinhalten die Zeit, die zur Lösung der Aufgaben benötigt wurde und die Anzahl der gemachten Fehler. Die gesammelten Daten werden ausgewertet und zur Optimierung der Szenarien und der Interaktionsschnittstellen benutzt, die dann wiederum bewertet werden. Auf diese Weise wird der Entwurf schrittweise immer weiter verfeinert und verbessert.

Bild 2.9: Methode zum anwenderorientierten Entwurf von VE-Interaktionen [Gabb99] 4.) Summierte vergleichende Evaluierung

In diesem Schritt wird der entwickelte Entwurf mit anderen bestehenden Interaktionsschnittstellen verglichen, die für gleiche Benutzeraufgaben konzipiert wurden. Auch hier wird der Vergleich von Anwendern vorgenommen. Die in diesem Verfahren gefundenen Unterschiede betreffen jedoch mehr das Design als die Benutzungsfreundlichkeit.

(1) Benutzeraufgaben-

analyse

(2) Richtlinienbasierte

Expertenevaluierung

(3) Formende

benutzerorientierte Evaluierung

(4) Summierte

vergleichende Evaluierung

Anwendbarer und nützlicher Prototyp einer

Benutzerschnittstelle

Aufgaben-beschreibungen,

-abfolgen und -abhängigkeiten

Schnittstellen-entwürfe

Iterativ verfeinerte Schnittstellen-

entwürfe

Richtlinien und Heuristiken

Repräsentative Szenarios von

Benutzeraufgaben


32

Eine Sammlung von Richtlinien, wie sie für den zweiten Schritt verwendet werden findet sich zum Beispiel in [Gabb97]. Hier werden vier Hauptbereiche für die Konzeption einer Interaktionsschnittstelle unterschieden: Benutzer/Benutzeraufgaben, Eingabemechanismen, virtuelle Modelle und Präsentationsmechanismen. In den Bereich Benutzer und Benutzeraufgaben fällt unter anderem die Navigation und Bewegung (Locomotion) durch die virtuelle Umgebung. Da dieser Aspekt in fast allen Systemen implementiert werden muß und alle anderen Bereiche beeinflußt, ist er ein Schwerpunkt des Entwurfs der Schnittstelle. Einige Überlegungen, die [Gabb97] dazu liefert sind:

• Bereitstellung von für die spezifische Aufgabe geeigneten Navigationsmetho-den.

• Beibehaltung eines konsistenten Layouts. • Angemessene Benutzung von Navigationshilfen, wie etwa Raumbezeich-

nungen, einem Horizont und Landmarken. • Der Anwender soll jederzeit wissen, wo er sich befindet, welches seine Höhe

und Blickrichtung ist, wohin er will und wie er dorthin kommen kann. • Vermeidung von modusbasierter Navigation.

2.2.3 Schlußfolgerung Die Evaluierung und Entwicklung einer benutzungsfreundlichen Interaktionsschnitt-stelle unter Einbeziehung von Benutzern mit der eben vorgestellten Methode verläuft in der Regel über einen Zeitraum von mehreren Monaten. Eine vollständige Anwen-dung ist daher im Rahmen dieser Arbeit nicht möglich. Dennoch sollen die in [Gabb97] vorgestellten Richtlinien in die Konzeption des VR-System mit einbezogen werden. Viele der dort angesprochenen Aspekte, gerade bezüglich Navigation und Benutzeraufgaben, werden die Bedienung der Anwendung für den Benutzer erleichtern. Für die Aufgabe der Szenariomodellierung sind diese Richtlinien ebenfalls relevant, hauptsächlich werden hier aber die in 2.2.1.3 beschriebenen Kriterien angewendet werden.

2.3 VR-Systeme Um die Anforderungen an das hier zu entwickelnde System verständlich zu machen, soll in diesem Kapitel das Thema virtuelle Realität (virtual reality, VR) und VR-Systeme behandelt werden. Zunächst wird eine allgemeine Definition gegeben und verschiedene Anwendungsgebiete diskutiert. Danach wird auf die Komponenten eines VR-Systems eingegangen, wobei der Vollständigkeit halber auch kurz die existierenden Technologien betrachtet werden. Für die Arbeit ist aber vor allem der Softwareteil eines VR-Systems interessant. Nachdem die allgemeine Struktur eines Softwaresystems genauer beschrieben wurde, werden noch die beiden Systeme vorgestellt, die für die Arbeit von Bedeutung sind: Java3D soll als Grundlage für diese Arbeit dienen, das ursprüngliche VR-System dagegen baute auf OpenGVS auf.

2.3. VR-Systeme

33

Virtuelle Realität beziehungsweise virtuelle Umgebungen (virtual environments, VE) stellen dreidimensionale Graphiken dar, mit denen ein Benutzer in Echtzeit interagieren kann. Dabei wird dem Anwender das Gefühl vermittelt, sich selbst in dieser computergenerierten Welt zu befinden, das heißt VR bietet einem Benutzer eine "interaktive und immersive (mit dem Gefühl der Präsenz) Erfahrung in einer simulierten (autonomen) Welt" [MaGe96]. Inzwischen existieren für virtuelle Realitäten eine Vielzahl von Anwendungsgebieten. Die Visualisierung architektonischer Daten ermöglicht etwa das Betrachten und Durchwandern virtueller Gebäude, bevor diese erbaut werden. Ebenso kann die Visualisierung von wissenschaftlichen Daten helfen, diese für den Betrachter leichter verständlich zu machen. VR kann aber nicht nur zum Darstellen, sondern auch zum Planen, Modellieren und Entwerfen virtueller Prototypen genutzt werden. Das modellierte Objekt kann dann in einer virtuellen Umgebung getestet werden, ohne das ein reales Modell hergestellt werden muß.

Bild 2.10 Virtuelle Augenoperation [MaGe96] Das Gebiet, das für diese Arbeit die größte Relevanz hat, ist das des Trainings und der Ausbildung. Eine der ersten Anwendungen in diesem Bereich sind Flugsimulationen, die in der Luftfahrt zum Training von Piloten genutzt werden. In der Medizin können Operationen an virtuellen Patienten geübt und so Risiken vermieden werden (siehe Bild 2.10).


34

Verteilte Systeme erlauben zudem das gleichzeitige Training mehrerer Teilnehmer, die über ein Netzwerk miteinander verbunden sind. In jedem lokalen System wird dem Betrachter eine Kopie der virtuellen Welt gezeigt, in der die übrigen Teilnehmer durch dreidimensionale Modelle (sogenannte Avatare) dargestellt werden.

2.3.1 VR-Technologien Ein immersives VR System wird in [Beie00] durch folgende Merkmale charakterisiert:

• Die virtuelle Kamera wird durch die Kopfposition des Benutzers gesteuert. • Es werden stereoskopischer Bilder erzeugt. • Die Welt wird in korrekten Relationen zum Benutzer dargestellt. • Es sind realistische Interaktionen mit der virtuellen Welt möglich (zum

Beispiel greifen von Objekten). • Das Gefühl der Präsenz in der Szene kann durch zusätzliche Ausgabegeräte

für auditives oder taktiles Feedback noch erhöht werden. • Verteilte VR Systeme erlauben gleichzeitiges Arbeiten innerhalb einer Welt

von mehreren Benutzern über ein Netzwerk. Abhängig von der verwendeten Technologie gibt es daher verschiedene Stufen der Immersion. Das einfachste System besteht aus einem Desktop-Computer mit einem normalen Bildschirm, als Eingabegeräte dienen Maus und Tastatur. Hier ist die Illusion, sich wirklich in der dargestellten Szene zu befinden, kaum vorhanden. Der Immersionsgrad kann nun durch Hinzufügen von spezieller Hardware erhöht werden, man unterscheidet hier zwischen Ein- und Ausgabegeräten. Eingabegeräte sind für die Interaktionen des Benutzers mit dem System verantwortlich. Eine Aufgabe dieser Komponenten besteht darin, die Bewegungen des Benutzers innerhalb der virtuellen Welt zu ermitteln. Dies wird unter anderem durch sogenannte Trackingsysteme erreicht, die mittels Sensoren in Echtzeit die Position und Orientierung von Kopf und Hand bestimmen [Vinc98]. Mittlerweile existieren hierfür unter anderem mechanische, optische, akustische und elektromagnetische Tracker. Eine andere Klasse von Eingabegeräten dient vor allem der Manipulation von virtuellen Objekten, kann aber auch für die Navigation durch die Szene benutzt werden. Beispiele hierfür sind 3D Mäuse, die sechs Freiheitsgrade bieten (Degree of Freedom, DOF) oder Datenhandschuhe, welche die Krümmungen der Finger registrieren und so sehr gut zum virtuellen Greifen von Objekten geeignet sind. Die Immersion des Benutzers in die virtuelle Welt hängt sehr stark von den verwendeten Ausgabegeräten ab. Da das Auge 70% der Sinneseindrücke des Menschen liefert, zielt ein Großteil der Forschung in dem Bereich der VR-Technologie auf die visuelle Simulation der künstlichen Welten [MaGe96].

2.3. VR-Systeme

35

Eine Möglichkeit, die Immersion des oben erwähnten Basissystems zu erhöhen, ist die Unterstützung von stereoskopischem Sehen, zum Beispiel über spezielle 3D-Brillen oder einem Head Mounted Display (HMD). Ein starkes Gefühl der Immersion kann ebenfalls durch eine CAVE (Cave Automatic Virtual Environment) erreicht werden. Hierbei befindet sich der Betrachter in einem Raum, auf dessen Seitenwände (manchmal auch auf Decke und Boden) die Szene von Außen projiziert wird. Zusätzlich wird durch 3D-Brillen Stereovision ermöglicht, und die Position der Benutzers über ein Trackingsystem ermittelt [Vinc98]. Neben den visuellen Ausgabegeräten kann die Immersion des Betrachters auch noch durch die Stimulierung weiterer Sinne erhöht werden. Audiosysteme können durch räumliche Geräuschquellen die (virtuelle) räumliche Wahrnehmung unterstützen. Aber auch als Feedback für Interaktionen mit der virtuellen Welt können Klänge eingesetzt werden (wie zum Beispiel ein Signalton, wenn ein Objekt selektiert wurde). Haptische Systeme schließlich simulieren zum Beispiel Gegenkräfte (Forcefeedback) oder taktile Sinneseindrücke beim Interagieren mit virtuellen Objekten.

2.3.2 Softwaresysteme Neben der Hardware zur Ein- und Ausgabe spielt die verwendete Software eine wichtige Rolle bei der Simulation virtueller Welten. Sie ist unter anderem dafür verantwortlich, die angeschlossenen Geräte zu verwalten, Eingabedaten zu analysieren und entsprechende Ausgaben zu generieren. Bestehende VR Systeme lassen sich in zwei Hauptkategorien unterteilen: Toolkits und Autorensysteme [Isda00] [Youn00]. Ein Toolkit beziehungsweise API (Application Programmer Interface) besteht aus einer Reihe von Programmbibliothe-ken zur Erstellung einer VR-Applikation. Diese Bibliotheken sind in den meisten Fällen für die Programmiersprachen C oder C++ entwickelt. Ein Autorensystem hingegen besteht aus einem kompletten Programmpaket mit gra-phischer Benutzungsoberfläche zur Erstellung von dreidimensionalen Welten und oft auch einer integrierten Skriptsprache zur Beschreibung von Ereignissen. Diese Systeme sind meistens benutzungsfreundlicher als ein Toolkit, dafür aber nicht so flexibel und eventuell etwas langsamer.

2.3.2.1 Komponenten eines Softwaresystems Ein VR-Softwaresystem kann in vier Untersysteme gliedert werden [Isda00] (siehe auch Bild 2.11): Eingabeverarbeitung, Simulation, Datenbank und Darstellung. Eingabeverarbeitung Hier werden die angeschlossenen Eingabegeräte gesteuert und die empfangenen Posi-tionsdaten verarbeitet. Bei einem verteiltem System kommen noch Synchronisations-daten hinzu, die über das Netzwerk empfangen werden und die Positionen der anderen Teilnehmer angeben. Diese können damit dann als Avatare dargestellt werden.


36

Bild 2.11: Untersysteme eines VR-Softwaresystems. Simulation Der Simulationsprozeß ist das Kernstück des Programms, er verwaltet die Objekte der Szene und die Daten der Eingabeverwaltung. Hier findet die Behandlung aller Interaktionen zwischen der Welt und dem Benutzer statt. Abhängig von der Art des Eingabegerätes und der zu bewältigenden Aufgabe, gibt es verschiedene Interaktionsparadigmen. Dies verwenden Metaphern, um den Dialog zwischen Computer und Mensch zu beschreiben [MaGe96]. Für die Kamerakontrolle unterscheidet man hier zwischen Eyball-in-Hand und Scene-in-Hand. Bei der ersten Metapher steuert der Benutzer ein virtuelles Auge, mit dem er sich in der Szene umsehen kann, indem er dessen Blickrichtung verändert. Im zweiten Fall hat der Betrachter die Szene in der (virtuellen) Hand und kann sie beliebig drehen und verschieben. Diese Metapher eignet sich besonders für die Manipulation von Objekten. Für die Fortbewegung durch die virtuelle Welt gibt es ebenfalls verschiedene Metaphern. Bei der handgeführten Navigation wird die Richtung der Bewegung durch Position und Orientierung der Hand festgelegt, während bei blickgeführter Navigation die Blickrichtung des Benutzers verwendet wird. Eine weitere Möglichkeit ist die Verwendung von physikalischen Kontrollen, wie Joysticks oder 3D-Mäusen. Analog dazu ist auch die Verwendung virtueller Kontrollen möglich die mit den gleichen Methoden manipuliert werden können wie andere virtuelle Objekte. Schließlich gibt es noch unterstützende Fortbewegungsmethoden, wie Teleportation und Skalierung der Welt; bei letzterem können die Distanzen in der virtuellen Welt nach Bedarf verändert werden.

Eingabegeräte

Eingabe-verarbeitung

Simulation

Datenbank

Darstellung

Ausgabegeräte

2.3. VR-Systeme

37

Um ein Objekt zu selektieren, gibt es die Möglichkeit dies lokal oder aus der Distanz zu tun. Bei der lokalen Selektion wird das Objekt durch die Kollision mit einer virtuellen Hand oder eines 3D Cursors ausgewählt. Für die Auswahl aus der Distanz wird ein Strahl in die Szene geschickt und auf Schnittpunkte mit Objekten geprüft, die Richtung kann durch die Orientierung von Hand oder Kopf des Benutzers festgelegt werden. Um ein selektiertes Objekt auch manipulieren zu können, muß das System dem Anwender einen entsprechenden Modus anbieten, in dem das Objekt verändert werden kann. Dieser Modus kann zum Beispiel über spezielle Knöpfe, Handgesten oder Menüeintrage aufgerufen werden. Im Simulationsprozeß werden auch alle Skripte abgearbeitet, die das Verhalten von Objekten beschreiben und damit Interaktionen zwischen dem Anwender und der virtuellen Welt erst ermöglichen. Dieses Objektverhalten kann autonom sein oder durch ein anderes Ereignis ausgelöst werden. Dies kann ein bestimmter Zeitpunkt, eine Kollision, das Betreten einer bestimmten Region oder auch die Selektion durch einen Benutzer sein. Ein Skript kann je nach System aus einer einfachen Textdatei bestehen oder auch im Programmcode enthalten sein. Das Verhalten der Objekte kann aber nicht nur durch Skripte, sondern zusätzlich auch durch die Simulation physikalischer Gesetze beeinflußt werden. Aus Performanzgründen wird hier nur eine vereinfachte Untermenge benutzt, meistens beschränkt man sich auf die Newtonschen Gesetze. Die physikalische Simulation wird in der Regel in einem eigenen Subprozeß ausgeführt und ist somit von der Bearbeitung der Benutzerinteraktionen entkoppelt [MaGe96]. Weitere Informationen zu diesem Aspekt der Simulation findet sich zum Beispiel in [Dai97]. Bei einer verteilten Simulation muß weiterhin die Synchronisation der verteilten virtuellen Umgebungen gesteuert werden. Hier hat jeder Teilnehmer zum Beispiel eine lokale Kopie der Weltdatenbank, die bei ihm dann auch lokal visualisiert wird Um den Eindruck zu vermitteln, sich gemeinsam mit anderen Benutzern in einer Welt zu befinden, müssen diese Kopien alle konsistent gehalten werden. Eine Veränderung innerhalb eines lokalen Systems muß daher allen anderen Systemen bekannt gemacht werden. Hier ist die Geschwindigkeit, mit der diese Synchronisationsnachrichten weitergeleitet werden, der kritische Punkt, da sich die durch eine Benutzerinteraktion hervorgerufene Veränderung möglichst in Echtzeit auf das System auswirken soll. Daher ist es nötig, den Umfang und die Häufigkeit dieser Nachrichten soweit wie möglich zu reduzieren [Brol98]. Nachdem nun all diese Informationen berücksichtigt und verarbeitet wurden, bestimmt der Simulationsprozeß den neue Zustand, in dem sich die virtuelle Welt anschließend befindet. Dies ist ein diskreter Prozeß, der für jedes Bild beziehungsweise nach einem festgelegtem Zeitschritt ausgeführt wird [Isda00]. Darstellung Der Darstellungs- beziehungsweise Renderingprozeß erzeugt aus dem in der Simulation berechneten Zustand der Szene die nötigen Daten für die Ausgabegeräte. Für verschiedene Typen von Ausgabegeräten gibt es für gewöhnlich separate Prozesse, zum Beispiel für die visuelle, haptische oder Audioausgabe.


38

Die Erzeugung von Bilddaten ist in den meisten System implementiert. Der visuelle Darstellungprozeß wird oft auch als Rendering Pipeline bezeichnet, da er aus einer Reihe von Unterprozessen besteht, die für die Erzeugung jedes Bildes aufgerufen werden. Für die Erzeugung des Bildes muß der momentan sichtbare Bereich ermittelt werden, abhängig von der verwendeten Hardware, der Kopfposition des Betrachters und dem Zustand der Eingabegeräte. Hierfür sind sowohl die Transformationen der virtuellen Objekte als auch der virtuellen Kamera zu beachten [MaGe96]. Aus den Informationen zu den Lichtquellen, den Farbwerten sowie vorhandener Texturen werden anschließend die Schattierungen der Objekte berechnet. Für eine stereoskopische Darstellung müssen entsprechend zwei Bilder erzeugt werden, abhängig von der Position des linken beziehungsweise rechten Auges. Für die Bilderzeugung ist die Bildrate, also die Anzahl der dargestellten Bilder pro Sekunde, von besonderer Bedeutung. Eine zu niedrige Bildrate führt zu einem flackerndem Bild. Um dies zu vermeiden, sind mindestens 20 fps1 oder besser 60 fps nötig. Eine sich ändernde Bildrate kann bei manchen Betrachtern zu Unwohlsein führen (Simulator sickness), daher muß auch darauf geachtet werden, die Bildrate konstant zu halten [MaGe96]. Eine Möglichkeit zur Beschleunigung der Bilderzeugung ist die Verwendung von Level-of-Detail (LOD): für jedes Objekt existieren mehrere Repräsentationen mit unterschiedlich hohen Detailstufen. Bei einer größeren Distanz zum Betrachter wird ein entsprechend weniger detailliertes (und dadurch schneller darstellbares) Modell verwendet. Bei ausreichender Entfernung reicht meist eine einzige Fläche mit entsprechender Textur aus. Dies kann auch zur Erzeugung konstanter Bildraten benutzt werden, indem für jedes Objekt der optimale Detailgrad ermittelt wird. Bild 2.12 zeigt zwei verschiede Detailstufen eines Avatars.

Bild 2.12: Zwei Detailstufen eines Level-of-Detail-Objektes [Vinc98]

1 Frames per Second (Bilder pro Sekunde)

2.3. VR-Systeme

39

Datenbank Dieser Teil ist für die Verwaltung aller Daten zuständig, welche die virtuelle Welt definieren. Dies umfaßt unter anderem die Objekte, aus denen die Szene besteht, Skripte zur Beschreibung von Aktionen und Objektverhalten, Beleuchtungsinforma-tionen, Kontrollelemente und Informationen zur Hardware. Die Geschwindigkeit der Darstellung ist von großer Wichtigkeit, daher muß bei der Modellierung der Objekte ein Kompromiß zwischen einer detaillierten Geometrie und ausreichender Performanz eingegangen werden. In den meisten Systemen bestehen die Objekte deshalb aus einer Reihe von Polygonen (in der Regel Dreiecke). Diese Objekte wirken dadurch zwar etwas kantiger, beanspruchen aber weniger Speicherplatz und können schneller dargestellt werden. Manchmal werden vom System auch noch Objektprimitive (wie Kugeln oder Würfel) zur Verfügung gestellt. Zusätzlich muß für das Objekt auch noch die Position und Orientierung innerhalb der Welt gespeichert werden. Schließlich kann für das Objekt auch noch ein sogenanntes Bounding Volume definiert sein, also ein einfaches geometrisches Objekt wie etwa ein Quader, welches das komplexere umschließt. Dies kann später für eine schnellere Sichtbarkeitsberechnung oder Kollisionserkennung benutzt werden. Alle diese Daten werden normalerweise bezüglich eines kartesischen Koordinatensystems angegeben.

Bild 2.13 Aufbau eines Szenengraphen.

Objekt

Transformation

T1

T2

T3

O2

O1

T4

O3

Wurzel


40

In vielen Systemen sind die Objekte in einer Hierarchie angeordnet, dem sogenannten Szenengraphen. Dabei handelt es sich um einen einfach gerichteten, azyklischen Graphen mit den Objekten als Blättern. Die Koordinaten eines Objektes werden ermittelt, indem der Graph von der Wurzel aus traversiert und jede Transformation auf diesem Pfad nacheinander angewendet wird, das heißt ein Objekt erbt alle Transformationen der Eltern. Ein Beispiel ist in Bild 2.13 skizziert: Das Objekt O1 wird durch die Transformationen T1 und T2 (in dieser Reihenfolge) transformiert, auf das Objekt O2 werden die Transformationen T1, T2 und T3 angewendet. Da die Transformation T1 sich direkt unter der Wurzel des Szenengraphen befindet, gilt sie für die gesamte Szene, die durch ihn definiert wird. Neben den geometrischen Daten können dem Objekt noch weitere Eigenschaften wie Farbe, Material oder Transparenz zugeordnet sein. Sollte es weiterhin ein Skript geben, das ein gewisses Verhalten für das Objekt definiert, kann das Objekt außerdem noch skriptspezifische Attribute besitzen (zum Beispiel physikalische Eigenschaften wie Masse oder Geschwindigkeit). Die Daten können als Textdateien oder in einem binären Format gespeichert sein. Bei manchen Systemen sind die Informationen auch in die Applikation selbst integriert, wie es zum Beispiel in Java3D der Fall ist (siehe Kapitel 2.3.2.3).

2.3.2.2 OpenGVS OpenGVS von der Firma Quantum3D [Quan00] ist das VR-System, das für die ursprüngliche VR-Umgebung von ETOILE verwendet wurde. Aus diesem Grund soll hier kurz auf die Architektur dieses System eingegangen werden. Weitere Informationen finden sich auf der OpenGVS-Internetseite [Ogvs00]. OpenGVS ist ein Toolkit, das auf einem „lower-level API“ wie OpenGL [Opgl00], Glide [Glid00] oder Direct3D [Dirx00] aufsetzt (siehe auch Bild 2.14). Damit sollte dem Programmierer ein plattformunabhängiges, objektorientiertes, einfach zu benutzendes Programmierwerkzeug zur Verfügung gestellt werden, das auf die Leistungsfähigkeit des unterliegenden System zurückgreifen konnte[Ogvs99]. OpenGVS bietet Funktionsbibliotheken zur Erstellung dreidimensionaler Welten für ANSI C und C++. Für ein Anwendungsprogramm sieht es dabei immer so aus, als ob es sich bei der zugrundeliegenden Hardware um OpenGL handelt. Für Systeme, die keine Hardwareunterstützung bieten, gibt es eine weitere Schicht (Subset OpenGL, SGL), die eine Untermenge von OpenGL implementiert. Die Funktionsbibliotheken sind in eine Reihe objektorientierter Module organisiert, sogenannte Facilities. Bild 2.15 skizziert beispielhaft, wie die wichtigsten Komponenten miteinander in Zusammenhang stehen. Die primäre Ressource ist die Szene, die auch die Datenbank der Objekte verwaltet. Jedes graphische Objekt ist als ein Szenengraph organisiert. Um ein Objekt zu der Szene hinzuzufügen, muß eine Objektdefinition vorhanden sein, von dieser können beliebig viele Objektinstanzen erzeugt und dargestellt werden. OpenGVS erlaubt es, die Objekte im Programm selbst zu definieren, oder aus externen Dateien (die in einem unterstützten Format, wie etwa OpenFlight, vorliegen) zu importieren.

2.3. VR-Systeme

41

Bild 2.14: OpenGVS Softwareschichten [Ogvs99]

Bild 2.15: Konfiguration einer Beispielapplikation unter OpenGVS (aus [Ogvs99]). Weiterhin kann man der Szene Nebeleffekte (fog model) und eine oder mehrere Lichtquellen hinzufügen. Ein Channel definiert die dreidimensionale Geometrie einer

Anwendungsprogramm

OpenGVS

Rendersoftware

Hardware Funktionsaufrufe und Callbacks.

Direkte Aufrufe zur unterliegenden Rendersoftware, falls nötig.


42

Darstellungsoberfläche, und stellt sozusagen ein "3D-Fenster" dar. Die Frame Buffer Facility stellt eine Verbindung her zwischen dem Bildspeicher der Graphikhardware und OpenGVS, auf die der Channel zugreifen kann. Dieser kontrolliert die Ausgabe der Videodaten an das physikalische Ausgabegerät. Jedem Channel ist für gewöhnlich eine Kamera zugeordnet, die dadurch aktiv wird. Die Kamera definiert und kontrolliert den aktuellen Blickpunkt innerhalb der virtuellen Welt. Eine Szene kann beliebig viele Kameras enthalten, es kann aber immer nur eine pro Channel aktiv sein. Einem Channel kann jederzeit eine neue inaktive Kamera zugeordnet werden. Weitere Facilities beinhalten Material und Texturen, sowie mathematische Schnittpunktberechnungen und Informationen über die Zusammensetzung der zugrundeliegenden Geometrie (Geometry Intersections and Feedback). Dies kann eine Anwendung unter anderem zur Implementierung von Kollisionserkennung benutzen.

2.3.2.3 Java3D Java3D ist ein API zur Erstellung dreidimensionaler Szenen unter der Programmiersprache Java. Das Java SDK in der Version 1.2 und höher wird dafür um Klassen erweitert, die Methoden zur Erstellung und Präsentation von virtuellen Welten zur Verfügung stellen. Dieses System wird zur Realisierung der in dieser Arbeit beschriebenen Anwendung eingesetzt werden, aus diesem Grund folgt hier nun ein Überblick der grundlegenden Konzepte. Wie OpenGVS baut Java3D auf eine unterliegende "low-level API" wie Direct3D [Dirx00] und OpenGL [Opgl00] auf [Sowi00]. Und wie auch bei OpenGVS, ist die dargestellte Szene in hierarchische Szenengraphen organisiert (siehe Bild 2.16). Die größte Einheit zur Darstellung einer dreidimensionalen Welt mit Java3D ist das virtuelle Universum (virtual universe), es kann auch als die Objektdatenbank des Systems angesehen werden [Sowi00]. Ein virtuelles Objekt kann zu einem gegebenen Zeitpunkt nicht in mehr als einem Universum existieren, es kann auch nicht in anderen Universen wahrgenommen werden. Im Normalfall wird eine Applikation nur ein virtuelles Universum benötigen. Um auch große Welten zu ermöglichen, enthält das Universum ein oder mehrere sogenannte Locale-Objekte, die einen Koordinatenursprung in hochauflösenden Koordinaten angeben1. Die Koordinaten aller Objekte, die sich unterhalb befinden, sind relativ zu diesem Ursprung (diese benutzen Zahlenformate mit geringerer Präzision). Ein Locale-Objekt kann als Verankerung einer zusammengehörigen Szene in der größeren virtuellen Welt betrachtet werden.

1 Gegeben durch ein Tripel (x, y, z), wobei jeder Wert eine 256-Bit Zahl mit festem Gleitkommapunkt bei Bit 128 darstellt. Der Wert 1.0 bezeichnet einen Meter.

2.3. VR-Systeme

43

Bild 2.16: Java3D Szenengraphen [Sowi00] Branch Graphen Ein Locale-Objekt kann mehrere Szenengraphen enthalten, sogenannte Branch-Graphen [Sowi99]. Hier gibt es zwei mögliche Arten: enthält der Szenengraph Knoten, die den Inhalt der virtuellen Welt bestimmen (wie etwa sichtbare Objekte und Lichtquellen), spricht man von einem Content-Branch. Der linke Teilgraph unterhalb des Locale-Objekts in Bild 2.20 stellt einen solchen Content-Branch dar. Alternativ können in einem Branch-Graphen Informationen zur Position und Orientierung der Benutzers enthalten sein, dieser wird dann View-Branch genannt (der rechte Teilgraph in Bild 2.20 ist ein Beispiel dafür). Der Grund für diese Unterscheidung ist das Modell, welches von Java3D zur Darstellung der Szene verwendet wird (siehe unten). Ein Branch-Graph ist ein gerichteter, azyklischer Graph, in dem jeder Knoten nur einen Vater besitzt. Das heißt der Zustand eines Blattknotens ist definiert durch einen linearen Pfad von der Wurzel bis zum Blatt. Der Vorteil dieser Konvention ist, daß der Graph für die Darstellung in beliebiger Reihenfolge traversiert werden kann, sogar parallel, ohne das sich an der Ausgabe etwas ändert. Ein Subgraph, der an ein Locale-Objekt eingehängt ist, heißt live. Weiterhin kann ein Branch-Graph kompiliert werden, das heißt er wird in eine optimierte Form gebracht (es werden beispielsweise Transformationen zusammengefaßt). In diesen Zuständen

T

S

T

BG BG

VP

B

View

Andere Objekte Appearance Geometry

Behavior-Knoten

Anwendungscode und -daten

Shape3D-Knoten

TransformGroup-Knoten

BranchGroup-Knoten

Locale-Objekt

ViewPlatform-Objekt

VirtualUniverse-Objekt


44

kann die Ausführung einiger Aktionen auf den Knoten des Graphen eingeschränkt sein. Damit der Java3D-Renderer die Szene effizienter darstellen kann, werden zum Beispiel die Werte von Transformationen fixiert, das heißt sie können nicht mehr verändert werden [Rein99]. Soll eine TransformGroup während der Laufzeit manipuliert werden können, muß dieses Recht vorher explizit festgelegt werden. Dazu werden sogenannte Capability-Bits benutzt, welche die Zugriffsrechte für jeden Knoten des Graphen regeln. Ein Knoten innerhalb des Szenengraphen kann entweder ein Blatt- oder ein Gruppenknoten sein. Gruppenknoten werden verwendet, um andere Knoten zu einer Einheit zusammenzufassen. Blattknoten haben keine Kinder, sondern enthalten Informationen, die zur Präsentation der virtuellen Szene benötigt werden. Gruppenknoten Die wichtigsten Klassen sind hier BranchGroup, TransformGroup, Switch, OrderedGroup und SharedGroup [Sowi99]. BranchGroup stellt die Wurzel eines Branch-Graphen dar. Dies ist der einzige Knoten, der während der Laufzeit aus der Szene entfernt werden kann. Der TransformGroup-Knoten enthält eine räumliche Transformation, er dient dazu, die untergeordneten Objekte zu positionieren, orientieren und skalieren. Ein Switch erlaubt es, aus einer Reihe von Subgraphen dynamisch einen oder mehrere zur Darstellung auszuwählen. Der OrderedGroup-Knoten stellt eine Ausnahme von der Regel dar, daß die Pfade eines Szenengraphen beliebig traversiert werden können. Er legt eine genaue Reihenfolge fest, in der die Kindknoten dargestellt werden sollen. Ein SharedGroup-Knoten ist die Wurzel eines speziellen Branch-Graphen. Dieser ist kein direkter Teil des Szenengraphen, kann aber von einem oder mehreren Link-Knoten referenziert werden (hierbei handelt es sich aber nicht um eine Vater-Sohn-Beziehung). Auf diese Weise ist es trotz der Einschränkungen des Szenengraphen möglich, daß ein Subgraph von mehreren Objekten gemeinsam genutzt wird. Blattknoten Blattknoten enthalten Informationen zur virtuellen Szene oder Referenzen auf sogenannte NodeComponent-Objekte. Diese enthalten meist Daten, die von mehreren Knoten gemeinsam genutzt werden können. Der Blattknoten Shape3D zum Beispiel repräsentiert ein visuelles Objekt. Er besitzt Referenzen auf die NodeComponent-Objekte Appearance und Geometry, die Informationen über die Erscheinungsform (wie Material oder Farbe) beziehungsweise die Objektgeometrie enthalten. Sollen mehrere Objekte das gleiche Erscheinungsbild (bei verschiedenen Geometrien) haben, reicht es aus, ein einzelnes Appearance-Objekt zu definieren, das von diesen referenziert wird (siehe auch Bild 2.17). Ein Behavior-Knoten ist ein Blattknoten, mit dem ein bestimmtes Objektverhalten definiert werden kann. Dies kann zur Realisierung von Animationen oder Benutzerinteraktionen eingesetzt werden. Java3D stellt verschiedene Ereignistypen (Events) zur Verfügung, auf die ein Behavior reagieren kann. Dies kann beispielsweise eine Kollision von zwei Objekten sein, das Verstreichen einer bestimmten Zeitspanne oder ein Mausklick in der Szene.

2.3. VR-Systeme

45

Bild 2.17: Zwei Shape3D-Knoten teilen dasselbe Appearance-Objekt Tritt eines oder mehrere der Ereignisse ein, für die sich das Objekt registriert hat, wird von Java3D eine bestimmte Methode in der Klasse aufgerufen, die das Behavior implementiert. Diese kann vom Programmierer zur Ausführung des gewünschten Verhaltens gestaltet werden. Da ein Behavior typischerweise andere Objekte der Szene beeinflußt, enthält der Knoten meistens Referenzen auf weitere Knoten des Szenengraphen. Um die Performanz der Applikation zu erhöhen, ist jedem Behavior ein Aktivierungsbereich (Scheduling Bounds) zugeordnet. Dadurch wird dieses von Java3D nur für das Empfangen von Ereignissen berücksichtigt, wenn sich dieser Bereich mit dem aktuellen Sichtbereich des Betrachters (Activation Volume) überschneidet. Blattknoten, die von der Klasse Light erben, dienen zur Spezifizierung von Lichtquellen in der Szene. Java3D bietet dabei Quellen für ambientes Licht, Punktlichtquellen, gerichtete Lichtquellen und Spotlights. Ähnlich wie bei den Behavior-Knoten wird der Lichtquelle ein Wirkungsbereich zugeordnet (Influencing Bounds), nur die Objekte, die sich in dieser Region befinden, werden von der Lichtquelle beleuchtet. Der ViewPlatform-Knoten befindet sich im View-Branch und gibt die aktuelle Position und Orientierung des Betrachters an. Dieser Knoten kann wie jeder andere Knoten des Szenengraphen manipuliert werden, das heißt der Blickpunkt ist von der Applikation durch eine Transformation beliebig veränderbar.

T

S

Appearance Geometry

S

Geometry


46

Weitere Blattknoten sind der Sound-Knoten, der zum Abspielen von Audiodaten benutzt wird und der oben erwähnte Link-Knoten, der eine Referenz auf einen mehrfach verwendeten Subgraphen enthält. Das View-Modell Das Modell zur Darstellung der virtuellen Welt (view model) beruht auf der Trennung der virtuellen und der physikalischen Welt. Dies ist vorteilhaft, da es möglich ist, Ein- und Ausgabegeräte wie ein HMD, einen Tracker oder ähnliches dem System hinzuzufügen, ohne daß der Szenengraph geändert werden muß [Sowi00]. Das Modell geht davon aus, daß der Betrachter gleichzeitig in der virtuellen und in der physikalischen Welt existiert [Sowi99]. Das ViewPlatform-Objekt repräsentiert den Benutzer in der virtuellen Welt, es enthält Daten über dessen Position, Orientierung und Dimension. Für die Darstellung wird das Koordinatensystem des Locale-Objektes benutzt, das den aktiven View-Branch enthält. Die Physikalische Welt, das heißt die Umgebung zur Darstellung der virtuellen Welt, wird vom View-Objekt und anderen mit ihm verbundenen Objekten beschrieben (siehe Bild 2.18). Das View-Objekt koordiniert alle Aspekte des Darstellungsprozesses und enthält die nötigen Daten, die Bilder zu generieren. Das Canvas3D-Objekt repräsentiert ein Fenster, in dem Java3D seine Bilder darstellt (analog zum Canvas-Objekt des AWT von Java). Es besitzt eine Referenz auf ein Screen3D-Objekt, welches die physikalischen Eigenschaften des Ausgabegerätes enthält. Das Objekt PhysicalBody beschreibt die physikalischen Eigenschaften des Benutzers (wie Augenhöhe, Augenabstand und Abstand zum Monitor). PhysicalEnvironment schließlich beschreibt die physikalische Welt, hauptsächlich enthält es Daten über eventuell vorhandene Tracking-Eingabegeräte. Für den Fall, daß die Parameter der physikalischen Umgebung unbekannt sind, bietet Java3D Hilfsklassen an, welche die Eigenschaften der benutzten Hardware ermitteln und ein Universum mit entsprechendem View-Branch erzeugen. Eingabegeräte und Sensoren Anstatt alle möglichen Eingabegeräte zu unterstützen, stellt Java3D eine Schnittstelle InputDevice zur Verfügung, die von Herstellern benutzt werden kann, um einen Treiber für ein spezielles Eingabegerät zu implementieren [Sowi99]. Innerhalb der virtuellen Welt wird ein Eingabegerät durch ein oder mehrere Sensor-Objekte repräsentiert, die das zugehörige InputDevice-Objekt bereit stellt. Ein Sensor stellt jeweils eine Quelle von Daten bezüglich sechs Freiheitsgerade dar, zusätzlich liefert er ein Array, welches die Zustände eventuell vorhandener Knöpfe und Schalter definiert. Diese Daten werden zusammen mit einem Zeitstempel in einem SensorRead-Objekt gespeichert. Um auch Durchschnittsdaten zu behandeln, puffert ein Sensor immer eine feste Anzahl von Datensätzen.

2.3. VR-Systeme

47

Bild 2.18: View-Objekt und zugehörige Objekte [Sowi00] Java3D verwaltet alle vorhandenen Sensoren innerhalb des PhysicalEnvironment-Objektes, wo sie für das System verfügbar sind. Anstatt direkt auf ein spezielles Eingabegerät zuzugreifen, benutzt eine Applikation also eine Reihe von Objekten, ohne sich um die physikalischen Spezifikationen des Gerätes kümmern zu müssen. Weitere Informationen zur Java3D API findet sich auf der Java3D Webseite [Ja3d00], einen sehr guten Einstieg bietet auch das Java 3D Tutorial von Sun [Bouv99].

2.4 Konzept der dreidimensionalen Beanbox Diese Anwendung entstand im Rahmen einer Studienarbeit an der Technischen Universität Darmstadt [Rein99]. Die in der vorliegenden Arbeit verwendeten dreidimensionalen Komponenten werden auf den dort entwickelten Konzepten aufbauen, zumal es möglich sein soll, Beans, die in ETOILE verwendet werden mit der Beanbox zu bearbeiten, oder mit der Beanbox erstellte Beans wieder in ETOILE zu benutzen. Die Motivation, die zu der Entwicklung dieses Systems führte, war die Tatsache, daß die Modellierung von dreidimensionalen Objekten und Welten eine komplexe und aufwendige Arbeit darstellte. Ebenso war es schwierig, bestehende Objekte für andere Szenen wiederzuverwenden [DoGr00].

BG

View Canvas3D Screen3D

View Platform

Physical Body

Physical Environment

VP

Virtual Universe

Locale


48

Bild 2.19: Die dreidimensionale Beanbox. Aus diesem Grund bot sich das Konzept der komponentenbasierten Softwareentwicklung an (siehe auch Kapitel 2.1). Dies wurde in der Programmiersprache Java mit dem Modell der JavaBeans (siehe Kapitel 2.1.1.3) schon unterstützt und sollte nun auf Java3D übertragen werden. Das Ergebnis war ein Autorenwerkzeug, welches das Arbeiten mit dreidimensionalen JavaBeans ermöglichte (siehe Bild 2.19). Die Beanbox erlaubt das Einfügen von 3D-Beans als unabhängige Objekte oder auch relativ zu einem übergeordneten Objekt. Diese zusammengesetzten Objekte können dann als eine Einheit wieder ein neues Bean bilden. Die geometrischen Eigenschaften Position, Orientierung und Skalierung können zur Laufzeit ebenso verändert werden, wie die Eigenschaften, die das Bean über die Methoden getXxx() und setXxx() zur Verfügung stellt. Analog zu den herkömmlichen JavaBeans ist es auch möglich, Komponenten über Ereignisse zu verknüpfen. Dies schließt die Spezialfälle wie PropertyChangeEvent und VetoableChangeEvent mit ein (vergleiche mit Kapitel 2.1.1.3).

2.4. Konzept der dreidimensionalen Beanbox

49

2.4.1 Struktur eines Beans der dreidimensionalen Beanbox

Ein 3D-Bean muß sich an dieselben Konventionen halten, wie ein normales JavaBean1. Um als Java3D-Objekt in der dreidimensionalen Beanbox dargestellt werden zu können, ist es außerdem notwendig, daß die Hauptklasse des Beans die Klasse BranchGroup erweitert (siehe Kapitel 2.3). Um das Objekt im virtuellen Raum der Beanbox positionieren zu können, wird oberhalb der BranchGroup von der Beanbox eine TransformGroup eingefügt. Diese enthält dann neben dem Bean zusätzliche Behavior-Klassen, welche die Manipulation mit der Maus erlauben (siehe Bild 2.20).

Bild 2.20: Aufbau eines dreidimensionalen Beans.

2.4.2 Schlußfolgerung Der Vorteil, ein 3D-Bean als Erweiterung der BranchGroup-Klasse zu implementieren, liegt in der Tatsache, daß eine solche Komponente einem Java3D-Szenengraphen auch zur Laufzeit beliebig hinzugefügt oder entfernt werden kann.

1 Ein Problem ist hierbei die Implementierung der Schnittstelle Serializable, da ein Großteil der in Java3D verwendeten Klassen noch keine Serialisierung unterstützen. Die 3D Beanbox wurde daher so implementiert, daß es ausreicht, wenn die Eigenschaften (Properties) der Beans serialisierbare Typen sind.

TG

BGHauptklasse des Beans,die von BranchGroup erbt.

Weitere Java3D Klassen, die dasAussehen und Verhalten desObjektes definieren

B

Behavior-Klassen zum Selektierenund Manipulierendes Beans mit derMaus

TransformGroup zumPositionieren des Beansinnerhalb der Beanbox.


50

Durch die Möglichkeit, 3D-Beans graphisch anzupassen und zusammenzufügen, stellt die dreidimensionale Beanbox ein nützliches Werkzeug dar, um neue Beans zu entwerfen. Es ist daher von Vorteil, wenn Komponenten, die für das ETOILE-System benutzt werden, auch in der Beanbox behandelt werden können. Die für das geplante VR-System verwendeten dreidimensionalen Objekte werden deshalb auf der hier vorgestellten Struktur aufbauen, um eine möglichst hohe Kompatibilität zu der dreidimensionalen Beanbox zu gewährleisten.

51

3 Das ETOILE-System Das Trainingssystem ETOILE (Environment for Team, Organisational and Individual Learning in Emergencies) ermöglicht es, Notfallsituationen in einer virtuellen Welt zu simulieren und die kommunikativen und koordinierenden Aufgaben zu trainieren. Das System benutzt dafür unter anderem intelligente Agenten, welche als "Mitspieler" die Rollen von beteiligten Personen übernehmen können. Das Training kann verteilt über ein Netzwerk abgehalten werden, das heißt Trainierende müssen sich physikalisch nicht am selben Ort aufhalten. Ein VR-System stellt die virtuelle Trainingssituation zusammen mit den Agenten und anderen Teilnehmern dar. Bild 3.1 zeigt eine Trainingsapplikation mit separatem VR-Fenster.

Bild 3.1: ETOILE Trainerapplikation Für die Erstellung und Anwendung verschiedener Trainingsszenarien bietet ETOILE eine Reihe von Werkzeugen. Für eine Trainingssitzung gibt es typischerweise eine Trainerapplikation und mehrere Teilnehmerapplikationen. Der Trainer koordiniert den Ablauf des Trainings, beobachtet die Teilnehmer und greift gegebenenfalls in den Ablauf ein. Er kann beispielsweise gezielt Fehlverhalten bei den computergesteuerten Agenten oder ein anderes Ereignis in der Szene auslösen und die Reaktionen der Teilnehmer auswerten [Doer99b]. Die Eigenschaften der Szenarien, der menschlichen Teilnehmer und das Verhalten der Agenten sind alle durch Szenariodateien festgelegt. Für einige dieser Dateien stellt das System schon Editoren zur Verfügung. In den folgenden Abschnitten soll nun auf die für die Integration des neuen VR-Systems relevanten Aspekte von ETOILE eingegangen werden. Da das Konzept der komponentenbasierten Softwareentwicklung eine wichtige Rolle für die vorliegende

Kapitel 3: Das ETOILE-System

52

Arbeit spielt, wird die Verwendung von Komponenten im ETOILE-System betrachtet. Das Kommunikationssystem, das für den Datenaustausch zwischen den verteilten Applikationen benutzt wird, ist für die Anbindung der VR-Komponente an das Restsystem von Bedeutung. Schließlich soll auf die dem aktuell benutztem VR-System zugrundeliegende Spezifikation, sowie die Schnittstelle, die dieses mit ETOILE verbindet, eingegangen werden.

3.1 Anwendung von JavaBeans in ETOILE Um die graphischen Oberflächen der Applikationen an ein gegebenes Szenario anpassen zu können, sind die graphischen Bedienelemente als JavaBeans realisiert (siehe auch Kapitel 2.1.1.3). So können die Oberflächen mit einem geeigneten Werkzeug, wie zum Beispiel dem JBuilder von Borland [Jbui00], mit den zur Verfügung stehenden Beans gestaltet werden. Damit die Beans mit dem restlichen System kommunizieren können, stellt ETOILE den Zugriff auf die benötigten Klassen über einen Infobus bereit (siehe Kapitel 2.1.1.3). Wird ein Bean in einer Beanbox dem GUI hinzugefügt und instanziiert, registriert es sich automatisch für diesen Infobus und erhält so Zugriff auf das Kommunikationssystem [Doer99b]. Bei einigen Beans handelt es sich um Werkzeuge zur Kommunikation mit anderen Teilnehmern und Agenten (es existieren beispielsweise ein Telefon-Bean und ein Chat-Bean), diese benötigen auch Zugriff auf einen Kommunikationsmanager, den sie ebenfalls über den Bus erhalten. Dieser Manager regelt den Datenaustausch mit anderen Beans dieser Art.

3.2 Das Kommunikationssystem Um den Datenaustausch der Subsysteme von ETOILE untereinander und vor allem auch mit den anderen an das Netzwerk angeschlossenen Systemen zu ermöglichen, gibt es ein Kommunikationssystem, das es erlaubt, Nachrichten zu verschicken und zu empfangen. Die Kommunikationskomponente bietet einfache Methoden an, um eine Nachricht zu versenden, oder sich als Empfänger von Nachrichten zu registrieren. Um Nachrichten zu empfangen, muß eine Klasse eine bestimmte Schnittstelle erfüllen. Ein Nachrichtenobjekt besteht mindestens aus einem Schlüsselwort und dem Nachrichtentext. Dieser kann aus mehreren Teilen bestehen, die durch ein spezielles Zeichen getrennt sind. Jede Trainer- und Teilnehmerapplikation besitzt eine eigene Kommunikations-komponente, die unter einem eindeutig festgelegtem Namen adressierbar ist. Der zu der Applikation gehörende VR-Programmteil besitzt ebenfalls ein eigenes Kommunikationsmodul. Eine Nachricht kann an einen bestimmten Empfänger, an alle Applikationen oder an alle VR-Systeme geschickt werden. Um das Training später

3.2 Das Kommunikationssystem

53

besser auswerten zu können, werden alle versendeten Nachrichten beim Trainer in einer Logdatei festgehalten. Das Kommunikationssystem benutzt zum Versenden der Nachrichten eine unterliegende Kommunikationsschicht. Zum aktuellen Zeitpunkt ist diese Schicht mit Hilfe von Java RMI (Remote Method Invocation) implementiert, da dies schon, in Java integriert ist.

3.3 Das VR-System Das von STN Atlas [Stn00] entwickelte VR-System wurde in C++ implementiert und über JNI (Java Native Interface) an das ETOILE-System angeschlossen. Als zugrundeliegende Graphikbibliothek wird OpenGVS verwendet (vergleiche Kapitel 2.3.2.2).

3.3.1 Die Systeme des VR-Teils Um ein Szenario zu entwerfen, das mit dem VR-System dargestellt werden soll, sind drei Schritte nötig. Zuerst muß mit einem geeignetem Werkzeug die Geometrie der dreidimensionalen Objekte modelliert werden. Die so erzeugte Szene wird in einer Datei zur Verwendung als Objektdatenbank gesichert. Mit dem Szenarioeditor von ETOILE wird eine logische Beschreibung des Szenarios erstellt. Diese enthält symbolische Bezeichnungen für alle im Training referenzierten Objekte.

Bild 3.2: Übersicht der ETOILE-Systeme [Doer99a]

Editor zum Erstellen der logischen

Szenariobeschreibung

Editor zum Erstellen der Mappingtable

Werkzeuge zum Modellieren von 3D-

Objekten

ETOILE-Base

ETOILE-Visualization

ETOILE-Sound

Audio

2D-GUI

3D-Visualization

Authoring Training


54

Schließlich wird mit einem herkömmlichen Texteditor eine Zuordnungstabelle (Mapping-Table) erzeugt, welche die in der Szenariobeschreibung enthaltenen symbolischen Namen den Objekten der Datenbank entsprechend zuordnet. Weiterhin können hier den Objekten noch optionale Attribute zugewiesen werden. Bild 3.2 zeigt eine Übersicht über die Systeme von ETOILE, aufgeteilt in einen Entwurfs- (Authoring) und Simulationsteil (Training). Für das Training sind aus der Sicht der VR-Simulation drei Systeme von Bedeutung. ETOILE-Base beinhaltet den gesamten logischen Simulator, dieses System verwaltet und kontrolliert den Verlauf einer ETOILE-Sitzung [Doer99a]. ETOILE-Visualization kontrolliert die Darstellung der 3D-Szene und bearbeitet die Benutzerinteraktionen zur Navigation des Trainers beziehungsweise Teilnehmers. Dieses System stellt das Kernstück der VR-Umgebung dar. Seine Aufgaben umfassen das Einlesen der Mapping-Table und der Datenbank, die Verwaltung der Objekte, die Bearbeitung der Befehle von ETOILE-Base sowie die Meldung von Ereignissen, wie etwa die Selektion eines Objektes. Zusätzlich muß die Synchronisation der Positionen aller dargestellten Avatare gewährleistetet werden. Die 3D-Visualisierung ist für die Darstellung der Szene sowie die Erkennung von Benutzereingaben zuständig. Benutzerinteraktionen mit dem VR-System beschränken sich auf das Selektieren bestimmter Objekte und das Navigieren durch das Szenario mit der Maus. Die Bewegung der Agentenavatare und das Verhalten der übrigen Objekte wird vollständig von ETOILE-Base gesteuert. Abhängig von der Art des Benutzers kann die Darstellung und Interaktion verschieden sein. Ein normaler Teilnehmer wird durch einen Avatar repräsentiert und kann Objekte der Szene selektieren, außerdem muß für ihn eine Kollisionserkennung durchgeführt werden. Der Trainer ist für die anderen Teilnehmer nicht sichtbar, das heißt er besitzt keinen Avatar. Er kann sich frei durch die Szene bewegen (keine Kollisionserkennung) aber keine Objekte selektieren.

3.3.2 Modellstruktur der Datenbank Die verwendeten dreidimensionalen Modelle werden als Dateien im OpenFlight-Format gespeichert. Eine Datei enthält die gesamte statische Szene. Für dynamische Objekte, wie zum Beispiel Avatare, gibt es jeweils separate Dateien. Das OpenFlight-Format verwaltet die Objekte ebenfalls in einer hierarchischen Baumstruktur [Open00]. Die für das VR-System wichtigsten Knotentypen sind Objektknoten, die die aktuelle Geometrie eines Objektes enthalten, Gruppenknoten und Switch-Knoten. Letztere erlauben die Auswahl eines oder mehrerer Kindknoten. Jedem Knoten kann als Attribut ein Name zugewiesen werden, diese werden benutzt, um ein bestimmtes Objekt zu identifizieren, oder den Typ eines Objektes zu bestimmen.

3.3 Das VR-System

55

Neben normalen statischen Objekten kann die Szene auch noch Animationen oder Switches enthalten. Beide werden über Switch-Knoten realisiert, zur Unterscheidung wird eine Namenskonvention benutzt. Außer den sichtbaren Objekten existieren in der statischen Szenen auch noch folgende (nicht sichtbare) Objekttypen:

• Pfade (Predefined Paths): Agenten können nur entlang vorher definierter Pfade bewegt werden. In der aktuellen Implementierung werden Pfade nur über die Mapping-Table angegeben und nicht in der Datenbank definiert (siehe unten).

• Regionen (Labeled Areas): Dies sind Regionen, für die beim Betreten oder

Verlassen durch einen Teilnehmer eine Nachricht an ETOILE-Base gesendet wird, das daraufhin ein bestimmtes Ereignis auslösen kann. Die Region ist in der Datenbank durch ein Polygon dargestellt, das den Grundriß beschreibt.

• Aktionspunkte (Action Points): Dies sind Positionen in der Szene, an denen

Agenten eine Aktion ausführen können, beziehungsweise die als Startpositionen für Teilnehmer dienen. Aktionspunkte werden in der Datenbank durch ein kleines Dreieck dargestellt, dessen Mittelpunkt die Position bestimmt.

Um diese Objekte von den sichtbaren Objekten zu unterscheiden, sind sie in der Datenbankstruktur unterhalb entsprechend benannter Gruppenkoten (AP beziehungsweise LA) organisiert, wie in Bild 3.3. dargestellt.

Bild 3.3: Datenbankstruktur der statischen Szene

3.3.3 Die Mapping-Table In der Mapping-Table werden die in der Szenariobeschreibung enthaltenen symbolischen Namen den in der OpenFlight-Datei benutzten geometrischen Namen der Objekte zugeordnet. Ein Eintrag in der Mapping-Table hat folgende Struktur [StWe00]:

Datenbank

Geometrie AP LA

Typ Logischer Name Geometrischer Name Status Link


56

Im Feld Typ wird der Objekttyp festgelegt: Datenbank (db), Objekt (obj), Animation (objani), Switch (objsw), Aktionspunkt (ap), Pfad (pp) oder Region (la). Die Felder Logischer Name und Geometrischer Name geben entsprechend die symbolischen Namen aus der Szenariobeschreibung beziehungsweise die Namen der referenzierten Objekte an. Der geometrische Name kann sich auf einen Knoten in der aktuellen Datenbank oder den Namen einer externen OpenFlight-Datei beziehen. Im Statusfeld können optional drei Attribute gesetzt werden. Dynamic (dyn) gibt an, daß das Objekt in der Szene bewegt werden kann. Selectable (sel) zeigt an, das es möglich ist, das Objekt auszuwählen. Animation (ani) schließlich zeigt an, daß das Objekt eine Animation enthält. Will man bei einem in einer externen Datei definierten Szenengraph einen anderen Knoten als den obersten referenzieren, kann man eine Verknüpfung zu der Datei im Feld Link angeben. Der geometrische Name des Knotens wird normal im entsprechen Feld eingetragen. Für den Fall, daß es sich bei dem Objekt um einen Pfad handelt, tritt ein Sonderfall ein, da dieser nicht in der Datenbank enthalten ist. Hier wird statt des geometrischen Namens eine Liste logischer Namen von Aktionspunkten gegeben, die den Verlauf des Pfades definieren.

3.3.4 Die Schnittstelle zum ETOILE-System Der Datenaustausch zwischen ETOILE-Visualization und ETOILE-Base findet über das Kommunikationssystem statt, das heißt es werden Nachrichten mit einem Schlüsselwort verschickt, die im Textrumpf eventuelle Parameter enthalten. ETOILE-Base schickt Befehle an das VR-System, das diese dann entsprechend bearbeitet [StWe00]. Dies sind im einzelnen:

• Datenbank laden (loadMap): laden einer Mapping-Table und der zugehörigen OpenFlight-Dateien.

• Objekt laden (loadObject): lädt ein dynamisches Objekt und plaziert es an eine angegebene Position.

• Objekt bewegen (moveObj): bewegt ein dynamisches Objekt entlang eines spezifizierten Pfades.

• Objektstatus ändern (changeObjStatus): ändert das dargestellte Objekt eines Switch.

• Objekt entfernen (removeObject): entfernt ein dynamisches Objekt aus der Szene.

• Initialisieren (initTrainAppl): initialisiert die VR-Applikation mit dem Namen und Typ des Teilnehmers und den Daten für den Multicast.

• Umgebung (environStatus): verändert die Lichtverhältnisse bezüglich einer angegebenen Tageszeit und eines Helligkeitswertes.

• Helligkeit (setBrightness): bestimmt die Helligkeit der Szene.

3.3 Das VR-System

57

ETOILE-Visualization schickt an das ETOILE-System Nachrichten, die das Auftreten spezieller Ereignisse anzeigen:

• Objekt selektiert (objSelected): gibt an, daß ein Objekt ausgewählt wurde. • Region betreten (entryLA): eine angegebene Region wurde betreten. • Region verlassen (leaveLA): eine Region wurde verlassen. • Pfad beendet (endOfPath): ein Objekt, das entlang eines Pfades bewegt

wurde, hat dessen Ende erreicht. Des weiteren wurden noch einige Nachrichten zu Testzwecken realisiert, auf die hier aber nicht näher eingegangen werden soll.

58

4 Konzept des komponentenbasierten VR-Systems

Nachdem in den vorhergehenden Kapiteln die theoretischen Grundlagen behandelt wurden, auf denen diese Arbeit aufbaut, soll hier nun auf den konzeptionellen Entwurf des VR-Systems eingegangen werden. Das in Kapitel 2.1 vorgestellte Konzept der komponentenbasierten Softwareentwicklung ist ein wesentlicher Bestandteil des in dieser Arbeit entwickelten Systems. Beide in jenem Kapitel vorgestellten Sichtweisen einer Softwarekomponente sind hier vertreten. Die dreidimensionalen Objekte der Szene sind als 3D-Beans konzipiert, analog zu den in der 3D-Beanbox (siehe Kapitel 2.4) entwickelten Komponenten. Die 3D-Beans des VR-Systems verkörpern die Idee der frei verfügbaren (eventuell auch kommerziellen) Bausteine, die einem System hinzugefügt werden können. Der Aspekt der Pflegeleichtigkeit tritt mehr im Entwurf des VR-System hervor, das die dreidimensionalen Komponenten darstellt und zur Visualisierung eines Trainingsszenarios von ETOILE dient. Dieses System setzt sich nämlich aus mehreren Teilsystemen zusammen, die ebenfalls als Komponenten realisiert sind. Damit werden viele Vorteile verfügbar, die durch die Anwendung komponentenbasierter Softwareentwicklung ermöglicht werden. Wie noch gezeigt wird, bedeutet die Verwendung der 3D-Beans vor allem für das Erstellen und Warten von neuen Trainingsszenarien eine Verbesserung. Dieser in Kapitel 3.3.1 beschriebene Prozeß beinhaltete die manuelle Erstellung einer Mapping-Table, um den modellierten Objekten bestimmte Eigenschaften zuzuordnen. Da die 3D-Beans programmierbare geometrische Objekte darstellen, können diese Attribute als Properties zusammen mit dem Bean gespeichert werden. Vor allem aber bieten die 3D-Beans die Möglichkeit, ein Szenario visuell zu erstellen und zu bearbeiten. Die Struktur und Art der verwendeten 3D-Beans wird in Kapitel 4.1 genauer erläutert. Wie in Kapitel 2.1. beschrieben, wird durch die Realisierung eines Softwaresystems als Komponentensystem dieses pflegeleichter und bietet die Möglichkeit, die Programmfunktionen leicht zu erweitern beziehungsweise Untersysteme für andere Applikationen wiederzuverwenden. Wie wir zeigen werden, trifft dies auch auf das hier entwickelte VR-System zu. Um die erwähnten Vorteile des Konzepts zu demonstrieren, wurde prototypisch ein Editor entwickelt, der die visuelle Bearbeitung der Objektattribute erlaubt und zu großen Teilen aus Komponenten besteht, die auch im VR-System verwendet werden. Die Architektur des VR-Systems und des Editors wird in Kapitel 4.2 behandelt. Kapitel 4.3 beschreibt schließlich, wie die in 2.2 vorgestellten Prinzipien für eine benutzungsfreundliche Gestaltung der Interaktionsschnittstellen der Systeme verwandt wurden.

4.1 Eigenschaften der dreidimensionalen Beans

59

4.1 Eigenschaften der dreidimensionalen Beans Eine Eigenschaft eines in ETOILE verwendeten 3D-Beans soll es sein, daß die Attribute, welche beim alten VR-System in der Mapping-Table definiert wurden, nun schon ein Bestandteil des zugehörigen Objektes sind. Ein 3D-Bean muß also eine bestimmte Schnittstelle erfüllen, welche es erlaubt, dem Objekt die benötigten Eigenschaften zuzuweisen:

• Der geometrische Name wird benutzt, um das Objekt innerhalb der Datenbank eindeutig zu identifizieren.

• Der symbolische Name ist eine logische Bezeichnung, unter der ETOILE-Base

das Objekt während einer Trainingssitzung referenzieren kann. Objekte, denen kein Name zugewiesen wurde, werden für die Trainingssimulation auch nicht betrachtet (mit Ausnahme von physikalischen Simulationen, wie zum Beispiel Kollisionserkennung).

• Das Attribut selektierbar zeigt an, daß das Objekt ausgewählt werden kann.

Wird ein solches Bean während des Trainings von einem Teilnehmer ausgewählt, wird eine entsprechende Nachricht an ETOILE gesendet.

• Mit dem Attribut dynamisch schließlich wird angegeben, daß das Objekt kein

Teil der statischen Umgebung ist, sondern der Szene hinzugefügt, wieder daraus entfernt sowie darin bewegt werden kann. Dynamischen Objekten ist in der geometrischen Beschreibung der Szene keine Startposition zugeordnet, diese wird in der logischen Beschreibung festgelegt.

Das Attribut animierbar, das in der Mapping-Table des ursprünglichen Systems vorhanden ist, wird nicht mehr benutzt. Ob ein Objekt eine Animation beinhaltet, wird aus der Verwendung eines Animation-Beans (siehe unten) ersichtlich.

Bild 4.1: Teilkomponenten eines dreidimensionalen Beans in ETOILE.

Geometrie

Programmcode

Attribute: Geometrischer Name Symbolischer Name Selektierbar Dynamisch

Kapitel 4: Konzept des komponentenbasierten VR-Systems

60

Neben diesen Attributen enthält ein 3D-Bean von ETOILE außerdem Daten, welche die verwendete Geometrie beschreiben und eventuell noch weiteren Programmcode zur Definition des Objektverhaltens (siehe Bild 4.1). Beschreibung der verwendeten Beans ETOILE kennt verschiedene Objekttypen, die in einem virtuellen Szenario vorkommen können (vergleiche auch Kapitel 3.3.2). Jeder dieser Typen wird innerhalb des VR-Systems durch ein entsprechendes 3D-Bean repräsentiert. Die verwendeten Typen lassen sich einteilen in sichtbare Objekte, die in der Szene dargestellt werden und spezielle, nicht sichtbare Komponenten, die Positionen und Bereiche innerhalb der Szene definieren (siehe Bild 4.2).

Bild 4.2: Klassifizierung der verschiedenen Bean-Typen. Das einfachste der dargestellten 3D-Beans ist das 3D-Objekt. Hierbei handelt es sich um ein Objekt mit statischer Geometrie und ohne zusätzlichen Programmcode für ein dynamisches Verhalten. Neben diesem existieren noch die Beans Animation und Switch, welche die entsprechende Funktionalität im Programmteil implementieren.

3D-Bean

Visuelle Objekte

Nicht sichtbare Objekte

3D-Objekt

Switch

Animation

Pfad

Aktionspunkt

Region

Szenario

4.1 Eigenschaften der dreidimensionalen Beans

61

Die nicht sichtbaren Beans werden im Trainingsszenario zwar nicht dargestellt, sie enthalten aber dennoch geometrische Repräsentationen, die bei Bedarf sichtbar gemacht werden. Dies ist nützlich, falls diese Komponenten in einem visuellen Editor wie der Beanbox manipuliert werden sollen. Zu diesem Zweck besitzen diese Beans ein zusätzliches Attribut sichtbar, mit dem die Repräsentation ein- oder ausgeschaltet werden kann. Ein Pfad definiert wie beim ursprünglichen VR-System einen Weg innerhalb der Szene, auf dem Objekte bewegt werden können. Ursprünglich war geplant, die Interpolation von Objektpositionen entlang eines Pfades durch eine Komponente des VR-Systems zu realisieren. Doch die Implementierung der 3D-Objekte als Softwarekomponenten erlaubte eine elegantere Lösung: das Pfad-Bean selbst ist für die Translation eines beliebigen sichtbaren Beans entlang des definierten Weges zuständig. Die Beans Aktionspunkt und Region beschreiben analog zum alten System eine Position beziehungsweise ein Raumvolumen innerhalb der dreidimensionalen Szene. Zur Verwaltung der Beans eines Trainingsszenarios existiert ein spezielles Bean Szenario, das als Behälter der übrigen Objekte dient. Dadurch ist es möglich, die gesamte Szene durch eine einzige Komponente zu repräsentieren. Diese kann dann einfach an andere Systeme übergeben oder auch in einer Objektdatenbank gespeichert werden.

4.2 Beschreibung der Architektur In diesem Kapitel soll die Struktur des Systems und der Aufbau der beiden Applikationen behandelt werden. Abschnitt 4.2.1 legt zunächst die Aufgaben dar, die das System erfüllen muß. In 4.2.2 und 4.2.3 werden danach die aus diesen Anforderungen hervorgegangenen Teilsysteme und ihr Zusammenspiel beschrieben.

4.2.1 Aufgaben des VR-Systems Der Zweck des VR-Systems ist, wie in Kapitel 3.3.1 beschrieben, die Visualisierung eines virtuellen Trainingsszenarios, welches aus 3D-Beans aufgebaut ist. Die wichtigsten Teilaspekte, die für diese Aufgabe nötig sind, beinhalten die Verwaltung der Beans, die Visualisierung der Szene, die Eingabeverarbeitung, die Kommunikation mit anderen Systemen und in gewissem Ausmaß die Simulation der virtuellen Welt.

4.2.1.1 Verwaltung der 3D-Beans Ein virtuelles Szenario besteht aus einer Menge von 3D-Beans, die Objektgeometrien, Attribute und Verhaltensbeschreibungen enthalten. Diese Daten können zum Beispiel in einer serialisierten Form (also als Byte-Code) vorliegen und in einem JAR-Archiv organisiert sein. Eine andere Möglichkeit ist die Aufteilung in eine Mapping-Table


62

und eine separate Datei, welche die geometrischen Daten enthält, wie es auch bei dem ursprünglichen System der Fall war. Der Nachteil dieser Methode ist, daß die Informationen nicht in einer einzelnen Datei konzentriert, sondern auf mehrere verteilt sind, die alle bei einer Wiederverwendung des Szenarios zusammen weitergegeben werden müssen. Um ein Szenario darstellen zu können, muß eine Methode bereitgestellt werden, welche die in einer solchen Form vorliegenden Daten auslesen und in Instanzen von 3D-Beans umwandeln kann. Um Änderungen am Szenario zu sichern, muß aber auch der umgekehrte Weg möglich sein. Weiterhin müssen nach der Instanziierung der Beans diese innerhalb des System verwaltet werden, so daß allen Komponenten, die diese benötigen, ein schneller Zugriff gewährt wird.

4.2.1.2 Visualisierung der Szene Die virtuelle Szene, die aus den 3D-Beans aufgebaut ist, soll für den Trainingsteilnehmer möglichst realistisch dargestellt werden. Um das Gefühl der Immersion zu bewahren, muß aber auch eine genügend hohe Bilderzeugungsrate eingehalten werden. Die Darstellung ist abhängig vom aktuellen Blickpunkt des Betrachters und den Positionen der dreidimensionalen Objekte. Um den Blickpunkt zu verändern und die Szene zu betrachten, müssen geeignete Navigationsparadigmen (siehe Kapitel 2.3.2.1) bereitgestellt werden. Die Aufgabe der Visualisierung wird hauptsächlich von Java3D übernommen werden.

4.2.1.3 Eingabeverarbeitung Das System muß auf viele Arten von Eingaben reagieren. Eine Möglichkeit sind direkte Benutzereingaben mit der Maus, dies schließt die Navigation durch die Szene sowie das Selektieren von Objekten ein. Diese Aktionen haben einerseits eine direkte Auswirkung auf das VR-System (Änderung der Position, Markieren des gewählten Objektes), stellen aber auch Ereignisse dar, die an ETOILE-Base weitergeleitet werden müssen (Betreten oder Verlassen einer Region und jede Selektion, die ein Teilnehmer vornimmt). Andere Eingaben kommen von ETOILE-Base, dies sind Befehle, die den Zustand der virtuellen Welt an den aktuellen Zustand der Simulation angleichen. Beispiele sind das Laden eines bestimmten Szenarios, das Positionieren von Objekten oder das Bewegen eines Objektes entlang eines Pfades. Das VR-System muß die über das Kommunikationssystem gesendeten Befehle auswerten und die entsprechende Aktion ausführen. Schließlich muß das System auf indirekte Benutzereingaben reagieren. Dies ist der Fall, wenn sich ein Teilnehmer eines anderen VR-Systems, das über ein Netzwerk mit diesem verbunden ist, bewegt und die neuen Positionsdaten zur Darstellung des entsprechenden Avatars zur Synchronisation an dieses System gesendet werden.

4.2 Beschreibung der Architektur

63

4.2.1.4 Kommunikation Um mit ETOILE-Base zu interagieren, muß das System Nachrichten über das Kommunikationssystem von ETOILE versenden und empfangen können. Damit das neue VR-System ohne größere Probleme mit ETOILE zusammenarbeiten kann, sollte die in 3.3.4 beschriebene Schnittstelle soweit wie möglich beibehalten werden. Ein weiterer Aspekt der Kommunikation ist die Synchronisation der Avatare und anderer dynamischer Objekte zwischen den verteilten VR-Systemen. Der Zustand der dargestellten virtuellen Welten muß konsistent sein, um ein sinnvolles Arbeiten zu ermöglichen. Änderungen im Szenario sollten sich, wenn möglich, in Echtzeit auswirken. Daher müssen diese Daten so schnell wie möglich übermittelt werden.

4.2.1.5 Simulation Die Simulation eines Szenarios wird hauptsächlich von ETOILE-Base gesteuert, dem VR-System kommt dabei noch die Aufgabe der physikalischen Simulation zu. Um ein sinnvolles Arbeiten mit dem System möglich zu machen, soll hier zumindest eine Kollisionserkennung zwischen dem Teilnehmer und den 3D-Beans realisiert werden.

4.2.2 Architektur des VR-Systems Die im vorherigen Kapitel angestellten Überlegungen führen zu einer Aufteilung des Systems in mehrere Teilsysteme, welche Methoden zur Durchführung der angesprochenen Aufgaben anbieten. Dabei ist jedes Teilsystem als Softwarekomponente gemäß Kapitel 2.1 aufzufassen. Die Struktur des Systems ist in Bild 4.3 abgebildet, die Pfeile stellen den Datenaustausch zwischen den Komponenten dar. Koordination. Dieses System ist das Herzstück der Anwendung, es kann als die Infrastruktur angesehen werden, welche die Kommunikation zwischen den Komponenten steuert. Weiterhin werden hier die Nachrichten von ETOILE-Base interpretiert und die entsprechenden Aktionen ausgelöst. In der Gegenrichtung werden aus den Benutzerinteraktionen resultierende Ereignisse, wie zum Beispiel die Selektion eines Objektes, an das ETOILE-System zurückgemeldet. Schließlich werden hier auch direkte Rückmeldungen zu den Benutzereingaben erzeugt, zum Beispiel das Markieren eines selektierten Objektes oder die Angabe der aktuellen Position. Szenario-Verwaltung Diese Komponente erlaubt das Einlesen eines gespeicherten Szenarios und wandelt die Daten in 3D-Beans um. Umgekehrt ist es auch möglich, eine aus Beans bestehende Szene wieder in diesem Format zu sichern.


64

Bild 4.3: Komponentenstruktur des VR-Systems Visualisierung und Navigation Hier werden die 3D-Beans der Szene abhängig vom Blickpunkt des Betrachters dargestellt. Weiterhin werden Eingaben, die ein Teilnehmer mit der Maus tätigt, registriert und bei Bedarf an die Koordinationskomponente weitergeleitet. Für die Navigation durch die Szene stellt die Komponente zwei Paradigmen zur Verfügung (siehe auch Kapitel 2.3.2.1): Eyeball-in-Hand wird bei einer normalen Trainingssitzung verwendet, während Scene-in-Hand für die Verwendung von Editoren gedacht ist. Betritt oder verläßt der Anwender während der Navigation eine spezifizierte Region, wird dies ebenfalls der Koordinationskomponente mitgeteilt. Die Änderungen der Position werden zu Synchronisationszwecken über die Kommunikationskomponente an die anderen VR-Systemen gesendet.

Szenario-Verwaltung

Koordination

Graphische Oberflächen

Visualisierung und Navigation

Kommunikation

Bean-Verwaltung

ETOILE-Base

Gespeichertes Szenario

Kollisionserkennung

4.2 Beschreibung der Architektur

65

Kollisionserkennung Für das VR-System eines regulären Trainingsteilnehmers ist es nötig, daß Kollisionen erkannt werden und eine Fortbewegung durch Objekte hindurch nicht möglich ist. Diese Komponente ermittelt mögliche Kollisionen des Betrachters mit der Umgebung und kann von der Navigationskomponente aufgerufen werden. Bean-Verwaltung Nachdem die Szenario-Verwaltung die 3D-Beans aus den Szenariodaten erzeugt hat, werden diese hier verwaltet. Andere Komponenten können hier auf die gespeicherten Beans zugreifen. Der Zugriff geschieht zum Beispiel über den symbolischen Namen, den Typ des Beans oder eines der Attribute. Graphische Oberflächen Da das VR-System je nach Anwender (Trainer oder Teilnehmer) unterschiedliche Schnittstellen anbietet, stellen die graphischen Benutzungsoberflächen separate Komponenten dar. Bei der Initialisierung des Systems wird von der Koordinationskomponente automatisch die richtige Oberfläche ausgewählt und dargestellt. Kommunikation Diese Komponente stellt die Verbindung zum Kommunikationssystem von ETOILE her, das heißt sie ist für das Senden und Empfangen von Nachrichten zuständig. Neben der Behandlung von normalen ETOILE-Nachrichten tauscht sie auch mit anderen VR-Systemen Daten zur Synchronisationen der Teilnehmer-Avatare aus.

4.2.3 Architektur des Editors Zur Demonstration der Vorteile der komponentenbasierten Softwareentwicklung wird in dieser Arbeit prototypisch ein aus Komponenten des VR-Systems bestehender Mapping-Editor entwickelt. Dieser soll die Aufgabe übernehmen, für die im ursprünglichen VR-System die Mapping-Table verwendet wurde, also die Zuordnung von Attributen zu den einzelnen Objekten. Der Editor soll es erlauben, die Eigenschaften der Objekte visuell über eine graphische Benutzungsoberfläche zu bearbeiten. Wie in Bild 4.4 zu sehen ist, werden für den Editor zum größten Teil die Komponenten des VR-Sytems wiederverwendet. Nur die Koordinationskomponente ist verändert, hier wird die Funktionalität des Editors implementiert. Der Editor ist als Werkzeug gedacht, um die Attribute der 3D-Beans zu bearbeiten. Aus diesem Grund wird die Szenario-Verwaltung nicht nur zum Einlesen, sondern auch zum Speichern von Szenariodaten genutzt. Da der Editor nur eine Benutzungsoberfläche braucht, ist sie nicht als Komponente entworfen, sondern in die Hauptkomponente integriert. Die Kollisionserkennung wird ebenfalls nicht benötigt.


66

Bild 4.4: Komponentenstruktur des Mapping-Editors

4.3 Überlegungen zur Benutzungsfreundlichkeit In diesem Kapitel wird der Aspekt der Benutzungsfreundlichkeit des Systems behandelt werden. Dazu sollen die in Kapitel 2.2 angesprochenen Konzepte der visuellen Programmierung (für den Autorenprozeß) und der anwenderfreundlich gestalteten Interaktionsschnittstelle (für das VR-System) geeignet umgesetzt werden.

4.3.1 Interaktionsschnittstelle der VR Als Grundlage für den Entwurf der Interaktionsschnittstelle, die dem Benutzer des VR-Systems angeboten wird, dienten hauptsächlich die in [Gabb97] definierten Richtlinien. Wie schon in Kapitel 2.2.2 angedeutet, kommt dem Aspekt der Navigation und der Locomotion, das heißt der Bewegung durch die virtuelle Szene, große Bedeutung zu, da diese Tätigkeit von dem Benutzer am häufigsten ausgeführt wird. Ein weiterer Gesichtpunkt, der für das Trainingssystem relevant ist, ist die Selektion von dreidimensionalen Objekten. Für die Benutzerinteraktionen sollen daher folgende Anforderungen in Betracht gezogen werden:

• Orientierungs- und Navigationshilfen. Um sich innerhalb der virtuellen Welt orientieren zu können, sollten dem Teilnehmer Informationen über seinen aktuellen Standort vorliegen. Im Fall eines Trainingsszenarios kann

Szenario-Verwaltung

Editor-Koordination

Visualisierung und Navigation

Bean-Verwaltung

Gespeichertes Szenario

4.3 Überlegungen zur Benutzungsfreundlichkeit

67

dies zum Beispiel über die Anzeige des Namens der Region beziehungsweise des Raumes geschehen, in dem er sich gerade befindet. Eine (beschriftete) Übersichtskarte des Szenarios ist ebenfalls hilfreich.

• Angemessene Kontrollmetaphern. Wie schon oben erwähnt, ist für die

Navigation durch das Szenario während des Trainings das Paradigma Eyeball-in-Hand am besten geeignet, da es der natürlichen Art entspricht, mit der auch in der Realität die umgebende Welt betrachtet wird. Die Fortbewegung erfolgt entweder durch "Laufen", das über ein physikalisches Eingabegerät (hier die Tastatur) gesteuert wird oder auch durch Teleportation (vergleiche Kapitel 2.3.2.1).

• Vermeidung modusbasierter Navigation. Bei handbasierter Navigation, wie

es bei der Eingabe mit der Maus der Fall ist, können die Interaktionsmöglichkeiten des Benutzers eingeschränkt sein, da Navigation sowie Manipulation mit der Hand ausgeführt werden. Ist der Anwender gezwungen, erst in einen anderen Modus umzuschalten, um etwa nach dem Betreten eines Raumes einen Lichtschalter selektieren zu können, nur um dann wieder in den Navigationsmodus wechseln zu müssen, hat das eine kontraproduktive Wirkung auf den Trainingsverlauf. Eine Möglichkeit, dies zu vermeiden, ist zum Besipiel die sinnvolle Ausnutzung der Maustasten: jeweils einer Taste wird die Funktion Selektion beziehungsweise Blickpunktänderung zugeordnet.

• Nur die benötigten Freiheitsgrade implementieren. Die Veränderung von

Position und Orientierung des Benutzers innerhalb der virtuellen Welt kann durch sechs Freiheitsgrade beschrieben werden. Abhängig von der Art der Navigation und Fortbewegung kann es aber sinnvoll sein, nicht alle Dimensionen zu benutzen. Da bei der Trainingssimulation die Szene "durchlaufen" wird, braucht zum Beispiel die Translation entlang der Y-Achse und die Rotation um die Z-Achse nicht betrachtet zu werden.

• Feedback zu Selektionen. Wurde ein Objekt selektiert, sollte dies dem

Benutzer kenntlich gemacht werden. Dies kann durch eine Markierung des gewählten Objektes (Highlight) geschehen, die Wiedergabe eines akustischen Signals sowie die Anzeige weiterer Informationen über das Objekt in einem Textfenster.

• Konsistentes Layout. Wird der Anwender mit verschiedenen Oberflächen

konfrontiert, sollten sie sich in Aufbau und Bedienung ähnlich sein. Erkennt der Benutzer die Bedienungsstruktur wieder, findet er sich schneller mit dem Programm zurecht.

Ausgehend von diesen Überlegungen soll nun das Konzept für die Interaktionsschnittstelle des VR-Systems entworfen werden. Navigation und Objektmanipulation Das Trainingssystem ist als "Desktop-VR" entworfen, das heißt zur Eingabe dienen Tastatur und Maus, die Ausgabe erfolgt über einen Monitor. Selektionen erfolgen


68

daher wie gewohnt über die Maus, dies gilt gleichermaßen für Bedienelemente der graphischen Oberfläche wie Objekte der dreidimensionalen Szene. Der Blickpunkt des Anwenders in der Szene wird gleichfalls mit Hilfe der Maus verändert. Damit ein Umschalten zwischen einem Navigations- und Selektionsmodus vermieden wird, sollten die verschiedenen Maustasten ausgenutzt werden, um beide Interak-tionsarten zu ermöglichen. Ebenso kann die Tastatur als zusätzliches Eingabegerät genutzt werden, zum Beispiel für die Locomotion. Die Selektion eines Objektes sollte durch eine Markierung kenntlich gemacht werden, zusätzlich ist die Ausgabe in einem Textfenster (siehe unten) möglich.

Graphische Benutzungsoberfläche Abhängig von der Art des Benutzers (Trainer oder Trainingsteilnehmer) wird eine andere Oberfläche benutzt. Da der Trainer unter anderem eine beobachtende Rolle hat, stehen ihm zusätzliche Möglichkeiten der Navigation zur Verfügung. Den Hauptteil der Oberfläche wird der Sichtbereich ausmachen, in dem die VR-Szene dargestellt wird. Der Teilnehmer interagiert mit dem VR-System nur über die oben beschriebenen Navigations- und Selektionsmechanismen innerhalb dieses Fensters, es sind keine weiteren Bedienelemente nötig.

Bild 4.5a: Möglicher Aufbau der Graphischen Oberfläche (Teilnehmer) Um dem Benutzer Rückmeldungen über seine Aktionen zu geben, sollte die Oberfläche ein Informationsfenster enthalten, das Statusmeldungen und allgemeine Daten anzeigt, beispielsweise den Namen des aktuell ausgewählten Objektes. Als Orientierungshilfe kann in einem weiterem Textfenster der Name der Region oder des Raumes, in dem sich der Teilnehmer zur Zeit befindet angezeigt werden. Bild 4.5a skizziert ein mögliches Layout der Teilnehmeroberfläche.

Informationsfenster Position

VR-Fenster


69

Für den Trainer können noch erweiterte Möglichkeiten zur Navigation innerhalb des Szenarios zur Verfügung gestellt werden. Um ein konsistentes Layout beizubehalten, werden die Informationsfenster aber analog zur Oberfläche der Teilnehmer angeordnet. Erweitert wird die Oberfläche des Trainers um Listen, welche die dynamischen Objekte (einschließlich der Avatare der Teilnehmer) und Aktionspunkte der Szene zugänglich machen, wie in Bild 4.5b angedeutet. Wählt der Trainer aus diesen Listen einen Punkt oder ein Objekt aus, wird er sofort an den entsprechenden Ort versetzt. Dies ist von Vorteil, wenn der Trainer schnell ein Ereignis oder die Aktionen eines Teilnehmers bewerten möchte, die an einer weiter entfernten Position stattfinden.

Bild 4.5b Möglicher Aufbau der graphischen Oberfläche (Trainer)

4.3.2 Interaktionsschnittstelle des Editors Die Aufgabe des Editors ist es, dem Anwender die Möglichkeit zu geben, die Attribute der 3D-Beans eines ETOILE-Szenarios bearbeiten zu können. Die Anwendung soll dabei ansatzweise das Konzept der visuellen Programmierung umsetzen. Um die Benutzungsfreundlichkeit zu erhöhen, muß also der Formulierungsaufwand reduziert und der Visualisierungsgrad erhöht werden, hierfür lassen sich, wie für das VR-System, aus den in Kapitel 2.2 vorgestellten Konzepten folgende Anforderungen herleiten:

• Ikonen und Farben verwenden. Anstatt des ausschließlichen Gebrauchs von Text, können Sachverhalte durch die Verwendung von Bildern für den Anwender intuitiver vermittelt werden. Dabei muß aber auch darauf geachtet werden, daß der Bildschirm nicht mit zu vielen Ikonen überladen wird. Die Anwendung von Farbmetaphern kann den Visualisierungsgrad weiter erhöhen.

Informationsfenster Position

VR-Fenster

Aktionspunkte Objekte / TeilnehmerAP_1 HUMAN_1


70

• Möglichst wenig Fenster. Werden Informationen in zu vielen

Bildschirmfenstern präsentiert, kann die Übersichtlichkeit verloren gehen. Die Informationen sollten möglichst innerhalb eines einzigen Fensters präsentiert werden. Es ist jedoch möglich, daß innerhalb dieses Fensters zwischen verschiedenen Bildschirmen umgeschaltet wird.

• Unterstützung des Benutzers bei der Eingabe. Der Anwender sollte bei

falschen Eingaben auf den Fehler aufmerksam gemacht werden. Weiterhin kann für bestimmte Eingaben im vorhinein eine Liste möglicher Werte angeboten werden, aus denen der passende nach Bedarf ausgewählt wird. Die Möglichkeit, eine getätigte Eingabe wieder rückgängig zu machen, ist generell hilfreich.

• Verschiedene Selektionsmechanismen. Zur Auswahl eines 3D-Beans sollte

es mehrere Möglichkeiten geben. Soll zum Beispiel ein Objekt bearbeitet werden, das sich in der Szene an einer bestimmten Position befindet, ist die direkte Auswahl innerhalb der dreidimensionalen Szene am Besten. Ist aber der geometrische Name des Beans bekannt, kann die Auswahl aus einer Liste heraus eventuell günstiger sein.

• Verständliche Informationen. Bezeichnungen und Meldungen sollten immer

klar verständlich sein. Es sollten nur die benötigten Informationen dargestellt und zusammengehörige Angaben logisch gruppiert werden. Bedienelemente können über eine kontextsensitive Hilfe oder Tooltips erklärt werden.

Entwurf der graphischen Oberfläche Die Szene, welche die zu bearbeitenden Objekte enthält, wird in einem VR-Fenster dargestellt werden, analog zur Darstellung innerhalb des VR-Systems. Um den Blickwinkel, mit dem die Objekte betrachtet werden, zu verändern, wird hier jedoch das Scene-in-Hand-Paradigma benutzt, das heißt die Szene kann rotiert, verschoben, vergrößert oder verkleinert werden. Des weiteren werden auch alle nicht sichtbaren Objekte wie Aktionspunkte und Pfade durch entsprechende graphische Repräsentationen dargestellt. Ein Szenario enthält normalerweise eine statische Szene und zusätzlich dynamische Objekte, die dort plaziert werden können. Den dynamischen Objekten wird innerhalb der Datenbank noch keine bestimmte Position zugewiesen. Sie werden erst während des Trainings vom ETOILE-System aufgrund der Informationen der logischen Szenariobeschreibung positioniert. Aus diesem Grund sollten für den Mapper zwei separate Bildschirme vorhanden sein, um die statische Szene und die dynamischen Objekte zu bearbeiten. Der Benutzer kann zwischen diesen Bildschirmen beliebig umschalten. In einem Auswahlfenster sollten die geometrischen Namen der vorhandenen 3D-Beans in einer Liste selektiert werden können. Der Typ eines Listeneintrags soll durch Zuordnung einer entsprechenden Ikone kenntlich gemacht werden. Die Liste kann entweder alle Objekte der Szene enthalten, oder wahlweise alle Beans eines


71

bestimmten Typs (sichtbare Objekte, Aktionspunkte, Pfade oder Regionen). Außer in der Liste sollen Objekte auch direkt in der 3D-Szene mit der Maus selektierbar sein. Wurde ein 3D-Bean in der Liste oder der virtuellen Szene ausgewählt, müssen die Attribute angezeigt und dem Anwender die Möglichkeit gegeben werden, diese zu verändern. Außerdem sollten weitere Informationen über das Bean gegeben werden, wie zum Beispiel der Typ und der geometrische Name. Hat der Editor Zugriff auf die logische Szenariobeschreibung, kann für die Eingabe des symbolischen Namens auf eine dem Typ entsprechende Auswahl vorhandener Namen zurückgegriffen werden (also etwa eine Liste von Pfadnamen für ein Pfad-Objekt). Schließlich soll eine getätigte Eingabe über eine Undo-Funktion wieder rückgängig gemacht werden können.

Bild 4.6: Layout für die graphische Oberfläche des Editors Über die Farben oder die Verwendung von Meta-Ikonen (Vergleiche Kapitel 2.2.1.3) kann in der Auswahlliste kenntlich gemacht werden, welchen Objekten schon symbolische Namen zugewiesen wurden. Für die Verwendung von Farben bietet sich die Ampelmetapher an [Posw96], das heißt Objekte, die mit roter Schrift repräsentiert werden, besitzen noch keinen Namen, Objekte mit grüner Schrift dagegen schon. Da ein symbolischer Name innerhalb eines Szenarios eindeutig sein muß, sollte der Anwender außerdem mit einer Fehlermeldung benachrichtigt werden, wenn er versucht, einen vorhandenen Namen für eine weiteres Objekt zu benutzen. Auch

VR-Fenster

Auswahlliste mit Ikonen und Farbcodierungen

Bearbeitungsfenster mit Liste gültiger symbolischer Namen

NAME_1

Selektierbar

SymbolischerName

PATH_1

DOOR_1

AP_2

OBJ_3Informationsfenster

Name: DOOR_1 Typ: Switch


72

andere, nicht sinnvolle Eingaben sollten verhindert werde, so könnte es zum Beispiel nicht möglich sein, einen Pfad selektierbar zu machen. Analog zum VR-System sollten allgemeine Statusmeldungen in einem Informationsfenster angezeigt werden. In Bild 4.6 ist die mögliche Komposition der graphischen Oberfläche skizziert.

73

5 Implementierung In diesem Kapitel soll beschrieben werden, wie die eben entworfenen Konzepte bei der Implementierung des VR-System und des Editors umgesetzt wurden. Kapitel 5.1 beschreibt die wichtigsten der verwendeten Java-Klassen und wie diese miteinander in Zusammenhang stehen. Kapitel 5.2 erläutert, welche Schwierigkeiten bei der Programmierung auftraten, ob und wie diese gelöst wurden und wie sich diese Änderungen auf das System ausgewirkt haben. Kapitel 5.3 schließlich beschreibt, wie die erstellten Anwendungen zu bedienen sind und welche Funktionen dem Anwender zur Verfügung stehen.

5.1 Programmstruktur Da das System auf die Verwendung, Manipulation und Darstellung von dreidimensionalen Beans aufbaut, soll zunächst beschrieben werden, wie diese implementiert wurden und welche verschiedenen Typen existieren. Danach wird auf das VR-System und den Editor genauer eingegangen.

5.1.1 Implementierung der 3D-Beans Ein für ETOILE benutztes 3D-Bean sollte die für das VR-System benötigten Attribute besitzen und weiterhin mit der dreidimensionalen Beanbox kompatibel sein. Zusätzlich soll es ein gültiges JavaBean darstellen, also die in Kapitel 2.1.1.3 vorgestellten Namenskonventionen erfüllen. Um die Bereitstellung der nötigen Attribute, beziehungsweise die Implementierung der entsprechenden get- und set-Methoden zu sichern, wäre es möglich, ein Interface zu definieren, das diese deklariert. Das hieße aber, daß ein ETOILE-Bean einerseits die Klasse BranchGroup (zur Darstellung in der Beanbox) erweitern und zusätzlich noch dieses Interface implementieren muß. Da für das Bean sowieso schon die Erweiterung einer bestimmten Klasse gefordert wird, erschien es deshalb sinnvoll, statt eines Interface eine abstrakte Klasse zu verwenden. Diese Klasse EtBean3D kann ebenso wie ein Interface die benötigten Methoden spezifizieren und erbt zusätzlich von der Klasse BranchGroup. Damit braucht ein 3D-Bean, das für ETOILE verwendet werden soll, nur noch diese eine Klasse zu erweitern. Ein weiterer Vorteil der Verwendung einer abstrakten Klasse besteht darin, daß sie nicht vollständig abstrakt sein muß. Methoden, die voraussichtlich für alle Beans in der gleichen Art umgesetzt werden würden, können schon hier implementiert werden. Bei Bedarf ist es natürlich möglich, daß ein Bean eigene Implementierungen für sämtliche Methoden enthält, so daß die abstrakte Klasse auch als reine Schnittstellenbeschreibung aufgefaßt werden kann.

Kapitel 5: Implementierung

74

5.1.1.1 Klassenstruktur Wie in Kapitel 4.1 beschrieben, existieren verschiedene Typen von 3D-Beans, die jeweils durch eine entsprechende Klasse repräsentiert werden. Bild 5.1 gibt einen Überblick über den Vererbungsbaum der Klassen (vergleiche auch mit Bild 4.2 in Kapitel 4.1)

Bild 5.1 Vererbungsstruktur der ETOILE-Beans Wie schon vorher erwähnt, können die Beans in weitere Gruppen eingeteilt werden. Entsprechend existieren weitere abstrakte Klassen, welche die für die jeweilige Gruppe spezifischen Methoden deklarieren und teilweise schon implementieren. Die beiden Hauptgruppen sind dabei die sichtbaren Objekte, die alle die Klasse EtVrVisibleObject erweitern und die nicht sichtbaren Beans, welche von EtVrPositionMarker erben. Im Folgenden sollen nun die einzelnen 3D-Beans, die für den Einsatz mit ETOILE realisiert wurden, genauer beschrieben werden.

5.1.1.2 Die Klasse EtBean3D Wie oben schon ausgeführt, ist EtBean3D eine abstrakte Klasse, die alle in ETOILE verwendeten 3D-Beans erweitern müssen. Sie erbt von der Klasse BranchGroup, das

BranchGroup

EtVrPositionMarker

EtBean3D

EtVrPlace EtVrObject EtVrSwitch

EtVrScenario

EtVrActionPoint EtVrLabeledArea

EtVrPath

EtVrSwitchAnimation

EtVrAnimation

EtVrVisibleObject

Abstrakte Klasse Klasse

EtVrBeanboxObject

5.1 Programmstruktur

75

heißt sie kann in einen Java3D-Szenengraphen eingehängt werden und Objekte zur Beschreibung von Geometrie und Verhalten enthalten. Diese Klasse definiert die get- und set-Methoden der in 4.1 beschriebenen Attribute, die allen 3D-Beans gemeinsam sind. (Im folgenden beschränken wir uns bei der Beschreibung von get- , is- oder set-Methoden, auf jeweils eine Methode des Paares. Wenn nicht ausdrücklich angeführt, kann von der Existenz des entsprechenden Gegenstücks ausgegangen werden.) Die Methoden getName() und getGeometricName() liefern jeweils den symbolischen oder den geometrischen Namen des Beans zurück. Die Position und Orientierung eines Beans wird über die übergeordnete TransformGroup verändert. Der Zugriff auf diese ist mit getTransformGroup() möglich. Falls das geometrische Modell dieses Beans sich nicht innerhalb der aktuellen Modelldatenbank befindet, erhält man mit der Methode getLink() schließlich Zugriff auf den Namen der Geometriedatei, die den Szenengraphen mit dem Objekt enthält. Diese Methoden wurden alle schon innerhalb der abstrakten Klasse implementiert. Anders verhält es sich mit den Methoden isDynamic() und isSelectable(), welche die Attribute dynamisch und selektierbar festlegen, da sich diese abhängig vom Typ des Beans unterschiedlich verhalten. Ein Aktionspunkt zum Beispiel kann niemals selektierbar oder dynamisch sein, also liefern dessen Methoden immer den Wert false zurück. Aus diesem Grund existieren in EtBean3D auch keine set-Methoden für diese Werte. Eine weitere abstrakte Methode ist getState(), mit welcher der durch die Attribute definierte Zustand (enthalten in einem EtVrBeanState-Objekt) mit einer einzigen Operation ausgelesen werden kann. Diese Methode kann zum Beispiel dazu benutzt werden, den Zustand einer aus Beans bestehenden Szene zu sichern und später wieder herzustellen, ohne diese serialisieren zu müssen. Trotzdem soll es außerdem möglich sein, das gesamte Bean in binärer Form sichern zu können, darum implementiert EtBean3D ebenfalls das Interface Serializable. Durch diesen Mechanismus lassen sich allerdings wiederum nur die Attribute des Beans speichern, da Java3D das Serialisieren des Szenengraphen noch nicht unterstützt (siehe auch Kapitel 5.2).

5.1.1.3 Die Klasse EtVrScenario Das Bean EtVrScenario ist ein Spezialfall und keiner der beiden Hauptgruppen zugeordnet. Es dient als ein Container, der alle anderen Beans der Szene enthält. Innerhalb der Klasse werden diese als Array von EtBean3D verwaltet, auf das mit der Methode getBeans() zugegriffen werden kann. Mit addBean() und removeBean() können einzelne Beans hinzugefügt oder entfernt werden. Außerdem verwaltet die Klasse eine Liste von Dateinamen. Diese verweisen auf externe Ressourcen, die für die Darstellung der Beans erforderlich sind. Dabei kann es sich zum Beispiel um Geometriedateien oder Bilder handeln. Diese Informationen werden später benötigt, um die Beans wieder rekonstruieren zu können. Mit getResourcePath() kann auf den Namen des Verzeichnisses zugegriffen werden, das


76

die Ressourcen enthält, getResources() liefert die Dateinamen. Mit addResouce() und removeResource() kann die Liste entsprechend erweitert oder verkürzt werden. Die Verwaltung der Szene innerhalb dieses Beans ist deshalb von Vorteil, da die Serialisierung von Klassen rekursiv verläuft, das heißt es reicht aus, diese eine Klasse zu serialisieren, um die gesamte Szene zu sichern. Da EtVrScenario als Erweiterung von BranchGroup die Wurzel des Szenengraphen darstellt, der die 3D-Beans enthält, braucht auch nur diese Klasse in den Szenengraphen einer Applikation gehängt werden, um das Szenario darzustellen. Für eine Trainingssitzung mit dem ETOILE-System kann immer nur ein einziges EtVrScenario-Objekt existieren. Wird ein Szenengraph mit mehreren dieser Beans geladen, ist das erste, das gefunden wurde, für die Verwaltung der Szene verantwortlich. Alle Beans der anderen Szenario-Objekte werden dort entfernt und diesem hinzugefügt.

5.1.1.4 Die Klassen der sichtbaren Beans Sichtbare 3D-Beans sind alle Objekte, die eine geometrische Repräsentation in Form eines Java3D-Szenengraphen enthalten, die während einer Trainingssitzung von ETOILE sichtbar ist. Mit diesen Objekten können die Teilnehmer während des Trainings interagieren. Folgende Klassen existieren für die Darstellung von sichtbaren 3D-Beans: EtVrVisibleObject Diese abstrakte Klasse definiert die gemeinsamen Eigenschaften der sichtbaren Objekte. Da diese Objekte dynamisch beziehungsweise selektierbar sein können, werden hier auch die Methoden setDynamic() und setSelectable() implementiert. Eine weitere Eigenschaft eines 3D-Objektes ist die Position. Diese Information kann zwar über die zugehörige TransformGroup ermittelt werden, da sie aber häufiger abgefragt werden wird, existiert auch eine Methode getPosition(), die diese Aufgabe übernimmt. Die Objektgeometrie wird in Form eines Java3D-Szenengraphen direkt mit der von BranchGroup übernommenen Methode addChild() eingefügt. Um eine mögliche Kollisionserkennung zu unterstützen, kann diese Eigenschaft mit der Methode setIntersectionEnable() ein- oder ausgeschaltet werden. Wird die Methode das erste Mal aufgerufen, werden Referenzen auf alle Shape3D-Objekte, die der Szenengraph enthält, in einem Vector gespeichert. Danach kann mit der Methode intersect() geprüft werden, ob das Objekt sich mit einem gegebenen Bereich schneidet. Es ist allerdings noch nicht möglich, die Kollision zweier verschiedener Objekte zu erkennen. EtVrObject Dieses Bean stellt ein einfaches, statisches dreidimensionales Objekt dar. Es besitzt kein dynamisches Verhalten, das von ETOILE-Base gesteuert werden kann. Es ist aber trotzdem möglich, daß der Szenengraph, der die Objektgeometrie beinhaltet, eigene Behavior-Knoten enthält, die ein autonomes Verhalten definieren. Dies kann zum Beispiel nützlich sein, um selbstablaufende Animationen zu implementieren, die


77

den Ablauf des Trainings aber nicht beeinflussen und umgekehrt auch nicht von ETOILE-Base direkt kontrolliert werden. EtVrBeanboxObject Dieses Bean wurde für die Verwendung mit der dreidimensionalen Beanbox entwickelt. Ein Bean, das mit der Beanbox erstellt oder angezeigt wird, kann in dieser Form für gewöhnlich noch nicht in ETOILE benutzt werden, da die Attribute von EtBean3D fehlen, also der geometrische Name, der symbolische Name, der Verweis auf die TransformGroup und die Angabe, ob das Objekt selektierbar beziehungsweise dynamisch ist. Ein EtVrBeanboxObject besitzt diese Attribute und kann nun als Container für ein beliebiges 3D-Bean benutzt werden. Dafür wird erst das EtVrBeanboxObject in die Beanbox eingefügt, danach kann das gewünschte 3D-Bean unterhalb dieses Beans angefügt werden. Beim Einlesen in ETOILE wird das Container-Bean nun als visuelles Bean erkannt, dessen Szenengraph die Geometrie des Beans aus der Beanbox enthält. Der Vorteil dieser Implementierung ist, daß es nicht nötig war, die Beanbox anzupassen, um normale 3D-Beans in ETOILE-Beans umzuwandeln. Die angebotene Funktionalität liegt allein bei der Komponente, das heißt es ist unabhängig vom verwendeten Editor möglich, 3D-Objekte für die Verwendung in ETOILE anzupassen, solange dieser die Struktur der 3D-Beans entsprechend unterstützt. Der Nachteil dieses Ansatzes ist allerdings, daß durch die Notwendigkeit, einen Container zu verwenden, der Autorenprozeß weniger intuitiv wird.

Bild 5.2: 3D-Objekt innerhalb eines EtVrBeanboxObject


78

Innerhalb der Beanbox wird die Position des EtVrBeanboxObject durch eine transparente Sphäre markiert, diese kann mit setVisible() ein- oder ausgeschaltet werden (Siehe Bild 5.2). EtVrSwitch Dieses Objekt implementiert einen Switch, das heißt das Objekt enthält mehrere Geometrien, von denen wahlweise eine dargestellt wird. Intern wird dazu ein Switch-Knoten von Java3D benutzt, der an dieses Objekt angehängt wurde. Mit den Methoden addNode() und removeNode() können Knoten oder Szenengraphen zu der Menge der Geometrien hinzugefügt oder daraus entfernt werden. Es ist möglich, mit setNames() den einzelnen Kindknoten Namen zuzuweisen. Mit der Methode setCurrentNode() kann dann über einen Namen oder Index der darzustellende Knoten ausgewählt werden. Wie bei allen visuellen Objekten kann über addChild() zusätzlich Geometrie angefügt werden, die unabhängig von der Wahl des darzustellenden Knotens sichtbar ist, da das Bean immer noch eine BranchGroup darstellt. Aus diesem Grund muß eine Animation (siehe unten) oder ein Switch innerhalb eines Objektes auch nicht mehr über ein Link-Attribut referenziert werden. Beim Einladen eines solchen Objektes wird der Switch beziehungsweise die Animation erkannt und entsprechend ein EtVrSwitch oder EtVrAnimation erzeugt, wobei die statische Geometrie direkt an die BranchGroup angehängt wird. Der Nachteil dieser Realisierung ist, daß ein solches Objekt nur genau eine Animation oder Switch enthalten kann. Es ist jedoch möglich, daß ein visuelles Bean beliebig viele EtVrSwitch- oder EtVrAnimation-Objekte als Kinder hat, die dann wieder einzeln angesprochen werden können. EtVrAnimation Diese abstrakte Klasse definiert die Methoden, die ein animierbares Objekt implementieren muß. Diese erlauben es, die Animation zu starten oder anzuhalten und den Knoten zu definieren, der dargestellt werden soll, wenn die Animation nicht ausgeführt wird. Jedes EtVrAnimation-Objekt kann nur eine Animation enthalten. Für die zeitliche Steuerung der Animation kann ein Alpha-Objekt spezifiziert werden. Dabei handelt es sich um eine Java3D-Klasse, die eine Funktion über die Zeit darstellt und mit deren Hilfe unter anderem die Geschwindigkeit kontrolliert werden kann, mit der die Animation abläuft. EtVrSwitchAnimation Dieses Bean erweitert EtVrAnimation und implementiert eine Animation mit Hilfe eines Switch-Knoten, dessen Kindknoten nacheinander dargestellt werden. Dazu wird ein Java-Thread benutzt, der die Interpolation ausführt und durch ein Alpha-Objekt gesteuert werden kann. Ähnlich wie bei EtVrSwitch können über zwei Methoden addFrame() und removeFrame() Objekte hinzugefügt oder entfernt werden. Diese hinzugefügten


79

Subgraphen stellen dann die einzelnen "Bilder" der Animation dar, das heißt nach dem Start werden diese nacheinander angezeigt.

5.1.1.5 Die Klassen der nicht sichtbaren Beans Die Beans, die während eines ETOILE-Trainings nicht sichtbar sind, beinhalten Informationen über bestimmte Positionen innerhalb der Szene, die für das Trainingsszenario relevant sind. Dies kann ein Bereich, ein Weg oder ein einzelner Punkt in der Szene sein. Hier sollen nun die diesen Typen entsprechenden Beans beschrieben werden. EtVrPositionMarker In dieser abstrakten Klasse wird eine gemeinsame Eigenschaft der positionsbeschreibenden Beans festgelegt. Obwohl diese Objekte in ETOILE nicht dargestellt werden, ist es manchmal wünschenswert, sie durch ein geometrisches Objekt zu repräsentieren, etwa zur Bearbeitung in einem Editor.

Bild 5.3: Szene mit visualisierten Pfaden, Regionen und Aktionspunkten Mit der Methode setRepresentation() kann nun zu diesem Zweck eine Geometrie angegeben werden. Alternativ ist es möglich, festzulegen, daß eine geeignete Repräsentation automatisch auf Grund der Daten des Objekts erstellt werden soll, zum Beispiel eine Sphäre für einen Aktionspunkt oder ein Linienzug für einen Pfad.


80

Ändern sich die Eigenschaften des Objektes, wie zum Beispiel durch Angabe anderer Punkte für einen Pfad, wird diese Darstellung erneut berechnet. Bild 5.3 zeigt eine Szene, in der die Aktionspunkte, Regionen und Pfade entsprechend visualisiert sind. EtVrPlace Diese Klasse gruppiert die Beans EtVrActionPoint und EtVrLabeledArea und spezifiziert eine Methode, die eine diese Objekte umgebende Region angibt. Im Fall des Aktionspunktes ist dies eine Sphäre, die den Punkt umgibt. Dies ermöglicht es, auch für den Punkt zu testen, ob sich ein bestimmtes Objekt in relativer Nähe befindet. EtVrLabeledArea Dieses Bean definiert eine Region im Raum, die in Form einer BoundingBox ausgegeben wird. Zu diesem Zeitpunkt dient das Objekt nur zur Beschreibung der Region, für spätere Implementierungen ist es denkbar, daß sie auch aktiv das Eintreten oder Verlassen von anderen Beans registrieren kann. Die Region kann als transparenter Quader visualisiert werden. EtVrActionPoint Ein Aktionspunkt definiert einen beliebigen Punkt im Raum, dessen Position verändert und abgefragt werden kann. Als Repräsentation dient eine transparente Sphäre. Anders als bei EtVrLabeledArea kann die umgebende Region (die in Form einer BoundingSphere vorliegt) nicht verändert werden. EtVrPath Durch dieses Bean wird ein Pfad innerhalb der Szene bestimmt. Diesen Pfad entlang kann nun ein beliebiges 3D-Bean oder ein anderes Java3D-Objekt, welches sich unterhalb einer TransformGroup befindet, mit einer bestimmten Geschwindigkeit bewegt werden. Der Pfad wird durch ein Array von Raumpunkten definiert, das mit getPath() abgefragt werden kann. Visualisiert wird er durch einen Linienzug, der die einzelnen Punkte miteinander verbindet. Zusätzlich bietet das Bean aber auch noch die Funktionalität, ein Objekt entlang des Pfades zu bewegen und ein Event bei Beendigung des Weges auszulösen. Um die Bewegung anzupassen, ist es möglich, die Geschwindigkeit (in m/s) anzugeben, mit der sich das Objekt bewegen soll. Alternativ kann auch die gewünschte Gesamtdauer der Interpolation spezifiziert werden. Des weiteren läßt sich festlegen, ob der Pfad vom ersten bis zum letzen Punkt durchlaufen werden soll, oder in der entgegengesetzten Richtung. Um das gewünschte Objekt bewegen zu können, muß schließlich noch die TransformGroup angegeben werden, die dieses enthält, sowie ein Name, der in der Nachricht am Ende der Interpolation (siehe unten) enthalten sein wird. Die Bewegung des Objektes ist als stückweise lineare Interpolation implementiert. Um die Performanz zu verbessern, werden die benötigten Werte für die Interpolation


81

berechnet, sobald die nötigen Parameter (Pfadverlauf und Geschwindigkeit) eingegeben wurden. Zuerst wird die Länge der einzelnen Segmente sowie die Gesamtlänge des Pfades ermittelt. Anhand der Geschwindigkeit oder der Bewegungsdauer wird berechnet, zu welchen Zeitpunkten sich das Objekt auf welchem Segment befinden muß. Die Endpunkte der Segmente liefern den Vektor der die Orientierung des Objektes auf diesem Segment festlegt. Diese Werte werden für beide Richtungen, in der der Pfad durchlaufen werden kann, berechnet. Eine Interpolation wird innerhalb eines Threads realisiert, so daß es möglich ist, mehrere Bewegungen hintereinander entlang des gleichen Pfades durchzuführen. Der Thread durchläuft eine Iterationsschleife, bis der Zeitpunkt überschritten ist, an dem das Ende des Pfades erreicht wird. Während der Iteration wird durch Vergleichen des aktuellen Zeitpunkts mit den gespeicherten Zeiten das korrekte Wegsegment und der zugehörige Orientierungsvektor ermittelt und durch lineare Interpolation die Position bestimmt. Diese Aktualisierung geschieht bei jedem Schleifendurchlauf. Wurde die Interpolation beendet, sendet das Bean ein InterpolationEvent, daß den Namen des bewegten Objektes enthält. Gemäß der JavaBean-Konventionen können sich andere Beans mit addInterpolationListener() als Empfänger registrieren. Die Angabe des Zielobjektes durch eine TransformGroup und eines Namens anstelle eines EtBean3D-Objektes wurde gewählt, um auch allgemeinere Objekte bewegen zu können, einschließlich der ViewPlatform, die den Blickpunkt des Betrachters bestimmt.

5.1.2 Implementierung des VR-Systems Das VR-System setzt sich ebenfalls aus mehreren JavaBeans zusammen, die jeweils einen bestimmten Aufgabenbereich abdecken. Das Ziel war es, die Komponenten so zu implementieren, daß sie auch in anderen Applikationen für gleiche oder ähnliche Aufgaben wiederverwendet werden können. Zunächst soll ein Überblick über die verwendeten Klassen und ihr Zusammenspiel gegeben werden, danach werden die wichtigsten Komponenten genauer beschrieben.

5.1.2.1 Klassenstruktur Bild 5.4 zeigt die Zusammenhänge zwischen den einzelnen JavaBeans des Systems (vergleiche auch Bild 4.3 in Kapitel 4.2.2). Die Pfeile repräsentieren dabei den Datenaustausch zwischen den Komponenten. Die Klassen EtVrScenarioHandler und EtVrGeometryLoader sind dafür zuständig, ein gespeichertes Szenario für die Benutzung mit ETOILE einzulesen. Letztere ist dabei für das Importieren von externen Dateien verantwortlich, die Geometriedaten enthalten.


82

Bild 5.4: Klassenstruktur des VR-Systems EtVrVisualization übernimmt die Darstellung der Szene und erlaubt es dem Anwender, darin zu navigieren. Mithilfe von EtVrCollisionDetector wird die Kollisionserkennung behandelt, EtVrSelectionFeedback markiert das aktuell selektierte Objekt. EtVrCommunication übernimmt die Kommunikation mit ETOILE-Base. Für die Auswertung und die Erzeugung von Nachrichten ist die Kontrollklasse EtVrControl zuständig. Sie wählt für den Benutzer entsprechend seiner Rolle (Teilnehmer oder Trainer) die passende graphische Oberfläche aus, die in der Klasse EtVrLearnerGui beziehungsweise EtVrTrainerGui implementiert ist. Die Verwaltung der 3D-Beans erfolgt durch EtVrObjectManager.

5.1.2.2 Die Dateiverwaltung Das Interface EtVrScenarioHandler definiert Methoden, um ein in einer Datei gesichertes dreidimensionales Szenario einzulesen und in ein entsprechendes

EtVrGeometryLoader EtVrScenarioHandler

EtVrControl

EtVrLearnerGui

EtVrTrainerGui

EtVrVisualization

EtVrCommunication

EtVrSelectionFeedback

EtVrObjectManager

ETOILE-Base

EtVrCollisionDetector


83

EtVrScenario umzuwandeln. Ebenso läßt sich ein vorliegendes Szenario wieder in Form einer oder mehrerer Dateien auf der Festplatte sichern. Für das hier entwickelte System wurden zwei Implementierungen dieser Schnittstelle realisiert: EtVrMapHandler und EtVrJarHandler. Für die Umwandlung der Dateien, welche die Geometrien der Szene enthalten, in 3D-Beans ist das Interface EtVrGeometryLoader zuständig. Dieses wird von der Klasse EtVrFltLoader implementiert, welche die im OpenFLT-Format vorliegenden Modelle einlesen kann. EtVrFltLoader Zum Einlesen der Geometriedateien wird der OpenFLT-Loader von Full Sail [Full00] in der Version 0.9.6 beta verwendet. Damit kann eine OpenFlight-Datei geöffnet und das enthaltene Modell als Java3D-Szenengraph ausgegeben werden. Durch die Verwendung von erweiterten Klassen für die speziellen OpenFlight-Gruppenknoten, bleiben dabei Namen und Typen der vorhandenen Gruppenknoten erhalten. Für die Knoten Group, Object und Switch stellt der OpenFLT-Loader die Klassen FLTgroup, FLTobject und FLTswitch zur Verfügung, die alle die Klasse BranchGroup erweitern, und zusätzlich noch die Namen der OpenFlight-Knoten enthalten. Dies ist wichtig, da der Typ eines Objektes in ETOILE nicht allein aus dem Typ des Knotens in der OpenFlight-Datei, der die Geometrie enthält, hervorgeht. Die Namen der Gruppen- und Objektknoten der OpenFlight-Datei werden deshalb dafür benutzt, um die Art der Objekte festzulegen, zu denen die untergeordneten Geometrien gehören. Ein Szenengraph einer statische Szene, die mit EtVrFltLoader eingelesen werden soll, muß die in Bild 5.5 dargestellte Struktur besitzen (vergleiche auch Bild 3.3 in Kapitel 3.3.2).

Bild 5.5: Benötigte Datenbankstruktur der statischen Szene Der vorliegende Szenengraph wird dabei traversiert, bis ein Knoten mit einem bestimmten Namen beziehungsweise Typ gefunden wurde. Die Knoten unterhalb des Gruppenknotens "AP" werden als Aktionspunkte aufgefaßt. Jeder einzelne Aktionspunkt ist noch mal in einem weiteren Gruppenknoten enthalten, dessen Name als geometrischer Name des Beans verwendet wird. Von der enthaltenen Geometrie wird der Mittelpunkt berechnet, der dann die Koordinaten des Aktionspunktes bestimmt.

Datenbank

Geometrie AP LA PP


84

Analog werden Regionen ermittelt, die unter dem Knoten "LA" liegen müssen, hier wird die Bounding-Box verwendet, die die Geometrie umschließt. Für die Pfade, die unter dem Knoten "PP" liegen, werden die Eckpunkte des vorgefundenen Geometrieobjektes benutzt, um einen Weg innerhalb der Szene zu definieren. Geometrieobjekte, die unterhalb eines Objekt-Knoten liegen, werden zu einem EtVrObject, der Name des Knotens wird wieder zum geometrischen Namen des Beans. Animationen und Switches werden beide mit einem Switch-Knoten realisiert. Beginnt dessen Name mit "ani", wird von einer Animation ausgegangen, ansonsten von einem Switch. Bei einem Switch werden die Namen der Kindknoten als Namen für die möglichen Zustände benutzt. Die hier benutzte Struktur und Namenskonvention entspricht größtenteils derjenigen, die in [StWe00] benutzt wurde, hinzugekommen ist die Möglichkeit, auch Pfade in der Geometriedatenbank zu definieren. Wird eine OpenFlight-Datei mit loadDatabase() geladen, liefert die Klasse ein EtVrScenario-Objekt zurück, das die dort definierten Objekte in Form von mehreren 3D-Beans enthält. Es gibt aber auch die Möglichkeit, einzelne Objekte mit loadObject() zu laden, die in separaten OpenFlight-Dateien definiert wurden. Dies kann zum Beispiel der Fall sein für dynamischen Objekte, die in der statischen Szene bewegt werden sollen. In diesem Fall wird aus der Datei nur ein einziges Bean erzeugt. Enthält die Datei eine Animation oder einen Switch, wird eine EtVrSwitchAnimation beziehungsweise EtVrSwitch zurückgeliefert, ansonsten ein EtVrObject. EtVrMapHandler EtVrMapHandler benutzt zur Speicherung der Szene die Methode des ursprünglichen Systems. Eine Mapping-Table enthält die Attribute der Objekte sowie Verweise auf die Dateien, welche die entsprechenden Geometrien enthalten. Dieses Format wurde vor allem unterstützt, um schon vorhandene Szenarien auch mit dem neuen VR-System benutzen zu können. Die Einträge der Mapping-Table entsprechen größtenteils dem in Kapitel 3.3.3 vorgestellten Format. Ein Unterschied betrifft die Verwendung von Animationen und Switch-Knoten. In der ursprünglichen Version wurde das Objekt, welches die Animation enthielt als Typ "obj" mit dem Attribut "ani" definiert. Danach wurde der Knoten innerhalb dieses Objektes als Typ "objani" zusätzlich spezifiziert, mit einem Verweis auf die Datei, die das gesamte Objekt enthielt. In dem neuen System ist eine Animation immer in einem EtVrAnimation beziehungsweise EtVrSwitchAnimation-Bean enthalten, welches die nötigen Methoden zum Starten und Anhalten der Sequenz bereitstellt. Ebenso ist ein Switch auch immer Teil eines EtVrSwitch. Es reicht daher aus, diese Typen in der Mapping-Table mit "objani" und "objsw" zu kennzeichnen, das Attribut "ani" wird beim Einlesen ignoriert.


85

Ein weiterer Unterschied ist die Möglichkeit, Aktionspunkte jetzt vollständig in der Mapping-Table zu definieren, statt des geometrischen Namen können auch drei Zahlen, welche die Position des Punktes spezifizieren, angegeben werden. Soll ein Szenario geladen werden, wird aus der Mapping-Table der Name der Datei ermittelt, welche die Geometrie enthält und diese mit einem EtVrGeometryLoader geladen und in ein EtVrScenario umgewandelt. Den darin enthaltenen Beans werden dann die Attribute aus der Mapping-Table zugewiesen. Im umgekehrten Fall werden aus den Attributen der Beans wieder die entsprechenden Einträge der Mapping-Table generiert. EtVrJarHandler Die bevorzugte Methode, eine aus 3D-Beans bestehende Szene zu sichern, ist innerhalb einer JAR-Datei, dies unterstützt die Klasse EtVrJarHandler. Soll ein Szenario gespeichert werden, wird das vorliegende EtVrScenario serialisiert, und dem Archiv hinzugefügt. Da die Serialisierung rekursiv erfolgt, sind damit alle Eigenschaften der vorhandenen Beans gesichert, mit Ausnahme der Geometrien der sichtbaren Objekte. Das bedeutet auch, daß es zur Zeit nur möglich ist, ein komplettes Szenario zu speichern und wieder einzulesen. Damit auch die Geometrien wiederhergestellt werden können, müssen die entsprechenden Geometriedateien ebenfalls dem Archiv hinzufügt werden. Welche dies sind, kann in EtVrScenario mit getResources() abgefragt werden. Um die Beans in einem anderen System auch erzeugen zu können, müssen ebenfalls alle benutzten Klassen vorhanden sein, die nicht Teil von Java oder Java3D sind, also unter anderem auch alle Klassen der 3D-Beans. Die Rekonstruktion übernimmt die spezielle Klasse EtoileBean, die ebenfalls im Archiv vorhanden sein muß. Diese versucht bei ihrer Erzeugung, ein vorhandenes EtVrScenario zu deserialisieren und die Geometrie mit dem EtVrGeometryLoader zu rekonstruieren. Die Benutzung dieser Klasse ist nötig, um ein Szenario auch in der Beanbox anzeigen zu können (siehe auch Kapitel 5.2). Sie wird in der Manifest-Datei des JAR als JavaBean gekennzeichnet, um beim Ladevorgang als die zu erzeugende Klasse erkannt werden zu können. Wird ein Szenario aus einem JAR mit dem Handler eingeladen, wird versucht, die erste Klasse, die in der Manifest-Datei als Bean gekennzeichnet ist, zu erzeugen. Handelt es sich bei der Klasse um einen Gruppenknoten, wird der vermeintliche Szenengraph, dessen Wurzel dieser darstellt, nach einem EtVrScenario durchsucht. Wurde dies gefunden, wird in dem restlichen Graph nach weiteren EtBean3D-Objekten gesucht, die dann dem Szenario als weitere 3D-Beans noch hinzugefügt werden.

5.1.2.3 Die Klassen für die Visualisierung und Navigation Die Klasse EtVrVisualization ist für die Darstellung der Szene in einem Canvas3D verantwortlich. Zusätzlich bietet sie noch zwei Navigationsparadigmen zur Auswahl


86

an, mit denen die Szene betrachtet werden kann. Beide sind über Behavior-Klassen realisiert. Für Scene-in-Hand werden die von Java3D bereitgestellten Mouse-Behaviors benutzt, mit denen die Szene rotiert und verschoben werden kann. Für Eyeball-in-Hand wird die Klasse EtVrNavigationBehavior verwendet. Hierbei kann bei gedrückt gehaltener rechter Maustaste der Blickpunkt durch die Mausbewegung verändert werden, die Pfeiltasten der Tastatur erlauben die Bewegung in oder entgegengesetzt der aktuellen Blickrichtung. Es ist außerdem möglich, eine Kollisionserkennung einzuschalten (siehe 5.1.2.5). Bei jeder Veränderung der Position wird zudem ein NavigationEvent ausgelöst, das zur Synchronisation mit anderen VR-Systemen an die Kommunikationskomponente geschickt wird. Um die Anzahl der Synchronisationsnachrichten zu reduzieren, wird jedoch nur jede zweite Nachricht versendet. Weitere Benutzerinteraktionen werden ebenfalls von EtVrVisualization durch Behavior-Knoten registriert und in Form von Ereignissen weitergeleitet. EtVrSelectionBehavior registriert Mausklicks mit der linken Maustaste und erzeugt ein SelectionEvent, welches das gewählte Objekt enthält. Zur Ermittlung des entsprechenden Objektes wird die Hilfsklasse PickObject verwendet, die von Java3D zur Verfügung gestellt wird. Um das Eintreten oder Verlassen einer Region zu erkennen, ist für jede EtVrLabeledArea ein EtVrAreaDetectionBehavior vorhanden, das ein entsprechendes Ereignis erzeugt. Dieses Behavior ist nur aktiv, wenn die Navigation per Eyeball-in-Hand durchgeführt wird.

5.1.2.4 Das Interface EtVrSelectionFeedback Klassen, die das Interface EtVrSelectionFeedback implementieren, können dazu benutzt werden, unabhängig von ETOILE-Base auf Selektionen von Objekten zu reagieren. Die Klasse EtVrSelectionHighlight markiert zum Beispiel das gewählte Objekt, indem es dessen Farbe ändert. EtVrSelectionFeedback implementiert SelectionListener, das heißt es ist möglich, SelectionEvents zu empfangen. Mit setSelection() kann ein Objekt aber auch direkt ausgewählt werden.

5.1.2.5 Die Klasse EtVrCollisionDetection EtVrCollisionDetection wird von der Navigationskomponente benutzt, um zu testen, ob der Betrachter auf einer bestimmten Position innerhalb der Szene mit einem Objekt kollidiert. Dieser Test wird jedesmal durchgeführt, wenn der Anwender sich in der virtuellen Szene bewegt, nicht jedoch bei einer Veränderung des Blickpunktes. Es ist allerdings noch nicht möglich, mit dieser Klasse Kollisionen zwischen einzelnen Beans zu bearbeiten. Für die Kollisionserkennung erzeugt die Klasse eine Bounding-Box, die an der gewünschten Stelle plaziert wird. Nun wird in zwei Schritten auf mögliche Kollisionen getestet. Zuerst wird die Bounding-Box mit den Bounds-Objekten aller 3D-Beans geschnitten und so die potentiellen Kandidaten für eine Kollision ermittelt. Danach werden die Geometrien der gefundenen Objekte mit der Bounding-Box geschnitten. Zu diesem Zweck wird aus der Box ein PickBounds-Objekt erzeugt. Mit


87

diesem ist es dann möglich, durch die Methode intersect() der Shape3D-Objekte, welche die Geometrie enthalten, einen eventuellen Schnitt zu erkennen. Sobald eine Überschneidung gefunden wird, signalisiert die Klasse eine Kollision.

5.1.2.6 Die Objektverwaltung EtVrObjectManager ist ein Interface, das Methoden zur Verwaltung der 3D-Beans einer Szene definiert. Der Zugriff kann auf verschiedene Arten erfolgen. Mit objectByName() wird das Bean mit dem angegebenen symbolischen Namen zurück geliefert. Die Methode objectsByAttribute() liefert eine Aufzählung aller Beans, die eine bestimmte Eigenschaft besitzen: dynamisch, selektierbar oder namenlos (diesen Beans wurde noch kein symbolischer Name zugewiesen). Mit objectsByType() kann analog auf alle Beans mit einem bestimmten Typ zugegriffen werden, also zum Beispiel Aktionspunkt, Pfad oder Animation. Die Klasse EtVrBeanManager implementiert das Interface und benutzt zur Verwaltung der Beans eine Hashtable. Durch die Bereitstellung eines Interface ist es möglich, für spätere Applikationen weitere Objektmanager zu implementieren, die andere Methoden zur Verwaltung der Objekte anwenden.

5.1.2.7 Die Klasse EtVrCommunication Zur Kommunikation mit ETOILE-Base wird die Klasse EtVrCommunication verwendet. Diese erweitert EtCommunication, die Kommunikationskomponente von ETOILE (siehe Kapitel 3.2), und bietet entsprechend Methoden an, um Nachrichten an andere Systeme zu schicken. Eine Klasse, die Nachrichten empfangen möchte, muß sich hier als EtCommunicationReceiveInterfaceListener registrieren (und natürlich das entsprechende Interface implementieren). Neben der Kommunikation mit dem ETOILE-System koordiniert diese Klasse auch den Informationsaustausch zur Synchronisation der Avatare der Teilnehmer. Verändert ein Teilnehmer seine Position, sendet das entsprechende EtVrNavigationBehavior ein NavigationEvent, das die neue Transformationsmatrix für den Avatar enthält. Diese Information muß nun effizient an alle VR-Systeme übermittelt werden, die über das Netzwerk mit der aktuellen Trainingssitzung verbunden sind. Die Synchronisation soll daher über einen Multicast erfolgen: die Kommunikationskomponenten der VR-Systeme, die mit derselben Trainingssitzung verbunden sind, gehören einer sogenannten Multicastgruppe an. Jede Nachricht, die an diese Gruppe adressiert ist, wird von allen Gruppenmitgliedern empfangen. Zur Realisierung der Synchronisation wurde das NCSA Portfolio [Ncsa00] in der Version 1.3 beta 3 benutzt. Dieses bietet Klassen zur Implementierung eines Multicast an. Zum Versenden der Nachrichten erzeugt die Kommunikationskomponente einen MulticastHandler, dieser erlaubt es, Informationen an die zugehörige Multicastgruppe


88

zu senden. Eine Synchronisationsnachricht enthält einen Zeitstempel, den Namen des Avatars und die Matrix, welche dessen Transformation enthält. Zum Empfangen dieser Informationen, muß eine Klasse das Interface Customer implementieren. Die hier benutzte Klasse EtVrPositionCustomer prüft bei einer neuen Nachricht zunächst, ob der enthaltene Zeitstempel neuer ist, als derjenige der letzen Änderung. Ist dies der Fall, wird die neue Transformation auf den entsprechenden Avatar angewendet. Bild 5.6 gibt noch einmal einen Überblick über die Kommunikationswege des Systems.

Bild 5.6: Kommunikation der VR-Systeme

5.1.2.8 Die Klasse EtVrControl Dies ist die zentrale Komponente des Systems. Sie ist hauptsächlich dafür verantwortlich, die Nachrichten von ETOILE-Base zu verarbeiten und die entsprechenden Aktionen auszuführen. Bei Eingang einer neuen Nachricht, werden das Schlüsselwort und die Parameter extrahiert. Ist der Befehl bekannt und ist für diesen die korrekte Anzahl von Parametern vorhanden, wird die Aktion ausgeführt. Die Anweisungen, die das System versteht, entsprechen der in Kapitel 3.3.4 beschriebenen Schnittstelle. Die zweite Aufgabe ist die Benachrichtigung des ETOILE-Systems über bestimmte Ereignisse. EtVrControl empfängt die Events, die bei Selektion eines Objektes,

VR-System 1

EtVrCommunication

EtVrPositionCustomer

ETOILE-Base

VR-System 2

VR-System n

Synchronisationsnachricht über Multicast

Nachricht über das ETOILE-Kommunikationssystem


89

Betreten oder Verlassen einer Region und Beendigung eines Pfades von den entsprechenden Komponenten ausgelöst wurden. Diese werden dann in Form einer Nachricht an ETOILE-Base weitergeleitet. Zum Empfangen von Nachrichten muß die Klasse das entsprechende Interface (EtCommunicationReceiveInterface) und die dort spezifizierte Methode receiveMessage() implementieren. Dort wird ein Thread aufgerufen, der die eigentliche Verarbeitung der Nachricht übernimmt. Dies ist nötig, um zu vermeiden, daß ein Fehler bei der Übermittlung einer Nachricht das gesamte System blockiert.

5.1.3 Implementierung des Editors Der Editor, der zum Bearbeiten der Attribute der 3D-Beans dienen soll, verwendet zum größten Teil Komponenten, aus denen sich auch das VR-System zusammensetzt. Die Struktur der Anwendung zeigt Bild 5.7 (vergleiche auch Bild 4.4. in Kapitel 4.2.2), die Pfeile stellen dabei wieder den Datenaustausch zwischen den Komponenten dar. Die zusätzliche Programmfunktionalität implementiert die Klasse EtVrMapper, die auch die graphische Oberfläche enthält.

Bild 5.7: Klassenstruktur des Editors Wie in 4.3.2 beschrieben, haben dynamische Objekte keine initiale Position in der statischen Szene. Die statische Szene und die dynamischen Objekte werden darum in separaten Bildschirmen präsentiert, es werden dafür zwei EtVrVisualization-Objekte verwendet. Diesmal wird zur Betrachtung der Szene die Scene-in-Hand-Metapher benutzt, daher ist auch EtVrCollisionDetector zur Kollisionserkennung nicht mehr nötig. EtVrSelectionFeedback dient wieder dazu, selektierte Beans zu markieren.

EtVrVisualization

EtVrSelectionFeedback

EtVrScenarioHandler EtVrGeometryLoader

EtVrMapper

EtVrObjectManager


90

Es ist möglich, vorhandene Szenarien einzulesen und später wieder zu sichern, ebenso kann für die Erstellung eines neuen Szenarios eine einzelne Geometriedatei geöffnet werden. Hierzu werden wieder ein EtVrScenarioHandler und ein EtVrGeometryLoader benötigt. Die Verwendung von EtVrMapHandler sowie EtVrJarHandler ermöglicht es, beide oben vorgestellte Formate zum Sichern der Szenen zu benutzen. Da der Editor eine eigenständige Applikation darstellt, gibt es keine Kommunika-tionskomponente.

5.2 Schwierigkeiten bei der Implementierung In diesem Kapitel soll auf die hauptsächlichen Probleme eingegangen werden, die während der Realisierung des oben vorgestellten Systems auftraten. Neben der Problembeschreibung wird auch der jeweils verwendete Lösungsweg beschrieben.

5.2.1 Serialisierung der 3D-Beans Ein Großteil der Probleme der Entwicklungsphase läßt betraf die Speicherung der verwendeten dreidimensionalen Beans. Da der Serialisierungsmechanismus von Java noch nicht von Java3D unterstützt wird, ist es nicht ohne weiteres möglich, einen Java3D-Szenengraphen in binärer Form zu sichern. Die Attribute, die in einem 3D-Bean enthalten sind, lassen sich dagegen problemlos serialisieren. Da die ursprünglichen Geometrien der Beans in separaten Dateien vorliegen, wurde nun entschieden, diese ebenfalls in das entsprechende JAR-Archiv aufzunehmen, damit auch diese Daten später wieder rekonstruiert werden können. Wenn das EtVrScenario-Bean serialisiert wird, werden alle enthaltenen Attribute gespeichert, einschließlich des geometrischen Namens. Ein spezielles Attribut database von EtVrScenario enthält den Namen der hauptsächlichen Datei, welche die Geometrie der statischen Szene definiert. Alle untergeordneten Beans besitzen als geometrischen Namen entweder den Namen des Subgraphen innerhalb der statischen Szene oder ebenfalls einen Dateinamen. Diese Informationen werden beim Einlesen der Beans benutzt, um das Szenario wieder herzustellen. Objekte, bei denen die geometrischen Daten nicht aus externen Quellen stammen und innerhalb des Programmcodes erzeugt werden, lassen sich vollständig serialisieren, dies trifft zum Beispiel auf alle in ETOILE nicht sichtbaren Objekte zu, wie Pfade, Regionen und Aktionspunkte. Voraussetzung dafür ist eine entsprechend implementierte Methode readObject()1, welche die Geometrie wieder aufbaut.

1 Diese Methode wird von Java automatisch während des Deserialisierungprozesses aufgerufen.

5.2 Schwierigkeiten bei der Implementierung

91

Um das Erstellen des Archivs zu beschleunigen, enthält EtVrScenario eine Liste der Namen aller in diesem Szenario verwendeten Dateien. Diese Informationen werden zum Beispiel beim Erstellen oder Ändern einer Szene mit dem Mapper hinzugefügt.

5.2.2 Verwendung der 3D-Beans in der Beanbox Der oben beschriebene Mechanismus zur Sicherung der 3D-Beans mußte nun noch so angepaßt werden, daß die verwendeten Beans auch in der dreidimensionalen Beanbox eingelesen, bearbeitet und zur weiteren Verwendung in ETOILE gespeichert werden konnten. Ein 3D-Bean wird zu dem Szenengraphen der Beanbox hinzugefügt, indem die Klasse, welche in der Manifest-Datei des JAR-Archives als Bean gekennzeichnet ist, mit Beans.instantiate() erzeugt wird. Diese Methode der Klasse Beans sucht zunächst nach einer serialisierten Form der Klasse (Klassenname mit Endung ".ser"), mit der diese dann wieder hergestellt wird. Einem auf diese Weise erzeugten EtVrScenario würden wieder die geometrischen Daten der externen Dateien fehlen. Es wäre möglich, die Methode readObject() dieser Klasse so zu implementieren, daß diese Dateien bei der Deserialisierung eingelesen und die Geometrien der Beans rekonstruiert werden. Dieser Ansatz erwies sich jedoch in Hinsicht auf den Sicherheitsmechanismus von Java als problematisch. Eine Klasse aus einem JAR-Archiv wird von Java generell als untrusted behandelt, also Programmcode, dem nicht vollständig vertraut wird. Falls nun das Archiv eine Klasse enthält, die in der aktuellen Umgebung schon vorhanden ist, wird ein Objekt mit dieser lokalen Klasse erzeugt, nicht mit der aus dem JAR. Soll nun also im ETOILE-System ein EtVrScenario aus einem JAR-Archiv instanziiert werden, wird statt dessen die Klasse verwendet, die als Teil des System im Klassenpfad enthalten ist. Diese hat aber im Gegensatz zu der Datei aus dem Archiv keinen Zugriff auf die ebenfalls im JAR vorliegenden Geometriedateien, so daß es nicht möglich ist, die Geometrien der Beans zu rekonstruieren. Aus diesem Grund enthält jedes JAR-Archiv, eine Klasse EtoileBean, welche die Aufgabe übernimmt, das Szenario-Bean zu deserialisieren, die Geometriedateien auszulesen und die Beans zu rekonstruieren. Diese Klasse erbt von BranchGroup und ist in der Manifest-Datei als Bean markiert, so daß sie in der Beanbox in den Szenengraphen eingefügt werden kann. Um das oben beschriebene Problem mit dem Sicherheitsmechanismus von Java zu vermeiden, ist diese Klasse kein Teil des VR-Systems, das heißt sie ist nicht im Klassenpfad enthalten. Da die nicht sichtbaren Beans, wie zum Beispiel Aktionspunkte, vollständig serialisiert werden, sollte es möglich sein, diese Objekte direkt in die Beanbox einzufügen. Leider führt der Versuch, 3D-Beans in der Beanbox zu laden, die bei der Instanziierung keine Geometrie enthalten, zu einem fehlerhaften Abbruch des Programms. Um diese Objekte dennoch einfügen zu können, wurde das in Kapitel 5.1.1.4 beschriebene EtVrBeanboxObject um ein Attribut type erweitert, mit dem einem EtVrScenarioHandler mitgeteilt werden kann, daß die enthaltene Geometrie als


92

Aktionspunkt, Region oder Pfad interpretiert werden soll. Für einen Aktionspunkt zum Beispiel wird die Position des Containers als Position des Beans benutzt und die Geometrie ignoriert1. Da type einen Integerwert darstellt, lassen sich beliebig viele Typen definieren. Allerdings muß der verwendete EtVrScenarioHandler diese Typen kennen und beim Einlesen des Szenarios die entsprechenden Beans erstellen.

5.2.3 Probleme bei Verwendung von Interpolatoren In den ersten Versionen des Programmsystems wurden für die Animationen in EtVrSwitchAnimation und EtVrPath Interpolatoren benutzt, die von Java3D bereitgestellt werden. Diese verwendeten jeweils ein Java3D-Behavior, das periodisch aktiviert wird (nach einer bestimmten Anzahl von Millisekunden oder Bildern). In einer ersten Testapplikation, die das VR-System benutzte, traten mit diesen Animationen noch keine Schwierigkeiten auf. Probleme gab es erst, als das VR-System mit ETOILE zusammen verwendete wurde. Falls während einer laufenden Trainingssitzung eine Animation gestartet wurde, wurden Benutzereingaben nur mit großen Verzögerungen verarbeitet. Die Vermutung war, daß der Thread des in den Interpolatoren benutzten Behavior-Knotens, durch die zeitabhängige Aktivierung andere Threads aushungern kann. Dies machte sich erst durch die Erhöhung der Threadanzahl aufgrund der von ETOILE hinzugekommenen Threads bemerkbar. Die (vorläufige) Lösung bestand darin, die Animationen in den entsprechenden Beans durch Threads statt Interpolatoren zu implementieren. Diese Threads gaben den Prozessor nach jeder Iteration wieder frei, zusätzlich wurde ihnen eine niedrige Priorität zugewiesen. Als Resultat waren die Animationen nicht mehr so flüssig wie zuvor, doch die Benutzerinteraktion wurde nicht mehr beeinträchtigt.

5.2.4 Realisierung der Kollisionserkennung Für die Erkennung von Kollisionen zweier Objekte bietet Java3D die Möglichkeit, ein Behavior zu aktivieren, wenn eine Kollision stattfindet oder wenn eine vorher registrierte Kollision nicht mehr besteht. Der Nachteil dieser Methode ist aber, daß eine Kollision erst registriert wird, wenn diese stattgefunden hat. Da die Kollision auch erst mit einer gewissen Verzögerung gemeldet wird, ist es meist nicht möglich, festzustellen, daß es keine Kollision gegeben hat. Für die Navigationskomponente des VR-Systems ist es aber nötig, zu jedem gegebenen Zeitpunkt testen zu können, ob der Betrachter mit einem Objekt kollidieren würde, falls eine bestimmte Bewegung ausgeführt wird. Daher wurde die in Kapitel 5.1.2.5 beschriebene Methode verwendet: an die gewünschte Position wird eine Bounding-Box plaziert, die dann auf Überschneidungen mit den vorhandenen Objekten getestet wird.

1 Der EtVrJarHandler implementiert diese Funktionalität zu diesem Zeitpunkt nur für den Typ Aktionspunkt.

5.3 Anwendung der Applikationen

93

5.3 Anwendung der Applikationen In diesem Abschnitt sollen die entwickelten Benutzerschnittstellen der Applikationen und deren Bedienung erläutert werden. Bei der Benutzung des VR-System stehen zwei leicht verschiedene Oberflächen für den Trainer oder einen Teilnehmer zur Verfügung. Diese sind relativ einfach gehalten, da ein Großteil der Interaktionen mit dem ETOILE-System über dessen zweidimensionale Oberfläche abgewickelt wird. Die Schnittstelle des Mappers bietet dagegen mehr Optionen und ist entsprechend vielseitiger.

5.3.1 Benutzung des VR-Systems als Teilnehmer Bild 5.8 stellt die graphische Benutzungsoberfläche des VR-Systems dar, wenn dieses als Teilnehmer benutzt wird (vergleiche auch Kapitel 4.3.1).

Bild 5.8: Oberfläche des VR-Systems für Trainingsteilnehmer. Die Navigation erfolgt über die Maus und die Tastatur. Wird die Maus innerhalb des 3D-Bereiches mit gedrückter rechter Maustaste bewegt, ändert sich der Blickpunkt des Betrachters entsprechend. Die Pfeiltasten erlauben die Bewegung nach vorn, nach hinten oder zur Seite, relativ zur aktuellen Blickrichtung. Mit dem Menüpunkt Controls ist es möglich, die Blickänderung bei vertikaler Mausbewegung zu invertieren.


94

Mit der linken Maustaste können Objekte in der Szene selektiert werden. Der ausgewählte Gegenstand wird dabei rötlich markiert. In der unteren Bildleiste befinden sich drei Informationsfenster. Das Statusfenster links zeigt den aktuellen Zustand des Systems an: waiting, wenn noch keine Szene geladen wurde, loading, während sie geladen wird und ready, wenn der Ladevorgang abgeschlossen ist. Das Informationsfenster beinhaltet allgemeine Nachrichten, wie Fehlermeldungen, Hilfstexte oder Namen von selektierten Teilnehmern. Im Positionsfenster schließlich wird der Name des Raums beziehungsweise der Region angezeigt, in der sich der Betrachter momentan befindet.

5.3.2 Benutzung des VR-Systems als Trainer Die Oberfläche des VR-Systems im Trainermodus entspricht in Aufbau und Bedienung der des Teilnehmers (siehe Bild 5.9).

Bild 5.9: Oberfläche des VR-Systems für den Trainer. Zusätzlich zu den oben beschriebenen Bedienelementen enthält das Fenster jedoch am oberen Bildrand eine weitere Navigationshilfe: aus zwei Listen können alle Aktionspunkte und Teilnehmer (beziehungsweise dynamische Objekte), die in der Szene vorhanden sind, ausgewählt werden. Daraufhin wird der Betrachter direkt an die entsprechende Position versetzt.


95

5.3.3 Bedienung des Mappers Der Mapper ist ein graphischer Editor, der es erlaubt, die Attribute geometrischer Name und selektierbar der 3D-Beans eines Szenarios graphisch zu bearbeiten. Für das Editieren der statischen Szene und der dynamischen Objekte gibt es zwei Bildschirme, zwischen denen hin- und hergeschaltet werden kann. Bild 5.10 zeigt die Oberfläche zum Bearbeiten der statischen Szene (siehe auch Kapitel 4.3.2).

Bild 5.10: Bearbeiten der statischen Szene mit dem Mapper In einem VR-Fenster wird die dreidimensionale Szene dargestellt. Diese kann mit der Maus rotiert (linke Maustaste), verschoben (rechte Maustaste) oder vergrößert beziehungsweise verkleinert werden (mittlere Maustaste). Auf der linken Seite befindet sich eine zweidimensionale Bedienoberfläche. Im oberen Teil werden die Attribute und der Typ des aktuell gewählten Beans angezeigt. Hier kann auch ein symbolischer Name festgelegt werden. Ist dieser schon für ein anderes Objekt vergeben, wird eine Warnmeldung angezeigt. Es wird jedoch noch nicht überprüft, ob dieser Name auch in der logischen Beschreibung der Szene oder des Agentenverhaltens vorkommt. Für ein visuelles Beans kann schließlich noch festgelegt werden, ob es in ETOILE selektierbar ist. In dem unteren Fenster kann ein Bean der Szene aus einer Liste aller verfügbaren Objekte ausgewählt werden. Der Typ der aufgelisteten Beans wird durch eine entsprechende Ikone gekennzeichnet. Die Namen von Beans, denen schon ein symbolischer Name zugewiesen wurde, werden in der Liste in grüner Farbe, ansonsten rot dargestellt.


96

Ein selektiertes Objekt wird in der 3D-Ansicht markiert, umgekehrt wird bei der Selektion in der dreidimensionalen Szene dieses auch in der Liste ausgewählt. Über fünf Knöpfe kann der Anwender auswählen, ob alle Beans in der Liste dargestellt werden sollen, oder nur diejenigen eines bestimmten Typs. In der unteren Bildhälfte befindet sich noch ein Schieberegler für die Helligkeit der 3D-Szene und ein Infofenster für allgemeine Nachrichten. Über den Reiter am oberen Bildrand kann auf den Bildschirm für die dynamischen Objekte umgeschaltet werden (siehe Bild 5.11).

Bild 5.11: Dynamische Objekte im Mapper. Die Bedienung auf diesem Bildschirm ist ähnlich zur statischen Szene. In der Liste werden alle vorhandenen dynamischen Objekte aufgezählt, wird eines davon ausgewählt, wird es im 3D-Fenster angezeigt. Im Attributsfenster kann hier auch noch die Eigenschaft link angegeben werden1. Über einen Knopf unterhalb der Liste ist es möglich, eine neue Datei im OpenFlight-Format als dynamisches Objekt der Szene hinzuzufügen. Dies ist ebenso im Menü File möglich. Dieses Menü erlaubt es außerdem, ein gespeichertes Szenario zu laden, oder das aktuelle Szenario in Form eines JAR-Archives oder einer Mapping-Table abzuspeichern. Schließlich ist es möglich, ein neues Szenario zu erstellen, die 1 Die Verwendung dieses Felds in ETOILE ist in der vorliegenden Version allerdings noch nicht implementiert.


97

Anwendung fordert den Benutzer dann auf, eine OpenFlight-Datei als statische Szene auszuwählen. Wie schon zuvor gesagt, handelt es sich bei dem Editor um eine prototypische Implementierung. Viele wichtige Funktionen sind noch nicht realisiert, zum Beispiel die Möglichkeit, Pfade zu definieren oder Animationen abzuspielen. Auch die Undo-Funktion zur Rücknahme von Eingaben fehlt. Dennoch konnten mit der vorliegenden Applikation die Vorteile des komponentenbasierten Ansatzes und dessen Einbeziehung in das Konzept des VR-Systems schon deutlich sichtbar gemacht werden.

98

6 Evaluierung In diesem Kapitel soll das oben beschriebene Konzept evaluiert und das daraus entwickelte System mit der monolithischen Realisierung verglichen werden. Als Grundlage für diese Evaluierung wird ein Testszenario entworfen, das die wichtigsten Funktionen, welche die VR-Systeme zur Verfügung stellen, benutzt. Zunächst müssen jedoch noch die Kriterien aufgestellt werden, anhand derer die beiden System verglichen werden sollen.

6.1 Kriterien zur Evaluierung Bei der Betrachtung eines Softwaresystems gibt es grundsätzlich zwei Sichtweisen, für die sich jeweils eigene Bewertungskriterien angeben lassen: die Sicht des Anwenders und die Sicht des Programmierers. Aus der Perspektive des Anwenders sind Gesichtspunkte der Benutzungsfreundlichkeit von Bedeutung. Wichtig hierbei ist, wie leicht das System zu bedienen ist, und ob der Anwender bei seiner Aufgabe vom System unterstützt oder behindert wird. Dies betrifft gleichermaßen die Benutzung des VR-Systems während des Trainings, als auch den Prozeß zur Erstellung eines neuen Trainingsszenarios. Ein weiteres Kriterium, das für das VR-System betrachtet werden muß, ist der Grad der Immersion. Je glaubwürdiger die Darstellung der simulierten Situation, desto effektiver wird auch das Training sein. Die Illusion der Präsenz in der virtuellen Szene wird unter anderem von der Performanz des Systems beeinflußt. Niedrige Bildraten und hohe Verzögerungszeiten bei der Eingabe können sich hier negativ auswirken. Auch eine konsistente Darstellung der Welt mit einer glaubwürdigen Simulation des (physikalischen) Verhaltens der Objekte ist wichtig. Für den Programmierer ist der Aspekt der Programmpflege relevant. Hier ist von Interesse, wie leicht sich das System an neue Anforderungen anpassen läßt, beziehungsweise welcher Aufwand nötig ist, um allgemein Änderungen am System vorzunehmen. In diesem Zusammenhang ist auch das Zusammenspiel der VR-Komponente mit dem gesamten ETOILE-System wichtig. Weiterhin ist zu prüfen, inwiefern sich Teile des Programms für andere Systeme sinnvoll wiederverwenden lassen. Hier muß die Arbeit in Betracht gezogen werden, die für die Anpassung des Programmteils und dessen Integration in das neue System aufgebracht werden muß.

6.2 Ein Beispielszenario

99

6.2 Ein Beispielszenario Um die beiden Systeme miteinander zu vergleichen, wurde ein Testszenario erstellt, das für die jeweiligen Trainingssitzungen verwendet werden soll. Bild 6.1 stellt schematisch den Aufbau der Szene dar, die symbolischen Namen der von der Simulation benutzten Objekte sind dort ebenfalls vermerkt.

Bild 6.1: Aufbau der Beispielszene. Das Szenario besteht aus zwei Räumen (Room1 und Room2) mit jeweils zwei Arbeitsplätzen, die durch einen Gang (Corridor) miteinander verbunden sind. Der Teilnehmer (Human1) startet im ersten Raum (auf dem Aktionspunkt R1_wp1). Am ersten Arbeitsplatz befindet sich eine Lampe (R1_lamp), die bei Selektion die Helligkeit der Szene herabsetzt beziehungsweise erhöht. In Raum 2 trifft der Teilnehmer auf einen Agenten (Agent1). Wird der Raum betreten, bewegt sich der Agent entlang eines Pfades (agentPath1) auf den Teilnehmer zu. Am Ende des Pfades wird eine Animation des Agenten gestartet. Sobald der Raum wieder verlassen wird, endet die Animation und der Agent bewegt sich entlang eines zweiten Pfades (agentPath2) wieder auf seinen Ausgangspunkt zurück (R2_wp2). Der Trainer, der die Situation beobachtet, hat als Ausgangspunkt einen weiteren Aktionspunkt (startTrainerAP).

Room1 Room2

Corridor

R1_wp1

agentPath1 agentPath2

R1_lamp

startTrainerAP

Agent1

Human1

R2_wp2

Kapitel 6: Evaluierung

100

6.3 Vergleich der beiden Systeme Anhand der in 6.1 aufgestellten Kriterien sollen nun die beiden VR-Systeme miteinander verglichen werden. Für beide Systeme wird dabei die gleiche Version von ETOILE verwendet, sowie das eben beschriebene Testszenario.

6.3.1 Erstellen des Szenarios Für ein Trainingssystem, das in einer Vielzahl von Anwendungsgebieten eingesetzt werden soll, ist es wichtig, daß neue Szenarien und Situationen möglichst einfach und ohne Programmierkenntnisse erstellt werden können. Um diesen Aspekt, bezogen auf die dargestellte virtuelle Szene, zu bewerten, soll nun für jedes VR-System der Modellierungsprozeß genauer betrachtet werden. Die Geometrie der statischen Szene (ohne die Lampe) und der benutzten Avatare liegt schon im OpenFlight-Format vor und wurde mit einer separaten Anwendung erstellt (RXscene von RealAX [Real00]). Dieses Modell der statischen Szene existierte schon vorher für das alte System und wird hier wiederverwendet, da die angesprochene Applikation zur Modellierung für diese Arbeit nicht zur Verfügung stand. Des weiteren wurden ebenfalls schon die logischen Beschreibung des Szenarios und die Verhaltensbeschreibung der Agenten vorbereitet.

6.3.1.1 Der Modellierungsprozeß mit dem ursprünglichen System

Um das Modell mit ETOILE benutzen zu können, ist es nötig, die in der symbolischen Beschreibung und den Skripten der Agenten verwendeten Namen den Objekten der 3D-Szene zuzuordnen. Diese Zuweisungen von symbolischen Namen müssen manuell mit einem Texteditor in eine Mapping-Table eingetragen werden. Da RXscene oder ein ähnliches Tool nicht zur Verfügung stand, konnte der Szene kein Modell einer Lampe hinzugefügt werden, statt dessen wurde der symbolische Name R1_lamp einem anderen Objekt zugewiesen (einem Monitor). Aus dem gleichen Grund konnten auch keine zusätzlichen Aktionspunkte mehr definiert werden, für die Pfade und den Startpunkt des Trainers wurden andere, schon existierende Punkte benutzt. Die resultierende Mapping-Table hatte folgenden Inhalt:

db example tstsc5.flt

obj Human1 man2r.flt sel dynobj Agent1 man1anir.flt sel dyn aniobjani Human1anisw anisw sel man1anir.fltobj R1_wp1_screen R1_lamp sel

la Room1 LA_R1la Room2 LA_R2la Corridor LA_corridor

6.3 Vergleich der beiden Systeme

101

ap startTrainerAP AP_R1_fire_aniap R1_wp1 AP_H1_start_pointap R2_wp2 AP_R2_fire_aniap R2_wp1 AP_H2_start_point

pp agentPath2 R2_wp1 R2_wp2pp agentPath1 R2_wp2 R2_wp1

6.3.1.2 Modellieren mit dem komponentenbasiertem System Da für den Mapper oder die dreidimensionale Beanbox die Funktionalität zum Einfügen eines Pfades noch nicht implementiert wurde, werden die beiden Pfade für den Agenten vorerst ebenfalls in einer Mapping-Table angegeben. Zwei dafür benutzte Aktionspunkte, die nicht in der Geometriedatei enthalten waren, werden hier ebenfalls definiert: db example tstsc5.flt

ap R2_wp2 AP_R2_fire_aniap R2_wp1 AP_H2_start_pointap AgentTurn 2.48 0.0 -4.0ap AgentPause 3.28 0.0 -2.72pp agentPath1 R2_wp2 R2_wp1pp agentPath2 R2_wp1 AgentPause AgentTurn R2_wp2

Diese Tabelle wird aber nur benötigt, um initial die Pfade in die Szene einzufügen. Sobald die Szene das erste mal als JAR gesichert wurde, sind auch diese Daten dort in serialisierter Form gespeichert und die Tabelle wird nicht mehr gebraucht. Wenn keine Objekte verwendet werden sollen, die nicht in einer OpenFlight-Datei definiert sind, kann das Szenario auch im Mapper unter Angabe einer Geometriedatei für die statische Szene neu erzeugt werden. Es ist dann nicht notwendig, zuvor eine Mapping-Table einzuladen. Der nächste Schritt im Modellierungsprozeß ist die Bearbeitung der Attribute mit dem Mapper. Bild 6.2 zeigt den Bildschirm zur Bearbeitung der statischen Szene. Die vorher definierten Objekte bekommen als geometrischen Namen automatisch <generated> zugeordnet. Wie in Kapitel 5.3 beschrieben, lassen sich den anderen Objekten jetzt bequem die geplanten symbolischen Namen zuweisen. Für Objekte, bei denen es später möglich sein soll, sie auszuwählen, muß auch noch das entsprechende Kontrollkästchen gesetzt werden. Bei einzelnen Objekten, wie etwa den Aktionspunkten, ist die direkte Auswahl in der 3D-Ansicht günstiger. Für Objekttypen, bei den allen Beans ein Name zugewiesen werden soll, ist die Auswahl über die Liste geeigneter, wie in diesem Fall für die drei Regionen. Wurden alle Namen zugewiesen, fehlen der Szene noch die Avatare des Agenten und des Teilnehmers. Diese Beans können im Bildschirm für dynamische Objekte hinzugefügt und ebenfalls benannt werden (siehe Bild 6.3).


102

Bild 6.2: Bearbeiten des Testszenarios mit dem Mapper.

Bild 6.3: Hinzufügen der Avatare.


103

Für unsere Beispielszene fehlt jetzt noch die Lampe und der Aktionspunkt, der den Startpunkt des Trainers markiert. Diese Objekte sollen mit Hilfe der dreidimensionalen Beanbox hinzugefügt werden. Zu diesem Zweck wird die Szene im Mapper jetzt in Form eines JAR-Archives gesichert. Die obigen Namenszuweisungen hätten ebenso in der Beanbox über den Eigenschaftseditor des EtoileBean-Objektes vorgenommen werden können. Dieser bietet jedoch nicht die gesamte Funktionalität des Mappers, wie verschiedene Listen für die einzelnen Typen oder Überprüfung von Eingabefehlern. Da er ebenfalls nur prototypisch implementiert ist, enthält er vielmehr nur eine einfache Auswahlliste der Beans. Bild 6.4 zeigt die eben erzeugte Szene, nachdem sie in der Beanbox geladen wurde.

Bild 6.4: Das Testszenario in der dreidimensionalen Beanbox. Das JAR-Archiv, in dem sich die Szene befand, enthält auch noch ein EtVrBeanboxObject, das als Container für beliebige 3D-Objekte dient. In der Beanbox wird es durch eine grüne, transparente Sphäre repräsentiert. Für die Schreibtischlampe fügen wir jetzt ein solches Objekt ein und plazieren es auf einem Schreibtisch im ersten Raum. Die Schreibtischlampe ist ein Objekt, das als Beispiel von der Beanbox zur Verfügung gestellt wird. Dieses wird jetzt dem Container untergeordnet eingefügt. Durch Bearbeiten der Objekteigenschaften des Container-Beans kann der Lampe sofort ein symbolischer Name und die Eigenschaft selektierbar zugewiesen werden (Bild 6.5).


104

Bild 6.5: Einfügen eines Objektes in einen Container.

Bild 6.6: Einfügen eines Aktionspunktes in der Beanbox.


105

Für das Einfügen eines Aktionspunktes reicht es, einen Container an der gewünschten Stelle zu positionieren und für die Eigenschaft type das Objekt als Aktionspunkt zu deklarieren (die geschieht über einen Integerwert), wie in Bild 6.6 dargestellt. Wie bei der Lampe wird auch noch gleich der symbolische Name vergeben. Am Ende wird die Szene mit der Beanbox erneut in einem JAR-Archiv gesichert und ist bereit für den Einsatz mit ETOILE.

6.3.1.3 Fazit Vor allem bei großen Szenarien mit sehr vielen Objekten kann der Ansatz mit der Mapping-Table schnell unübersichtlich werden, zumal von jedem benutzten Objekt der geometrische Name bekannt sein muß. Die Eingabe mit einem normalem Texteditor ist zudem auch fehleranfälliger. Durch die Möglichkeit, die 3D-Beans mit dem Mapper oder der Beanbox visuell bearbeiten zu können, wird der Prozeß der Szenarioerstellung intuitiver und damit auch leichter. Insbesondere für den Mapper wurden benutzungsfreundliche Aspekte berücksichtigt, um den Autor des Szenarios bei seiner Aufgabe zu unterstützen. Objekte können direkt aus der 3D-Ansicht ausgewählt werden, so daß es nicht mehr nötig ist, die geometrischen Namen der Beans zu kennen. Auch fehlerhafte Eingaben werden teilweise vermieden: die doppelte Vergabe von Namen wird abgefangen, unsinnige Eingaben, wie etwa einen Aktionspunkt als selektierbar zu kennzeichnen, sind auch nicht möglich. Einige wichtige Funktionen wurden für den Mapper allerdings noch nicht implementiert. So ist es noch nicht möglich, Pfade direkt zu definieren, hierzu muß immer noch der umständliche Weg über die Mapping-Table gewählt werden. Auch die in Kapitel 4.3.2. beschriebene Liste, welche gültige Namen aus der Szenariobeschreibung für die Eingabe des symbolischen Namens zur Verfügung stellt, existiert noch nicht. Es sollte weiterhin noch möglich sein, die einzelnen Bilder der Animations- und Switch-Objekte darzustellen. Der prototypische Ansatz der Applikation zeigt dennoch die Vorteile für den Autorenprozeß, welche sich durch die Ausnutzung des Komponentekonzeptes ergeben. Die Arbeit wird für den Anwender vereinfacht und verlangt von ihm weniger Kenntnisse über den internen Aufbau der Szene, wie etwa die geometrischen Namen der Objekte, oder den Namen des Knotens, der die Animation eines Objektes enthält. Die Erhöhung des Visualisierungsgrades durch die Verwendung von Ikonen und Farbmetaphern macht die Bedienung der Anwendung intuitiver und leichter.

6.3.2 Bedienung des VR-Systems Das alte VR-System bietet innerhalb des 3D-Fensters keine zusätzlichen Bedienelemente. Die Steuerung ist modusbasiert: im Navigationsmodus bestimmt die Position des Mauszeigers die Richtung und Geschwindigkeit der Fortbewegung, im Selektionsmodus können Objekte ausgewählt werden. Zwischen den beiden Modi wird mit der Leertaste der Tastatur umgeschaltet.


106

Diese Art der Navigation kann problematisch werden, besonders wenn ein Anwender schnell ein Objekt auswählen möchte und vergißt, in den richtigen Modus zu schalten. Hinzu kommt, daß im Navigationsmodus die Daten der Mauspositionen selbst dann ausgewertet werden, wenn sich der Mauszeiger außerhalb des VR-Fensters befindet. Dies kann ebenfalls zu unerwünschten Effekten führen, falls der Anwender versucht, auf die 2D-Oberfläche zuzugreifen. Diese Eigenschaften können sich störend auf die Effizienz des Trainings auswirken. Die Navigationsmethode des in dieser Arbeit entwickelten Systems benutzt zwar auch Maus und Tastatur, jedoch ist es nicht nötig zwischen verschiedenen Modi umzuschalten. Vielmehr wird jeder Maustaste eine bestimmte Aktion (Selektieren oder Navigieren) zugeordnet. Das heißt der Blickwinkel ändert sich nur beim "Ziehen" des Mauszeigers. Dadurch kommt es seltener vor, daß eine unbeabsichtigte Bewegung ausgeführt wird, obwohl nur der Mauszeiger zum Selektieren positioniert werden sollte. Die in Kapitel 5.3 beschriebenen Navigationshilfen erleichtern zusätzlich die Arbeit mit dem Trainingssystem. Die Positionsanzeige hilft dem Benutzter, jederzeit seinen aktuellen Standort festzustellen. Das ursprüngliche System hat keine solche Funktion, dies kann besonders in großen Szenarien mit vielen ähnlichen Räumen zu Orientierungsproblemen führen. Schließlich wird der Trainer durch die Möglichkeit, sich zu verschiedenen Punkten und Teilnehmern zu teleportieren, ebenfalls bei seiner Aufgabe unterstützt. Dies ist wiederum gerade bei großen Szenen von Nutzen: wollte der Trainer beim alten System einen weit entfernten Teilnehmer beobachten, mußte er die Strecke "laufend" zurücklegen. Insgesamt betrachtet wird die Bedienung also durch die aus den Überlegungen zur Benutzungsfreundlichkeit in der Konzeption hervorgegangen Navigationshilfen im Vergleich zum älteren System verbessert. Ein Nachteil jedoch ist die zur Zeit einfacher implementierte Kollisionserkennung. Eine Bewegung, die zu einer Kollision führen würde, wird einfach nicht ausgeführt. Der Benutzter bleibt dadurch öfter an Türen und anderen Objekten hängen, als es mit dem ursprünglichen VR-System der Fall war. Statt dieser trivialen Lösung sollte in einer zukünftigen Realisierung der Kollisionspunkt berechnet und eine Bewegung bis zu diesem Punkt ausgeführt werden.

6.3.3 Grad der Immersion Der Grad der Immersion hängt unter anderem von der Performanz des Systems ab. Flackern durch niedrige Bildwiderholungsraten, ruckelnde Darstellung von Bewegungen und spürbare Verzögerungszeiten bei der Eingabe stören das Gefühl der Präsenz und können in Extremfällen sogar zu Übelkeit führen (siehe Kapitel 2.3.2.1). Aus diesem Grund sollen zunächst diese Faktoren für die beiden Systeme betrachtet werden. Für eine Messung der Bildwiderholungsraten der beiden VR-Systeme wurde die oben erstellte Beispielszene auf zwei PCs (jeweils ein Trainer und ein Teilnehmer) mit gleichen Systemleistungen mit ETOILE gestartet. Bei den Rechnern handelte es sich


107

um Systeme mit einem Pentium-III-Prozessor, 650 MHz und 256MB Speicherkapazität. Als Betriebssystem diente Windows NT 4.0, als Java-Interpreter wurde das SDK 1.2 mit Java3D 1.1.2 verwendet. Als Graphikkarte stand eine Elsa ERAZOR X² Geforce DDR mit 32 MB Bildspeicher zur Verfügung. Für den Test wurden die VR-Fenster jeweils auf Vollbild vergrößert, bei einer Auflösung von 1280 x 1024 Pixel und True-Color-Farbtiefe. Während der Simulation mit dem ursprünglichen VR-System wurden die Bilder des Trainers mit einer durchschnittlichen Frequenz von 76,92 fps dargestellt, bei der Applikation für den Teilnehmer im Durchschnitt 90,91 fps. Das Minimum von 50 fps trat vor allem bei Kollisionen auf, der erreichte Maximalwert betrug 100 fps. Für den Trainer des neuen VR-Systems wurde ein durchschnittlicher Wert von 82,81 fps festgestellt, mit Extremwerten von 50,95 fps als Minimum und 102,79 fps als Maximum. Die Anwendung für den Teilnehmer jedoch kam nur auf einen durchschnittlichen Wert von 66,33 fps mit Extrema von 45,50 fps und 82,10 fps. Allgemein kann man also sagen, daß die Bildraten der beiden Systeme vergleichbar sind, wobei im Falle des Teilnehmers die Performanz des alten Systems etwas besser ausfällt. Eine wichtige Beobachtung war auch, daß die Bildrate des alten VR-Systems gleichmäßiger blieb, wo hingegen beim neuen System die Werte abhängig vom dargestellten Inhalt stärker schwankten. Die Performanz des hier entwickelten Systems wurde allerdings auch durch den im Kapitel 5.2 beschriebenen Kompromiß erkauft, der durch die Probleme mit den Interpolatoren und Behaviors heraus entstand. Dies macht sich besonders dadurch bemerkbar, daß Animationen und Pfadinterpolationen nicht mehr so flüssig, und damit unrealistischer, ablaufen, wie das im alten System der Fall war. Dies hat ebenfalls negative Auswirkungen auf die Immersion. Außerdem sind aus den oben genannten Gründen weitere Einbußen in der Performanz des Systems zu erwarten, wenn 3D-Beans benutzt werden, die ihrerseits die als problematisch erkannten Interpolatoren verwenden. Unterschiede in den Reaktionszeiten für Benutzereingaben konnten dagegen nicht beobachtet werden. In diesem Fall ist der größte Flaschenhals noch das ETOILE-System selber, das von beiden VR-Systemen benutzt wird. Einzig beim Einlesen der dreidimensionalen Szenen konnte festgestellt werden, daß das neue System wesentlich länger braucht. Dies liegt vor allem in der Methode, mit der das Szenario im neuen System eingelesen wird: zuerst müssen die OpenFlight-Dateien aus dem JAR-Archiv in ein temporäres Verzeichnis geschrieben und von dort mittels des OpenFLT-Loaders wieder eingelesen werden. Hier ist es vor allem nötig, ein geeigneteres Verfahren für die Serialisierung der Beans zu finden. Die im vorigen Kapitel angesprochenen Probleme des neuen Systems bezüglich der Kollisionserkennung führen auch zu einer Einbuße der Immersion, ebenso das Fehlen sonstiger physikalischer Simulation. Die Kollisionserkennung des alten Systems ist genauer, außerdem wurde teilweise eine Simulation der Gravitation des Betrachters implementiert: während der Navigation folgt die eigene Bewegung eventuellen Höhenunterschieden (Treppen). Im neuen System ist zur Zeit nur die Bewegung innerhalb der x-z-Ebene möglich. Eine Implementierung zur Erkennung von


108

Höhenunterschieden wäre innerhalb der Kollisionserkennung möglich. Die verwendete Bounding-Box müßte zu diesem Zweck von einer erhöhten Position heruntergelassen werden, bis eine Kollision erkannt wird. Die Immersion des neuen Systems wird außerdem noch erheblich durch Fehler in der Darstellung gestört, wie der Vergleich in Bild 6.7 zeigt.

Bild 6.7: Darstellungsunterschiede zwischen dem alten (links) und neuen VR-System (rechts). Wie im rechten Bild zu sehen ist, treten beim neuen System Z-Buffer-Fehler auf: die Koordinatenebene der texturierten Fläche fällt mit derjenigen der Vorderseite des Schrankes zusammen. Für die Pixel der beiden Objekte, die jetzt zusammenfallen, kann Java3D nun nicht mehr korrekt entscheiden welche im Vordergrund liegen, deshalb werden Teile der Fläche dargestellt, andere verdeckt. Die Darstellung ändert sich auch mit jeder Änderung des Blickpunktes, so das ein irritierendes Flackern die Folge ist, das den Realismus der Szene zerstört. Diese Fehler sind zwar auf die Modellierung der Szene zurückzuführen (die auf dem Schrank liegende Fläche sollte immer ein wenig vor diesem liegen), werden aber von OpenGVS besser bewältigt. Ebenfalls auffällig sind die fehlenden Farbattribute der Objekte. Dies liegt vermutlich an der Verwendung des OpenFlight-Loaders, der nur in einer Betaversion vorlag. Insgesamt kann also festgehalten werden, daß das alte System dem hier entwickeltem im Punkt der Immersion des Betrachters noch überlegen ist. Die aufgetretenen Schwierigkeiten sind aber nicht auf das zugrunde liegende Konzept zurückzuführen, sondern sind vielmehr implementierungsbedingt. Viele Probleme der Performanz begründen sich durch die Tatsache, daß das Java3D-System innerhalb der gleichen virtuellen Maschine wie ETOILE gestartet wird, während die OpenGVS-Realisierung in einem separaten Prozeß läuft. Dieser Ansatz wäre alternativ auch für das hier entwickelte System denkbar.

6.3.4 Erweiterbarkeit und Wiederverwendbarkeit Das alte VR-System stellt seine Funktionalität in Form einer DLL (Dynamic Link Library) zur Verfügung. Das bedeutet wiederum, daß die Änderung, die an der Implementierung einer Funktion vorgenommen wird, oder auch das Entfernen beziehungsweise Hinzufügen von Funktionen sich auf das gesamte System auswirkt,


109

es ist jedesmal erforderlich, die Programmbibliothek neu zu kompilieren (neue Funktionen könnten allerdings auch in Form einer neuen DLL hinzugefügt werden). Die komponentenbasierte Konzeption des neuen VR-Systems dagegen macht auch die in Kapitel 2.1 beschriebenen Vorteile zur Programmpflege verfügbar. Wird die Implementierung einer Komponente verändert und dabei die Schnittstelle zum System nicht beeinflußt, wirkt sich diese Änderung auch nur auf die entsprechende Komponente aus. Es reicht dann aus, nur diese neue Komponente neu zu kompilieren. Neue Funktionen werden in Form neuer Komponenten (die schon kompiliert sein können) hinzugefügt. Zum Beispiel wäre es denkbar, eine Komponente zu entwerfen, die zur besseren Orientierung eine Übersichtskarte der aktuellen Szene darstellt und dort die Positionen des Teilnehmers anzeigt. In diesem Fall reicht eine Anpassung der Koordinationskomponente aus: sie muß die neue Komponenten erzeugen, ihr die Daten der Szene zur Verfügung stellen und sie als Empfänger für Positionsänderungen bei der Visualisierungskomponente registrieren. Wie am Beispiel des Mappers zu sehen war, können die Komponenten des VR-Systems auch in neuen Anwendungen wiederverwendet werden, ohne daß es nötig ist, diese neu zu kompilieren. Diese Eigenschaft ist natürlich auch gewöhnlichen Java-Klassen zu eigen. Durch den Reflection-Mechanismus, der auf die JavaBeans angewendet werden kann, ist es nicht mehr notwendig, den Quellcode zu kennen, um diese auch anwenden zu können. Um Programmelemente des alten VR-Systems wiederzuverwenden, muß immer eine komplette DLL benutzt werden. Natürlich ist es jederzeit möglich, Quellcode wieder zu benutzen, aber dies erfordert jedesmal eine erneute Kompilierung und die Kenntnis des Programmcodes. Durch die javabasierte Realisierung schließlich ist das VR-System keine separate Einheit mehr, sondern in das ETOILE-System integriert. Damit ist es auch möglich, daß einzelne existierende oder später hinzukommende Komponenten direkt von mehreren ETOILE-Untersystemen gemeinsam genutzt werden können. Zusammenfassend läßt sich daher feststellen, daß das neue VR-System im Vergleich zur ursprünglichen Realisierung, wie alle komponentenbasierten Systeme, die Pflege des Systems vereinfacht und die Wiederverwendbarkeit von Programmteilen erhöht. Durch die Integration in ETOILE ist das Gesamtsystem stabiler geworden, seine Weiterentwicklung wird vereinfacht.

6.4 Ergebnis Durch die Möglichkeit, Objekte der verwendeten virtuellen Szene visuell anzupassen, wird es einem Anwender des Trainingssystems, im Vergleich zu der ursprünglichen Realisierung, erleichtert, ein neues Trainingsszenario zu erstellen. Besonders umfangreichere Szenen lassen sich mit größerer Übersicht bearbeiten, Fehler können so leichter vermieden werden.


110

Durch die Berücksichtigung von benutzungsfreundlichen Prinzipien, insbesondere Navigationshilfen, wird die Arbeit mit dem System weiter erleichtert, der Anwender wird bei seiner Tätigkeit unterstützt und kann sich auf diese Weise besser auf die Bewältigung seiner eigentlichen Aufgaben konzentrieren. Das Training mit dem ETOILE-System wird somit effektiver. Ein weiterer Vorteil des komponentenbasierten Konzeptes gegenüber der monolithischen Realisierung, ist die problemlosere Pflege des Systems sowie die erhöhte Wiederverwendbarkeit von Programmteilen. Die Integration des VR-Systems in ETOILE, die durch die Wahl von Java und Java3D als Plattform für das System möglich wurde, ist ein weiterer Vorteil. Dies alles kann sich positiv auf die benötigte Entwicklungszeit für die Evolution des Projektes auswirken und somit die Entwicklungskosten senken. Ein Schwachpunkt des neuen Systems ist jedoch die schlechtere Immersion des Anwenders in die virtuelle Welt und die dadurch geringere Effektivität des Trainings, die vor allem durch die schlechtere Performanz und Darstellungsfehler verursacht wird. Diese Probleme sind jedoch implementierungsbedingt und sprechen nicht grundsätzlich gegen die Vorteile, welche die zugrundeliegende Konzeption bietet.

111

7 Zusammenfassung und Ausblick In der vorliegenden Arbeit wurde für das Trainingssystem ETOILE ein komponentenbasiertes VR-System entwickelt, welches eine Alternative zu dem schon bestehenden System darstellen sollte. Durch die Realisierung mit Java und Java3D war es möglich, das VR-System vollständig in das ebenfalls in Java implementierte ETOILE zu integrieren. Die ursprüngliche Version wurde in C++ entwickelt und über das Java Native Interface (JNI) an ETOILE angebunden. Die Prinzipien der komponentenbasierten Softwareentwicklung wurden dabei auf zwei Ebenen angewandt. Die dreidimensionalen Objekte, die in der virtuellen Szene dargestellt werden, sind Komponenten, sogenannte 3D-Beans. Aber auch das VR-System selbst ist aus Softwarekomponenten aufgebaut. Der Anwender der Applikation beziehungsweise der Autor neuer Trainingsszenarien profitiert vor allem von der Verwendung dreidimensionaler Beans, aus denen die virtuellen Szenen aufgebaut sind. Diese enthalten neben der Geometrie des jeweiligen Objektes zusätzliche Attribute, die für die Verwendung von ETOILE benötigt werden. Außerdem kann ein eventuelles Verhalten ebenfalls innerhalb der Komponente beschrieben sein. Durch die Realisierung der Objekte als Komponenten ist es möglich, deren Eigenschaften in einer graphischen Benutzungsumgebung visuell anpassen zu können. Aus Sicht des Programmierers vereinfacht sich die Pflege des VR-Systems durch dessen Entwurf als Komponentensystem, da es flexibler wird. Änderungen an einer Komponente des Programms erfordern nicht das erneute Kompilieren des gesamten Systems. Komponenten mit neuer Programmfunktionalität können hinzugefügt oder alte Komponenten entfernt werden. Außerdem können diese für andere Applikationen wiederverwendet werden. Die Vorteile beider Sichtweisen wurden anhand eines prototypisch implementierten Editors dargestellt. Dieser erlaubte das visuelle Anpassen der Attribute der 3D-Beans eines Szenarios. Dabei bestand diese Applikation zum größten Teil aus den selben Softwarekomponenten, aus denen sich auch das entwickelte VR-System zusammensetzte. Ein weiterer Aspekt, der zu einem gewissen Maße ebenfalls berücksichtigt wurde, war die Benutzungsfreundlichkeit der Interaktionsschnittstellen der Anwendung. Durch die Bereitstellung von Navigationshilfen wurde hier die Bedienung des VR-Systems erleichtert. Bei einem Vergleich des alten VR-Systems mit dem in dieser Arbeit entwickelten wurde schließlich festgestellt, daß durch die Verwendung von 3D-Beans und die Möglichkeit, diese visuell anzupassen, der Autorenprozeß intuitiver wurde. Auch die Bedienung der Interaktionsschnittstellen war dank der eingebrachten Konzepte zur Benutzungsfreundlichkeit leichter.

Kapitel 7: Zusammenfassung und Ausblick

112

Der Entwurf als Komponentensystem erleichterte die Pflege des Systems, die Wiederverwendbarkeit von Teilen des Programms war problemloser als mit dem monolithischen System. Ein Schwachpunkt des komponentenbasierten Systems war die Einbuße bei der Immersion des Anwenders, die durch die etwas schlechtere Performanz und Fehlern bei der Darstellung der virtuellen Szene verursacht wurde. Ausblick Obwohl das Konzept der dreidimensionalen JavaBeans schon sehr brauchbar ist, kann es sicherlich noch weiter ausgebaut werden. Vor allem die Erhaltung der Persistenz ist aufgrund der nicht vorhandenen Unterstützung der Serialisierung von Java3D-Szenengraphen noch nicht zufriedenstellend gelöst worden. In dieser Hinsicht ist die Jamal Component Architecture interessant [Rudo00a], [Rudo00b], die ebenfalls Java und Java3D benutzt. Hier wurde eine deklarative Infrastruktur für die Entwicklung von Komponentensystemen implementiert. Dabei werden der dynamische Zustand der Eigenschaften (properties) und die Verknüpfungen der Komponenten untereinander durch Beschreibungen in XML (Extensible Markup Language) [Xml00] definiert. Anpassungen von Komponenten können dadurch in einer normalen Textdatei gesichert werden. Weiterhin ist es denkbar, daß ein 3D-Bean zusätzlich zu seiner Geometrie eine 2D-Repräsentation enthält. Diese könnte benutzt werden, um die Objekte auch in zweidimensionalen Autorenumgebungen, wie zum Beispiel der ursprünglichen Beanbox von Sun, bearbeiten zu können. Dieser Ansatz wurde in [DoGr00] vorgeschlagen. Ein Gesichtspunkt, der bei der zukünftige Entwicklung des hier vorgestellten VR-Systems von Interesse sein wird, ist die Ausdehnung des Bean-Konzeptes auf das restliche Trainingssystem. Dabei ist es denkbar, daß vor allem die Aufgabe der Simulation noch mehr vom ETOILE–System hin zu den 3D-Beans verlagert wird. Dreidimensionale Objekte, welche Agenten darstellen, könnten zusätzlich auch noch deren aktives Verhalten beinhalten. Ebenso könnte der Szenarioagent, der die globale Simulation übernimmt, mit dem Szenario-Bean, welches die dreidimensionalen Beans enthält, vereinigt werden. Für diese "Agenten-Beans" wäre es möglich, den direkten Zugriff auf das Kommunikationssystem über einen Infobus zu ermöglichen (in der aktuellen Implementierung geschieht der Datenaustausch mit dem restlichen System noch über die Koordinationskomponente). Diese Methode wurde schon für die in der zweidimensionalen Benutzungsoberfläche von ETOILE verwendeten Beans angewandt. Ein solcher Ansatz eines Trainingssystems mit einer agentenbasierten Struktur wurde zum Beispiel in [Lin99] entwickelt. Die Kontrolle der Simulation wurde auf die Agenten des Systems verteilt, jeder Agent hat lokale Kontrolle über seine Umgebung und die Möglichkeit, mit anderen Agenten zu kommunizieren.

113

Die zweidimensionalen Beans von ETOILE könnten ebenfalls mit ihren dreidimensionalen Gegenstücken verschmolzen werden, sofern solche vorhanden sind. Ein Beispiel hierfür wäre ein Telephon-Bean, das sowohl von der ETOILE-Oberfläche als auch aus der virtuellen Szene heraus aktiviert werden kann. Durch die Möglichkeit, einzelnen Objekten der virtuellen Szene Attribute und Verhalten zuweisen zu können, ist es ebenfalls denkbar, die Szene um eine physikalisch-basierte Simulation zu erweitern. Wie zum Beispiel in [Dai97] beschrieben, können die statischen Größen von (dynamischen) Objekten neben der Geometrie auch die Masse, einen Reibungskoeffizienten oder einen Trägheitstensor beinhalten. Außerdem können noch dynamische Größen, wie die lineare und Winkelgeschwindigkeit in dem Objekt gespeichert werden. Das Verhalten aufgrund der physikalischen Eigenschaften ist passiv, wird also nicht von der Komponente selbst simuliert, da zu diesem Zweck auch Kenntnisse über den Zustand der gesamten Szene nötig sind. Diese Aufgabe würde daher wieder dem Szenario-Agenten beziehungsweise dem ETOILE-System zufallen. Die Funktionalität der Agenten könnte im Bereich der graphischen Präsentation verbessert werden, etwa durch die Verwendung von detaillierteren Avataren. Durch die Möglichkeit, Gesten und Mimik darzustellen, wird nicht nur die Immersion erhöht. Die Agenten können nun nicht nur als Mitspieler sondern vielmehr auch als Tutoren eingesetzt werden. Ein Beispiel für ein solches System ist der Agent STEVE ( Soar Training Expert for Virtual Evironments) [RiJo98], der an der University of Southern California entwickelte wurde (siehe auch Bild 7.1).

Bild 7.1: Der pädagogische Agent STEVE [RiJo98]. Der zweite wesentliche Aspekt, auf den sich eine zukünftige Entwicklung konzentrieren muß, ist sicherlich die Modellierung neuer Szenarien. Dieser Prozeß sollte so einfach und einsichtig wie möglich sein. Die in dieser Arbeit vorgestellten

Kapitel 7: Zusammenfassung und Ausblick

114

Möglichkeiten zur visuellen Anpassung der dreidimensionalen Beans zeigen einen ersten Ansatz zur Ausnutzung des durch die komponentenbasierte Struktur bereitgestellten Potentials. Für das Erstellen einer Trainingssituation sollten alle Aspekte in einem einzigen Editor vereint werden: Modellierung der Geometrie, Anpassung der Attribute, logische Beschreibung des Szenarios und Festlegen des Verhaltens der Agenten. Dieser Editor sollte wahlweise als alleinstehende Applikation oder aus dem ETOILE-System heraus aufgerufen werden können. Für die Gestaltung der geometrischen Modelle können primitive Java3D-Objekte bereitgestellt werden, die sich miteinander kombinieren lassen. Weiterhin ist es denkbar, eine Bibliothek von vorgefertigten Modellen zur Verfügung zu stellen, auch die Möglichkeit zum Importieren fremder Dateiformate sollte vorhanden sein. Zusätzlich zu einer Modellbibliothek ist aber auch noch eine Komponentenbibliothek sinnvoll, hier werden dem Anwender fertige Beans inklusive Geometrie, Verhaltensbeschreibung und physikalischen Eigenschaften angeboten, die für den Einsatz in einem neuen Trainingsszenario verwendet werden können. So könnten beispielsweise generische Agenten mit entsprechenden Avataren existieren, die wiederholt auftretende Standardaufgaben übernehmen. Die Funktionen zum Bearbeiten des Verhaltens sollten dabei die einfache Anpassung dieser Agenten an die eigenen Bedürfnisse ermöglichen. Beans, die mit dem Editor erstellt wurden, können dann ihrerseits für andere Projekte wiederverwendet werden. Schließlich lassen sich auch noch die benutzungsfreundlichen Aspekte des hier vorgestellten Systems weiter entwickeln. Beispielsweise können die angewendeten Navigationshilfen zusätzlich erweitert werden, etwa durch die Anzeige der aktuellen Position in einer Übersichtskarte der Szene. Generell läßt sich das in dieser Arbeit entwickelte Konzept auf viele Bereiche der virtuellen Realität ausdehnen. Es müssen nur entsprechende Attribute für die verwendeten 3D-Beans konzipiert und der neuen Aufgabe gemäße Objekttypen realisiert werden. Letztendlich ist die Realisierung eines solchen Systems auch keineswegs auf Java oder Java3D beschränkt, das vorgestellte Konzept kann zum Beispiel mit jeder der in Kapitel 2.1.1 vorgestellten Architekturen umgesetzt werden.

115

Anhang: Literaturverzeichnis [Beie00] Beier, K.-P.: Virtual Reality: A Short Introduction.

http://www-VRL.umich.edu/intro/index.html, 2000-02-28, Abruf am 2000-04-14.

[BoDo97] Boshernitsan, Marat; Downes, Michael: Visual Programming

Languages: A Survey, CS 263 Final Project. University of California, Berkley, Computer Science Division, 1997.

http://www.cs.berkeley.edu/~maratb/cs263/paper.html [Bouv99] Bouvier, Dennis J.: Getting Started with the Java 3D API.

http://java.sun.com/products/java-media/3D/collateral/#tutorial, 1999-10-26, Abruf am 2000-02-01.

[Bray00] Bray, Mike: Graphical User Interface Builders. http://www.sei.cmu.

edu/str/descriptions/guib.html, Software Engineering Institute, Carnegie Mellon University, 1997-01-10, Abruf am 2000-02-18.

[Brol98] Broll, Wolfgang: Ein objektorientiertes Interaktionsmodell zur

Unterstützung verteilter virtueller Umgebungen. GMD-Forschungszentrum Informationstechnik GmbH, GMD Research Series 1998, No. 11.

http://www.gmd.de/publications/research/1998/011/Text.pdf [BrWa98] Brown, Alan W.; Wallnau, Kurt C.: The Current State of CBSE. In:

IEEE Software15 (1998) 5, S. 37 – 46. http://www.computer.org/software/so1998/extras/s5037.htm

[Chov98] Chovan, Rastislav: Java Beans. Unterlagen zu einem Seminar am

Zentrum für Graphische Datenverarbeitung e. V., Darmstadt 15. Mai 1998.

[Cola00] Colan, Mark (Hrsg.): InfoBus 1.2 Specification. http://java.sun.com/

beans/infobus/spec12/IB12Spec.html, Sun Microsystems, Inc, 1999-02, Abruf am 2000-04-13.

[Com00] Microsoft COM Technologies Homepage. http://www.microsoft.com/

com/default.asp, 2000-06-01, Abruf am 2000-07-10. [Corb99] Ohne Verfasser: What Is CORBA? http://cgi.omg.org/corba/

whatiscorba.html, 1999, Abruf am 2000-02-18. [Corb00] Ohne Verfasser: The Common Object Request Broker: Architecture

and Specification, Revision 2.2. http://cgi.omg.org/cgi-bin/doc?formal/ 98-07-01.pdf, Object Management Group, Inc., 1998-02, Abruf am 2000-04-04.

Anhang: Literaturverzeichnis

116

[Dai97] Dai, Fan: Lebendige virtuelle Welten: physikalisch-basierte Modelle in Computeranimation und virtuelle Realität. Springer, Berlin 1997.

[Delp00] Delphi Homepage von Borland. http://www.borland.de/delphi/

index.html, 2000-01-04, Abruf am 2000-07-10. [Dirx00] DirectX Hompage von Microsoft. http://www.microsoft.com/

directx/default.asp, 2000-02-04, Abruf am 2000-07-28. [Doer99a] Dörner, Ralf et al.: Tools To Support Emergency Training. Project

deliverable D1.3 of the ETOILE project of the European Commission, EU Esprit Project-No. 29086, Fraunhofer Institut für Graphische Datenverarbeitung, Darmstadt 1999.

[Doer99b] Dörner, Ralf et al.: The Designs of the Tool-Set. Project deliverable

D3.1 of the ETOILE project of the European Commission, EU Esprit Project-No. 29086, Fraunhofer Anwendungszentrum Computergraphik in Chemie und Pharmazie, Frankfurt 1999.

[DoGr00] Dörner, Ralf; Grimm, Paul: Three-dimensional Beans - Creating Web

Content Using 3D Components In a 3D Authoring Environment. In: Spencer, Stephen N.(Hrsg.): Proceedings Web3D – VRML 2000, Fifth Symposium on the Virtual Reality Modeling Language, ACM Press, New York 2000. S. 69 – 74.

[Ecke98] Eckel, Bruce: Thinking in Java. 1. Aufl. Prentice Hall, 1998.

http://www.eckelobjects.com/javabook.html [Flan99] Flanagan, David: Java in a Nutshell. 3. Aufl. O'Reilly & Associates,

Inc., Sebastopol 1999. [Full00] Hompage des OpenFLT-Loaders von Full Sail Real World Education.

http://www.fullsail.com/loader, 2000-03-17, Abruf am 2000-04-13. [Gabb97] Gabbard, Jospeph L. et al: A Taxonomy of Usability Characteristics in

Virtual Environments. Deliverable to Office of Naval Research, Grant No. N00014-96-1-0385, 1997. http://csgrad.cs.vt.edu/~jgabbard/ve/taxonomy/

[Gabb99] Gabbard, Joseph L. et al.: User-Centered Design and Evaluation of

Virtual Environments. In: IEEE Computer Graphics & Applications 19 (1999) 6, S. 51 – 59. http://csgrad.cs.vt.edu/~jgabbard/ve/documents/vr99.pdf

[Glid00] Glide Homepage von 3dfx. http://www.3dfx.com/developers/

glidesdk/glsdk-intro.html, 1999-12-03, Abruf am 2000-07-28.

117

[Goer97] Görner, Claus et al.: Dialogbausteine: Ein Konzept zur Verbesserung der Konformität von Benutzungsschnittstellen mit internationalen Standards. In: Liskowsky, Rüdiger (Hrsg.): Berichte des German Chapter of the ACM 49: Software-Ergonomie '97. Teubner, Stuttgart 1997, S.157-165.

[Hain00] Haines, Gary, Capt. et al.: Component-Based Software Development /

COTS Integration. http://www.sei.cmu.edu/str/descriptions/cbsd.html, Software Engineering Institute, Carnegie Mellon University, 1997-10-07, Abruf am 2000-02-18.

[Hami00] Hamilton, Graham (Hrsg.): JavaBeans API Specification, Version 1.01.

http://java.sun.com/beans/docs/spec.html, Sun Microsystems, Inc., 1997-07-24, Abruf am 2000-03-01.

[Isda00] Isdale, Jerry: What is Virtual Reality. http://www.isx.com/~jisdale/

WhatIsVr.html, 1998-09, Abruf am 2000-02-29. [Java00] Java Homepage von Sun. http://java.sun.com, 2000-07-28, Abruf am

2000-07-30. [Ja3d00] Java 3D Homepage von Sun. http://www.javasoft.com/products/

java-media/3D/index.html, 2000-07-28, Abruf am 2000-07-30. [Jbui00] Jbuilder Homepage von Borland. http://www.borland.de/jbuilder/

index.html, 2000-03-21, Abruf am 2000-07-10. [Lee00] Lee, Dennis: A Component Road Map. http://www.sjug.org/

component.html, 1999-04-30, Abruf am 2000-03-16. [Lin99] Lin, Fuhua et al.: An Agent-based Approach to Developing Intelligent

Virtual Reality-based Training Systems. In: Proceedings of the 11th IEEE International Conference on Tools with Artificial Intelligence, 1999, S. 253 – 260.

[MaGe96] Mazuryk, Tomasz; Gervautz, Michael: Virtual Reality - History,

Applications, Technology and Future. Institut für Computergraphik, Technische Universität Wien, 1996. http://www.cg.tuwien.ac.at/research/TR/96/TR-186-2-96-06Abstract.html

[MoLi00] Morris, Ed, Litvak, Emil: Component Object Model (COM), DCOM,

and Related Capabilities. http://www.sei.cmu.edu/str/descriptions/ com.html, Software Engineering Institute, Carnegie Mellon University, 1997-06-23, Abruf am 2000-02-18.

[Ncsa00] Hompage des NCSA Portfolio der NCSA Java3D Group.

http://www.ncsa.uiuc.edu/~srp/Java3D/portfolio/index.html, 1999-10-01, Abruf am 2000-05-12.

Anhang: Literaturverzeichnis

118

[Ober00] Oberndorf, Tricia: COTS and Open Systems -- An Overview. http:// www.sei.cmu.edu/str/descriptions/cots.html, Software Engineering Institute, Carnegie Mellon University, 1997-08-07, Abruf am 2000-02-18.

[Ogvs99] Ohne Verfasser: OpenGVS Programming Guide V4.3. Dokumentation

des OpenGVS SDK 4.3, Quantum3D, Inc. – OpenGVS Development Center, 1999.

[Ogvs00] OpenGVS Homepage von Quantum3D. http://www.opengvs.com/

opengvs/index.html, 2000-07-13, Abruf am 2000-07-28. [Omg00] Hompage der Object Management Group. http://www.omg.org,

2000-07-17, Abruf am 2000-07-28. [Open00] Ohne Verfasser: OpenFlight Specification v15.6.0.

http://www.multigen.com/ products/pdf_files/of156.pdf, MultiGen-Paradigm, Inc., 1998-07-31, Abruf am 2000-02-25.

[Opgl00] OpenGL Homepage. http://www.opengl.org, 2000-07-28, Abruf am

2000-07-28. [Posw96] Poswig, Jörg: Visuelle Programmierung: Computerprogramme auf

graphischem Weg erstellen. Hanser, München 1996. [Prog00] Prograph Homepage von Taylor Design. http://www.taylor-design.

com/DataLink/Home.htm. 2000-04-06, Abruf am 2000-06-03. [Quan00] Homepage von Quantum3D. http://www.quantum3d.com,

2000-07-14, Abruf am 2000-07-28. [Real00] Homepage der REALAX AG. http://www.realax.com, 2000-03-21,

Abruf am 2000-07-10. [Rein99] Reinhold, Silvan: Eine dreidimensionale Beanbox. Studienarbeit,

Fachbereich Informatik, Technische Universität Darmstadt, Sommersemester 1999.

[RiJo98] Rickel, Jeff; Johnson, W. Lewis: STEVE: A Pedagogical Agent for

Virtual Reality. In: Katia P.; Sycara, Michael Wooldridge (Hrsg): Proceedings of the Second International Conference on Autonomous Agents, ACM Press, New York 1998, S. 332-333. http://www.isi.edu/isd/VET/agents98-distribution.pdf

[Rudo00a] Rudolph, Mark: Jamal: Components Frameworks and Extensibility.

http://www.web3d.org/TaskGroups/x3d/lucidActual/jamal/Jamal.html, 1999-08-30, Abruf am 2000-07-24.

119

[Rudo00b] Rudolph, Mark: X3DComponents. http://www.web3d.org/TaskGroups/ x3d/lucidActual/X3DComponents/X3DComponents.html, 1999-12-16, Abruf am 2000-07-24.

[ScAs00] Schmidt, R.; Assman, U.: Concepts for Developing Component-Based

Systems. http://www.sei.cmu.edu/cbs/icse98/papers/p12.html, 1998-04-25, Abruf am 2000-03-16.

[Sowi99] Sowizral, Henry A. und Deering, Michael. F.: The Java 3D API and

Virtual Reality. In: IEEE Computer Graphics and Applications 19 (1999) 3, S.12-15.

[Sowi00] Sowizral, Henry et al.: Java 3D API Specification, Version 1.1.2.

http://java.sun.com/products/java-media/3D/forDevelopers/j3dguide/ j3dTOC.doc.html, Sun Microsystems, Inc., 1999-06, Abruf am 2000-02-01.

[Stn00] Homepage von STN Atlas Elektronik. http://www.stn-atlas.de,

2000-06-30, Abruf am 2000-07-10. [StWe00] Stührmann, K.; Westphal, J.: VR User Manual. Project deliverable

D3.2 of the ETOILE project of the European Commission, EU Esprit Project-No. 29086, STN Atlas Elektronik, Bremen 2000.

[Thom98] Thomas, Anne: Enterprise JavaBeans Technology: Server Component

Model for the Java Platform. http://java.sun.com/products/ejb/ white_paper.html, 1998-12, Aufruf am 2000-04-06.

[Vinc98] Vince, John: Essential virtual reality fast: how to understand the

techniques and potential of virtual reality. Springer, London 1998. [Visu00] Visual Basic Homepage von Microsoft. http://msdn.microsoft.com/

vbasic/default.asp, 2000-07-17, Abruf am 2000-07-28. [Xml00] XML.ORG Hompage der Organization for the Advancemant of

Structured Information Standards (OASIS). http://www.xml.org, 2000-07-19, Abruf am 2000-07-24.

[Youn00] Young, Peter: Virtual Reality Systems. http://www.dur.ac.uk/~dcs0zz6/

pages/work/documents/lit-survey/VR-Survey/VR-Survey.ps.gz, 1996-02-06, Abruf am 2000-04-14.

Documents

Konzeption und Realisierung der Integration einer ... · Konzept integriert werden kann, befaßt sich der nächste Abschnitt mit Grundlagen der Benutzungsfreundlichkeit und visueller