Allein machen sie dich ein … aus: "Keine Macht für Niemand", Ton Steine Scherben (1972)

2	Bestandsanalyse existierender Systeme

Die Idee, verteilte virtuelle Umgebungen zu schaffen, ist nicht neu. Es existieren verschiedene Systeme und Forschungsarbeiten, in denen mit unterschiedlichen Methoden versucht wird, sich dem Gegenstand zu nähern. In diesem Abschnitt werden einige Arbeiten näher vorgestellt. Zuvor erfolgt eine Aufstellung möglicher Kommunikations- und Verteilungsmethoden und allgemeiner Anforderungen an verteilte virtuelle Umgebungen. Dies ermöglicht eine Systematisierung der Lösungsmethoden.

2.1	Kommunikationsmechanismen
	Verteilte virtuelle Umgebungen bestehen aus verschiedenen Stationen, die auf den Austausch von Informationen angewiesen sind, um die Konsistenz der gemeinsamen Umgebung zu gewährleisten. Jede Station bietet dabei eine eigene Sicht auf die gemeinsame virtuelle Umgebung. Prinzipiell sind verschiedene Strategien für die Lösung des entstehenden Kommunikationsproblems vorstellbar.
2.1.1	Hierarchische Client/Server Modelle
	Ein System für verteilte virtuelle Umgebungen kann als Client/Server System ausgelegt werden. Ein zentraler Server hält die Informationen der virtuellen Umgebung vor und gibt diese Informationen an Clients (Teilnehmer) weiter. Der Server fungiert in einem solchen System auch als Synchronisationsinstanz. Alle Teilnehmer erhalten über den Server die gleichen Informationen über die virtuelle Umgebung. Um den notwendigen Netzwerkverkehr zu verringern, können Methoden zur bedingten Nachrichtenweiterleitung eingesetzt werden. Dadurch erhalten die jeweiligen Stationen nur relevante Daten. Client/Server Systeme besitzen immer eine zentrale Instanz, die prinzipiell als Beschränkung des Systems angesehen werden muß. In den Systemen werden Filtermechanismen und die Verteilung von Aufgaben auf mehrere zentrale Server dazu benutzt, um diesen Nachteil auszugleichen. Ein Weg, die große Kommunikationslast, die beim Server entsteht, zu verringern, ist der Einsatz von Broad- und Multicast . Beim Broadcast wird dabei eine Nachricht einmalig abgeschickt und von allen Stationen empfangen, beim Multicast wird die einmal gesendete Nachricht von einer Gruppe von Empfängern empfangen. Broadcast hat dabei den Nachteil, daß sehr schnell Grenzen erreicht werden, da jede Station alle Nachrichten empfängt und auswerten muß (auch diejenigen, die nicht relevant sind). Multicast besitzt den Nachteil, daß die Einteilung in Multicastgruppen statisch erfolgt und somit eine dynamische Zuordnung von Stationen zu Multicastgruppen schwierig ist. Ein weiteres Problem sind sichere Netzwerkverbindungen. Um solche Verbindungen zu erhalten, ist es notwendig, daß der Empfänger den Erhalt eines Datenpaketes bestätigt, also an den Absender eine Bestätigungsnachricht schickt. Bei Broad- bzw. Multicast führt dies sofort zu einer erhöhten Netzwerkbelastung, die durch den Einsatz dieser Techniken eigentlich verhindert werden sollte.
2.1.2	Punkt-zu-Punkt Kommunikation
	Systeme, bei denen die Kommunikation auf Punkt-zu-Punkt Verbindungen zwischen gleichberechtigten Stationen basieren, besitzen nicht den Nachteil einer zentralen Instanz. Ein Mangel solcher Systeme ist aber, daß theoretisch ein vollständiger Kommunikationsgraph zwischen allen Stationen notwendig ist. Dadurch wächst die Anzahl der notwendigen Verbindungen quadratisch zur Anzahl der beteiligten Stationen. Die sich ergebenden Einschränkungen für Systeme, die einen solchen vollständigen Kommunikationsgraph benutzen, liegen auf der Hand, wenn der entstehende Netzwerkverkehr betrachtet wird. Es ist aber denkbar, daß Filtermechanismen eingesetzt werden, um redundante oder nicht benötigte Verbindungen zu vermeiden. Auch bei solchen Systemen ist es möglich, Broad- bzw. Multicastmechanismen anzuwenden. Die oben beschriebenen Vor- und Nachteile gelten analog. Kommunikation über Punkt-zu-Punkt Verbindungen hat den Vorteil, daß prinzipiell alle Module gleichberechtigt sind. Alle notwendigen Funktionen sind bei jedem Teilnehmer vorhanden, Es existiert keine zentrale Instanz, die zum Engpaß werden könnte.
2.1.3	Hybride Ansätze
	Weiterhin ist es möglich, die oben beschriebenen Methoden zu kombinieren. Solche hybriden Ansätze könnten z.B. so aussehen, daß mehrere Server eine gewisse Anzahl von Clients verwalten. Zwischen den Clients und dem Server existiert die oben beschriebene Client/Server Struktur. Die Server untereinander sind über Punkt-zu-Punkt Verbindungen gekoppelt. Andererseits ist aber auch vorstellbar, daß ein zentraler Server als Verbindungsmanager fungiert. In einem solchen System würden zwischen den Teilnehmern Punkt-zu-Punkt Verbindungen bestehen, die durch einen zentralen Server verwaltet werden. Mit solchen Ansätzen ist es möglich, die Nachteile einer bestimmten Art der Kommunikation abzuschwächen und damit insgesamt die Performance zu erhöhen.
2.2	Verteilungsmechanismen
	Die Verteilung der Daten in verteilten virtuelle Umgebungen kann durch zwei Merkmale kategorisiert werden. Ein Merkmal ist der Ort, an dem die Daten verwaltet werden. Dieser Ort ist entweder zentral oder dezentral. Das zweite Merkmal ist die Art der Replikation der Daten. Die Daten können entweder als vollständige Replikation bei allen Teilnehmern vorliegen, oder es erfolgt lediglich die Replikation der Daten, die aktuell von der jeweiligen Station benötigt werden. Danach können vier Verteilungsmechanismen unterschieden werden. Die einzelnen Mechanismen sind in Tabelle 1 dargestellt.

	vollständige Replikation (VRep) (multi-user-same-content)	Replikation nach Bedarf (RepNB) (multi-user-different-content)
zentrale Datenverwaltung (ZeD)	zentrales Datenmodell mit vollständiger Replikation auf allen Stationen (ZeD-VRep)	zentrales Datenmodell mit Replikation der Daten nach Bedarf der Stationen (ZeD-RepNB)
dzentrale Datenverwaltung (DeD)	dezentrales Datenmodell mit vollständiger Replikation auf allen Stationen (DeD-VRep)	dezentrale Datenverwaltung mit Replikation der Daten nach Bedarf der Stationen (DeD-RepNB)

