Show Interactive

Aus toolbox_interaktion
Wechseln zu: Navigation, Suche
Projekt Plakat (WS16/17)
Projekt Plakat (SoSe17)

Unser Ziel ist es, die Lerninhalte des Studiengangs Media Engineering einzusetzen, um den Zuschauer durch ein interaktives Erlebnis nachhaltig zu beeindrucken. In unserer Anwendung „Show Interactive“ funktionieren Personen als Module im virtuellen Raum der aus musikalischen und visuellen Elementen besteht. Visualisierung und Musik werden durch die anwesenden Personen im Raum gesteuert.

Inhaltsverzeichnis

Ideenfindung

Produktfunktionen

Use Case Diagramm mit den Produktfunktionen

Beschreibung zu Use Case 1: Im Raum bewegen Bei Show Interactive geht es darum etwas zu erleben. Unser Erlebnis wird durch die Bewegung des Nutzers im Raum beeinflusst. Daher ist es wichtig, dass der Nutzer sich im Raum bewegen kann aber auch dazu angespornt wird das zu tun.

Beschreibung zu Use Case 2: Musik hören/verändern Dem Nutzer soll es möglich sein die Musik welche er hört, selbst zu beeinflussen. Das geschieht über seine Bewegungen beziehungsweise über seine Position im Raum. So ist es dem Nutzer möglich direkten Einfluss auf sein Erlebnis in diesem Raum zu nehmen.

Beschreibung zu Use Case 3: Visualisierung erleben/verändern Die Bewegungen des Nutzers werden durch die Visualisierung wiedergespiegelt. Somit erhält der Nutzer direktes Feedback über seine Position im Raum, was dazu führt, dass ausprobiert wird wie sich die Visualisierung mit ihm bewegt. Das Projekt „Show Interactive“ war in seiner Vorstellung zunächst ein sehr freies Projekt. Die Ziele dahinter waren ein Projekt zu entwickeln, das eine Interaktion zwischen Mensch und Maschine beinhaltet. Dabei stand im Vordergrund etwas zu schaffen, das von mehr als einer Person gleichzeitig genutzt werden kann und den Besucher der „Show Interactive“ beeindruckt.

Zunächst war vorgesehen, dass dies innerhalb von zwei Teams mit unterschiedlichen Ideen umgesetzt wird. Nachdem sich allerdings recht bald herauskristallisierte, dass unsere Ideen recht überschneidend zu einem „interaktiven Raum“ tendierten, wurde das Projekt doch zu einem großen Einzelprojekt zusammengefasst.

Aus allen Ideen wurden zunächst zwei Räume entwickelt, die miteinander in Beziehung stehen: Ein visueller „Aktivraum“, in dem der Besucher aktiv teilnimmt und dagegen ein akustischer „Erlebnisraum“. Die Details sollten sich aus der Umsetzung der Idee entwickeln. Die Ideen der beiden Entwürfe und im Projekt-Team fügen sich zu einem gemeinsamen Raum zusammen. Visuelle Konzeption und Audio-Effekte sollen sich hier gegenseitig unterstützen. Der Input soll durch die Personen im Raum selbst entstehen: Ihre Bewegungen, ihre Position. Der alte Aspekt „Battle Interactive“, nach dem zwei interaktive Räume gegeneinander antreten, hat sich umgekehrt in drei Teams, die sich gegenseitig aufbauen.

Aus dieser Idee entwickelte sich ein Weltraum Design, das neue Funktionen mit sich bringen sollte. Das Tracking der Personen sollte optimiert werden. Grafiken und Bewegungsmuster sollten überarbeitet werden. Die Umsetzung der Bodenvisualisierung sollte in Betracht gezogen werden und das Trackingfeld sollte fortan genauer abgegrenzt werden und Platz für mehrere Personen bieten.

Ein mögliches Nutzerszenario lautete nach der Ideenfindung und dem gemeinsamen Konzeptausbau wie folgt: Der User befindet sich in der Trackingfläche unserer Systems und blickt auf eine Projektionsfläche. Er blickt auf einen Kometen, auf dem er als Avatar dargestellt wird. Auch ein zweiter Nutzer kann mit angezeigt werden. Bewegt sich ein Spieler, bewegt sich der Avatar. Ein dritter Spieler kann an einem Pult, in dem ein Tablet eingebunden ist, Objekte auf die Projektionsfläche legen. Das Tablet spiegelt zweidimensional die Visualisierung wieder. Somit wird ein solches Objekt sowohl auf dem Tablet als auch auf dem Kometen dargestellt. Das Pult dient also als Steuerzentrale. Läuft ein Spieler im Trackingfeld auf ein solches Objekt zu und kollidiert gegebenenfalls damit, wird ein Sound ausgelöst und das Objekt verschwindet. Seine Bewegungen kann er also immer auf der Leinwand beobachten. Durch eine Begrenzung des Trackingfelds mit LED-Stripes, konnte hier eine weitere Funktion eingebaut werden. Wird ein neues Objekt gelegt oder zerstört, blinken diese auf. Zudem folgen die LED’s den Personen, die sich im Trackingfeld befinden.


Produktdaten

Die Produktdaten unseres Systems:

Produktdaten


Gruppeneinteilung

Es wurde beschlossen mehrere Untergruppierungen vor zu nehmen und das Team darauf aufzuteilen. Allerdings sollte niemand bis zum Ende des Projekts zwingend an seine Untergruppe gebunden sein, sondern hätte jederzeit die Möglichkeit in eine andere zu wechseln falls dort gerade eine helfende Hand gebraucht werden würde.

Die Gruppe Visualisierung, zu dem zu Beginn Yvonne Sieber, Dominik Schweiger, Alexander Liebler, Kristin Feldmann und Nina Körner gehören, bildete sich. Ebenfalls kamen zur Untergruppe Tracking Alexander Woernlein und Oliver Schmitt und zur Untergruppe Audio gehörten nun Christian Weichert und Arthur Hilbert. Das Projektmanagement wurde zunächst von Christian Weichert übernommen. Zudem wurde in jeder dieser Gruppen ein Gruppenleiter bestimmt. Dies waren für Visualisierung Alexander Liebler und für Audio Arthur Hilbert. Der Leiter für das Gesamte Team war nach einer Wahl Christian Weichert.

Ab diesem Zeitpunkt sollte sich die Gruppe in ihren Unterkategorien treffen und das Gesamtteam an einem gemeinsamen Termin den aktuellen Stand und die Entwicklung in den Einzelgruppen austauschen. Das Projektmanagement Team sollte dabei den Überblick behalten, ob alles nach Projektplan läuft, ob Fristen eingehalten werden und ob regelmäßig Protokolle angefertigt werden. Sobald die Einzelteams etwas vorzuweisen hatten, wurden wieder gemeinsame Treffen veranschlagt um die Einzelelemente des Projekts zusammenzuführen.

Durch die Erweiterung unseres interaktiven Systems und weiteren Verbesserungen musste die Projektstruktur im weiteren angepasst werden. Bisher Bestand unser Team aus den Bereichen Projektmanagement, Tracking, Audio und Visualisierung. Somit erschien es logisch für die Entwicklung einer Applikation für Android einen weiteren Bereich einzuführen. Der Bereich App ist entstanden und war für die Initialisierung des Tablets sowie die Entwicklung zuständig. Zudem ist der Teilbereich Aufbau entstanden, welcher sich mit der Lichtsteuerung, den LEDs, der Halterung für das Tablet und somit mit der Ausgestaltung des physischen Raumes beschäftige.

Produktcharakteristiken

Systemumgebung

Unsere Anwendung läuft vollkommen in einer Windows Umgebung, festgelegt durch die Nutzung einer Ethernet Kamera.

Hardware-Umgebung

Die Hardware Verwendung wird maßgeblich durch die Tracking-Geräte bestimmt. Unter Verwendung einer Ethernet Kamera mit Infrarotfilter werden die Spieler von oben getrackt. Der Filter lässt nur ein für uns unsichtbares Infrarotfarbspektrum in das Kamerabild und sperrt damit visuelle Störungen aus. Durch einen Infrarotstrahler können wir genau bestimmen, welchen Bereich wir wahrnehmen möchten. Die Ethernet Kamera bietet den Vorteil, dass sie über den IDS Treiber viele Einstellungsmöglichkeiten bietet, so wird eine gute Belichtung am Rechner für die weitere Verarbeitung der Daten erstellt. Außerdem ermöglicht diese eine Verbindung über das Netzwerk. Unsere ganze Kommunikation verläuft über Ethernet, somit wird der Visualisierungslaptop lokal über einen Router mit integriertem Switch verbunden. Die Audioanwendung wird mittels Wireless LAN, und der Beamer für die Projektion der Visualisierung wird ebenfalls mittels HDMI zu Ethernet verbunden.

Softwareumgebung

Für die Zusammenarbeit der Hard- und Software verwendeten wir verschiedene Systeme. Für die Programmierung des Trackings und der Visualisierung kam Open Frameworks, eingebunden in der Entwicklungsumgebung des Qt Creator, zum Einsatz.

Open Frameworks ist auf ein C++ ausgelegtes Open-Source-Toolkit, welches auf einer Vielzahl von Betriebssystemen lauffähig ist und uns die Möglichkeit der kreativen und freien Gestaltung bot. Eingebunden ist diese in Qt Creator, die für die Entwicklung von plattformunabhängigen C++ Programmen mit der Qt-Bibliothek gedacht. Die von der ISO genormte Programmiersprache C++ ermöglicht sowohl die effiziente und maschinennahe Programmierung als auch eine Programmierung auf hohem Abstraktionsniveau. Der Standard definiert auch eine Standardbibliothek, zu der verschiedene Implementierungen existieren. Es wird sowohl in der Systemprogrammierung als auch in der Anwendungsprogrammierung eingesetzt. Eine der Stärken von C++ ist die Kombinierbarkeit von effizienter, maschinennaher Programmierung mit mächtigen Sprachmitteln, die einfache bis komplexe Implementierungsdetails zusammenfassen und weitgehend hinter abstrakten Befehlsfolgen verbergen. Die Plattform Open Frameworks bietet viele hilfreiche Bibliotheken und Add-Ons. Im Trackingprogramm wird das Kamerabild bei einer Bildfrequenz von 25 Frames pro Sekunde bereitgestellt. Das Kamerabild wird in einzelnen Bild-Frames verarbeitet. Dazu wird unter anderem ein Bild-Objekt für die leere Tanzfläche zugewiesen, eines für das aktuelle Kamerabild und eines für die Differenz aus diesen beiden Bildern. Eine weitere Klasse wertet das Differenzbild aus, was die Umrisse von weißen Flächen erfasst und deren Größe, Umfang und Formfaktor und die Position im Bild zur Verfügung stellt. Diese weißen Flächen, identische Bildpunkte werden dabei ignoriert, dargestellt in einem schwarzen Frame, nennen wir Blobs. Diese Blobs, welche die die getrackten Personen darstellen, löschen sich, wenn diese nicht mehr eindeutig zu identifizieren oder aus dem Bild verschwunden sind. Diese gewonnen Daten werden anschließend zu oscFloat-Werten verarbeitet. Die Werte liegen zwischen 0 und 1. Für jeden, der bis zu zwei möglichen Besucher, sind 2 Werte definiert: Die x- und y- Position im Raum. Diese Werte werden dann mittels Ethernet an die verschiedenen Ansprechsoftwares geschickt. Dieses entscheidende C++ Toolkit bot uns das OSC Add-On, welches die einfache Kombination des Programms mit der Schnittstelle möglich machte, um unsere Daten an die Gruppe Visualisierung oder Audio zu senden. Unsere Datenübermittlung wurde in diesem Semester nun zentral gebündelt. Da sich das Team Tracking um die Entwicklung der CoreLogic kümmerte, konnten wir am Ende alle Daten über die CoreLogic laufen lassen. Diese kümmerte sich jedoch nicht nur um den Datenaustausch, sondern auch um die Kollisionsabfrage, welche überprüfte, ob entweder ein Benutzer mit Objekten oder ein Benutzer mit einem Benutzer kollidierte.


Datenübermittlung


Reaktor 6 ist eine Entwicklungsumgebung zur Programmierung von virtuellen Instrumenten die in einer DAW verwendet werden können. Die Programmierung erfolgt über grafische Elemente welche einfach miteinander verknüpft werden. Ein virtuelles Instrument oder unser Audio-Patch, welcher für mehr als nur eine einfache Audioerzeugung zuständig ist, besteht aus einer Struktur von sogenannten Core- und Primary-Cells. Core-Strukturen erlauben es Daten auf Bit-Ebene zu bearbeiten. Zusammengefasst in Makros ergeben diese Core-Strukturen Primary-Cells. Diese können untereinander oder zum Beispiel mit dem Output der Soundkarte verknüpft werden. Bei Audio war es zudem die zentrale Aufgabe, die Steuerung der Synthesizer umzusetzen. Diese sollten der Theorie nachspielen, sobald ein Kollisionsevent eines Nutzers mit einem Objekt stattgefunden hatte. Die Erkenntnisse zur Korrelation von OSC und MIDI innerhalb von Reaktor wurden in einem Dokument zusammengefasst, nach dem sich das Tracking Team beim Beschreiben der OSC-Werte richtet. Da das MIDI-Protokoll 4 Bit für die Kodierung einer Kanalinformation vorsieht, wurde entschieden den Kanal mit der ObjektID gleichzusetzen um darüber die direkte und eindeutige Kommunikation zwischen Objekten und ihrem vorgesehenen Instrument sicherzustellen. Jedes Objekt unserer Interaktion hat einen eigenen MIDI-Channel, zu dem es sendet. Das entsprechende Instrument in Reaktor hört nur auf Signale aus diesem MIDI-Channel. Die Konversion findet in Reaktor statt.

Zur Umsetzung der Tablet App wurde das Framework Ionic verwendet. Dieses ermöglicht es Webanwendungen als Native Applikationen für Android und iOS zu entwickeln. Code wird in Typescript geschrieben. Somit ist unsere App eine Webapplokation die in einem Cordova -Container als Webview laufen lässt und dabei Zugriff auf native Systemkomponenten erhält. So wurde mit Hilfe eines Plug-Ins für Cordova, die UDP Funktionalität des verwendeten Android Tablets angesprochen und genutzt. Dadurch ist es möglich, unsere Daten wie im restlichen System, über OSC zu versenden und zu empfangen.

Die Visualisierung erhält von Tracking und Tablet die Daten Objekt-ID, Nutzer-ID, Position x,y sowie Kollision von Avatar und Objekten. Aus diesen Daten werden die Position der Avatare auf der Trackingfläche und somit der Visualisierung generiert. Die Objekt- und Nutzer-ID dienen dazu die Nutzer, sowie die einzelnen verfügbaren Objekte, unterscheiden zu können. Bei einer Kollision von Avatar und Objekt wird ein Sound erzeugt und das Objekt mit dem Kollidiert wurde, verschwindet. Die verschiedenen Avatare und Objekte wurden mittels Blender in 3D erstellt und in das Programm über Open Frameworks eingefügt.

Nicht-funktionale Anforderungen

Nicht-funktionale Anforderungen Klangqualität
Nicht-funktionale Anforderungen Modularität
Nicht-funktionale Anforderungen Design
Nicht-funktionale Anforderungen Latenz

Verwendete Soft- und Hardware

Protokolle und Schnittstellen

Der Projektbereich Tracking erfasst die Besucher-Daten und steht damit an einer frühen Stelle der logischen Reihenfolge. Für den Prototyp der Show Interactive wurde festgelegt, dass von den erfassbaren Besucher-Daten zunächst nur die Position von bis zu 4 Personen auf der getrackten Ebene erfasst und verarbeitet werden sollen. Es gilt also 4 Personen zu erfassen und deren Position als normalisierte X- und Y-Werte (von 0,0 bis 1,0) zur Verfügung zu stellen. Im Ausblick auf den weiteren Projektverlauf könnten auch zusätzliche Daten verarbeitet werden Es bietet sich an, die Dynamik der Bewegungen oder die Blickrichtung oder Orientierung der Personen , zu erfassen und zu verarbeiten.

Diese Daten werden pro Frame an das Audio-System und an die Visualisierung über Ethernet (bzw. WLAN) gesendet. Hierzu standen 2 Standards zur Auswahl: Open Sound Control und Midi.


MIDI

(2000) MIDI ist die Abkürzung von Musical Instruments Digital Interface. Der 1982 veröffentlichte MIDI-Standard beschreibt eine Methode zur digitalen Übertragung von Musikdaten über eine serielle Schnittstelle. MIDI-Daten enthalten ähnlich einer Partitur, daher kann der musikalische Eindruck wiedergegebener MIDI-Dateien je nach verwendeter Hardware variieren [1]. Die Geschwindigkeit der MIDI-Schnittstelle ist vom technischen Standpunkt überholt. Da für das Auslösen eines Tons bis zu 3 Bytes übertragen werden müssen, was 0,960 ms in Anspruch nimmt, kommt es bei mehreren Events, die eigentlich gleichzeitig gesendet werden sollen, zu Verzögerungen [2].

