Am Ende des Tunnels wartet das Licht aber hier draußen gibt's kein zurück ... Bleib wo Du bist aus: "Ton Steine Scherben IV" Ton Steine Scherben, (1981)

3	Lösungsansatz

In diesem Abschnitt wird die Beschreibung eines speziellen Lösungsansatzes für eine verteilte virtuelle Umgebung erfolgen. Eine verteilte virtuelle Umgebung, wie sie das Voodie System unterstützen soll, läßt sich in verschiedene Problemkategorien einteilen: Objektdefinition Für die Konstruktion von virtuellen Umgebungen ist die Definition von Objekten und deren Verhalten die wesentliche Aufgabe. Wird die Objektdefinition vom eigentlichen Kern getrennt, lassen sich die Objekte einfacher und flexibler erstellen und testen. Im Prototyp besitzen die Objekte nur minimales Verhalten. Dieses Verhalten wird durch die Implementation der jeweiligen Objektklasse festgelegt. Objektkommunikation Die Kommunikation zwischen einzelnen replizierten Objekten ist die wesentliche Grundlage für den Aufbau einer verteilten virtuellen Umgebung. In dieser Arbeit werden entsprechende Mechanismen vorgestellt. Objektinteraktion Eine wesentliche Aufgabe des Systems wird die Feststellung und Auflösung von Objektinteraktionen sein, da erst die Interaktionen zwischen Objekten eine virtuelle Umgebung wirklich nutzbar machen. Es werden grundsätzliche Ansätze zur Lösung des Interaktionsproblems vorgestellt. Objekttransport Der Transport von Objekten von einer Station zu einer anderen muß gelöst werden, damit die Mechanismen zur dezentralen Objektverwaltung effizient einsetzbar sind. Die Möglichkeit des Objekttransportes muß bei der Art der Objektdefinition beachtet werden. Verteilungsstrategie Die Bestandsanalyse hat gezeigt, daß die Netzwerkbelastung ein nicht zu unterschätzender Faktor für verteilte virtuelle Umgebungen ist. Neben Mechanismen zur Objektkommunikation müssen deshalb auch Überlegungen zur Verteilung der Informationen und der Rechenlast auf die beteiligten Stationen angestellt werden. Ein- und Ausgabe Die Visualisierung und die Anbindung von VR spezifischen Eingabegeräten (z.B. System zum Positionsfeststellung - Trackingsystem, 6 DOF Eingabegeräte) ist eine weitere, für die Akzeptanz des Systems, sehr wesentliche Aufgabe.

In dieser Arbeit können bei weitem nicht alle Mechanismen, die für ein solches System notwendig sind, bis ins letzte Detail vorgedacht, geschweige denn implementiert werden. Deshalb sind viele der beschriebenen Ideen lediglich als Lösungsvorschläge zu betrachten, die als Basis für weitere Forschungstätigkeit dienen können. In Abbildung 2 sind die einzelnen Problemkategorien zusammenfaßt. Dabei sind die Aspekte, die im Prototyp implementiert wurden, dunkel dargestellt.

3.1	Unabhängige Welten

	Der Begriff Welt wird als Synonym für die virtuelle Umgebung eines Teilnehmers benutzt. Ein Teilnehmer sieht seine Umgebung als (seine virtuelle) Welt.
zentrale Objekt- verwaltung	Die Systeme, bei denen eine zentrale Verwaltung der virtuellen Umgebung vorgenommen wird, haben das Problem, daß sich jeder Teilnehmer mit dieser zentralen Instanz verbinden muß, um Daten mit ihr auszutauschen.
	Bei einer zentralen Objektverwaltung muß an irgendeiner Stelle etwas wie eine zentrale Datenbank vorhanden sein, in der die Informationen der Welt unabhängig von den Betrachtern aufbewahrt und ggf. auch bearbeitet (Objekte mit zeitlich veränderten Eigenschaften, Simulationen) werden. Problematisch ist natürlich, wie die Teilnehmer und die zentrale Datenbank einerseits nur minimal miteinander kommunizieren sollen, andererseits aber auch alle Teilnehmer ein einheitliches, synchrones und konsistentes Bild der Welt (oder des Teiles der Welt, der für sie relevant ist) haben sollen. Dies führt in jedem Fall zu einer prinzipiellen Begrenzung des Systems durch die zentrale Instanz.