Tabelle 1: Verteilungsmechanismen Die einzelnen Verteilungsmechanismen besitzen verschiedene Vor- und Nachteile. Multi-user-same-content (/SIN94/) Systeme gehen von einer vollständigen Replikation aller Objekte der virtuellen Umgebung auf allen beteiligten Stationen aus. Dies führt zu einer hohen Belastung der Netzwerkverbindungen zwischen den Stationen, da jede Änderung einzelner Objekte an alle beteiligten Stationen weitergegeben werden muß. In Systemen, die keine vollständige Replikation der Objekte erfordern, muß aber ein Mechanismus vorhanden sein, mit dessen Hilfe entschieden werden kann, welche Objekte repliziert werden und welche nicht. Die zentrale Verwaltung der Objekte ermöglicht eine zentrale und damit einfacher umzusetzende Interaktionserkennung. Gleichzeitig ergibt sich aber die Notwendigkeit, alle Informationen an einer zentralen Stelle zu verwalten. Dies kann leicht zu einer Überlastung führen. Dezentrale Datenverwaltung impliziert die gleichmäßige Aufteilung der Informationen auf die Teilnehmer der verteilten virtuellen Umgebung. Das Problem der Überlastung kann dadurch gelöst werden. Wenn aber an keiner Stelle die vollständigen Informationen der Umgebung vorhanden sind, erhöht sich die Komplexität der Interaktionserkennung. Um komplexe Welten zu erzeugen, sollte ein DeD-RepNB Mechanismus eingesetzt werden. Prinzipiell ist ein solcher Verteilungsmechanismus am besten geeignet, große verteilte virtuelle Umgebungen zu unterstützen. Diese Art der Verteilung erfordert aber auch den größten Aufwand bei der Implementierung und erfordert den Einsatz von Mechanismen, die noch nicht vollständig entwickelt sind.

2.3	Informationen in verteilten virtuellen Umgebungen
	In verteilten virtuellen Umgebungen existieren verschiedene Arten von Informationen, die über Kommunikation zwischen den Teilnehmern ausgetauscht werden müssen. Es können folgende Informationsarten unterschieden werden:
[K1]	Statisches Aussehen der gemeinsamen Welt.
	Die Stationen, die an einer gemeinsamen virtuellen Umgebung beteiligt sind, müssen Informationen austauschen, die die Umgebung beschreiben. Angenommen, einige Nutzer wollen sich in einem virtuellen Büro treffen, um eine Besprechung abzuhalten. In diesem Fall ist es notwendig, daß alle Teilnehmer die gleichen Informationen über das Aussehen des Büros (der Umgebung) erhalten. Diese Informationen sind relativ langlebig, ein neuer Teilnehmer der Umgebung muß diese Informationen lediglich einmal erhalten. Problematisch ist dabei allerdings die relativ komplexe Struktur dieser Informationen, welche zu großen Datenmengen und damit zu langen Übertragungszeiten führt.
[K2]	Dynamische Veränderungen der gemeinsamen Welt.
	Veränderungen in der gemeinsamen Welt müssen ebenfalls (möglichst zeitsynchron) an alle Teilnehmer übertragen werden, um die Konsistenz der Welt sicherzustellen. Ein Spezialfall dynamischer Änderungen in der verteilten Umgebung ist die direkte Kommunikation zwischen einzelnen Teilnehmern. Die Einteilung in statische und dynamische Informationen ist nicht starr, sondern hängt vom Systemdesign ab. Ausgehend von dieser Einteilung, kann die auftretende Netzlast und die Flexibilität einer verteilten virtuellen Umgebung, in Abhängigkeit von den statischen bzw. dynamischen Informationen, dargestellt werden. Aus der Abhängigkeit läßt sich schlußfolgern, daß die Definition statischer und dynamischer Informationen unter dem Gesichtspunkt der Netzlast und der notwendigen Systemflexibilität erfolgen muß (Abbildung 1).

2.4	Spezielle Anforderungen an verteilte virtuelle Umgebungen
	Wie bereits gesagt, werden an virtuelle Umgebungen folgende Anforderungen gestellt:
[A1]	Dreidimensionale Darstellung und Modellierung der Umgebung.
[A2]	Interaktive Manipulation in Echtzeit.
[A3]	Nutzer als integraler Bestandteil der Umgebung.
	An verteilte virtuelle Umgebungen werden, neben den allgemeinen Anforderungen, zusätzlich folgende Forderungen gestellt:
[B1]	Jedem Beteiligten muß eine verzögerungsfreie Sicht auf eine konsistente, gemeinsame Welt ermöglicht werden.
[B2]	Jedem Beteiligten muß die Möglichkeit der Interaktion mit der Welt (bzw. mit den autonomen Objekten der Welt) und den anderen Teilnehmern geboten werden.
[B3]	Es sollten keine prinzipiellen Beschränkungen in Bezug auf die Anzahl der beteiligten Nutzer vorhanden sein.
[B4]	Es sollten keine prinzipiellen Beschränkungen in Bezug auf die Komplexität der virtuellen Umgebung vorhanden sein.
	Es ist leicht einzusehen, daß die Erfüllung dieser Ansprüche einen erheblichen Kommunikationsbedarf zwischen den Computern (Stationen), über die die Nutzer in die virtuelle Umgebung eintauchen, hervorrufen. Werden die Probleme der virtuellen Umgebungen für Einzelnutzer beiseite gelassen, so ist der entstehende Kommunikationsaufwand das größte Problem bei verteilten virtuellen Umgebungen. Die Anforderungen erfordern eine Reduzierung des Verkehrs im Netzwerk, da dieses sehr schnell zum Engpaß bei verteilten Anwendungen wird. Weiterhin ist noch nicht klar, welche Netzwerkbelastung wirklich auftritt, da nur wenige Aussagen zur quantitativen Beschaffenheit der in virtuellen Umgebungen verwendeten Daten bekannt sind. Prinzipiell sollten alle bekannten Medien (3D Geometrie, akustische Informationen, bewegte Bilder usw.) integriert werden. Dies führt aber sicherlich nicht zu geringeren Ansprüchen an die Übertragungskanäle. Deshalb ist es erforderlich, die Kommunikation auf das absolute Minimum zu begrenzen. Zusätzlich ist es notwendig, dafür Sorge zu tragen, daß keine Überlastung einzelner Teile des Systems erfolgt, bzw. die Belastung auf alle Teilnehmer im System gleichmäßig verteilt wird, da sich sonst die überlasteten Stationen als Engpaß des Systems entpuppen.

2.5

Beschreibung der Systeme

Schwerpunkt bei der Untersuchung waren Systeme, die verteilte virtuelle Umgebungen für mehrere Nutzer zur Verfügung stellen. Neben den oben beschriebenen Kriterien zur Kommunikation und Verteilung, wurde besonderer Wert auf die Beantwortung der folgenden Fragen gelegt: Ist das System eine Applikation oder ist es eher als Basis (Toolkit, Programmbibliothek) für andere Anwendungen ausgelegt? Gibt es im System eine Beschränkung hinsichtlich der Größe und Komplexität der Welt(en), bzw. der Anzahl der gleichzeitig agierenden Nutzer in ein und derselben Welt und wo liegen die Ursachen für die etwaigen Beschränkungen? Werden vom System Mechanismen unterstützt, die eine effektive Nutzung der Ressourcen ermöglichen und welche Methoden werden benutzt? Auf welche Art und Weise erfolgt die Definition der Bestandteile (Objekte) der virtuellen Umgebung? Lassen sich vollkommen neue Bestandteile dynamisch in das System integrieren? Läßt das Systemdesign prinzipielle Erweiterungen zu?