Aufgrund der Tatsache, dass MIDI sehr langsam ist, wurde es für die Signalübertragung als uninteressant erachtet. Lediglich in der Audioverarbeitung unseres Prototypen findet sich MIDI wieder, allerdings in der Erzeugung von Audiosignalen und nicht der Übertragung.


OSC

Open Sound Control (OSC) ist ein nachrichtenbasiertes Netzwerkprotokoll, das hauptsächlich für die Echtzeitverarbeitung von Sound über Netze und Multimedia-Installationen verwendet wird [3]. OSC ist ein Kommunikationsprotokoll, das unabhängig von spezifischen Transportmechanismen ist. Das bedeutet, OSC-Pakete werden in der Regel als UDP-Sockets gesendet und empfangen. OSC verwendet eine offene, dynamische, URL-Style Symbolik.

Für die Übertragung von normalisierten X- und Y-Werten bietet sich das Gleitkomma-Format „float32“ an. Weitere Optionen wären ASCII-Zeichen „als OSCString“ oder auch binäre Daten (OSCBlob).

Die Address-Pattern Struktur ermöglicht mehreren Empfängern gleichzeitig einer Nachricht zu empfangen und auszuwerten. Das Protokoll benutzt Hochauflösende time tags (Zeitmarken). Eine OSC-Message hat folgende allgemeine Form: <address pattern> <type tag string>

Das address pattern ist ein String beginnend mit "/" gefolgt von einer Nachricht, die entweder ihre Herkunft oder ihr Ziel beschreibt. Im weiteren Projektverlauf hat sich das Team Tracking weiter mit dem Thema OSC beschäftigt und diese Art der Signalübertragung als geeignet befunden.


Weitere Vorteile von OSC:

- Schnellere Transportgeschwindigkeit von Daten (nicht nur Musikdaten)

- Höhere Auflösung von 32Bit (im Vergleich zu MIDI)

- OSC kann über ein Netzwerk versendet werden

- Keine weitere Verkabelung nötig

- Steuerung von Hardware


Wegen seiner vielfältigen Einsatzmöglichkeiten entschieden wir uns für OSC. Gleichzeitig wurde mit dem Team Audio nach Software-Lösungen gesucht, die übermittelten Werte in Sound umwandeln.

Tracking-Daten-Konvention: Die Positionen der Personen im Raum vom Tracking-Rechner soll an die beiden darstellenden Systeme per OSC gesendet werden. Adresse ist jeweils die IP-Adresse der Rechner. Die OSC-Werte sollen auf Port 9001 der Zielrechner geschickt werden. Die Werte werden benannt mit den Strings /OSCX0, /OSCY0 ... bis /OSCY3.

Hardware

Bezüglich der Hardware konzentrierte sich das Tracking Team zunächst auf die Kamera, da diese ja das Herzstücks des Projekts darstellt. Über die Kamera werden alle Werte empfangen und weitergeleitet. Das finden einer geeigneten Kamera stand an erster Stelle so begannen wir mit einigen Kameratests, die wir bereits auf der Projektfahrt begannen durchzuführen. Folgende Kameras wurden von uns getestet: Microsoft Kinect, Flir Wärmebild-Kamera, Kamera mit Infrarot Filter, Ethernet Kamera mit Infrarotfilter.

Hier nun eine genauere Beschreibung der Durchführung der Test so wie der einzelnen Kameras:

Microsoft Kinect

Microsoft Kinect

Die Microsoft Kinect ist eine für die Videospielkonsole Xbox 360 entwickelte Kamera mit einem Tiefensensor zur Tiefenwahrnehmung im Raum. Sie liefert ein RGB- Farbbild und ist dafür gedacht, dass Spieler an der Xbox 360 mit ihren Körperbewegungen das Spiel beeinflussen können. Die Kamera sendet ein Infrarotnetz in den Raum und nimmt die Reflektion derselben auf. Befindet sich in diesem Raum eine Person, so setzt sie 35 Bildpunkte auf diese und errechnet daraus eine „Knochenstruktur“ dieser Person im Raum.

Test Aufbau mit der Kinect

Für die Kinect gibt es inzwischen freie Software die es möglich macht die Kamera an einem PC statt an einer Spielekonsole zu nutzen und die Daten für den gewünschten Effekt auszuwerten. In unserem Fall wollten wir eine Fläche mit bis zu vier Personen aufnehmen und Werte für jede einzelne Person erhalten. Die Personen sollten jedoch genug Raum haben um sich zu bewegen, so veranschlagten wir eine erste Raumgröße, die in etwa 4 x 5 Meter umfassen sollte. Wir bauten die Kamera auf einem Fliesenboden auf. Unsere Ersten „Personen“ die uns als Testobjekte dienten waren große Schachfiguren, die wir gegenüber von der Kamera positionierten. Angeschlossen war die Kamera zu diesem Zeitpunkt an einem Mac und lieferte uns mit der passenden Software, die dank eines OpenFrameworks Addons zur Verfügung gestellt wurde, die ersten Werte. Es war weiterhin auch kein Problem die Kamera mit einem Windows oder Linux PC zu verbinden.

Unsere erste Aufnahme war unter Bedingung, dass die Kamera in etwa zwei Meter von den Figuren entfernt steht. Das Erste Bild zeigt also die Ausgabe am Mac bevor noch weitere Einstellungen vorgenommen wurden. In unserer zweiten Abbildung hatten wir dann bereits die Near-Far-Planes eingerichtet. Bei einem dritten Versuch setzten wir die Objekte etwa einen Meter vor die Kamera. Uns viel sofort auf, dass der Bereich den die Kamera aufnehmen konnte sehr klein war. Wir versuchten also die Kamera in verschiedenen Positionen und Abständen einzustellen. Von Oben blieb das Problem, dass der Bereich sehr klein war, eine Person hätte sich nur in einem Bereich von 1,5 x 1,8 Metern bewegen können. Dies lag natürlich weit unter dem von uns angedachten Bereich von 4 x 5 Metern. Auch aus andern Perspektiven wie von schräg oben, oder von Unten erzielten wir keine besseren Ergebnisse. Außerdem stellten wir fest, dass es für unsere Form des Trackings keine Notwendigkeit war die Tiefe wahr zu nehmen, so halfen uns die Versuchsaufbauten mit der Kinect dahingehend weiter, dass wir uns auf ein zweidimensionales Tracken der Personen einigten. Aufgrund des kleinen Bildes jedoch fiel die Kinect aus den Optionen der Möglichen Kameras heraus, da sie nicht für unser Projekt geeignet war.

Test bei zwei Meter Abstand
Einrichtung der Near-Far-Plane
Ein Meter Abstand von der Kamera zum Objekt


Flir Wärmebild-Kamera

Die Flir Wärmebildkamera ist eine Kamera, die Infrarotstrahlen aufnimmt und aus diesen den Informationsbereich der Temperaturen herausfiltert. Dieses stellt sie in einem farbigen Bild basierend auf einer Farbscala dar. Personen unterscheiden sich so deutlich von ihrer Umgebungstemperatur, die meist unter der Körpertemperatur eines Menschen liegt.

Sie wurde über USB mit dem PC verbunden, allerdings gab es für diese keinen passenden Treiber für den MAC, für einen Windows PC allerdings ohne Probleme. Einen Nachteil den die Verbindung mit dem PC über USB lieferte war eine starke Latenz zwischen der Aufnahme des Bildes und dem Bild wie es in der Ausgabe erschien. Wir stellten eine Verzögerung von etwa 250 Millisekunden fest. Des Weiteren hatte auch diese Kamera ein sehr kleines Aufnahmebild von nur 360 x 250 Pixeln. Damit war es noch weiter unter dem Bereich den wir eigentlich vorgesehen hatten. Auch preislich war die Flir Wärmebildkamera in einem eher höher gelegenen Bereich. Aufgrund des kleinen Bildes, der Latenz und dem Preis schied die Flir Wärmebildkamera schon nach den ersten Tests für uns aus.

Wärmebild der Kamera


Kamera mit Infrarotfilter

Unsere ersten sehr guten Erfolgserlebnisse hatten wir mit einer Kamera mit Infrarotfilter. Der Filter lässt nur ein für uns unsichtbares Infrarotfarbspektrum in das Kamerabild. Durch einen Infrarotstrahler den wir installierten konnten wir also genauer bestimmen welche Bereiche von unserer Kamera wahr genommen werden sollten. Einen großen Vorteil bot diese Kamera durch ihre wechselbaren Objektive. Mit einem Weitwinkelobjektiv war es uns zum ersten Mal möglich eine große Fläche aufzunehmen und mit dieser zu arbeiten. Nachdem die Kamera wieder über USB mit einem USB-VideoGrabber verbunden wurde stellten wir leider wieder eine starke Latenz fest. Nach Rücksprache mit Herrn Frieder Weiss, der viel Erfahrung mit dem Tracking von Personen im Raum hat, kamen wir jedoch auf die Lösung unseres Problems sowie unserer bisherigen Prototypskamera.

Kamera
Infrarotfilter


Ethernet Kamera mit Infrarotfilter

Ethernet Kamera

Der Unterschied zur vorherigen Kamera ist, dass die Ethernet Kamera mit Infrarotfilter eine Verbindung über das Netzwerk ermöglicht. Damit fiel die durch den USB-VideoGrabber erzeugte Latenz vollkommen weg. Außerdem bietet die Ethernet Kamera noch den Vorteil, dass sie über den IDS Treiber erfreulich viele Einstellungsmöglichkeiten bot. So konnten wir variablen wie die Belichtung ganz einfach am Rechner einstellen und mussten nicht mehr viel an der Kamera direkt tun, was bei der USB Infrarot Kamera sich teilweise als Problem darstellte, da wir diese an einer Traverse an der Decke eines Raumes befestigt hatten.

Außerdem kam mit der Erweiterung durch die Ethernet Kamera eine weitere Erweiterung durch einen neuen Infrarotstrahler der uns freundlicherweise von Herrn Frieder Weiss zur Verfügung gestellt wurde. Der einzige erste Nachteil den wir an dieser Kamera feststellen mussten war leider, dass es zu ihr nur einen Treiber für Windows und Linux gab, so waren wir auf diese beiden Betriebssysteme festgesetzt.


Tracking

Prototyp

Nachdem wir einen funktionierenden VideoGrabber und OSC-Sender hatten, machten wir uns daran einen ersten funktionierenden Tracker zu programmieren. Auch für den Tracker konnten wir ein Add-on von OpenFrameworks nutzen. Mit dem „ofxOpenCV“-Add-on hatten wir die Möglichkeit auf den ContourFinder zuzugreifen, der geschlossene Flächen in einem Video erkennen kann. Auch die Umwandlung in ein Graustufenbild war dank „ofxOpenCv“ umsetzbar. Für unseren ersten Tracker arbeiteten wir mit Hintergrundsubtraktion. Dafür schrieben wir unseren Code so, dass man auf Knopfdruck eine Momentaufnahme des Videos macht. Mithilfe der Funktion „absDiff()“ konnten wir das Hintergrundbild von dem Video abziehen, und hatten damit ein Video, das nur die Änderungen zeigt. In diesem Video sollte der ContourFinder uns nun die geschlossenen Flächen zeigen. Nachdem der Tracker sowohl mit Kameraeingang als auch mit einer Video-Datei gut funktionierte, machten wir uns daran den OSC-Sender mit in den Code einzubinden.

Eine ausgiebige Internetrecherche brachte uns darauf, dass neben dem Add-on „ofxOpenCV“ auch noch das Add-on „ofxCv“ existiert. „ofxCv“ stellte uns genau das zur Verfügung was wir für unser Programm brauchten, eine Klasse für Graustufenbilder „ofxCvGrayscaleImage“, für Farbbilder „ofxCvColorImage“, einen erweiterten „ContourFinder“, der weiße Formen aus einem Graustufenbild trackt und mit einem Rechteck umzeichnet. Außerdem existierte eine Klasse namens „ofxCvRectTrackerFollower“, die allen vom ContourFinder getrackten Formen folgt. Um unser Programm übersichtlich zu halten entschieden wir uns dafür, einzelne Module für die jeweiligen Aufgaben zu schreiben.


ofApp

Jedes OpenFrameworks-Programm besteht aus einem ofApp Modul, dass die Zusatzmodule einbindet und das Programm steuert. Die drei wichtigsten Funktionen sind setup(), update() und draw(). Die Funktion setup() wird immer zu Beginns des Programms aufgerufen und ist dafür verantwortlich die Variablen und Objekte zu initialisieren. In unserem Code werden hier Objekte wie der VideoGrabber und der ContourFinder initialisiert und mit Werten, wie der Framerate definiert. Zur Laufzeit des Programms wird die Funktion „update()“ regelmäßig aufgerufen. Sie sorgt dafür, dass unser Kamerabild und das Differenzbild stetig erneuert werden und dass die OSC-Signale regelmäßig ausgesendet werden. Außerdem werden hier die Funktionen unseres Trackers stetig aufgerufen, damit auch dieser in Echtzeit arbeitet. In „draw()“ geht es um den optischen Output. In unserem Fall ist es natürlich wichtig, den Tracker bei seiner Arbeit zu verfolgen, deshalb lassen wir uns hier das Differenzbild und den ContourFinder ausgeben. Zudem wird eine Tabelle angezeigt in die die getrackten Formen mit zugehörigen Eigenschaften eingetragen werden.

Um stets ein günstiges Hintergrundbild zu bekommen, entschieden wir noch die Funktion „keyReleased()“ beizufügen, die auf Knopfdruck das Hintergrundbild festhält. Um besser mit den Programmen der anderen Arbeitsgruppen synchronisieren zu können haben wir noch einzelne OSC-Signale den Zahlentasten von 1-8 zugewiesen. Das Drücken der Taste „0“ sorgt dafür das der OSC-Sender ein-/ausgeschaltet wird.


blobFollower

Die Klasse „blobFollower“ erweitert den „ofxCvRectFollower“. Der „blobFollower“ basiert auf der Idee von Glow-Objekten, die McDonald in seinem Code benutzt um getrackte Flächen mit Hilfe eines Kreises auf dem Bild anzuzeigen. In der Klasse „blobFollower“ wird jedem getrackten Objekt eine Instanz zugeordent die die Eigenschaften des Objektes speichert. Der Vorteil des „blobFollower“ ist, dass sobald eine getrackte Form verschwindet, die zugewiesene Instanz gelöscht wird. Dies ist beispielsweise der Fall, wenn zwei Blobs verschmelzen oder ein Blob von der Trackingfläche verschwindet.


visitorData

„visitorData“ ist ein Vektor der die aktuellen „blobFollower“ verwaltet. Die maximale Anzahl an Besucher ist entweder einstellbar oder standartmäßig auf 4 gesetzt. Solange der Vektor vier „blobFollower“, gibt die Klasse diese aus. „visitorData“ prüft ständig seine Liste und prüft ob jede Stelle auch mit einem „blobFollower“ belegt ist, für den Fall das eine Lücke vorhanden ist, wird die Liste neu durchiteriert und es wird geprüft ob ein neuer „blobFollower“ vorhanden ist. Die Klasse arbeitet mit IDs und weist jedem „blobFollower“ eine Nummer zwischen 0-3 zu. Hierbei überprüft die Klasse stetig, dass der Vektor von unten nach oben befüllt wird, dass bedeutet für den Fall, dass ein Objekt verschwindet, rutscht das nächsthöhere eine Stufe nach unten.


oscManager

Die Klasse „oscManager“ ist größtenteils aus unserem älteren Prototypen übernommen. Für jeden der vier blobFollower wird jeweils die Position in zwei float-Werten zwischen 0-1 mit jeweils zugehörigem Namen gespeichert. „sendMessage“ sendet dieses Paket dann an die vorher eingestellte IP-Adresse und den zugehörigen Port.


Technische Umsetzung fertiges Produkt

Abbildung unseres Hardwareaufbaus

Neu hinzugekommene Elemente, wie LED-Stripes und ein Tablet. Vernetzt wurde unsere Anwendung per Wlan und Lan Verbindungen. Für den Aufbau hatten wir drei Computer. Einen Tower-PC auf dem die Visualisierung und die Audiokomponente abliefen. Um Latenzen vorzubeugen, beschlossen wir Tracking und CoreLogic auf zwei getrennten Laptops laufen zu lassen. Neben den Computern bestand unser Aufbau zudem aus einem Tablet und vier Arduinos, die für die Ansteuerung der LED-Stripes zuständig waren. Alle Komponenten waren in einem Netzwerk, das mit Hilfe einer Fritz Box erstellt wurde. Der Tracking-Laptop wurde per LAN-Kabel mit der Infrarot-Kamera verbunden. Weil wir Latenzprobleme hatten ließen wir die Positionsübertragung an die Arduinos direkt von dem Trackingprogramm ausgehen. Neben diesen Komponenten hatten wir wieder Boxen, Beamer und MovingHeads in unserem Aufbau.

