Short trippin'

Aus toolbox_interaktion
Wechseln zu: Navigation, Suche

Short trippin' - Virtueller Spaziergang
Semesterarbeit des Fachbereichs Medientechnik / Kommunikatiosdesign SS 2005

Konzept der interaktiven Anwendung

Durch Gestensteuerung soll es möglich sein, duch ein virtuelles 3D-Modell eines italienischen Dorfes frei zu navigieren. Ein vor einer Leinwand sitzender Benutzer wird so abgefilmt, dass steuerungsrelevante Daten aus seiner Handbewegung gewonnen werden können, welche über verschiedene Softwarekomponenten verarbeitet und den Funktionen der Systemmaus übergeben werden. Dieses Überschreiben ermöglicht im 3D-Modell, welches in Director erstellt ist, die Steuerung von den Bewegungen (Laufen, Anhalten), sowie den Blickwinkeln (also das simulierte Drehen des Kopfes). Die Erkennung erfolgt über einen "Datenhandschuh", dessen besondere Eigenschaft 2 eingearbeitete Leuchtdioden sind, die eine gute Erfassung beim Abfi lmen und der folgenden Verarbeitung liefern.
Weiter wird die Ausgabe über 2 Beamer so auf eine speziell beschichtete Leinwand projiziert, damit unter der Verwendung von Polfi lterbrillen ein 3D-Eff ekt entsteht.
An definierten Stellen im Modell werden Sounds ausgelöst.

Aspekte der Interaktion

Diese Art der "Fortbewegung", die Begehung einer virtuellen Welt mittels einfacher Handbewegungen ist fast schon eine klassische interaktive Anwendung. Der Benutzer interagiert mit dem System, er, und nicht die Maus oder die Tastatur ist das Eingabemedium.

Echtzeitanforderung an die Anwendung

Damit der Eindruck eines Spaziergangs entstehen kann, ist die unmittelbare Übersetzung von der steuernden Gestik zur Bewegung auf der Leinwand wichtig. Weiter ist es von Vorteil, eine gute Qualität der Darstellung zu liefern, um den Benutzer nicht etwa durch ein ruckelndes 3D-Modell laufen zu lassen, was sehr schnell ermüdent wirkt. Das Modell sollte sich also ohne Verzögerung steuern lassen.

Die Teilsysteme im Überblick

Dateneingang

Datenhandschuh

Eine herkömmliche DV-Kamera steht vor dem Benutzer und filmt diesen, möglichst den Bereich der agierenden Hand. Eine sehr effektive Möglichkeit der Merkmalsextraktion wurde mit dem Einsatz des "Datenhandschuh" erzielt. Dabei handelt es sich um einen herkömmlichen, recht dünnen Stoff handschuh, mit zwei Leuchtdioden an Daumen und Zeigefinger, welche durch eine Batterie versorgt werden. Der Trick dahinter ist, dass sich die stark weiss leuchtenden Dioden problemlos und recht effektiv vom Handschuh und der restlichen Umgebung erfassen lassen.

Beschreibung des Eyesweb- Patches

Der Benutzer wird mit dem Datenhandschuh von einer DV-Kamera gefi lmt. Das analoge Videosignal wird von einer Framegrabber-Karte digitalisiert und in der Software EyesWeb verarbeitet. Dabei werden die Koordinaten der beiden Leuchtdioden extrahiert. EyesWeb ist eine Open Source Anwendung, entwickelt an der Universität von Genua, für die Bild-, Audio- und Signalverarbeitung. Im Folgenden wird das verwendete EyesWeb-Patch in Stichpunkten erläutert.

Aufnahme

Die Aufnahme des Bildes erfolgt über eine Kamera, die wahlweise im Interlace-Modus oder Progressive-Modus arbeiten kann. In Eyesweb wird das Bild über ein Framegrabber-Modul erfasst (Input Imaging Framegrabber). Eyesweb steuert dabei die Falcon-Framegrabber-Karte an, die über ein BNC-Kabel mit der Kamera verbunden ist. In Eyesweb lässt sich die Kameraauflösung und die Framerate manuell einstellen.

