<<

Gruppe1 - M.K.K.R.

Installation: "Snow Control"



Dokumentation der Installation


PDF Version

Zum Ausdruck empfehlen wir die folgende ausführlichere PDF Version: PDF downloaden


Projektdateien

Projektdateiendownloaden


Bildergalerie

Bildergalerie



Zur Verdeutlichung des Datenflusses kann man sich unter dem folgenden Link unser interaktives Datenflussdiagramm ansehen: Datenflussdiagramm in Flash


Ton im Video entspricht den Sounds in der Installation





Table of contents





Abstract

Die Gruppe M.K.K.R. befasst sich in ihrer interaktiven Medieninstallation "Snow Control" mit der Thematik der Interaktion zwischen Beobachter und Beobachtetem (beobachteten Beobachters / Interaktion der Interakteure).

Die Installation besteht aus drei räumlich von einander getrennten Stationen, der "Gaming-Area", dem "Public-Space" und dem "Operator-Room". Diese repräsentieren die verschiedenen Benutzertypen der Installation: Es gibt den Interakteur (USER), den beobachtenden Interakteur (OPERATOR) und die Beobachter (Zuschauer im Publicbereich).

Funktion:

In der Installation wird der Hauptakteur, genannt "USER", dazu aufgefordert, spielerisch aus sich heraus zu gehen und ein interaktiv inszeniertes Videospiel zu meistern und dabei einen möglichst hohen Punktestand zu erreichen. Der USER sieht sich dabei als Silhouette (gefüllte Fläche) auf einer Großbildfläche, auf welcher dieser kurz erscheinende virtuelle Objekte mittels körperlicher Gestiken (Positionierung der Hände) treffen muss und dadurch Punkte sammelt.

Während des Spielprozesses erhält eine dem USER unbekannte Person, genannt "Operator", Zugriff auf visuelle und auditive Parameter des Spieles und kann dadurch den Akteur in seiner Spielweise beeinflussen, um ihn in einer Performance für den Public Bereich vorzuführen, ohne dass dieser während dem Spiel etwas davon erfährt. Der Operator ist hierbei die allwissende, kontrollierende Instanz, da er im Gegensatz zu den anderen Teilnehmern von allem weiß. Dies wird auch durch seine Positionierung dargestellt, da er den User von oben herab beobachten und steuern kann. Er steht am oberen Ende der "Wissenskette". Die Herausforderung für den Opperator besteht also darin eine Performance / Vorführung für den Public Bereich zu gestalten indem er versucht den User über visuelle und auditive Elemente zu steuern und zu beeinflussen.

Abb. 1: Raum- & Installationsübersicht


Namensgebung


Die Installation erhielt ihren Namen "Snow Control" als Mischung aus den Beschreibungen des Game- und Operator Bereiches. Das Wort Snow ist vom winterlich angehauchten Gamedesign sowie dem Abwehren von Schneebällen abgeleitet. Der zweite Teil "Control" verdeutlicht die Möglichkeit, den User im Spiel als Operator steuern zu können. Gepaart bilden Sie den Grundgedanken, den die Installation verfolgt - die unbemerkte Ausübung von Kontrolle im Spiel.



Ablauf

Gaming Area

Grundannahme:
Der USER ist unwissend er weiß von keiner anderen Station.

Aufgabe:
Das Spiel zu absolvieren, möglich viele Punkte sammeln

Thema:
Schneeballschlacht

Der User betritt den Raum und er wird durch einen Gang um den Screen herum geleitet. Er zieht sich die bereitliegende Handschuhe an. Auf dem Screen sieht er in der Mitte ein Welcome Screen, welcher ihn auffordert seinen Namen einzugeben. Dies geschieht über ein eingeblendetes Buchstabenfeld, dessen Buchstaben per Tracking ausgewahlt werden (wie bei Konsolenspielen). Dazu läuft die Jeopardy Melodie. Auf dem rechten anderen Screen steht der aktuelle Highscore. Nach der Eingabe erscheint eine kurze Anweisung "FANG DIE Schneebälle!!!" Dann startet ein Countdown. Danach folgt der Spielablauf, bei dem Objekte (Schneebälle) auftauchen und bei Kollision (Punktezahl taucht auf, Highscore erhöht sich) oder nach einer gewissen Zeit (Lifetime) verschwinden. Der Highscore wird auf dem rechten Screen angezeigt, die aktuelle Punktzahl auf dem linken Bildschirm.

Das Spiel läuft 120 Sekunden lang, die Zeit wird rücklaufend auf dem Screen angezeigt. Abschließend wird die erreichende Punktezahl angezeigt und ggf. die Position im Highscore Bereich. Während sich der USER mit der Installation beschäftigt, läuft im Hintergrund peppige Musik, außerdem ertönen ab und zu aufheiternde, ermunternde Sounds, diese sollen dem USER zusammen mit weiteren visuellen Effekten (Spiegelbild, auf den Kopf stellen), die vom Operator gesteuert werden, eine gewisse Willkürlichkeit suggerieren.

Layout:
Das Spiel findet in Futwangen statt, also dient auch ein Foto der verschneiten Hochschule als Hintergrund. Der User ist als Silhouette zu sehen und wird mit Schneebällen beworfen, die auftauchen und immer größer werden (fliegen auf ihn zu). Die Aufgabe ist also die Bälle abzuwehren, wenn die Schneebälle ihre LifeTime überschreiten (also nicht abgewehrt werden) treffen sie auf der "Kamera" auf und zerplatzen. Dies gibt Minuspunkte, wo hingegen abgewehrte Bälle Pluspunkte ergeben. Ggf. können die Füße zusätzlich noch zur Abwehr benutzt werden, sofern die Technik dies zulässt.

Abb. 2: Gamingscreen


Public Space:

Grundannahme:
Die Beobachter wissen vom USER und ggf. vom Operator

