KAPITEL 3.INTERAKTION DER MASCHINE ZUM MENSCHENClientVisualisierungVisualisierungRender<strong>in</strong>gRender<strong>in</strong>gSzeneSzeneClientVisualisierungVisualisierungRender<strong>in</strong>gRender<strong>in</strong>gSzeneSzeneServerVisualisierungVisualisierungServerVisualisierungVisualisierungRender<strong>in</strong>gRender<strong>in</strong>gSzeneSzeneServerVisualisierungVisualisierungServerVisualisierungVisualisierungRender<strong>in</strong>gRender<strong>in</strong>gSzeneSzeneAbbildung 3.4: Methoden zur Synchronisation e<strong>in</strong>er virtuellen Szenedie aktuelle Szene bereitzustellen und jeweils auf diesem Rechner die Darstellung zu berechnen.Dies ermöglicht zwar e<strong>in</strong>e hohe Ges<strong>am</strong>tperformance, br<strong>in</strong>gt aber die Problematik mitsich, dass jegliche Szenenänderung synchron auf allen verteilten Rechnern vorgenommen werdenmuss, d<strong>am</strong>it als Grundlage der Darstellung nicht verschiedene Szenen dienen. Es musshierbei also sichergestellt se<strong>in</strong>, dass e<strong>in</strong>e neue Änderung der Szene nur erfolgen darf, sobald alleangeschlossenen Computer die letzte Änderung erfolgreich aktualisiert haben. Diese Methodebietet ebenfalls den Vorteil der beliebigen Skalierbarkeit, da die Rechenleistung immer aufdie darstellenden Computer verteilt wird und nicht von e<strong>in</strong>em e<strong>in</strong>zelnen Computer getragenwerden muss.Im folgenden Kapitel wird der <strong>in</strong> dieser Arbeit entwickelte Lösungsansatz vorgestellt.3.1.3 UmsetzungAngelehnt an die Softwarestruktur (vgl. Kapitel 2.5.3) ist das Modul <strong>in</strong> zwei Teile untergliedert.Hierbei wurde e<strong>in</strong> Client-Server Ansatz umgesetzt, bei dem e<strong>in</strong> „Unifeye“ im Clientdie Verwaltung der ges<strong>am</strong>ten Szene übernimmt. Beliebige verbundene Server erhalten sämtlicheÄnderungen der Szene mittels e<strong>in</strong>er Netzwerkverb<strong>in</strong>dung, welche sie dann an e<strong>in</strong> lokales„Unifeye“ weiterreichen.Der Client steht hier der Applikation als Interface zur Verfügung und übernimmt dieKommunikation mit den Servern. Das bedeutet, dass für die Applikation nur der Client angesprochenwerden muss. Dieser ist für die Applikation identisch mit dem orig<strong>in</strong>alen „Unifeye“.Befehle der Applikation werden vom Client ausgeführt, visualisiert und zeitgleich automatischan den angeschlossenen Server weiter gesendet. Auf diese Weise erfolgt die ges<strong>am</strong>te Abwicklungder Synchronisation und Kommunikation <strong>in</strong>nerhalb e<strong>in</strong>er e<strong>in</strong>zelnen Komponente. Diesekann von jeder Applikation angesprochen werden und ist für die Applikation unabhängig <strong>in</strong>der Anzahl der verbundenen Server. Weiterh<strong>in</strong> können <strong>in</strong>nerhalb dieser Komponente weitereFunktionalitäten für die <strong>Interaktion</strong> mit der AR-Umgebung zur Verfügung gestellt werden.30
3.1. AUGMENTED REALITY ZUR VISUELLEN DARSTELLUNGSomit kann der Funktionsumfang des bestehenden „Unifeye“ erweitert werden.Grundlegend ist für die Umsetzung des Moduls AR die Entwicklung e<strong>in</strong>es def<strong>in</strong>iertenNachrichtenformats für die Erzeugung der zu sendenden Datenpakete. Aufgrund der Tatsache,dass hier Funktionen mit teils optionalen Par<strong>am</strong>etern verschickt werden sollen, kannhier ke<strong>in</strong>e e<strong>in</strong>fache Konvertierung <strong>in</strong> re<strong>in</strong>e Zeichenketten erfolgen. Die Auswertung wäre beiunbekannter Anzahl von Par<strong>am</strong>etern e<strong>in</strong>er Funktion nicht realisierbar. Aus diesem Grundwird auf das „ICE“ Fr<strong>am</strong>ework zurückgegriffen, dass für die Kommunikation von verteiltenRechenprozessen entwickelt und optimiert wurde [36]. Dieses übersetzt auf dem Server unddem Client def<strong>in</strong>ierbare Funktionsaufrufe mit deren Par<strong>am</strong>etern und Rückgabewerten <strong>in</strong> e<strong>in</strong>Format, das über Netzwerk übermittelt werden kann. Funktionen, die <strong>in</strong> diesem Fr<strong>am</strong>eworkdef<strong>in</strong>iert wurden, können danach im Progr<strong>am</strong>m aufgerufen werden, ohne dass zusätzlich fürdie Netzwerkübertragung gesorgt werden muss, da dieses das Fr<strong>am</strong>ework erledigt.Funktionsaufrufe der Applikation werden <strong>in</strong>nerhalb des Clients direkt an das lokale „Unifeye“weitergereicht. Gleichzeitig werden diese Funktionsaufrufe mittels „ICE“ <strong>in</strong> dessen Nachrichtenformatgewandelt und an die verbundenen Server verschickt. Hierbei liegt für jedeFunktion e<strong>in</strong>e exakte Beschreibung vor, <strong>in</strong> der der N<strong>am</strong>e der Funktion und ihre möglichenPar<strong>am</strong>eter und Rückgabewerte h<strong>in</strong>terlegt s<strong>in</strong>d. Anhand dieser Beschreibung werden Funktionen<strong>in</strong> e<strong>in</strong>en Str<strong>in</strong>g kodiert, der per UDP an alle verbundenen Server geschickt wird. DieBeschreibung ermöglicht den Servern anschließend, den übermittelten Str<strong>in</strong>g wieder <strong>in</strong> dieursprüngliche Funktion s<strong>am</strong>t se<strong>in</strong>er Übergabewerte zu dekodieren. Diese Funktion wird dann<strong>in</strong>nerhalb des Servers an dessen lokales „Unifeye“ weitergeleitet und ausgeführt. E<strong>in</strong>ige Funktionsaufrufedes „Unifeye“ liefern Rückgabewerte, wie etwa die Abfrage von Sichtbarkeitenvirtueller Objekte. Diese Rückgabewerte werden nur <strong>in</strong>nerhalb des Clients verwendet und abgefragt.Server erhalten von Client ke<strong>in</strong>e Funktionen weitergereicht, die Rückgabewerte liefernwürden (unidirektionale Übertragung). Server haben also e<strong>in</strong>en re<strong>in</strong> darstellenden Charakterund dienen nur der Visualisierung. Somit stellt diese Komponente den vollen Funktionsumfangdes orig<strong>in</strong>alen „Unifeye“ zur Verfügung.Die Übertragung der Str<strong>in</strong>gs, die die Informationen der auszuführenden Funktionen enthalten,erfolgt nicht mittels TCP, sondern über UDP. Aufgrund der Kontrolle des Paketaustausches,die e<strong>in</strong>e sichere Übertragung garantiert, entstehen teils sehr hohe Laufzeiten fürDatenpakete. Diese verr<strong>in</strong>gern die maximale Anzahl an Befehlen pro Zeit erheblich (<strong>in</strong> Testsbetrug die Rate teilweise unter fünf Befehle je Sekunde). Dyn<strong>am</strong>ische Manipulationen, wieetwa Translationen s<strong>in</strong>d d<strong>am</strong>it auf e<strong>in</strong>e bestimmte Anzahl von Schritten pro Zeit begrenztund führen zu e<strong>in</strong>er ruckartigen Darstellung. Daher erfolgt die Übertragung mittels UDP.Die Übertragungsraten s<strong>in</strong>d hier wesentlich höher (etwa 20 Befehle je Sekunde) und ermöglichenso flüssigere Manipulationen. Gleichzeitig wird aber auf die Sicherheit der Übertragungverzichtet.Um die Synchronisation zu gewährleisten, wurde e<strong>in</strong>e eigene Funktion erstellt, die als e<strong>in</strong>zigee<strong>in</strong>en Rückgabewert liefert. Sendet also der Client diese Funktion an e<strong>in</strong>en Server, erhältder Client erst e<strong>in</strong>e Antwort des Servers <strong>in</strong> Form e<strong>in</strong>es Rückgabewertes, sobald dieser sämtlichevorher übertragenen Befehle ausgeführt hat, und er diese spezielle Funktion ausführt. DieseFunktion besteht lediglich aus dem Rücksenden e<strong>in</strong>es e<strong>in</strong>fachen boolschen Wertes (true). Aufdiese Weise kann der Client erfahren, ob alle Server die Aktualisierung der Szene gemäß demletzten Befehl abgeschlossen haben. Dadurch werden alle Server synchronisiert, da der Clientden nächsten Befehl erst nach dem Erhalt des boolschen Wertes (true) aller Server versendetund somit auf alle Server wartet.31