Unsere Datenübermittlung wurde nun zentral gebündelt. Da sich das Team Tracking um die Entwicklung der CoreLogic kümmerte, konnten wir am Ende alle Daten über die CoreLogic laufen lassen. Diese kümmerte sich jedoch nicht nur um den Datenaustausch, sondern auch um die Kollisionsabfrage, welche überprüfte, ob entweder ein Benutzer mit Objekten oder ein Benutzer mit einem Benutzer kollidierte.



XML Dokument

XML Dokument Tracking

Ein eher störendes Problem war die lange Kompilierzeit des Qt-Creators unter Windows. Dies ist uns vor allem aufgefallen, weil wir sehr oft kleinere Sachen im Code ändern mussten. Beispielsweise wären hier die einzelnen IP-Adressen der anderen Computer zu nennen. Um dies zu vermeiden suchten wir nach einer Möglichkeit die Zuweisung der Variablenwerte extern zu vollziehen. Dabei stießen wir auf das Add-On „ofxXmlSettings“ mit dem Werte aus einem externen File in XML-Datenstruktur ausgelesen werden können. Dies nutzen wir um direkt bei Start unserer Software diese Datei auszulesen und unsere Variablen mit den entsprechenden Werten zu befüllen. Auf der linken Seite der Abbildung befinden sich die Starteinstellung der Software, die dann später auch im User Interface anpassbar und veränderbar sind. Auf der rechten Seite werden die Ports und IP-Adressen der einzelnen Komponenten festgelegt. Also von Visualisierung, Audio und von den Arduinos, die mit der LED-Steuerung zusammenhängen.

User Interface

User Interface Tracking

Weil sich während der Projektphase auch immer wieder unser Aufbau und dadurch die Umgebungsbedingungen änderten, mussten wir oft unsere Trackingparameter neu anpassen und kalibrieren. Wir hatten jetzt zwar den Vorteil nicht mehr bei jeder Änderung das Programm neu kompilieren zu müssen, dennoch gestaltete sich die Einstellung der Parameter schwierig. Deshalb entschieden wir ein kleines User Interface für unsere Software zu entwickeln in dem wir anhand des Livebilds die Parameter ändern können und somit auch die Auswirkungen sofort sehen.

Mit „FRAMEDIFF“ kann zwischen Graustufenbild oder Binärbild gewählt werden. So kann man sich zwei verschiedene Visualisierungen der Software in einem Fenster anzeigen lassen und mögliche Fehlerquellen die beim Tracking entstehen schneller erkennen. „BORDERWIDTH“ bestimmt den Bereich des Bildes in dem tatsächlich getrackt wird. Dies brachte den Vorteil unerwünschte Randbereiche leicht auszublenden. „FRAMERATE“ war wie der Name schon verrät verantwortlich für die Bildrate die von der Kamera aufgezeichnet wurde. In unserem Fall waren das die meiste Zeit 25 fps. „ctfMinArea“ und „ctfMaxArea“ legten die Mindest- bzw. Maximalgröße eines Blobs oder einer Fläche fest, die getrackt wird. Weil die Kamera immer wieder verstellt wurde, konnten die Besucher je nach Bildausschnitt größer/kleiner wirken und wir konnten das Tracking daran anpassen. „ctfThreshold“ und „fdThreshold“ waren die Schwellenwerte anhand derer die einzelnen Bilder binarisiert wurden. „fdBlur“ machte das Bild unschärfer und machte dadurch das Tracking manchmal etwas flüssiger.

In der Settingssektion wurden die Größe der Blobs festgelegt, sowie beispielsweise der „Blur“-Effekt, also wie scharf die Kanten der Objekte wahrgenommen werden. Bei Einstellungen des Kamerabildes war dies häufig sinnvoll, vor allem als wir beschlossen, unsere getrackte Fläche zu vergrößern und damit eine deutlich andere Blobgröße erzeugten. In der Sektion OSC werden zunächst alle gesetzten IP Adressen angezeigt, die auch im XML-Dokument stehen. Hier war schnell zu erkennen falls irgendwelche Daten nicht ihr Ziel erreichen würden aufgrund einer falsch gesetzten oder übernommenen IP-Adresse. Außerdem kann das Senden von OSC-Signalen an bestimmte Adressen oder an alle Adressen ausgeschaltet werden, um Latenz-Problemen vorzubeugen.

Weil das Tablet noch in der Entwicklung war, haben wir noch eine Funktion zum Setzten von Objekten umgesetzt, damit wir überprüfen können ob unsere CoreLogic diese Daten verarbeitet. Die Testobjekte waren über das Tracking mit den Tasten „1“ bis „4“ platzierbar und hatten damit auch die jeweilige ID und den jeweiligen Typus.


CoreLogic

Während die Tracking-Software sich in diesem Semester eher wenig weiterentwickelt hat, hatten wir die Aufgabe eine neue Komponente unseres Aufbaus zu erstellen. Die CoreLogic fungiert als eine Art Schaltzentrale unseres Systems. Die Hauptaufgaben bestehen darin auf bestimmte Events zu reagieren und alle benötigten Daten zu verteilen. Den Schritt ein gänzlich neues Programm zu entwickeln haben wir aus mehreren Gründen gewählt. Ein Aspekt waren die verschiedenen die verschiedenen Hardware-Komponenten unseres Systems, die mit Daten versorgt werden mussten. Weil der Datenaustausch jedoch auch eine gewisse Leistung vom Programm abverlangt, beschlossen wir Ihn auszulagern um das Tracking unbeeinflusst zu lassen. Um den Datenaustausch zu realisieren brauchte es natürlich auch Code, was zur Folge hatte, dass unser Programmcode schnell sehr unübersichtlich geworden wäre. Um diesem Problem vorzubeugen, entschlossen die CoreLogic als externes Programm zu schreiben. Zu guter Letzt entschlossen wir uns für die CoreLogic, weil wir die nötige Kollisionsabfrage nicht innerhalb des funktionsfähigen Trackingcodes programmieren wollten.

Kollisionsabfrage

Die Kollisionsabfrage besteht aus verschiedenen nötigen Einzelkomponenten. Da ist zunächst die Methode „readOscObject(ofxOscMessage m)“. Diese wird aufgerufen sobald die CoreLogic eine OSC-Nachricht über die Adresse „/tablet“ geschickt bekommt, da es nur über das Tablet möglich sein sollte, Objekte auf der Fläche zu setzen.

Eine fast identische Methode wurde zum Setzen der Benutzer entwickelt. Die Methode „readOscUser(ofxOscMessage m)“. Diese wird aufgerufen sobald Daten über die Tracking Software mit der Adresse „/person“ empfangen werden. Nun, da wir sowohl sämtliche Daten der Nutzer, sowie der Objekte im direkten Zugriff in der CoreLogic zur Verfügung stehen hatten, konnten wir zur eigentlichen Kollisionsabfrage kommen. Zunächst die Kollision zwischen einem Benutzer und einem Objekt. Dies überprüft die Methode „checkForCollision()“. Die Methode wird in der „update()“ Methode aufgerufen und ist damit dauerhaft aktiv.

Die Kollisionsabfrage zwischen zwei Personen ist ähnlich aufgebaut und nennt sich „handleUserCollision(ofxOscMessage m)“. Findet eine Kollision statt, so wird die Methode „sendMessageCollision(int, int, int, float, float)“ aufgerufen. Diese verwaltet das Senden der Kollisionen an die einzelnen Komponenten. Hierzu im Punkt Datenübertragung mehr.

Datenübertragung

Tracking

Die Positionsdaten unserer Nutzer generieren wir nach wie vor im Tracking und senden diese über die Adress “/person“ an die CoreLogic. In der CoreLogic werden diese, wie oben beschrieben, gespeichert und weitergeleitet. Ebenso kommt die Nachricht einer Personenkollision vom Tracking und wird in der CoreLogic nur weiterverteilt. Das Senden der Positionsdaten an die LED-Stripes geschieht aus Latenzgründen im Tracking. Deshalb senden wir von der CoreLogic auch ein Signal an das Tracking sobald ein Objekt gesetzt oder zerstört wurde. Dieses wird dann vom Tracking an die LEDs weitergegeben.

Tablet

Das Tablet sendet Nachrichten mit der Adresse „/tablet“, wenn ein Objekt gesetzt wurde. In diesem Fall erhalten wir die Position und die ObjektID. Aber auch das Tablet erhält Daten sobald eine Kollision passiert ist. Hierfür senden wir die ObjektID, damit das kollidierte Objekt auf dem Tablet zurückgesetzt werden kann.

Außerdem wird vom Tablet ein Startsignal zum initialisieren des Videos zum Start des gesamten Projektes gesendet. Dies ist eine Eins, die über die Adresse „/tablet/start/“ empfangen wird.

Audio

Für den Fall, dass eine Person die Trackingfläche betritt wird an Audio die Nachricht „/audio/personIn“ gesendet. Mit dem Audio hat die CoreLogic nur eine einseitige Verbindung, das heißt es werden nur Daten gesendet, aber keine empfangen. Im Falle einer Kollision, bekommt das Audio eine Nachricht mit der Adresse „audio/collision“ in die wir neben der ObjektID auch noch vorgegebene feste Werte mitsenden, die das Soundprogramm benötigt.

Außerdem leiten wir im Falle einer Personenkollision eine Nachricht mit „/audio/userCollision“ weiter.

Diese Nachricht schickt einen einfachen Integer mit dem Wert Eins, allerdings wurde sie im aktuellen Projektmodell nicht weiterverwertet.

Visualisierung

Auch die Visualisierung empfängt nur Daten und sendet keine weiter. Zuerst wird auch hier ein Signal zur Personenkollision weitergeschickt. In diesem Fall senden wir die IDs der beiden Nutzer und die Koordinaten der Kollision mit.

Auch die Kollision zwischen Objekten und Benutzern wurde an die Visualisierung weitergeleitet um die Objekte wieder verschwinden zu lassen. Die Kollisionsnachricht wurde an die Adresse „/video/collision“ gesendet.

Für die Darstellung der Avatare und Objekte waren natürlich auch die Koordinaten der Nutzer und Objekte von Nöten. Sobald wir also die Koordinaten erhalten haben, wurden diese an die Visualisierung weitegeleitet.

Visuell umgesetzt ist die CoreLogic nur ein einfaches graues Fenster.

XML Dokument CoreLogic

XML Dokument CoreLogic

Um auch in der CoreLogic wichtige Variablen zu verändern ohne neu kompilieren zu müssen, haben wir die Einbindung eines XML_Files in unserem Code umgesetzt. Hierbei konnten wir einfach anhand der Vorlage des Trackingcodes arbeiten. In dem Dokument sind alle IP-Adressen aller Komponenten festgehalten, sowie die Größe und Breite des Feldes und des Objektes. Außerdem sind die wichtigsten Adressen festgehalten über die gesendet und Empfangen wird.

Audio

Der Audio-Patch ist für den musikalischen Anteil von „Show Interactive“ zuständig. Die Funktionsweise ist so angedacht, dass die OSC-Daten, die vom Tracking gesendet werden, in unserem Patch auf die entsprechenden Regler, welche für die Modulation der Musik zuständig sind, gelegt werden. Gleichzeitig sollte ein OSC-Signal an die Visualisierung gesendet werden, welches verwendet werden würde um einen Visualizer in Bewegung zu versetzen. Der aktuelle Stand des Audio-Patch wurde so umgesetzt, dass die erstellten Instrumente in einen Mixer laufen. Die Instrumente werden über verschiedene Midi-Kanäle angesprochen. Danach geht der Output an die Lautsprecher und an das ezFFT Modul, welches das Audiosignal umwandelt. Das umgewandelte Signal wird per OSC Send Array weitergeleitet an die Visualisierung. Das ezFFT Modul stammt aus der User Library von Reaktor 6 und wurde für die Ausgabe an die Visualisierung angepasst. Den groben Ablauf und damit unsere Anforderungen, können nachfolgendem UML-Diagramm entnommen werden.


Klangkonzept und Arrangement

Oscilators

Unser erster Patch sah vor, die diversen Instrumente, die in unserer Einarbeitungsphase entstanden waren, zu optimieren und zu einem zusammen zu führen. Es sollte ein einziges Instrument entstehen, dass verschiedene Klangbilder realer Instrumente nachbilden kann. Indem wir zwischen Presets interpolierten und nicht einfach nur die Lautstärke einzelner Module veränderten, wollten wir dem Nutzer eine besonders markante Modulation ermöglichen. Diese Idee erwies sich als Irrtum. Mit der Kombination von mehreren Instrumenten beraubten wir uns nur der Möglichkeit einen MIDI-Kanal korrekt zuzuordnen, während die Ergebnisse der Klangmodulation keine Verbesserung brachten. Die verwendeten beiden Oszillatoren waren extrem prägnant und ein deutlicher Wechsel zwischen den beiden war nur über einen Lautstärkemixer möglich. Aus diesem Grund verwarfen wir die Idee eines einzigen Instrumentes und sammelten stattdessen 4 funktionierende Elemente die sich klanglich und strukturell stark unterschieden.

Neben den Stimmen unseres Ensembles läuft auf einem Beatlooper aus der Standardbibliothek ein Regengeräusch. Diesen Effekt bezeichnen wir als Klangteppich, welcher zu Beginn dafür sorgen soll, dass der Nutzer sich wohlfühlt. Durch ein bekanntes Geräusch wie dem Regen wird eine gewisse Atmosphäre geschaffen welche sich wieder auflöst sobald der erste Nutzer den Trackingbereich betritt. In diesem Moment wird der Klangteppich leiser und die Musik die moduliert werden kann, fängt an zu spielen. Somit wird aus einem Raum in dem zunächst kaum etwas los zu sein scheint, ein überraschendes Erlebnis. Derzeit geschieht der Wechsel noch von Hand im Studio Mixer. Für nächstes Semester ist jedoch ein automatischer Wechsel zwischen Ruhezustand und Aktivzustand vorgesehen.


Audio-Patch

Unser Audio-Patch besteht aus Core- und Primary-Cells welche miteinander verknüpft wurden. Wie diese Verknüpfungen in unserem Prototyp des Audio-Patches aussehen.

Prototyp Audiopatch

Durch die OSC-Einstellungen, welche über die Metadaten direkt modifiziert werden können wurde das Handling der OSC-Daten eingestellt. Die Nachrichten, welche an einem Eingangs-Port abgehört und entpackt werden können nun verschiedenen Reglern als Wert zugewiesen werden. Da wir vorerst nur die Position eines Nutzers ermittelten, konnte sich darauf verlassen werden, dass mit oscX0 und oscY0 die jeweilige Achse auf die Steuereinheiten richtig projiziert wird. Die Skalierung der Werte, die vom Tracking auf 0 bis 1 normiert sind, übernimmt Reaktor glücklicher weise von selbst. Daher blieb uns nur noch überlassen, den Wertebereich eines Reglers abzuhören und anzupassen. Der Abschluss des Patches bestand nun im Mapping der OSC-Werte.

Instrumente

Orgel

Das erste Instrument, das für den Audio-Patch gebaut wurde ist eine Orgel die dem Additive Synthesis Tutorial für eine ältere Version von REAKTOR nachempfunden ist.

Die Orgel besteht aus aus mehreren Oszillatoren die durch einen Mixer miteinander verbunden werden. Das Gate, mit dem der Output der Oszillatoren multipliziert wird, verhindert, dass ununterbrochen ein Ton gespielt wird. Der 4-Pole Filter sorgt dafür, dass der Hoch- und Tiefpass gefiltert wird. Flanger und Fbk Delay sind optionale Effekte und sorgen dafür, dass das Instrument etwas besser klingt. Die Schieberegler A1 bis A8, sowie die Regler F1 bis F8 bestimmen, wie sich das Instrument anhört. Dieses Instrument ist an sich nicht sehr komplex, erfüllt aber seinen Zweck voll und ganz.

VOSIM

Das zweite Instrument heißt VOSIM. Es klingt nach einem typischen elektronischen Synthesizer und ist einem Tutorial von ADSR nachempfunden [4].

Bei VOSIM handelt es sich um ein komplexes Instrument, welches eine normale Sinus-Kurve und eine Hüllkurve mit einander verrechnet und daraus einen Output generiert. Dieses Instrument ist im Prinzip Folgende Abbildung gibt einen Einblick in die innere und eigentliche Funktion von VOSIM. eine komplexe Mathematik Aufgabe.

Midi-Input

Bei der Wahl der Software gab es unter anderem das Problem, dass Reaktor 6 kein Modul zur Verfügung stellt, welches das Einlesen von Midi-Dateien erlaubt. Somit musste eine geeignete Software gefunden werden, welche die Midi-Files einliest und an Reaktor 6 sendet. Übergangsweise wurde dieses Problem mit der DAW (Digital Audio Workstation) TRAKTOR gelöst. Da die Universität nicht über eine Lizenz dieser Software verfügt, musste eine DAW gefunden werden, welche kostenfrei zur Verfügung steht.