Am Screen ist ein Video zu sehen, eine Person bewegt sich auf einer virtuellen Bühne zur Musik (Sisscor Sisters - I don't feel like dancing). Die Musik kommt aus den Lautsprechern (einfache Stereo Sound aus Lautsprechern auf dem Boden). Die Performance ist wird live aus dem MediaLab übertragen, jedoch ohne die Schneebälle. Wenn keine Performance stattfindet, werden archivierte Videos abgespielt.

Abb. 3: Public Space Bildschirmdarstellung


Operator Room:

Grundannahme:
Der Operator weiß von allen 3 Stationen.

Aufgabe:
Mit Hilfe der Funktionen den USER zu beieinflussen und vorzufuehren.

Auf dem Operator Screen sind Buttons (mit Beschriftung) für die Sounds und die Effekte zu sehen sowie in der Mitte das aktuell, live aufgezeichnete Bild des Users. Auf dem Videobild kann der Operator klicken um an der Stelle Schneebälle erscheinen zu lassen. Die max. Anzahl der Objekte ist begrenzt (z.B. 5 Stück). Der Operator kann rechts aus dem Fenster hinab auf den USER schauen. Dies stellt die "Über" Position des Operators dar. Auf seinem Screen erscheint Parallel zum USER eine Startsequenz sobald der User seinen Namen eingegeben hat. Erst danach kann er die volle Funktionalität nutzen. Anschließend hat er ebenfalls wie der USER Zeit um sich "sein Werk" auf dem Screen anzuschauen.

Funktionen:
Dem Operator stehen folgende Möglichkeiten (Buttons) zur Verfügung:

  • Spiegeln (horizontal & vertikal)
  • SlowMo (User bewegt sich langsamer)
  • Scale (User wird kleiner dargestellt, muss sich mehr bewegen)
  • diverse Sprachtasten mit hinterlegten Sounddateien
Abb. 4: Operator Terminalscreen




Raumzusammenhänge

Abb. 5: Zusammenhang der einzelnen Räume


Use Cases

Projektphasen

Abb. 6: Projektphasen



Technische Umsetzung



Raumaufbau

Der Raumaufbau unserer Installation entsprach dem geplanten Modell, jedoch mussten wir uns auf Grund des tatsächlichen Platzes und der technischen Einrichtungen etwas einschränken. So konnten wir den Eingang beispielsweise nicht mehr realisieren, da wir die zur Verfügung stehenden Trennwände alle zum Aufbau des Greenscreens benötigten und der Platz, auf Grund der Ausdehnung des Greenscreens, nicht ausgereicht hätte. Die „Green-Wall“ hatten wir ebenfalls leicht unterschätzt, so dass wir zunächst die Stellwände auf Tischen montieren mussten um die benötigte Höhe zu erreichen. Die Breite verschlang alle sechs Stellwände. Die Höhenbegrenzung erlaubte uns daher auch nicht weiter nach hinten zu rücken, da die Fläche zu klein gewesen wäre und den Hintergrund nicht mehr komplett ausgefüllt hätte. Um dies auszugleichen hätten wir mit der Kamera näher heran zoomen müssen, wodurch die Bewegungen des USERs nicht mehr ganz erfasst worden wären. Dadurch bedingt, hatten wir leider auch nur einen begrenzten Spielraum für die Lichtsetzung, da wir die Studiolichter leider nur rotieren und neigen, jedoch nicht verschieben konnten. Die Rückprojektions-Leinwände waren in ihrer Position auch beschränkt, da sie nur auf und ab gefahren werden konnten und sich nicht vor oder zurück bewegen ließen. Für eine perfekte Umgebung unserer Installation hätten wir daher weitere und höhere Stellwände benötigt, daraus resultierend ein größeres grünes Tuch, mehr Platz um den Eingang umzusetzen und ein besseres Lichtsetting. Berücksichtigen wir jedoch die physikalischen und technischen Rahmenbedingungen, so lässt sich konstatieren, dass wir aus unseren Möglichkeiten das Beste gemacht haben und ein optimales Ergebnis für die Installation erzielen konnten.

Raumaufbau



Vorgehensweise

Nachdem das Konzept feststand, begannen wir mit der Umsetzung. In den Weihnachtsferien entstanden die ersten Flashmodule, bestehend aus einer ersten Spielversion, die bereits eine Highscoreliste, einen Timer und zu Testzwecken eine Spielfigur besaß. Die Spielfigur konnte über die Pfeiltasten bewegt werden und diente dazu, die zu diesem Zeitpunkt per Zufall erstellten Schneebälle über eine Hittest-Abfrage einzusammeln. Des Weiteren wurden während dieser Zeit im Tonstudio des Radiosenders „Fips“ in Göppingen die Sounddateien für den Operator aufgezeichnet. Nach den Ferien begann dann die Integration der Flashapplikation für den Operator und das Testen der Kommunikation über Max durch das Plugin flashserver. Parallel wurden erste Trackingsysteme ausprobiert und die Verknüpfung der Komponenten in Max Patches vorbereitet. Auf Grund der Problematiken mit der Belegung des Media Labs war es uns leider nicht möglich, unseren Entwicklungsstand zu testen und somit nicht am Tag der Medien präsentieren zu können. Nach einer Pause, verursacht durch die anstehenden Klausuren, hatten wir drei Tage Testzeit im Media Lab zzgl. einiger Tests in einer improvisierten Testumgebung in der Wohnung eines unserer Teammitglieder. Die dabei auftretenden Probleme konnten zwar noch gefixt werden, verhinderten jedoch die komplette Fertigstellung sämtlicher Zusatzfeatures unserer Installation.



Probleme



Generell


Problem: Welche Kamera nehmen wir?

Lösungsansätze:

  • Fire-I Firewire Kamera (640 x 480)
  • Sony Handycam Firewire MiniDV Kamera (PAL 720 x 576) (Consumer Kamera)
  • Sony HVR Z1 E (HDV Kamera)

Ergebnis:
Bei den ersten Heimtests mit der Fire-I Camera erzielten wir hinsichtlich des Trackings und unter Berücksichtigung der bescheidenen Lichtverhältnisse, recht gute Ergebnisse. Jedoch zeigte sich am ersten Testtag, dass diese Kamera zum Chromakeying nicht zu gebrauchen war, da die Farbdarstellung sehr zu wünschen übrig ließ. Also ersetzten wir die Kamera durch die Consumer Cam Sony Handycam Firewire MiniDV, welche ein besseres Bild lieferte und uns half das Differenzbild Patch zu entwickeln. Um ein noch besseres Ergebnis zu erhalten liehen wir uns die Sony HVR Z1 E aus und zeichneten das DV Signal in Max auf, da Max kein HD Videosignal verarbeiten kann.

Problem: Max/Msp erkennt die Kamera nicht mehr obwohl sie aus- und wieder eingesteckt wurde.

Lösungsansatz:

  • Deinstallieren der Kamera und erneutes Verbinden

Ergebnis:
Die Kamera konnte wieder ohne Probleme verwendet werden.

Problem: Wie schaffen wir es Videodaten über das Netzwerk zu versenden?

Lösungsansätze:

  • WLAN
  • LAN 100 MBit
  • FireWire
  • LAN 1000 MBit

Ergebnis:
Bei unseren ersten Tests die Daten in Max über ein Netzwerk an verschiedene Rechner zu schicken stellten wir folgendes Problem fest: Um eine Videomatrix, bestehend aus vier Planes mit einer Auflösung von 640 x 480 und jeweils 8 bit ergeben sich bei 25 fps ein Daten Volumen von ca. 30 MB pro Sekunde. Um dieses Datenvolumen in der benötigten Echtzeit zu versenden, fielen die Optionen Wlan und 100 Mbit LAN schon einmal weg. Die Option des Firewire Kabels schied durch die Längenbegrenzung von 5m pro Kabel aus, da wir eine Kabelstrecke von mind. 20m in den ersten Stock überwinden mussten. Das Ergebnis war also ein lokales Netzwerk über einen 1000 Mbit Switch, den wir uns zum Glück von der Hochschule besorgen konnten.



MAX/MSP


Problem: Wie setzen wir das Spielsystem allein in Max um?

Lösungsansätze:

  • Einbettung von OpenGL in Max und Benutzung des Partikelsystems für die Schneebälle
  • Flash Anwendung

Ergebnis:
In Max stellten sich uns die Probleme, dass wir eine Möglichkeit brauchten auf die erzeugten Objekte individuell zugreifen zu können. Das bedeutete die Implementierung einer höheren Programmiersprache. Auf Grund unserer geringen Kenntnisse in Max und der weit aus größeren Kompetenz in Flash und Actionscript entschieden wir uns dafür das Spiel mit Flash zu realisieren, um sowohl qualitativ, funktional als auch optisch ein einheitliches ansprechendes Design zu gewährleisten, da uns dies sehr wichtig für das Spielelement unserer Installation war. Max würde die Aufgabe übernehmen, die Videobearbeitung und Datenkommunikation zu verwalten.

Problem: Wie kommunizieren wir mit Max?

Lösungsansatz:

  • Das Flashserver PlugIn

Ergebnis:
Max stellt leider von Haus aus keine Möglichkeiten zur Kommunikation mit Flashanwendungen bereit. Es ist zwar möglich Flashanwendungen in Max einzubetten und abzuspielen, jedoch benötigten wir die Möglichkeit auch Daten, z.B. die Trackingdaten und Videodaten in Echtzeit an die Flash Anwendung weiter zu schicken. Bei unseren Recherchen stießen wir auf das eigens für Max von einem USER geschriebene PlugIn Fashserver. Dieses erlaubt die Kommunikation von Max und Flashanwendungen, indem die Daten von Flash gesendet werden und diese dann in Max als Strings ankommen und dort ggf. als Integer oder ähnliches interpretiert werden können.

Problem: Wie senden wir die benötigten Videodaten an Max? Flashserver erlaubt nur Strings!

Lösungsansätze:

  • Aus Max raus senden an die TV out Schnittstelle und das Videosignal zum Flashserver weiterleiten und dort über die TV in Schnittstelle in Flash als Videosignal abgreifen
  • Überlagern der Flash Applikation und einem Transparenten Video auf dem Präsentationsscreen
  • Überlagerung beider visuellen Elemente durch einen zweiten Beamer
  • Lucid – Ein Programm um Windowsfenster transparent zu schalten

Ergebnis:
Erstere Lösung fiel weg, da diese zu hardwarelastig gewesen wäre und wir nicht sicher auf das benötigte Material zurückgreifen konnten. Also Beschlossen wir das Videosignal (Silhouette) in Max zu erstellen und über das Flashgame drüber zu legen. Bei Recherchen stießen wir auf das Tool Lucid, mit Hilfe dessen wir die Flashapplikation transparent schalten konnten und die Silhouette in Max auf weißem Hintergrund dahinter legen konnten.



User Bereich


User Bereich



Problem: Wie kommen wir an die benötigten Trackingdaten?

Lösungsansätze:

  1. Tracking mit cv.jit.track und cv.jit.features2track in Max/Msp
    • Beschreibung:
      • Tracken eines individuellen Pixels
    • Vorteile:
      • Sehr genau
    • Nachteile:
      • Sobald man das zu trackende Objekt aus dem Bereich, den die Kamera aufnimmt, heraus und wieder hinein hält, wird der Bereich nicht wieder erkannt -> nicht zu verwenden
  2. Tracking mit dem Program CamSpace (http://www.camspace.com)
    • Beschreibung:
      • Tracken von mehreren Objekten mit bestimmten Farben
      • Entwickelt zur Steuerung von Spielen mit der Webcam
    • Vorteile:
      • Sehr genau
      • Trackt die Farbigen Objekte Optimal
      • Erkennt auch z-Achse
      • Kein einheitlicher Hintergrund nötig
    • Nachteile:
      • Von Haus aus nur Emulation von Maus, Tastatur, Joystick oder Gamepad
      • Mehrere Mäuse nicht möglich
      • Anbindung der Programmiersprache „Lua“ möglich, die uns allerdings nicht geläufig ist
      • Keine Vernünftige Anbindung an Max/Msp oder Flash, daher hätte das Spiel komplett in Lua programmiert werden müssen
  3. Infrarot-Tracking mit den vorinstallierten Geräten im MediaLab
    • Vorteile:
      • Äußerst genau
      • Erkennt auch z-Achse
    • Nachteile:
      • Bisher keine Max/Msp-Anbindung bekannt
      • Koordinaten müssen in sinnvolles Format umgewandelt werden
      • Zu wenig Zeit zum Testen im MediaLab
  4. Tracking mit dem Programm tbeta (http://tbeta.nuigroup.com/)
    • Beschreibung:
      • Eigentlich gedacht für Multi-Touch-Tische
      • Erkennt weiße Punkte auf einem invertierten Eingangssignal und weist jedem Punkt eine eigene ID zu
    • Vorteile:
      • Anbindung an Flash vorhanden
      • Sehr genaue Erkennung
    • Nachteile:
      • Anpassen des Kamerasignals auf kontraststarkes Schwarz-Weiß ist schwierig
      • Realisierung nur mit Lichtern möglich -> Probleme beim Ausleuchten
  5. Tracking mit jit.findbounds in Max/Msp
    • Beschreibung:
      • Tracken von mehreren Objekten mit bestimmten Farben
      • Legt ein Quadrat um den Bereich mit dem angegebenen Farbwert und ermittelt die x/y-Koordinaten der Ecke oben links und unten rechts
    • Vorteile:
      • Bei guter Beleuchtung recht genau
      • Verliert das zu trackende Objekt nicht, wenn es den Bereich der Kamera verlässt
    • Nachteile:
      • Beleuchtung muss stimmen
      • Bei falscher Toleranz leicht Interferenzen mit z.B. ähnlich farbiger Kleidung oder Hautfarben
    • Probleme:
      • Umwandlung der Koordinaten von jit.findbounds in sinnvolle Koordinaten für das Tracking nötig, da jit.findbounds vier statt den benötigten zwei Koordinaten liefert.

Ergebnis:
Alle getesteten Varianten bieten bei optimalen Verhältnissen ein recht genaues Tracking. Die Idee, Camspace für das Tracking zu verwenden, mussten wir verwerfen, da das Erlernen und Umsetzung mit der Programmiersprache Lua zu viel Zeit in Anspruch genommen hätte. Das Tracking mit den Infrarot-Kameras des MediaLabs mussten wir leider auf Grund der fehlenden Zeit im MediaLab streichen. Das Tracking mit tbeta zu realisieren wäre ein zu großer Aufwand gewesen, da es mit der Lichtsetzung Probleme gegeben hätte und wir mehrere Kameras gebraucht hätten um ein Signal für tbeta und die anderen Bereiche zu erstellen.
Als einzige sinnvolle Möglichkeiten blieb daher cv.jit.track und jit.findbounds. Das Problem mit dem Verlassen des Bereiches bei cv.jit.track lies sich nicht beheben und so beschlossen wir, jit.findbounds zu verwenden, das in den ersten Tracking-Tests bei guter Beleuchtung passable Ergebnisse erzielte. Die Optimierung und Umrechnung der Ergebnisse erschien uns im Gegensatz zu den anderen Tracking-Varianten leichter und weniger zeitaufwendig.
Probleme ergaben sich dann bei den Tests im MediaLab. Da wir für den Public-Screen möglichst keine Schatten auf dem Green-Screen haben durften, allerdings trotzdem für das Tracking eine gute Ausleuchtung aus verschiedenen Positionen benötigten, damit die Tracking-Hände auch beim Kippen der gleich beleuchtet werden, mussten wir einen Kompromiss finden, der zu Lasten der Tracking-Genauigkeit ging. Dies hätten wir mit mehr Lichtquellen und mehr Testzeit im MediaLab beheben können. Sowohl das Überziehen der Tracking-Hände mit farbigem Papier als auch die Gummi-Handschuhe erwiesen sich als schlecht, da beides das Licht zu stark reflektierte. Dies konnten wir bei den Tracking-Händen mit Stoff-Überzügen eindämmen.
Nach den letzten Tests kamen wir auf die Idee, runde Gegenstände zum Tracken zu verwenden. Leider erwiesen sich alle getesteten Gegenstände als zu klein.
Falls wir die Installation doch noch vor Publikum präsentieren sollten, könnten wir uns mehr mit dem Infrarot-Tracking im MediaLab beschäftigen, da dieses in absehbarer Zeit wohl nicht mehr in Anspruch genommen wird.

Problem: Die von Max verarbeiteten aufgenommenen Tracking-Koordinaten stimmen nicht mit den Koordinaten in Flash überein.

Lösungsansatz:

  • Multiplizieren und Subtrahieren verschiedener Berechneter Werte von den Tracking-Koordinaten

Ergebnis:
Da Max den Null-Punkt links oben ansetzt, die Schneeball-Erzeugung allerdings von einem Null-Punkt in der Mitte ausgeht, waren hier einige Subtraktionen (um die Hälfte der USER-Screen-Breite bzw. -Höhe) nötig. Da die Kameraauflösung nicht der Auflösung des USER-Screens entspricht waren hier Multiplikationen (640x480 -> 800x600 daraus folgt: mal 1,25) nötig, damit man mit dem Tracking jeden Punkt innerhalb des Spiel-Bereiches erreicht.

Problem: Das Tracking ist sprunghaft und das Tracking-findbounds-Patch „verliert die zu Trackenden Gegenstände aus dem Auge“

Lösungsansätze:

  • Erhöhen der Metro-Geschwindigkeit in Max/Msp
  • Verbessern der Beleuchtung

Ergebnis:
Da unser Tracking sehr stark von den Lichtverhältnissen und einer gleichbleibenden Farbe abhängig ist und sich diese beim Kippen eines Gegenstandes sofort ändert, ist eine gute Ausleuchtung unbedingt notwendig. Wir stellten bei den Tests fest, dass Tageslicht wesentlich besser geeignet ist, da sich dort das Licht gleichmäßiger verteilt. Des Weiteren stellten wir fest, dass die Geschwindigkeit, mit der Max/Msp die Tracking-Daten an Flash sendet recht hoch sein muss, damit es nicht zum Stocken der Tracking-Kreuze kommt.

Problem: Es entstehen Schneebälle beim Start des Spiels, ohne das geklickt wurde, Daten tauchen an Stellen auf, an die sie nicht gehören und Daten werden erst beim nächsten Versand verschickt.

Lösungsansatz:

  • Ersetzen der Schalter im Flashserver-Patch durch if-Abfragen

Ergebnis:
Immer wieder kam es beim Start zu ungesetzten Schneebällen. Wir fanden heraus, dass die Schalter in Max auf ihrer letzten Position blieben und beim erneuten Senden von Daten zu spät umschalten. So wurden ungewollt Daten an das Spiel geschickt, die die Schneebälle erzeugen. Weiterhin kam es zu einem Verarbeitungsfehler in der USER-Flash-Datei.

Problem: Wie speichern wir die erreichten Ergebnisse der Spieler (Highscore) und lesen sie später wieder aus?

Lösungsansätze:

  • Kommunikation von Flash über einen Webserver mit einem PHP – Script, welches die Daten in einer SQL-Datenbank ablegt und wieder auslesen kann.
  • Kommunikation von Flash über einen Webserver mit einem PHP – Script, welches lokal .txt Files ablegt und diese wieder auslesen kann.
  • Speichern und auslesen der Daten direkt aus Flash heraus, über ein so genanntes SharedObject. Die Funktionsweise entspricht dem eines Cookies, und erlaubt Flash Daten lokal zu speichern.

Ergebnis:
Unter Berücksichtigung der bisher sehr komplexen technischen Umsetzung und der zu erwartenden Last auf der Netzwerkebene, entschieden wir uns für die Flash interne Variante mit einem SharedObject. Die dadurch entstanden Nachteile, wie der Datenverlust bei Löschung der temporären Dateien sowie der direkte Zugriff auf die Daten mittels zusätzlicher Tools (.sol Editor) waren uns dabei bewusst. Diese Entscheidung war allerdings vertretbar, da die Daten ohnehin nicht für eine längere Speicherung bzw. Nutzung vorgesehen waren.



Operator Bereich


Operator Bereich


Problem: Der Operator kann unbegrenzt Sounds an den USER-Bereich senden

Lösungsansatz:

  • Einführung eines Timers, der die Soundwiedergabe erst nach einer bestimmten Zeit wieder freigibt (für jeden Sound einzeln einstellbar)

Ergebnis:
Zum einen erreichten wir durch diese Methode, dass jeder Sound in voller Länge beim USER ankam, zum anderen hatte die Wartezeit, die der Operator durch diesen Timer hat, den Effekt, dass sich die Person, die den Operator bediente, mehr auf das Platzieren von Schneebällen konzentriert.



Public Bereich


Public Bereich



Problem:Wie schaffen wir es den USER vor einer virtuellen Bühne darzustellen?

Lösungsansätze:

  • Aufnahme des USERs vor dem Greenscreen und Compositing durch Chromakeying
  • Differenzbild zur Gewinnung der Alphamaske

Ergebnis:
Mit einem ersten Testvideo einer Person vor einem Greenscreen, welches wir uns aus dem Internet zu Testzwecken besorgten, erzielten wir recht gute Ergebnisse, die uns an dieser Lösung festhalten ließen. Jedoch zeigte der erste Tag im Media Lab, dass diese Methode sehr unausgereift war und es nicht möglich war in Max ein sauberes Compositing zu erhalten. Mit der alternativen Methode des Differenzbildes erzielten wir hingegen weitaus bessere Ergebnisse.

Problem: Wie synchronisieren wir die Wiedergabe der Musik im Public-Bereich

Lösungsansatz:

  • Senden eines Startsignals

Ergebnis:
Da wir die Tests lange Zeit ohne Sound ausgeführt haben, fehlte uns die Verknüpfung zwischen dem Start des Spiels im USER-Bereich und dem Abspielen der Musik für den Public-Bereich. Wir lösten das Problem, indem wir ein Start- und ein Endsignal einführten, mit denen wir an verschiedenen Stellen der Installation den Datenfluss zur richtigen Zeit kontrollieren und die Synchronität sowohl zwischen Spiel und Public-Bereich als auch zwischen Spiel und Operator gewährleisten konnten.

Problem: Der Sound muss stoppen sobald das Spiel zu Ende ist

Lösungsansatz:

  • Schneiden des Sounds auf die richtige Länge

Ergebnis:
Der Sound endet im Public-Bereich zwei Minuten nachdem das Spiel begonnen wurde.

Problem: Der Sound läuft stockend und viel zu langsam

Lösungsansatz:

  • Im Taskmanager Max/Msp nur einen Prozessor-Kern zuweisen

Ergebnis:
Max/Msp scheint Probleme bei der Soundwiedergabe zu haben, wenn etwas über das Netzwerk gesendet wird und zwei Prozessor-Kerne für Max/Msp zugeteilt sind.



Datenflussdiagramm

Datenflussdiagramm in Flash

Umsetzung in MAX MSP



Das Main Patch


Main Patch




Das Main Patch versorgt die einzelnen Komponenten der Installation mit Daten. Dies sind zum einen das Kamerasignal welches an das tracking_coordinates Patch geschickt wird, den Operator Background und den Videostream für den Public Bereich. Für den Public Bereich wird das Bild einer virtuellen Bühne eingeladen und mit dem freigestellten Videosignal zusammen an den Public Rechner gesendet. Die geschieht jedoch nur, wenn das Main Patch den Start Befehl vom Flashserver erhält, da in diesem Fall dann der Schalter auf „Durchlauf“ umgelegt wird und anschließend bei Erhalt des Ende Signals wieder zurückspringt.



Das Background Patch


Background Patch




Das Background Patch liefert den Hintergrund für das Videosignal, welches für das Game und den Operator verwendet wird. Da sich die Silhouette mit dem Flash-Screens überlagern, wird hier ein weißes Bild im Format 800 x 600 (Displaygröße des mittleren Matrox Screen im Media Lab) geladen. Dieses Bild wird dann als Matrix an das Main Patch zurückgegeben.



Das User_Camera Patch


User_Camera Patch




Über das User_Camera Patch wird das Videosignal der angeschlossenen Kamera abgegriffen und an das Main Patch zurückgeliefert.



Das Diff_Screen Patch


Diff_Screen Patch




Das Diff_Screen Patch erhält das Kamerasignal aus dem Main Patch. Über einen Snapshot wird dann das Differenzbild errechnet und durch Filter-Operationen zu einer Alphamaske umgerechnet, welche im Main-Patch zur Freistellung des Originalvideosignals für den Public Screen dient. Für die benötigte Silhouette werden die RGB Werte des Originalvideosignals mit Nullen gefüllt und anschließend samt dem gefilterten Bild im Alphakanal, mit dem ausgewählten Background Bild aus dem Background_Patch zusammengefügt.



Das Operator und Public Patch


Operator Patch


Public Patch




Das Public Patch erhält die Videomatrix vom Main Patch. Sobald Daten ankommen wird über die rechte Schaltung ein „bang“ erzeugt, welcher das Musikstück „public.wav“ abspielt.



Das flashserver Patch


flashserver Patch




Das Flashserver-Patch beschäftigt sich mit der Kommunikation zwischen Max/Msp und Flash. Dazu verwendeten wir das frei erhältliche Max-Objekt „flashserver“ von Olaf Matthes, welches zwischen Max/Msp und Flash per TCP/IP-Socket-Verbindung eine bidirektionale Kommunikation ermöglicht. Sämtliche Daten, die per „send“ an das flashserver-Objekt geschickt werden, verteilt dieses über die Socket-Verbindung an die jeweilige Flash-Datei. Das flashserver-Objekt überwacht, welche Flash-Dateien verbunden sind und vergibt ihnen eine ID nach der Reihenfolge. Da wir festgelegt haben, dass die Operator-Flash-Datei Client 1 und die USER-Flash-Datei Client 2 ist, kann die Kommunikation zwischen den Dateien in Verbindung mit unseren Max/Msp-Patches nur funktionieren, wenn zuerst die Operator-Flash-Datei und dann die USER-Flash-Datei verbunden wird. Damit ist es möglich mittels der Zahl hinter dem „send“ Daten nur an einen bestimmten Klienten zu schicken. Das Senden von Daten an Flash erfolgt über den Eingang des flashserver-Objektes. Um die Daten richtig verarbeiten zu können, führten wir Bezeichner (inputtype) ein, die den eigentlichen Daten vorangehen. Somit ist es möglich, auf Datenströme getrennt voneinander zuzugreifen und sie unterschiedlich zu behandeln. Das flashserver-Objekt wandelt den Bezeichner und die dazu gehörigen Daten in einen mit Leerzeichen separierten String um. Möchte man also eine x-Koordinate aus Flash an Max/Msp schicken, benutzt man den Bezeichner „x“ und ein Integer, z.B. 400. Bei Max/Msp kommt dann „x 0 400 0“ an, was vom unpack-Objekt in vier Datenteile gespalten wird. Mittels des Max-Objekts „strcmp2“ (String-Compare) kann man nun überprüfen, ob der erste Datenteil (inputtype) einem bestimmten Wort entspricht. Kommt beispielsweise ein „x“ an, erkennt strcmp2, dass es enthalten ist und sendet eine 1. Die darunter befindliche if-Abfrage lässt nur Daten durch, falls eine 1 gesendet wird. An der rechten Seite wird der Datenausgang des flashserver-Objektes angeschlossen, der den richtigen Wert schickt. Das Gleiche passiert auch mit der y-Koordinate. Beide Koordinaten werden zum Schluss gepackt, was verhindert, dass die Koordinaten einzeln weiterverarbeitet werden. Anschließend werden sie an den Client 2 (USER-Flash-Datei) weitergesendet. Diese Trennung ist nötig, da Max/Msp Integer und Strings nicht als ein Objekt behandeln kann. Würde man statt der 400 z.B. „test“ senden, würde Max/Msp eine Fehlermeldung ausgeben. Da wir aber sowohl Strings (für die Sound-Dateien) als auch Integer (Tracking, Erzeugung der Schneebälle, Position des zu löschenden Schneeballs) benötigen, war diese Trennung von vornherein notwendig. Die anderen Teile des Patches funktionieren auf ähnliche Art und Weise. Beim Sound wird ein Dateiname übergeben, der von Max/Msp dann geöffnet und abgespielt wird. Beim Status wird lediglich ein „start“ oder „ende“ an die Operator-Flash-Datei gesendet, um die beiden Clients zu synchronisieren. Im unteren Teil des Patches befindet sich die Verarbeitung der Daten, die an die USER-Flash-Datei gesendet werden. Dabei erhält das Flashserver-Patch die Tracking-Daten durch das Metro kontinuierlich vom tracking_coordinates-Patch und Rechnet die erhaltenen Daten auf die Auflösung der USER-Flash-Datei hoch. In der Mitte des Patches wird das Metro, dass die Tracking Daten kontinuierlich liefert, gestartet und die Auflösung der Kamera gewählt, um die Tracking-Daten richtig zu berechnen. Die Auflösung der Kamera wird an das tracking_coordinates-Patch gesendet.



Das tracking_coordinates Patch


tracking_coordinates Patch




Das Tracking_Coordinates-Patch berechnet aus den Daten, die es von dem tracking_findbounds-Patch erhält, die eigentlichen Tracking-Daten und visualisiert sie. tracking_findbounds liefert 8 Werte (Tracking Hand 1: x- und y-Koordinaten links oben, x- und y-Koordinaten rechts unten; Tracking Hand 2: x- und y-Koordinaten links oben, x- und y-Koordinaten rechts unten). Um nun eine eindeutige Tracking-Position zu erhalten, errechnet das Patch hier den jeweiligen Mittelpunkt.
Berechnung der x-Koordinate:

expr $i1 + (($i2 - $i1)/2)
xWert1+ (xWert2 xWert1) ̅/2

Berechnung der y-Koordinate:

expr $i3 - ($i1 + (($i2 - $i1)/2)
HöheKamera-( yWert1+ (x-Wert2 x-Wert1) ̅/2 )

Die errechneten Daten zeigt dieses Patch mit Hilfe der Slider an, damit man mit dem vom main-Patch übergebenen Video überprüfen kann, ob die Berechnungen stimmen und wie gut das Tracking funktioniert.



Das tracking_findbounds Patch


tracking_findbounds Patch




Im Tracking_Findbounds-Patch findet das eigentliche Tracking statt. Das Patch erhält vom tracking_coordinates-Patch das Video-Signal. Das jit.findbounds-Objekt erstellt um einen Bereich mit einer bestimmten Farbe (zuzüglich Toleranz) in diesem Video ein Quadrat und liefert die x/y-Koordinate der linken oberen Ecke sowie die x/y-Koordinaten der rechten unteren Ecke zurück. Die Toleranz lässt sich über den Minimal- und Maximalwert einstellen. Im grünen Bereich oben wird das Quadrat im Videosignal angezeigt, was zur Kontrolle dient. Da wir zwei Hände tracken, hat dieses Patch zweimal den gleichen Aufbau.



Umsetzung in Flash


siehe PDF Version

Sound


Der Gaming-Bereich wird mit einem Soundtrack beschallt, sowie zusätzlichen Vocals, welche manuell vom Operator eingespielt werden können. Während der Performance wird zusätzlich ein Soundtrack im Public-Bereich abgespielt, der sich von dem im Gaming-Bereich unterscheidet. Für die Aufnahmen der Vocals konnten zwei Moderatoren (Alexander Kurz und Florian Maier) von Radio Fips (www.radiofips.de), einem freien Radio mit Sitz in Göppingen gewonnen werden. Die Aufnahmen entstanden in den Feiertagen zwischen Heiligabend und Neujahr 2009 in dem Sendestudio von Fips in Göppingen. Anschließend wurden die Aufnahmen und Soundtracks in Apples SoundtrackPro abgemischt.



Test im Media Lab


Tag 1
Donnerstag, 05.02.09, 10:00 Uhr – 17:00 Uhr

Am ersten Testtag stellten wir zunächst während unserer Tests am Greenscreen fest, dass die gewählte Kamera (Fire-I Firewire Kamera) für unsere Zwecke nicht ausreicht. Die Kamera überstrahlte im kompletten Bildbereich, bei hellem Licht und wies bei dunklen Lichtverhältnissen sehr starkes Bildrauschen auf. Eine brauchbare Ausleuchtung war bei diesen Verhältnissen also nicht möglich. Als Alternative benutzen wir eine Sony Firewire MiniDV Handycam. Diese bot uns ein verbessertes Bild. Jedoch war der Nachteil bei dieser Consumer Cam, dass der Autofokus nicht manuell abschaltbar war. Dies hatte zur Folge, dass es in der Berechnung des Max Patches zu Pixelfehlern bei schnellen Bewegungen des USER kam.

Mit der neuen Kamera testeten wir erneut das Chromakeying am Greenscreen und mussten diesmal erkennen, dass selbst bei guten Lichtverhältnissen und einem relativ gutem Kamerabild, das Chromakeying in Max nicht richtig funktionierte. Also entschlossen wir uns dazu eine alternative Methode zu versuchen, indem wir die Berechnung über die Differenzbildmethode laufen ließen, um an die Alphamaske zu kommen. Diese Methode erwies sich als deutlich schneller und effizienter.
Als weiteres Problem stellten wir an diesem Tage fest, dass der „Ichbinleise“-Rechner nicht über eine installierte Version des Programmes Adobe Flash verfügte, so dass wir unsere Flashapplikation trotz installiertem Flashplayer nicht starten konnten, bzw. nicht zum Flashserver connecten konnten.



Tag 2
Freitag, 06.02.09, 10:00 – 14:00 Uhr

Für den zweiten Testtag liehen wir uns die Sony HVR Z1E HDV aus, um die Problematiken mit dem Autofokus zu lösen. Nach diversen Versuchen gelang es uns schließlich die Kamera zu installieren und das gelieferte Bild, war weitaus brauchbarer als das der Consumer Cam vom Vortag.
Anschließend testeten wir verschiedene Lichteinstellungen unter Verwendung des im Lab vorhandenen Greenscreens sowie einer eigenen Lösung aus Stellwänden in Verbindung mit einem grünen Tuch. Dabei stellte sich heraus, dass sich die Schattenbildung aus einer frontaleren Position besser zur Berechnung des Differenzbildes eignete. Auf Grund dieses Umstandes entschieden wir uns für eine Lösung mit Hilfe von Stellwänden. Letzte Problematiken bei der Lichtsetzung konnten an diesem Tag, ohne den finalen Aufbau, leider nicht gelöst werden.
Da noch immer kein Flash auf dem „Ichbinleise“ Rechner installiert war, konnten wir die Installation in ihrer Ganzheit nicht testen. Jedoch gelang es uns mit einer Installation der „Matrox Triple Head to go“ - Software auf einem Laptop erste Erfahrungen mit den Rückprojektionsbeamern in Verbindung mit Flash zu machen.
Alle bis dato umgesetzten Max Patches funktionierten an diesem Tag ganz gut. Im Anschluss an den Test im Lab entdeckten wir noch das Tool Lucid, mit welchem es uns möglich war, die Flash Applikation transparent werden zu lassen, um sie über die Videomatrix des Max Patch zu legen.



Tag 3
Sonntag, 08.02.09, 12:00 – 22:00 Uhr

Am Sonntag wurden die Max Patches für den Operator und den Public Bereich erstellt. Hierbei stellten wir uns der Herausforderung, Videosignale aus Max heraus über Netzwerk live zu übertragen. Dabei wurde uns bewusst, dass sich bisher niemand Gedanken über die Datenlast gemacht hatte, die dieses Vorhaben in sich trug. Um ein Video mit 640 x 480 Pixeln, bei 25fps und vier Videoplanes zu übertragen, reichte ein Netzwerk mit 100 MBit leider nicht aus. Auf Grund dessen erwiesen sich zwei unserer eigenen Laptops, für die Installation als unbrauchbar und wir benötigten dringend einen Switch sowie drei Rechner die GBit fähig waren. Mithilfe eines Crossoverkabels gelang es uns schließlich eine GBit Verbindung zwischen einem Desktop PC (Game), einem Laptop (Operator) und einem Apple Mac Book mit Windows Emulation (Public) aufzubauen und die Patches für den Operator sowie Public Bereich parallel laufen zu lassen, so konnte zumindest eine simulierte Testumgebung bei gleichzeitig moderater Netzauslastung geschaffen werden.\\ Desweiteren testeten wir das Trackingsystem und nahmen einige Anpassungen vor, z.B. Austausch der Farbe blau gegen gelb. Außerdem mussten wir die Flashanwendungen des Operators und des Games sowie einen der zentralen Max Patches verändern, um eine Synchronisation über Netzwerk, zwischen den Anwendungen, zu erreichen. Anschließend mussten wir noch, aus den Erfahrungen vom Vortag, die Auflösung des Flashgames im Hinblick auf Rückprojektionsbeamer optimierten.



Tag 4
Montag, 09.02.09, 14:00 – 22:00 Uhr

An diesem Tag liehen wir uns die benötigte Hardware, wie z.B. den Gigabit Switch und konnten zum ersten Mal im privaten Bereich einen Testdurchlauf mit der Lastverteilung auf drei Rechner starten, welcher sehr vielversprechend verlief. Im Anschluss daran machten wir uns an die Implementierung der Sounddateien. Hierfür waren Änderungen in der Flashanwendungen des Operators sowie die Erstellung einer Soundschaltung für den Public-Bereich nötig geworden. Es folgte ein erneuter Test der gesamten Installation.\\ Abschließend mussten wir das Tracking auf das Format des DV-Signals justieren und die Änderungen in Bezug auf die neue Auflösung des Flashgames berechnen und einstellen. Auch waren kleinere Änderungen an der Berechnung der Schneeball Koordinaten notwendig geworden.



Tag 5
Dienstag, 10.02.09, 14:00 – 18:00 Uhr

Dieser Tag begann mit der heiß ersehnten Installation von Flash CS3 auf dem „Ichbinleise“-Rechner, parallel dazu bauten wir mit Hilfe von Stellwänden, Tischen, einem grünen Tuch und diversen Materialien unseren Greenscreen in der Mitte des Raumes auf. Nachdem es wieder zu Komplikationen mit der Sony HVR Z1E HDV gekommen war, konnten wir unter Verwendung eines zweiten Gerätes, mit der Lichtsetzung beginnen. Nach ersten Testläufen bemerkten wir einen Fehler in der Soundsteuerung, welcher sich allerdings recht schnell beheben ließ. Am Ende des Testtages und mehrere Licht- und Kameraeinstellungen sowie Änderungen an den Materialien für das Tracking, waren die Ergebnisse für uns leider nur befriedigend.



Beurteilung



Stärken

  • Große Anziehungskraft sowohl beim Operator als auch beim Game
  • Erfolgreiches zur Schau stellen des Users im Public Bereich, bei den Beobachtern wird Neugierde geweckt
  • Großer Spielspaß im Gaming Bereich
  • Die erfolgreiche Umsetzung des Raumkonzeptes unter Berücksichtigung der Synchronität der einzelnen Anwendungen.



Schwächen


  • Unausgereiftes Spielsystem: Es fehlt ein direktes Feedback
  • Trackingsystem: Das Trackingverfahren ist stark lichtabhängig und erlitt Präzisionsfehler auf Grund der Lichtverhältnisse.



Reaktionen


Wie bereits beschrieben konnten wir unser Projekt nicht am Tag der Medien präsentieren. Daher war es schwer die Reaktionen unbefangener Personen einzusammeln, da die Testteilnehmer größtenteils aus der Veranstaltung kamen und mit dem Konzept und der Technik schon vertraut waren. Es mangelte uns also an einem repräsentativen Publikum, um eine Auswertung der Reaktionen vornehmen zu können. Folgerungen und Schlüsse können wir nur vermuten.


Soweit wir feststellen konnten


  • Der Operator-Bereich besaß die meiste Anziehungskraft, selbst Personen die mit der Konzeption der Installation vertraut waren, zeigten eine große Motivation den Spieler zu beeinflussen und ihm so das Spiel besonders schwer zu machen.
  • Nach der Auflösung der Installation bestand bei den wenigsten Leuten der Wunsch einmal selber als User zu agieren.
  • Die Quelle des Public Videos war den meisten Leuten ein Rätsel, es machte sie neugierig und sie wunderten sich, was die Person auf dem Bildschirm wohl macht. Je bekannter ihnen die Person war, desto mehr Anziehungskraft hatte der Public Bereich.



Verbesserungen


  • Im Spielsystem sollen Effekte eingebaut werden, die dem Spieler mitteilen, dass er einen Schneeball getroffen hat, um ihm somit gleich auditiv oder visuell ein Feedback zu geben und dadurch ein Erfolgserlebnis beim Spieler zu erzielen.
  • Ob das zusätzliche Einfügen von Soundeffekten dem Spiel gut getan hätten, konnten wir nicht bestätigen, da ein beispielsweise ständiges „Zerplatschen“ der Schneebälle auf Dauer sicher nervig geworden wäre, jedoch könnte man in dieser Richtung weitere Überlegungen anstellen.
  • Hinzufügen eines Soundsystems für den Operator um zusätzlich zum Visuellen ebenfalls auditives Feedback zu bekommen.
  • Bei Gebrauch des Infrarot Trackingsystems wären die „Handschuhe“ nicht von Nöten und daher im Public Bereich nicht zu sehen.



Erweiterungen


Public:

  • Computergenerierter Hintergrund:
Lösung: Dies ist ein zeitaufwendiges Unterfangen


  • Falls keine Performance stattfindet sollen archivierte Videos abgespielt werden.
Lösung: Aus Max heraus Video-Dateien mit jit.record aufnehmen und in einem Ordner mit ID speichern; über eine Schaltung müssten dann die Files geladen werden (ID generieren lassen und an das "read" übergeben)

Operator:

  • Spiegeln
Lösung: Umrechnung der Koordinaten und Matrixoperation an der Silhouette.


  • Verlangsamen
Lösung: Begrenzung der Geschwindigkeit (Metro), in der das Max Patch die Trackingkoordinaten an das Flashfile sendet und die Anpassung der Silhouette.


  • Skalieren
Lösung: Umrechnung der Koordinaten.


  • Sound
Lösung: Lokales Abspielen der Soundfiles bei Klick auf den Button.

Gaming Area

  • Silhouette
Lösung: Finetuning; Zeitlicher Aufwand die Silhouette an die Trackingdaten anzupassen


  • Namen selbst eingeben
Lösung: Das Konzept "selber eingeben" des Namens ließen wir fallen, da es zu viel Zeit in Anspruch nehmen würde seinen eigenen Namen per Tracking einzugeben, wir entschieden uns für eine handelsübliche Tastatur. Die Möglichkeit per Tracking den Namen einzugeben würde dieses Problem allerdings lösen.



Fazit


Die Installation Snow Control konnte leider auf Grund zeitlicher Beschränkungen der Testphasen und technischer Komplexität nicht zu 100% fertig gestellt werden, daher kann bei der Bewertung leider kein umfassendes Urteil abgegeben werden. Jedoch konnten die wesentlichen Komponenten fertiggestellt und präsentiert werden. Das Ergebnis dieses Entwicklungsstandes war von unserer Seite jedoch höchst zufriedenstellend, da die elementaren Grundfunktionen, wie zum Beispiel das Abspielen der Sounddateien und das Steuern der Schneebälle von Seiten des Operators, einwandfrei funktionierten. Auch die grafischen Oberflächen der Flashanwendungen konnten überzeugen. Jedoch wurden einige Bereiche der Installation Opfer der mangelnden Zeit. So war es uns beispielsweise nicht mehr vergönnt die Möglichkeiten des Operators um die Funktionen Spiegeln, Skalieren und Verlangsamen zu erweitern, was technisch gesehen keine große Anforderung mehr dargestellt hätte sondern lediglich eine gewisse Testdauer für die Feinabstimmung benötigt hätte. Ebenso wurden sekundäre Ziele, wie ein computergrafisch gerenderter Bühnenhintergrund fallengelassen. Da wir die Wirkung des Public Bereiches jedoch auf Grund der mangelnden Besucher nicht ganz genau interpretieren können, lässt sich jedoch sagen, dass dieses Ziel sehr niedrige Priorität hatte und der gewünschte Effekt auch mit Hilfe des „Dummy Hintergrundbild“ erzielt wurde. Das Trackingsystem stellte ebenfalls eine enorme Hürde dar, welche wir jedoch von unserer Seite aus unter den Umständen der mangelnden Zeit und der uns zur Verfügung stehenden Möglichkeiten recht gut gelöst haben. Da es leider keine Referenzen für das eingerichtete Infrarot Trackingsystem im Media Lab in Verbindung mit MAX/MSP gibt, hätte eine dortige Einarbeitung den zeitlichen Rahmen für die Dauer der Entwicklung unserer Installation deutlich gesprengt. Dies wäre jedoch eine Aufgabe für die Weiterentwicklung dieser Installation. Für den Fall des Gebrauchs dieser Technik würde sich die Problematiken der Ausleuchtung auch nur auf den Green Screen beschränken um ein sauberes Differenzbild zu erzeugen.