2.5.1

DIVE

DIVE (Distributed Interactive Virtual Environment) wurde am Swedish Institute of Computer Science (SICS) entwickelt und 1993 von Carlsson/Hagsand vorgestellt (/CAR93/). Das System basiert auf UNIX als Betriebssystem und den Internet Protokollen zur Kommunikation. DIVE steht für nichtkommerzielle Nutzung frei zur Verfügung. DIVE besteht grundsätzlich aus Welten (worlds) und Prozessen (processes). Prozesse können in DIVE entweder Applikationen sein, oder Menschen die in der virtuellen Umgebung dargestellt werden. Die Daten der virtuellen Umgebung werden in einer Art verteilter Datenbank abgelegt. Jeder DIVE-Prozeß besitzt eine Kopie dieser Datenbank. Die Konsistenz der Daten wird über Nachrichten (messages) und Ereignisse (events) sichergestellt, die die einzelnen Prozesse austauschen. Jede Veränderung wird über Broadcast Messages an alle anderen Prozesse weitergeleitet. Die gesamte virtuelle Umgebung ist in Welten (worlds) unterteilt. Die einzelnen Welten sind unabhängig voneinander. Der Nutzer kann allerdings dynamisch von einer Welt in eine andere übergehen. In diesem Falle werden die Daten der neuen Welt vollständig repliziert. Informationen legt DIVE in Objekten ab. Objekte sind die Elementarbausteine der replizierten Datenbank. Als Benutzeroberfläche werden in DIVE verschiedene Konzepte eingeführt. Ein Benutzer z.B., wird durch ein Body-Icon dargestellt. Die Navigation und Fortbewegung in der virtuellen Umgebung erfolgt über Fahrzeuge (vehicles). Durch das Prozeßkonzept von DIVE ist es möglich, Applikationen einzubinden. Diese Applikationen können unter Umständen sogar unabhängig vom Benutzerinterface laufen. Applikation und Benutzerschnittstelle kommunizieren über die replizierte Datenbank. DIVE diente als Basis für weitere Forschungsarbeiten auf dem Gebiet der verteilten virtuellen Umgebungen, z.B. Einsatz von 3D-Audio (/POP93/). Durch die Art der Kommunikation und die Aufteilung in vollständig replizierte Welten ist das System in der Anzahl der gleichzeitig in einer Welt agierenden Personen beschränkt, weil bei jedem Teilnehmer eine vollständige Kopie der replizierten Datenbank vorliegen muß. Auch die Größe der einzelnen Welten ist begrenzt, da immer alle Zustandsänderungen aller Objekte in dieser Welt an alle Prozesse weitergegeben werden.

2.5.2

VEOS

Die Virtual Environment Operating Shell (VEOS) wurde ab 1990 am Human Interface Technologie Laboratory der University of Washington in Seattle entwickelt (/BRI94/). Das Projekt wurde 1994 abgeschlossen. VEOS ist, wie der Name bereits sagt, ein Ansatz, der in Richtung Betriebssystemaufsatz für virtuelle Umgebungen geht. Dieser Ansatz ist sehr interessant, wenn in Betracht gezogen wird, daß Applikationen für virtuelle Umgebungen den Umgang mit Computern sicher nachhaltig verändern werden und deshalb andere Anforderungen an ein Betriebssystem stellen, als heutige Anwendungen dies tun. Im VEOS Projekt wurde intensive theoretische Vorarbeit auf diesem Gebiet geleistet. VEOS besteht aus einem Kernel, den Modulen FERN (eine Art Verteilungsmanager), SENSORLIB (Device driver) und dem Renderer IMAGER. Prinzipiell kann eine VEOS Welt in einen Interpretationsteil, in einen Modellierungsteil und einen Darstellungsteil aufgespalten werden. Der VEOS Kernel stellt einfache Möglichkeiten zum Datentransport zur Verfügung (NANCY - eine Variante des Linda Parallel Database Model). Die Programmiersprache, in der VEOS Applikationen geschrieben werden, ist Lisp. VEOS basiert wie DIVE auf direkter Kommunikation zwischen einzelnen Teilnehmern der virtuellen Umgebung. Dies führt sehr schnell zu Performanceproblemen, wenn die Anzahl der partizipierenden Prozesse steigt. Methoden zur Ressourcenschonung sind nicht eingebaut - es werden immer alle Informationen allen anderen Teilnehmern mitgeteilt. Die Nutzung der Daten-Programm-Identität von Lisp ermöglicht es, interessante Wege bei der Verteilung und Kommunikation einzuschlagen. Nachteilig wirkt sich das Kommunikationsmodell aus, da es nicht skaliert, sondern sehr schnell Grenzen erreicht.

2.5.3

Distributed Virtual Environment System

Das Distributed Virtual Environment System (dVS) der britischen Firma Division Limited, ist nach Grimsdale /CRI91/ ein Betriebssystem für Applikationen in virtuellen Umgebungen. Es stellt eine verteilte Datenbank und entsprechende Manipulationsmechanismen als Basis der Kommunikation zur Verfügung. Ein dVS besteht aus Akteuren (actors), Elementen (elements) und Instanzen (instances). Akteure sind diskrete Prozesse, die in ihrer Gesamtheit die virtuelle Umgebung steuern. Akteure werden eingesetzt, um Aufgaben in der virtuellen Umgebung zu erfüllen. Solche Aufgaben reichen von der Überwachung von Eingabegeräten bis zur Animation von dynamischen Objekten. Elemente sind einfache Objekte, die von den Akteuren gesteuert werden, z.B. Lichtquellen (lights) oder Objekte der Umgebung (EnvObjects). Instanzen sind die Datenstrukturen, die die aktuell gültigen Daten einer Umgebung enthalten. Akteure generieren in einer Umgebung Instanzen von Elementen. Akteure halten (hold) nun bestimmte Instanzen. D.h. der Akteur betreut, überwacht und verändert den Status (state) der Instanzen, die von ihm gehalten werden. Akteure können den Status der lokalen Instanzen verändern. Wenn aber der Status aller im verteilten System vorhandenen Kopien verändert werden soll, dann muß der Akteur dies explizit veranlassen (update). Ein spezieller Akteur (director) übernimmt die Verteilung dieser Nachrichten und Ereignisse. Das System ist als kommerzielles Produkt konzipiert und unterliegt entsprechenden Lizenzbestimmungen. Es existiert ein API (VL), das es ermöglicht, Akteure zu implementieren. Auf einem höheren Level ist auch ein Toolkit (VCTools) vorhanden, mit dem komplexere Aufgaben auf höherem Niveau gelöst werden können. Das System bietet Unterstützung für die Parallelisierung der einzelnen Aufgaben des VR-Systems. Die Unterstützung mehrerer Nutzer ist auch vorgesehen, es fehlen aber spezielle Methoden, mit denen die Probleme größerer verteilter Umgebungen gelöst werden können.

2.5.4

VUE