Vorverarbeitung

Das Kamerabild wird zunächst verbessert und Störungen werden entfernt. Dazu wird das Bild zuerst deinterlaced (Imaging Operations Deinterlacer) und anschließend wieder zusammengefügt (Imaging Operations Interlacer). Als nächstes wird die Farbinformation verworfen (Imaging Conversion ColorToGray) und eine kantenerhaltende Glättung mit dem Median-Operator durchgeführt (Imaging → Filters → NonLinearFilters), um die später folgende Binarisierung zu erleichtern.

Binärbildverarbeitung

Um die Leuchtdioden des Datenhandschuhs eindeutig im Bild identifizieren zu können, muss dieses binarisiert werden. Der Schwellwert ist dabei sehrhoch angesetzt, da nur extrem helle Punkte, idealerweise nur die Dioden, erkannt werden sollen. Um letzte Störungen zu unterdrücken und die nötigen Elemente besser zu isolieren werden anschließend noch morphologische Operatoren angewandt.

Merkmalsextraktion

Die Koordinaten der Leuchtdioden, also der extrahierten Bereiche werden extrahiert und verrechnet.

Diagonale

Grafische Darstellung

Zunächst wird das umfassende Viereck des detektierten Bereiches ermittelt (Imaging → FeatureCalc → Bounding-Rect). Die Koordinaten der Eckpunkte repräsentieren dabei die Position der Leuchtdioden. Aus den Koordinaten wird die Diagonale des umfassenden Rechtecks berechnet mit Hilfe des Satzes von Pythagoras. (siehe Abbildung)

Die exakte Berechnung erfolgt dann über folgende Formel: Shorttrippin formel.png


Schwerpunkt

Für die Position des Mauszeigers wird der Schwerpunkt des detektierten Bereichs benötigt (Imaging FeatureCalc Baricenter).

Das OSC -Protokoll

Über das OSC-Protokoll kommuniziert Eyesweb mit der Java-Anwendung. Da die beiden Programme nicht auf demselben PC laufen, müssen die Daten mit Angaben von IP und Port über Ethernet verschickt werden. Von der Java-Anwendung empfangen, steuert diese dann entsprechend die System-Maus.

3DsMax

Mit Hilfe dieser 3D-Software entstand das gesamte Civitellamodell. Auf Grundlage von Zeichnungen und Fotos wurden so die Gebäude, Straßen und Pflanzen nachgebaut und anschließend mit abfotografierten Texturen versehen. Weiterhin wurden in 3DsMax zwei Kameras(cl, cr) so positioniert, um den 3D-Stereo Effekt zu erzielen. Die genau Technik der Stereoskopie wird im nächsten Kapitel erklärt. Die eine Kamera entspricht dem Blick des rechten und die andere die des linken Auges. Aus 3DsMax exportierten wir dann die beiden Kameraansichten in zwei separate Shockwave Dateien.

Macromedia Director und Shockwave 3D

Für die Zusammenführung aller Dateien wurde Macromedia Director ausgewählt, da mit diesem Programm sowohl Animationen gestaltet, als auch Shockwave Modelle verbearbeitet werden können. Mit Hilfe der Shockwave 3D Schnittstelle von Director war es möglich das 3D-Modell aus 3DsMax ins Shockwave Format(w3d) zu exportieren und in Director zu importieren. Dort konnten wir dann jedes einzelne 3D-Modell per Programmierung ansprechen und so die Echtzeitsteuerung durch unser Civitellamodell ermöglichen.

Aufbau der Dateien


Jede Datei hat folgenden Inhalt:

  • Die Shockwave 3D Darsteller aus 3D-Studio Max.
  • Preloading Screens
  • Scripte
  • Sound
  • sowie teilweise noch Grafi ken, wie z.B. Masken.