Durch Johannes Brendel sind wir auf Reaper gestoßen. Reaper ist eine kostenfreie DAW welche als Open-Source Projekt publiziert wird. Somit geschieht der Midi Input an den Audio-Patch nun übergangsweise mit Reaper. Nach dem sich mit der Software vertraut gemacht wurde, ist ein Setup entstanden, welches das direkte einspielen der Midi-Files in Reaktor 6 ermöglicht. Dazu muss Reaktor 6 geöffnet werden und der Midi-Receiver aktiviert werden. Sobald das geschehen ist, kann in Reaper der Midi-Output auf den Midi-Input in Reaktor gelegt werden. Diese Einstellungen können zusammen mit der Midi-Datei, welche abgespielt werden soll, als Projekt abgespeichert werden. Diese Projekte wurden später auf Grund von Änderungen am Audio-Patch weiter angepasst bis sie für den Finalen Patch verwendet werden konnten.

Steuerung OSC

Open Sound Control (OSC) ist ein Netzwerkprotokoll welches hauptsächlich zur Echtzeitverarbeitung von Sound und über Netzwerke und Multimedia Installationen verwendet wird. Es erweitert die Midi-Schnittstelle, welche den Standard im Musikbereich darstellt. Da Reaktor 6 OSC standardmäßig unterstützt, mussten wir keine zusätzlichen Programme dafür installieren. Es hat sich aber ergeben, dass wir einen Standard für die Verwendeten OSC-Ports festlegen müssen, da sonst immer Port und IP-Adresse abgefragt werden müssten, wenn das gesamte Projekt aufgebaut wird. Zudem sollten im Audio-Patch die Ports fest eingespeichert werden auf denen empfangen und gesendet wird, sodass die Verwendung des Patches im Reaktor Player immer einwandfrei funktioniert. Das liegt daran, dass im Reaktor Player nichts nachjustiert werden kann.

ezFFT

Für den Output an die Gruppe der Visualisierung haben wir das Modul ezFFT aus der User Library von REAKTOR6 genutzt [5]. Dieses Modul wurde herausgesucht nachdem klar wurde, dass der Audio Output der per OSC an die Visualisierung gesendet wird zunächst Fourier transformiert werden muss. Die Fourier transformierten Daten sollten anschließend als Array an die Visualisierung gesendet werden. In Zusammenarbeit mit der Visualisierung wurde das ezFFT Modul weiter modifiziert, um unseren Anforderungen gerecht zu werden.

So wird mit dem von REAKTOR6 bereitgestellten Modul OSC Send Array der Output des ezFFT direkt an die Visualisierung gesendet. Dieser musste jedoch noch weiter Modifiziert werden, da sonst zu viele Daten in zu kurzen Abständen gesendet wurden. Zu Beginn funktionierte der Output der Daten noch einwandfrei und die Visualisierung konnte diesen problemlos interpretieren. Doch mit der Fertigstellung des Audio-Patch Prototypen hatte die Ausgabe des ezFFT einen Bug bekommen der leider nicht mehr bis zur Präsentation zu beheben war. Nachfolgend ist das ezFFT Modul mit der OSC Send Array Erweiterung zu sehen.


Technische Umsetzung im Endprodukt

Nach der Neuausrichtung des Konzeptes mussten wir unseren Plan für die technische Basis anpassen. Dazu gehörte natürlich auch das Audioprogramm.

Seit dem Ende des letzten Semesters begann das Team-Audio verschiedene interessante Reaktor-Ensembles aus der Reaktor User Library zu sammeln, sodass wir bereits zum Beginn des zweiten Projektabschnitts über eine potente Sammlung von Instrumenten verfügte. Diese dienten uns auch als Vorlage um eigene Synthesizer umzusetzen, die er wiederum in seiner Bibliothek hinzufügte. Wir hatten damit eine große Samplebank zur Verfügung aus denen wir schließlich nur noch die entsprechenden Instrumente für unser Thema auswählen mussten. Die zentrale Aufgabe war es, die Steuerung der Synthesizer umzusetzen. Diese sollten Töne nachspielen, sobald ein Kollisionsevent eines Nutzers mit einem Objekt stattgefunden hatte. Probleme ergaben sich durch die verschiedenen Objekttypen, denen jeweils ein eigener Sound zugewiesen werden sollte, sowie der individuellen Spieldauer eines Synthesizers. Aus einem OSC-Event als Input mussten wir also eine MIDI-Nachricht “Note On” erstellen, auf die nach Ablauf einer bestimmten Zeit eine “Note Off”-Nachricht folgen sollte, damit der Synthesizer aufhören würde zu spielen.

Der erste wichtige Schritt lag darin, gemeinsam mit dem Team Tracking ein Protokoll festzulegen, dem unsere OSC-Kommunikation unterliegen sollte und dieses anschließend zu testen. Team-Audio fasste also die Erkenntnisse zur Korrelation von OSC und MIDI innerhalb von Reaktor in einem Dokument zusammen, nach dem sich dann das Tracking Team beim Beschreiben der OSC-Werte richtete. Da das MIDI-Protokoll 4 Bit für die Kodierung einer Kanalinformation vorsieht, wurde entschieden den Kanal mit der ObjektID gleichzusetzen um darüber die direkte und eindeutige Kommunikation zwischen Objekten und ihrem vorgesehenen Instrument sicherzustellen. Dieser Entscheidung lag die gesamte folgende Arbeit des Trackingteams zugrunde, die sich nun darauf konzentrierten die OSC-Nachrichten mit den entsprechenden Kanalnummern zu bepacken. Für unsere Zwecke erfüllte dieses Vorgehen die Anforderungen zur vollen Zufriedenheit, allerdings limitiert es die Arbeit mit Reaktor auf eine Instanz des Programms. Da eine Reaktorinstanz stets nur über einen bestimmten Port auf OSC-Nachrichten hören kann, war es nur noch möglich, den Identifier der OSC-Nachricht zu nutzen, um innerhalb von Reaktor zwischen einzelnen Nachrichten zu unterscheiden. Da dieser Identifier auch immer fest an eine MIDI-Kanalnummer gebunden war, konnten wir so gut wie alle Werte der OSC-Nachricht durch Konstanten ersetzen.

Hier das Dokument zur OSC-MIDI-Konversion:

Vorüberlegung: Maximal 16 verschiedene Instrumente

→ 16 IDs

→ 16 Channels

Jedes Objekt unserer Interaktion hat einen eigenen MIDI-Channel, zu dem es sendet. Das entsprechende Instrument in Reaktor hört nur auf Signale aus diesem MIDI-Channel. Die Konversion findet in Reaktor statt.

Ich nehme eine OSC-Nachricht an, die wie folgt aufgebaut ist: Status (4 Bit) → Channelnumber (4 Bit), Notevalue (8 Bit), Velocity (8 Bit)

In dem 4 Bit Status steht entweder 1000 (Note on) oder 1001 (Note off). In der Praxis kann das bedeuten, dass im ersten Identifier der OSC-Nachricht entweder 8 oder 9 stehen muss. Es kann aber auch sein, dass das Channel Message-Modul, das die Inputs in eine MDI-Nachricht verpackt, entweder 0 oder 1 erwartet und das allererste Bit als Kontrollbit verloren geht (das müssen wir dann testen). Die nachstehende Abbildung zeigt das nochmal auf. Die Funktion der Status Bits ist es, verschiedene MIDI-Befehle zu unterscheiden. Es gibt dann zum Beispiel noch Controller-Messages oder Pitchbend. Wir brauchen aber (zunächst) nur Note On/Off.

Specification Message Summary

In der OSC-Nachricht von Tracking stehen also vier Parameter:

i0 → Note on/off i1 → (0-15) i2 → (0-127) i3 → (0-127)

Der Identifier heißt hier jeweils ix. Das OSC-Receive Modul legt die Werte jedoch so wie sie ankommen in einem eigenen Ausgang ab, also ist der Name des Identifiers egal. Wichtig ist nur die Reihenfolge, in der die OSC-Nachricht aufgebaut ist.

Vom Channel Message-Modul wird dann intern in Reaktor die MIDI-Note im gewählten Kanal angeschlagen. Da das entsprechende Instrument nur auf diesen Kanal hört, wird auch nur dieses spielen. Im Folgenden die Erklärung der Module:

Aufbau Audio


Für den Fall, dass es Tracking einfacher erscheint, für jeden Parameter der MIDI-Nachricht eine eigene OSC-Nachricht zu schicken, können auch einzelne OSC-Nachrichten angenommen werden und nach Ihrem Adress-Pattern aufgelöst werden. Dann wären es also 4 OSC-Receive Module, die auf ihre eigene Nachricht warten. (Adress-Pattern ist der Name der gesamten OSC-Nachricht, Identifier sind die Namen der einzelnen Parameter die mitgeschickt werden)

Dann geht es noch um die Frage, wie der Ton ausklingt. Punkt ist auf jede Note ON- muss eine Note OFF-Nachricht folgen. Dafür ergeben sich m. M. n. mehrere Szenarien:


- Nach einer gewissen Zeit. Dafür muss ein Timer in der CoreLogic von Tracking laufen, oder man reseted das Channel Message Modul in Reaktor nach einer gewissen Zeit.


- Immer wenn eine neue Note eintrifft. Dafür stellt man im Reaktor-Instrument einfach ein, dass neue MIDI-Befehle alte überschreiben sollen.


- Immer wenn Teilnehmer verschwindet. Darauf müssen wir irgendwie reagieren und uns vielleicht überlegen wie wir reagieren, wenn wir nur kurzzeitig die ID verlieren.


Nach dem ersten vollständig erfolgreichen Test unseres OSC-Receivers, widmeten wir uns dem Problem der Off-Nachricht. Es gab hierbei zwei Optionen. Team-Audio konnte gemeinsam mit dem Trackingteam eine Timerfunktion in der Core Logic einbauen. Dies hätte den Vorteil Rechenlast vom Reaktorpatch zu nehmen. Die kohärentere Lösung war es jedoch, einen Mechanismus direkt in Reaktor zu implementieren, der auf eine On-Nachricht nach einer gewissen Zeit automatisch die entsprechende Off-Nachricht verschicken sollte. Ein Teammitglied hatte seine Suche nach einem geeigneten Timekeeping-Mechanismus in Reaktor bereits aufgegeben, als ein anderes Mitglied das entsprechende Modul fand. Mithilfe des Integrator Moduls waren wir in der Lage Zeit in Millisekunden zu messen und wir konfigurierten das OSC-Receiver Modul so, dass es die verstrichene Zeit seit dem Eintreffen der OSC-Nachricht des Kollisionsevents mit einer konstanten Zeitvorgabe verglich. Sobald diese überschritten wurde, aktiviert das Modul die Off-Nachricht und schaltete damit den Synthesizer ab.

Induktion: Objekte der Core Logic und Visualisierung sind direkt über die ID mit einem MIDI-Channel in Reaktor verbunden. Daher müssen die Receiver Module und Synthesizer auf einen Kanal fixiert werden.


Struktur des Reaktorpatches

Reaktor Patch

Durch die Aufteilung in OSC-Receiver-Module und korrespondierende Instrumente wurde das Arrangement des Reaktor Patches etwas komplexer als im Vorsemester. Die Aufteilung des Patches in Klangerzeuger und Datenverarbeiter ergab sich logisch aus den technischen Anforderungen. Des Weiteren beschränkten wir unser Produkt zunächst auf 4 verschiedene Objekte, um die Interaktion des außenstehenden Nutzers mit dem Terminal möglichst einfach zu halten. Innerhalb des Feldes sollten sich jedoch zumindest zwei Personen gleichzeitig aufhalten können, um zu zeigen, dass die Trackingsoftware auf mehr als eine Person skaliert werden konnte.

Um flexibel zu sein, koppelten wir eine Reaktoranwendung an einen physischen MIDI-Controller, den wir so einstellten, dass wir auf Knopfdruck das entsprechende Instrument auf einem exklusiven MIDI-Kanal ansprach. Neben den Instrumenten wurden Sounds für alle Events ausgewählt, die sich in unserer Trackingfläche ereignen konnten. Zudem wurden ein simples Hintergrundgeräusch modelliert, um keine absolute Stille aufkommen zu lassen, da die zusätzlichen audiovisuellen Reize leicht als störend aufgefasst werden konnten. Im finalen Arrangement erhielt nun jedes der vier Instrumente seinen eigens angefertigten Receiver mit spezifisch eingestelltem Timer. Zum Mixing nutzten wir das Bento Box Mix Modul der Reaktor Blocks Library. Dieses Modul ermöglichte uns nicht nur, alle Instrumente sowie das Hintergrundgeräusch zusammen zu fassen, sondern es gab auch die Möglichkeit für eine einfache Form von Sidechaining. Mithilfe eines Envelope-Followers, der den Amplitudengang eines Instrumentes auslas, konnten die umgebenden Instrumente im Mixbereich um denselben Lautstärkewert nach unten gedrückt werden. Damit wurde sichergestellt, dass für ein prominentes Instrument im Frequenzband des Audiomasters genügend Platz geschaffen wurde, sodass es besonders viel Punch bekam. Schlussendlich justierten wir noch die Receiver-Module auf die Instrument-Channel, sodass keine MIDI-Signale Kreuzfeuern konnten.

Induktion: Das Arrangement verbindet jedes Receiver- Modul mit dem ihm zugehörigen Instrument und sorgt für ein rudimentäres Mixing, sowie einen Sidechaineffekt.


Sounddesign

Reaktorpatch_SI

Das Entwerfen von Synthesizern rückte mit dem Fortschreiten des Semesters immer mehr in den Hintergrund. Wichtig war eine stilsichere Auswahl der Instrumente und vor allem eine funktionstüchtige Anordnung.

Das Sounddesign lässt sich im finalen Programm kurz zusammenfassen. Im finalen Reaktorpatch spielen 5 Instrumente. Für das Hintergrundambiente sorgt das Instrument “Spacedrone” in seinem Preset “Polar Wind”. Das Instrument “Space&Time” entstammt der User Library und wurde so justiert, dass es Laute erzeugt, die extraterrestrischen Signalen ähneln könnten. Ähnlich wurde mit “STELLA” verfahren, bei dem der Low Frequenz Oszillator so verwendetet wurde, dass eine wabernde Modulation der Tiefen und Mitttiefen entstand. Sound nummer drei erzeugt einen krachenden Explosionston, welcher aus einem knisternden Whitenoise, einem fulminanten Basston und dem langausgedehnten Subdrop besteht. Die Anschlagszeit für dieses Instrument beträgt aufgrund seiner Envelope-Einstellungen nur 10 Millisekunden, was jedoch für einen ordentlichen Wumms reicht. Das letzte Instrument ist von daher etwas Besonderes, dass es nur in Zusammenhang mit der MIDI-Clock Reaktors funktioniert. Es erzeugt mithilfe des Sequencers NODE-E asynchrone Glass Spielmusik auf dem Synthesizer Steampipe. NODE-E generiert die unrhythmischen Noten unter Zuhilfenahme der Tempoinformation der MIDI-Clock, weswegen diese konstant laufen muss, damit das Instrument spielt. Dieses letzte Instrument war am schwierigsten umzusetzen.


Visualisierung

Prototyp

Finaler Prototyp

Wir entschieden uns zu Anfang für einen zweidimensionalen Stil, der durch bestimmte stilistische Mittel, wie dunklere Farbabstufungen als Schatten, einen Eindruck von Dreidimensionalität vermitteln sollte. Bunte Farben sollten das Auge ansprechen und dem Besucher ein eindrucksvolles, visuelles Spektakel liefern. Nach einigen Skizzierungen der Grundidee entschieden wir uns nach einer gezeichneten Skizze für eine Pyramide, die in drei Teile zerschnitten wurde und somit unterschiedlich mit dem Besucher interagieren kann. Für die gleichzeitige Interaktion mit mehreren Besuchern – in der Ausarbeitung waren es konkret vier Figuren.

Unsere vier verschiedenen Formen (bisher die Pyramide), auf die pro Person je eine Figur zugewiesen wurde und die in 3 Teile aufgeteilt sind, können sich flexibel je nach Steuerung der Person im Raum bewegen. Durch einen Regler konnten wir einen Punkt auf der x- und y- Achse im Ausgabefenster bewegen. Ausgebaut auf unsere weiterentwickelten Figuren in Illustrator setzten wir dies in Java um. Wir ließen ein Polygon schweben und programmierten eine Schwebe- sowie Vibrationsfunktion (Hover-Funktion) der geometrischen Grundform. Durch die Beeinflussung von x und y Werten wurde die Figur mit hinterlegter Musik anfangs bewegt. Über das Ausgabefenster wurde die Pyramide angezeigt. Ein ausschlagender Bass in der Audio-Datei erzeugte die Vibration der Pyramide. Im nächsten Schritt fügten wir die Figur mittels eines PNG Bildes in unser Programm und unseren Code in Open Frameworks ein. Danach stimmten wir, das Team Visualisierung, mit der Gruppe Tracking das Verhalten der Figur mit der getrackten Person ab. Folgende Bewegungsmuster haben wir unserer Pyramide zugeteilt:

1. dauerhaftes vibrieren, schweben

2. bewegen mit der Position der getrackten Person nach rechts: Mittelteil verschiebt nach rechts und Ober- und Unterteil der Pyramide in die entgegengesetzte Richtung

3. bewegen mit der Position der getrackten Person nach links: Mittelteil verschiebt sich nach links und Ober- und Unterteil der Pyramide in die entgegengesetzte Richtung

4.bewegen mit der Position der getrackten Person nach vorne: Einzelne Figur Elemente ziehen sich von oben und unten auseinander (das Mittelteil bleibt mittig)

5.bewegen mit der Position der getrackten Person nach hinten: Einzelne Figur Elemente ziehen sich von oben und unten zusammen (das Mittelteil bleibt mittig)

Die Punkte von 2 bis 5 sind die Schnittstelle zu unserer Gruppe Tracking

Passend zu den Figurelementen wollten wir weitere Elemente (Linien, Kreise, Punkte) im Hintergrund mit einbinden. Anfangs wurde das Linien-Example in Open Frameworks weiterentwickelt. Diese Visualisierung bot uns einen Ausgangspunkt für weitere Ideen. Wir wollten nun passend zu der Pyramide weitere Effekte gestalten. Wir gestalteten einen rotierenden Kreis, der auf einer Seite abgeschwächt war und an ein Strahlen erinnern sollte. Diese Idee übernahmen wir für unsere ersten Prototypen im zweidimensionalen Raum und fügten Hintergrundvisualisierung (rotierender Kreis) und bereits beschriebene Pyramide zusammen. Für die Visualisierung der Musik dienten im Entwurf die um den Kreis angeordneten Linien. Im fertigen Prototypen überarbeiteten wir diesen Entwurf und ordneten diese unter die Pyramide an. Dieser Equalizer schlug passend zur Musik aus. Die in diesem Prototypen verwendeten Grafiken wurden ganz zu Beginn als Polygone und im weiteren Verlauf als Vektorgrafiken (für die Bearbeitung) und Rastergrafiken (für die Einbindung) umgesetzt.

Nach Ausarbeitung des Konzeptes und der Figur wurde entschieden, diese echt dreidimensional umzusetzen. Passend dazu wurde der Equalizer weiterentwickelt, der in Kombination mit der nun plastischeren Figur zu flach wirkte. Auch dieser wurde mittels 3D-Techniken umgesetzt.


Bodenvisualisierung

Zusätzlich zur Bespielung der Leinwand flossen einige Überlegungen in die Frage, wie man den Nutzungsprozess intuitiver gestalten kann, ohne das Konzept der Wandvisualisierung zu groß zu verändern. Gemeinsam mit dem gesamten Ziel kamen wir auf die Idee, dem Nutzer Informationen auf dem Boden also der Trackingfläche zu präsentieren. Nützliche Informationen wären z.B. die Zugehörigkeit zu einer bestimmten Figur, der Abstand zur Raummitte oder die aktuelle eigene Soundspur. Diese Aspekte flossen in einen Entwurf ein, der aufgrund eingeschränkter Umsetzbarkeit zwar nicht eingebaut wurde, aber ein möglicher Ausbau dieser Idee war vorgesehen.


Audiovisualisierung

Neben der visuellen Komponente, die mit den Bewegungen des Benutzers korreliert, sollte es auch eine Komponente geben, die die Änderungen des Audiosignals darstellt. Da die bekannteste Form von Audiovisualisierung ein Equalizer ist, hielten sich alle Entwürfe dieses Teils an das Konzept eines solchen. Ein rotierender Kreis war mittig platziert, auf der Bildunterseite dienten Linien für den Signal-Ausschlag. Die Umsetzung im Programm erfolgte durch Einbinden der Einzelteile als Bilder, aber die Idee wurde später verworfen und durch einen anderen Entwurf, der „Schallplatte“, ersetzt. Hierbei wurde ebenfalls ein Kreis eingebunden, der aber anstatt der Linien als Equalizer eingesetzt wurde und radial ausschlug. Um eine gewisse Dynamik beizubehalten, solange kein Audiosignal übertragen oder erzeugt wird, wurde eine Spirale eingebunden, die sich entgegen ihrer Windung dreht – das erzeugte den Eindruck, sie würde sich nach unten auf die Schallplatte zubewegen.


Implementierung

Als Grundlage des Visualisierungsprogrammes diente eine leere OFX-Projektvorlage. Die Anbindung an Eventhandler sowie die Hauptmethoden, die fürs Einrichten des Fensters, das Zeichnen und das Updaten verantwortlich sind, sind alle durch OFX gegeben.

Hauptklasse ofApp (Tracking-Schnittstelle)

Kern des Programmes bildet die Klasse ofApp, in der die Schnittstellen, die Darstellung und die Logik zusammenlaufen. Zudem wird die Steuerung hier eingebunden, die für die Präsentation zuständig ist. Ein Debugging-Modus, sowie verschiedene Modi für die aktuelle Anzeige (vor Präsentationsstart, Intro-Video, Tutorial-Video, Präsentationsmodus, normaler AppModus) sind ebenfalls in der ofApp implementiert. Die simple Tracking-Schnittstelle findet sich ebenfalls in der ofApp und wird mit den Membervariablen oscX1 bis oscX4 und oscY1 bis oscY4 sowie mit einem ofxOscReceiver-Objekt aus dem Plugin OfxOSC verwirklicht. Dieses wird in der updateOSC-Methode auf eingehende Nachrichten überprüft und weißt den Membervariablen die entsprechenden OSC-Werte zu, falls die OSC-Nachrichtenadresse übereinstimmt. Diese werden dann direkt an die Visualisierungsfigur übergeben, deren Aufbau im nächsten Abschnitt folgt.


Einzelkomponenten

Im Mittelpunkt der Visualisierung steht die Figur, die die Bewegungen des Nutzers im Raum wiederspiegelt und für eine direkte Assoziation mit dem Raum steht. Der Stand des Prototypen sah eine Pyramide als Figur vor, die dreigeteilt in der Wandmitte dargestellt wird. Jedoch sind beliebige andere optische Darstellungen möglich. In einem Vektor werden alle Teilkomponenten gespeichert und während dem Zeichnen und beim Empfangen von OSC-Werten werden deren analoge Methoden aufgerufen. Da die Figur aus unabhängigen Teilkomponenten besteht, die aber die gleichen Funktionen beherbergen, musste eine geeignete Unterklasse erzeugt werden, die diese implementiert. Im Laufe der Entwicklung änderte sich die Art der Teilkomponenten, aber die Funktionen blieben die gleichen. Neben der Zeichen-Methode, die sich je nach Art des Objektes ändert, beinhalten die Komponenten folgende Eigenschaften und Methoden:

• Base-Vektor, der die absolute Position innerhalb der Figur speichert

• Position-Vektor, der die aktuelle Position der Schwebebewegung speichert

• Offset-Vektor, der die vom Nutzer gesteuerte Verschiebung speichert

• Vektoren, die Dauer, Verzögerung & Reichweite des Schwebens festlegen (sind pro Objekt unterschiedlich, um einen gleichmäßigen sowie statischen Eindruck zu verhindern)

• Setter für die einzelnen Vektoren

• Hover-Methode, die die Schwebeposition aufgrund der Schwebe-Eigenschaften und der aktuellen Zeit seit Programmstart (ofGetElapsedTimeMillis) mit einer Sinusfunktion berechnet

Polygon:

Während der ersten Iteration der Prototypen wurde einfache Polygone als Einzelteile für die Figur verwendet. Dazu wurde die OFX eigene Klasse ofPolyline um die gewünschte Funktionalität erweitert.

Bild:

Nachdem die Entwürfe zu der Figur standen und in Adobe Illustrator umgesetzt und exportiert wurden, wurde die Polygon-Klasse myPolygon erweitert und eine BildKlasse myImage angelegt, die OFX‘ ofImage erweitert.

3D-Mesh:

Im finalen Zuge der Umsetzung wurde diese Funktionalität in 3D umgesetzt und ausgeweitet. Die entsprechende Klasse ist myMesh, abgeleitet von ofMesh. Aufgebaut wird das Mesh aus einzelnen Vektoren, Indizes für die Faces und Farben, welche alle in der figure.cpp gesetzt werden. Audio-Equalizer: Anstatt eines gewöhnlichen Equalizers wurde für Show Interactive ein kreisförmiger gewählt, der nach außen hin ausschlägt. Analog zur Figur wurden hier 3D-Meshes verwendet, die gleichmäßig um den Mittelpunkt verteilte Vertices beinhalten. Die Frequenz-Werte stimmen zahlenmäßig mit denen des Meshes überein und werden den mit den Radien der entsprechenden Einzelpunkte verrechnet. So entsteht der Equalizer-Ausschlag. Die entsprechende Klasse ist CircularVisuals.

Spirale:

Für eine dynamische Erscheinung, die genau wie bei der Figur für ein stets aktives Gefühl erzeugen soll, wurde hier die Spirale eingebunden, die sich kontinuierlich dreht – einmal zur Länge eines Taktes. Für die Spirale wurde ein kurzer Algorithmus geschrieben, der aus einer übergebenen Zahl an Windungen und Vertices pro Windung die Spirale es Polyline-Strip erzeugt.Wir haben außerdem getestet, die unteren Windungen der Spirale auch zum Klang ausschlagen zu lassen.


Schnittstellen

Die Bewegungen der Figur beginnen an der Tracking-Schnittstelle, die zwischen 0 und 1 genormte Fließkommawerte für die entsprechenden OSC-Koordinaten ausgibt. Diese werden in der update- und der darin aufgerufenen updateOSC-Methode an das Objekt figure über dessen Methode loadOffset(float x, float y) weitergegeben. Dort werden die Werte den einzelnen Teilkomponenten übergeben. Im Falle der Pyramide erhält der untere Teil eine Verschiebung in negative X- und Y-Richtung, der Mittelteil in X-Richtung und die Spitze in negative X- und positive Y-Richtung. Die Bewegung, die Schweben simuliert, ist in der Methode myMesh::hover(int now) implementiert und verwendet die Sinusfunktion für eine sanfte, runde Bewegung. Als Parameter wird die aktuelle Zeit verwendet, um einen offset verschoben und anteilig zur Schwebedauer hover_dur berechnet. Durch Verwenden des Modulo bleibt der Wert stets zwischen 0 und 1. Der Sinus wird auf die X- und Y-Variable angewandt und der Position übergeben. Zum Zweck der Präsentation wurde außerdem eine Animation fürs Starten und Stoppen eingebaut, die einen Koeffizienten startingTransition steuert, der mit den drei Positions-Vektoren vor dem Zeichnen multipliziert wird. Ist dessen Wert 0, werden die einzelnen Komponenten nicht bewegt und die Pyramide steht still am Boden. Beträgt dieser 1 schwebt die Pyramide und setzt die Bewegungen um. Ziel der Audio-Komponente ist es, die gehörten Klänge visuell darzustellen. Am bekanntesten sind hier sicherlich gewöhnliche Balken-Equalizer. Dabei wird das Audiospektrum in einzelne Frequenzbänder zerlegt, deren „Wert“ als Höhe des Balkens etc. dient. Unter Wert versteht sich hier die Gesamt-Lautstärke der einzelnen Frequenzen des Bandes. Um den Audioausgang in seine Frequenzanteile und damit deren Dezibel-Werte zu unterteilen, bemächtigt man sich einer Fast-FourierTransformation (kurz: FFT). Nach der Analyse werden aus dB-Werten Fließkommazahlen zwischen 0 und 1 geformt und von Audio an Visualisierung übergeben. Da eine FFT einen gewissen Programmieraufwand mit sich bringt, haben wir uns entschlossen ein passendes Plugin für das vom Audio-Team verwendete Programm Reaktor zu finden. Wir fanden das Plugin ezFFT aus der userlibrary3. Wir haben in Reaktor eine Schnittstelle implementieren können, die den Audioausgang mittels FFT analysiert, in eine von uns festgelegte Anzahl an Bändern zerlegt, normiert und via Reaktor-Funktion oscSendArray eine OSC-Nachricht mit mehreren float-Werten ausgibt. In den letzten Phasen der Entwicklung hat sich im Audio-Teil einiges geändert und die Werte, die analysiert wurden, haben keine passende Ausgabe mehr geliefert. Aufgrund von Reaktors Komplexität und fehlender Einarbeitungszeit in den Code des Plugins wird die Audiovisualisierung im folgenden Semester behoben und ausgeweitet.

Dummy

Bevor die Audioschnittstelle funktionsfähig war musste die visuelle Komponente getestet werden. Passend dafür war der ofxSoundPlayer, der eine Sounddatei lädt, diese abspielt und mithilfe der Methode ofGetSoundSpectrum die FFT-Funktionalität umsetzt.

Helper-Klassen

Einige Funktionalitäten sind mehrfach im Code aufgetreten, weshalb es Sinn machte, diese auszulagern und als Helper-Klassen zu implementieren. Die eine ist die Klasse animation, die eine Variable als Referenz annimmt und mittels der ebenfalls übergebenen Parameter diese gleichmäßig von einem Wert zum anderen animiert. Einstellungsmöglichkeiten sind hier die Dauer der Animation, in Schleife abspielen und die easing-Funktion, von denen zwei in der Helper-Klasse easing definiert sind.


Konzept

Hauptaufgabe des neuen Konzepts war die Gestaltung des Weltraums. Es wurden Avatare und Objekte in 2D für das Tablet entworfen, sowie 3D Versionen für die Wandvisualisierung.

Die ersten Skizzen zu unseren Avatar 1 wurden sehr genau gefasst. Eigenschaften wie rustikal und kantig beschrieben diesen. Auch eine Farbpalette legten wir an. Die Töne sollten in ein braun sowie in dunkle Farben gehen.

Die Objekte wurden ebenfalls genau aufgeführt. Wichtig hierbei war die Ansicht in 2D und 3D. Die Anzahl der einzelnen Elemente war genauso ausschlaggebend. Farben hierzu legten wir erst später fest. Allerdings überlegten wir uns schon passend dazu, welche Sounds man abspielen könnte. Die neuen Sounds sollten ausgelöst werden, wenn der Nutzer mit dem Objekt kollidiert. So war es also auch wichtig schon beim Konzipieren an die Verwendung zu denken. Futuristisch, klar und abstrakt sollten die Objekte werden.

Die Avatare sollten sich auf einer Art Insel oder einem Felsbrocken bewegen. Im Hintergrund sollte man das weite Weltall mit seinen Sternen erblicken. Ein Raumschiff begrenzte an den Ecken das Bild.

Ein Hintergrund wurde für die Visualisierung erstellt – Eine Textur des Alls mit einigen Sternen. Avatare, Objekte und das Raumschiff als 3D Modelle in Blender wurden erstellt. Ein Felsbrocken als Fläche wurde umgesetzt. Dieser wurde in Open Frameworks eingefügt. Einige Kometen, die sich um den Felsbrocken bewegen, wurden ebenfalls animiert.

Endprodukt

Vordergrund

Raumstation mit Blick auf Kometen

Für die Visualisierung sollte ein Raumschiff als Begrenzung, als eine Art Rahmen, dienen. Somit waren hier keine Grenzen gesetzt und wir erstellten ein futuristisches Innenleben. Die Dreiecke an der Wand sind leicht vorgehoben und sollen das animierte Licht verschieden brechen. In der Mitte steht ein Pult mit einigen Knöpfen und Tasten. Ein großes Glasdach lässt den Nutzer durch das Raumschiff auf den Kometen blicken. Hier findet er sich, als Avatar wieder.

Mittelgrund

Roboter

Roboter

Avatar 1 sollte rustikal und alt wirken. Beide Avatare sind komplett unterschiedlich und sollen dem Nutzer hierdurch vermitteln, welche Figur man besitzt. Für einen kantigen Look begannen wir mit einem halben Würfel und extrudierten ihn. Wichtig war hierbei einen halben Würfel zu verwenden, da dieser mittels dem Modifier „Mirror“ an der Y-Achse gespiegelt werden konnte.

Begonnen wurde mit dem Grundkörper, über den Hals und zum Kopf. Einzelne Elemente, wie die Hände, Füße, Augen und Ohren erstellten wir als eigenes Mesh. Diese wurden anschließend über den Modifier „Boolean“ zum Grundkörper hinzugefügt.

Farbe bekam der Avatar über die Eigenschaft „Material“. Neun verschiedene Farben mit gleichem Shading machen den Avatar aus. Zuerst wurde versucht den Avatar über den UV/Image Editor einzufärben. Leider wurde diese Farbe nicht in der Ausgabe als Objekt-Datei gespeichert. Da der Avatar letztendlich als Collada Datei ausgegeben und über die Eigenschaft „Material“ einfärbte wurde, wurde der Avatar richtig in Open Frameworks angezeigt.