Das Veridicial User Environment (VUE) wurde am IBM T. J. Watson Research Center New York entwickelt /APP92/. VUE ist als Client/Server System ausgelegt. Das System ist nicht als Interaktionssystem für mehrere Benutzer konzipiert, sondern als verteiltes System zur Visualisierung sehr großer, dynamischer Datenmengen. Prozesse kommunizieren über Nachrichtenaustausch miteinander. Es existieren sogenannte Device-Server, die über einen Dialogmanager von den eigentlichen Applikationen getrennt sind. VUE ist als Basis für VR-Applikationen anzusehen. Die strikte Trennung von Devices, Kommunikation und Applikationen bietet ein Grundgerüst für die Implementation virtueller Umgebungen. Im System sind allerdings keine Mechanismen vorgesehen, die eine effektivere Ressourcennutzung ermöglichen würden. Das System ist aber ohnehin nicht für die Interaktion vieler Nutzer, bzw. zur Implementation großer virtueller Umgebungen gedacht. VUE diente als Basis für weitere Forschung auf dem Gebiet der verteilten virtuellen Umgebungen am IBM Research Center.

2.5.5

Rubber Rocks

Rubber Rocks wurde am IBM T. J. Watson Research Center, Yorktown Heights, New York entwickelt (/COD92/). Es kombiniert flexible Objektsimulatoren mit einer VR Benutzeroberfläche. Das System basiert auf einer Client/Server Architektur. Ein Dialogmanager in Rubber Rocks fungiert als Bindeglied zwischen Nutzer und virtueller Welt. Der Dialogmanager kommuniziert mit Device- und Simulationsservern, um Informationen über die virtuelle Welt zu erhalten. Sollen mehrere Personen in der virtuellen Umgebung agieren, werden mehrere Dialogmanager eingesetzt. Diese Dialogmanager tauschen untereinander Informationen aus (z.B. die Position eines Nutzers). Das System ist eher eine flexibel gestaltete Applikation als ein Toolkit. Die Trennung von Inhalt (content) und Darstellung (style) war ein wichtiges Paradigma der Entwickler. Als Inhalt wird dabei die Funktionalität der Bestandteile des Systems und als Darstellung deren Benutzerinterface angesehen. Die Entwickler schlagen den Einsatz von komplexen Ereignissen (higher-level events) vor. Dies ist ein Ansatz, durch den die notwendige Kommunikation reduziert werden könnte. Interessant ist auch die Integration von physikalischen Gesetzen und Objektsimulatoren. Rubber Rocks ist nicht ohne weiteres auf viele Nutzer und große Welten erweiterbar, da es die exponentiell wachsende Informationsmenge nicht in geeigneter Weise reduzieren kann. Es fehlt an prinzipiellen Mechanismen, die eine solche Reduktion ermöglichen könnten.

2.5.6

VR-DECK

Das Virtual Reality Distributed Environment and Construction Kit (VR-DECK) wurde am IBM T. J. Watson Research Center, Yorktown Heights, New York, entwickelt (/COD93/). Die Entwickler ließen Erkenntnisse, die mit dem Rubber Rocks System gesammelt wurden, in das System einfließen. VR-DECK benutzt Module (modules) als Grundbausteine der virtuelle Umgebung. Diese Grundbausteine schließen Objekte, Operationen, Funktionen und Nutzer ein. Die Module kommunizieren über Ereignisse (events), die sie entweder erzeugen oder verarbeiten. Die Verarbeitung der Ereignisse basiert dabei auf Regeln (rules), die in C++ geschrieben werden. Welten in VR-Deck bestehen aus Modulen, die Ereignisse austauschen. Wenn zwei Module sich miteinander verbinden, so wird durch das Laufzeitsystem sichergestellt, daß nur diejenigen Ereignisse vom sendenden Modul zum empfangenden übertragen werden, die vom empfangenden Modul auch bearbeitet werden. Dieser Filtermechanismus stellt sicher, daß keine unnötigen Daten über das Netzwerk übertragen werden. VR-DECK vereinfacht die Erstellung einer virtuellen Umgebung durch eine intuitiv benutzbare Benutzeroberfläche. Es ist möglich, neue Module mit neuen Regeln zu erstellen und in die VR-DECK Bibliothek zu integrieren. Ressourcenschonung kann durch das Verändern der Regeln der einzelnen Module erreicht werden. Problematisch ist die Erzeugung von großen Welten. Es ist denkbar, daß durch die zentrale Regelauswertung des Systems die Rechenleistung eines einzelnen Computers bei großen Welten nicht ausreicht, um alle Regeln schnell genug auszuwerten und die resultierenden Ereignisse an die einzelnen Modulen weiterzuleiten. Ein anderer Nachteil des Systems ist, daß beim Start eines Moduls alle anderen Module auch gestartet werden müssen. Zum Einen ergibt sich daraus das Problem, daß eine Applikation auf einer fremden Maschine gestartet werden muß (also die nötigen Rechte vorhanden sein müssen), zum Anderen müssen eben immer alle Module auf allen Maschinen ausgeführt werden, was den dynamischen Eintritt neuer Nutzer in die Umgebung unmöglich macht.

2.5.7

BrickNet

Das BrickNet Toolkit wurde am Institute of Systems Science der University of Singapore entwickelt (/SIN94/). Es unterstützt die grafische, funktionale und netzwerkspezifische Modellierung virtueller Umgebungen. Dabei wird von virtuellen Welten ausgegangen, die Objekte gemeinsam benutzten (shared objects). Virtuelle Welten in BrickNet funktionieren objektorientiert, bestehen also aus Objekten, die ihre gesamte Funktionalität selbst enthalten (Grafik, Verhalten, Netzwerk). Objekte können zur Laufzeit dynamisch erzeugt und gelöscht werden, Attribute sind veränderbar. Die BrickNet Welten müssen nicht zwangsläufig alle den gleichen Inhalt haben. Jede virtuelle Welt verwaltet ihre eigenen Objekte. Diese Objekte können u.U. gemeinsam von verschiedenen, verteilten Welten benutzt werden. Die Kommunikation zwischen den Welten (Clients) geschieht über eine Client/Server Architektur. Server fungieren dabei als Objektanforderungsverteiler (Object Request Broker). Objekte in BrickNet sind ebenfalls Clients. Diese Objekte stellen sich über die Server anderen Clients zur Verfügung. Dabei ist auch eine Zugriffsrechteverwaltung mit eingebaut. BrickNet wurde in C und mit Hilfe der Starship (/LOO91/) Programmiersprache implementiert. Wenn ein Objekt über das Netzwerk verteilt benötigt wird, so wird der Starship Quelltext übertragen. Auch Objektaktualisierungen werden im Starshipcode übertragen und beim entfernten Rechner ausgeführt. Dabei übernimmt der BrickNet Server die Aufgabe der Verteilung, Weiterleitung und Filterung solcher Nachrichten. Wesentlich an BrickNet ist, daß die verschiedenen Benutzer nicht zwangsläufig die gleiche virtuelle Umgebung vor sich haben, obwohl dies durchführbar wäre. Dadurch kann die Komplexität der Welt, die auf der Station eines Teilnehmers vorhanden ist, begrenzt werden. BrickNet Clients kommunizieren nicht direkt miteinander, sondern immer nur über den Server. Ein Client in BrickNet besteht aus mehreren Schichten. Die Interaktionsunterstützungsschicht (interaction-support Layer) ist sozusagen die VR-Oberfläche. Sie besteht aus verschiedenen Modulen (bricks), die verschieden Aufgaben übernehmen (Gerätetreiber - device brick, grundlegende 3D Grafik - geometry brick, usw. ). Die zweite Schicht ist die VR-Wissensschicht (VR Knowledge Layer). Diese Schicht verwaltet die Objekte einer virtuellen Welt. Dabei kommen Gesetze (laws) zum Einsatz, die verschiedenes Verhalten der Objekte hervorrufen. BrickNet geht in der Wissensschicht von verschiedenen Klassen aus, die die einzelnen Wissenskomponenten enthalten. Solche Klassen sind die Geometrie- und Weltklassen (Solid- and World Classes), die Überwachungs- (Controller-) und Aktionsklassen (Action Classes) und die Objekt- und Abgleichskontrolle (Object- and Updatemanagement) Bei der Objektverwaltung ist das Konzept des derzeitigen Besitzers (current owner) eines Objektes interessant. Dieses Konzept verhindert Inkonsistenzen durch gleichzeitiges Verändern eines Objektes durch mehrere Clients. Um Besitzer eines Objektes zu werden, wird eine entsprechende Anforderung an den Server gesendet. Wenn niemand das Objekt besitzt, vergibt der Server die Besitzrechte und sperrt das Objekt für andere Clients solange, bis das Objekt wieder freigegeben wird. In der Kommunikationsschicht wird die Kommunikation des Clients mit dem Server abgewickelt. Ein Kommunikationsverwalter ist als separater Prozeß ausgelegt. BrickNet Server bestehen ebenfalls aus verschiedenen Schichten die folgende Aufgaben haben: Clientverwaltung (Client Management Layer) , Objektverwaltung (Object Management Layer), Aktualisierungsanforderungsverwalter (update request handler) und Kommunikation (communication Layer). Nachteil des BrickNet Systems ist ganz klar der Server, der zum Kommunikationsflaschenhals werden kann. Die Entwickler schlagen eine Lösung vor, in der die Aufgaben des Servers zusätzlich von den Clients übernommen werden. Dies führt aber zu komplizierteren Clientprogrammen und könnte die Interaktionsgeschwindigkeit evtl. nachteilig beeinflussen. Die Netzlast kann in BrickNet durch die Implementation der Objekte beeinflußt werden. Jedes Objekt entscheidet selbst, wie oft es entfernte Kopien aktualisiert, und wie die entfernten Kopien auf diese Aktualisierung reagieren.