dezentrale Objekt- verwaltung	Um die Skalierbarkeit einer verteilten virtuellen Umgebung zu gewährleisten, sollte neben dem Einsatz von Methoden zur Verringerung der Netzwerklast und des Kommunikationsaufwandes, vor allem über die dezentrale Verwaltung der Umgebung nachgedacht werden. Jeder zentralisierte Ansatz beinhaltet immer die Gefahr der Entstehung eines Engpasses. Demgegenüber besteht bei dezentralen Ansätzen das Problem der Synchronisation und der Konsistenz der gemeinsamen Umgebung.
	Trotzdem ist ein dezentraler Ansatz bei der Objektverwaltung besser geeignet, die Anforderungen an verteilte virtuelle Umgebungen zu erfüllen, da synchronisierte, dezentrale Datenhaltung zwar komplizierter umzusetzen ist, in jedem Fall aber besser skaliert als eine zentrale Verwaltung der gesamten virtuellen Umgebung. Deshalb wird folgende Lösung vorgeschlagen: Für jeden Teilnehmer existiert eine eigene virtuelle Umgebung (eine eigene Welt), die prinzipiell unabhängig von den Welten anderer Teilnehmer ist. Jeder Teilnehmer besitzt eine eigene Objektverwaltung, die direkt an seinen Avatar gekoppelt ist. Diese Objektverwaltungsinstanz ist für die Verwaltung der Objekte zuständig, die sich in einem gewissen räumlichen Einzugsbereich um den Avatar des Teilnehmers befinden. Diese Vorgehensweise begründet sich auf der Annahme, daß nur die Objekte für einen Teilnehmer relevant sind, die sich eben in einer gewissen endlichen Entfernung um ihn herum befinden (vgl. AVIARY, ab Seite 25 und /SNO94/), er diese Objekte also sehen kann.. Der Begriff "Sehen" kann in diesem Zusammenhang als spezielle Interaktion verstanden werden. Greenhalg und Benford beschreiben in MASSIVE (/GRE95/) ein räumliches Interaktionsmodell, bei dem davon ausgegangen wird, daß jede Art von Interaktion an räumliche Nähe gekoppelt sein muß. Die Idee eines räumlichen Einzugsgebietes ist also auch auf andere Interaktionsformen anwendbar. Wenn sich nun die räumlichen Einzugsbereiche zweier Teilnehmer überlappen, besteht die Möglichkeit, daß ein Objekt von den zwei Teilnehmern gemeinsam genutzt wird, d.h. in den Welten beider Teilnehmer synchron existiert. Das bedeutet, beide Teilnehmer können mit diesem Objekt interagieren. Gleichermaßen wird durch solche Objekte die Kommunikation zwischen den Teilnehmern möglich. Praktisch wird dabei das Objekt von einem der Teilnehmer generiert, der andere Teilnehmer abonniert das Objekt. Durch ein solches Abonnement wird eine Instanz des Objektes in der Welt des Abonnenten erzeugt. Diese Instanz kommuniziert selbständig mit der Hauptinstanz des Objektes und synchronisiert sich dadurch mit dieser. Die Objektverwaltung jedes Teilnehmers behandelt dabei alle Objekte (lokale und abonnierte) gleich. Sie generiert Nachrichten und Ereignisse, mit denen die Objekte über Interaktionen (z.B. Kollisionen) mit anderen Objekten informiert werden. Abbildung 3 und Abbildung 4 sollen das Prinzip der unabhängigen Welten verdeutlichen. In Abbildung 3 ist die Sicht auf die gesamte virtuelle Umgebung dargestellt. Für keinen der Teilnehmer A, B, C und D ist diese Gesamtsicht auf die virtuelle Umgebung möglich. Abbildung 4 zeigt die Erscheinungen der virtuellen Umgebung für die einzelnen Teilnehmer. Für jeden Teilnehmer ist lediglich ein gewisser Teil der gesamten Umgebung sichtbar. In Abbildung 5 wird die entsprechende Kommunikationstopologie, die zwischen den Teilnehmern besteht, dargestellt. Es ist erkennbar, daß z.B. zwischen den Teilnehmern A und D keine Verbindung besteht, da diese Teilnehmer sich nicht sehen können. Die Topologie kann sich aber jederzeit ändern, z.B. wenn sich der Teilnehmer A in den Sichtbereich des Teilnehmers D hinein bewegt. Dann muß auch eine Verbindung zwischen den Teilnehmern A und D hergestellt werden. Wichtig ist bei diesem Ansatz eine Definition der Position der Teilnehmer. Diese Definition muß global sein. Die Positionen der Teilnehmer (und ihrer Welten) muß aber nicht unbedingt an einer zentralen Stelle verwaltet werden. Jeder Teilnehmer könnte sich z.B. im Mittelpunkt seines eigenen (lokalen) Koordinatensystems befinden und die Objekte anderer Teilnehmer in sein eigenes Koordinatensystem einbauen (also die Positionen entsprechend transformieren). Kommt ein globales Koordinatensystem zum Einsatz, so sind die räumlichen Relationen der Teilnehmer zueinander festgelegt. Eine zentrale Verwaltung wird aber auch in diesem Fall überflüssig, wenn Situationen, in denen Objekte verschiedener Teilnehmer denselben Platz im virtuellen Raum einnehmen, durch geeignete Maßnahmen (z.B. Transformationsvorschriften) verhindert werden.

3.2	Autonome Objekte

	Sämtliche Bestandteile einer virtuelle Umgebungen können als autonome, dreidimensional darstellbare Entitäten angesehen werden. Diese Entitäten werden auch als Objekte der virtuellen Umgebung bezeichnet. Prinzipiell ist es in jeder verteilten virtuellen Umgebung notwendig, die Daten der beteiligten Stationen zu synchronisieren. Die implementierten Kommunikationsmechanismen gehen von der Grundidee aus, daß ein Objekt, das von mehreren Stationen gemeinsam benutzt werden soll, auf jeder dieser Stationen als separates, eigenständiges Objekt vorhanden ist. Jede eigenständige Welt besteht aus solchen autonomen Objekten. Diese Objekte können selbständig ihre Eigenschaften ändern. Dies geschieht durch Mechanismen, die objektspezifisch sind (Simulationsobjekte). Die Kommunikation zwischen einzelnen Objekten erfolgt durch das Senden und Empfangen von Ereignissen. Ein Ereignis (Event) beinhaltet eine bestimmte Information, die von einem Absender an einen Empfänger geschickt wird.
Objekt- gruppen	Objekte verschiedener Stationen können miteinander verbunden sein, sich also synchronisieren. Prinzipiell erfolgt die Synchronisation des gesamten Systems über solche verbundenen Objekte. Ein gemeinsam benutztes Objekt ist im Voodie System als Gruppe verteilter, voneinander abhängiger Objekte anzusehen, die ihre Erscheinung selbst bestimmen, aber durch eine (für diese Gruppe) zentrale Instanz synchronisiert werden. Im folgenden wird jede Menge solcherart verbundener Objekte als Objektgruppe bezeichnet.
Abonnement- mechanismus	Um verbundene Objekte bzw. Objektgruppen einsetzen zu können, wird ein Abonnementmechanismus eingeführt.
	Die Synchronisation innerhalb einer Objektgruppe wird über den Austausch von Synchronisationsereignissen erreicht. In jeder Gruppe abhängiger Objekte existiert genau ein Masterobjekt. Dieses Objekt besitzt die Kontrolle über die Objektgruppe, d.h. über dieses Objekt erfolgt die Synchronisation. Alle anderen Objekte der Gruppe sind Slaveobjekte. Das Masterobjekt schickt bei Bedarf an alle registrierten Slaveobjekte Synchronisationsereignisse. Die Slaveobjekte können auch als Abonnenten des Masterobjektes angesehen werden. Der Mechanismus sieht weiterhin die Möglichkeit vor, daß ein Abonnent selbst wieder Abonnenten besitzen darf. Dadurch ist prinzipiell jedes Objekt abonnierbar, egal ob dieses Objekt Masterobjekt ist oder nicht. Ein Slaveobjekt kann also seine Synchronisationsevents direkt vom Masterobjekt der Gruppe beziehen, oder aber es erhält seine Synchronisationsevents von einem anderen Slaveobjekt. Das Objekt welches die Synchronisationsereignisse sendet, wird dabei als Abomasterobjekt bezeichnet.