zweiter Roboter

Der zweite Avatar hingegen sollte als Kontrast zum Ersten dienen. Dieser war viel futuristischer geplant, mit weichen Kanten und einem hellem Weiß-Ton. Hier begannen wir mit einer Kugel („Sphere“) und halbierten diese genauso wie beim rustikalen Avatar. Um einen sehr ebenen und weichen Avatar zu erhalten, wurde der Modifier „Subdivision Surface“ mit dem View 3 und Render 4 verwendet. Dies erzeugt zwar sehr viele Vertices, jedoch wirkt die Oberfläche sehr glatt. Anfangs gab es hier noch einige Schwierigkeiten, da die vielen Vertices den Avatar und somit die Dateigröße immer mächtiger machten. Open Frameworks konnte diese große Datei nicht einbinden. Somit verringerten wir den View auf 3 – Anfangs auf 6. Die Knöpfe fungieren bei diesem Avatar wieder eigenständig.

Da der Avatar futuristisch und „neu“ wirken sollte, wählten wir die Farbe Weiß aus. Um dem Körper eine glänzende Oberfläche zu verleihen, stellten wir unter den Material Eigenschaften den Wert „Specular“ auf 1.0. Durch die Erhöhung der Härte bekam der Glanz schärfere Kanten und hebte sich mehr von dem weißen Grundton ab.


Objekte

Um ein Ineinandergreifen der Tablet-Oberfläche und der Visualisierungs-Oberfläche zu garantieren, mussten sich die Elemente des Tablets und die Elemente der Visualisierung ähneln. Wir entschieden uns die Elemente in der Visualisierung dreidimensional darzustellen und die Elemente auf dem Tablet zweidimensional abzubilden, da es sich bei dem Tablet und eine Draufsicht der Visualisierung handelt. Die Visualisierungselemente wurden in Blender erstellt und als 3D-Elemente in das Visualisierungsprogramm eingebaut. Die 2D Elemente wurden in Illustrator erstellt. Hier die finale 2D Version der App Applikation:

Finales Design der Tablet Elemente
vier Objekte, erstellt mittels Blender


Diese Elemente konnten dann mit Blender in 3D realisiert werden. Verschiedene Farben in den Farbpaletten blau, lila und türkis, rundeten die einzelnen Objekte ab. Die ersten zwei Objekte erhielten außerdem noch eine leichte Transparenz. Zum einen beim Zylinder, damit die anderen Ringe noch gut sichtbar waren und zum anderen bei den Kugeln der umfassende Kreis, um diese durch scheinen zu lassen.


Asteroid

Der Asteroid

Die Erstellung eines Asteroiden wurde mit der Light Version von Cinema 4D in Angriff genommen. Über die Einstellung von Landscape und Spherical wurde ein realistischer Asteroid erstellt. Doch leider bot sich in der Light Version von C4D keine FFT-Funktion um den Asteroiden angemessen zu verformen. Im Weiteren wurden verschiedene Materials erstellt und beleuchtet.

Erst im Nachhinein ist uns aufgefallen, dass in der C4D Light Version kein Export in .obj oder ein ähnliches Dateiformat vorgenommen werden kann. Der Asteroid konnte somit nur zur Videoerstellung in AfterEffects verwendet werden. Der Visualisierungs-Asteroid wurde im Nachhinein in Blender erstellt und in das Projekt eingefügt.

Die Modellierung des Hauptasteroiden sowie weiterer kleiner Asteroiden erfolgte dann in Blender. Ein einfacher Würfel als Grundlage wird segmentiert und die Vertices wurden randomisiert verschoben. Mittels des Subdivision-Surface-Modifier, der ein Mesh verfeinert, also abrunden, bekam der Würfel eine ovale Form, die der Grundform eines Asteroiden bereits nahekommt. Im nächsten Schritt wurden Details eingefügt, die für Krater und Unebenheiten sorgten. Für solche Unebenheiten verwendet man Texturen, die als Heightmap oder als Displacement-Modifier verwendet werden. Die Form war zwar korrekt, doch beim Rendern oder beim Verschieben von Lichtquellen fiel auf, dass die Beleuchtung nicht korrekt war. Um die einzelnen Komponenten des Phong-Shadings übersichtlicher einzustellen wurden Blenders Renderer – Cycles – benutzt und in der Node-Ansicht das Material eingestellt. Hier haben neben den Lichtanteilen noch diverse Texturen Einsatz gefunden, die als Normal-, Bump- oder Specularmap dem Objekt realistische Beleuchtung und somit ein zufriedenstellendes Shading verleihen.


Hintergrund

Die Erstellung eines Weltall-Hintergrundes für den Spiegelraum gestaltete sich mit Adobe Photoshop als sinnvoll. Nach der Erstellung verschiedener Ebenen, mit unterschiedlich stark rauschenden Filtern wurde für eine feinere Optik und ein Leuchten der Sterne, auf jeder Ebene zusätzlich ein Gaußscher Weichzeichner verwendet. Um die Sterne nicht nur einfarbig, sondern mehrfarbig leuchten zu lassen, wurde eine bunte Ebene auf die vorhandenen Sterne gelegt.

Eine weitere Ebene wurde für “Space-Wolken” genutzt, die mit dem Wolken-Filter gezeichnet wurden. Fluss und Deckkraft wurden verringert, um ungleichmäßige Wolken zu erzeugen. Der Hintergrund wurde in verschiedenen Farbabstufungen erstellt. Von den Farbtönen Blau, Lila und Orange, bis hin zum sehr abgeschwächten, fast farblosen Beispiel.

Die zusätzliche Modellage einer etwas gedeckten Version wurde zum Ausprobieren angelegt, da die leuchtenden Farben gegebenenfalls ablenken hätten könnten. Wir entschieden uns letztendlich für den leuchtenden Hintergrund, weil dieser ein guter Mittelweg war, um nicht ablenkend zu wirken und nicht zu sehr unterzugehen.

Videogestaltung

Introvideo

Das Show Interactive Introvideo sollte einen Show Effekt liefern. Wir entwarfen hierfür ein passendes Storyboard. Uns war wichtig, dass wir mit dem Introvideo eine kurze Vorgeschichte zu unserer Anwendung erzählen können. Da es absurd ist, plötzlich in einem Raumschiff zu stehen und durch einen Avatar repräsentiert zu werden, sollte zuerst die Erde explodieren und daraus ein Komet hervorgehen. Auf diesem Kometen landet dann unser Raumschiff und wir erblicken unseren Avatar.

Das Video wurde mit After Effects erstellt, einer Compositing- und Animationssoftware des Herstellers Adobe Systems. Mit der Software lassen sich Filmaufnahmen mit computergenerierten Bildern und Effekten zusammenfügen. Weil wir von der Erde natürlich keine echten Aufnahmen machen konnten, wurde das gesamte Video computeranimiert.

Zu Beginn wurde in der Hauptkomposition eine neue Komposition erstellt und mit zwei verschiedenen Texturen belegt: Einer im Internet Lizenzfrei existierenden Erdentextur und einer ebenfalls lizenzfreien Wolkentextur. Mit dem CC-Sphere Effekt, der auf diese Texturen gelegt wurde, formte sich aus den flachen Texturen ein rundes, dreidimensional wirkendes Modell der Erde. Mit Hilfe einer neu hinzugefügten Kamera in der Hauptkomposition, ließ sich die Erde animieren. Auch die Wolken-Textur in der Teilkomposition wurde über den Effekt „Motion Tile“ so animiert, dass sich die Wolken etwas schneller bewegen als die rotierende Erde. Dies stellte einen realistischen Bezug zur Wirklichkeit dar.

Durch das Anwenden von verschieden großen und verschieden farbigen Licht- und Leuchteffekten auf unterschiedlichen Ebenen des Erdmodells, wirkte diese nochmals realistischer. Die Erstellung eines zweiten Planetenmodells, dem Mond, gestaltete sich wie das erste Modell, lediglich mit anderen Texturen. Der Weltall-Hintergrund wurde aus der Visualisierung übernommen und in After Effects nachträglich bearbeitet. Mit Kurven und Farbeffekten wurde der Hintergrund optisch an die Stimmung der Erde angepasst. Mit dem Effekt Fratales Rauschen wurde mithilfe einer Maskenebene ein „Space Nebel“ kreiert, der zusätzlich animiert wurde. Während sich der Asteroid auf die Erde zubewegt, wurde zur Dramatisierung dieser Szene ein Bildflattern eingebaut. Dieses wurde mit Hilfe einer schwarzen Ebene erzeugt, deren Denkkraft je nach Frame auf 100% oder 0% gesetzt ist. Durch das ständige wechseln der Deckkraft entsteht das flackern. Um die Explosion zu erzeugen, wurde das Modell der Erde inklusive Animation exportiert und als Video neu in die Komposition eingebaut. Auf dieses Video wurde der Effekt Zertrümmern gelegt, um eine optische Explosion zu erzeugen. Zusätzlich wurden im Hintergrund und beim Einschlag des Asteroiden drei Green Screen-Explosionen eingebaut.

Die Druckwelle nach oder während der Explosion wurde in einer neuen Komposition erstellt. Hierfür wurde ein einfacher, orangener Rand einer Farbfläche erzeugt und durch Veränderung der Materialoptionen zum Leuchten gebracht.

Der Show Interactive Teil wurde ebenfalls mit After Effects erstellt und nachträglich in das Explosionsvideo eingefügt. Um unser Logo repräsentativ zeigen zu können, animierten wir dieses, wie es sich selbst malt – oder auch „aufbaut“. Mittels Adobe After Effects legten wir den Hintergrund des Plakates auf eine neue Komposition. Außerdem erstellten wir verschiedene Formebenen. Einige sollten Kreise, Linien oder ein Ladebalken sein. Indem wir die Pfade trimmen ließen, konnten wir einstellen, wann sie angezeigt werden sollen und wann nicht. Eine Linie sieht nun so aus, als würde sie gerade gezeichnet werden - Ein Ladebalken füllt sich. Dieser Effekt wurde auf einige der Elemente aus dem Logo und auf weitere Formebenen angewendet, die zusätzlich in After Effects erstellt wurden.

Die bereits erstellten Linien des Logos in Adobe Illustrator wurden als Pfade importiert und somit war es möglich jede einzelne Linie zu animieren. Durch das Spiel von Transparenzen auf manchen Ebenen leuchten diese erst gegen Ende der Komposition auf. Zudem animierten wir ein Bildflackern. Dies wurde durch das Herabsetzten der Deckkraft der jeweiligen Ebenen (Hintergrundebene und Zeitstrahl) von 100% auf 0% erreicht. Durch die hektische Abwechslung der Deckkraft entsteht solch ein Flackern.

Weitere Drehungen der Zahnräder oder die Bewegung des Reglers des Mischpultes rundeten die Animation ab.

Um das Videoprojekt zu codieren, nutzten wir den Adobe Media Encoder. Mit dem Programm konnten wir eigene benutzerdefinierte Codierungsvorgaben einstellen. Die erste Wahl fiel auf den H.-Standard H.264 zur Videokompression mit einer Auflösung von HD720p 25, die sich aus Zeilenzahl, Bildaufbau und Bildwiederholrate zusammensetzt.

App Entwicklung

Um ein weiteres interaktives Element in unser Gesamtsystem einzubauen, entschlossen wir uns, ein Tablet mit einzubringen. Passend zum Thema sollte dies die Kommandozentrale des Raumschiffs werden. In dieser sollten Elemente gelegt werden können, die dann in der ebenfalls in der Visualisierung auftauchen und bei Kollision mit einem Nutzer in der Trackingfläche einen Sound abspielen.


App Design

Entwurf

Finales Design der App

Zunächst gestalteten wir einen Entwurf mit den drei Views. Ein Start-Screen, welcher die Applikation startet, ein Ladebildschirm, welcher während des Intro Videos zu sehen sein sollte und der Spielbildschirm, welcher die Hauptanwendung enthält. Im Entwurf wurde eine ausklappbare Sidebar eingebaut, die nach Berührung einzelnen Elemente anzeigt. Der Spielbildschirm wurde im Gegensatz zur Visualisierung in der Vogelperspektive gezeigt. Somit ist das Spielfeld auch gleichzeitig die Trackingfläche, was später in der Umsetzung wichtig war, da die Position, auf der das Objekt abgelegt wird, auch der tatsächlichen Position in der Trackingfläche entspricht.

Finales Design

Das finale Design ist den Vorgaben des Entwurfes sehr nah. Der Startbildschirm entspricht bis auf Schriftart und Hintergrundbild genau den Vorgaben. Der Ladebildschirm entspricht genau den Designvorgaben aus dem Entwurf. Auf dem Spielbildschirm hat sich jedoch einiges getan. Zunächst wurde der Hintergrund angepasst. Dieser entspricht nun genau der Draufsicht des Asteroiden in der Visualisierung. Die Symbole wurden komplett geändert und entsprechen der Draufsicht ihrer zugehörigen 3D-Ansichten in der Visualisierung. Die Sidebar ist nun doch nicht ausklappbar. Dafür ist Platz für ein viertes Element entstanden und die Abgrenzung zwischen Spielfeld und Sidebar ist klarer. Zudem ist in der finalen Version der App das Display in Sidebar und Spielfeld geteilt und die Positionsdaten werden nur aus dem Spielfeld bezogen.


Vorbereitung des Tablets

Auswahl des Betriebssystems

Bevor mit der Umsetzung der App begonnen werden konnte, mussten wir und dafür entschieden, welches Tablet verwendet werden sollte. Da uns kein Apple iPad zur Verfügung stand, entschieden wir uns, ein Android Gerät zu verwenden. Weil es wichtig war, ein reines Android ohne Drittanbieter-Applikationen zu verwenden, welche eventuelle Performance beeinträchtigungen mit sich bringen hätten können, informierten wir uns, welche Geräte die Hochschule zur Verfügung stellt. Wir entschieden uns für ein Nexus 10 Tablet. Es war das einzige Tablet mit nativem Android. Die Betriebssystemversion war allerdings sehr veraltet. Deshalb hat entschlossen wir, ein neues Betriebssystem darauf zu installieren.

Installation von LineageOS

Unsere erste Wahl war die Open Source Custom-Firmware Cyanogenmod. Diese ist weit verbreitet. Leider war es nicht möglich diese zu installieren, da Cyanogenmod eingestellt wurde. Jegliche Downloads wurden aus dem Netz genommen. Dennoch gab es eine Alternative die auf Cyanogenmod basiert und von den gleichen Verantwortlichen gewartet wird. Die Custom-Firmware LineageOS[6]. Es basiert auf reinem Google Android und wird ohne Google Apps ausgeliefert. Aus praktischen Gründen sollten die Google Apps dennoch installiert werden.

Um das neue Betriebssystem auf das Tablet zu installieren[7] musste das Gerät im Downloadmodus gestartet werden. Mit der ADB kann das Gerät über die Konsole angesprochen werden. Nun musste das TWRP Recovery Menü installiert werden. Risiko, das Gerät beim Aufspielen des neuen Betriebssystems kaputt zu machen, ist nicht gerade gering und sollte daher mit größter Vorsicht nach genauen Anweisungen geschehen. Fehlen diese, können einige Funktionen nicht verwendet werden und würden das Entwickeln einer Applikation sehr erschweren. Anfangen würde dies beim Webview welcher meist auf Google Chrome basiert. Die Dateien und Tutorials sind auf dem beigelegten Datenträger zu finden. So konnte nun das Tablet auf die sehr aktuelle Android Version 6.0.1 aktualisiert werden. Das sollte auch andere Komplikationen gleich im Vorhinein vermeiden.

Möglichkeiten der App Entwicklung

Vor dem Beginn der Umsetzung galt es, eine geeignete Programmiersprache mit geeigneter Entwicklungsumgebung zu finden. Hierfür gab es eine Auswahl an verschiedenen Möglichkeiten: Die native App-Entwicklung via Android-Studio; die Umsetzung der App mit OFX samt anschließender Kompilierung in eine native Android-Applikation über ein bestimmtes OFX Plug-In; die Umsetzung mit Angular 3 und Cordova (JS Framework + Container) im Raum oder aber die Verwendung von Ionic 3 (JS Framework für mobile Applikationen). Im Folgenden werden die vorangestellten Programme kurz aufgeführt:

Android Studio

Android Studio ist die offizielle Entwicklungsumgebung von Google. Es ist eine frei integrierte Entwicklungsumgebung (IDE) und basiert auf der IntelliJ IDEA Community Edition. [8] Mit Android Studio sind wir in diesem Semester in dem Kurs Multimediaapplikationen vertraut geworden. Es wird zur nativen App Entwicklung verwendet.


Open Frameworks + Plug-In