2.5.8

NVR

Networked Virtual Reality (NVR) wurde durch Wissenschaftler der Bell Communications Research entwickelt (/BER94/). NVR stellt ein Software Toolkit dar, welches die Generierung von verteilten (networked) virtuellen Umgebungen unterstützt. Das System basiert auf einer Client/Server Architektur. Dabei existiert ein zentraler Kommunikationsserver, über den die Kommunikation der Clients untereinander erfolgt. Alle Clients besitzen eine Kopie der Datenbank, die die virtuelle Umgebung beschreibt. Über Nachrichten, die der Server verteilt, wird die Konsistenz der bei den Clients replizierten Daten sichergestellt. Es wird ein Mechanismus vorgestellt, der bei zu hohen Belastungen (Rechen- bzw. Netzwerkleistung) die Zeit zwischen solchen Nachrichten vergrößert. Dies führt aber zu deutlichem Qualitätsverlust, da die fehlenden Informationen in keiner Weise interpoliert werden. Als weitere Methode die Kommunikation zu verringern, benutzt NVR lokale Objekte (local objects). Diese Objekte werden allein von der lokalen Datenbank verwaltet. Denkbare Anwendungen sind hier z.B. Kontrollpanelobjekte, die sich jeder Nutzer lokal anpassen kann, oder auch Objekte, bei denen es nicht auf zeitsynchrones Verhalten bei allen Nutzern ankommt (z.B. ein Objekt welches zur besseren Erkennbarkeit immer um seine eigene Achse rotiert, oder eine Fackel deren Flamme flackert). Das Problem großer virtueller Welten wird von NVR über getrennte Welten, die über Portale (portals) verbunden sind, gelöst. Beim Neueintritt in das System oder beim Übergang in eine andere Welt wird vom Server eine vollständige Kopie der aktuellen Welt geliefert. Der Server hält also von jeder Welt eine Kopie vor und aktualisiert diese Welt permanent. Dieser Punkt ist problematisch, da dadurch der Server sehr schnell zum Flaschenhals des Systems werden kann. NVR zielt auf Low-End Hardware ab. Das System ist für heterogene Umgebungen geeignet, es basiert auf TCP/IP und benutzt entfernte Prozeduraufrufe (remote procedure calls - RPC) zur Kommunikation.

2.5.9

MASSIVE

Model, Architecture and System for Spatial Interaction in Virtual Environments (MASSIVE) ist ein experimentelles System. Es wurde von Greengalgh und Benford an der University of Nottingham entwickelt und 1995 auf der Conference on Distributed Computing in Vancouver vorgestellt (/GRE95/). Es benutzt verteilte virtuelle Umgebungen mit dem Ziel der Unterstützung gemeinsamen Arbeitens. Die Entwickler von MASSIVE haben bei ihrer Arbeit großen Wert auf das gemeinsame Arbeiten und auf die Bereitstellung von Schnittstellen für verschiedene Arten der Kommunikation gelegt. Die Entwicklung von MASSIVE wurde von zwei Grundideen getragen: Erstens sollen so viele gleichzeitig agierende Nutzer wie möglich unterstützt werden und zweitens soll Interaktion auch zwischen solchen Nutzern möglich sein, die radikal verschiedene Benutzeroberflächen benutzen bzw. deren Ausstattung sich sehr stark von einander unterscheidet. MASSIVE benutzt für die Kommunikation zwischen Benutzern das räumliche Modell der Interaktion (spatial model of interaction). Dieses Modell geht von zwei Grundkomponenten aus. Die eine Komponente - Skalierbarkeit (scalability) - basiert auf dem Aurakonzept. Jedes Objekt in einer virtuellen Umgebung besitzt eine Aura, also einen gewissen räumlichen Einflußbereich. Diese kann für jedes Medium in dem es interagieren kann, verschieden sein. Die Aura legt die Grenze fest, bis zu der das Objekt im jeweiligen Medium mit anderen Objekten interagieren kann. Interaktion kommt nur dann zustande, wenn die Aura zweier Objekte miteinander kollidieren (Aura collision). Die Kontrolle, ob eine solche Kollision vorliegt, übernimmt ein Auramanager. Der Auramanager informiert die Objekte, die an einer Kollision beteiligt sind und diese Objekte können dann eine Punkt-zu-Punkt Verbindung zueinander aufnehmen. Die zweite Komponente dieses räumlichen Interaktionsmodells ist die Wahrnehmung anderer Objekte (awareness) . Diese ist beim räumlichen Modell in weiter Entfernung weniger stark ausgeprägt als beim direkten Kontakt und kann etwa mit einem Detaillierungsgrad (Level of Detail, LOD) verglichen werden. Um die Wahrnehmung zu steuern, wurden Fokus (focus) und Nimbus (nimbus) eingeführt. Fokus geht immer von Beobachtern aus und gibt an, wie stark der Beobachter sein Wahrnehmung auf ein bestimmtes Objekt konzentriert. Nimbus beschreibt eine Art Sichtbarkeit. Mit dem Nimbus kann ein Objekt steuern, wie stark es selbst von anderen Objekten (Beobachtern) wahrgenommen wird. Wie ein Objekt ein anderes Objekt nun wahrnimmt hängt zum einen vom eigenen Fokus des Objektes ab und zum Anderen vom Nimbus der beobachteten Objekte. Aura, Fokus und Nimbus können auf drei verschiedene Arten beeinflußt werden. Einmal kann eine implizite Änderung erfolgen. Dies ist z.B. bei einer Bewegung durch die virtuelle Umgebung sinnvoll. Natürlich kann auch explizit Einfuß genommen werden, z.B. indem einfach verschiedene Größen oder Gestalten bzw. enger oder weiter Fokus gewählt werden. Eine weitere Einflußmöglichkeit auf diese Parameter sind Adapter. Adapter sind Objekte, die eine Transformation von Aura, Fokus und Nimbus vornehmen. Ein Beispiel für einen solchen Adapter ist z.B. ein Mikrofonobjekt. Dieses Objekt kann Aura, Fokus und Nimbus anderer Objekte verändern und dadurch bestimmte Funktionen bereitstellen (in diesem Beispiel Verstärkung von akustischen Informationen). MASSIVE unterstützt die Existenz mehrerer unabhängiger virtueller Welten, die über Portale miteinander verbunden sind. Kommunikation kann graphisch, über Audio oder mit Hilfe eines Textinterfaces bzw. als Kombination dieser Medien, erfolgen. Das Verteilungsmodell von MASSIVE benutzt typisierte Punkt-zu-Punkt Verbindungen, die eine Kombination aus entfernten Prozeduraufrufen (remote procedure calls, /BLO92/), gemeinsamen Attributen (shared attributes) und Strömen (streams) sind. Interaktionen können nur dann zustande kommen, wenn zwei Voraussetzungen erfüllt sind: Die Objekte müssen mindestens ein gemeinsames Interface besitzen und sie müssen nah genug beisammen sein. Beide Voraussetzungen spiegeln sich im Konzept des räumlichen Austausches (spatial trading) wider. Ein Auramanager übernimmt die Aufgabe, Aurakollisionen gleicher Interfaces verschiedener Objekte festzustellen und die Objekte davon in Kenntnis zu setzen. Die zentrale Kollisionsfeststellung durch den Auramanager ist als Nachteil von MASSIVE anzusehen, da zentralisierte Funktionalitäten in jedem Fall einen Engpaß darstellen können.