Abonnement- ketten	Durch diese Erweiterung des Mechanismus können Abonnementketten aufgebaut werden. In solchen Abonnementketten sendet ein Masterobjekt Synchronisationsereignisse an ein Slaveobjekt. Dieses Slaveobjekt sendet das Synchronisationereignis an seine Abonnenten, diese ggf. an ihre Abonnenten usw. Der Mechanismus stellt dabei sicher, daß am Anfang jeder Abonnementkette das Masterobjekt der Gruppe steht.
	Abbildung 6 zeigt Master-, Slave-, Abomaster- und Abonnentobjekte nochmals im Zusammenhang. In der Abbildung sind weiterhin Abonnementketten und direkte Abonnierung zu sehen. Wesentlich ist bei der Abbildung, daß die Objekte eine Objektgruppe bilden, also alle eingezeichneten Objekte das gleiche Objekt auf verschiedenen Stationen darstellen. Im Abschnitt 3.3 (ab Seite 43) werden die Vor- und Nachteile des Einsatzes von Abonnementketten bzw. direkter Abonnierung näher beschrieben. Die Abhängigkeit der Slaveobjekte vom Masterobjekt kann von sehr eng bis sehr lose variieren. Eine sehr enge Abhängigkeit wäre z.B. gegeben, wenn das Masterobjekt jede Änderung seiner Attribute an die Slaveobjekte weitergibt. Eine lose Abhängigkeit tritt dann auf, wenn die Slaveobjekte ihr Verhalten durch Verhaltensvorschriften autonom bestimmen können und das Masterobjekt nur in Ausnahmefällen Synchronisationsereignisse senden muß. Die Festlegung, wie häufig Synchronisationsereignisse auftreten, hängt von der Art des Objektes ab und ist Bestandteil des Objektverhaltens.

3.2.1

Objektinformigramme

	Ein Problem beim Ansatz der verbundenen Objekte ist der Austausch von Informationen über die Existenz und Lokalität von Objekten in anderen Welten.
Definition der OI	Deshalb werden Objektinformigramme (OI) eingeführt. Solche OI beschreiben, ähnlich wie ein URI (/LEE94a/), die Position eines Objektes im Netzwerk. Neben dieser netzwerkbezogenen Information enthält ein OI auch andere allgemeine, statische Daten. OI könnten auch als kleine statische Varianten eines - von der Informationsmenge her gesehen - größeren Objektes angesehen werden. Die OI können nun sehr einfach und schnell von einer Station an eine andere übertragen werden. Damit ist es möglich, daß ein Teilnehmer gewissermaßen eine Vorschau auf die Welt eines anderen Teilnehmers erhält.
	Ein OI enthält Informationen über die Maschine auf der sich die Hauptkomponente des Objektes befindet und eine Objektidentifizierung (analog URI). Weiterhin beinhaltet es Informationen zur Art des Objektes (Typ) und es sollte mindestens eine allgemeine, statische Geometriebeschreibung (Form, Größe, Position) enthalten sein.

3.2.2

Objektabonnement

Es ist nun folgendes Szenario vorstellbar: Ein Teilnehmer kennt lediglich die Adresse einer zweiten Station im Netzwerk, die Objekte zur gemeinsamen Nutzung zur Verfügung stellt. Die rufende Station stellt nun eine Verbindung her und fordert in einem ersten Schritt die OI aller freigegebenen (abonnierbaren) Objekte an. Die OI werden auf jeder Station von einem eigenständigen Modul, dem OI-Verwalter bzw. OI-Objekt verwaltet. Nachdem die OI übertragen wurden, kann in einem zweiten Schritt die rufende Station nun Abonnentin eines oder mehrerer Objekte werden. Ein Abonnent erzeugt auf seiner lokalen Station Kopien der entsprechenden Objekte. Diese Kopien tauschen mit einer Hauptinstanz (gewissermaßen das Original, das Masterobjekt) Daten zur Synchronisation aus. Diese Kopien könnten auch als entfernte oder abonnierte Komponenten des Masterobjektes bzw. als Slaveobjekte bezeichnet werden (vgl. Clones in Waves / Hidra, ab Seite 28). Der Abonnementmechanismus wird im Rahmen der Beschreibung der Prototypimplementation noch detaillierter vorgestellt werden (Abschnitt 4.6, ab Seite 59).

3.2.2

Übergang der Objektkontrolle

	Natürlich ist die starre Aufteilung in Haupt- und Abonnementkomponente nachteilig. Die Grundidee bei der Einführung der dezentralen Objektverwaltung war, daß auf jeder Station nur die Objekte vorhanden sind, die zur Visualisierung der unmittelbaren Umgebung des Teilnehmers notwendig sind. Bewegt sich ein Objekt aus dem Sichtbereich eines Teilnehmers, so sollte es gelöscht werden. Das Objekt kann aber nicht gelöscht werden, wenn es das Masterobjekt einer Objektgruppe ist, da sonst keine Synchronisation mehr erfolgen würde. Die Festlegung, wer in einer Objektgruppe Master- bzw. Slaveobjekt ist, wird deshalb nicht statisch getroffen, sondern ist dynamisch änderbar. Die Kontrolle über ein Objekt muß vom jeweiligen Masterobjekt an ein entferntes Slaveobjekt übertragen werden können. Um diese Übertragbarkeit zu erreichen, beinhaltet jedes Objekt die Funktionalitäten sowohl des Master- als auch des Slaveobjektes. Wenn zwei Teilnehmer ein Objekt gemeinsam benutzen, dann existiert dieses Objekt also bei beiden Teilnehmern in der gleichen Art und Weise. Durch die Identität von Master und Slaveobjekten ist es möglich, die Übergabe der Objektkontrolle durch den Austausch von Ereignissen zu realisieren. Wenn das Masterobjekt gelöscht werden soll, übergibt dieses Objekt die Objektkontrolle an einen seiner Abonnenten und sendet entsprechende Nachrichten an alle anderen Abonnenten. Die Abonnenten stellen dann eigenständig eine Verbindung mit dem neuen Masterobjekt her. Es sind allerdings auch Fälle denkbar, in denen die Objektkontrolle nicht übertragen werden kann. Die Implementierung der Objekte muß diese Fälle entsprechend behandeln. Wenn zusätzlich alle Abonnenten Kenntnis voneinander hätten, wäre auch ohne eine explizite Nachricht des Masterobjektes ein Übergang der Koordinierung realisierbar. Ist die Kommunikation mit dem Hauptobjekt nicht mehr möglich, so übernimmt das nächstjüngere Objekt diese Aufgabe. Diese Vorgehensweise bringt aber zusätzlichen Kommunikations- und Verwaltungsaufwand mit sich, da alle Mitglieder einer Objektgruppe die Objekte der gesamten Objektgruppe kennen müssen. In der jetzigen Implementierung ist diese Möglichkeit deshalb nicht vorgesehen. Ein Objekt kennt lediglich seine Abonnenten und sein Abomasterobjekt. Die Slaveobjekte besitzen keine Informationen darüber, welches Objekt das Masterobjekt der Objektgruppe ist. Es existieren verschiedene Gründe, den Übergang der Objektkontrolle von einem Masterobjekt zu einem Slaveobjekt zu ermöglichen:
[G1]	Das Masterobjekt sollte die Kontrolle der Objektgruppe an ein Slaveobjekt abgeben, wenn es sich nicht mehr im unmittelbaren Einzugsbereich einer Station befindet.
	Es sind durchaus bewegliche Objekte denkbar, die sich selbständig durch die virtuelle Umgebung bewegen. Hier ist leicht einzusehen, daß die Objektkontrolle sinnvollerweise an ein anderes Objekt der Objektgruppe übergeben werden sollte, wenn sich das Masterobjekt sehr weit von der Station entfernt hat, auf der es residiert und deshalb dort nicht mehr sichtbar ist. Ein solches, unsichtbares Objekt muß von dieser Station nicht mehr verwaltet werden. Hat das Masterobjekt die Objektkontrolle abgegeben, wird es zu einem Slaveobjekt und kann aus der Welt dieses Teilnehmers gelöscht werden. In den Welten anderer Teilnehmer existiert dieses Objekt aber weiterhin. An dieser Stelle tritt das Problem auf, daß Fälle konstruierbar sind, in denen ein Objekt für keinen der Teilnehmer sichtbar ist. Die Objektkontrolle kann in diesem Fall nicht übergeben werden, da keine weiteren Slaveobjekte vorhanden sind. Solche Masterobjekte residieren dann solange auf ihrer aktuellen Station weiter, bis sie in den Sichtbarkeitsbereich einer anderen Station eintreten. Diese Station abonniert dann dieses Objekt. Nun kann Objektkontrolle übertragen werden und das Objekt wird aus der Welt des Teilnehmers, für den es unsichtbar ist, entfernt.
[G2]	Das kontrollierende Objekt sollte die Kontrolle abgeben, wenn es gelöscht werden soll.
	Diese Forderung ist dann sinnvoll, wenn ein Objekt nicht vollständig aus der virtuellen Umgebung entfernt werden soll, sondern lediglich von einer der beteiligten Stationen nicht mehr benötigt wird, bzw. diese Station aus der virtuellen Umgebung ausscheidet.
[G3]	Kontrollierendes Objekt sollte immer dasjenige Objekt sein, welches den meisten Interaktionen mit anderen Objekten ausgesetzt ist.
	Es ist abzusehen, daß die Interaktion zwischen verschiedenen Objekten durch die jeweiligen Masterobjekte, bzw. die Stationen auf denen das Masterobjekt residiert, realisiert wird. Slaveobjekte geben Interaktionswünsche an ihr jeweiliges Masterobjekt weiter (ggf. über verschiedene Abomasterobjekte). Das Masterobjekt einer Objektgruppe sollte deshalb bei dem Teilnehmer residieren, in dessen Sichtbereich die meisten Objekte vorhanden sind. Es ist wahrscheinlich, daß bei diesem Teilnehmer die meisten Interaktionen auftreten werden. Dadurch kann der bei der Interaktion anfallende Kommunikationsaufwand und die sich ergebende Verzögerung gering gehalten werden.
Erweiterung der OI (Redirection)	Das Konzept der OI muß mit der Einführung des Übergangs der Objektkontrolle auch entsprechend erweitert werden. Wenn ein Teilnehmer mit Hilfe eines OI auf ein Objekt zugreifen will, wird eine Verbindung zur entsprechenden Station aufgebaut. Der Interaktionsdämon des Teilnehmers (der Maschine), auf den der OI verweist, leitet die Anforderung an das entsprechende Objekt weiter. Wenn das Objekt nicht mehr existiert - weil es sich z.B. aus dem Sichtbarkeitsbereich des Teilnehmers heraus bewegt hat und deshalb gelöscht wurde - muß eine Art Redirection-Mechanismus angewandt werden. Der Interaktionsdämon hält zu diesem Zweck über die Lebenszeit aller Objekte hinaus Informationen darüber bereit, wo das Objekt (oder besser ein Objekt der entsprechenden Objektgruppe) zu finden ist. Mit "alle Objekte" sind hierbei die Objekte gemeint, von denen zumindest einmal ein OI gesendet wurde. Dieser Service wird als dynamische Liste von Objektinformigrammen ausgelegt, da die OI alle notwendigen Informationen enthalten. Ein Redirect könnte dann durch das Senden eines aktualisierten OI erfolgen. Der Service sollte zeitlich begrenzt sein.
	Wenn ein entfernter Teilnehmer nun ein Objekt abonnieren will, das sich nicht mehr auf dieser Maschine befindet, kann durch den Redirection-Mechanismus ein entsprechend aktualisierter Verweis zurückgesandt werden. Das Slaveobjekt, welches das Abonnement gewünscht hat, sollte nun in der Lage sein, ein entsprechendes Objekt zu finden. Wenn keine Informationen zu einem Objekt vorliegen, muß ein entsprechendes Fehlerereignis generiert werden bzw. das Slaveobjekt, von dem der Abonnementimpuls ausging, reagiert nach einer gewissen Zeit eigenständig.