Die Android Erweiterung für Open Frameworks wurde eingerichtet um mit der Eclipse IDE oder experimentell mit der neusten Android Studio IDE zu arbeiten[9]. Die Projekte verwenden derzeit eine benutzerdefinierte Toolchain, die auf Makefiles basiert. Diese wird verwendet um die Anwendung zu kompilieren. Diese Variante hätte den Vorteil, dass das selbe Plug-In für OSC verwendet werden könnte wie bereits in der Tracking Anwendung implementiert.

Angular3

Angular3 ist ein JavaScript Framework welches die Typescript Erweiterung verwendet. Es ist Front-End basierend und unterstützt das asynchrone Laden einzelner Elemente in einer Webanwendung. Mit diesem Framework ist es einfach Webapplikationen zu entwickeln.

Cordova

Cordova ist ein nativer Container, welcher Webanwendungen als Native App für Android oder iOS verpackt[10]. Cordova kann auf Gerätefunktionen zugreifen, weshalb es in Verbindung mit Angular3 eine gute Möglichkeit darstellt, Applikationen für Mobilgeräte nur mit Hilfe von Web Sprachen zu entwickeln.

Ionic3

Ionic ist ein Framework zur Entwicklung von Hybrid Apps aus der Basis von HTML, CSS oder Sass und JavaScript bzw. Typescript. Es basiert auf Angular und Cordova. Dabei werden Ionic eigene Komponenten bereitgestellt mit denen die App Entwicklung sehr unterstützt wird[11]. Der Fokus liegt hier genauso wie bei Angular auf dem Front-End, also der Benutzerschnittstelle.

Auswahl der Programmiersprache

Wir entschlossen uns die Applikation mit Ionic3 zu entwickeln. Ionic hingegen hat den Vorteil, dass HTML, CSS und JavaScript verwendet werden kann. So ging die Entwicklung sehr schnell voran.

Auswahl des Übertragungsprotokolls

Eine Frage, die auch schon ziemlich zu Beginn geklärt werden musste war, welches Protokoll zur Übertragung der Daten an die CoreLogic verwendet wird. Naheliegend wäre es gewesen, die Daten per HTML Protokoll als JSON an einen Websocket zu übergeben, welcher mit der CoreLogic in Verbindung steht. Da aber im gesamten System nur per OSC kommuniziert wurde musste eine Lösung gefunden werden um auch aus unserer Anwendung heraus OSC-Daten zu senden, da sonst in der CoreLogic wieder einiges hätte geändert werden müssen.

So haben wir das Cordova-Plug-In „cordova-plugin-chrome-apps-sockets-udp”[12] und das NPM-Package „osc.js”[13] gefunden. Unsere Tests damit waren erfolgreich und so konnte die weitere Entwicklung voranschreiten.


Entwicklungsumgebung: Atom

Die Umsetzung der App mit Ionic hatte eine vorgegebene Projektstruktur. In dieser werden verschiedene Pages hinzugefügt. Das Hinzufügen der Pages wurde über die Ionic-CLI implementiert. So konnten wir über einen Konsolenbefehl die verschiedenen Pages hinzufügen. Um in der laufenden Anwendung zwischen den Pages wechseln zu können, müssen gewisse Abhängigkeiten eingetragen werden. Das fällt bei dem Erstellen der Pages mit der Ionic-CLI weg und garantiert funktionsfähige Grundbausteine. Jede der Pages besteht aus drei Teilen. Einer HTML-, SCSS- und TS-Datei. HTML und Scss bestimmen das Aussehen der Page während die TS-Datei die Logik, also den Typescript-Code enthält. Im Folgenden wird näher auf die einzelnen Pages eingegangen.

Umsetzung

Die Umsetzung der App mit Ionic hatte eine vorgegebene Projektstruktur. In dieser werden verschiedene Pages hinzugefügt. Das Hinzufügen der Pages habe ich über die Ionic-CLI gemacht. So konnten wir über einen Konsolenbefehl die verschiedenen Pages hinzufügen. Um in der laufenden Anwendung zwischen den Pages zu wechseln zu können, müssen gewisse Abhängigkeiten eingetragen werden. Das fällt bei dem Erstellen der Pages mit der Ionic-CLI weg und garantiert funktionsfähige Grundbausteine. Die Projektstruktur ist rechts zu sehen. Jede der Pages besteht aus drei Teilen. Einer HTML-, SCSS- und TS-Datei. HTML und Scss bestimmen das Aussehen der Page während die TS-Datei die Logik, also den Typescript-Code enthält. Im Folgenden wird näher auf die einzelnen Pages eingegangen.

homePage

Der gesamte Inhalt ist zusammengefasst in einem Ionic-spezifischen ion-content. Die Inhaltskomponente bietet einen einfach zu bedienenden Inhaltsbereich mit einigen nützlichen Methoden. In diese Komponente wurde der Hintergrund eingebettet. Ein div innerhalb des ion-content enthält den Start Button, der bei Betätigung ein Signal zum Starten des OSC Services sendet.

Die Gestaltung des Screens wurde durch scss-Klassen optisch ansprechend dargestellt und möglichst nahe am Entwurf gehalten. Die Klasse .startbutton zeichnet den Startbutton rund und entsprechend groß, um sich gut in das Gesamtbild einzufügen. Die graue Hintergrundfarbe wurde ebenfalls an das Design des Entwurfs angepasst. Beim Betätigen des Start-Buttons auf der Oberfläche wird die Klasse .startbutton:hover aktiviert und so ein Effekt über den Button gelegt. In der Klasse .text werden alle geplanten Text Formatierungen angelegt und angewendet. Wie zum Beispiel die font-size, text-align und letter-spacing. Der Hintergrund wird über url("../assets/pictures/background.jpg") in das Programm geladen, der erst nach dem beseitigen eines überflüssigen ../ richtig dargestellt wurde.

Nach dem Import der nötigen Seiten und Dateien, wurde in der Funktion startSystem() festgelegt, das nach dem Drücken des Buttons, die nächste Seite, die loadingPage geladen werden sollte. Zudem wurde von hier aus die OSC-Signalübertragung gestartet.

loadingPage

Die loadingPage wurde mit der Intention angelegt, dass während des Abspielens eines Intro-Videos, welches vor der eigentlichen Anwendung gezeigt wird, der playground nicht gestartet werden kann. Somit ist es während des Intro-Videos auch nicht möglich, Elemente in der Anwendung zu setzen. Erst nach einer vorgegebenen Ladezeit beginnt die eigentliche Anwendung. In einem eigenen ion-content wird ebenfalls ein einfacher Hintergrund dargestellt. Ein div auf der Seite beinhaltet ein Textfeld. Darunter wird eine horizontale Linie dargestellt. Fünf verschiedenen Klassen werden fünf verschiedenen divs zugeordnet. Diese ergeben die einfache Darstellung der Ladepunkte.

Der Hintergrund wurde schlicht schwarz gehalten. Der loading Text wurde an den Entwurf angepasst.

Jeder Punkt wurden einzeln animiert. Mit jedem Punkt wurde das animation-delay um 0.5s erhöht. Durch das zeitversetzte Einfärben der Ladepunkte in weiß und schwarz macht es den Anschein, als würde der Bildschirm laden. Dieser Screen wurde erzeugt, um einen ansprechenden Effekt zu erzeugen und den playground vor Spielbeginn zu schützen.

Auf der LoadingPage wurde alles sehr einfach und schlicht gehalten, um die Modernität des Weltalls darzustellen. In der loading.ts wurde die Zeit festgelegt, welche die LoadingPage bestehen bleiben sollte. Nach 40.000ms, die der Länge des Videos entsprechen, sollte der Benutzer automatisch auf die playgroundPage weitergeleitet werden. Dieser Vorgang wurde in drei Funktionen umgesetzt.

playgroundPage

Der Playground ist die eigentliche Bedienoberfläche der Anwendung. Sie ist in zwei Hälften geteilt. Das Spielfeld und die Sidebar. Um das Spielfeld herum befindet sich ein Wrapper, der dieses umschließt. In der Sidebar, die sich auf 25% des rechten Spielfeldrandes ausdehnt, befindet sich ein Textelement sowie vier div Elemente, welche die Spielelemente für unser Programm beinhalten. Zwischen den beiden Feldern befindet sich eine vertikale Linie zur Abgrenzung dieser.

Der wrapper wird unter anderem über die Eigenschaften display, justify-content, sowie hight und width festgelegt. Die Sidebar wurde ähnlich angelegt. Über die Klasse .sidebar:after, wurde der Hintergrund in der Sidebar verändert, jedoch sorgte dies für eine Verzögerung in der Bewegung der Elemente. Der Hintergrund wurde deshalb mit Photoshop bearbeitet und somit abgegrenzt. Die Elemente in der Sidebar, wurden wie der Startbutton rund dargestellt und mit zusätzlichen Bildern geschmückt. Der Hintergrund wurde wie der Startseitenhintergrund eingebunden.

In der playground.ts wird der eigentliche technische Hintergrund der Applikation realisiert.

Elemente aus der Sidebar sollten via Drag and Drop in das Spielfeld gelegt werden können. Nach dem Setzen der Objekte sollten diese nicht mehr bewegt werden können, bis diese durch eine Kollision wieder zurück in die Sidebar katapultiert wurden. Innerhalb der Sidebar sollten Elemente nicht gelegt werden können. Bei einem Versuch, ein Element in die Sidebar zu legen, wird dieses automatisch zurück an seine ursprüngliche Position gezogen.

Für die Drag and Drop Funktion, die es ermöglichen sollte, Elemente im Raum zu setzen, wurde zunächst im Internet recherchiert. Im Zuge der Recherchearbeiten wurde dann der erste Versuch “Dragular” einzubinden unternommen. Dies erwies sich allerdings als nicht geeignet für unser Projekt.

Die Funktionsweise sieht vor, dass jedes Objekt nur einmal gelegt werden kann. Sobald das Objekt gesetzt ist, kann es nicht mehr verschoben werden.

Um die Applikation für den Anwender so zu gestalten, dass nicht auffällt, dass diese auf einem Tablet läuft, musste die Applikation im Fullscreen-Modus laufen.

OSCService

Um unsere Daten an das Tracking übermitteln zu können, wurde die Bibliothek osc.js von Christian Weichert eingebunden. Dabei trat zunächst allerdings ein Fehler auf.

Christian erstellte einen OSC-Service, in dem die osc-chromeapp.js eingebunden wurde. Da Ionic im Grunde eine Webanwendung ist, welche in einem nativen Container für Android liegt, der nur einen Webview anzeigt, musste die chromeapp verwendet werden. Diese spricht über ein Cordova-Plugin die native Funktion der UDP-Ports an. Jedoch gab es nach der Einbindung des OSC-Service einen Fehler, der die App zum Absturz brachte. Nach einigen Tests konnte der Fehler leider zunächst nicht behoben werden.

Nach weiterer Recherche und Auswertungen der Consoleerrors konnte der Fehler im OSC-Service später jedoch ausfindig gemacht werden. Der Fehler wurde durch eine fehlerhafte Referenz in der osc.js Bibliothek verursacht. Dieser wurde wie Folgt behoben: Unter node_modules/osc/dist/osc-chromeapp(.js) wurde nach ../ gesucht und durch ./ ersetzt. Die referenzierte Datei befindet sich in demselben Ordner und nicht eine Ebene darüber.

OSC wurde durch statische IP-Adressen und Ports festgelegt. Die Struktur der OSC-Nachrichten stand fest und das Senden von Test-Daten an die CoreLogic funktionierte einwandfrei.

GIT Repository

Um einen guten Überblick über unser Projekt sowie die Änderungen des Codes zu behalten haben wir ein GIT Repository auf BitBucket erstellt. Durch die richtige Arbeit mit GIT konnte auf verschiedenen PCs gearbeitet und Fortschritte immer abgeglichen werden. Zudem wäre es möglich gewesen, eine ältere Version des Projektes wiederherzustellen.

Aufbau

Aufbau Prototyp

Für einen reibungslosen Ablauf unserer Visualisierung war eine stabile Infrastruktur nötig.

Hardwareaufbau

Unsere komplette Datenkommunikation erfolgte über Ethernet. Dies hatte mehrere Vorteile für uns. Zum einen konnten wir unseren Visualisierungslaptop mit dem des Trackings lokal über einem Router mit integrierten Switch verbinden. Da der Audiolaptop keinen Ethernetanschluss ohne Adaptierung anbot, wurde dieser über eine Wireless LAN Verbindung verbunden. Der Beamer wurde ebenfalls mittels HDMI to Ethernet angebunden.

Für unseren Prototypen wurden einige LED PAR Lampen und professionelle Movinglights eingesetzt. Diese sollten zunächst eine Ambiente Lichtstimmung erzeugen.

Die PAR Scheinwerfer wurden überwiegend an den Deckentraversen im Labor angebracht. Dies hatte den Vorteil, dass man aus einer gewissen Distanz zum Boden, mit wenigen Scheinwerfern eine flächige Ausleuchtung erzielen. Die Ansteuerung der Scheinwerfer erfolgte nun über eine DMX Software welche mittels eines USB Interfaces von einem Laptop aus gesteuert werden konnte.

Für die Präsentation unserer Show Interactive hatten wir die komplette Fläche des Media Labs im BB Gebäude Erdgeschoss zur Verfügung. Wir haben mit schwarzem Bühnenmolton und Alu Pipes die wir an den bestehenden Alu Traversen angebracht haben den Raum für die Besucher zu einem anregend „Messestand“ umfunktioniert. Die ambietene Raumbeleuchtung hat das ganze stimmungsvoll abgerundet.

Aufbau Endprodukt

LED-Stripes

Die Trackingfläche sollte nun eine Begrenzung durch LED-Stripes erhalten. Da diese nicht einfach auf dem Boden angebracht werden konnten, musste hierfür ein Schacht, durch den das Licht scheinen kann, angefertigt werden. Auch sollte das Tablet in einer Art Pult befestigt werden. Um die Trackingfläche noch weiter zu verschönern, sollten futuristische, beleuchtete Dreiecke an jeder Ecke der Fläche stehen.

Der Boden der Installation sollte mit den Besuchern interaktiv reagieren, hierzu war die Idee, dass die LED Stripes auf die Bewegung reagieren könnten. In der ersten Phase der Planung überlegten wir wie es zu schaffen sei die LED Stripes möglichst stabil und geschützt vor den Besuchern am Boden anzubringen und zusätzlich noch Akzente fürs Gesamtbild setzten zu können. Daraus ergaben sich dann zwei getrennte Bereiche der Visualisierung die im Nachfolgenden beschrieben werden. Mit Bodenvisualisierung ist der Bereich um die Trackingfläche gemeint. Zum einen soll der Besucher ohne große Erklärung erkennen können wohin er sich begeben muss um Teil des Interaktiven Erlebnisses werden zu können zum anderen soll die Bodenvisualisierung Anreiz schaffen sich mehr im leeren Raum zu bewegen. Das Ganze erfolgte über WS2810b LED Stripes, welche im Vergleich zu den „Handelsüblichen“ LED Stripes aus dem Baumarkt einzeln ansteuerbar sind. Das heißt man kann zu jeder Zeit t einen Punkt x auf dem Stripe ansprechen. Für unser Konzept war dies enorm wichtig, da der Besucher am Rand der Trackingfläche eine farbliche Markierung sehen sollte die seine Bewegung beschreibt und diesen „verfolgt“.

Die LED Stripes wurden in vier Segmente unterteilt. Es gab für jede Seite einen Stripe mit eigenem Netzteil und eigener Steuereinheit. Damit die LED Stripes besser vor den Besuchern geschützt waren, haben wir aus einfachen kleinen Kabelkanälen, eine Art Lichtschacht gebaut. Im Deckel des Kanals wurden große Segmente entfernt, und mit derselben diffusen Folie wie die Ecken beklebt. Diese brach das Licht ein wenig, um dieses nicht ganz so stark gerichtet wirken zu lassen.

Die „Eckvisualisierung“ sollte ein weiteres Feature zusätzlich zur Verfolgung der Besucher werden. Dafür haben wir Pyramidenartige Holz/Acrylglas Elemente entworfen und gebaut, welche die jeweilige Ecke der Trackingfläche symbolisierten. Diese wurden auch mit einem LED Stripes ausgestattet, welcher von innen heraus die Diffuse Oberfläche des Acrylglases beleuchten sollte. Zusätzlich sollte in den Ecken auch die Stromversorgung für den LED Stripes und der Ecke sitzen. Hier wurde dann in Handarbeit eigene Steckverbindungen für die Stromversorgung und die Signalführung gelötet. Die Holzecken bekamen mit Silberner Sprühfarbe einen metallischen Look der mehr in das Weltraumthema passen sollte. Der Sinn dieser Eckvisualisierung war recht trivial. Diese dient im Wesentlichen zur Beleuchtung des Bodens. Wir habe uns auf die Farbe Weiß geeinigt, und die LEDs auf 50% ihrer Helligkeit betrieben. Im Falle einer Kollision auf der Trackingfläche haben wir so noch ausreichend Luft nach oben, um diese optisch zu untermalen, indem die Ecken und Stripes kurzzeitig bei 100% aufblitzen.