2.5.10

AVIARY

Das AVIARY System wurde von der Communications Research Group am Department of Computer Science der University of Nottingham entwickelt und in /SNO94/ vorgestellt. AVIARY kann als Sammlung autonomer, miteinander kommunizierender Objekte angesehen werden, die unabhängig voneinander ausgeführt werden. Alle Objekte exportieren ein Interface, mit dessen Hilfe sie in einem gemeinsamen Kommunikationsmedium durch den Austausch von Nachrichten kommunizieren. Solche Objekte können sowohl Gegenstände oder Objekte (artifacts) der virtuellen Umgebung sein, als auch Dienste anbieten (z.B. Kollisionsfeststellung). Das System ermöglicht die Einrichtung von verschiedenen Welten, in denen auch verschiedene Gesetze gültig sein können. Die Kommunikation zwischen AVIARY Objekten geschieht über Nachrichtenaustausch (message passing). Es ist möglich, neue Nachrichtentypen zur Laufzeit zu erzeugen. Die Objekte in AVIARY können von verschiedener Art sein. Es gibt Objekte, die als Applikationen ausgelegt sind, die also ohne weiteres ausführbar sind (heavyweight objects) und es gibt Objekte, die - ähnlich den Objekten aus Standard Programmiersprachen - weniger Overhead besitzen, somit leichter (lightweight objects) sind und auf eine einfache Art und Weise zwischen Prozessoren hin und her bewegt werden können. Nutzer werden von AVIARY auf die gleiche logische Ebene gestellt wie Applikationen. Erkennung von Interaktionen zwischen Objekten (hier Kollisionsfeststellung) erfolgt bei AVIARY über eine Umgebungsdatenbank (Environment Database). Diese Datenbank wird von den Objekten über räumliche Änderungen informiert und informiert ihrerseits die Objekte, wenn eine Kollision festgestellt wurde. Die Objekte müssen dann geeignete Maßnahmen einleiten. In AVIARY wird zur zeitlichen Synchronisation das Konzept einer globalen Zeit (world-time) eingeführt. Schonender Benutzung von Netzwerkressourcen wurde Beachtung geschenkt, indem z.B. nur diejenigen Bestandteile (artifacts) der virtuellen Umgebung Synchronisationsereignisse erhalten, die sich in einem bestimmten räumlichen Umfeld um den Betrachter befinden.

2.5.11

NPSNET

NPSNET wurde für militärische Simulationen entwickelt (/MAC94/). Es benutzt sowohl das IEEE 1278 distributed interactive simulation (DIS) application protocol (/DIS/), als auch das IP Multicast network protocol (/LOO91b/). Ein weiterer wesentlicher Punkt des NPSNET Systems ist die Verwendung eines Dead Reckoning Verfahrens zur Verminderung der Netzwerkbelastung. Dead Reckoning bezeichnet eine Methode zur Verringerung der notwendigen Datenübertragung zum Abgleich der Stationen. Um eine flüssige Darstellung der Bewegung eines Objektes zu erhalten, müssen ca. 25 Bilder pro Sekunde dargestellt werden. Wenn Objekte über ein Netzwerk abgeglichen werden müssen, ist es somit notwendig, die Informationen zum Abgleich 25 mal pro Sekunde über das Netzwerk zu übertragen. Dies führt zu einer hohen Belastung des Netzwerks. Außerdem kommt die Bewegung eines Objektes ins Stocken, wenn bei der Übertragung der Abgleichsinformationen Verzögerungen auftreten. Wird Dead Reckoning eingesetzt, so kann die Bewegung eines Objektes anhand der aktuellen Position, der Geschwindigkeit und der Beschleunigung des Objektes bei jedem Teilnehmer berechnet werden. Durch diese lokale Berechnung ist die Flüssigkeit der Darstellung unabhängig vom Eintreffen neuer Objektinformationen. Zusätzlich kann der Zeitraum zwischen zwei Synchronisationsimpulsen erhöht werden. Dadurch erfolgt eine Entlastung des benutzten Übertragungskanals. Für die Berechnung der Bewegung eines Objektes anhand o.g. Attribute existieren verschiedene Lösungen. Neben der Lösung, die in NPSNET benutzt wurde, sei an dieser Stelle noch auf /SIN95/ verwiesen. Das DIS Protokoll unterstützt und verlangt eine volle Replikation aller Objekte in der virtuellen Umgebung und es verlangt auch, daß die replizierten Objekte immer den aktuellen Status des Originals kennen. Selbst durch den Einsatz von Mechanismen wie Dead Reckoning ist ein Ansatz mit dem DIS Protokoll nicht allgemeingültig anwendbar, da durch die vollständige Replikation aller Objekte sehr schnell die Grenzen der zur Verfügung stehenden Hardware und Netzbandbreite erreicht werden.

2.5.12

RING