Die Bühne, auf der die Darsteller (die einzelnen Dateien, Scripte usw. heißen Darsteller oder im englischen Cast) platziert werden, hat die Größe 2048 x 768 Pixel. Das entspricht der doppelten Breite einer gängigen Bildschirmauflösung. Diese kommt zu Stande, weil wir 2 Beamer ansteuern, und einer jeweils eine Auflösung von 1024x768 Pixel besitzt. Die Darsteller liegen jeweils in mittig auf der jeweiligen Hälfte der Bühne. Das linke Modell liegt folglich auf x: 512 – y:384; das rechte auf x:1536 – y:384.

Reihenfolge im Drehbuch

Wie schon angesprochen sind die Shockwave 3D Darsteller meist sehr groß. Dadurch dauert das Laden der Dateien in Director auch dementsprechend lange. Deshalb wurde versucht die großen Dateien zu cachen bzw. vorzuladen. Dafür wurden Preloading-Screenshots entwickelt, die angezeigt werden, während die 3D-Modelle im Hintergrund geladen werden. Dabei wurde das 1. Frame des jeweiligen 3D Modells in Max rausgerendert. Das hat den Vorteil, dass es kein Ruckeln gibt, denn die Position vom ersten Bild des 3D-Modells ist gleich der Position im Preloading-Screen. Allgemein sieht die Reihenfolge der Darsteller folgendermaßen aus:
Preloading-Screens / Textfelder → Shockwave 3D Modelle / ggf. Audio

Eine wichtige Einstellung in Director muss vorgenommen werden, denn sonst hilft das ganze Preloading mit den dazugehörigen Screens nichts. Das Stichwort lautet: Direkt auf die Bühne (Direct-To-Stage). Dazu folgender Auszug aus der Hilfedatei von Director:
Die Option Direkt auf Bühne gibt an, ob das Rendering direkt auf der Bühne (Standardeinstellung) oder im Off screen-Puffer von Director erfolgt. Im Off screen-Puffer berechnet Director, welche Sprites teilweise von anderen Sprites verdeckt werden. Wenn die Option Direkt auf Bühne aktiviert ist, übergeht Director den Off screen-Puffer, um Zeit zu sparen. Damit wird auch die Wiedergabegeschwindigkeit erhöht. Allerdings steht in diesem Fall der Modifizierer Farbwalze nicht zur Verfügung, und über dem 3D-Sprite können keine anderen Sprites platziert werden.

Wenn die Option "Direct-To-Stage" deaktiviert ist, schaut Director nach, ob Objekte überlagert werden, was hier zwar nicht der Fall ist, aber er würde die Preloading-Screens nicht anzeigen, bzw. nicht so lange, bis das Modell komplett auf der Bühne ist. Es ist anzunehmen, dass die Screens im Off screen-Puffer sind und er diesen, laut obiger Beschreibung, umgeht. Man sieht als Konsequenz kurz den Hintergrund der Bühne, bevor die Modelle platziert und abgespielt werden.
"Direct to Stage" findet man im Eigenschafts-Inspektor im Tab "3D-Modell". Dazu muss vorher das 3D-Modell im Drehbuch markiert sein. Jetzt kann die Option deaktiviert werden. Außerdem muss im gleichen Tab, die Option "Schleife" (Loop) ausgeschalten werden. Sonst wiederholt er die Animation des 3D-Modells. Diese Optionen müssen immer wieder deaktiviert werden, wenn ein Darsteller ins Drehbuch gezogen oder ausgetauscht wird.

Scripte

Die einfachsten Scripten in Director sind Sprungbefehle, zum Beispiel:

on exitFrame me
go to frame 1
end

Dieses Script ist dafür verantwortlich, dass Animationen ganz abgespielt werden, auch wenn im Drehbuch nur 31 Frames angezeigt werden.

Diese Scripten werden auf den letzten Frame eines Darstellers gesetzt, was folgende Abbildung verdeutlicht.

Shorttrippin scripting.jpg

Preloading

Zum vorher schon angesprochenen "cachen" von großen Dateien wurde ein Preloading Script geschrieben. Dieses sieht folgendermaßen aus:

on enterFrame me
  member("ohm2_l").preload()
  member("ohm2_r").preload()
  --preload ist vermutlich unnütz, weil director es sowieso macht!
  if (member("ohm2_l").state<>4 AND member("ohm2_r").state<>4) then
    go to frame 1
  else
    put "Status" (member("ohm2_l").state)
    put (member("ohm2_l").percentStreamed) "%"
    put (member("ohm2_l").streamsize) "bytes loaded"
    go to frame 32
  end if
end

Soundtiming

Nun hat man aber noch folgendes Problem. Director weiß leider nicht, wann eine 3D-Animation zu Ende gespielt ist. So ist es auch bei unserer Ohm-Logo-Animation, welche in 3D Studio Max generiert wurde. Dabei ist zu beachten, dass Director nur die Kamera Anfangspositionen verarbeiten kann (diese werden wohl nur in das Shockwave Format exportiert) und keine Kamerabewegung, was heißt, dass man immer das Objekt bewegen muss.
Nach einer ergebnislosen Suche nach Abfragen, wie man das Ende oder nur die Länge einer Shockwave3D-Animation bestimmen kann, wurde einfach der Soundkanal in Director zur Hand genommen. Da das Soundstück genausolang wie die Animation ist, also 30 sek. kann man auch den Sound abfragen wann er eine bestimmten Wert überschreitet. Dann springt direktor zu einem vorgegebenen Frame: Die Soundmarke liegt bei 28500 ms, wobei der Wert von mal zu mal unterschiedlich sein kann. Woran das liegt ist noch unklar. Das Skript liegt auf dem "ohm_l" Darsteller.

on enterFrame me
  sprite("ohm2_l").cursor = 200
  --put sound(1).currenttime
  if sound(1).currenttime > 28500.0000 then
    --put ("stop and jump")
    go to frame 60
  end if
end enterFrame

Der Befehl put sound(1).currenttime gibt im Messagefenster die jeweilige Zeit aus, wenn on enterFrame me ausgelöst wird, also wenn die Schleife betreten wird. sprite("ohm2_l").cursor = 200 versteckt den Mauszeiger, während der Animtaion.

Die Programierung der Kamerafahrt

Die zweite Director Datei ist wie bereits erwähnt für den Gang durch Civitella zuständig. Die Fahrt durch das 3D Modell sollte interaktiv gestaltet werden, d.h. verglichen mit einem 3D-Spiel, kann der User selber entscheiden wie er sich im Modell wohin bewegt. Da die Interaktions-Events durch den Datenhandschuh eingeschränkt sind, musste die Steuerung in Director dementsprechend modifi ziert werden. Die bestehenden Methoden benötigten eine Vielzahl von Events und kamen nicht in Frage. So wurde die bestehende Struktur der Skripten umprogrammiert und auf unsere Bedürfnisse angepasst. Die Achsen in einem 3D-Modell verhalten sich relativ zum Weltmittelpunkt und zu verschiedenen benachbarten Objekten, von Objekt zu Objekt verschieden. Es gibt ein Gizmo für die Rotations-Achsen das sich in Beziehung zur Transformation des Objektes bewegt.d.h. Es gibt ein globales Koordinatensystem "World.tranform()", zu dem hat jedes Objekt sein eigenes unabhängiges Koordinatensystem.

Shorttrippin winkel.jpg

So ändern sich die Gizmo-Richtungen eines Objekts, wenn man es z.B. um 90° rotiert. Im Beispiel wurde das Objekt um 90° in Y-Richtung rotiert. Nun sind die gewohnten Achsen relativ zur Drehung verschoben. Diese Tatsache erschwerte die Orientierung im Modell bei den Kamera-Fahrten enorm und ist für die Programmierung der Methoden unabdinglich.