Steuerung

Hardware zur Software

Ich gehe hier kurz auf den die technischen Details ein:

Material:

4x Node MCU (Arduino-Nachbau)

4x LED-Stripes Adafruit NeoPixel

4x Netzteil 5V

Holz, Folie, Plexiglas, Schrauben u.v.m. (zur Dekoration der Ecktürme) Kabelschächte mit Sichtfenstern (zum Schutz der Stripes am Boden)


Umgebung:

Show Interactive Systemkomponenten - insbesondere WiFi-Netzwerk Implementierung der Steuerung in die CoreLogic und zur Evaluation in der Trackingsoftware.


Tool: Mac für die IDE und zum flashen der Minirechner Die Steuerung der Stripes wird per OSC-Nachricht in der CoreLogic und in der Tracking-Software erzeugt und an die vier Mini-Rechner übermittelt.


Software-Entwicklung

Als Entwicklungsprogramm wird vom Hersteller der LED-Stripes die IDE ATOM1.18.0 x64 empfohlen und mit Tutorials unterstützt. Das Arduino Framework Platformio for Arduino wird installiert und um die folgenden Addons/Libraries erweitert:


• Arduino-Treiber (Arduino.h) - der verwendete Node MCU Mini-Computer ist baugleich zum Original Arduino und kann mit dessen Treibern angesteuert werden.

• Die NeoPixel Bibliothek (Adafruit_NeoPixel.h) enthält Treiber und Steuerfunktionen für die LED-Stripes.

• Die Netzwerk Setup Bibliotheken von Platformio (WiFiUdp.h, ESP8266WiFi.h).

• Für den Datenaustausch müssen wir noch die OSC-Bibliotheken (osc.h, OSCMessage.h, OSCBundle.h, OSCData.h) laden, die ebenfalls von Platformio zur Verfügung gestellt werden.


Aufbau / Logik

Die Teile bestehen jeweils aus Turm, Arduino, Netzteil und Stripes. Angeordnet sind sie im Uhrzeigersinn im Uhrzeigersinn. Immer die ersten 40 Pixel sind im Eckturm die nächsten 200 Pixel sind ebenfalls im Uhrzeigersinn ausgerollt zum nächsten Turm. Der Nullpunkt des Koordinatensystems ist aber für alle vier Seiten oben links also ist die Reihenfolge der Pixel im Stripe aufsteigend: oben und rechts – dagegen absteigend: unten und links. Der Radius der beleuchteten Streifen ist abhängig vom senkrechten Wert. So beeinflusst der y-Wert bei den horizontalen Stripes die Breite des Streifens. Die Stripes oben und rechts laufen in derselben Richtung wie das Koordinatensystem. Die x- und y-Werte sind also identisch. Die beiden anderen Stripes unten und links dagegen laufen entgegengesetzt zum Koordinatensystem. Hier müssen wir also mit „x = 1 – x“ und „y = 1 – y“ die Werte umkehren.

Arduino

Als Herzstück unserer LED Steuerung haben wir einen NodeMCU verwendet. Dank des auf GitHub verfügbaren ESP8266 „Core for the Arduino IDE“[14]

Auf diesem ist ein ESP8266 Wi-Fi Soc angebracht, welcher kabellosen Datenempfang möglich macht. Er verfügt über 128kBytes Arbeitsspeicher und 4Mbytes Speicher und wird über USB mit 5V Spannung betrieben. Die USB Schnittstelle dient auch gleichzeitig als Programmierschnittstelle. Für unsere Zwecke war es nötig die OSC Daten des Trackings empfangen und auswerten zu können, um später damit eine zufriedenstellende Interaktion zu gewährleisten. Programmiert wurde der NodeMCU von uns über die Entwicklungsumgebung ATOM, auf welches ich im Folgenden näher eingehen möchte.

Atom

ATOM ist im Wesentlichen ein frei konfigurierbarer Texteditor. Der einzige Grund weshalb wir nicht in der Arduino Entwicklungsumgebung programmiert haben, war die bessere Übersichtlichkeit der ATOM Plattform. Zur Ansteuerung der LEDs haben wir die Adafruit Neopixel Library verwendet. Diese sehr mächtige Library verfügt über einige Example, die uns für den Einstieg in unsere Entwicklung unserer Visualisierungssoftware sehr geholfen haben.

Mit diesem aus der Adafruit Neopixel Library mitgelieferten Example konnten wir die Funktionalität unseres Hardwareaufbaus zunächst testen. Mit #define PIN und #define NUMPIXELS konnte man angeben an welchem Pin der NodeMCU Daten überträgt und wie viele LEDs dahinter hängen welche angesprochen werden.

Ein weiteres Script ESP8266ReceiveBundle.ino zeigt das Standard-Beispiel einer OSC-Verbindung. Aus beiden Scripts entwickeln wir einen Prototypen, der die Ecktürme zunächst einfach beleuchtet. Mit den Stripes wird die Position der Personen auf der Tanzfläche mit einem Streifen von 20 Pixeln angezeigt. Mit Herrn Brendels Hilfe entwickeln wir eine stabile WiFi-Verbindung.

Die ankommenden Nachrichten werden asynchron gespeichert und mit jeden Loop in ein Message-Bundle übertragen. Jetzt können wir uns ganz auf die Ansteuerung der Stripes konzentrieren. Da alle Stripes dasselbe tun sollen, beschränken wir uns auf die Programmierung des Stripes, der entlang zur Wandprojektion ausgelegt ist und vom Arduino oben rechts im Koordinatensystem gesteuert wird. Die anderen 3 Teile des Moduls verhalten sich entsprechend dem ersten, entweder mit vertauschter Pixelrichtung und/oder mit vertauschten x- und y-Werten. Die teils komplizierten Fallunterscheidungen werden von zwei Switch-Weichen übernommen. Man muss nur noch vor dem Flashen der Mini-Computer die ID der jeweiligen Position im Viereck als Zahlenwert von 1 bis 4 festlegen.

Die OSC-Methode wird in jedem Loop ausgeführt. Sie prüft die Länge des Bundles. Und arbeitet bei Bedarf (size > 0) die Nachrichten ab. Je nach Adresse werden sie an die entsprechende Funktion übergeben. Eine Nachricht Adresse „/person“ enthält ID und Positionsdaten eines Besuchers auf der Tanzfläche. Besucher werden als beleuchteter Streifen jeweils senkrecht auf dem Stripe dargestellt. Der Streifen leuchtet auf der näheren Seite jeweils wesentlich breiter als auf der gegenüberliegenden, entfernteren Seite. Genauer gesagt ist die maximale Breite des beleuchteten Bereichs durch eine Variable „radius“ definiert. Wenn der Besucher nahe an einem Stripe ist leuchtet dieser also zweimal so breit wie dieser Wert (1 – y-position * radius x 2 breit; y-position ist definiert zwischen 0 und 1; der Nullpunkt oben links). Wenn er nahe der gegenüberliegenden Seite (hier: unten) ist, dann ist die Breite des oberen Streifens, die ja von 1-y abhängig ist, sehr gering. Wie bereits erwähnt: Für alle vier Stripes ändert sich die Logik.

Kollisions-Ereignisse (Adresse „/collision“) werden durch grelles Aufleuchten des gesamten Teils mit beleuchtetem Eckturm realisiert. Ziel für unsere Bodenvisualisierung war, dass die man einen direkten Bezug von der Bewegung im Raum zu den dargestellten LED Pixeln an der Seite hat. Deshalb sollten je näher man sich den Rand annähert, mehr LEDs Farbig ausschlagen, und mit zunehmenden Abstand, sollte der Bereich kleiner werden. Zusätzlich sollten die LED Pixel die Person „Verfolgen“. Eigentlich hatten wir anfangs die Überlegung zwei „Spielerfarben“ zu benutzen, was technisch auch umsetzbar gewesen wäre. Allerdings war die Trackingsoftware nicht ausgreift genug um bei Kollisionen zweier Personen, die Personen ID nicht Random neu zu vergeben. Um dieses, nennen wir es mal Feature, zu kaschieren, haben wir uns dafür entschieden, dass es nur eine Farbe für beide Personen innerhalb der Trackingfläche gibt. Kurz gesagt: ein eiskaltes Hellblau mit den überraschenden RGB-Werten 150/150/150 passt sich perfekt in den violett-blauen Farbwert der Visualisierung und überzeugt uns. Der Wert wird auf alle Effekte angewendet.

Bis hierhin hatten die Lichtstreifen eine Farbe und Breite. Bei einem Test sahen wir ein Script von Herrn Bär in Aktion. Seine Animation hatte ebenfalls wandernde Streifen.

Diese waren aber von den Seiten her smooth einblendend. Er gab uns den Tipp, die unter Gaußsche Normalverteilung in Wikipedia nachzusehen! Da ist die Formel für eine Glockenkurve.

Die Funktion „gaussIt“ erzeugt einen Lichtstreifen, der anfangs sachte heller wird, dann rasch auf den Maximalwert ansteigt und wieder ebenso rasch absteigt. Am Ende des Streifen werden die Lichter wieder langsam schwächer. Der Funktion werden zwei Werte übergeben: Die x-Position T0 entspricht der Spitze der Glockenkurve. Die x-Position t ist der aktuelle zu berechnende Pixel im Streifen. Vordefiniert ist der Wert _lightradius, der ursprünglich die Breite des Streifens bestimmt. In der Funktion ist er für die Breite der Glockenform zuständig. Die Breite der Glocke soll ja identisch zur Breite des leuchtenden Bereichs sein. Der Wert „versatz“ wird aus den beiden Zahlen auf der x-Achse berechnet (t - T0). Er hat als quadratisches Element den entscheidenden Einfluss auf die Lichtintensität an Position t. Zurückgegeben wird ein Float-Wert zwischen 0 und 1 wieder an die Funktion SetTypeColors, die alle Pixel im Bereich des Streifens durchiteriert und deren aktuelle Farbe prüft. Wenn diese auf #000000 steht wird ihnen jeweils die Farbe (unser kaltes Hellblau) und die Lichtstärke zugewiesen. Gespeichert und ausgelesen werden die Farbinformationen in einem Vektor im Pixels-Objekt.

Die Farben für die ersten 40 Pixel des Stripes werden am Ende des Loops festgelegt und gespeichert. Zuletzt wird geprüft, ob ein Ereignis stattfand. Falls auf der Tanzfläche eine Kollision stattfand, werden alle 240 Pixel für zehn Loops – also eine zehntel Sekunde – voll beleuchtet. Zuletzt werden die gespeicherten Farbinformationen mit dem Kommando pixels.show() auf den Stripe übertragen. Der nächste Loop beginnt (wieder) mit 10 Millisekunden Pause. Mindestens während dieser Pause steht stellt der Stripe die Pixel-Informationen dar, die im vorherigen Loop gestaltet, berechnet und übertragen wurden. Die Werte werden erst geändert, wenn eine neue Nachricht mit einer Personen-Position oder einem Ereignis eintrifft.

Da nun durch das Tablet die Möglichkeit bestand, dass ein dritter Besucher, virtuelle Objekte in den Trackingraum zu legen, hatte sich Arthur Hilbert dafür zusätzliche Sounds überlegt die bei einer Kollision abgespielt werden. Um den gesamt Eindruck für den Besucher zu maximieren, hatten wir uns von der Visualisierung überlegt, dass die LED Stripes am Boden inklusive der Ecke kurzzeitig komplett Weiß aufblitzen.

Installation der Elemente im Raum

Das Design sowie der Aufbau des Raumes und die Installation wurde an zwei Tagen fertiggestellt. Wichtig war es, alles sehr funktional zu gestalten und trotzdem einen Eindruck beim Besucher zu hinterlassen. In den Ecken des Trackingfeldes wurden leuchtende Dreiecke aufgebaut, die die LED-Stipes verbinden sollten. Das Pult sollte passend dazu ebenfalls beleuchtet werden. Hierzu planten wir Plexiglas Ausschnitte. Nach den fertigen Planungen besorgen wir alle nötigen Materialien. Von Kabelkanälen, über Folien bis hin zu Schrauben und Farbspraydosen

Das Grundgerüst für das Pult bildeten mehrere unterschiedlich lange Kanthölzer, welche mit einer Kappsäge auf die Richtige Länge gebracht wurden. Das Tablet sollte zum Benutzer geneigt sein, weshalb wir die vorderen Füße des Ständers kürzer schnitten, um eine ca. 45° Neigung zu erzielen. Als Verkleidung wurden Acrylglasplatten mit unserer Diffusen Klebefolie verwendet. Diese wurden ebenfalls mit einer Heißklebepistole angebracht. Final hatten wir dann keine Vollflächige Acrylverkleidung, sondern zwischen den Holzstreben immer wieder metallische Akzente. Für die Beleuchtung im inneren des Ständers, entschieden wir uns für LED Strahler. Dadurch hatten wir nun die Möglichkeit die Farbe des Ständers über den DMX Bus mit zu steuern. Im inneren des Ständers befand sich eine Mehrfachsteckdose damit man LED PAR und Tablet dauerhaft mit Stromversorgen kann.

Aufbau und Ablauf Show Interactive

Für die Präsentation mussten wir unsere Hardware aufbauen. Zur Verfügung stand uns der Raum BB.008, das Medialab in dem wir zuvor schon unser Programm getestet hatten. Dieses extra für den Studiengang Media Engineering eingerichtete Labor, verfügt über eine Vielzahl von Hilfreichen Einrichtungsgegenständen. Zum einen gibt es eigen Abgesicherte Starkstromverteiler und Fahrbare Traversen unter der Decke, welche eine optimale Arbeitsumgebung für uns boten. Mit Molton, den wir an Traversen aufhingen, dunkelten wir den Raum ab. Hardware wie Kamera, Computer, Lautsprecher und Beamer wurden aufgebaut.

Die „Steuerzentrale“ von „Show Interactive“ wurde hinter dem Trackingbereich aufgebaut, da wir so eine bessere Sicht auf das komplette Szenario halten konnten. Als Projektionsfläche wurde eine Wand vor der Trackingfläche verwendet. Dafür musste ein Beamer eingerichtet werden.

Der Einsatz eines Dunsterzeugers, eines sog. Hazers kam hinzu. Dieser sorgte mit kontinuierlichen Dunst dafür, dass die Lichtstrahlen der Movinglights besser erkennbar wurden. Dieser war für die Intro Lichtshow von großer Wichtigkeit, um den gewünschten WoW-Effekt zu erzeugen. Was als kleines Feature noch hinzukam, war ein Moderationsmikrofon, welches mit einem Stimmeffektgerät, eine Roboterstimme erzeugen konnte. Dies sollte zur leichten Aufheiterung der doch sehr trocknen Präsentation dienen, und war ein voller Erfolg. Da wir durch den enorm großen Einsatz von LED Scheinwerfern, Movinglights und den LED Stripes etc. sehr viel mehr Strom und DMX Kabel als im Semester zuvor brauchten, konnten wir uns extrem glücklich schätzen, dass wir Unterstützung von der Firma LF Medientechnik aus Neumarkt erhalten haben. Mit einer großzügigen Bereitstellung von zusätzlichen Movinglights, Bühnenmolton, und jede Menge Kabel.

Unterstützt durch viele Features und eine PowerPoint Präsentation wurde unser Vortrag erfolgreich absolviert.


Projektpräsentation 2017
Projektpräsentation 2017
Projektpräsentation 2017
Projektpräsentation 2017
Projektpräsentation 2017


Downloads

Quellcode

(nur für registrierte Benutzer der TH)

Einzelnachweise

  1. http://lexikon.martinvogel.de/midi.html, Martin Vogel
  2. https://de.wikipedia.org/wiki/Musical_Instrument_Digital_Interface, Wikipedia MIDI
  3. https://de.wikipedia.org/wiki/Open_Sound_Control, Wikipedia OSC
  4. https://www.youtube.com/watch?v=qE2nq399vt4&t=10s, Youtube Creating a VOSIM Oscillator
  5. https://www.native-instruments.com/en/reaktor-community/reaktor-user-library/entry/show/4453/, native-instruments
  6. http://lifehacker.com/cyanogenmod-is-dead-and-its-successor-is-lineage-os-1790554964, Cyanogenmod und LineageOS
  7. http://www.cyanogenmods.org/forums/topic/official-lineage-os-13-nexus-10-marshmallow-rom/, LineageOS Installation
  8. https://de.wikipedia.org/wiki/Android_Studio, Android Studio
  9. http://openframeworks.cc/setup/android-eclipse/, OFX Plug-In
  10. https://cordova.apache.org/, Cordova
  11. https://de.wikipedia.org/wiki/Ionic_(Framework), Ionic3
  12. https://www.npmjs.com/package/cordova-plugin-chrome-apps-sockets-udp, Cordova-plugIn
  13. https://de.wikipedia.org/wiki/Angular, osc.js
  14. https://github.com/esp8266/Arduino , Arduino