3.2.3

Objekttransport

	Die Erzeugung eines Objektes auf einer Voodie Station kann als Transport dieses Objektes über das Netzwerk angesehen werden. Für diesen Transport sind zwei Wege denkbar:
[A1]	Es werden vorgefertigte Bibliotheken mit Standardobjekten benutzt.
[A2]	Es wird Objektcode von einer Station zu einer anderen übertragen.
	Die Bibliotheksvariante hat den Vorteil, daß lediglich der Typ des Objektes und ggf. Initialisierungsparameter übertragen werden müssen. Nachteilig ist, daß diese Art der Objekterzeugung voraussetzt, daß auf allen Stationen die entsprechenden Objektbibliotheken vorhanden sind. Die zweite Variante ermöglicht ein sehr flexibles System, welches unproblematisch erweiterbar ist. Interpretierte Objekte haben weitere Vorteile:
[B1]	Umgebungs- und Objektdaten werden von den Verwaltungsmodulen getrennt.
[B2]	Objekte unbekannter Klassen können zur Laufzeit generiert werden, da der Transport zur Laufzeit interpretierbarer Daten über das Netzwerk sehr einfach möglich ist.
	Zur Umsetzung wird eine Möglichkeit benötigt, Voodie Objekte geeignet zu beschreiben. Diese Objektbeschreibung muß nicht nur die Attribute eines Voodie Objektes beinhalten, sondern vor allen Dingen eine Beschreibung des Objektverhaltens und die Funktionalitäten zur Eventbehandlung. Erst dann ist eine wirklich flexible Arbeit mit dem System möglich. Als Lösungsmöglichkeiten für dieses Problem sollten folgende Wege in Betracht gezogen werden:
[C1]	Objektdefinition in einer interpretierten Programmiersprache.
	Vorteil: Interpretierte Programmiersprachen sind als bekannte und erprobte Programmiersprachen existent. Die Integration eines Interpreters sollte relativ einfach möglich sein. Nachteil: Es müssen wahrscheinlich systemspezifische Erweiterungen definiert werden, die eine effiziente Implementation der Objekte ermöglicht.
[C2]	Objektdefinition in einer eigens zu entwickelnden Beschreibungssprache.
	Vorteil: Die Beschreibungssprache kann so definiert werden, daß sie den Anforderungen des Voodie Systems optimal genügt. Nachteil: Der Aufwand, eine Beschreibungssprache und einen entsprechenden Interpreter zu entwickeln, ist relativ hoch.

3.2.5

Zusammenfassung

Die verteilte virtuelle Umgebung besteht aus Objekten. Diese Objekte sind einzelnen Stationen zugeordnet. Nutzer treten in die Umgebung über Stationen ein. Jede Station kann lediglich die Objekte der verteilten Umgebung darstellen, die aktuell auf dieser Station vorhanden sind. Objekte können repliziert werden. Die Replikation erfolgt über einen Abonnementmechanismus. Bedingte Abonnierung kann mit Hilfe der Objektinformigramme realisiert werden. Replizierte Objekte bilden eine Objektgruppe. Dabei existiert immer ein Objekt, welches die Objektkontrolle besitzt. Replizierte Objekte müssen sich synchronisieren. Die Synchronisation ist Aufgabe der Objekte, d.h. ein Objekt entscheidet selbst, ob und wieviel Synchronisationsnachrichten (UPDATE Events) es an andere (replizierte) Objekte sendet.

3.3	Kommunikationsprinzip

	Die Kommunikation im System erfolgt auf der Basis von Punkt-zu-Punkt Kommunikation zwischen den Stationen bzw. zwischen den Objekten. Diese Art der Kommunikation wird verwendet, weil sie am besten für ein dezentral organisiertes System geeignet ist. Wie bereits beschrieben, ist in diesem Fall aber eine Beschränkung der Anzahl der Punkt-zu-Punkt Verbindungen notwendig. Im Folgenden soll ein Ansatz vorgestellt werden, der eine solche Begrenzung ermöglicht.
Eventrouting	Wird eine Umgebung betrachtet, die aus n Stationen besteht, jede dieser Stationen jeweils ein Objekt verwaltet und alle Objekte auf allen anderen Stationen als Replikanten (Slaveobjekte) vorliegen, so können die folgenden Extremszenarien unterschieden werden.
Fall A:	Wenn jedes Slaveobjekt seine Synchronisationsimpulse direkt vom Masterobjekt erhält, sind pro Synchronisationstakt von jeder Station (n-1) Synchronisationsereignisse an (n-1) andere Stationen zu schicken. Insgesamt existieren also ½n(n-1) Punkt-zu-Punkt Verbindungen zwischen den n Stationen. Abbildung 7 zeigt die entsprechende Verbindungstopologie.
Fall B:	Wenn jedes Masterobjekt nur ein Slaveobjekt mit Synchronisationsereignissen versorgt, bestehen im günstigsten Fall lediglich (n-1) Punkt-zu-Punkt Verbindungen zwischen den Stationen. Dieser Fall wird dann erreicht, wenn jede Station nur Verbindungen zu maximal zwei anderen Stationen aufbaut. In diesem Fall werden die Synchronisationsereignisse über eine gewisse Anzahl von Stationen geroutet (Abonnementkette). Die Anzahl der Zwischenstationen ist dabei maximal (n-2). Abbildung 8 stellt die Verbindungstopologie für diesen Fall dar.
	Wird davon ausgegangen, daß der maßgebliche Aufwand bei der Versendung der Synchronisationsereignisse darin liegt, die Verbindung herzustellen, und daß es weiterhin möglich ist, mehrere Synchronisationsereignisse über eine bestehende Verbindung abzusenden, bedeutet das Szenario im Fall B eine wesentliche Schonung der Netzwerkressourcen. Problematisch ist bei Fall B allerdings, daß die Synchronisationsereignisse u.U. über (n-2) Stationen geroutet werden müssen. Die Laufzeit der Ereignisse erhöht sich dadurch direkt proportional zur Anzahl der Zwischenstationen. Dies führt natürlich auch zu einer Begrenzung der beteiligten Stationen. Praktisch bietet sich deshalb eine Lösung an, die die Vorteile beider Szenarien integriert und dabei die Auswirkungen der jeweiligen Nachteile möglichst gering hält. Unter Beibehaltung der Forderung nach geringstmöglicher Verbindungszahl zwischen verschiedenen Stationen sind somit folgende Optimierungsziele wesentlich:
[Z1]	minimale Laufzeit von Station zu Station
[Z2]	minimale Anzahl der Zwischenstationen
[Z3]	maximaler Zeitraum zwischen zwei Synchronisationsereignissen

3.4	Objektinteraktion

	Im Voodie System ist zur Zeit noch keine Interaktion zwischen einzelnen Objekten möglich. Es ist ein separater Mechanismus zu entwickeln, mit dessen Hilfe Interaktionen erkannt und aufgelöst werden können. In dieser Arbeit kann nur ansatzweise über verschiedene Verfahren nachgedacht werden.
Interaktions- erkennung	Alle Objekte können mit anderen Objekten in Interaktion treten. Im einfachsten Fall wird diese Interaktion aus Berührungen bestehen. Die Interaktion zwischen den Objekten erfolgt dabei mit Hilfe einer übergeordneten Instanz. Diese Instanz ist für die Interaktion aller Objekte innerhalb eines bestimmten Raumabschnittes zuständig. Es ist sinnvoll, diesen Raumabschnitt mit dem räumlichen Einzugsbereich des jeweiligen Teilnehmers gleichzusetzen, da dadurch gleichzeitig eine Aufteilung der notwendigen Rechenlast auf die Stationen der Teilnehmer erfolgt.
	Interaktionen zwischen zwei Objekten sind prinzipiell nur dann möglich, wenn sich beide Objekte im gleichen Raumabschnitt, d.h. unter der Verwaltung der gleichen Interaktionsinstanz befinden. Interaktion erfolgt also in jeder Welt separat.
Interaktions- dämon (ID)	Die Instanz, die die Objekte über Interaktionsereignisse informiert, soll mit Interaktionsdämon (ID) bezeichnet werden. Der ID kann auch die Verwaltung der Objekte übernehmen, da Verwaltung (Erzeugung, Zerstörung etc.) und Interaktionserkennung eng miteinander verbunden sind und prinzipiell die gleichen Informationen (z.B. Objektpool) benötigt werden.
	Interaktionsereignisse treten z.B. dann auf, wenn sich zwei Objekte berühren. Der ID muß also die Möglichkeit haben, Informationen über Größe und Position der Objekte auszuwerten. Ein Interaktionsdämon ist für die Erkennung von Interaktionen zwischen Objekten zuständig, die sich in einer gewissen Umgebung um den Teilnehmer befinden. Weil der Teilnehmer in der Lage sein soll, sich in der virtuellen Umgebung zu bewegen, muß konsequenterweise auch der Interaktionsdämon als beweglich definiert werden. Der Raumabschnitt, für den ein ID zuständig ist, ist also kein statisch definiertes Gebiet der virtuellen Umgebung, sondern dieser Raumabschnitt unterliegt dynamischen Änderungen. Für den Teilnehmer bedeutet diese Kopplung, daß keine Grenzen der Welt bemerkbar werden. Der Teilnehmer sieht die Grenzen lediglich in einer gewissen Entfernung (vgl. Aura in MASSIVE, ab Seite 23). In jeder dieser Welten ist nur das existent, was sich in einem gewissen räumlichen Umkreis um den Akteur abspielt. In gewisser Weise kann dies auch als eine Analogie zu idealistischen Philosophien gesehen werden - "Nur das sichtbare ist real. Alles andere ist die Idee" Die gesamte virtuelle Umgebung stellt sich in diesem Zusammenhang als eine Idee dar, ein jeder Teilnehmer sieht lediglich vergängliche (Teil-)Abbilder und Teilaspekte dieser Idee. Sollte sich ein Masterobjekt aus dem Einflußbereich eines lokalen ID heraus bewegen, existieren zwei Möglichkeiten zum weiteren Verfahren:
[A]	Das Objekt hört auf zu existieren. Wenn das Objekt Abonnenten besitzt, geht die Koordinierung an einen (z.B. den ältesten) Abonnenten über. Das lokale Objekt wird gelöscht und muß neu abonniert werden, wenn es wieder sichtbar sein soll.
[B]	Das Objekt existiert unabhängig von seiner Position zum ID bis zur expliziten Zerstörung weiter. Dabei geht die Koordinierung nicht an einen Abonnenten über.
	Es ist denkbar, daß der Übergang an einen Abonnenten nicht nur durch die Lebensdauer der Abonnenten gesteuert wird, sondern durch andere Mechanismen. Weiter oben wurde bereits ein Übergang in Abhängigkeit von der Position des Objektes vom lokalen ID besprochen. Abonnenten könnten dann die Übernahme vorschlagen, wenn sich das Objekt sehr nahe am eigenen ID befindet. Letztlich entscheidet aber das Masterobjekt, ob es die Kontrolle abgibt oder nicht. Nachdem nun geklärt ist, wann Interaktionen auftreten können, steht noch die Frage, wie diese Interaktionen erkannt und aufgelöst werden.