Die Methode Rotate und Tranlate sorgen in einem Director-3D-Modell dafür, das sich Objekte drehen und bewegen können. Das Problem war, dass man über diese Befehle nicht auf die reinen Richtungskoordinaten zugreifen kann, jedoch gab es auch einige Eigenschaften dieser Methoden, die wir uns zu Nutze machen konnten. Dies hatte zur Folge dass eine eigene modifizierte Methode implementiert werden musste:
Bei einer Rotationsbewegung um sich selber, legte sich das Objekt (Kamera) immer auf die Seite (Die Kamera stand irgendwann auf dem Kopf). Diese Eigenschaft war für die Orientierung und Bewegung im Modell nicht akzeptabel. Die Lösung war, die reinen Eigenschaften des Objektes (Kamera) direkt anzusprechen. Es wurde eine neue Methode entworfen.

Methoden Rotation:
pCamera.rotate(vector, vector, vector, #world)
Reine Eigenschaften Rotation:
pcamRotateZ = pCamera.transform.rotation.z
zetwinkelc1 = pcamRotateZ + Drehwert
pCamera.transform.rotation.z = zetwinkelc1

In dieser Methode wurde die Eigenschaft des inkrementierten Pans beibehalten jedoch die falsche Rotationslage beseitigt. Da es für den Stereo-3D Effekt wichtig ist, nicht nur, wie bei einem 3D-Spiel eine Ansicht zu rendern, sondern 2 perspektivisch unterschiedliche Ansichten zu erzeugen, mussten die Kameras separat für jede Ansicht programmiert werden. Im Folgenden werden die verschiedenen Erkenntnisse während der Entwicklungen geschildert.

In der 1. Version gab es zwei verschiedene 3D-Modelle, die jeweils eine andere Kameraansicht (aus 3D-Max) besaßen und nebeneinander auf der Bühne platziert wurden.
Die Kameraansichten haben einen Target-Point. Jede Kamera hat ca. einen Winkel von 4° bzw. –4°. So entsteht der leichte Versatz auf der Leinwand der essentiell für den Stereoeffekt ist.
Der Hauptfilm wurde durch ein Skript angesprochen. In diesem Skript wird die 3D Kamera für die 1. Ansicht generiert, die vom User durch Mousevents gesteuert wird. Die Linke Maustaste steuert den horizontalen und vertikalen Pan der Ansicht, die rechte Maustaste steuert den Zoom (vorwärts Fahrt). Durch das Skript wird parallel zur 1.Kamera, die 2. Kamera für die 2. Ansicht generiert, die an die Events des Hauptfilmes gekoppelt ist. – So wird eine parallele/gekoppelte Navigation gleichzeitig in beiden Filmen ermöglicht.
In der Version2 steuert das Skript nach wie vor beide Ansichten auf der Bühne an. Das Skript reagiert sensitiv auf Mausevent und liegt auf dem 1.Sprite. Da aber gleichzeitig mit der Initialisierung der Modells des 1.Sprites, die Models der 2.Sprites initialisiert werden, ist es möglich beide Ansichten über den 1.Sprite anzusprechen. So wird über den 1.Sprite die 1.Kamera für die linke Ansicht und die 2.Kamera für die 2.Ansicht initialisiert und auch gesteuert.

In einem Skript:
--1.Ansicht (Modell linkes)
pSprite = sprite(me.spriteNum)
pCamera = pSprite.camera
--2.Ansicht (Modell rechts)
pSprite2 = sprite(1)
pCamera2 = pSprite2.camera

Mouseevents

Da uns mit unserm Handschuh Gerd nur eine Beschränkte Anzahl an Events zur Verfügung stehen, musste überlegt werden wie die Steuerung genau aussehen sollte. Zur Verfügung standen nur die normale Mausbewegung und MouseRelease.
An der normalen Mausbewegung hängt der PicturePan, d.h, mit jeder Bewegung der Maus wird das 3D-Bild in die jeweilige Mausrichtung ausgerichtet. So ist es möglich sich in der Welt umzuschauen. Ein Nachziehen der Maus ist nicht nötig, da die vertikale und horizontale Mausposition auf die Sichtposition inkrementiert wird. Der MouseRelease-Event bewirkt in unserem 3D-Model einen Zoom in die Tiefe. Dies gibt dem User das Gefühl als würde er sich vorwärts bewegen.

3D-Effekt

In dieser Version ist es leider noch nicht möglich, einen wirklichen 3D-Stereo Effekt auf der Leinwand zu generieren. Die Kameras haben noch nicht das Verhalten des menschlichen Auges.
Ferner muss der Kameraaufbau das gleiche Verhalten aufweisen wie der Kopf mit seinen Augen des Menschen. Die Augen haben immer den gleichen Abstand und immer denn gleichen Targetpoint. Wir vernachlässigen, dass sich die Augen seperat von der Kopfbewegung drehen können und dass sich der Targetpoint je nach fokussiertem Objekt adaptiert.

Sound Design

Nachdem die Sounds aufgenommen und bearbeitet waren, sollten diese an den richtigen Orten im 3D Modell, während des Vorbeigehens des Users abgespielt werden.
Die Sounds

  • Hintergrundsound: Grillen zirpen
    Dieser Sound wurde als Loop über das 3D-Modell gelegt.
    Hierzu war es nötig den Sound als internen Cast in die Directordatei zu integriere. Er wurde folgendermaßen abgespielt und geloopt.
puppetSound(5),"zirp"
member("zirp").loop = true
  • interaktive Sounds:
    Es sollten z.B. ein Hund bellen sobald man an einem bestimmten Punkt im Modell vorbeikommt. Um die Dateigröße und somit die Performance nicht zu belasten, werden diese Sound als externe Cast’s behandelt, d.h. sie werden bei bedarf von der Festplatte gestreamt und müssen nicht beim starten der Anwendung geladen werden.

Um die Sounds nun an der richtigen Stelle im Modell abspielen zu können, wurden aktive Boxen programmiert. Diese kann man sich als Kollisionsobjekte vorstellen. Wenn eine Kollision mit der Kamera, also mit dem Benutzer stattfindet, wird der entsprechende Sound geladen und abgespielt. Dort gibt’s es nun 2 verschiedene Abspielarten.

  1. Sounds die nur 1mal abgespielt werden
  2. if counter = false AND ywert >= -120 AND ywert <= 20 then
    if not soundBusy (2) then
    sound playfile 2, "mirjam_22.wav"
    counter = true
    end if
    end if
    
  3. Sounds die bei jedem Vorbeigehen abgespielt werden:
  4. if ywert > 15 AND ywert < 88 AND xwert > 410 then
    if not soundBusy (3) then
    sound playfile 3, "hund_44.wav"
    end if
    end if
    
  5. Sounds die bei der Nährung an ein Objekt lauter werden und bei der Entfernung leister.
  6. if ywert > 571 AND zwert > -5 AND xwert > 460 then
    if not soundBusy (1) then
    sound playfile 1, "giovanni_44.wav"
    end if
    gio = true
    sound(1).fadeto(255,4000)
    else if soundBusy (1) AND gio = true then
    sound(1).fadeto(0,4000)
    gio = false
    end if
    

    Exportieren als Projektor

    Director besitzt die Möglichkeit von ihm erstellte Dateien in einen Projektor zu exportieren. Das heißt, er speichert alle verwendeten Daten, z.B. Grafiken, Shockwave 3D Modelle, Bilder usw. in eine Datei ab. Diese besitzt die Endung .exe und ist somit ausführbar. Das gute daran ist, dass Director nicht auf dem Rechner installiert sein muss auf dem die Projektor Datei ausgeführt wird. Man muss aber den "Shockwave-Player" installiert haben, dessen Verionsnummer aber vom jeweilig verwendeten Director abhängt. Es stand Director MX2004 zum Arbeiten zur Verfügung, dieser verwendet Shockwave Version 10.

    Vorgehensweise:
    Unter dem Menüpunkt "Datei" findet man "Veröffentlichungseinstellungen". In diesen kann man nähere Einstellungen vornehmen. Im 1. Tab "Formate" kann man den Pfad einstellen, in welchen veröffentlicht werden soll. Des weiteren kann man noch in andere Formate veröffentlichen, oder in Webseiten integrieren, hier aber uninteressant.
    Der Tab "Projektor" ermöglicht diverse Einstellung zum Projektor. In diesem sollte bei "Playertyp" der Listeneintrag "Shockwave" ausgewählt werden und außerdem noch die Häkchen bei "Animation im Hintergrund" und "Vollbild" gesetzt sein.
    Im Tab "Dateien" kann man nun weitere Director Dateien anhängen. Das heißt eben, dass man modular arbeiten kann, so wie wir es auch gemacht haben. Da das 3D-Civitella Objekt anfänglich, dh. ohne Texturkompression und ohne Kamerapositionierung per Script, sehr groß ar, mussten wir so arbeiten. Denn Director wird beim Bearbeiten der großen Modelle extrem langsam! Und wenn man die 2. Datei mit dem großen Modell einfach nachlädt, erspart man sich viel Wartezeit. Außerdem machte das auch sinn, weil es immer wieder neue Modell-Versionen gab, die man aber ja auch testen musste. Deshalb wird der "Cast" der jeweiligen Director-Datei meist recht voll. Dadurch geht leicht die Übersicht verloren.
    Um Dateien hinzu zufügen klickt man im unteren Drittel des Fensters auf "Dateien hinzufügen", wählt die Datei aus und bestätigt. Sie erscheint anschließend in der kleinen Liste unter den Buttons. Jetzt noch das Häkchen bei "Alle Filme in der Liste abspielen" setzen.
    Die restlichen Tabs kann man vernachlässigen, es gibt dort keine weiteren – für unser Projekt wichtige – Einstellungen. Mit dem Button "Veröff entlichen" wird die Projektor-Datei erstellt. Alternativ kann man auch das Tastaturkürzel "Strg+Umschalt+S" benutzen.

    Java Anwendung

    Die Maussteuerung ist ein Java-Programm, das Daten aus dem Eyesweb-Patch per OSC-Protokoll erhält und weiterverarbeitet. Über die eingegangenen Werte wird die Mausbewegung gesteuert. Realisiert wurden die generelle Bewegung, weiterhin das Drücken der Maus und ein einfacher Klick.
    Eine Kamera nimmt den Benutzer und seine Bewegungen mit dem Datenhandschuh auf. Das Bild wird übermittelt an das Programm Eyesweb, das die Position der Leuchtdioden ermittelt und die Entfernung der Dioden zueinander berechnet. Diese Werte werden zusammen mit der Kameraauflösung über Port 3000 geschickt. Die Daten von der Java-Anwendung empfangen und verarbeitet, anschließend wird die Maus auf dem Bildschirm entsprechend bewegt.

    Datenhandschuh kamera eyesweb.jpg

    Die Maus-Steuerung benutzt neben den Standardbibliotheken eine externe Jar-Datei als zusätzliche Bibliothek. Die JavaOSC-Bibliothek wurde von C. Ramakrishnan / Illposed Software geschrieben und ist im Internet frei verfügbar. Die Bibliothek enthält verschiedene Klassen, die es möglich machen über Java OSC-Messages zu empfangen und zu verschicken.
    OSC steht für Open Sound Control und ist ein Protokoll, das dem Midi Protokoll ähnelt und vor allem in der Audioverarbeitung genutzt wird.

    Aus dem OSC-Protokoll werden folgende Werte extrahiert:

    • X-Wert des Schwerpunkts
    • Y-Wert des Schwerpunkts
    • Diagonale
    • Kameraauflösung Breite
    • Kameraauflösung Höhe

    Die X- und Y Werte werden jeweils mit dem Wert der Kameraauflösung verrechnet und auf die Bildschirmauflösung skaliert. Dabei ist zu beachten, dass nur die Hälfte der Bildschirmbreite genutzt wird. Der Bildschirm ist erweitert auf zwei Monitore und gibt die Ansichten über zwei Beamer auf die Leinwand aus. Da die Beamer jedoch übereinander und nicht nebeneinander strahlen, kann der Benutzer nur in einem Bereich der halb so breit ist wie die Bildschirmauflösung agieren. Die Diagonale ist der Indikator für das Drücken der Maus. Wenn die Diagonale sehr klein ist, d.h. die beiden Leuchtdioden sind eng zusammen, wird die Maus gedrückt. Wenn die Diagonale wieder größer wird, wird ein Klick ausgeführt.

    In der Anwendung kann man einstellen, ab welcher Größe der Diagonale ein Drücken detektiert werden soll. Dieses Einstellen geschieht momentan noch statisch über Eingeben des Wertes auf der Oberfläche. Geplant ist, dieses Einstellen in Zukunft dynamisch zu generieren.

    Zur besseren Erkennung des Drückens der Maus wurde ein Puffer programmiert, der jeweils 3 Diagonalen-Werte verrechnet. Erst wenn 3 Werte kleiner sind als die anfangs eingestellte Bedingung wird ein Drücken der Maus meldet. Durch Spiegelungen in Brillengläsern oder der Umgebung detektiert Eyesweb teilweise falsche Werte, die unter Umstanden zufällig einen Klick herbeiführen könnten. Durch den Puff er wird dies verhindert.

    Dokumentationen der einzelnen Klassen

    Ausgabe

    Die Klasse "Ausgabe" ist die Oberfläche der Anwendung und gleichzeitig die Main-Klasse. Über sie kann die Anwendung gesteuert werden.
    Beim Start generiert sie ein Objekt der Klasse Voreinstellung und die Zentrale. Wenn der "Start"-Knopf gedrückt wird, wird diese Aktion in der Zentrale bemerkt.
    In der Oberfläche stehen Informationen über die Bildschirmauflösung und die Kameraauflösung. In späteren Versionen soll der Benutzer hier auch seine eigene Auflösung einstellen können. Das bedeutet, er legt fest, welchen Bereich des Kamerabildes er erreichen kann.
    Der Wert der Diagonale, von dem an ein Klick registriert wird, kann ebenfalls in der Oberfläche eingestellt werden. Momentan geschieht diese über eine manuelle Eingabe. Später soll dieses Textfeld ausgetauscht werden. Der Benutzer wird dann aufgefordert, seine Finger einmal zu Testzwecken zusammenzuführen und dieser Wert der Diagonale wird gespeichert als Bedingung für einen Klick.

    Voreinstellung

    Diese Klasse wird sofort nach Erstellen der Oberfläche aktiv und registriert einkommende Werte aus dem OSC-Protokoll. Sie extrahiert die Kameraauflösung und gibt diese, zusammen mit der Bildschirmauflösung in der Oberfläche aus.

    Zentrale

    Die Zentrale erzeugt ein Objekt der Klasse Verbindung und registriert das Drücken des Start-Knopfs. Daraufhin wird der Thread in der Klasse Verbindung gestartet, der auf einkommende OSC-Meldungen wartet.

    Verbindung

    Diese Klasse behandelt die die Verbindung zu dem OSC-Port. Sie erzeugt ein Objekt der Klasse OSCPortIn aus dem JavaOSC-Package und eine Objekt der Klasse Steuerung.
    Sobald eine OSC-Meldung eingeht werden folgende Werte extrahiert:

    • Kameraauflösung
    • Koordinaten x und y
    • Länge der Diagonale

    Diese Werte werden an die Steuerung weitergeleitet.

    Steuerung

    Diese Klasse ist ein Kind der Klasse Robot und kontrolliert und steuert die Mausbewegung. Die extrahierten Werte der OSC-Meldung werden verrechnet und die entsprechende Aktion ausgeführt.
    Eine Auflistung der implementierten Maus-Aktivitäten:

    • mousemove
    • mousepress
    • mouserelease