RING wurde von den AT&T Bell Laboratories, Murray Hill, New York als Client-Server System für virtuelle Umgebungen mit mehreren gleichzeitig agierenden Nutzern konzipiert(/FUN95/). Die Kommunikation wird über Server abgewickelt. Dabei werden aber nicht alle Statusänderungen aller Objekte an alle Clients weitergeleitet, sondern es werden nur Nachrichten weitergeleitet, die für den Empfänger wirklich notwendig sind. Diese Notwendigkeit errechnet der Server über einen Sichtbarkeitsalgorithmus. Clients werden nur über Statusänderungen von Objekten informiert, die für sie selbst sichtbar sind. Es existiert für jedes Objekt (entity) genau ein Client, der dieses Objekt verwaltet. Wenn ein Objekt für einen anderen Client interessant wird, dann wird eine Kopie des Objektes angelegt. Die Statusänderungen werden durch Nachrichten (messages) übertragen. Die Server fungieren dabei als Filter für Nachrichten. Problematisch wirkt sich dabei aus, daß jede Kommunikation über den Server abläuft und beim Server die räumlich Aufteilung der gesamten Umgebung bekannt sein muß. Das RING System benutzt verschiedene Methoden, um die Ressourcen effizient auszunutzen. So wurde z.B. eine Erweiterung vorgeschlagen (multiresolution update), die dafür sorgt, daß die Position von Objekten, die räumlich weiter vom Betrachter entfernt sind, mit einer geringeren zeitlichen Auflösung aktualisiert wird als Objekte, die sich dicht beim Betrachter befinden.

2.5.13

MR-Toolkit Peer Package

Das Minimal Reality (MR) Toolkit wurde an der University of Alberta entwickelt (/SHA92/, /SHA93a/). MR ist eine Programmbibliothek, mit der es möglich ist, Applikationen für virtuelle Umgebungen zu entwickeln. MR basiert dabei auf einer Client/Server Architektur, bei der die Gerätetreiber als Server fungieren. Von diesen Servern rufen die Applikationen dann die benötigten Daten ab. MR stellt eine Softwarebasis für die Entwicklung von Einzelplatz VR-Anwendungen dar. Peer Package ist eine Erweiterung des MR Systems und wurde an derselben Einrichtung entwickelt (/SHA93b/). Mit Peer Package ist es möglich, MR-Applikationen miteinander über ein Netzwerk zu verbinden. Dies macht das MR-System zum Multi-User VR System. Die Kommunikation der einzelnen Stationen basiert auf Punkt-zu-Punkt Verbindungen. Die Netzwerktopologie ist dabei ein vollständig konnektierter Graph, d.h. jede Applikation besitzt Verbindungen zu jeder anderen Applikation. Durch diese Vorgehensweise wächst der Kommunikationsbedarf quadratisch mit der Anzahl der beteiligten Nutzer. MR Peer Package ist deshalb nicht in der Lage, die Probleme großer, verteilter virtueller Umgebungen mit vielen Nutzern zu lösen. Die Implementation basiert auf UDP, einem verbindungslosen Transportprotokoll /LOO91a/. MR Peer Package besitzt keine Methoden zur Unterbindung der Nachteile von UDP. Diese Nachteile liegen darin, daß der Empfang von Paketen nicht bestätigt wird. Außerdem kann sich die Reihenfolge der Pakete durch die Übertragung ändern, so daß ein Paket A, welches früher als ein Paket B abgeschickt wurde, später beim Empfänger ankommt, als das Paket B. Deshalb eignet es sich nur für den Einsatz in schnellen LANs, in denen davon ausgegangen werden kann, daß keine Verzögerungen beim Routen der Pakete auftreten und in der Regel alle Pakete ankommen. Als Demonstration wurde ein Multi Player Handball vorgestellt. Mit einem weiteren Zusatzmodul, dem Umgebungsmanager (Environment Manager, EM) werden einige der Probleme in Angriff genommen (/WAN95/). Netzwerkverkehr wird durch verschiedene Methoden (u.a. lokale Simulation, Nachrichtentransfer nur an relevante Empfänger) verringert. Weiterhin werden verteilte Objekte und Zugriffsrechte benutzt. Der EM vereinfacht aber nicht nur die Arbeit mit verteilten Systemen mit mehreren Nutzern, sondern auch Einzelplatzsysteme profitieren von dieser Systemerweiterung.

2.5.14

Waves / Hidra

Die Waves (Waterloo virtual environment system) Architektur wurde von Rick Kazman (University of Waterloo, Canada) vorgestellt (/KAZ93a/). Die Architektur geht davon aus, daß eine virtuelle Umgebung aus einer Anzahl Nachrichtenverwaltern (message managers) besteht, die die Kommunikation zwischen Stationen (hosts) realisieren. Die Nachrichtenverwalter leiten Nachrichten von einer Station zu einer anderen und fungieren dabei auch als Nachrichtenfilter. Eine Station kann einem Nachrichtenverwalter explizit mitteilen, daß sie nur bestimmte Nachrichten empfangen will. Die Stationen sind Prozesse, die Objoids simulieren. Objoids ist ein Kunstwort, welches bei Waves für Objekte in der virtuellen Umgebung steht. Ein Objoid besteht aus einem internen Status, exportierten Attributen und einer Anzahl ausführbarer Verhaltensvorschriften, mit denen der interne Status des Objoids dezentral und autonom aktualisiert werden kann. Virtuelle Welten in Waves enthalten nichts außer solchen Objoids. Die Stationen stellen den Objoids Serviceleistungen wie Simulation, Interaktionserkennung und -auflösung (interaction detection and resolution) und Visualisierung zur Verfügung. Objoids können auf einfache Weise von einer Station zu einer anderen übertragen werden, da die gesamte Beschreibung eines Objoids in Parameter überführt werden kann. Diese Parameter können über das Netzwerk an eine andere Station übertragen werden. Dort existiert das Objoid als Kopie (clone) weiter. Es ist in der Lage, seinen internen Status eigenständig zu ändern und seinen Zustand mit dem Originalobjoid abzugleichen. Leider wird in den Quellen nichts über die Implementation und die Parameterisierung der Objoids ausgesagt. Dieser Umstand ist bedauerlich, da gerade die Darstellung der Verhaltensvorschriften als Parameter der Objoids eine komplexe Aufgabe zu sein scheint. Es ist denkbar, daß die Lösung des Problems durch eine Art Interpreter bewerkstelligt wurde, mit dessen Hilfe die parametrisierten Verhaltensprogramme ausgeführt werden können. Der Autor des Systems, Rick Kazman, teilte auf Anfrage mit, daß das Projekt nicht mehr weiterverfolgt wird und deshalb keine weiteren Informationen verfügbar seien. Die Verhaltensvorschriften der Objoids enthalten auch explizite Verhaltensmodelle (explicit behavioral models). Diese Modelle erlauben es, zukünftiges Verhalten von Objoids vorherzusagen. Damit können z.B. Verzögerungen beim Nachrichtentransfer ausgeglichen werden. Interaktionserkennung wird in Waves durch separate Stationen durchgeführt. Dabei simulieren diese Stationen eine Anzahl Objoids. Die Interaktionserkennung und -auflösung erfolgt über separate Vorschriften. Die Objoids interagieren also nicht selbst, sondern Interaktionen werden von der Implementation der Objoids getrennt definiert. Dabei besteht eine Interaktionsdefinition aus zwei Teilen: einem Interaktionserkennungsteil und einem Interaktionsauflösungesteil. Die Interaktionserkennung erfolgt zentral, also nur an einer Stelle im Gesamtsystem. Der Engpaß, der sich dadurch ergeben könnte, wird in Waves dadurch gelöst, daß die Erkennung verschiedener Arten von Interaktionen auf verschiedenen Stationen (Interaktionserkennungsstationen) durchgeführt werden kann. Die Waves Architektur wurde mit dem Prototypen HIDRA (Higly interactive distributed real-time architecture) implementiert (/KAZ95/, /KAZ93b/). Leider ist dieser Prototyp nicht frei verfügbar und das Projekt wird derzeit nicht weiterentwickelt.