Interaktions- auflösung	Ein Ansatz wäre die Erweiterung des Interaktionsdämons. Der Interaktionsdämon ist immer mit der Position der Station (also des Nutzers bzw. dessen Avatar) im virtuellen Raum gekoppelt. Um diese Position des Nutzer existiert ein Bereich, in dem alle Objekte (bekannter) entfernter Stationen abonniert werden müssen. Es werden nun dynamische Interaktionsgruppen gebildet, die sich aus den Objekten zusammensetzen, die auf einer Station existieren (Master- und Slaveobjekte). Interaktion kann nur zwischen solchen Objekten stattfinden.
	Interaktion wird zusätzlich nur zwischen Masterobjekten erlaubt. Slaveobjekte, mit denen eine Interaktion durchgeführt werden soll, geben den Interaktionswunsch an ihr Masterobjekt weiter. Wenn zwei Masterobjekte interagieren, so geschieht dies, indem beide Objekte von der notwendigen Interaktion informiert werden. Die Objekte können dann miteinander ihre Reaktion abstimmen. Im einfachsten Fall sieht das so aus, daß beide Objekte an das jeweils andere Objekt eine Nachricht mit ihren Interaktionsdaten schicken und das jeweils andere Objekt entsprechend darauf reagiert. Kompliziertere Interaktionsmechanismen sind dabei nicht ausgeschlossen. Sollte eine Station lediglich ein Objekt von zwei interagierenden Objekten abonniert haben, so geschieht die Interaktion ohne das zweite Objekt, indem nötigenfalls die Objektkontrolle an die Station übertragen wird, auf der beide interagierende Objekte vorhanden sind. Die Interaktionen werden bei dieser Vorgehensweise durch die Objekte selbst aufgelöst. DIVE (/CAR93/) verwendet diese Methode. Kazman beschreibt in /KAZ93a/ die Schwierigkeiten einer solchen Vorgehensweise. Problematisch ist die Anzahl von Interaktionsmöglichkeiten bei vielen Objekten. Jeder Objekttyp muß die Interaktion mit sämtlichen anderen Objekttypen beherrschen. Die jeweiligen Aktionen sind dabei Bestandteil der Objektdefinition. Dadurch ist es nicht möglich, neue Objekte (und damit neue Interaktionen) einzuführen, ohne die alten Objekte zu verändern. Diese Vorgehensweise wird deshalb nicht weiter in Betracht gezogen.
Interaktions- objekte	Die Interaktion verschiedener Voodie Objekte könnte durch den Einsatz von Interaktionsobjekten ermöglicht werden. Diese Interaktionsobjekte sind nichtsichtbare, aber abonnierbare Voodie Objekte. Die Kommunikation von Voodie Objekten über Interaktionsobjekte geschieht, indem ein Interaktionsobjekt Referenzen auf die Objekte besitzt, die interagieren sollen. Das Interaktionsobjekt prüft dabei permanent, ob eine Interaktion zwischen zwei Objekten vorliegt (z.B. Kollision). Ist dies der Fall, so werden beide Objekte davon benachrichtigt. Interaktionsobjekte residieren dabei auf der Station, auf der auch die beteiligten Objekte vorhanden sind. Durch die Interaktionsobjekte wird die Definition der Interaktionen von der Definition der Objekte getrennt. Neue Objekte (und damit neue Interaktionsmöglichkeiten) können in das System integriert werden, ohne die bereits existierenden Objekte zu verändern. Es müssen lediglich entsprechende Interaktionsobjekte definiert werden.
	Nachteilig wirkt sich bei diesem Vorgehen aus, daß für jedes Paar interagierender Objekte ein Interaktionsobjekt benötigt wird. Dadurch steigt die Anzahl der zu verwaltenden Objekte sehr stark an. Bei n Objekten, die alle miteinander interagieren sollen, sind ½ n(n-1) Interaktionsobjekte notwendig.
separate Interaktions- definitionen	Auch Kazman (/KAZ93b/) schlägt eine von den Objekten unabhängige Definition der Interaktionen vor.
	Dieser Ansatz ist sinnvoll, weil Objektinteraktionen prinzipiell unabhängig vom Verhalten einzelner Objekte sind. In den Objekten wird nur das Verhalten der Objekte definiert. Wenn neue Objekte in das System eingeführt werden sollen, ist es notwendig, das Verhalten des Objektes zu spezifizieren und festzulegen, welche Interaktionen mit anderen Objekten möglich sind. Die Spezifikation des Verhaltens und der Interaktionen erfolgt dabei unabhängig voneinander. Diese Trennung hat den Vorteil, daß die Objekte ohne Änderung weiterverwendbar sind, auch wenn neue Interaktionen mit neuen Objekten notwendig sind. In Anlehnung an die Implementation wird für die Interaktion von Objekten folgende Lösung vorgeschlagen: Das Verhalten eines Objektes wird mit Hilfe einer Simulationsschleife und der Eventbehandlungsroutine des Objektes festgelegt. Interaktionen werden separat spezifiziert. Angenommen es existieren zwei Objekte A und B vom Typ Type_A und Type_B. Jedes dieser Objekte besitzt ein bestimmtes Verhalten und bestimmte Attribute: Type_A (z.B. sich bewegendes Objekt): Attribute: Geometrie, Position, Geschwindigkeit Verhalten: verändere Position in Abhängigkeit von Geschwindigkeit Type_B (z.B. Wand): Attribute: Geometrie, Position Verhalten: bleibe immer an der gleichen Stelle. Die Interaktionsspezifikation für diese Objekte müßte dann Folgendes enthalten: Interaction (Type_A A1 <--> Type_A A2): tritt auf: (A1.Geometrie(A1.position)) schneidet/berührt (A2.Geometrie(A2.position)) Reaktion: A1: Umkehren(A1.Geschwindigkeit) A2: Umkehren(A2.Geschwindigkeit) Interaction (Type_A A1 <--> Type_B B1): tritt auf: (A1.Geometrie(A1.position)) schneidet/berührt (B1.Geometrie(B1.position)) Reaktion: A1: Umkehren(A1.Geschwindigkeit) B1: nichts machen Interaction (Type_B B1 <--> Type_B B2): nicht relevant Es ist auch denkbar, globale Gesetzmäßigkeiten (z.B. Gravitation) als Interaktion von Objekten mit einem Environmentobjekt aufzufassen. Jedes Objekt wird dabei von der Interaktion mit der Umgebung unterrichtet und die Objekte stellen dann ihr Verhalten auf dieses Umgebungsobjekt ein. Problematisch ist dabei, daß solche Interaktionen permanent auftreten, die Objekte also permanent von diesen Interaktionen unterrichtet werden müßten. Eine Lösung für dieses Problem stellt die separate Definition von Interaktionsmethoden dar, die einmalig vom Objekt angefordert und dann immer wieder durch das Objekt ausgeführt werden.

3.5	Konsistenz der Welten

	Um verteilte virtuelle Umgebungen benutzen zu können, ist es notwendig, den beteiligten Teilnehmern eine konsistente Sicht der Umgebung zu bieten. Durch die dezentrale Datenhaltung können Inkonsistenzen auftreten. Die Konsistenz einer verteilten Umgebung wird in folgenden Fällen verletzt:
[A]	Ein Objekt ändert eigenständig seine Eigenschaften.
	Diese Inkonsistenz wird durch den Abomechanismus und die damit gewährleistete Synchronisation behoben.
[B]	Zwei Welten enthalten nicht die gleichen Objekte.
	Diese Verletzung der Konsistenz kann nur über einen Mechanismus gelöst werden, der sicherstellt, daß jede Welt die gleichen Objekte enthält. Dies führt im Extremfall zu einer, auf jeder Station vollständig replizierten Umgebung. Dieser Fall tritt aber in den seltensten Fällen ein. Ein Teilnehmer benötigt für eine konsistente Sicht auf die Welt lediglich die Objekte, die sich in einer gewissen Entfernung von ihm befinden. Denkbar ist auch eine Zuordnung von Objekten zu Interaktionsgruppen. Zu diesen Gruppen gehören alle Objekte, die sich gegenseitig beeinflussen. Wenn ein Objekt abonniert wird, dann müssen auch alle Objekte der jeweiligen Interaktionsgruppe abonniert werden. Solche Interaktionsgruppen könnten als verkettete Listen von OI implementiert werden. Dieser Ansatz brächte allerdings unnötige Mehrkommunikation mit sich und ist deshalb nicht sinnvoll. Welten, die lediglich die Objekte der gesamten Umgebung enthalten, die sich innerhalb eines gewissen Bereiches um den Teilnehmer befinden können diese Konsistenzverletzung besser lösen. Für zwei Teilnehmer der virtuellen Umgebung, die sich im gleichen Raumabschnitt des virtuellen Raumes befinden, müssen die gleichen Objekte sichtbar sein. Ist dies nicht der Fall, sind prinzipiell Situationen vorstellbar, in denen ein Objekt in unterschiedlichen Welten unterschiedliches Verhalten zeigt. Als Beispiel sei an zwei Welten gedacht, in denen sich ein Objekt (z.B. Ball) bewegt. In der einen Welt könnte dieses Objekt auf ein anderes Objekt (z.B. Wand) treffen und damit seine Flugbahn ändern. Wenn in der anderen Welt nicht die gleichen Objekte vorhanden sind, wäre das Verhalten des Objektes inkonsistent, weil entweder der Ball völlig unmotiviert seine Flugbahn im freien Raum ändert, oder der Ball sich einfach weiterbewegt (und damit in der anderen Welt durch die Wand hindurch fliegt). Deshalb ist das Abonnement aller Objekte in der unmittelbaren Umgebung eines Teilnehmers zwingend notwendig. Interaktionen (z.B. Kollisionen) sind dann immer schlüssig, da der Interaktionspartner eines Objektes im gleichen Raumabschnitt existent ist. Im ungünstigsten Fall kann sich eine Interaktion zwischen zwei Objekten auf ein einzelnes Objekt eines anderen ID auswirken. Da sich dieses Objekt aber am Rand des Einflußbereiches des ID befindet, ist die scheinbar unmotivierte Veränderung der Objekteigenschaften akzeptabel. Die automatische Abonnierung aller relevanten Objekte kann über die Untersuchung der OI erfolgen. Die OI müssen dazu Informationen zur Position in der Umgebung enthalten. Eine Station kann dann eigenständig alle Objekte abonnieren, die für sie relevant sind.
dynamische Optimierung der Kommu- nikations- topologie	Natürlich ergibt sich daraus die Notwendigkeit, daß die OI aller Objekte auf allen Stationen verfügbar sind. Ein klarer Verstoß gegen die Anforderung, möglichst große Welten (viele Objekte) mit vielen Teilnehmern zu unterstützen. Leider ist zu diesem Zeitpunkt noch keine vollständige Lösung für dieses Problem gefunden. Ein Ansatz könnte sein, spezielle OI für die Stationen einzuführen. Diese OI müssen auf allen Stationen bekannt sein. Da die Stationen nur Objekte verwalten, die sich in unmittelbarer Nähe der Station befinden, kann anhand der Positionen der Stationen entschieden werden, ob die OI angefordert werden oder nicht. Natürlich bedeutet diese Lösung nur eine Verschiebung des Skalierungsproblems. Wesentlich eleganter wäre eine Lösung, mit deren Hilfe es möglich wäre, relevante Stationen bzw. Objekte ohne Kenntnis der Gesamtstruktur, nur mit Hilfe der jeweils benachbarten Stationen, ausfindig zu machen. Die dynamische Optimierung der Kommunikationstopologie zwischen den beteiligten Stationen scheint hier ein vielversprechender Ansatz zu sein, der in jedem Fall weiter untersucht werden sollte.

3.6	Optimierung der Ein- und Ausgabe

Die Visualisierung der virtuellen Umgebung sollte mit Hilfe einer separaten Applikation erfolgen. Die Kommunikation der Voodie Applikation mit der Applikation, die die graphische Ausgabe besorgt, wird dabei über Ereignisse abgewickelt.

Display- sprache

Wenn ein Objekt seine Visualisierung verändern will, muß es demzufolge ein Ereignis an die Visualisierungsapplikation bzw. an das Visualisierungsmodul (Renderer) absetzen. Diese Vorgehensweise stellt aber einen Engpaß dar, da mitunter sehr viele Objekte sehr oft solche Ereignisse absetzen werden. Um keinen Engpaß zu provozieren, sollte vorgesehen werden, die Visualisierungsereignisse so auszulegen, daß diese Events vom Renderer lediglich einmal empfangen werden und dann immer wieder ausgeführt werden. Dieses Vorgehen könnte etwa mit der Registrierung von Callbacks verglichen werden. Diese Methode macht allerdings die Definition einer Displaysprache notwendig. Die Darstellungsereignisse enthalten dann Anweisungen in dieser Sprache und werden vom Renderer ausgeführt. Ähnlich sieht die Kommunikation der Objekte mit den Eingabegeräten aus. Auch hier empfiehlt es sich, den Kommunikationsaufwand gering zu halten. In verschiedenen Systemen (Rubber Rocks, ab Seite 20 und /COD92/, Waves / Hidra, ab Seite 28 und /KAZ93a/) wird die Definition von higher-level Events vorgeschlagen, um den Kommunikationsaufwand zu verringern.