Tangible User Interfaces für interaktive Medieninstallationen am

Tangible User Interfaces für
interaktive Medieninstallationen
am Beispiel Dry Garden MR
Florian Bacher
DIPLOMARBEIT
eingereicht am
Fachhochschul-Masterstudiengang
Digitale Medien
in Hagenberg
im Juni 2006
c Copyright 2006 Florian Bacher
Alle Rechte vorbehalten
ii
Erklärung
Hiermit erkläre ich an Eides statt, dass ich die vorliegende Arbeit selbstständig und ohne fremde Hilfe verfasst, andere als die angegebenen Quellen
und Hilfsmittel nicht benutzt und die aus anderen Quellen entnommenen
Stellen als solche gekennzeichnet habe.
Hagenberg, am 5. Juli 2006
Florian Bacher
iii
Inhaltsverzeichnis
Erklärung
iii
Vorwort
vii
Kurzfassung
viii
Abstract
ix
1 Einleitung
1.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Gliederung der Arbeit . . . . . . . . . . . . . . . . . . . . . .
1
1
1
2 Medieninstallationen
2.1 Überblick über relevante Projekte .
2.1.1 SandScape . . . . . . . . .
2.1.2 Diorama Table . . . . . . .
2.1.3 Augmented Sound Reality .
2.1.4 Rakugaki . . . . . . . . . .
2.1.5 processingLIVE . . . . . . .
2.1.6 Khronos Projector . . . . .
2.1.7 webcam:tracking . . . . . .
.
.
.
.
.
.
.
.
2
2
3
4
5
6
7
7
9
.
.
.
.
.
.
.
.
.
.
10
10
12
12
16
16
17
18
19
19
19
3 Grundlagen
3.1 Kultureller Hintergrund . . . . .
3.2 Tangible User Interfaces . . . . .
3.2.1 Definition und Taxonomie
3.3 Bildverarbeitung . . . . . . . . .
3.3.1 Binäre Regionen . . . . .
3.3.2 Momente . . . . . . . . .
3.3.3 Homografie . . . . . . . .
3.4 Rendering . . . . . . . . . . . . .
3.4.1 Pfadanimation . . . . . .
3.4.2 Catmull-Rom Splines . .
iv
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
v
4 Konzept
4.1 Zielsetzung . . . . . . . . . . . . . . . . . . . . .
4.2 Setup . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Content . . . . . . . . . . . . . . . . . . . . . . .
4.4 Interaktionskonzept . . . . . . . . . . . . . . . .
4.4.1 Interaktion durch die Hand des Benutzers
4.4.2 Interaktion mit den Steinen . . . . . . . .
4.4.3 Interaktion mit dem Bambusrechen . . . .
4.5 Hardware Setup . . . . . . . . . . . . . . . . . . .
4.5.1 Peyote iPoint . . . . . . . . . . . . . . . .
4.5.2 Granulat . . . . . . . . . . . . . . . . . .
4.5.3 Projektionssetup und Beleuchtung . . . .
4.5.4 Kamera . . . . . . . . . . . . . . . . . . .
4.6 Erweiterungen . . . . . . . . . . . . . . . . . . .
4.7 Alternatives Konzept . . . . . . . . . . . . . . . .
4.8 Konzepte des Renderings . . . . . . . . . . . . .
4.8.1 Wasserströmungen . . . . . . . . . . . . .
4.8.2 Animation der Fische . . . . . . . . . . .
4.8.3 Oberflächenwellen . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
22
22
22
23
24
24
26
27
27
27
29
30
32
33
33
35
36
41
42
5 Implementierung
5.1 Struktur . . . . . . . . . . . . . . .
5.2 Interaktionsserver . . . . . . . . . .
5.2.1 Struktur . . . . . . . . . . .
5.2.2 Ablauf . . . . . . . . . . . .
5.2.3 Interaktionserkennung . . .
5.2.4 Netzwerkkommunikation . .
5.3 Kommunikation der Komponenten
5.3.1 Netzwerkprotokoll . . . . .
5.4 Renderclient . . . . . . . . . . . . .
5.4.1 Einführung in Processing .
5.4.2 Softwarearchitektur . . . .
5.4.3 Ablauf . . . . . . . . . . . .
5.4.4 Datenaustausch . . . . . . .
5.4.5 Thread Kommunikation . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
43
43
44
44
45
45
52
52
53
55
55
63
69
70
71
.
.
.
.
.
.
73
73
76
77
77
78
79
6 Ergebnisse
6.1 Detailbeschreibung . . . .
6.2 Analyse . . . . . . . . . .
6.3 Performanceüberlegungen
6.3.1 Renderclient . . .
6.3.2 Interaktionsserver
6.4 Benutzerreaktionen . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
INHALTSVERZEICHNIS
vi
7 Resümee
A Inhalt der CD-ROM
A.1 Diplomarbeit . . .
A.2 Applikation . . . .
A.3 Sourcecode . . . .
A.4 Quellen . . . . . .
A.5 Bilder . . . . . . .
A.6 Video . . . . . . .
Literaturverzeichnis
82
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
84
84
84
85
85
85
86
87
Vorwort
An dieser Stelle möchte ich mich bei all jenen bedanken, die mir bei der
Erstellung dieser Diplomarbeit geholfen haben. Zuallererst bei meinem Betreuer Dr. Michael Haller, für die unkomplizierte Zusammenarbeit. Außerdem bei Keiko Takahashi deren Idee die Grundlage des Projektes bildet. Für
die technische Unterstützung, danke ich Dr. Hirokazu Kato und Dipl. Ing.
Jürgen Zauner. Nicht zu vergessen Oliver Irschitz und sein Unternehmen
Peyote, welche den iPoint zu Verfügung gestellt haben. Weiters ein herzliches Dankeschön an Dietmar Offenhuber, der wertvollen Input zum Konzept
des Projektes geliefert hat, sowie an Petra Affenzeller die mir bei der Organisation von Raum und Equipment immer helfend zur Seite gestanden ist und
vor allem meiner Schwester Kathi, für ihren Einsatz beim Korrekturlesen.
Schlussendlich stellt diese Arbeit den Abschluss einer fünfjährigen Ausbildung dar. Auch wenn nicht immer genug Zeit blieb um sich zu revanchieren, konnte ich doch immer auf die Unterstützung meiner Freunde zählen,
von denen ich einige erst durch mein Studium kennen lernen durfte. Mein
aufrichtigster Dank euch allen. Abschließend noch ein riesiges Dankeschön
an meine Eltern, die mir dieses Studium erst ermöglicht haben.
Die Erstellung dieser Arbeit hat mich die letzten Wochen und Monate
viel Zeit und Kraft gekostet. Diese Kraft, habe ich meiner geliebten Freundin
Magda Abdel-Salam zu verdanken. Egal wie ausweglos die Situation auch
erschien, sie hat an mich geglaubt und war immer eine Quelle neuen Antriebs
und neuer Motivation. Dafür danke ich dir aus tiefstem Herzen.
vii
Kurzfassung
Die vorliegende Arbeit beschreibt die Umsetzung einer Medieninstallation
mit einem Tangible User Interface, dem Dry Garden MR. Zielsetzung dieses
Projektes ist es, die kulturellen Hintergründe japanischer Sandgärten im
wahrsten Sinne des Wortes begreifbar zu machen.
Anhand einer kurzen Beschreibung vergleichbarer Projekte wird zunächst
das Umfeld, in dem sich der Dry Garden MR bewegt, definiert und eingegrenzt. Diese Installationen werden hinsichtlich ihrer technischen Umsetzung
analysiert und aufgrund ihres Interfacedesigns klassifiziert. Anschließend erfolgt eine ausführliche Beschreibung der Eigenschaften und Funktionsweisen der Komponenten des Projektes Dry Garden MR. Die prototypische
Installation realisiert das Tangible User Interface mit Hilfe eines optischen
IR-Trackings, einer Rückprojektionsscheibe und einer Schicht transparenten Granulats. Dieses ist auf der Rückprojektionsscheibe verteilt und lädt
zum Zeichnen beliebiger Muster ein. Mit Hilfe dieser Muster kontrolliert
der Benutzer die visuelle Ausgabe, welche durch die Projektion eines NonPhotorealistic Renderings zu beiden Seiten der Granulatschicht erfolgt. Das
Granulat ist somit Ein- und Ausgabemedium gleichermaßen. Das Verbergen
jeglicher Technik beseitigt die Barriere zwischen Anwender und Installation
und lässt die Interaktion völlig ungehindert stattfinden.
viii
Abstract
This thesis describes the development of the project Dry Garden MR. The
aim of this interactive installation, featuring a tangible user interface, is to
make people familiar with the concept of Japanese dry gardens.
Several related projects are presented in order to provide an overview of
the field of interactive installations. These projects are analysed in regard to
their technical setup. At the same time they are put into categories defining
the metaphor and embodiment of their user interface. Afterwards, a detailed
description of the operating mode and properties of the Dry Garden MR’s
interface is given. This interface consists of an optical IR-tracking system, a
rear projection screen and a layer of transparent plastic beads. These beads
are spread over the rear projection screen and can be used to draw arbitrary
patterns. Creating these patterns allows the user to control the visual output
of the installation. These visuals are created by projecting non-photorealistic
renderings onto both sides of the “bead-layer”. Due to the presence of this
information overlay, the beads are transformed into being input and output
device at the same time. Hiding all technical equipment from the user’s view
allows the interaction to be as natural and barrier-free as possible.
ix
Kapitel 1
Einleitung
Dieses Kapitel gibt einen Überblick über Zielsetzung und Gliederung der
vorliegenden Diplomschrift.
1.1
Zielsetzung
Nach Befassung mit dieser Diplomarbeit soll der Leser verstehen, welche
Aspekte für die erfolgreiche Umsetzung einer Medieninstallation zu beachten sind. Durch die Beschreibung des im Rahmen dieser Arbeit realisierten
Projektes Dry Garden MR, wird vermittelt, wie ein künstlerisches Konzept
in eine konkrete Installation umgesetzt werden kann.
Bei den angesprochenen Problemstellungen handelt es sich neben der
Klassifizierung von Tangible User Interfaces um Algorithmen der Bildverarbeitung, sowie Problematiken der Registrierung virtueller Objekte im reellen
Raum und weiteren Besonderheiten die das Rendering für Projektionen auf
außergewöhnliche Projektionsoberflächen und -medien betreffen.
1.2
Gliederung der Arbeit
Die folgenden Zeilen beschreiben Struktur und Gliederung des vorliegenden
Dokuments. Das einleitende Kapitel 2 steckt das Umfeld des Projektes Dry
Garden MR durch eine Auflistung relevanter Projekte ab. Bei der Auswahl
der Projekte wurde besonderen Wert auf das Vorhandensein eines Tangible
User Interfaces und den Einsatz der Programmierumgebung Processing gelegt. Das nächste Kapitel ist der Erarbeitung theoretischer Grundlagen der
Bildverarbeitung und des Renderings gewidmet. Anschließend beschreibt
Kapitel 4 das Konzept, des konkreten Projektes Dry Garden MR. Dessen
Implementierung wird in Kapitel 5 beschrieben.
Den Abschluss der Arbeit bildet eine Diskussion der erzielten Ergebnisse. Diese beinhaltet weiters eine Evaluierung der eingesetzten Hard- bzw.
Software hinsichtlich ihres Einsatzes in zukünftigen Installationen.
1
Kapitel 2
Medieninstallationen
Für den Begriff Medieninstallation lässt sich eine scharfe Abgrenzung schwer
treffen. Am ehesten scheint eine Entwicklung des Begriffs über deren historische Entwicklung geeignet. 1981 präsentiert Sony das Videoformat Betacam.
Dessen rasche Verbreitung ermöglicht es auch freischaffenden Künstlern sich
mit dem Medium Video auseinanderzusetzen. Neben dem Videoinhalt an
und für sich, wurde von Künstlern wie Marcel Odenbach und Maria Vedder
erstmals auch das Umfeld in die Präsentation ihrer Werke eingebracht. Der
weitere technische Fortschritt bot alsbald die Möglichkeit, Inhalte nicht nur
in Echtzeit zu generieren sondern auch deren Betrachter interaktiv einzubinden. Aus Werken der Installationskunst wurden somit interaktive Installationen.
Zusammenfassend könnte der Begriff Medieninstallation also folgendermaßen definiert werden. Medieninstallationen setzen zur Informationsvermittlung, zur Verstärkung von Sinneseindrücken oder zur Aufarbeitung eines
bestimmten Themas auf den Einsatz audiovisueller Komponenten der Informationstechnologie. Das Vorhandensein einer interaktiven Komponente, die
es dem Benutzer erlaubt, die dargestellten Inhalte aktiv zu beeinflussen, ist
ein sehr häufiges aber nicht zwingend auftretendes Merkmal.
Der folgende Abschnitt versucht einen Überblick über das angesprochene
Themengebiet zu geben. Dazu wird eine Auswahl aktueller und thematisch
relevanter Projekte gegeben.
2.1
Überblick über relevante Projekte
Bei der Auswahl der analysierten Projekte wurde versucht, Verknüpfungen
zum in den späteren Kapiteln beschriebenen Projekt Dry Garden MR herzustellen.
Jene vorgestellten Projekte, die nicht als klassische Medieninstallationen
gewertet werden können, sind aufgrund der eingesetzten Interfacetechnologie
Teil der Auswahl.
2
KAPITEL 2. MEDIENINSTALLATIONEN
3
(a)
Abbildung 2.1: SandScape. (a) Setup. (1) IR-Kamera, (2) Projektor, (3)
Sand (4) IR-Scheinwerfer. (b) Foto der Installation. Aus [Ish04].
2.1.1
SandScape
Bei SandScape [Ish04] handelt es sich um ein Projekt, welches zur Analyse
von Landschaftsmodellen in Echtzeit zum Einsatz kommt. Die zu analysierende Landschaft wird in diesem Projekt durch Sand repräsentiert. Dessen
Form kann vom Benutzer mit bloßen Händen verändert werden. Diese Veränderungen, werden vom System registriert, die interne Repräsentation des
Landschaftsmodells wird entsprechend angepasst.
Setup: Die technische Funktionsweise sei anhand von Abbildung 2.1 erklärt. Unterhalb des Sandes (3) ist ein IR-Scheinwerfer (4), angebracht.
Durch Analyse der Bilder einer oberhalb der Installation montierten IRKamera (1) ist es möglich auf die Höhe der Sandschicht an der entsprechenden Stelle zu schließen. Je höher der Sand, desto schwächer der entsprechende Intensitätswert im Kamerabild. Die Ergebnisse dieser Analyse
werden von einem ebenfalls über der Installation angebrachten Projektor
(2) direkt auf den Sand projiziert.
In seiner Benutzerführung ist das Projekt seinem Vorgänger Illuminating
Clay sehr ähnlich, einzig die eingesetzte Technologie unterscheidet sich. Im
Projekt SandScape ersetzt das beschriebene kostengünstige IR-Tracking den
bei Illuminating Clay [Pip02] zur Erstellung des Höhenmodells notwendigen
Laserscanner.
Anknüpfungspunkt: Das Projekt wurde auf Grund des vorgestellten IRTrackings und der Projektion auf Sand ausgewählt.
KAPITEL 2. MEDIENINSTALLATIONEN
(a)
4
(b)
Abbildung 2.2: Diorama Table. (a) Setup. (1) USB-Kamera, (2) Projektor,
(3) Tisch, (4) Lautsprecher. (b) Foto der Installation. Aus [Tak05].
2.1.2
Diorama Table
Bei dem Projekt Diorama Table [Tak05] handelt es sich um eine interaktive
Medieninstallation der japanischen Künstlerin Keiko Takahashi1 .
Grafisch einfach gestaltete Inhalte reagieren auf die Interaktion des Benutzers mit der Oberfläche des Tisches. Stellt der Benutzer beispielsweise
eine Tasse auf den Tisch, entsteht rund um diese eine ganze Stadt. Durch
die Positionierung von Seilstücken kann der Benutzer Züge auf den Tisch
zaubern und diesen Schienen legen. Legt der Anwender ein Messer auf den
Tisch, wird an dessen Stelle ein Auto platziert. Ziel der Installation ist es, die
Benutzer zur Kommunikation und Interaktion untereinander zu motivieren.
Setup: Vergleiche dazu auch Abbildung 2.2. Es handelt sich um eine Installation in klassischer Tabletop Anordnung. Der Projektor (2) sowie die
Kamera (1), die der Interaktionserkennung dient, sind oberhalb (der Projektionsfläsche (3)) platziert. Bei der Projektionsfläche handelt es sich um
einen normalen Tisch der keine speziellen Anforderungen zu erfüllen hat.
Unterhalb des Tisches sind Lautsprecher (4) angebracht, die die kreierten
Sounds ausgeben.
Anknüpfungspunkt: Es handelt sich um ein Projekt, welches von jener
Künstlerin, die auch Dry Garden MR initiiert hat, entwickelt wurde. Das Installationssetup ist ähnlich, lediglich die Interaktionserkennung erfolgt nicht
im IR- sondern im sichtbaren Bereich des Lichts, durch den Einsatz einer
einfachen USB-Kamera ohne zusätzliche Filter.
1
http://www.th.jec.ac.jp/∼keiko/
KAPITEL 2. MEDIENINSTALLATIONEN
(a)
5
(b)
Abbildung 2.3: Augmented Sound Reality. (a) Gesamtansicht. (b) Benutzersicht. Aus [Dob04].
2.1.3
Augmented Sound Reality
Kernaspekt dieses Projektes ist das Platzieren virtueller Schallquellen im
dreidimensionalen Raum. Dazu dient dem Benutzer ein Augmented Reality Interface. Wie aus Abbildung 2.3 hervorgeht, besteht dies aus einem
mit einem Marker ausgestatteten stiftförmigen Eingabemedium. Durch das
Head Mounted Display kann der Benutzer die Schallquellen optisch erkennen. Akustisches Feedback über deren Position erhält er über ein Surroundsound-System.
Setup: Zur Registrierung der virtuellen Objekte im realen Raum kommt
das ARToolkit 2 zum Einsatz. Dessen Funktion beruht auf dem Einsatz einer
Webcam und speziellen optischen Markern. Die Marker werden im Kamerabild erkannt und ermöglichen so eine Registrierung virtueller dreidimensionaler Objekte in der realen Welt. Die optische Ausgabe erfolgt über ein
Head Mounted Display (HMD ). In diesem wird das Videobild der Webcam
mit den virtuellen Objekten überlagert. Die akustische Ausgabe des Systems
erfolgt mit der Creative EAX Library. Diese erlaubt die Erzeugung und Platzierung von bis zu 128 Schallquellen. Neben HMD, Webcam und einem PC
mit Dolby Digital-Soundkarte, wird nur ein einziger Marker, der fix mit dem
Raum verbunden ist, sowie das stiftförmige Eingabegerät, benötigt.
Anknüpfungspunkt: Das Projekt wurde vorgestellt um in der Kategorisierung des nächsten Abschnittes ein Beispiel eines User Interfaces mit
Soundausgabe zu Verfügung zu haben.
2
http://www.hitl.washington.edu/artoolkit/
KAPITEL 2. MEDIENINSTALLATIONEN
(a)
6
(b)
Abbildung 2.4: Rakugaki. (a) Instrumente. (b) Grafische Ausgabe. Aus
[Tak01].
2.1.4
Rakugaki
Diese Installation von Keiko Takahashi erlaubt es seinem Benutzer mittels
Trompeten, Trommeln, Pfeifen und Glockenspielen (siehe Abbildung 2.4(b))
mit dieser zu interagieren. Das System zeigt je nach Musikinstrument unterschiedliche Reaktionen. Wird die Trompete oder die Pfeife gespielt, erscheinen auf der Projektionsfläche (Abbildung 2.4(a)) animierte Linien. Greift
der Benutzer zum Glockenspiel, werden die Grafiken entsprechend rotiert.
Als Rahmen dient ein handgezeichneter Würfel. Rüttelt der Benutzer am
Shaker, so rotiert er diesen Würfel. Lautstärke und Frequenz der erzeugten Klänge beeinflussen welche Objekte dargestellt werden, bzw. wie schnell
sich diese drehen. Die Installation hat reinen Unterhaltungscharakter und
soll die Menschen die Menschen daran erinnern, wie viel Spaß gemeinsames
Musizieren bereitet.
Setup: Zur Erkennung der Sounds kommt eine Eigenimplementierung zum
Einsatz. Die grafische Ausgabe gelingt durch den Einsatz von C++ und
OpenGL. Die generierten Grafiken werden mittels Frontprojektion einer möglichst breiten Öffentlichkeit zugänglich gemacht.
Anknüpfungspunkt: Das Projekt wurde zur Analyse seiner Benutzerschnittstelle ausgewählt. Außerdem stammt dessen Konzept von der selben
Künstlerin, die auch das ursprünglich Konzept des Dry Garden MR entwickelt hat.
KAPITEL 2. MEDIENINSTALLATIONEN
7
Abbildung 2.5: processingLIVE. Aus [Hod05a].
2.1.5
processingLIVE
Wie aus dem Untertitel des Projektes – using processing and powermates
”
as a VJ tool“ – hervorgeht, erlaubt es diese Installation, mittels Processing
erzeugte Visuals, über ein eigens angefertigtes Hardware-Interface zu kontrollieren.
Setup: Diese Installation setzt zur Erfassung von Live-Videomaterial auf
den Einsatz einer Webcam. Gleichzeitig erfolgt 24 mal pro Sekunde eine
Audioanalyse. Entsprechend der Analyseergebnisse wird das erfasste Bild
verändert. Die Audioanalyse erfolgt über die externe Java-Bibliothek Sonia.
Das Hardwareinterface dient dazu, die den Einsatz der Installation auch im
Live-Betrieb zu ermöglichen. Dank der vier Griffin Powermate Drehregler,
die mittels USB-Schnittstelle mit dem Rechner verbunden sind, kann der
VJ die Installation schnell genug bedienen um die Anpassung der Visuals im
Takt der Musik vornehmen zu können. Mit diesen Reglern werden neben der
Rotation der Kamera auch deren Focus und je nach aktuellem Einsatzzweck
weitere Parameter wie z. B. Farbstimmung, optische Frequenz etc. gesteuert.
Die Ausgabe der Visuals gelingt wiederum mittels Frontprojektion.
Anknüpfungspunkt: Das Projekt wurde ausgewählt, um die Leistungsfähigkeit und Erweiterbarkeit von Processing aufzuzeigen. Laut3 läuft diese
Installation auf einem Apple Powerbook bei einer Auflösung von 1680x1050
mit 20 bis 40 fps. Ein beachtliches Resultat wenn man bedenkt, dass als
Eingabeparameter die Analyse des Videomaterials, sowie die Audioanalyse
in Echtzeit erfolgen und gleichzeitig die hoch auflösende Ausgabe der generierten Visuals erfolgt.
2.1.6
Khronos Projector
Diese Installation zeichnet sich sowohl durch ihr innovatives Interface, als
auch durch die außergewöhnlichen Inhalte aus. Mittels Großprojektion werden verschiedenste Fotografien dargestellt. Durch Berühren der Projektions3
http://www.processing.org
KAPITEL 2. MEDIENINSTALLATIONEN
(a)
8
(b)
Abbildung 2.6: Khronos Projector. (a) Setup. (1) Projektor, (2) Kamera,
(3) Leinwand. (b) Screenshot. Aus [Cas05].
leinwand, kann der Benutzer die Stelle des Bildes, die sich unter seiner Hand
befindet, an eine zeitlich andere Stelle transferieren.
Setup: Die folgende Beschreibung erfolgt anhand von Abbildung 2.6(a).
Um zu ermitteln wie weit der Screen nach innen gedrückt wurde, kommt
eine selbst entwickelte IR-Technologie zum Einsatz. Hinter der Projektionsleinwand (3) ist eine konventionelle CCD-Kamera (2) montiert. Rund um
die Optik sind IR-LEDs angebracht. Deren optische Achse ist dadurch parallel zur Achse der Kamera. Die Leinwand ist auf ihrer Rückseite speziell
beschichtet, um das IR-Licht besser zu reflektieren und durch den Projektor
(1) ausgelöste Hotspots zu vermeiden.
Aus den durch die Kamera ermittelten Grauwerten lässt sich die Abweichung der Normalen des entsprechenden Punktes der Projektionsleinwand
von der optischen Achse bestimmen. Aus dieser Abweichung wird eine Tiefeninformation für jeden Pixel und den korrespondierenden Punkt auf der
Leinwand errechnet. Anhand dieser Information, kann die Stelle im Bild
zeitlich in die Zukunft oder die Vergangenheit verschoben werden.
Anknüpfungspunkt: Das Projekt wurde auf Grund seines interessanten Benutzerinterfaces ausgewählt. Weiters fand die Entwicklung des ersten
Prototypen unter Processing statt4 . Die finale Implementierung wurde aus
Performancegründen aber in OpenGL und C++ umgesetzt.
4
http://www.k2.t.u-tokyo.ac.jp/members/alvaro/Khronos/Khronos P5/
Khronos Applets.htm
KAPITEL 2. MEDIENINSTALLATIONEN
(a)
9
(b)
Abbildung 2.7: webcam:tracking. (a) Setup. (1) Projektor, (2) Webcam, (3)
Rückprojektionsleinwand, (4) Taschenlampe. (b) Screenshot. Aus [Hod05b].
2.1.7
webcam:tracking
Der Anwender kann über die Positionierung eines Lichtstrahl die Ausgabe
unterschiedlicher Grafiken steuern.
Setup: Vergleiche für folgenden Absatz auch Abbildung 2.7(a). Hinter der
Rückprojektionsleinwand (3) ist eine Webcam (2) angebracht. Deren Bilder
werden von einer in Processing entwickelten Software analysiert. Die Stelle,
der durch die Taschenlampen (4) ausgelösten Hotspots in diesem Bild determiniert die Platzierung verschiedener grafischer Elemente. Das Tracking
passiert rein optisch, es kommt weder eine zusätzliche IR-Beleuchtung noch
ein IR-Filter zum Einsatz. Die Ausgabe der Grafiken erfolgt mittels Projektor (1).
Anknüpfungspunkt: Diese Installation wurde ausgewählt um die Fähigkeit von Processing, zur Bildverarbeitung und der gleichzeitigen Ausgabe von
Computergrafik in Echtzeit zu demonstrieren.
Kapitel 3
Grundlagen
Das folgende Kapitel dient der Vermittlung von Grundlagen, auf die die
weiteren Kapitel aufbauen. Dabei wird eine breite Palette von Aspekten
angesprochen: kulturelle Hintergründe des Projektes, Definition und Taxonomie von Tangible User Interfaces, sowie Grundlagen der Bildverarbeitung
und der Computergrafik. Die inhaltliche Breite dieser Themen lässt erkennen wie viele unterschiedliche Aspekte bei der Umsetzung des Projektes
Dry Garden MR in Erwägung gezogen wurden.
3.1
Kultureller Hintergrund
Der Garten als ein Ort der Inspiration, Entspannung und Ruhe hat in der
japanischen Kultur lange Tradition. Er besteht aus einer bestimmten Anzahl
fix vorgegebener Elemente, die nach gewissen Regeln [Lyo02] angeordnet
sind. Bei diesen Elementen handelt es sich um Teiche (vgl. 3.2(c)), Bäume,
Blumen und kleine Bäche. Als verbindendes bzw. trennendes Element in der
Gestaltung werden Wege gezielt eingeplant. Jedes dieser Elemente hat dabei
seine symbolische Bedeutung. So genießen es die Bewohner der japanischen
Inseln, in ihrer Fantasie in den Steinen Gebirge, in den Seen Ozeane und in
den Bächen sprudelnde Flüsse zu sehen.
Mit Beginn der Muromachi Periode im 15. Jahrhundert, wurde die Abstraktion von Ozeanen und Gebirgen weiter vorangetrieben. Die natürlichen
Elemente des Gartens verschwanden, die kleinen Wasserläufe und Inseln
wurden durch Kies und Steine ersetzt (vgl. 3.1). Unter dem Namen Zen
Garten (engl. dry garden, jap. karesansui) erfreuen sich Sandgärten dieser
Art bis heute großer Beliebtheit.
Für Angehörige anderer Kulturkreise kaum nachvollziehbar, bereitet es
Menschen der japanischen Kultur größte Freude, Muster in den Kies zu rechen (vgl. 3.2(b)) und diese in Gedanken zum Leben zu erwecken, und so ein
eigenes Universum entstehen zu lassen. Das Rechen der Muster wird als meditatives Erlebnis erfahren, die Muster symbolisieren den Fluss des Lebens.
10
KAPITEL 3. GRUNDLAGEN
11
Abbildung 3.1: Zen Garten in Ryoan Ji (Kyoto, Japan). Aus [Lyo02].
(a)
(b)
(c)
Abbildung 3.2: Verschiedene Zen Gärten. (a) Tischversion mit Handrechen. (b) Buddhistischer Mönch bei der Pflege des Gartens des Zuiryusan
Tempels. (c) Die Teiche japanischer Gärten sind meist Habitat einer speziell
gezüchteten Karpfengattung (Cyprinus carpio). Aus [Lyo02].
Um dieses Erlebnis auch an Orten zu ermöglichen, die nicht genug Platz
für einen Garten bieten, gibt es auch kleinere Versionen, die z.B. auf einem
Tisch platziert werden können (siehe 3.2(a)). Die kreis- und wellenförmigen
Muster werden in diesem Fall mit kleinen Bambusrechen in den Sand bzw.
Kies gezogen.
Hierin liegt der Ansatzpunkt des Projektes Dry Garden MR. Auch Menschen die sich noch nie mit der japanischen Kultur beschäftigt haben, soll
es möglich sein, die Faszination für einen Zen Garten nachzuvollziehen. Dies
wird beim Dry Garden MR durch den Einsatz unterschiedlicher Technologien der Projektion und der Interaktionserkennung erreicht.
KAPITEL 3. GRUNDLAGEN
3.2
12
Tangible User Interfaces
Bei Dry Garden MR handelt es sich um eine Medieninstallation mit Tangible
User Interface (im weiteren Verlauf des Textes als TUI bezeichnet). Der
folgende Abschnitt dient deren Definition und beschreibt die von Fishkin
in [Fis04] vorgeschlagene Taxonomie. Um diese anhand konkreter Beispiele
nachvollziehbar zu machen, finden sich jeweils Verweise auf die in Abschnitt
2.1 beschriebenen Projekte.
3.2.1
Definition und Taxonomie
Wie auch in [Fri] beschrieben, unternahmen Ishii und Ulmer in [Ull97] erstmalig den Versuch, den Begriff des Tangible User Interface, zu definieren.
Dabei entstehen TUIs, den Autoren zu Folge, durch die Kombination physikalischer Alltagsgegenstände und -objekte mit digitalen Informationen. Um
den Begriff weiter einzuschränken definieren sie in [Ull01] TUIs als Auflösung des Unterschiedes zwischen Ein- und Ausgabemedium.
Fishkin geht in seiner Beschreibung des Begriffs [Fis04] zurück zur ursprünglichen Definition und beschreibt TUIs ganz allgemein als Reaktion
eines Computersystems auf einen Eingabe Event. Fishkins Definition im Detail:
1. Durch die physische Manipulation eines Alltagsgegenstandes wird der
Eingabe Event ausgelöst.
2. Der Eingabe Event wird durch das Computersystem erfasst. Als Reaktion verändert dieses seinen Status.
3. Die Statusänderung wird dem Benutzer mittels einer Veränderung am
Eingabemedium angezeigt.
Zur Verifizierung seiner These analysiert Fishkin 60 Benutzerschnittstellen hinsichtlich ihrer Klassifizierbarkeit als TUIs. Das Resultat der Untersuchung: Es gibt kein eindeutig differenzierendes Kriterium zur Einteilung
einer Benutzerschnittstelle als TUI. Demzufolge wird in [Fri] bzw. [Fis04]
die Klassifizierung von Benutzerschnittstellen hinsichtlich ihrer tangibility
anhand einer zweidimensionalen Taxonomie vorgeschlagen. Die beiden Dimensionen dieser Taxonomie werden als Embodiment und Metaphor bezeichnet (Um so korrekt wie möglich zu bleiben, werden die englischen Bezeichnungen sowohl für die Achsen selbst, wie auch für deren Parametrisierung
übernommen. Diese finden sich auch in Abbildung 3.2.1 wieder). Dabei gilt
eine Benutzerschnittstelle als umso greifbarer, je weiter sie vom Ursprung
des, durch die beiden Parameter Embodiment und Metaphor aufgespannten
Koordinatensystems entfernt liegt. Abbildung 3.2.1 zeigt dieses Diagramm.
Darin eingetragen finden sich alle in Abschnitt 2.1 beispielhaft erwähnten
Projekte.
KAPITEL 3. GRUNDLAGEN
13
Abbildung 3.3: Taxonomie für Tangible Userinterfaces nach Fishkin
[Fis04].
Embodiment
Dieser Parameter beschreibt die subjektive Distanz zwischen dem durch den
Benutzer manipulierten Objekt und dem System an und für sich. Der Wert
ist umso höher, je stärker das Gefühl vermittelt wird, das System wäre Teil
des manipulierten Objektes. Fishkin unterscheidet anhand der vier Stufen
Full, Nearby, Environmental und Distant.
Full: Das Eingabemedium dient gleichzeitig als Ausgabemedium. Als praktisches An dieser Stelle sei auf das Projekt SandScape (Abschnitt 2.1.1) verwiesen. Hierbei dient der zum Einsatz gekommene Sand gleichzeitig als Eingabemedium (die Höhe der aufgeschichteten Sandschichten beeinflusst die
Topologie des Computermodells) wie auch Ausgabemedium (die Ausgabe
der Analysefunktionen der Landschaft wird direkt auf den Sand projiziert).
KAPITEL 3. GRUNDLAGEN
14
Nearby: Das Systems gibt seine Reaktion in unmittelbarer örtlicher Nähe
zum Eingabemedium aus. Beim Projekt Diorama Table (Abschnitt 2.1.2)
gilt dies für die Projektionen auf die Oberfläche des Tisches (= Ausgabe).
Diese findet direkt neben den Objekten statt, die durch die Erfassung ihrer
Positionen durch die Interaktionserkennungskomponente selbst zum Eingabemedium werden.
Environmental: Das Ausgabemedium umgibt“ den Benutzer. In den
”
meisten Fällen handelt es sich also um ein Audiointerface. Da diese Schnittstelle nicht physisch greifbar ist, wird sie von Ullmer und Ishii auch als non”
graspable“ kategorisiert. Dies trifft auf das in Abschnitt 2.1.3 vorgestellte
Projekt Augmented Sound Reality zu: Der Klang der virtuellen Schallquellen kommt auch akustisch aus der durch den Benutzer definierten Position.
Nachdem die optische Ausgabe von einem VR-System mit Head Mounted
Display übernommen wird, kann auch diese als den Benutzer umgebend“
”
klassifiziert werden.
Distant: Die Reaktion auf ein Eingabeevent erfolgt in diesem Fall in örtlicher Distanz zu diesem. Hierbei sei auf das Projekt processingLIVE (Abschnitt 2.1.5) verwiesen. Die Bedienung des Hardwareinterfaces durch den
VJ bewirkt die Änderung der örtlich von diesem weit entfernt projizierten
Visuals.
Metaphor
Wird eine Benutzerschnittstelle physisch greifbar, stehen dem Interfacedesigner eine Vielzahl an Möglichkeiten offen, das Interface bzw. dessen Elemente, mit einer Metapher zu verknüpfen. In Bezug auf TUIs bedeutet das
Folgendes. Aussehen und/oder Reaktion eines User Interface-Elements ähneln dem/der, eines Gegenstandes in der realen Welt. Auch diese Taxonomie
quantisiert Fishkin in vier Stufen. Der nächste Abschnitt widmet sich deren
Beschreibung im Detail.
None: Eine Schnittstelle die gar keine Metapher definiert. Als Beispiel sei
die klassische Kommandozeile erwähnt.
Noun oder Verb: Die Schnittstelle selbst ist einem Objekt in der realen
Welt ähnlich. In [Fis04] bringt Fishkin diesen Sachverhalt auf den Punkt:
An <X> in our system is like an <X> in the real world.
Die mit der Schnittstelle möglichen Aktionen haben allerdings keine oder
nur eine minimale Entsprechung in der realen Welt. Als Beispiel sei auf das
Projekt Rakugaki (Abschnitt 2.1.4) verwiesen. Die Musikinstrumente die das
KAPITEL 3. GRUNDLAGEN
15
Eingabemedium der Installation darstellen, stellen auch in der Installation
selbst Musikinstrumente dar. Das Spiel eines Benutzers mit diesen, löst neben einem Klang auch ein optisches Feedback auf der Projektionsleinwand
aus. Zu diesem Verb“ des Interfaces gibt es in der Realität keine Entspre”
chung. Dieser Fall wird von Fishkin als Metapher des Nomens“ bezeichnet.
”
Im gegensätzlichen Fall hat die mit der Benutzerschnittstelle mögliche Interaktion eine Entsprechung in der realen Welt. Die Form der Schnittstelle
ist jedoch irrelevant. In [Fis04] drückt Fishkin dies folgendermaßen aus:
<X>-ing in our system is like <X>-ing in the real world.
Er definiert dies als Metapher des Verbs“. Beim Projekt Augmented Sound
”
Reality (Abschnitt 2.1.3 kann eine Soundquelle im virtuellen Raum beliebig
verschoben werden. Das virtuelle Objekt lässt sich also wie ein reales Objekt
verschieben. Die Form des zum Einsatz gekommenen Eingabemediums ist
dabei nicht von Relevanz.
Noun und Verb: Sowohl die Form als auch die möglichen Interaktionen
mit der Schnittstelle entsprechem einem Objekt der realen Welt. Im Original
[Fis04]:
<X>-ing an <A> in our system is like <X>-ing something
<A>-ish in the real world.
Im Kontext klassischer Human Computer Interfaces (HCI ) wird dies durch
die Metapher des Drag and Drop“ zum Ausdruck gebracht. Durch Ziehen
”
eines Dokuments an eine andere Stelle, wird dieses auch an anderer Stelle
im Dateisystem abgelegt. Dabei kommuniziert das eingesetzte Icon auch
grafisch, dass es sich bei der mit diesem Symbol verknüpften Datei um ein
Dokument handelt.
Full: In diesem Fall ist für den Benutzer des Systems keine Unterscheidung zwischen physikalischer und virtueller Schnittstelle erkennbar. An dieser Stelle sei ein weiteres Mal auf SandScape (Abschnitt 2.1.1) verwiesen.
Mittels physikalischer Verformung des Sandes ändert der Benutzer auch die
Form von dessen digitaler Repräsentation.
Nachdem nun neben einer Definition auch eine Taxonomie für TUI s
besteht, stellt sich die Frage, welcher Vorteil sich durch den Einsatz von
TUIs gegenüber jenem traditioneller User Interfaces ergeben. Der Vorteil
von TUIs liegt ganz klar darin begründet, dass sie den Tastsinn des Benutzers ansprechen, denn der Mensch nimmt haptische Einwirkungen auch
dann wahr, wenn er diesen keine bewusste Aufmerksamkeit schenkt. Ein
tangibles“ Bedienelement kann auch bedient werden, ohne den Benutzer
”
von seiner Haupttätigkeit abzulenken. Als Beispiel sei an dieser Stelle der
Hebel zur Bedienung der Blinkanlage in Autos angeführt. Auch ohne dass
KAPITEL 3. GRUNDLAGEN
16
der Fahrer seinen Blick von der Strasse nehmen muss, kann er den Blinker betätigen. Außerdem informiert ihn neben dem optischen und akustischen Feedback zusätzlich die Position des Hebels über dessen Status. Daraus lässt sich der folgende Schluss ziehen: Ein TUI ist im Allgemeinen für
den Benutzer deshalb besser bedienbar, weil es mehrere Sinne des Benutzers
gleichzeitig anspricht, in Summe aber weniger Aufmerksamkeit von dessen
Benutzer fordert. Ein weiteres Element welches die Bedienung einer Benutzerschnittstelle vor Allem für Anwender, die die Schnittstelle zum ersten Mal
verwenden, vereinfacht, ist der Einsatz von Metaphern beim Interfacedesign.
Dabei muss die eingesetzte Metapher für den Benutzer klar verständlich und
vor Allem konsistent sein. Als Negativbeispiel wird von [Fri] und anderen
das Papierkorb Icon unter MacOs beansprucht. Mittels Ziehen einer Datei
auf dieses Icon wird diese gelöscht. Gleichzeitig kann ein Wechseldatenträger nur aus dem Laufwerk ausgeworfen werden, indem dieser ebenfalls über
das Papierkorb Icon gezogen wird. Der Benutzer erwartet von der Metapher
Konsistenz und hat infolgedessen Angst, die Daten des Wechseldatenträgers
würden durch Ziehen auf das Papierkorbsymbol ebenfalls gelöscht. Durch
diese inkonsistente Mehrfachbelegung einer Metapher wird der Benutzer in
der Bedienung nicht unterstützt sondern vielmehr behindert.
3.3
Bildverarbeitung
Die Interaktionserkennung des Dry Garden MR funktioniert, mittels Analyse
der Bilder, die von der in Abschnitt 4.5.4 beschriebenen IR-Kamera stammen. Eine solche rechnergestützte Analyse von digitalen Bilddaten wird allgemein als Bildverarbeitung bezeichnet. Dabei handelt es sich um einen eigenen Zweig der Informatik dem zahlreiche Bücher und Forschungsarbeiten gewidmet sind. Die vorliegende Diplomarbeit erhebt nicht den Anspruch, dieses Gebiet vollständig abzudecken, das folgende Kapitel dient somit alleine
der Erarbeitung der Grundlagen und Definitionen der bei der Beschreibung
des umgesetzten Konzeptes verwendeten Fachbegriffe. Diese Einführung ist
so kompakt wie möglich gehalten.
3.3.1
Binäre Regionen
Die primäre Motivation hinter der implementierten Bildverarbeitung ist es,
Objekte (Steine, Löcher in der Granulatschicht, Interaktionsmuster des Benutzers) zu erkennen. Dabei handelt es sich um eine Standardaufgabe der
Bildverarbeitung. Die eingesetzte Technik wird als Region Labeling bezeichnet. Die folgenden Sätze fassen kurz zusammen, wie diese Technik bei Graustufenbildern funktioniert.
In einem ersten Schritt wird durch einen konstanten Threshold zwischen Hintergrund- und Vordergrundpixeln unterschieden. In einem zweiten
KAPITEL 3. GRUNDLAGEN
17
Schritt werden die benachbarte Pixel des Vordergrundes zu Regionen zusammengefasst. Dabei wird allen Pixeln einer Region ein einheitliches Label zugeordnet. Somit ist über dieses Label ein Zugriff auf alle Pixel dieser Region
möglich. Zur Implementierung des Region Labelings stehen zwei Verfahren,
Floodfilling und sequentielle Regionenmarkierung, zur Auswahl. Beide werden nicht näher erläutert, da bei der konkreten Implementierung auf eine
spezielle Regionlabelingvariante des ARToolkits 1 zurückgegriffen wird.
3.3.2
Momente
Vgl. für den folgenden Abschnitt (3.3.2) sowie die Formeln (3.1, 3.2, 3.3 und
3.4) [Bur05, Kap. 11]. Zur Interpretation der Interaktionsmuster des Benutzers werden für die detektierten Regionen bestimmte Merkmale (Features)
berechnet. Im konkreten Fall handelt es sich dabei um die Exzentrizität und
um die Ausrichtung der Hauptachse. Beide Merkmale werden über die Ermittlung zentraler Momente berechnet. In beiden Fällen spricht man von
statistischen Formmerkmalen, da bei deren Berechnung die Region als
statistische Verteilung von Koordinatenpunkten im zweidimensionalen Raum [Bur05]
betrachtet wird. Die Berechnung dieser Merkmale gelingt durch den Einsatz
des allgemeinen statistischen Konzeptes der Momente. Mittels
mpq =
up v q
(3.1)
(u,v)∈R
wird das Moment der Ordnung p, q für die Vordergrundpixel einer binären
Region berechnet. Bestimmte Momente können herangezogen werden um
auf die geometrische Eigenschaften der Region zu schließen. So beschreibt
beispielsweise der Moment m00 , deren Fläche (= Summe der Pixel).
In die Berechnung der Momente fließen die Koordinaten der Pixel der
jeweiligen Region ein. Dadurch sind diese abhängig von der Lage der Region
im Bildkoordinatensystem. Durch den Einsatz zentraler Momente lässt sich
eine Region unabhängig von ihrer Lage beschreiben. Dazu wird in einem
ersten Schritt der Schwerpunkt der Region berechnet. Im zweiten Schritt
werden die Koordinaten aller Pixel der Region in Bezug zu diesem gesetzt.
Durch
µpq (R) =
(u − x)p · (v − y)q
(u,v)∈R
kann das zentrale Moment der Ordnung p, q berechnet werden.
1
http://www.hitl.washington.edu/artoolkit/
(3.2)
KAPITEL 3. GRUNDLAGEN
18
Hauptachse
Die berechneten Momente lassen sich heranziehen, um direkt auf geometrische Eigenschaften, wie z. B. die Lage der Hauptachse, zu schließen. Diese
beschreibt die Ausrichtung einer Region und sei anhand des folgenden Beispiels aus [Bur05] beschrieben. Stellt man sich die Region als Ebene im Raum
vor und rotiert diese um alle möglichen Achsen die durch deren Schwerpunkt
verlaufen, so ist die Hauptachse jene Rotationsachse, die einer Drehung das
geringste Trägheitsmoment entgegensetzt. Durch
2 · µ11 (R)
1
−1
(3.3)
θ (R) = tan
2
µ20 (R) − µ02 (R)
gelingt die Berechnung des Winkels der Hauptachse.
Exzentrizität
Die Exzentrizität (engl. Eccentricity) beschreibt die Länglichkeit einer Region. Diese ist als das Verhältnis der beiden Hauptachsen der umhüllenden
Ellipse definiert. Dabei kommt jene umhüllende Ellipse mit dem maximalen
Verhältnis der beiden Hauptachsen zum Einsatz. Der durch
Eccentricity (R) =
[µ20 (R) − µ02 (R)]2 + 4 · [µ11 (R)]2
[µ20 (R) + µ02 (R)]2
(3.4)
berechnete Wert liegt im Bereich [0, 1]. Für eine kreisförmige Region ergibt
sich dabei ein Wert von 0, für eine lang gezogene Region ergibt sich eine
Exzentrizität von 1.
3.3.3
Homografie
Nach der Identifikation der interessanten Regionen und deren geometrischer
Merkmale, ist die Grundlage geschaffen mittels dieser geometrischen Daten das Rendering zu beeinflussen. Dabei tritt folgendes Problem auf: Die
Koordinaten der Interaktionsanalyse beziehen sich auf das Bildkoordinatensystem der Kamera. Um die virtuellen Repräsentationen der Objekte an der
korrekten Stelle im Weltkoordinatensystem der dreidimensionalen Szene zu
ermöglichen, müssen die beiden Koordinatensysteme in Bezug zueinander
gebracht werden.
Dies erfolgt durch das Konzept der Homografie. Dabie handelt es sich
um die kollineare Abbildung zweier Vektorräume der Dimension 2. Die Abbildung auf einen Vektor des jeweils anderen Vektorraumes gelingt durch
Multiplikation mit der, in einem ersten Schritt erstellten Homografiematrix.
Diese beschreibt ein lineares Gleichungssystem, das durch die Angabe der
Koordinaten der Referenzpunkte determiniert ist. Wir bewegen uns im zweidimensionalen Raum. Zur Berechnung kommen homogene Koordinaten (im
KAPITEL 3. GRUNDLAGEN
19
zweidimensionalen also dreielementige Spaltenvektoren) und eine 3 × 3 Matrix zum Einsatz. Die beschriebene Transformation ist skalierungsinvariant,
das Gleichungssytem weist daher acht Freiheitsgrade auf. Zu deren Determinierung ist also die Angabe der Koordinaten von vier Referenzpunkten
notwendig. Dabei kommen die Eckpunkte der Region of Interest zum Einsatz, die zu den Punkten des Einheitsrechteckts in Bezug gebracht werden.
Die so normalisierten Koordinaten werden im Renderclient durch Multiplikation mit der Dimension der Region of Interest im Weltkoordinatensystem wieder in Weltkoordinaten umgewandelt.
3.4
Rendering
Es folgen theoretische Grundlagen sowie eine Beschreibung der zum Einsatz
gekommenen Algorithmen, die die Grundlage des Renderings bilden. Diese
Grundlagen werden in bewusst kompakter Form abgehandelt, für tiefer gehende Informationen sei der Leser erneut auf die einschlägige Fachliteratur
(z.B. [Fel92] und [Mor90]) verwiesen.
3.4.1
Pfadanimation
Ein Grundproblem der Umsetzung fast aller Medieninstallationen, ist es,
Objekte in Bewegung zu versetzen. Bewegung bedeutet Veränderung der
Bildinhalte, und genau dadurch wird die Aufmerksamkeit des Betrachters
auf eine Installation gelenkt. Eine abwechslungsreiche Animation stellt somit
den Schlüssel zu einer gelungenen und publikumswirksamen Installation dar.
Beim Dry Garden MR wird diese Problematik durch die so genannte
Pfadanimation [Fil06] gelöst. Jedes Objekt (Fische, Blätter, Wasserströmungen...), das sich bewegt, folgt einem vorgegebenen Pfad. Solch ein Pfad ist
durch eine Summe an Stützpunkten definiert. Um Positionen zwischen diesen
Stützpunkten zu ermitteln, kommt die im Folgenden beschriebene CatmullRom Spline Interpolation zum Einsatz.
3.4.2
Catmull-Rom Splines
Der Begriff Spline sei durch folgendes Zitates aus [Ben03, Kap. 3.5.5] definiert.
Der Begriff der Spline-Kurve wird in der Literatur sehr unterschiedlich definiert und ebenso weit reichend für die unterschiedlichsten Arten von Kurven benutzt. Als kleinster gemeinsamer
Nenner aller Definitionen gilt die Charakterisierung einer SplineKurve als stückweise zusammengesetzte Kurve, die in ihren Segmenttrenngrenzen festgelegte Stetigkeitsbedingungen bzw. Glattheitskriterien erfüllt.
KAPITEL 3. GRUNDLAGEN
20
Bei dem von Catmull und Rom entwickelten Verfahren Splines zu beschreiben [Cat74], handelt es sich um Kurven dritter Ordnung, genauer um
eine Untergruppe der Kardinal-Splines. Deren Verlauf ist durch Richtung
und Länge von Tangenten bestimmt. Beim Einsatz des Catmull-Rom Verfahrens werden die Tangenten anhand der Stützpunkte des Pfades automatisch
gewählt.
Die Kontinuität der resultierenden Kurve erfüllt die Kriterien G1 (die
Richtungen der Tangenten sind für 2 benachtbarte Kurvensegmente gleich)
und C 1 (die erste Ableitung der Kurvenfunktion benachtbarter Segmente
ist gleich → die Tangenten sind gleich lang). Eine komplette mathematische
Herleitung der Funktion findet sich in [Twi03], das resultierende Gleichungssystem
⎛
v (u) =
1 u u2
0
⎜
−τ
u3 · ⎜
⎝ 2τ
−τ
1
0
0
τ
τ − 3 3 − 2τ
2−τ τ −2
⎞ ⎛
0
pi−2
⎜ pi−1
0 ⎟
⎟·⎜
−τ ⎠ ⎝ pi
pi+1
τ
⎞
⎟
⎟ (3.5)
⎠
in Matrixnotation.
Dabei entspricht v dem zu berechnenden Stützpunkt, pi−2 bis pi+1 den
vier zur Interpolation herangezogenen Stützpunkten und τ der so genannten
Tension bzw. Spannung. Beim Catmull-Rom Verfahren werden die Tangenten wie erwähnt anhand eines zwischen den aktuellen Stützpunkten linear
interpolierten Punktes definiert. Der Parameter τ bestimmt dabei im Wertebereich [0..1] den Interpolationsfortschritt. Catmull-Rom Splines sind so
definiert, dass der zur Bestimmung der Tangente interpolierte Punkt genau in der Mitte von Start- und Endpunkt des aktuellen Kurvensegmentes
liegt. τ ist somit auf 0.5 fixiert. Im konkreten Fall wurde die Tension bei
0.5 belassen, da sich bei der Wahl eines kleineren Wertes, die Animationspfade zu stark durchbiegen“, ein größerer Wert aber unnatürlich eckige“
”
”
Animationspfade bewirkt (vgl. Abbildung 3.4).
Der wesentliche Vorteil, eines Catmull-Rom Splines liegt darin, dass dieser immer durch alle ihn definierenden Stützpunkte verläuft. Die einzigen
Ausnahmen bilden der erste und der letzte Stützpunkt. Diese dienen nur der
Definition der Tangenten im zweiten bzw. vorletzten Stützpunkt des Pfades.
Um bei den Pfadanimationen die Catmull-Rom Spline Interpolation verwenden zu können, gleichzeitig aber trotzdem zu garantieren, dass Start- und
Endpunkt des Pfades durchlaufen werden, werden vor dem Startpunkt sowie
nach dem Endpunkt eines Pfades automatisch zusätzliche Punkte eingefügt.
Die Position dieser Punkte ist durch die jeweils vor bzw. nach dem Startbzw. Endpunkt liegenden Punkte definiert. Diese werden um den Start bzw.
KAPITEL 3. GRUNDLAGEN
(a)
21
(b)
(c)
Abbildung 3.4: Splines mit unterschiedlichen Tension-Parametern. (a)
Tension = 0.0, (b) Tension = 0.5, (c) Tension = 1.0.
Abbildung 3.5: Catmull-Rom Interpolation. Punkte in rot stellen die Stützpunkte des Pfades dar. Punkte in blau sind nachträglich eingefügt, um die
Interpolation auch zwischen den Stützpunkten 1 und 2 bzw. 5 und 6 zu ermöglichen.
um das Ende des Pfades gespiegelt. Zur Verdeutlichung sei an dieser Stelle
auf Abbildung 3.5 verwiesen. Alle den Pfad definierenden Punkte sind rot,
die zur Interpolation zusätzlich eingefügten Punkte sind blau eingezeichnet.
Kapitel 4
Konzept
Im folgenden Kapitel wird das Konzept des Dry Garden MR inklusive aller Interaktionsmetaphern erläutert. Die Grundlage dafür wurde von der
japanischen Medienkünstlerin Keiko Takahashi erstellt und im Laufe des
Projektfortschritts fortlaufend angepasst und verfeinert. Einige Punkte des
ursprünglichen Konzeptes konnten auf Grund mangelnder zeitlicher und materieller Ressourcen nicht umgesetzt werden, andere wurden auf Grund der
Benutzerreaktionen auf frühe Prototypen geändert. Diese Änderungen erfolgten in Absprache mit der Künstlerin. Die Weiterentwicklungen an diesem
Konzept sind im vorliegenden Kapitel bereits enthalten, auf das ursprüngliche Konzept oder dessen Änderungen wird nicht näher eingegangen.
4.1
Zielsetzung
Allgemein formuliert, ist es das Ziel des Dry Garden MR, Angehörigen anderer Kulturkreise die Idee japanischer Sandgärten (auch bekannt unter dem
Synonym Zen Garten, Karesansui bzw. englisch: Dry Garden) mit Hilfe von
Computergrafik, Projektion und computergestützter Interaktionserkennung
näher zu bringen.
4.2
Setup
Wie die in 4.1 gezeigte Abbildung verdeutlicht, lehnt sich der Dry Garden MR in seinem prinzipiellen Aufbau an die unter 3.1 erwähnten TischVersionen von Zen-Gärten an. Diese Konzeptskizze lässt aber auch erkennen,
dass die Konzeption wichtige Details der technischen Umsetzung wie Art und
Richtung der Projektion sowie Funktionsweise der Interaktionserkennung bei
Seite lässt. Diese wurden vom Autor der vorliegenden Diplomarbeit in enger
Zusammenarbeit mit der Künstlerin selbst, mit Dipl. Ing. Dietmar Offenhuber sowie Dr. Hirokazu Kato und Dr. Michael Haller entwickelt.
22
KAPITEL 4. KONZEPT
23
Abbildung 4.1: Konzeptskizze zum Setup des Dry Garden MR aus [Tak05].
Das Ergebnis dieses iterativen Prozesses ist eine Medieninstallation mit
Tangible User Interface. Die grundsätzliche Anordnung entspricht der einer
klassischen Table-Top Installation und erlaubt mehreren Benutzern gleichzeitig mit der horizontalen Projektionsfläche zu interagieren.
4.3
Content
Wie in jedem Sandgarten gibt es auch im Dry Garden MR Sand und Steine.
Beim Dry Garden MR werden diese allerdings nicht nur in der Fantasie des
Betrachters zum Leben erweckt, sondern auch durch die Projektion eines
Non-Photorealistic Renderings. Dieses stellt Wasserströmungen und darauf
tanzende Blätter dar. Bei der Berechnung des Verlaufs dieser Wasserströmungen werden die Positionen der Steine im Dry Garden MR berücksichtigt.
Die Richtung der Wasserströmungen kann vom Benutzer durch Muster im
Sand bestimmt werden. Der Sand dient somit gleichzeitig als Eingabe- wie
auch als Ausgabemedium. Zusätzlich ist der Dry Garden MR das Habitat einer virtuellen Fischkolonie. Dabei handelt es sich um Cyprinus carpio, einer
speziell für japanische Gärten gezüchteten Gattung von Zierkarpfen. Diese
schwimmen unter der Sandschicht und tauchen erst zur Oberfläche auf, wenn
der Benutzer Löcher in die Granulatschicht gräbt. Sobald ein Fisch die Oberfläche erreicht hat, verweilt er dort um vom Benutzer in Händen gehalten
werden zu können.
KAPITEL 4. KONZEPT
(a)
24
(b)
Abbildung 4.2: Content des Dry Garden MR. (a) Konzept (aus [Tak05]).
(b) Umsetzung.
Abbildung 6.5(a) (a) zeigt das Konzept und ein Foto (b) zum Content des
Dry Garden MR. Bei (b) handelt es sich um eine Debugversion, die zusätzlich die für Wasserströmungen und Blätter an der Oberfläche berechneten
Pfade visualisiert. Erkennbar sind zwei Steine sowie der an deren Position
angepasste Verlauf der Wasserströmungen. Weiters treiben zwei Fische an
der Oberfläche.
4.4
Interaktionskonzept
Der folgende Abschnitt fasst die unterschiedlichen Interaktionsmetaphern
des Dry Garden MR zusammen. Gewisse Anknüpfungspunkte ergeben sich
zu [Whi98]. So die Projektion auf eine nicht plane Oberfläche, und die Möglichkeit des Benutzers, den eigenen Körper in eine Projektionsfläche zu verwandeln.
4.4.1
Interaktion durch die Hand des Benutzers
Dem Benutzer stehen zwei mögliche Arten der Interaktion mit dem Sand
des Dry Garden MR offen. Einerseits kann er durch Ziehen gerader Interaktionsmuster die Richtung der Wasserströmungen bestimmen.
In Abbildung 4.3 sind die Interaktionsmuster des Benutzers rot markiert.
Deutlich erkennbar ist, wie die Wasserströmungen ihre Richtung, jener der
Interaktionsmuster anpassen. Andererseits können die Fische des Dry Garden MR durch Graben von Löchern in die Sandschicht, zum Auftauchen
veranlasst werden. Dies geschieht erst wenn einer der Fische ein Loch direkt
über seiner momentanen Position wahrnimmt“. In Abbildung 4.4(b)) ist
”
das Loch in der Granulatschicht, sowie der Fisch im Moment des Erreichens
KAPITEL 4. KONZEPT
(a)
25
(b)
Abbildung 4.3: Durch die Richtung der Interaktionsspur (rote Markierung)
gibt der Benutzer die Richtung der Wasserströmungen vor. (a) 45◦ . (b) 85◦ .
(a)
(b)
(c)
(d)
Abbildung 4.4: Interaktionsmöglichkeiten durch die Hand des Benutzers.
Links jeweils das Konzept (aus [Tak05]) rechts die Umsetzung. In (a) und
(b) schwimmt ein Fisch zur Hand des Benutzers. In (c) und (d) wird dieser
durch den Benutzer in seiner Hand gehalten.
KAPITEL 4. KONZEPT
26
der Oberfläche erkennbar. Dabei werden die in Abschnitt 4.8.3 beschriebenen Oberflächenwellen ausgelöst. Sobald die Oberfläche erreicht ist, verbleibt
der Fisch dort um vom Benutzer in Händen gehalten werden zu können (vgl.
Abbildung 4.4(d)).
4.4.2
Interaktion mit den Steinen
Die Steine des Dry Garden MR stellen für Wasserströmungen, Blätter und
Fische natürliche Hindernisse dar. Das heißt, dass diese über die Position der
in der Realität vorhandenen Steine Bescheid wissen und diesen ausweichen.
Sobald der Benutzer einen Stein im Dry Garden MR platziert, entstehen
Wellen um die Interaktionsstelle. Die Wasserströmungen verlaufen um diese
Steine herum. Auch die Animationspfade der an der Oberfläche treibenden
Blätter werden entsprechend angepasst (vgl. dazu auch Abbildung 4.5).
(a)
(b)
(c)
(d)
Abbildung 4.5: Interaktion des Benutzers mit einem Stein. (a) und (c)
zeigen das Konzept (aus [Tak05]). (b) und (d) zeigt die Umsetzung.
KAPITEL 4. KONZEPT
4.4.3
27
Interaktion mit dem Bambusrechen
Wie einleitend beschrieben, kommen beim Zeichnen von Mustern in den
Sand von Sandgärten kleine Bambusrechen zum Einsatz. Beim Dry Garden
MR wurde der Sand wie unter 4.5.2 beschrieben durch PS1161 ersetzt. Da
dieses Granulat relativ grobkörnig ist, ist die Interaktion mit einem Bambusrechen nicht mehr möglich. Der Benutzer muss seine Muster daher wie
in Abschnitt 4.4.1 beschrieben mit der Hand ziehen. Ein mögliches alternatives Interaktionskonzept, welches den Rechen doch integriert, beschreibt
Abschnitt 4.7.
4.5
Hardware Setup
Der folgende Abschnitt beschreibt das Hardware Setup des Dry Garden
MR. Um die im Konzept geforderten Interaktionsmöglichkeiten zu erlauben,
wurde das in Abbildung 4.6 gezeigte Setup gewählt (Die Zahlen in Klammer
beziehen sich auf die Markierungen im Bild). Im weiteren Verlauf des Textes
wird der Begriff Infrarot durch IR abgekürtzt. Es handelt sich dabei um eine
Installationsanordnung die einer klassischen Tabletop Projektion entspricht.
Auf die horizontal angebrachte Projektionsscheibe wird sowohl von oben (4)
als auch von unten (5) projiziert. Die Projektion von beiden Seiten ist nur
deshalb möglich, weil auf der Projektionsscheibe eine Schicht PolystyrolGranulat (2) liegt. Die Interaktionserkennung erfolgt durch eine unterhalb
des Tisches angebrachte Kamera mit IR-Filter(1). Um einen ausreichend
starken Kontrast sicherzustellen leuchtet dieser ein IR-Scheinwerfer (3) entgegen. Die rechte Abbildung zeigt den Versuchsaufbau in einem Labor der
Fachhochschule Hagenberg. Auf den Projektor der Bestandteil des iPoint
ist (5) wird als Rückprojektor, auf den oberhalb der Installation montierten
Projektor (4) als Frontprojektor referenziert.
4.5.1
Peyote iPoint
Im konkreten Fall ist diese Scheibe Bestandteil des Peyote iPoint. Dabei handelt es sich um einen interaktiven Präsentationstisch aus lasergeschnittenem
Aluminium, der aus zwei Hauptbestandteilen zusammengesetzt ist: Der mit
thermisch verformten Plexiglas verkleidete starre Außenkorpus übernimmt
die statische Funktion, während ein um 360◦ frei drehbarer Innenkorb alle
audiovisuellen Komponenten beinhaltet.
Auf dem drehbaren Innenkorb liegt eine 40“ Rückprojektionsscheibe auf,
welche vom Rückprojektor über einen kleinen Spiegel angestrahlt wird. Der
Innenkorb wird über einen Schleifkontakt mit Strom versorgt, ansonsten
ist er in sich abgeschlossen. Des Weiteren befindet sich in dem Korb ein
Stereo-Soundsystem sowie eine PC der seine Daten mit Hilfe des Projektors
darstellt.
KAPITEL 4. KONZEPT
(a)
28
(b)
Abbildung 4.6: Hardwaresetup des Dry Garden MR. (a) Komponenten
Diagramm. (b) Versuchsaufbau.
Einen weiteren wichtigen Bestandteil des Peyote iPoint stellt dessen Interaktionserkennung dar. Direkt über der Rückprojektionsscheibe sind IRDioden sowie IR-Sensoren angebracht, die den Punkt der Interaktion erkennen. Eine von Peyote entwickelte Software interpretiert diese Daten und
positioniert unter Windows den Mauszeiger entsprechend. Diese Lösung zur
Interaktionserkennung kommt beim Dry garden MR aus mehreren Gründen
nicht zum Einsatz:
• Beschränkung auf einen Interaktionspunkt
Die mit dem Tisch ausgelieferte Software erlaubt nur die Erkennung
eines einzigen Interaktionspunktes. Die Installation sollte allerdings die
Interaktion mehrerer Benutzer erlauben.
• Verdeckung durch das Granulat
Da auf der Tischoberfläche der Sand“ des Dry Garden MR liegt, ver”
deckt dieser die IR-Sensoren. Die Interaktionserkennung kann daher
unter keinen Umständen mehr funktionieren.
Abschließend sei noch auf die LED-Beleuchtung des Peyote iPoint verwiesen. Diese besteht aus vier an den Innenseiten angebrachten Elementen, die
softwaregesteuert verschiedene Farben kombinieren können. Mangels einer
KAPITEL 4. KONZEPT
29
API wurde dieses interessante Ausgabemedium aber nicht in die Gesamtinstallation eingebunden.
4.5.2
Granulat
Essentieller Bestandteil eines Zen-Gartens ist Sand bzw. Kies. Da sich das
Setup zur Interaktionserkennung auf eine Rückprojektionsanordnung stützt,
muss dieser durch ein transparentes Medium ersetzt werden. Zwei unterschiedliche Materialien wurden getestet. Polystyrol der Firma Gabriel Chemie1 (Korndurchmesser 1mm) und PS1161 der Firma Slupetzky2 (Korndurchmesser 2-3mm).
Abbildung 4.7: Unterschiedliche Projektionsmaterialien im Vergleich.
V.l.n.r.: Karton, PS1161, Polystyrol.
Abbildung 4.7 zeigt die Materialien beim Einsatz einer Frontprojektion
im Vergleich. Ganz links ist die Projektion auf eine glatte Oberfläche erkennbar. Auffällig ist in diesem Fall das fein strukturierte Muster, das durch die
Rasterung des LCD -Panels des Frontprojektors entsteht. Das mittlere Bild,
zeigt die Projektion auf PS1161. Durch dessen Grobkörnigkeit ergibt sich
eine sehr starke Streuung des auftreffenden Lichtes. Daraus resultieren relativ unscharfe Bilder. Ganz rechts in der Abbildung, ist das feinkörnige Polystyrol erkennbar. Der geringere Korndurchmesser verringert die Streuung,
was einen schärferen Bildeindruck als die Projektion auf PS1161 bewirkt.
Trotzdem fiel die Entscheidung zu Gunsten von PS1161. Dies liegt in der
haptischen Qualität der beiden Materialien begründet. Das feinkörnige Granulat bleibt an den Händen der Benutzer kleben, worauf Versuchspersonen
sehr negativ reagierten. Für den Betreiber der Installation ist dagegen das
feinkörnige Granulat unzumutbar, weil es von den Benutzern im gesamten
Raum des Versuchsaufbaus verteilt wird.
1
2
http://www.gabriel-chemie.com/
http://www.slupetzky.at/
KAPITEL 4. KONZEPT
30
Abbildung 4.8: Rückprojektion beim Einsatz von PS1161.
4.5.3
Projektionssetup und Beleuchtung
Es kommt das in Abschnitt 4.5.1 beschriebene Rückprojektionssetup zum
Einsatz. Das auf der Rückprojektionsscheibe verteilte Granulat ist zwar
transparent, allerdings sind die von unten projizierten Bilder kaum erkennbar (vgl. Abbildung 4.8). Aus diesem Grund, liefert eine zusätzliche FrontProjektion Bilder von oberhalb der Installation.
Um genügend Abstand zur Projektionsscheibe zu gewährleisten, wird
der zweite Projektor an der Decke des Versuchslabors montiert. Die dafür
zum Einsatz gekommene Befestigung dient gleichzeitig der Aufnahme des
zur Interaktionserkennung benötigten IR-Scheinwerfers.
Dieser ist nicht zwingend erforderlich. Der IR-Anteil der im Versuchsraum vorhandenen Beleuchtung ist groß genug, um der Kamera genügend
Licht in diesem Frequenzbereich zu Verfügung zu stellen. Durch das auf
der Projektionsscheibe verteilte Granulat sind die von der Kamera aufgezeichneten Bilder relativ dunkel. Werden vom Benutzer zusätzlich Steine
auf den Tisch gelegt, sind diese zwar als dunkle Stellen im Bild erkennbar,
der Kontrast zwischen den Grauwerten des Hintergrundes und den Steinen
ist allerdings sehr gering (vgl. Abbildung 4.9(a)). Die Interaktionserkennung
arbeitet dadurch nicht mehr zuverlässig.
Um den Kontrast zu verbessern kommt der erwähnte IR-Scheinwerfer
zum Einsatz. Er wird mit einem Diffuser versehen, um Hotspots im Kamerabild zu vermeiden. Der Raum wird komplett verdunkelt. Somit trifft das
gesamte IR-Licht direkt von oben auf den Tisch auf. Dadurch steigt der
Kontrast sowohl der hellen als auch der dunklen Stellen stark an (vgl. Ab-
KAPITEL 4. KONZEPT
(a)
31
(b)
Abbildung 4.9: Bild der Kamera zur Interaktionsermittlung. (a) Ohne Verdunkelung. (b) Mit Verdunkelung und zusätzlichem IR-Scheinwerfer.
Abbildung 4.10: Abstimmung von Rückprojektion und Interaktionserkennung. Mittels der grünen Marker gelingt es, die Kamera der virtuellen Szene
auf die Region of Interest der Interaktionserkennung abzustimmen.
bildung 4.9(b)) und die Konturen der Interaktionsmuster und Steine sind
klar erkennbar. Ein weiterer Vorteil der Verdunkelung liegt darin, dass die
projizierten Bilder hell und für den Benutzer gut erkennbar sind.
Weiters ist es für die Funktion der Installation von enormer Wichtigkeit,
dass das Kamerabild auf die beiden Projektionen abgestimmt wird. Dazu
kommen die in Abbildung 4.10 rot hervorgehobenen Marker zum Einsatz.
Einerseits definieren sie die Region of Interest des Kamerabildes und somit
auch die Begrenzung der Interaktionsfläche. Andererseits muss beim Setup
der Installation darauf geachtet werden, dass sich die Fläche der Frontprojektion, genau mit dem durch die Marker begrenzten Rechteck deckt. Die
KAPITEL 4. KONZEPT
32
Rückprojektion, deckt immer die gesamte Rückprojektionsscheibe des iPoint
ab. Aus diesem Grund muss die Anpassung der Perspektive des Renderings
in der Applikation erfolgen. Dies gelingt durch Veränderung der virtuellen
Kameraposition der dargestellten dreidimensionalen Szene. In Abbildung
4.10, ist die Begrenzung der Szene durch die grüne Fläche markiert.
Abschließend stellt sich die Frage, warum überhaupt ein eingeschränkter Bereich und nicht die gesamte Fläche der Rückprojektionsscheibe als
Interaktionsbereich zum Einsatz kommt. Dies liegt in der zu Verfügung stehenden Hardware begründet. Der zum Einsatz gekommene IR-Scheinwerfer
strahlt der Kamera direkt entgegen. Durch den Diffuser, wird Hotspotting
zwar abgeschwächt, kann allerdings nicht komplett vermieden werden. So
nimmt die Intensität der Grauwerte im Kamerabild zum Rand hin stark ab.
Die Begrenzung der Interaktionsfläche wird auf den Bereich eingeschränkt,
der genügend hell und gleichmäßig ausgeleuchtet ist.
4.5.4
Kamera
Die im Konzept eingeforderte Interaktionserkennung wird mit der FirewireKamera Point Greyscale Dragonfly realisiert. Als Objektiv kommt das Computar T2314FICS-3 3 zum Einsatz. Dies weist eine Fixbrennweite von 2.3
mm, eine manuell einstellbare Blende sowie einen manuellen Fokus auf.
Für das Projekt wurde das Objektiv zusätzlich mit dem IR-Filter helioc
nm) ausgestattet. Durch den Betrieb
pan RG 780 (Sperrfrequenz bei 780
im IR-Bereich, kann die Kamera im Graustufenmodus betrieben werden.
Hierbei ist es von entscheidendem Vorteil, dass deren Sensor nativ Grauwerte liefert. Zur Erklärung dieses Vorteils folgt ein kurzer Exkurs über die
digitale Bildaufzeichnung mitCCD -Kameras. Bei Standard CCD -Kameras
sind die fotosensitiven Zellen des CCD (Charged Coupled Device) abwechselnd mit Farbfolien in rot, grün und blau beklebt. Pro Bildpunkt steht
also nur ein Rot- oder ein Grün- oder ein Blauwert zu Verfügung. Um für
einen Bildpunkt den korrekten RGB-Wert zu ermitteln, wird daher durch
die Software der Kamera zwischen den Farbwerten der benachbarten Zellen
interpoliert. Wird der Graustufenmodus aktiviert, müssen diese RGB-Daten
von der Kamera-Software wieder zu Graustufenbildern zusammengerechnet
werden. Diese zweimalige Interpolation bewirkt einen weiteren Verlust an
Bildqualität. Bei der Dragonfly fällt diese zweimalige Interpolation weg, die
Kamerabilder sind von entsprechend hoher Qualität.
Ein weiterer Vorteil des gewählten Modells ist dessen Firewire-Schnittstelle. Derentwegen können die Bilder der Kamera unkomprimiert an den
aufzeichnenden PC weitergegeben werden. Die beim Einsatz normaler USBKameras durch deren verlustbehaftete Komprimierung auftretenden Komprimierungsartefakte werden dadurch vermieden.
3
http://www.computar.jp/
KAPITEL 4. KONZEPT
4.6
33
Erweiterungen
Das ursprünglichen Konzept von Keiko Takahashi, sah neben linearen auch
kreis- und wellenförmige Interaktionsmuster vor. Die Erkennung solcher Muster durch den Interaktionsserver und die entsprechende Reaktion des Renderclient wurde aus Zeitgründen jedoch nicht implementiert.
Bei einer vom Autor dieser Arbeit entwickelten Erweiterung, die zu einer
Verbesserung des Interaktionserlebnisses führt, werden nicht nur die Handpositionen der Benutzer, sondern zusätzlich die Umrisse der interagierenden
Hände bestimmt. Diese Bereiche könnten in der Projektion von oben maskiert werden. Somit würden die Benutzer nicht mehr sofort wahrnehmen,
dass Wasserströmungen und Blätter von oben projiziert werden. Entsprechend größer wäre ihre Überraschung, die Projektion eines Fisches in ihre
Hand zu entdecken.
4.7
Alternatives Konzept
Das in den vorangegangenen Abschnitten beschriebene Konzept ist nur eines
von mehreren die vor der Umsetzung des Projektes entwickelt wurden. Diese
Konzepte wurden allerdings nicht umgesetzt und sind in dieser Arbeit daher
auch nicht näher beschrieben. Aus den ersten Erfahrungen, die mithilfe des
auf dem Peyote iPoint aufbauenden Prototypen, gewonnen wurden, resultiert das in Folge beschriebene, weiterentwickelte Konzept (vgl. Abbildung
4.11). Es verbessert die folgenden Schwachstellen des bisherigen Konzeptes:
• Geringe optische Qualität des eingesetzten Granulats.
• Beschränkung auf primitive Interaktionsmuster.
• Verdunkelung des Raumes.
• Verzicht auf den Einsatz des Rechens.
Da der Peyote iPoint nicht vom Auftraggeber des Projektes zu Verfügung gestellt wurde, ist das weiterentwickelte Konzept unabhängig von
dessen Einsatz. Die in Folge zur Beschreibung verwendeten Ziffern beziehen sich auf Abbildung 4.11. Das Projekt stützt sich auf den Einsatz eine
simplen Tisches. In dessen Tischplatte ist eine Auslassung eingearbeitet, die
der Aufnahme einer Glaswanne dient. Diese Glaswanne wird mit weissem
Sand (4) gefüllt, der das das grobkörnige PS1161 ersetzt. Dies bietet den
Vorteil, besser erkennbarer Projektionsbilder. Weiters können somit traditionelle Bambusrechen (3) zur Interaktion verwendet werden. Der Benutzer
steht in keinem direkten Kontakt mit dem Granulat. Der kulturelle Kontext eines Zen-Garten wird dadurch stärker gewahrt. Des Weiteren liegen
durch den Verzicht des Einsatzes von PS1161, die Steine näher an der Tischoberfläche. Deren Konturen sind dadurch im Kamerabild schärfer und
KAPITEL 4. KONZEPT
34
Abbildung 4.11: Alternatives Setup für den Dry Garden MR.
klarer. Somit wird der Verzicht auf die Verdunkelung des Raumes möglich.
Je nach Lichtsituation muss evtl. ein IR-Scheinwerfer mit Diffuser oberhalb
der Installation angebracht werden.
Die Projektion ist in diesem Fall auf eine reine Frontprojektion (1) von
oberhalb der Installation beschränkt. Die Interaktionsmetapher des Löcher
”
grabens“ entfällt dadurch. Fische schwimmen genauso wie Blätter an der
Oberfläche.
Interaktionserkennung: Diese geschieht weiterhin mit einer IR-Kamera,
die unterhalb des Tisches montiert ist. Sie ist gemeinsam mit den restlichen Hardware-Komponenten in einer abschließbaren Box (5) unterhalb des
Tisches angebracht. Diese ist fix mit dem Tisch verbunden, um die Ausrichtung der Kamera auf den Tisch nicht zu gefährden. Das IR-Tracking
wird wesentlich vereinfacht, indem nur noch die Positionen der Steine auf
der Tischoberfläche ermittelt werden müssen. Für die Erkennung der In-
KAPITEL 4. KONZEPT
(a)
35
(b)
Abbildung 4.12: (a) Traditioneller Bambusrechen. (b) Konzept des Rechens mit Komponenten zur Interaktionserkennung. Das Ende des Rechens
ist mit IR-Dioden ausgerüstet (1), deren Stromversorgung ist in den Griff
integriert (2).
teraktionsmuster wird ein völlig neuer Ansatz gewählt. Dazu werden die
traditionellen Bambusrechen (vgl. Abbildung 4.12) mit IR-Dioden ausgestattet. Neben dem Projektor ist oberhalb der Installation eine zusätzliche
IR-Kamera montiert.
Da aus der Richtung des Tisches kaum Licht im IR-Frequenzbereich emittiert wird, heben sich die an den Rechen angebrachten IR-LEDs sehr stark
als helle Stellen vom relativ dunklen Hintergrund des Kamerabildes ab. Pro
Rechen sind mehrere LEDs angebracht. Somit ist neben der Bestimmung der
Position auch zu jedem Zeitpunkt eine genaue Bestimmung der Ausrichtung
des Rechens möglich.
Zur Bestimmung der Interaktionsmuster werden für jeden Rechen, die
jeweiligen Bewegungs-Trajektorien aufgezeichnet. Diese können durch den
Einsatz eines Pattern-Matching Verfahrens auf Ähnlichkeit verglichen werden. In einer ersten Version könnte dies durch so genanntes Chamfer Matching realisiert werden. Dieses Verfahren hat zum Nachteil, nicht rotationsinvariant zu sein. Damit die Interaktionsmuster der Benutzer, unabhängig
von deren Rotation erkannt werden können, muss ein komplexeres Verfahren zum Einsatz kommen. Das Gebiet des Pattern-Matching ist ein eigenes
Forschungsgebiet und wird daher im Rahmen dieser Diplomschrift nicht behandelt.
4.8
Konzepte des Renderings
Der folgende Abschnitt beschreibt die Konzepte die hinter dem Rendering
des Dry Garden MR stehen. Dabei werden die wichtigsten Punkte des gra-
KAPITEL 4. KONZEPT
36
fischen Konzeptes aufgegriffen und einzeln analysiert. Zur besseren Veranschaulichung, befindet sich neben jeder Konzeptskizze die entsprechende Abbildung der fertigen Implementierung.
4.8.1
Wasserströmungen
Für die Visualisierung der Wasserströmungen, sowie der Blätter die an der
Oberfläche treiben, wurden auf Grund der schwierigen Projektionsbedingungen (die Projektionsoberfläche ist nicht plan und nicht glatt) grafisch sehr
einfache Elemente gewählt. Diese werden wie in Abschnitt 3.4.1 beschrieben,
anhand vorberechneter Pfade animiert. Bei der Berechnung dieser Pfade
werden die Hindernisse (= Steine an der Oberfläche) berücksichtigt.
Pfadberechnung durch Stützpunktverschiebung
Im ersten Ansatz wird ein Pfad mit einer fix vorgegebenen Anzahl an Stützpunkten berechnet. Alle Stützpunkte dieses Pfades liegen zu Beginn des
Algorithmus auf einer Geraden. Über diese Stützpunkte wird iteriert, und
jeweils überprüft, ob sich die aktuelle Position mit der eines Hindernisses
deckt. Diese Überprüfung findet im dreidimensionalen Raum statt. Dabei
wird an der Stelle jedes Hindernisses eine Kugel platziert, deren Radius um
einen konstanten Faktor (im konkreten Fall 2.5) größer als der Durchmesser
des Hindernisses ist. Im weiteren Verlauf des Textes werden diese Kugeln als
Influencespheres bezeichnet. In Abbildung 4.14 sind drei solche Influencesphere als grüne Wireframe-Modelle erkennbar. Mit Hilfe von
(X − M )3 = r 3
(4.1)
wird nun berechnet, ob sich der aktuelle Stützpunkt innerhalb der Influencesphere befindet. Ist dies der Fall, dann wird der Punkt entlang der
Normalen der Geraden, auf der die Stützpunkte liegen, vom Hindernis weg“
”
verschoben (vgl. auch Abbildung 4.8.1). Die Distanz ist dabei die Hälfte der
Strecke zwischen dem Schnittpunkt (Kugel in dunkelgrün) der Normalen
mit der Influencesphere, und der ursprünglichen Position des Stützpunktes
(Kugel in grün) selbst. Durch die Gewichtung der ermittelten Distanz mit
dem Faktor 0.5 werden Punkte, die näher am Hindernis liegen, stärker von
diesem weggeschoben als Punkte die weit vom Hindernis entfernt sind. Die
resultierende Position (Kugel in hellgrün), kann sich durch die Überschneidung mit weiteren Influencespheres erneut verändern.
Resultat: Die Qualität der entstehenden Pfade ist beim reinen Verschieben von Stützpunkten sehr davon abhängig, wie viele Stützpunkte pro Gerade definiert werden. Werden zu wenige Stützpunkte festgelegt, führen die
interpolierten Pfade nicht um das Hindernis herum (vgl. Abbildung 4.14
Kugel ganz rechts).
KAPITEL 4. KONZEPT
(a)
37
(b)
Abbildung 4.13: Berechnung der Pfadverläufe durch Verschieben bestehender Stützpunkte. (a) Konzept. (b) Screenshot.
Abbildung 4.14: Berechnung des Pfadverlaufes durch Verschieben bestehender Stützpunkte. Berechnete Pfade verlaufen durch die Hindernisse hindurch (Hindernis links unten).
KAPITEL 4. KONZEPT
38
Pfadberechnung durch Schnitt von Kreis und Gerade
In einem zweiten Ansatz wurde der im Folgenden beschriebene Algorithmus
entwickelt: Die Anzahl an Stützpunkten, die einen Pfad durch den Dry Garden MR beschreibt ist zu Beginn auf zwei beschränkt (Jeweils ein Punkt an
den Rändern des Begrenzungsrechtecks).
Es wird über alle Hindernisse iteriert. Dabei wird überprüft, ob sich
zwischen dem aktuellen Pfad und der Influencesphere des aktuellen Hindernisses eine Überschneidung ergibt. Diese und alle weiteren Berechnungen
finden im zweidimensionalen Raum statt. Hindernisse und Influencespheres
werden somit durch Kreise repräsentiert.
Durch das Gleichsetzen von Geraden- und Kreisgleichung werden die
Schnittpunkte S1 (Kugel in rot) und S2 (Kugel in blau) berechnet, welche
zu dem aktuellen Pfad hinzugefügt werden.
(a)
(b)
Abbildung 4.15: Berechnung der Pfadverläufe durch Einfügen des Schnittpunktes zwischen Kreis und Gerade. (a) Konzept. (b) Screenshot.
Außerdem wird ein weiterer Stützpunkt (im weiteren Verlauf des Textes
als H1 bezeichnet, in Abbildung 4.8.1 als hellgrüne Kugel erkennbar) eingefügt. Dessen Position errechnet sich folgendermaßen: Ausgehend von der
Halbierung der Strecke durch die beiden Schnittpunkte (Kugel in dunkelgrün) wird die Normale des Pfades erneut mit der Influencesphere geschnitten. Die Strecke zwischen dem Schnittpunkt der näher zum Pfad liegt, und
dem Halbierungspunkt wird im Verhältnis 50:50 geteilt. Die Teilungsposition
ist nun die Position die dem Pfad hinzugefügt werden soll. Weiters wird gespeichert, ob sich diese Position (im weiteren Verlauf H1 genannt) links oder
rechts vom gerade aktuellen Pfad befunden hat (isLeft-Berechnung). Damit
sichergestellt ist, dass die animierten Objekte um das Hindernis herum strömen, wird der Normalabstand des soeben berechneten Punktes vor seinem
KAPITEL 4. KONZEPT
39
Hinzufügen zum Pfad noch auf mindestens die Hälfte der Dimension des
entlang des Pfades animierten Objektes gesetzt.
Resultat: Gegenüber der in Abschnitt 4.8.1 beschriebenen Methode ergeben sich keine erkennbaren Nachteile. Für Influencespheres mit geringem
Radius biegt“ sich die Kurve zwischen den Schnittpunkten und dem Mit”
telpunkt sehr stark durch“. Die in Abschnitt 4.8.1 beschriebene erweiterte
”
Form des Algorithmus berücksichtigt diese Problematik.
Probleme: Eine Problematik die sich erst bei näherer Beschäftigung mit
diesem Ansatz offenbart ist die Notwendigkeit, die berechneten Punkte in
der richtigen Reihenfolge zum Pfad hinzuzufügen. In der konkreten Implementierung stellt ein Pfad eine Liste an Punkten dar. Zur Interpolation wird
über diese Liste in aufsteigender Reihenfolge iteriert. Somit wird die Reihenfolge, in der die Punkte in der Liste gespeichert sind, ausschlaggebend für
die Interpolation. Werden die berechneten Schnittpunkte einfach in der Reihenfolge ihrer Berechnung zum Pfad hinzugefügt, muss dies aus Sicht der
Interpolation nicht die richtige sein. Abbildung 4.8.1 zeigt dieses Problem
deutlich.
(a)
(b)
Abbildung 4.16: Pfadberechnung durch Schnitt von Kreis und Gerade. (a)
Ohne Vorsortierung. (b) Sortiertes Einfügen in den Pfad.
Lösung: Um die neu berechneten Punkte in der richtigen Reihenfolge zum
Pfad hinzuzufügen, wird für den einzufügenden Punkt, der Abstand vom
ersten Stützpunkt des Pfades berechnet. Es wird an der Indexposition des
ersten Stützpunktes, der einen größeren Abstand vom Ursprung als der des
KAPITEL 4. KONZEPT
40
einzufügenden Punktes aufweist, eingefügt. Die Indizes aller Stützpunkte die
nach diesem Punkt folgen werden um eins erhöht.
Einfügen eines zusätzlichen Stützpunktes
Bei dieser Methode wird zusätzlich zu den durch 4.8.1 berechneten Stützpunkten ein weiterer Stützpunkt der, in Flussrichtung der Wasserströmung,
vor dem Mittelpunkt liegt, eingefügt. Zur besseren Veranschaulichung sei an
dieser Stelle auf Abbildung 4.8.1 verwiesen. Die Strecke zwischen dem ersten Schnittpunkt (rote Kugel) von Kreis und Geraden und dem Mittelpunkt
(dunkelgrüne Kugel) wird im Verhältnis 60:40 geteilt. Ausgehend von diesem
Teilungspunkt (braune Kugel) wird der Normalen der Geraden gefolgt. Die
Richtung der gefolgt wird, ist durch die isLeft()-Berechnung von H1 vorgegeben. Dadurch ist sichergestellt, dass der soeben berechnete Stützpunkt
(gelbe Kugel) auf derselben Seite des Pfades liegt wie H1.
(a)
(b)
Abbildung 4.17: Berechnung der Pfadverläufe durch Schnitt zwischen
Kreis und Gerade und zusätzlichem Einfügen eines Hilfspunktes. (a) Konzept. (b) Screenshot.
Es ist nicht notwendig einen zusätzlichen Stützpunkt, in Flussrichtung
nach dem Hindernis einzufügen, da der so entstandene Wasserverlauf eher
dem natürlichen (tropfenförmigen) Fluss des Wassers entspricht.
Abschließend betrachtet ergibt die Methode die Animationspfade der
Wasserströmungen um Hindernisse herum im Voraus zu berechnen zwei
Vorteile. Zum einen muss nicht während der Animation an und für sich,
fortlaufend überprüft werden, ob die animierten Objekte, mit den Hindernissen kollidieren. Zum anderen erfolgt die Berechnung neuer Pfade immer
nur dann, wenn sich die Anzahl der Hindernisse oder die durch den Benutzer
vorgegebene Flussrichtung ändert.
KAPITEL 4. KONZEPT
4.8.2
41
Animation der Fische
Auch für die Fische des Dry Garden MR werden die Pfade denen diese folgen, im Voraus berechnet. Die Punkte dieser Pfade werden für jeden Fisch
zufällig gesetzt. Sobald ein Fisch das Ende eines Pfades erreicht hat, wird ein
neues Ziel per Zufall generiert und dessen Position dem Pfad hinzugefügt.
Dabei befinden sich alle Ziele auf demselben y-Level im Weltkoordinatensystem. Gräbt der Benutzer ein Loch in die Granulatschicht, kann er dadurch
ein neues Ziel setzen, das an der Oberfläche des Dry Garden MR liegt. Sobald
ein solches Ziel erreicht ist, bleibt der Fisch an dieser Position und wartet
darauf, vom Benutzer aufgenommen zu werden. Zusätzlich werden beim Erreichen der Oberfläche die unter 4.8.3 beschriebenen Oberflächenwellen ausgelöst. Zur Berechnung der jeweils aktuellen Position im Raum, kommt die
Catmull-Rom Spline Interpolation zum Einsatz. Die korrekte dreidimensionale Ausrichtung des entsprechenden Modells, wird über Rotationen um die
Achsen des lokalen Koordinatensystems gewährleistet. Diese Vorgehensweise
gilt für alle dreidimensionalen Objekte des Dry Garden MR. Die Rotationen
erfolgen immer in der Reihenfolge x, y, z. Zur Berechnung der Rotationswinkel der Fische wird jeweils deren letzte Position im Weltkoordinatensystem
gespeichert, und die Differenz zur aktuell berechneten Position ermittelt.
Dieser Richtungsvektor stellt die Grundlage der Berechnung der Rotationswinkel um die lokalen Koordinatenachsen dar. Vor dieser Berechnung wird
mit Hilfe eines konstanten Thresholds pro Achse vermieden, dass eine zu geringe Änderung die Ergebnisse der Rotationsberechnung verfälschen. Ohne
diese Treshholds kommt es zu einem unkontrollierten Zucken“ der Fische,
”
da Änderungen in der Position durch das langsame Schwimmen der Fische
0 sein können und somit auch der entsprechende Winkel 0◦ beträgt. Zur
Berechnung der Rotationswinkel kommt die Methode zum
Einsatz. Diese liefert im Vergleich zur normalen Arcus Tangens Berechnung
keine Werte im Bereich von −π/2 bis π/2, sondern Werte zwischen −π und
π. Dies hat den Vorteil, dass für die eindeutige Zuordnung eines Winkels
keine zusätzliche Überprüfung der Eingangsparameter mehr notwendig ist.
In den meisten Fällen werden die Fische am selben y-Level des Weltkoordinatensystems animiert. Es findet daher lediglich um die y-Achse eine
Rotation statt. Um diese Rotationen langsam und rund von Statten gehen
zu lassen, werden 10 Werte zwischengespeichert. Deren Mittelwert ergibt immer den aktuellen Rotationswinkel. Die in [Ben03, Kap. 7.2.2] angesprochene
Problematik des Gimbal Lock tritt vereinzelt auf. Durch die Verwendung von
Quaternionen ließe sich dieses Problem leicht umgehen.
Sekundäre Animationen der Fische
Ein schwimmender Fisch zeichnet sich nicht nur durch seine Vorwärtsbewegung aus. Um Vortrieb zu generieren, bewegt er Körper und Flossen glei-
KAPITEL 4. KONZEPT
42
chermaßen. Um diese Bewegung zu simulieren, wurde im ersten Ansatz darauf zurückgegriffen, für jede Körperstellung ein eigenes Modell zu laden.
Zwischen den einzelnen Modellen wird im Zuge der Animation ohne Interpolation umgeschalten. Um den dadurch bedingten statischen Eindruck zu
vermeiden, wäre der Umstieg vom OBJ - auf das MD2 -Format ein geeigneter Ansatz. Dieses Format unterstützt die Interpolation zwischen einzelnen
durch Keyframes vorgegebene Posen. Eine Portierung des Modelloaders für
Processing steht ebenfalls zu Verfügung.
4.8.3
Oberflächenwellen
Neben den Wasserströmungen treten an der Oberfläche des Dry Garden
MR auch Wellen auf, sobald ein Fisch diese erreicht hat, bzw. ein Benutzer einen Stein auf dessen Oberfläche platziert. Auch diese Wellen verfolgen
ein grafisch sehr einfaches Konzept. Ausgehend vom Zentrum der Interaktion werden konzentrische Kreise gezeichnet, deren Alpha-Wert in direktem
Verhältnis zum Abstand vom Zentrum des Hindernisses steht. Je weiter sich
diese Oberflächenwellen vom Zentrum entfernen, desto transparenter werden
sie. Sobald die Transparenz den Wert 0 erreicht hat, wird ein entsprechendes Sichtbarkeitsflag auf gesetzt, und im Anschluss daran auch das
Objekt selbst zerstört.
Kapitel 5
Implementierung
Das folgende Kapitel behandelt die Implementierung, des in Kapitel 4 beschriebenen Konzeptes.
Ausgangspunkt stellt die Beschreibung der Struktur des Dry Garden MR
dar. Die so gewonnene Übersicht, wird anschließend durch die Beschreibung
der konkreten Umsetzung der eingesetzten Algorithmen vertieft.
Weiters werden Besonderheiten die bei der Verwendung der zum Einsatz
gekommenen Bibliotheken auftreten, durch den Einsatz kurzer aber aussagekräftiger Codebeispiele erläutert. Dadurch wird vermittelt, welche Schritte
notwendig sind, um eine Bildverarbeitung mit Hilfe des ARToolkits bzw. ein
Rendering durch den Einsatz von Processing zu ermöglichen.
5.1
Struktur
Der folgende Abschnitt beschreibt die Struktur der Gesamtinstallation (vgl.
dazu auch Abbildung 5.1). Diese setzt sich aus zwei Hauptbestandteilen zusammen. Interaktionserkennung und Rendering. Im weiteren Verlauf werden
diese als eigenständige Applikationen entwickelten Module als Renderclient
und Interaktionsserver bezeichnet. Zu deren Implementierung kamen unterschiedliche Programmiersprachen zum Einsatz. Java in Kombination mit
Processing für den Renderclient und C zur Implementierung des Interaktionsserver s. Um einen Datenaustausch zwischen diesen beiden Komponenten
zu ermöglichen, wurde die Kommunikation über TCP Socketverbindungen
realisiert. Dadurch können die beiden Komponenten auf zwei verschiedenen
PC s ausgeführt werden. Dies ist auch bei der konkreten Implementierung der
Fall. Als Interaktionsserver dient ein PC unter MS Windows, der für den Anschluss der Kamera mit einer 6-poligen IEEE 1394 Schnittstelle ausgestattet ist. Über diese Schnittstelle wird die Kamera auch mit Strom versorgt.
Als Renderclient kommt der PC der Bestandteil des iPoint ist, zum Einsatz. Dieser ist mit einer Dualhead-Grafikkarte ausgestattet, die wiederum
das Signal für die beiden zum Einsatz kommenden Projektoren liefert. Das
43
KAPITEL 5. IMPLEMENTIERUNG
44
Abbildung 5.1: Strukturdiagramm des Dry Garden MR.
Signal des ersten Ausganges wird zusätzlich mit Hilfe eines Videosplitters
aufgeteilt. Diese Vorgehensweise gibt dem Softwareentwickler bzw. Administrator der Applikation die Möglichkeit das Bild über einen Kontrollmonitor
zu überprüfen.
Die Gliederung des Kapitels folgt dieser zweigeteilten Struktur und ist
ebenfalls in die Beschreibung von Interaktionsserver und Renderclient geteilt.
5.2
5.2.1
Interaktionsserver
Struktur
Der Interaktionserver wurde in mehrere Module aufgeteilt um einzelne Komponenten bei Bedarf einfach austauschen zu können. Dadurch kann mit Hilfe
einer einzigen Preprozessoranweisung zwischen der Interaktionserkennung
mittels Kamera und einer Debugversion umgeschalten werden. Diese Debugversion generiert Positionen für die Steine an der Oberfläche, für Hände
und für Löcher in der Granulatschicht, sowie die Richtung der Interaktion
entsprechend der Vorgaben des Benutzers via Keyboard. Der Ressourcenverbrauch der Debugversion ist minimal. Dadurch kann diese problemlos
KAPITEL 5. IMPLEMENTIERUNG
45
gleichzeitig auf demselben Rechner wie der Renderclient ausgeführt werden.
Eine solche Debugversion zu erstellen ist im Allgemeinen bei der Arbeit an
einer Medieninstallationen äußerst hilfreich, da dies den Entwicklungsprozess vom komplexen Hardwaresetup trennbar macht.
Wie beschrieben kommt zur Erfassunf und zur Analyse der Interaktionsdaten das ARToolkit zum Einsatz. Dieses steht als Bibliothek für die
Programmiersprache C zu Verfügung. Aus diesem Grund ist auch der restliche Interaktionsserver komplett in C implementiert. Die erwähnte Strukturierung erfolgte daher nicht durch ein objektorientiertes Softwaredesign im
klassischen Sinn, sondern durch ein Aufteilen in mehrere Quelldateien.
Die beiden Hauptbestandteile des Interaktionsservers stellen die Interaktionserkennung sowie die Implementierung der Netzwerkkommunikation
dar. Die folgenden Abschnitte gehen detailliert auf diese beiden Komponenten ein.
5.2.2
Ablauf
Nach erfolgreicher Initialisierung von Viewport und Displaymode findet die
Initialisierung der Kamera statt. Sobald diese abgeschlossen ist, wird einmalig das Maskierungsbild anhand einer zuvor generierten Datei zur Beschreibung der Region of Interest erstellt. Im nächsten Schritt wird parallel dazu
die Netzwerkkommunikation in einem neuen Thread gestartet. Diese beiden
Threads werden in der Folge als Bildverarbeitungs-Thread und als Netzwerk -Thread bezeichnet, und jeweils in einem eigenen Abschnitt detailiert
beschrieben.
5.2.3
Interaktionserkennung
Nach Abschluss der Initialisierungsphase geht der Bildverarbeitungs-Thread
in den Mainloop über. Dieser wird bis zum Beenden der Applikation durchlaufen und beinhaltet die folgenden Schritte:
1. Aktuelles Kamerabild anfordern.
2. Kamerabild maskieren.
3. Differenzbild erstellen.
4. Thresholds für Hindernisse und Löcher bilden.
5. Binäre Regionen der Threshold-Bilder finden.
6. Features (Hauptachse, Exzentrizität) der Regionen berechnen.
7. Koordinaten der Regionen normalisieren.
Zum besseren Verständnis werden in den folgenden Abschnitten, die einzelnen Schritte des Mainloops genauer betrachtet. Die Darstellung der Ergebnisse dieses Kapitels finden sich in Abbildung 5.2.
KAPITEL 5. IMPLEMENTIERUNG
46
(a)
(b)
(c)
(d)
(e)
(f)
Abbildung 5.2: Die einzelnen Schritte der Bildanalyse. Durch die roten
Markierungen sind die Marker zum Abstecken der Region of Interest hervorgehoben. (a) Hintergrundbild, (b) Ausgangsbild, (c) Differenzbild, (d) Thresholdbild, (e) Regionenanalyse der dunklen Regionen, (f) Erkannte Interaktionsmuster. Der Stein ist rot, die Interaktionsspur grün und ein Loch in der
Granulatschicht gelb umrandet. Die gezeigten Screenshots wurden mit den
folgende Einstellungen erstellt: Unterer Threshold = 40, Oberer Threshold
= 235, Threshold Differenzwert = 45.
KAPITEL 5. IMPLEMENTIERUNG
47
Initialisierung der Kamera
Der Interaktionsserver greift direkt auf das Point Greyscale SDK zur Analyse der Kamerabilder zu. Dies gewährleistet zwar einerseits optimale Performance (30 fps @ 640 x 480), bringt andererseits aber den Nachteil mit
sich, hinsichtlich Softwareupdates vom Hersteller der Kamera abhängig zu
sein. Dies ist im konkreten Fall vor allem deshalb ein Problem, weil folgender
Fehler reproduzierbar auftritt. Überschreitet die CPU-Belastung 75%, liefert
die Kamera keine weiteren Bilder. Durch den Einsatz kürzerer Kabel verbessert sich dieses Problem zwar, es tritt aber weiterhin vereinzelt auf. Laut
Herstellerangaben, tritt das Phänomen nur in Verbindung mit bestimmten
Firewire-Kontrollern auf. Für Tests mit anderer Hardware waren aber weder zeitliche noch materielle Ressourcen vorhanden. Somit bleibt lediglich
die Hoffnung auf ein Softwareupdate des Herstellers.
Der Zugriff auf das Point Greyscale SDK erfolgt nicht direkt, sondern
über das ARToolkit 1 . Zu Beginn erfolgt die Initialisierung der Kamera. Das
folgende Codebeispiel demonstriert die dazu notwendigen Schritte.
!""
# $ % $& ' (#)*+ ,, & ' -#)*+ ! .
. //// !""! 0#
Kamerabild anfordern
Das folgende Codesegment dient dazu, mit Hilfe des ARToolkits einen neuen
Frame der Kamera anzufordern. Dies wird im weiteren Verlauf des Textes
als Framegrabbing bezeichnet.
1
http://sourceforge.net/projects/artoolkit
KAPITEL 5. IMPLEMENTIERUNG
48
1234 )! 5366 7
"
8 91:;21<+#;=+2<)51=27
>>?125)5@@+ >! !""!'A
B
"
CC
3#D
>
B
"
Nach dem Framegrabbing wird überprüft, ob die aktuellen Daten gültig sind.
Im Fehlerfall wird der Bildverarbeitungs-Thread für zwei Millisekunden suspendiert. Nach Ablauf dieser Zeitspanne wird erneut ein Bild der Kamera
angefordert. Die Anzahl der Fehlversuche wird protokolliert. Übersteigt diese
einen definierten Threshhold, wird versucht das Framegrabbing neu zu initialisieren. Aufgrund des erwähnten Fehlers im Point Greyscale-SDK, funktioniert diese Neuinitialisierung aber in den wenigsten Fällen. War das Framegrabbing erfolgreich, so steht der aktuelle Frame als eindimensionales Array
an -Werten2 zu Verfügung. Bei den von der Kamera gelieferten Daten, handelt es sich um Grauwerte im Bereich [0..255]. Die 8 Bit die Werte zu Verfügung stellen, decken diesen Wertebereich exakt ab. Auffällig
an dem gezeigten Programmcode ist eventuell die Funktion . Dabei handelt es sich um eine Kapselung der -Funktion. Jedes Modul
des Interaktionsservers bietet diese Funktion. Für den Entwicklungsprozess
ist eine solche Vorgehensweise hilfreich, weil dadurch die Ausgabe einzelner
Module einfach de- und wieder reaktiviert werden kann.
Ausgangspunkt der folgenden Ausführungen ist das unbearbeitete Bild
der Kamera (vgl. Abbildung 5.3(a)). Die Kamera ist unterhalb des Tisches
platziert. Der IR-Scheinwerfer leuchtet ihr von oben entgegen. Die Kamera
arbeitet im Graustufenmodus, stellen sich der IR-Beleuchtung keine Hindernisse entgegen, ist das unbeeinflusste Bild somit weiß. Durch das auf dem
Tisch verteilte Granulat, wird die IR-Beleuchtung abgeschwächt, Resultat
ist ein relativ gleichmäßig verteiltes Grau. Werden an der Oberfläche Steine
platziert, sind diese als dunkle Stellen im Bild erkennbar. Werden Löcher in
die Granulatschicht gegraben, oder zeichnet der Benutzer Interaktionsmuster in die Granulatschicht, sind diese als annährend weiße Stellen im Bild
zu sehen.
Maskierung
Wie aus Abbildung 5.3(a) hervorgeht, sind im Kamerabild, bedingt durch
die kleine Brennweite des Objektives (f = 2.3mm) auch Teile des Innenle2
1234 ist ein Datentyp der durch das ARToolkit spezifiziert ist. Es handelt sich
dabei um >!
"&-Werte.
KAPITEL 5. IMPLEMENTIERUNG
(a)
49
(b)
Abbildung 5.3: Blickfeld der Kamera. (a) Definition der Region of Interest.
(b) Maskierung nicht relevanter Bildteile.
bens des iPoint sichtbar. Um diese Teile auszublenden, muss die Region of
Interest manuell eingestellt werden. Dies geschieht durch eine eigenständige
Hilfsapplikation vor Start des Interaktionsservers. Mit der Maus werden die
Eckpunkte der Region of Interest, gemäß der auf der Projektionsscheibe angebrachten Marker, bestimmt (vgl. das rote Viereck in Abbildung 5.3(a)).
Diese Marker dienen ebenfalls der Kalibrierung der beiden Projektionen.
Die Koordinaten der Eckpunkte der Region of Interest werden in eine Textdatei geschrieben, die beim Start des Interaktionsservers ausgelesen wird.
Anhand dieser Daten wird einmalig ein binäres Maskierungsbild erstellt. Im
Zuge des Threshholdings werden die Pixel, die im Maskierungsbild als Hintergrund markiert sind, auch im aktuellen Bild als Hintergrund markiert
(vgl. Abbildung 5.3(b)).
Erstellen des Differenzbildes
Die Bildverarbeitung des Dry Garden MR erfolgt nicht absolut, sondern relativ zu einem Referenzbild. Diese differenzielle Vorgehensweise erlaubt es
den inhomogenen Hintergrund, der durch die unterschiedliche Verteilung des
Granulats bedingt ist, aus dem aktuellen Bild herauszufiltern. Somit fließen
nur noch die Änderungen des Benutzers an der Oberfläche (Hinzufügen von
Steinen, Graben von Löchern) in die weitere Analyse der Kamerabilder ein.
Das Referenzbild wird bei Applikationsstart gespeichert, kann aber auch im
weiteren Verlauf der Applikation neu gesetzt werden. Abbildung 5.2(a) zeigt
das Referenzbild. Dieses enthält im Idealfall weder Steine, noch Interaktionsmuster. Abbildung 5.2(b) zeigt das aktuelle Bild. Deutlich erkennbar,
sind ein Stein, ein strichförmiges Interaktionsmuster, sowie ein Loch in der
Granulatschicht. Das Differenzbild (vgl. Abbildung 5.2(c)) wird durch einfa-
KAPITEL 5. IMPLEMENTIERUNG
50
che Subtraktion der Pixelwerte von Abbildung 5.2(a) und Abbildung 5.2(b)
generiert.
Thresholding
Zum aktuellen Zeitpunkt steht das Kamerabild als Array an Grauwerten zu
Verfügung. Über dieses Array wird iteriert, und dabei die Maskierung des
Hintergrundes sowie die Erstellung des Differenzbildes durchgeführt. Für jedes Pixel wird anhand eines Thresholds entschieden, ob es sich stark genug
vom Hintergrund unterscheidet, um in die weiteren Berechnungen einzufließen. Ist dies der Fall, wird anhand zweier weiterer Thresholds zwischen den
Steinen auf der Oberfläche, und den vom Benutzer in die Granulatschicht
gegrabenen Löchern (in der Folge als Ziele referenziert) bzw. Interaktionsmustern unterschieden. Interaktionsmuster und Ziele sind heller als der Hintergrund, Steine naturgemäß dunkler.
Zum momentanen Verarbeitungszeitpunkt finden sich im Bild vier Graustufen, mit jeweils unterschiedlicher Bedeutung. Graustufe 128 markiert im
Vergleich zum Referenzframe dunklere Stellen (= voraussichtliche Steinbzw. Handpositionen ), Graustufe 250 markiert im Vergleich zum Referenzframe hellere Stellen (= voraussichtliche Interaktionsmuster bzw. Ziele),
Graustufe 32 deckt die maskierten Bereiche ab. Die Differenz aller übrigen
Pixel im Vergleich zum Referenzbild ist zu gering, sie werden mit dem Grauwert 0 gekennzeichnet und in der weiteren Verarbeitung nicht mehr berücksichtigt. In Abbildung 5.2(d) sind die 4 Graustufen deutlich erkennbar.
Alle drei Threshholds können während der laufenden Installation verändert werden, um auf geänderte Beleuchtungsbedingungen reagieren zu
können.
Regionlabeling
Das in vier Graustufen diskrete Bild, bildet die Basis für das Regionlabeling.
Dies wurde nicht selbst implementiert, sondern verwendet eine Funktion des
ARToolkits. Das folgende Codebeispiel zeigt dessen Aufruf.
"!#>"
1234 !%
%
& %
%
619+6;)5;= ")%
12)EF ")!%
.
Neben dem Pixelarray werden die folgenden Parameter angegeben: Die Dimensionen des Bildes in x- und y-Richtung, der Grauwert auf den der Labelingalgorithmus ansprechen soll, die Datenstruktur die die Labelinformatio-
KAPITEL 5. IMPLEMENTIERUNG
51
nen im Abschluss an das Regionlabeling enthält, ein Pointer auf das Array
in dem die Regionen eingetragen werden, sowie der Verweis auf ein Array
welches temporär während des Regionlabelings zur Verwendung kommt. Bei
der Implementierung dieses Verfahrens handelt es sich um einen speziellen
Algorithmus der nur einen Durchlauf für das Regionlabelings benötigt. Eine
daraus resultierende Besonderheit stellt der Zugriff auf die Pixel, die zu
einer Region gehören, dar. Übliche Methoden des Regionlabelings weisen
allen Pixeln einer Region ein konstantes Label zu. Nicht so die Methode
des ARToolkits. In Abbildung 5.2(e) ist deutlich erkennbar, dass für eine
zusammenhängende Region mehrere unterschiedliche Labels (erkennbar an
den unterschiedlichen Graustufen) vergeben werden. Der Zugriff auf die Pixel dieser zusammengehörenden Region gelingt daher nur über ein spezielles
Codekonstrukt. Das folgende Codebeispiel demonstriert dessen Anwendung.
. & " ! )! $")!GH
! & - & - &CC7
( ( CC7
)! 8 $$ .G)!IEH !6" 7
"! ! ")!DG&(#)*+ C H DJJ
B
7
!
")!DG&(#)*+ C H B
B
)!CC
B
Da das Regionlabeling nur jeweils Regionen einer Graustufe markiert, müssen für Steine bzw. Handpositionen und Ziele bzw. Interaktionsmuster zwei
separate Bilder generiert werden. Die Ergebnisse sind nach Abschluss des
Regionlabelings in jeweils einem eigenen struct gespeichert
(vgl. Abbildung 5.2(e)). Dieses beinhaltet für alle detektierten Regionen neben der für diese Region vergebenen einzigartigen ID, auch deren aktuelle
Position und Fläche (= Summe aller Pixel).
Feature Extraktion
Je nach Art der Region werden unterschiedliche Daten berechnet. Bei den
Steinen ist nur die Position ausschlaggebend, bei den Interaktionsmustern
KAPITEL 5. IMPLEMENTIERUNG
52
muss zuerst das relevante gefunden und anschließend die Richtung von dessen Hauptachse berechnet werden. Als relevante Region wird jene in Betracht
gezogen, die die größte Exzentrizität aufweist.
Stößt eine Region mit dem Rand der Interaktion zusammen, wird diese
als Hand eines Benutzers interpretiert. Hierbei wird nicht mehr die Position
des Mittelpunktes sondern die Längsseite des Rechtecks, welches von der
Region beschrieben wird, als Position ermittelt und an den Renderclient
übertragen (vgl. Abbildung 5.2(f)).
Normalisierung
Vor der Übertragung via Netzwerkprotokoll müssen alle berechneten Koordinaten vom Bildkoordinatensystem in den Wertebereich [−1..1] übergeführt
werden.
Dies geschieht durch den Aufruf der Funktion. Zur Berechnung der normalisierten Koordinaten greift diese auf das Konzept der
Homografie zurück. Die Parameter der dafür notwendigen Homografiematrix
werden einmalig beim Programmstart generiert. Dazu wird einmal mehr, auf
die Koordinaten der Region of Interest zurückgegriffen.
5.2.4
Netzwerkkommunikation
Zur Netzwerkkommunikation wird zunächst der entsprechende TCP-Socket
initialisiert, und an den für den Interaktionsserver spezifischen Port gebunden. Danach wird ein eigener Thread gestartet, der in seinem Mainloop auf
einen Request des Interaktionsclients wartet. Zur Implementierung kommt
die Funktion !" des ARToolkits zum Einsatz. Sobald ein Request
einlangt, wird anhand des ersten Bytes, des empfangenen Datenstroms überprüft, ob dieser Request vom Renderclient stammt. Ist dem so, setzt der
Interaktionsserver eine DGMR-Response zusammen, und sendet diese über
die bestehende Socketverbindung zurück an den Client. Für eine detaillierte
Beschreibung dieser Kommunikation sei auf Abschnitt 5.3.1 verwiesen.
5.3
Kommunikation der Komponenten
Um größtmögliche Flexibilität zu gewährleisten, erfolgt die Kommunikation zwischen dem Interaktionsserver und dem Renderclient über TCP-IP
Sockets. Somit ist es möglich diese beiden Komponenten der Gesamtinstallation auf zwei verschiedenen Rechnern auszuführen. Um die Kommunikation der Sockets in C (Interaktionserkennung) und Java (Rendering) auf
eine solide Basis zu stellen, wurde ein eigenes Netzwerkprotokoll spezifiziert
und implementiert. Der Ablauf der Kommunikation folgt einer klassischen
Client-Server Architektur. Die Interaktionskomponente analysiert das Videobild, berechnet die Interaktionsdaten und stellt sie zur Verfügung. Der
KAPITEL 5. IMPLEMENTIERUNG
53
Abbildung 5.4: Ablaufdiagramm der Gesamtinstallation.
mit diesem Interaktionsserver verbundene Renderclient, fragt diese Informationen in einem regelmäßigen Zeitintervall ab und passt das Rendering
entsprechend an. Eine Beschreibung des Protokolls folgt im nächsten Abschnitt.
5.3.1
Netzwerkprotokoll
Wie beschrieben haben es die Spezifika der Installation erfordert, ein eigenes
Protokoll zu spezifizieren. Dieses wird in Folge DGMRP genannt. Es handelt
sich dabei um ein Binärprotokoll. Unnötige Overheads werden vermieden,
die übertragenen Datenmengen betragen wenige Byte.
Laut Protokoll wird die Kommunikation vom Client initiiert. Dieser sendet einen Request an den Interaktionsserver. Dieser Request ist ein Byte lang
KAPITEL 5. IMPLEMENTIERUNG
54
und enthält eine eindeutig definierte ID. Entspricht die ID des Requests nicht
der Spezifikation, wird dieser vom Server verworfen. Anderenfalls, wird mit
einer entsprechenden Response geantwortet. Diese hat folgenden Aufbau:
• Byte 0: Framedelimiter
• Byte 1-2: Anzahl der Messages
Die unterschiedlichen Interaktionsdaten werden in verschiedene Messages
gepackt und gemeinsam im Rahmen einer Response verschickt. Eine solche
Message hat wiederum folgenden Aufbau:
• Byte 0: Message-ID
• Byte 1-2: Länge der zu übertragenden Daten
• Byte 4-65535: Nutzdaten
Das vorgestellte Protokoll hat den Vorteil, dass jederzeit neue Messagetypen
definiert werden können, ohne an der Datenübertragung an und für sich etwas ändern zu müssen. Soll die Installation um weitere Interaktionsmuster
erweitert werden, müssen nur neue Message-IDs und entsprechende Messages
definiert werden. Auch ohne Änderung an der Implementierung des Clients
funktioniert die Kommunikation mit diesem weiterhin ohne Probleme. Messages mit unbekannten IDs werden einfach verworfen. Nicht zu vergessen
ist natürlich die Implementierung zur Erkennung bzw. zur Reaktion auf die
neuen Muster zu beiden Seiten der Kommunikation.
Bei den verschickten Daten handelt es sich hauptsächlich um normalisierte Koordinaten. Da diese im Wertebereich [−1..1] liegen, beschreibt der
folgende Abschnitt die Übertragung von Fließkommazahlen.
Übertragung von Fließkommazahlen
Zur Übertragung von Fließkommazahlen im Wertebereich [−1..1] kommen
beim Dry Garden MR vier Byte große Integerwerte zum Einsatz.
Vor der Übertragung, wird jede Fließkommazahl mit einem konstanten
Faktor multipliziert. Um Vorzeichen zu erlauben, beträgt dieser Faktor die
Hälfte der größten durch vier Byte darstellbaren Ganzzahl. Das Ergebnis
dieser Multiplikation wird in einen vier Byte großen Integerwert umgewandelt. Diese vier Byte werden sequentiell übertragen.
Clientseitig werden die vier Byte gelesen und wiederum zu einer einzigen Ganzzahl kombiniert. Durch Division mit derselben Konstanten, die bei
deren Erstellung am Interaktionsserver zum Einsatz kam, wird die Zahl wieder in den Bereich [−1..1] gebracht. Die Genauigkeit dieser Technik ist auf
1/1073741823 beschränkt.
KAPITEL 5. IMPLEMENTIERUNG
5.4
55
Renderclient
Im folgenden Abschnitt wird die Implementierung des Renderings beschrieben. Dies ist laut Vorgabe der Künstlerin Non-Photorealistic. Zur Darstellung der Daten kommt die relativ neue Programmierumgebung Processing
zum Einsatz. Eine Einführung in deren Verwendung bildet den ersten Teil
des nächsten Abschnittes. Weiters folgt eine Beschreibung der Klassenhierachie, sowie der Ablauf eines Renderdurchlaufes.
5.4.1
Einführung in Processing
Zur Einführung sei an dieser Stelle [Fry06] zitiert.
Processing is an open source programming language and environment for people who want to program images, animation, and
sound. It is used by students, artists, designers, architects, researchers, and hobbyists for learning, prototyping, and production.
It is created to teach fundamentals of computer programming within a visual context and to serve as a software sketchbook and
professional production tool. Processing is developed by artists
and designers as an alternative to proprietary software tools in
the same domain.
Processing ist also Programmiersprache und Entwicklungsumgebung gleichermaßen. Der in dieser Sprache entwickelte Quellcode ist Java-kompatibel.
Wird ein mit Processing entwickeltes Programm, in der Processing Nomenklatur Sketch genannt, mit der mit dem Projekt ausgelieferte Programmierumgebung ( Processing Development Environment, PDE ) ausgeführt,
so wird dessen Quelltext in Java-Code umgewandelt. Dieser wird mit Hilfe
des mit der Installation ausgelieferten Jikes-Compilers, zu Java Bytecode
kompiliert. Die so generierten Class-Dateien laufen als Java-Applet.
Sketchbook
Jeder Sketch liegt, laut Definition, in seinem eigenen Ordner, der den gleichen Namen wie die Datei des Sketches trägt. Diese trägt die Dateiendung
.pde“. Der Ordner enthält mit allen Unterordnern die gesamten Daten, die
”
zur Ausführung des Sketches notwendig sind. Dieser Ordner wird als Sketchbook bezeichnet. Neben dem Quellcode gehören zu einem Sketch in den meisten Fällen noch weitere Daten (Fonts, Bilder, Modelle,..). Fügt man diese
mittels der PDE dem Sketchbook hinzu, wird automatisch ein Unterordner
Data angelegt. In jedem Fall sollte der Entwickler die Übersicht über diesen Ordner bewahren. Wird der fertige Sketch als Applet exportiert, werden
alle zum Sketch gehörenden pde-Files in, für Applets zulässigen Java-Code
übersetzt, kompiliert, und die so entstandenen Class-Dateien gemeinsam
KAPITEL 5. IMPLEMENTIERUNG
56
mit allen Dateien die im Data-Ordner liegen, in einem einzigen Java-Archiv
(Dateiendung: jar Komprimierung:zip) archiviert. Liegen nicht benötigte
Dateien im Data-Ordner, wird die erzeugte jar -Datei unnötig groß.
Durch diese Möglichkeit des Exports können Sketches sehr einfach im
Web publiziert werden. Zur Betrachtung wird dann nur noch ein Javafähiger Browser benötigt. Seit Version 0115 gibt es sogar die Möglichkeit
in solchen Sketches den OpenGL-Renderer zu verwenden.
Neben der Export-Funktion für Applets, bietet die PDE seit der Version
0097 auch die Funktion Export to Application. Durch die Auswahl dieser
Option werden Standalone-Versionen des Sketches für die Betriebssysteme
Windows XP, Linux und MacOS X erstellt. Diese benötigen keine JavaLaufzeitumgebung zur Ausführung und können im Fullscreen-Modus betrieben werden.
Jikes
Bei Jikes 3 handelt es sich um ein durch IBM initiiertes Projekt, dessen
Ziel es ist, die Entwicklung und Ausführung von Java-Programmen zu beschleunigen. Der mit Processing ausgelieferte Java-Compiler, ist eine Entwicklung dieses Projektes. Die im Vergleich zum von Sun entwickelten javac-Compiler bessere Performance, macht sich nur in größeren Projekten
bemerkbar [Gri99]. Die Entwickler von Processing haben sich für dessen
Einsatz vor allem deshalb entschieden, weil er neben Microsoft Windows
auch für Linux und MacOS X zu Verfügung steht.
Processing Development Environment
Die PDE ist eher an Einsteiger in die Programmierung an und für sich
gerichtet, und deshalb sowohl was Bedienung als auch Möglichkeiten anbelangt, bewusst einfach gehalten. Abbildung 5.5 zeigt einen entsprechenden
Screenshot. Rechts ist das Ausgabefenster erkennbar, links die Programmierumgebung. Bei der Arbeit an komplexeren Projekten, wird die PDE eher
nicht zum Einsatz kommen, ein Befehl sei dennoch der Vollständigkeit halber erwähnt. Durch Selektion des Menüeintrags Tools → Create Font ... ist
es möglich einen beliebigen Systemfont in ein Processing-kompatibles Format umzuwandeln. Die PDE steht unter GPL (GNU Public License), ist
also im Sourcecode frei verfügbar. Veränderungen an dieser, müssen vom
Entwickler wieder unter GPL veröffentlicht werden. Anders verhält es sich
bei der Processing Kern-Bibliothek (core.jar ), die für den Zugriff auf Processing Funktionen mit jedem Projekt ausgeliefert werden muss. Diese steht
unter LGPL (GNU Lesser General Public License) was zur Folge hat, dass
darauf basierende Werke auch Closed Source veröffentlicht werden dürfen.
3
http://jikes.sourceforge.net/
KAPITEL 5. IMPLEMENTIERUNG
(a)
57
(b)
Abbildung 5.5: Screenshot der Processing Development Environment. (a)
Entwicklungsumgebung. (b) Ausgabefenster.
Dies stellt beim Einsatz in kommerziellen Projekten ein wichtiges Kriterium
dar.
Koordinatensystem
In Processing kommt ein kartesisches Koordinatensystem zum Einsatz, dessen Ursprung sich in der linken oberen Ecke des Ausgabefensters befindet.
Beim Einsatz eines Renderers mit 3D-Funktionalität, haben Objekte die hinter der Bildschirmebene liegen eine negative z-Koordinate. Es handelt sich
also um ein rechtshändiges Koordinatensystem. Dies wahrt die Konsistenz
zum ebenfalls rechtshändigen Weltkoordinatensystem von OpenGL.
Entwicklung unter Eclipse
Die PDE, ist bewusst einfach gehalten. Dies erleichtert eine einfache und effiziente Bedienung, bei der Arbeit an komplexeren Projekten vermisst man
aufgrund dessen aber äußerst nützliche Features wie einen Debugger, sowie
die Möglichkeit von Unit-Tests, einer Code-Completion oder eines Refacto-
KAPITEL 5. IMPLEMENTIERUNG
58
rings. Der folgende Abschnitt gibt daher eine Anleitung wie man die Entwicklungsumgebung Eclipse für den Einsatz von Processing konfigurieren
kann. Diese Beschreibung bezieht sich auf Eclipse in der Version 3.1.0.
Nach dem Start von Eclipse wird über File → New → Project..“ ein
neues Projekt angelegt. Anschließend wird Java ausgewählt und ein Name
für das neue Projekt vergeben.
Anschließend wird mit dem Button Add External JAR“ des Reiters Li”
”
braries“ das Java Archiv der Processing Kernbibliothek ( core.jar“) inklu”
diert. Im Normalfall genügt es nun die Konfiguration des Projektes, mit Finish zu beenden. Durch core.jar“ werden allerdings nur die Kernfunktionen
”
von Processing abgedeckt. Möchte man die durch externe Bibliotheken zu
Verfügung gestellte Funktionen, wie Zugriff auf Videomaterial, obj -Loader,
etc. einsetzen, müsste man jedes der als Java Archiv ausgelieferten Dateien
einzeln zu diesem Projekt hinzufügen. Verwendet man bestimmte Bibliotheken öfter, so macht erscheint es sinnvoll, die von Eclipse angebotene Funktion der Userlibraries zu nutzen. Dabei fasst man einmalig eine bestimmte
Anzahl an jar -Dateien zusammen, und muss bei der Erstellung eines neuen
Projektes diesem nur noch diese eine Userlibrary hinzufügen. Nachdem das
Projekt nun eingerichtet ist, kann mit der Entwicklung begonnen werden.
Um die von Processing zu Verfügung gestellten Funktionen zu verwenden,
muss eine eigene Klasse angelegt werden, die von #
abgeleitet ist.
Zur Ausführung des Programms wird die Option Run as → Java Applet
ausgewählt. Auf diese Art gestartete Sketches laufen im Appletviewer von
Eclipse. Soll ein Sketch (im Codebeispiel trägt dieser den Namen HelloP5)
als Java-Applikation ausgeführt werden, gelingt dies durch Hinzufügen der
folgenden Codezeilen.
>" #!GH !7
1/. #!GH7KJB
B
Programmiermodi
Um für Programmierer vom Einsteiger bis zum erfahrenen Experten ein
geeignetes Werkzeug darzustellen, stehen in Processing insgesamt drei verschiedene Modi der Programmierung zu Verfügung. Die nächsten Abschnitte
geben darüber Überblick.
Basic Mode: Die einfachste Art Sketches zu programmieren wird als Basic Mode bezeichnet. In diesem Modus werden Konzepte wie Funktionen
oder Variablen vor dem Programmierer verborgen. Dieser Modus ist an Einsteiger in die Programmierung gerichtet. Es folgt ein kurzes Beispiel.
KAPITEL 5. IMPLEMENTIERUNG
59
.! D% D
& "!>
I "!>
DJJ
" I
> .! > & ED4% ED4% ED4
! .! !
<
0+5=+2
. E% E% JJ% JJ
Continous Mode: Um anspruchsvollere Sketches zu entwickeln, kann auf
den so genannten Continous Mode zurückgegriffen werden. Dieser gibt zwei
Methoden vor. Die Methode , die nur beim Start der Applikation
ausgeführt wird (die Anweisung unterbindet ein mehrfaches Ausführen), sowie die Methode "$ welche den Renderloop repräsentiert.
Zusätzlich können eigene Funktionen definiert werden. Außerdem besteht
die Möglichkeit, auf Maus und Keyboard zuzugreifen.
KAPITEL 5. IMPLEMENTIERUNG
60
>7
D% D
"!>
DJJ
ED4% ED4% ED4
<
0+5=+2
! B
I! 6
.7
.! "!>
DJJ
>
7
>"> " DJJ% % L
B
7
"> ED4% ED4% ED4
D
B
B
> . >0 0 & >07
>0 >
) D
B
>0 C E
>0 CC7
E% E% )% )
B
Java Mode: Neben der PDE, ist auch die Processing-Kernbibliothek sowie alle diese erweiternden Bibliotheken in Java implementiert. Erfahrenen
Programmierern eröffnet sich somit die Möglichkeit, direkt in Java zu ent-
KAPITEL 5. IMPLEMENTIERUNG
61
wickeln. In einem solchen Fall dient Processing nur noch als Bibliothek zur
Grafikausgabe. Es folgt die beispielhafte Implementierung eines Sketches im
Java Mode.
>" <&: 1 7
>7
& >>
" +56% L:% D:% M11D: D% D% +56
<
0+5=+2
ED4% ED4% ED4
B
B
.7
"!>
DJJ
>(% >-% D% D
B
Rendermodes
Von Processing werden im Moment vier verschiedene Rendermodes unterstützt. Um zwischen diesen umzuschalten, muss der letzte Parameter der
-Anweisung spezifiziert werden. Zur Auswahl stehen %&' #' #('
und #). Diese verschiedenen Rendermodes seien in Folge kurz beschrieben.
JAVA2D: Wird kein Rendermode explizit definiert kommt dieser Modus
zum Einsatz, der auf das AWT (Abstract Window Toolkit) zur Grafikausgabe
zurückgreift. Selbstverständlich eignet sich der Einsatz dieses Rendermodes
nur zur Ausgabe zweidimensionaler Grafiken.
P2D: Bei diesem Rendermode kommt ebenfalls ein Softwarerenderer zur
Ausgabe zweidimensionaler Grafik zum Einsatz. Dieser unterscheidet sich
vom Java 2D -Mode durch bessere Performance, aber eine visuell geringere
Qualität.
P3D: Dieser Rendermode setzt zur Ausgabe dreidimensionaler Grafik auf
einen Softwarerenderer. Optimaler Einsatzzweck ist die Ausgabe von 3D
Grafik, bei Publikation des Sketches im Web.
KAPITEL 5. IMPLEMENTIERUNG
62
OPENGL: Um auf die OpenGL-Hardwarebeschleunigung der Grafikkarte
zurückzugreifen, steht dieser Rendermode zu Verfügung. Der Zugriff auf
OpenGL unter Java wird in diesem Fall durch JOGL4 gewährleistet. Bei
JOGL handelt es sich um Java Bindings for OpenGL“ (JSR-231). Diese er”
möglichen den direkten Zugriff auf alle OpenGL-Befehle nach Spezifikation
2.0.
Texturierung
Dreidimensionale Objekte zu texturieren funktioniert in Processing sehr
ähnlich wie bei anderen Grafik-APIs. Für jeden Vertex der Geometrie werden
entsprechende Texturkoordinaten vergeben. Deren Wertebereich wird durch
die Wahl des Texturmodes bestimmt. Durch * " +',
liegt dieser zwischen 0 und 1. Wird * " ), gesetzt, beziehen
sich alle spezifizierten Texturkoordinaten auf das Bildkoordinatensystem.
Dabei reichen die Werte von 0 bis Höhe bzw. Breite der Bilddatei in Pixeln.
Sehr einfach gestaltet sich auch die Erstellung von Texturen aus vorhandenen Bilddateien. #
stellt dazu die Methode "- zum
Instantieren von #--Objekten zu Verfügung. Unterstützt werden im Moment Dateien vom Typ GIF, JPEG, TGA und beim Einsatz von Java 1.3
oder aktueller auch PNG. Um die Transparenz von PNG- und GIF -Dateien
für die erstellte Textur zu übernehmen, sollte für das #--Objekt die Instanzvariable - " auf ) gesetzt werden. Das folgende Codebeispiel
zeigt eine Methode zum Zeichnen eines texturierten Rechtecks.
4
https://jogl.dev.java.net/
KAPITEL 5. IMPLEMENTIERUNG
63
. >
!% . ! .2!=>
.
% !% )! >% 1 7
>I! & & . $ N> /DJJ% DJJ% DJJ% DJJ
" .! ! /"!#1/O31:#
& > />>
& !& >I
! //% % /&% % //% % /&% % E
/
/% % /&% E% E
/
/% % /&% E% B
/
#
5.4.2
Softwarearchitektur
Der folgende Abschnitt beschreibt das zum Einsatz gekommene Klassendesign. Einen ersten Überblick erlangt man bei Betrachtung des Klassendiagramms 5.6. In Folge sind die darin eingetragenen Klassen aufgelistet und
näher beschrieben. Die Implementierung dieser Architektur erfolgte in Java,
um für das Rendering Processing einsetzen zu können.
Renderclient: Die Klasse "!
ist die zentrale Klasse des Renderclient. Sie beinhaltet die Eintrittsmethode und kümmert sich um die Initialisierung der Applikation. Sie implementiert das Interface .
", welches
den Zugriff auf die Positionen der Steine an der Oberfläche, sowie die beiden
Renderer garantiert. Dabei stellt die Klasse "!
den zentralen Angelpunkt der Applikation dar. Für die Frontprojektion (") sowie
für die Rückprojektion (") hält sie jeweils ein eigenes Objekt
sowie eine Instanz eines $/, der die Kommunikation mit
dem Trackingserver nach DGMRP übernimmt.
Renderer: Bei der Klasse " handelt es sich um die gemeinsame
Oberklasse für " und ". Diese unterscheiden sich
hauptsächlich in der Art der dreidimensionalen Objekte die sie enthalten,
ansonsten gelten die folgenden Aussagen jedoch für Objekte beider Klassen.
" ist von der Klasse #
abgeleitet, und hat dadurch, Zugriff auf
KAPITEL 5. IMPLEMENTIERUNG
64
Abbildung 5.6: Klassendiagramm des Renderclient.
alle Funktionen von Processing. Vorgegeben sind damit auch die Methoden
zur Initialisierung und "$ zum Rendering. Zur Bezeichnung
von Instanzen der Klasse " und deren Unterklassen wird im weiteren
Verlauf des Textes der Begriff " verwendet.
Beim Instantieren eines " werden im Konstruktor unter anderem die Datenstrukturen, welche die zu rendernden Objekte speichern, und
die Projektionsmatrix initialisiert. Zugriff auf Processing-Methoden darf erst
innerhalb von und nicht etwa schon im Konstruktor erfolgen, da
das Objekt erst zu diesem Zeitpunkt initialisiert ist. In dieser werden grundlegende Einstellungen für das Rendering mit Processing getroffen. Unter
anderem werden der Rendermode (vgl. 5.4.1) die Auflösung der Quadrics 5
5
Quadric Surfaces: Durch quadratische Gleichungen beschriebene gewölbte Oberflächen
wie z.B.: Kugeln, Zylinder, etc..
KAPITEL 5. IMPLEMENTIERUNG
65
und der Texturmodus 5.4.1 definiert, sowie die Tightness die bei der Kurvendarstellung zum Einsatz kommt, definiert. Im konkreten Fall wird das
Antialiasing, durch 0 aus Performancegründen ausgeschalten. Die
Methode "$, die das Rendering, übernimmt, folgt als Codebeispiel.
>" .7
:.!
P "Q "Q
" I8 "& 2
9 2
= B
:.!
'$- setzt die aktuelle Beleuchtung, die Hintergrundfarbe sowie die Kameramatrix. Durch den Aufruf von "12! werden die
12!('-Instanzen deren Verweise der " in einer typsicheren Collection hält, je nach gesetzten Sichtbarkeitsflags dargestellt. Dabei wird über
alle Objekte dieser Liste iteriert und jeweils die Methode " aufgerufen. Im weiteren Verlauf wird auf diese Liste als renderList referenziert.
Aus Performancegründen ist die 3 nicht Threadsafe. Da aber neben dem Renderthread auch der Netzwerkthread auf diese zugreift, muss die
Synchronisierung manuell durchgeführt werden. Abschnitt 5.4.5 geht näher
darauf ein.
Die Methode ", dient in den konkreten Klassen "
und " dazu um die 12!('-Objekte deren Referenzen sie enthalten zu rendern. Die Methode '$- zerstört, während des
Renderzyklus als zu löschend markierte Objekte endgültig und entfernt die
entsprechenden Referenzen aus der renderList.
Um den Zugriff auf die zu rendernden Objekte bestimmter Typen zu
optimieren, hält der Renderer nicht alle 12!('-Instanzen in der renderList, sondern stellt für Fische, Blätter und Steine eigene Datenstrukturen
zu Verfügung. Beim Aufruf der Methode ""12! wird der Typ des
hinzuzufügenden Objektes geprüft, und somit die Zuordnung zu einer dieser
spezialisierten Datenstrukturen sichergestellt.
Mittels Aufruf von 412!, kann ein Objekt der renderList
gelöscht werden. Dadurch wird das zu löschende Objekt der 3
12!4 hinzugefügt. Nach Abschluss des aktuellen Renderzyklus,
werden in der Methode !
alle Objekte dieser Liste, aus der renderList gelöscht. Zum Abschluss wird auch 12!4 geleert. Diese
Vorgehensweise ist notwendig, da die Elemente der verschiedenen renderLists
KAPITEL 5. IMPLEMENTIERUNG
66
auch untereinander verknüpft sind. Ein Entfernen von Elementen während
eines Renderzyklus, würde infolge dessen zu Inkonsistenzen im Datenmodell
führen, was unbedingt vermieden werden muss.
Zu Dokumentationszwecken (unter anderem zur Erstellung dieser Diplomschrift) kann ein " während der Laufzeit, in den Debugmodus
versetzt werden. In diesem werden neben Statusinformationen wie der aktuellen Framerate, auch die zur Pfadanimation berechneten Pfade visualisiert.
Dabei kommt die processing-Funktion !4 zum Einsatz. Mittels eines
Aufrufes von !4- wird zur Darstellung der Kurven der gleiche
Wert für die Tension gewählt, wie er auch bei der Interpolation der Pfadpositionen zum Einsatz kommt. Somit entspricht die dargestellte Kurve, dem
zur Interpolation eingesetzten Pfad.
RendererTop: Diese Klasse wurde entworfen, um das Rendering der Frontprojektion zu implementieren. Dementsprechend werden Instanzen der an
der Oberfläche treibenden Objekte in typsicheren 3 verwaltet.
Weiters stehen mit "11
# und "5# Methoden zu Verfügung, um die Berechnung neuer Pfadpositionen für diese Objekte zu initiieren. Die Berechnung neuer Pfadpositionen findet in der Klasse
#6
!
, durch !
!
##1!
4" statt. Mit
Hilfe der so berechneten Positionen wird ein neues Path-Objekt instantiert.
Um das Update der renderLists möglichst schnell durchführen zu können,
werden alle Path-Objekte zuerst einer Hilfsliste hinzugefügt. Erst nachdem
für alle Objekte an der Oberfläche neue Pfade berechnet wurden, werden
die Animationspfade der bestehenden Objekte gegen die soeben neu berechneten Pfade ausgetauscht. Dies erfolgt sehr performant, da keine Objekte,
sondern nur Referenzen auf Objekte kopiert werden.
RendererBottom: Zur Realisierung der Rückprojektion wird ein Objekt
der Klasse " instantiert. Zusätzlich zu den von " geerbten Datenstrukturen enthält der " jeweils eine 3
mit den Positionen der Ziele, sowie den Oberflächenwellen.
Object3D: Diese Klasse wurde als Basisklasse für alle dreidimensionalen
Objekte des Dry Garden MR entwickelt. Entsprechend enthält sie Instanzvariablen für Position, Rotation, Skalierung, Farbe und Animationsgeschwindigkeit, sowie mehrerer Flags zur Beeinflussung des Stils des Renderings. In
der Methode "- werden all diese Statusflags abgefragt,
und das Objekt entsprechend im Raum platziert und ausgerichtet. Um ein
12!('-Objekt darzustellen genügt der Aufruf der Methode ".
Dies bewirkt den internen Aufruf von "-.
Weiters definiert die Klasse die abstrakte Methode "$. Von 12!('
abgeleitete Klassen, müssen diese überschreiben, und darin den Quellcode,
KAPITEL 5. IMPLEMENTIERUNG
67
der das Rendering für die Objekte der jeweiligen Klassen beschreibt, enthalten.
DGMRProtokoll: Diese Klasse enthält die Definitionen der laut Protokoll vergebenen Message-IDs.
Networklistener: Durch diese Klasse wird die Netzwerkkommunikation
laut DGMRP implementiert. Nach dem Instantieren der Klasse durch den
"6
wird mittels !!!04 die Verbindung
zum Interaktionsserver hergestellt. Die dazu hergestellte Socketverbindung
wird durch ein Objekt der Klasse 6! gekapselt. Dieses speichert
die Verbindungsdaten zum Server und startet einen neuen Thread. Dessen
Mainloop wartet eine definierte Zeitspanne (im konkreten Fall eine Sekunde),
fordert danach neue Interaktionsdaten vom Interaktionsserver an und leitet
diese dann an den ihm zugeordneten $/ weiter. Danach
wird der Thread wieder für die definierte Zeitspanne suspendiert, neue Interaktionsdaten werden angefordert und zur Verarbeitung wiederum an den
$/ weitergeleitet.
Der $/ implementiert das Interface $/
und kann sich deshalb beim 6!-Objekt zum Abarbeiten der Interaktionsdaten, registrieren. Dazu implementiert er die Interface-Methode
!'. Dieser wird der '0 übergebene und in einem mehrstufigen Prozess analysiert. Zuerst wird überprüft ob
die Response auch wirklich vom Interaktionsserver kommt. Ist dies der Fall,
wird anhand der Message-ID entschieden, an welche spezialisierte Methode
die Daten weitergegeben werden. Pro Messagetyp ist eine solche Methode
definiert. Innerhalb dieser werden aus dem Byte-Strom dann je nach Messagetyp die entsprechenden Interaktionsdaten-Objekte erstellt. Für Steine
an der Oberfläche handelt es sich dabei um 1!
', für erkannte
Löcher in der Granulatschicht um -' und für Handpositionen um
5"". Um die Erweiterungsmöglichkeit sicherzustellen, sind im DGMRProtokoll Message-IDs zur Übertragung von nicht-linearen Interaktionsmustern, sowie der Übertragung der Umrisse der interagierenden Hand (siehe
dazu auch 4.6) bereits definiert.
Animator: Diese Klasse stellt die gemeinsame Oberklasse für die unterschiedlichen Spezialisierungen von Animatoren dar. Jede Animatorklasse
kümmert sich um die Animation eines bestimmten Wertes. Die bereits in
dieser Klasse implementierten Methoden, die dadurch jedem zu
Verfügung stehen sind: (zum Start), (zum Zurücksetzen) sowie ". Der Aufruf von " muss jedes
Mal erfolgen, bevor der von einem animierte Wert abgefragt werden kann.
KAPITEL 5. IMPLEMENTIERUNG
68
PathAnimator: Dieser animiert ein 12!(' entlang eines definierten
Pfades. Neben der Position können auch die Rotationswinkel um die Achsen
des lokalen Koordinatensystems (durch Vergleich mit der letzten Position,
die zwischengespeichert wird) abgefragt werden.
RippleAnimator: Dieser implementiert die Animation der unter 4.8.3
beschriebenen Oberflächenwellen. Nach erfolgreichem Update kann neben
dem aktuellen Durchmesser auch der entsprechende Alphawert abgefragt
werden.
PathInterpolatorCatmul: Der # dient dazu, die relative
Position entlang eines Pfades, entsprechend dem aktuellen Animationsfortschritt zu ermitteln. Da sich ein Pfad aus einer Menge diskreter Stützpunkte
zusammensetzt, muss zur Ermittlung einer dreidimensionalen Position, zwischen den je nach Animationsfortschritt aktuellen Stützpunkten interpoliert werden. Diese Interpolation gelingt mit Hilfe eines Objektes der Klasse
#
6
. Der relative Fortschritt (Wertebereich [0..1]) entlang des Pfades wird vom # ermittelt und die entsprechenden
Stützpunkte vom #-objekt angefordert. Neben den Start- und Endpunkten des aktuellen Pfadabschnittes werden zusätzlich jeweils ein Punkt vor
dem Start und ein Punkt nach dem Ende angefordert. Zwischen diesen vier
Punkten wird die in 3.4.2 geschilderte Catmull-Rom Interpolation durchgeführt.
SurfaceRipple: Berührt ein Fisch die Wasseroberfläche des Dry Garden
MR, werden dadurch Wellen an dessen Oberfläche ausgelöst. Für jedes Auftreten solcher Wellen wird ein eigenes Objekt der Klasse 0!
instantiert. Dieses beinhaltet wiederum eine fixe Anzahl an 12!Objekten, welche in einer 3 verwaltet werden. Weiters enthält es
eine Referenz auf einen . Dieser berechnet auf Grundlage der
seit dem letzten Update vergangenen Zeit, den aktuellen Durchmesser, sowie
Alphawert für jedes einzelne 12!. Hierbei tritt ein weiterer Vorteil des Einsatzes von Processing zum Vorschein. Alphablending funktioniert
sehr intuitiv. Der Programmierer muss weder wie in OpenGL üblich eine
"! spezifizieren, noch muss er für die Tiefen-Sortierung aller Geometriedaten sorgen. Alleine den Alpha-Wert der aktuellen Füllfarbe kleiner
als 255 zu setzen reicht aus, um mehr oder weniger transparent zu zeichnen.
InteractionData: Diese Klasse bildet die Basisklasse für die Klassen zur
Speicherung der verschiedensten Interaktionsdaten. Dazu hält sie eine Position, sowie eine eindeutige ID zur Nachverfolgung des Objektes über mehrere
Frames. Diese wird im momentanen Entwicklungsstand, nur durch die Ähnlichkeit der Position gewährleistet. Dazu implementiert !'
KAPITEL 5. IMPLEMENTIERUNG
69
das Interface 61
. Der Vergleich der Positionen, findet im normalisierten Wertebereich ([−1..1] statt.
CircleData: Objekte dieser Klasse, dienen dem Speichern der Daten der
Steine. Zusätzlich zu den Daten der Oberklasse !', wird der
Radius eines Hindernisses gespeichert. Steine müssen nicht über mehrere
Frames nachverfolgt werden, daher wird diesen keine eindeutige ID zugewiesen.
HandData: Ein Objekt dieser Klasse, speichert die Positionsdaten einer
Hand im normalisierten Koordinatensystem.
TargetData: Objekte der Klasse -' nehmen die Positionsdaten
und den Radius von erkannten Löchern in der Granulatschicht auf.
PointList: Diese von 3 abgeleitete Klasse dient der Speicherung von Positionsdaten, die die Stützpunkte eines Pfades bilden. Da bei
der Animation entlang eines Pfades die einzelnen Stützpunkte in der Reihenfolge ihres Vorkommens in der Liste durchlaufen werden, ist es beim
Einfügen neuer Positionen in den Pfad unerlässlich, davor deren Reihenfolge zu prüfen. Aus diesem Grund stellt die # zusätzlich die Methode ""6!" zu Verfügung. Dabei wird für den einzufügenden Punkt, die Distanz vom Ursprung des Pfades ermittelt. Aufgrund dieser
Information kann dann ein sortiertes Einfügen gelingen.
Utilities: Diese Klasse enthält eine Vielzahl geometrischer Hilfsmethoden,
die zum Beispiel Schnittpunkte zwischen Kreis und Gerade berechnen, oder
die Umwandlung zwischen den verschiedenen Datentypen, die zum Beispiel
eine zweidimensionale Position speichern bereitstellen. Da die Methoden dieser Klasse essentiell für die Funktionalität des Renderclient sind, wurden
diese besonders intensiv getestet. Um diese Tests, komfortabel und nachvollziehbar zu gestalten, wurden sie unter dem Einsatz von % durchgeführt.
5.4.3
Ablauf
Aus Abbildung 5.4 gehen Datenfluss und Ablauf der Gesamt-Installation
hervor. Es folgt eine textuelle Beschreibung der Abläufe des Renderclients.
Der $/ empfängt und interpretiert die Daten des Interaktionsservers. Anhand dieser Informationen instantiert er Objekte der Klassen
6!
', -' und 5"'. Diese werden dem "6
per Methodenaufruf übergeben und zur Instantierung von Objekten aus den
entsprechenden von Object3D abgeleiteten Klassen herangezogen. Konkret
KAPITEL 5. IMPLEMENTIERUNG
70
gelten folgende Zuordnungen. -' – -, 5"' – 5" sowie 6!
' – 1!
. Diese Trennung der visuellen Repräsentation
von den Daten, wird in der Informatik ganz allgemein als MVC -Architektur
(MVC – Model View Controller ) bezeichnet (vgl. dazu Abbildung 5.7).
Abbildung 5.7: MVC -Architektur der Gesamtinstallation.
Das Model stellen die Objekte der Klassen -', 5"' und
6!
' dar. Der "!
hält diese intern als Referenz, und stellt
entsprechende Zugriffsmethoden zu Verfügung. Die View wird durch den
Renderer implementiert. Dieser enthält die Objekte der von 12!(' abgeleiteten Klassen und stellt sie mit Hilfe von Processing dar.
Controller ist im Fall des Dry Garden MR der Interaktionsserver. Der
Benutzer kontrolliert demzufolge mittels des TUI, das sich aus dem Granulat und den Steinen zusammensetzt, den Controller, der wiederum eine
Änderung am Model veranlasst. Die View reagiert entsprechend und wird
über Front- und Rückprojektion ausgegeben.
5.4.4
Datenaustausch
Da die Objekte " und " als Referenzen in der
selben Applikation zu Verfügung stehen, handelt es sich beim Datenaus-
KAPITEL 5. IMPLEMENTIERUNG
(a)
71
(b)
Abbildung 5.8: Screenshot des Renderings mit rotierter Kamera. Die Weltkoordinatensysteme von und haben die selbe
Ausrichtung. (a) . (b) .
tausch zwischen den beiden um einfache Methodenaufrufe. Es besteht die
Möglichkeit, alle 12!('-Instanzen, zwischen den beiden Renderings auszutauschen. Das Konzept sieht allerdings nur den Austausch einzelner Fische
vor.
Zu Beginn des Datentransfers, wird das zu transferierende -Objekt
dem jeweils anderen Renderer hinzugefügt. Dazu stellt der Renderer eine Methode bereit, die die Synchronität des Zugriffs auf die Renderlist der Fische
gewährleistet. Im Anschluss daran wird für das -Objekt, der interne
Verweis auf den darstellenden Renderer, neu gesetzt. Zum Abschluss des
Transfers, wird der Fisch aus der Renderlist des ursprünglichen Renderers
gelöscht. Durch diese Vorgangsweise werden keine Daten kopiert, sondern
nur Referenzen mit neuen Werten belegt. Alle Transformationen bleiben
erhalten. Da Frontprojektion wie Rückprojektion gleich ausgerichtete Koordinatensysteme besitzen, muss keine Änderung an den Positionsdaten zu
erfolgen (vgl. Abbildung 5.8). Vorraussetzung dafür ist, dass beim HardwareSetup darauf geachtet wurde, dass keine der beiden Projektionen gespiegelt
ist.
5.4.5
Thread Kommunikation
Um den gleichzeitigen Einsatz von Netzwerkkommunikation und Rendering
zu ermöglichen kommen beim Dry Garden MR mehrere Threads zum Einsatz. Dadurch ergibt sich naturgemäß die Notwendigkeit, der Kommunikation zwischen diesen beiden Threads, sowie die Notwendigkeit der Synchronisierung beim Zugriff auf gemeinsame Datenstrukturen. Um optimale Per-
KAPITEL 5. IMPLEMENTIERUNG
72
formance zu garantieren, hält der Renderer die darzustellenden Objekte in
einer 24
3712!('8. Bei deren Verwendung muss die
Synchronisierung vom Programmierer sichergestellt werden. Dies gelingt
in Java durch die Verwendung des 3! "-Statements. Sowohl der
Renderthread, als auch der Netzwerkthread, fordern vor dem Zugriff auf
die 3 einen Lock auf diese an. Betritt einer der beiden Threads
den 3! "-Block, so werden alle weiteren darauf synchronisierten
Threads (im konkreten Fall der Netzwerkthread) bis zum Verlassen dieses
Blocks, suspendiert. Dadurch ist garantiert, dass der Netzwerkthread die
Datenstrukturen eines "s nicht verändern kann, während der Renderthread zur Darstellung über dessen Objekte iteriert. Um diese soeben
erklärte Synchronisierung beim Zugriff auf die 3 sicherzustellen,
ist diese durch das Zugriffsattribut 4 geschützt. Ein Hinzufügen und
Löschen ist also nur über die dafür implementierten Methoden, die die Synchronisierung gewährleisten, möglich.
Kapitel 6
Ergebnisse
Das folgende Kapitel ist der Präsentation und Analyse der bei der Implementierung des Dry Garden MR erzielten Ergebnisse gewidmet. Dabei wird zu
Beginn die Installation in ihrer Gesamtheit dokumentiert und im Anschluss
anhand der in 3.2.1 beschriebenen Taxonomie analysiert. Die Durchführung
einer Usability-Studie war aus Zeitgründen nicht mehr möglich. Dennoch
wurden in kleinerem Rahmen unterschiedliche Entwicklungsstadien der Installation Probanden der verschiedensten Hintergründe vorgeführt. Einer
Diskussion der Reaktionen dieser Testpersonen widmet sich der anschließende Abschnitt. Den Abschluss des Kapitels bilden Überlegungen zur Performance sowohl des Renderclient als auch des Interaktionsservers.
6.1
Detailbeschreibung
Der folgende Abschnitt zeigt Details der Komponenten des Dry Garden MR.
Abbildung 6.1 bietet eine detaillierte Ansicht der Installation. Der Blauton
der Abbildung resultiert aus der LED-Beleuchtung des iPoint. In der Abbildung wurde eine der Seitenverkleidungen entfernt, um Einblick in dessen
Innenleben zu gewähren. Gut erkennbar ist der Aluminiumkäfig, der die Basis des Tisches bildet. Durch das relativ große Luftvolumen des Innenraums,
gibt es auch während langer Laufzeiten keine Überhitzungsprobleme. Der
Einsatz eines aktiven Lüfters ist daher nicht notwendig. In Abbildung 6.1
ist in der Innenansicht der Projektor, der zum Einsatz gekommene Spiegel
und die Point Greyscale Dragonfly erkennbar. Um die Verzerrungen, die sich
durch die Umlenkung über den Spiegel ergeben auszugleichen, kommt die
Trapezkorrektur des Rückprojektors zum Einsatz.
Die Detailaufnahme der Point Greyscale Dragonfly (Abbildung 6.1 (a))
zeigt das Objektiv mit aufgesetztem IR-Filter. Der kompakte und schlichte
Formfaktor ermöglicht ein direktes Anbringen auf der Bodenfläche des iPoint.
Die Detailaufnahme des Steins zeigt die angebrachten Filzknöpfe, die ein
Zerkratzen der Rückprojektionsscheibe des iPoint verhindern. Die Steine
73
KAPITEL 6. ERGEBNISSE
74
Abbildung 6.1: Detailaufnahme des iPoint. (1) LED-Beleuchtung, (2) Renderclient, (3) Interaktionsmuster, (4) Stein.
(a)
(b)
Abbildung 6.2: Innenansicht des iPoint. (a) Detailansicht – Dragonfly. (b)
Überblicksansicht – Spiegel, Dragonfly, Sanjo SJ345.
KAPITEL 6. ERGEBNISSE
75
Abbildung 6.3: Montage von Front-Projektor und IR-Scheinwerfer oberhalb des Dry Garden MR.
(a)
(b)
Abbildung 6.4: Detailaufnahmen der Interaktionselemente. (a) Stein mit
Filzknöpfen zum Schutz der Projektionsscheibe. (b) PS1161.
KAPITEL 6. ERGEBNISSE
76
sollten möglichst rund sein, da der TrackingServer zwar deren Größe ermittelt, die Steine im Datenmodell allerdings kugelförmig (der Radius der Kugel
entspricht immer der längeren Seite der für den Stein ermittelten Boundingbox) sind. Beim Einsatz von länglichen Steinen, ergeben sich Animationspfade, die einen unnatürlich großen Abstand zum Hindernis aufweisen.
Um den Kontrast im Kamerabild zu verbessern, kommt wie erwähnt ein
zusätzlicher IR-Scheinwerfer zum Einsatz. Dieser ist gemeinsam mit dem
Frontprojektor oberhalb der Installation angebracht. Abbildung 6.3 zeigt
deren Montage in einer Nahaufnahme.
(a)
(b)
Abbildung 6.5: Detailaufnahme der Frontprojektion. (a) Versuchsaufbau
an der FH-Hagenberg. (b) Screenshot.
Abbildungen 6.5(b) und 6.5(a) zeigen Screenshot und Projektion der
Frontprojektion. In beiden Abbildungen erkennt man, dass an der Stelle der
Steine, schwarze Kugeln gerendert werden. Diese stellen die interne Repräsentation des Datenmodells des Dry Garden MR dar. Weiters wird durch
deren Projektion von oben vermieden, dass Grafiken auf die Steine projiziert werden. Der Screenshot ist im Debug-Modus des " entstanden. Aus diesem Grund sind die Animationspfade in blau eingezeichnet, der
Hintergrund ist weiß. Als Methode der Stützpunktberechnung kommt die in
4.8.1 beschriebene Variante des Einfügens neuer Stützpunkte zum Einsatz.
6.2
Analyse
Die folgende Analyse bezieht sich auf das Userinterface des Dry Garden MR.
Durch Front- und Rückprojektion wird dessen Granulat mit digitalen Inhalten überlagert. Mit den Steinen steht dem Benutzer ein Alltagsgegenstand
als Eingabemedium zu Verfügung, der es ihm erlaubt das digitale Modell des
Dry Garden MR sehr direkt zu beeinflussen. In dieser Eigenschaft erinnert
der Dry Garden MR an das Projekt Bricks [Ull95]. Bezogen darauf handelt
KAPITEL 6. ERGEBNISSE
77
es sich um ein Graspable User Interface. Für das Granulat verschwindet der
Unterschied zwischen physikalischer Ein- und digitaler Ausgabe. Laut [Ull97]
verwandelt es sich somit zum TUI. Dieses wird in Folge anhand der in Abschnitt 3.2.1 definierten Taxonomie klassifiziert.
Durch die Interaktionserkennung des Interaktionsservers wird das Granulat des Dry Garden MR zum Eingabemedium, die Topprojektion zum
Ausgabemedium. Somit gilt für das Embodiment ganz klar der Parameter
Full. Gleiches gilt für die Parametrisierung der zweiten Koordinate der Taxonomie, der Metaphor. In seinem Interface ist der Dry Garden MR also
dem Projekt SandScape sehr ähnlich. Den größten Unterschied bildet die
zusätzliche Rückprojektion. Diese stellt eine neue und bisher einzigartige Erweiterung des Interaktionsraumes zu beiden Seiten der Projektionsscheibe
dar, bietet aber aus Sicht der Usabilty Anlass zur Kritik. Im Rahmen einer Usability-Studie wäre zu klären, ob das Freischaufeln der Löcher in der
Granulatschicht, die Metaphor des Zeichnens von Interaktionsmustern nicht
doppelt belegt und den Benutzer somit überfordert. Einen weiteren Kritikpunkt stellt die Reaktionsgeschwindigkeit der Rückprojektion auf Benutzereingaben dar. Auf Zeichnen der Interaktionsmuster und Positionieren der
Steine reagiert der Dry Garden MR ohne Verzögerung. Setzt der Benutzer
allerdings durch Freischaufeln eines Lochs in der Granulatschicht ein Ziel für
die Fische, kommt erst dann ein Fisch an die Oberfläche, wenn er sich direkt
unter diesem Loch“ befindet. Zum derzeitigen Entwicklungsstand erhält der
”
Benutzer kein Feedback vom Dry Garden MR, dass ein Loch als Ziel erkannt
wurde. Eine Visualisierung ähnlich der Oberflächenwellen würde diese Situation in jedem Fall verbessern.
6.3
Performanceüberlegungen
Der folgende Abschnitt befasst sich mit Überlegungen zur Performance und
allfälligen Verbesserungsmöglichkeiten. Weil die Installation in Renderclient
und Interaktionsserver geteilt ist, beide komplett unabhängig voneinander
durch den Einsatz verschiedener Programmiersprachen entstanden sind und
jeweils andere Anforderungen gelten, folgen auch die anschließenden Ausführungen dieser Zweiteilung.
6.3.1
Renderclient
Eines der definierten Ziele des Projektes war es, einen Überblick über Processing zu erlangen, und dessen Eignung für den Echtzeiteinsatz in weiteren Medieninstallationen zu klären. Die Visualisierungskomponente, des
Dry Garden MR, verwendet nur Funktionen des dreidimensionalen Renderings und setzt dabei auf den OpenGL-Rendermode von Processing. Viele
weitere Möglichkeiten die diese Programmierumgebung bietet (u. a. Verarbeitung von Echtzeitvideo, Soundsynthese und Analyse, Partikelsysteme,
KAPITEL 6. ERGEBNISSE
78
Einbindung von Mikro-Kontrollern über Wiring1 ) blieben ungenutzt. Die
folgenden Aussagen beziehen sich daher nur auf den Einsatz von Processing
als Bibliothek zum Rendering.
Bevor konkret auf die Performance des Renderings eingegangen wird,
noch ein paar allgemeine Bemerkungen zum Einsatz von Processing. Der
Entwicklungsprozess entspricht dem, einer klassischen Java-Applikation. Ein
Processing-Projekt ist ein Java-Projekt. Alle Vorteile wie Plattformunabhängigkeit oder online verfügbar machen als Java-Applet (inkl. OpenGLUnterstützung) treffen voll zu. Der Einsatz von Processing bietet neben dem
Zugriff auf die große Java-Klassenbibliothek viele weitere Vorteile. So stehen Funktionen für das Laden von Fonts und Texturen oder für das Zeichnen von Splines ohne das Einbinden externer Bibliotheken zu Verfügung.
Eine weitere Vereinfachung betrifft den Einsatz von Transparenzen. Unter
OpenGL müssen zur korrekten Darstellung von halbtransparenten Objekten alle Objekte der Szene nach ihrer z-Koordinate aufsteigend sortiert sein.
Beim Einsatz von Processing fällt diese Notwendigkeit weg. Ein so genanntes Alpha-Blending kann durch einfaches Bestimmen, des Alpha-Wertes der
aktuellen Zeichenfarbe definiert werden.
Natürlich haben Komfort, Sicherheit und Plattformunabhängigkeit von
Java auch einen entscheidenden Nachteil: Trotz OpenGL-Hardwarebeschleunigung sind die unter Processing erzielbaren Frameraten eindeutig niedriger
als beim Einsatz von OpenGL unter C++. Um einen besseren Vergleich
zu bekommen, wurde eine primitive Szene mit nur einer Lichtquelle und
250 Würfeln ohne Texturen gleichermaßen in Processing sowie in OpenGL
unter C++ auf der selben Hardware gerendert. Dabei handelte es sich um
einen wenig leistungsstarken Intel 82852 Grafikkontroller. Unter Processing
wurden 6–8 fps erreicht, in OpenGL mit C++ 28–30fps. Das Rendering des
Dry Garden MR ist sehr schlicht gehalten. Aus diesem Grund werden trotz
der Performancenachteile von Processing, befriedigende 30 fps erreicht.
6.3.2
Interaktionsserver
Die folgenden Abschnitte geben Auskunft über Verbesserungsmöglichkeiten
am Interaktionsserver, die dazu dienen die Robustheit der Interaktionserkennung und die Performance der Gesamtinstallation zu verbessern.
Buffering und Mittelwertbildung
Da die zur Interaktionserkennung eingesetzte Kamera 30 fps liefert, der Renderclient aber nur im Sekundenintervall neue Interaktionsdaten abfragt, ist
es sinnvoll, über die, seit dem letzten Request berechneten Daten den Mittelwert zu bilden. Somit würden Ausreißer“ kaum ins Gewicht fallen. Die
”
ermittelten Interaktionsdaten wären entsprechend robuster.
1
http://wiring.org.co/
KAPITEL 6. ERGEBNISSE
79
Identifikation der Interaktionsdaten
Im momentanen Entwicklungsstand liefert der Server bei jedem Request
alle Interaktionsdaten ohne diesen eine eindeutige ID zuzuordnen. Bei den
auf der Oberfläche verteilten Steinen, macht es keinen Unterschied ob die
Positionen zweier aufeinander folgender Frames miteinander in Zusammenhang stehen oder nicht. Anders hingegen, bei den Zielen. Sobald ein solches
für einen bestimmten Fisch gesetzt ist, muss dieses natürlich über mehrere
Frames hinweg bestehen bleiben und in jedem Frame als dasselbe, wie in
den vorangegangenen Frames erkannt werden. Diese Nachverfolgung wird
im Moment vom Renderclient übernommen.
Selbes gilt für die Erkennung der Handpositionen. Sobald ein Fisch vom
Benutzer aufgenommen wird, sollte dieser der Position der Hand nachgeführt
werden. Dazu wäre es notwendig eine Hand über mehrere Frames als das
selbe Objekt zu identifizieren.
Handpositionen und Zielen bereits durch den Server eine eindeutige ID
zuzuweisen, würde den Renderclient entlasten. Weiterer Vorteil, der Objekterkennung am Server ist der Zugriff auf das Kamerabild. Somit können
bessere und robustere Methoden als der reine Ähnlichkeitsvergleich der Position zum Einsatz kommen.
6.4
Benutzerreaktionen
Abschließend seien noch einige Worte zu den Benutzerreaktionen auf den
Dry Garden MR verloren. Am Tag der offenen Tür wurde das Projekt in
einer sehr frühen Version erstmals einer breiten Öffentlichkeit zugänglich
gemacht. Vorallem bei Benutzern, die den kulturellen Kontext des Projektes nicht kannten, bestand vor einer Einführung in dessen kulturelle Hintergründe, eine relativ große Skepsis. Sobald diese aber überwunden war,
machte es ihnen, wie auch aus den Abbildungen 6.6(a) und 6.6(b) hervorgeht, einfach Spaß mit dem Sand zu interagieren. Zum damaligen Entwicklungsstand, war die Interaktionserkennung noch in einem sehr rudimentären
Zustand, das System reagierte nicht immer nachvollziehbar. Trotzdem bereitete es den Benutzern große Freude mit dem Sand zu interagieren. Die Kontrolle des Systems rückt demnach in den Hintergrund, das Interface selbst
wird (wie auch von Rokeby in [Rok98] beschrieben) zum Content. Einzig
die, durch die Grobkörnigkeit des Granulats bedingte geringe visuelle Qualität der Projektion wurde von den meisten Probanten kritisiert. Da der
Einsatz des feinkörnigen Granulats aus den genannten Gründen allerdings
keine mögliche Option darstellt, wurde das in Abschnitt 4.7 beschriebene
alternative Setup entwickelt.
Die finale Version wurde in einem Versuchlabor der FH-Hagenberg getestet. Die mystische Ausstrahlung von Abbildung 6.7 ist Resultat der Verdunkelung des Raumes der Installation, rief bei der Probandin aber keine
KAPITEL 6. ERGEBNISSE
80
(a)
(b)
Abbildung 6.6: Demonstration des ersten Prototyps am Tag der offenen
Tür der FH-Hagenberg.
KAPITEL 6. ERGEBNISSE
81
Abbildung 6.7: Testlauf der finalen Version mit einer Probandin im Versuchslabor der FH-Hagenberg.
negativen Reaktionen hervor. Dieser bereitete es sichtlich großes Vergnügen
die Fische zu beobachten, sie an die Oberfläche zu locken und mittels Steinen
und Interaktionsmustern die Wasserströmungen zu beeinflussen.
Kapitel 7
Resümee
Im Rahmen dieser Diplomarbeit wurde eine interaktive Medieninstallation,
welche über ein TUI gesteuert werden kann, entwickelt. Für den Autor dieser
Arbeit war dies eine große Herausforderung, da er mit der Erarbeitung dieses
Themengebietes völliges Neuland betrat. Um das Konzept einer Künstlerin
in eine anwendbare Installation umzusetzen, musste eine tiefgehende (und
zeitaufwändige) Einarbeitung in die Materie erfolgen. Komplexe technische
Konzepte wurden selbstständig erarbeitet. Weiters galt es die inhaltliche
Barriere gegenüber dem Projekt zu eliminieren. Dies gelang erst durch eine
nähere Beschäftigung mit dessen kulturellen Hintergründen. Die selbe inhaltliche Skepsis macht sich auch bei vielen Benutzern, die den Dry Garden
MR in keinen kulturellen Kontext stellen können, bemerkbar. Erst nach
Erklärung des (wohlgemerkt gut durchdachten) Konzepts und dessen Hintergründen, ist die inhaltliche Basis für die Befassung mit der Installation
gegeben. Danach benötigt es meist nur noch des Satzes: Nicht alles was
”
Spaß macht, muss einen Sinn ergeben.“, um die Leute vom Spiel mit Wasser, Sand und Steinen zu überzeugen.
Die Tatsache, dass es sich beim User Interface des Dry Garden MR um
ein TUI handelt, stellt einen der größten Pluspunkte des Projektes dar.
Dies zeigt auch die Reaktion der Benutzer, und legt den Schluss nahe, dass
es sich bei Medieninstallationen um den idealen Einsatzzweck für TUI s handelt. Deren Einsatz erlaubt es mehreren Benutzern gleichzeitig, auf intuitive
Art und Weise, mit einem Computersystem zu interagieren. Die Greifbarkeit räumt Barrieren klassischer HCIs aus dem Weg, und ermöglicht somit
Benutzern aller Altersklassen einen einfachen und schnellen Zugang. Vorraussetzung einer erfolgreichen Umsetzung stellt den Einsatz zuverlässiger
Technik, die bestmöglich vor dem Benutzer verborgen werden sollte, dar.
Durch die erfolgreiche Implementierung des Projektes wurde die Eignung
von Processing für die Entwicklung von Medieninstallationen unter Beweis
gestellt. Der optimale Einsatzzweck liegt dennoch in der schnellen Realisierung eines Prototypen, als in der Umsetzung einer finalen Applikation.
82
KAPITEL 7. RESÜMEE
83
Der Entwicklungsprozess wird nicht durch eine mühsame Konfiguration und
Einarbeitung in verschiedene externe Bibliotheken verlängert, es ist innerhalb kürzester Zeit möglich Ergebnisse zu erzielen. In Folge dieses raschen
Entwicklungsprozesses ist es schon in einem frühen Stadium möglich, Prototypen auf ihre Anwenderfreundlichkeit hin zu überprüfen. Die gewonnenen
Schlüsse können wiederum entsprechend rasch eingearbeitet werden, um in
zeitlich knapp darauf folgenden weiteren Testläufen den überarbeiteten Prototypen weiteren Überprüfungen zu unterziehen. Erst wenn dieser iterative
Prozess ein befriedigendes Ergebnis geliefert hat, wird auf Grund der gewonnenen Erfahrungen eine finale Version entwickelt. Diese finale Version wird
in den meisten Fällen mit Hilfe performanterer Programmierumgebungen
wie C++ in Kombination mit OpenGL implementiert.
Abschließend sei nochmals auf die Zukunft des Dry Garden MR hingewiesen. Bei der Diskussion der Ergebnisse wurden schon etliche Verbesserungsmöglichkeiten genannt. Deren Umsetzung erscheint sehr wünschenswert und wäre vor einer eventuellen öffentlichen Ausstellung sogar zwingend
erforderlich. Ob dies aber durch Einsatz des iPoint geschehen wird, ist eher
fraglich. Es bestünde allerdings die Möglichkeit, die aus der Entwicklung des
Prototypen gewonnenen Erfahrungen zu verwerten, um das in Abschnitt 4.7
gezeigte Konzept umzusetzen.
Anhang A
Inhalt der CD-ROM
File System: Joliet
Mode: Single-Session (CD-ROM)
A.1
Diplomarbeit
Pfad:
/
iInstallationen.pdf . . .
iInstallationen.ps . . . .
A.2
Applikation
Pfad:
/applikation/
readme.txt . . . . . . .
Pfad:
Installationsanleitung.
/applikation/interaktionsServer/
interaktionsServer.exe .
dummyServer.exe . . . .
calib.exe . . . . . . . . .
Pfad:
Diplomarbeit (PDF-File).
Diplomarbeit (PostScript-File).
Interaktionserkennung.
Dummyversion.
Kalibrierungs-Applikation.
/applikation/renderClient/
renderClient.bat . . . .
data/images/ . . . . . .
data/models/ . . . . . .
Batch-Datei zum Start.
Texturen.
Modelle.
84
ANHANG A. INHALT DER CD-ROM
A.3
Sourcecode
Pfad:
/source/renderClient/
.project . . .
Manifest.txt .
src/ . . . . .
data/images/
data/models/
Pfad:
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
85
Eclipse-Projekt.
Manifest für JAR-Erstellung.
Java-Files.
Texturen.
Modelle.
/source/interaktionsServer/
interactionServer.sln
Source/ . . . . . . .
Include/ . . . . . . .
Lib/ . . . . . . . . .
A.4
Quellen
Pfad:
/quellen/
CatmullRom.pdf . .
Rakugaki.pdf . . . .
processingLIVE.pdf
dryGarden.pdf . . .
CGGrundlagen.pdf .
SpeedingUp.pdf . .
A.5
Bilder
Pfad:
/bilder/
dragonFly.tif . . .
fishSurfaceing.tif .
handPlaceStone.tif
handsHoldFish.tif
.
.
.
.
.
.
.
.
.
.
.
.
Solution-File für VS.NET.
Implementierung.
Header-Files.
Dependencies.
.
.
.
.
.
.
.
.
.
.
.
.
Catmull-Rom Einfführung [Twi03].
Projektbeschreibung [Tak01].
Projektbeschreibung [Hod05a].
Projektbeschreibung [Tak05].
CG-Grundlagen [Fil06].
Jikes-Compiler [Gri99].
.
.
.
.
.
.
.
.
Detailaufnahme der Dragonfly- Kamera.
Fisch beim Erreichen der Oberfläche.
Ein Stein wird in den Dry Garden MR gelegt.
Ein Fisch wird vom Benutzer in der Hand
gehalten.
installationFinal.tif . . . Probandin bei der Interaktion in einem
Versuchslabor der FH-Hagenberg.
iPointDetail.tif . . . . . Detailaufnahme des iPoint.
iPointDetailNoCaption.tif Detailaufnahme des iPoint (ohne Captions).
iPointInside.tif . . . . . Innenaufnahme des iPoint.
ANHANG A. INHALT DER CD-ROM
iPointRed.tif . . . . .
logo.png . . . . . . . .
projectionMaterials.tif
projectorFront.tif . . .
.
.
.
.
rake.tif . . . . . . . .
screenRendererTop.tif
stone.tif . . . . . . . .
stoneRipple.tif . . . .
stonesAndFish.tif . . .
.
.
.
.
.
strokeLinear.tif . . . . .
tdot1.tif . . . . . . . . .
tdot2.tif . . . . . . . . .
A.6
Video
Pfad:
/video/
dryGardenMR.mp4 . . .
86
Gesamtansicht der Installation.
c
Logo des Projekts Florian
Bacher.
Unterschiedliche Projektionsmaterialien.
Projektor und IR-Scheinwerfer oberhalb der
Installation.
Traditioneller Bambusrechen.
Screenshot der Frontprojektion.
Detailaufnahme des Steins.
Wellen um einen neuplatzierten Stein.
Installation mit zwei Steinen und zwei
Fischen an der Oberfläche.
Lineares Interaktionsmuster.
Dry Garden MR am Tag der offenen Tür
2006.
Dry Garden MR am Tag der offenen Tür
2006.
MPEG4-komprimierte Version der
Videodokumentation
Literaturverzeichnis
[Ben03]
Bender, Michael und Brill, Manfred: Computergrafik.
Hanser, 2003.
[Bur05]
Burger, Wilhelm: Digitale Bildverarbeitung. Springer Verlag,
2005.
[Cas05]
Cassinelli, Alvaro, Ishikawa Masatoshi und Ito Takahito: Khronos Projector. In: SIGGRAPH Emerging Technologies.
ACM Press, 2005.
[Cat74]
Catmull, E. und Rom, R.: A Class of Local Interpolating Splines. In: Computer Aided Geometric Design, Seiten 317–326. Academic Press, San Francisco, 1974.
[Dob04]
Dobler, Daniel und Stampfl, Philipp: Enhancing threedimensional vision with three-dimensional sound. In: Proceedings
of the conference on SIGGRAPH 2004, New York, 2004. ACM
Press.
[Fel92]
Fellner,
Wolf-Dietrich:
Wissenschaftsverlag, 1992.
[Fil06]
Filler, A.: Mathematische Grundlagen der 3D-Computergrafik
und ihre Umsetzung in Grafiksoftware.
URL, http://www.
ph-heidelberg.de/wp/filler/CG-Grundlagen.pdf, April 2006. Kopie
auf CD-ROM.
[Fis04]
Fishkin, P. K.: A taxonomy for and analysis of tangible interfaces. Personal and Ubiquitous Computing, 8:347–358, May-June
2004.
[Fri]
Frigg, Patrick: Tangible User Interfaces - Beispiele und eine
Taxonomie. Seminar Verteilte Systeme zum Thema Smarte Ob”
jekte und smarte Umgebungen“.
[Fry06]
Fry, Ben und Reas, Casey: Processing Homepage. URL, http:
//www.processing.org/, June 2006.
87
Computergrafik.
BI-
LITERATURVERZEICHNIS
[Gri99]
88
Grinzo, Lou: Speeding up Java development.
URL, http:
//www-128.ibm.com/developerworks/linux/library/l-jikes.html,
September 1999. Kopie auf CD-ROM.
[Hod05a] Hodgin, Robert: processing:Live. URL, http://flight404.com/
vj/exhibit.html, April 2005. Kopie auf CD-ROM.
[Hod05b] Hodgin, Robert: webcam:tracking.
URL, http://www.
processing.org/exhibition/works/tracking/index.html, April 2005.
[Ish04]
Ishii, H., Ratti C. Piper B. Wang Y. Biderman A. und
Ben-Joseph E.: Bringing clay and sand into digital design. BT
Technology Journal, 22:287–299, 2004.
[Lyo02]
Lyons, Michael J., Van Tonder Gert J. Shortreed Ian
und Tetsutani Nobuji: Calming Visual Spaces: Learning from
Kyoto Zen Gardens. In: Conference Abstracts on SIGGRAPH
2002, New York, 2002. ACM Press.
[Mor90]
Mortenson, Michael E.: Computer Graphics Handbook. Industrial Press Inc., 1990.
[Pip02]
Piper, Ben, Ratti Carlo und Ishii Hiroshi: Illuminating
Clay: A 3-D Tangible Interface for Landscape Analysis. In: Proceedings of CHI 2002, New York, 2002. ACM Press.
[Rok98]
Rokeby, David: The Construction of Experience: Interface as
Content. In: Dodsworth Jr., C. (Herausgeber): Digital Illusion: Entertaining the Future with High Technology, Seiten 27–47.
Addison-Wesley Publishing Co., San Francisco, 1998.
[Tak01]
Takahashi, Keiko: Rakugaki. URL, http://www.th.jec.ac.jp/
September 2001. Kopie auf CDROM.
∼keiko/rakugaki/rkframe.html,
[Tak05]
Takahashi, Keiko: Project Dry Garden. Konzeptskizzen, July
2005. Kopie auf CD-ROM.
[Twi03]
Twigg, Christopher: Catmull-Rom Splines.
URL, http:
∼
//www.cs.cmu.edu/ fp/courses/graphics/asst5/catmullRom.pdf,
March 2003. Kopie auf CD-ROM.
[Ull95]
Ullmer, Brygg und Ishii, Hiroshi: Bricks: Laying the Foundations for Graspable User Interfaces. In: Proceedings of CHI 1995,
Denver, May 1995. ACM Press.
[Ull97]
Ullmer, Brygg und Ishii, Hiroshi: Tangible Bits: Towards Seamless Interfaces between People, Bits and Atoms. In: Proceedings
of CHI 1997, Seiten 234–241, Atlanta, March 1997. ACM Press.
LITERATURVERZEICHNIS
89
[Ull01]
Ullmer, Brygg und Ishii, Hiroshi: Emerging Frameworks for
Tangible User Interfaces. In: Carroll, John M. (Herausgeber):
Human-Computer Interaction in the New Millennium, Seiten 579–
601. Addison-Wesley, Atlanta, 2001.
[Whi98]
White, Tom und Small, David: An Interactive Poetic Garden.
In: Conference on Human Factors in Computing Systems. ACM
Press, 1998.