2.5.15

Demand Driven Geometry Transmission

Schmalstieg und Gervautz vom Institut für Computergrafik der technischen Universität Wien stellen verschiedene Methoden zur Minimierung der Netzwerkbelastung in verteilten virtuellen Umgebungen vor (/SCH95/, /SCH96/). Ein Prototyp ist als Client/Server System ausgelegt. Der Server hält dabei die Daten der gesamten Umgebung vor. Clients erhalten vom Server die Daten der für sie relevanten Objekte. Die Relevanz wird dabei durch das räumliche Umfeld des Clients festgelegt (Area of Interest, AOI). Hauptaugenmerk legten die Autoren auf die Optimierung des Transports von Geometriedaten. Dabei werden für Objekte Datenstrukturen eingesetzt, die verschiedene Detaillierungsgrade (Level of Detail, LOD) enthalten. Wird ein Objekt für einen Client interessant, so wird das Modell des Objektes in der geringsten Auflösung an den Client übertragen. Ein Prefetch-Mechanismus sorgt dafür, daß die Übertragung der Daten vor der eigentlichen Visualisierung abgeschlossen ist. Die AOI um den Client besteht aus verschiedenen Zonen, denen jeweils ein LOD des Objektes zugeordnet ist. Bewegt sich der Client näher an das Objekt heran (bzw. das Objekt an den Betrachter), so werden entsprechend feinere Geometrieinformationen vom Server geladen. Die Autoren schlagen einen Serververbund vor, um die Skalierbarkeit des Systems zu gewährleisten. Jeder Server ist dabei für einen gewissen Teil der virtuellen Umgebung zuständig. Es existieren Objekte, die lediglich aus statischen Geometrieinformationen bestehen, Objekte, die zusätzlich statische Animationen beinhalten können und Objekte, deren Verhalten in einer Art Skript festgelegt werden kann. Dabei werden die Skripts hauptsächlich dazu benutzt, die Reaktion auf asynchrone Ereignisse zu definieren. Bei dieser Art der Objekte wird weiterhin unterschieden, ob das Skript durch den Server oder durch den Client interpretiert werden soll. Weiterhin sind externe Applikationen möglich, die über Clients in die virtuelle Umgebung eingebunden werden können. Das System von Schmalstieg und Garvautz besitzt den Charakter eines unvollständigen Prototypen. Tests mit vielen Nutzern und großen Umgebungen stehen noch aus und die verwendeten Mechanismen müssen noch optimiert werden.

2.6

Zusammenfassung

Neben der in der Beschreibung der einzelnen Systeme erfolgten Darstellung der Vor- und Nachteile, soll an dieser Stelle nochmals eine zusammenfassende Aufstellung wichtiger Parameter der Systeme erfolgen (Tabelle 2). Dabei wurde die anfänglich durchgeführte Systematisierung zugrunde gelegt. Der Prototypcharakter der meisten Systeme erschwert eine genaue Gegenüberstellung. Es zeigt sich, daß sich der Einsatz einer Client/Server Architektur nur dann für den Einsatz in verteilten virtuellen Umgebungen eignet, wenn diese Architektur entweder in Verbindung mit Punkt-zu-Punkt Kommunikation eingesetzt wird oder ein hierarchisches Client/Server System aufgebaut wird. Punkt-zu-Punkt Kommunikation stellt einen flexibleren Ansatz dar, ist aber nur in Verbindung mit Methoden zur Netzlastbegrenzung sinnvoll.

System	Kommunikations- methode	Verteilungs- methode	Netzlast- begrenzung	max. Nutzeranzahl	Komplexität der Welt
DIVE	Punkt-zu-Punkt	DeD-Vrep	Filtermechanismen	in einer Teilwelt < 10,	durch Einteilung in unabhängige Teilwelten hoch
VEOS	Punkt-zu-Punkt	DeD-Vrep	keine	keine Angaben, wahrscheinlich < 10	durch Kommunikations- und Verteilungsmethode beschränkt
dVS	Punkt-zu-Punkt	ZeD-Vrep	keine	keine Angaben, wahrscheinlich < 10	durch Kommunikations- und Verteilungsmethode beschränkt
VUE	Client/Server	ZeD-RepNB	keine	1 (Verteilung wird zum Zweck der Parallelisierung der Aufgaben eingesetzt)	hoch
Rubber Rocks	Client/Server	ZeD-Vrep	higher-level Events vorgeschlagen	keine Angaben, wahrscheinlich< 10	gering (durch Kommunikations- und Verteilungsmethode beschränkt)
VR-DECK	Punkt-zu-Punkt	ZeD-RepNB	Filtermechanismen (spezielle Regeln)	keine Angaben, wahrscheinlich < 10	mittel
BrickNet	Client/Server	ZeD-RepNB	Filtermechanismen	keine Angaben, wahrscheinlich < 10	mittel (Stationen verwalten nur benötigte Daten)
NVR	Client/Server	ZeD-Vrep	verzögerter Abgleich bei Überlastung, lokale Objekte	keine Angaben, wahrscheinlich < 10	durch Einteilung in unabhängige Teilwelten hoch
MASSIVE	hybrid	ZeD-Vrep	spatial model of interaction	keine Angaben, wahrscheinlich < 20	durch Einteilung in unabhängige Teilwelten hoch
AVIARY	hybrid	ZeD-RepNB	Filtermechanismen	keine genauen Angaben, wahrscheinlich < 10	keine genauen Angaben, durch Prototypcharakter wahrscheinlich gering
NPSNET	Punkt-zu-Punkt	DeD-Vrep	Dead Reckoning, Multicast	max. 300 (10 Mbit Ethernet LAN)	hoch (Datenmodell bei allen Staionen initial vorhanden)
RING	Client/Server	ZeD-RepNB	bedingte Nachrichten- weiterleitung	bis zu 1024	hoch (durch Aufteilung in dynamische Sichtbarkeitsräume)
MR	Punkt-zu-Punkt	DeD-Vrep	Erweiterungen (EM) vorgesehen.	keine Angaben, wahrscheinlich < 10	gering (durch Kommunikations- und Verteilungsmethode beschränkt)
Waves / Hidra	hybrid	DeD-RepNB	Filtermechanismen Abgleich nach Bedarf	keine Angaben, wahrscheinlich < 100	hoch
Demand Driven Geometry Transmission	hybrid	ZeD-RepNB	bedingte Nachrichten- weiterleitung	keine Angaben (Prototyp)	hoch (durch Art der Verteilung)

Tabelle 2: Systematisierung der untersuchten Systeme