Multitouch and Beyond

FMF vs. GestureWorks

Heute haben wir uns entschieden statt dem Flash Multitouch Framework (FMF) von EVOLUCE, das kommerzielle GestureWorks-Framework zu verwenden. Dieses bietet u.A. eine Unterstützung für die Bühnengröße 1920×1080 (Full-HD) und ist einfacher zu verwenden. In dieser Entscheidung sind wir unseren Mit-Studenten gefolgt, die seit letzter Woche ebenfalls GestureWorks statt FMF verwenden.

Flash Hardware Beschleunigung

Hardwarebeschleunigung in Flash

Wir haben heute außerdem eine Lösung für die Performance-Probleme von Flash gefunden. Unser erster MT-Prototyp (mit FMF) hatte auf dem MT-Tisch z.T. große Probleme mit der Leistung. Die Anwendung lief sehr ruckelig und die Objekt-Erkennung war langsam und unpräzise. Die Lösung dafür war klein aber fein. Unter den Veröffentlichungs-Einstellungen bietet Flash, im Bereich “Erweitert”, die Möglichkeit eine Hardwarebeschleunigung festzulegen. Mit “Stufe 2 – GPU” lief unsere Anwendung flüssig und ohne Verzögerung auf dem Evoluce-ONE. Schön, dass es manchmal auch einfache Lösungen gibt

Oberflächengestaltung - Entwurf mit Pappe

Die Oberfläche hat sich noch ein wenig weiter entwickelt. Nun ist die Optik des Papiers noch einmal überarbeitet worden und die Boxen in Form von Karteikarten, die den Inhalt transportieren sollen, haben schon mal ein erstes Äußeres bekommen.

Die Karteikarten sind auf der Oberfläche frei bewegbar, sie sind beliebig ein- und ausklappbar und können auch außerhalb des Papiers platziert werden. Die physikalischen Objekte werden jedoch durch das Blatt Papier begrenzt.

Für den Hintergrund haben wir einiges ausprobiert. Von einfarbig über Verläufe und leichten Strukturen, bis hin zur Pappe ist alles mal da gewesen. Leider wirkt alles entweder zu unruhig, oder langweilig.

Oberflächengestaltung - Entwurf mit Holz

Da wir die anfänglich eingesetzte Holzstruktur sehr schön finden, haben wir nun versucht durch dunklere Farben einen stärkeren Kontrast zu dem Papier herzustellen und dem Holz an sich nicht so kontrastreiche Farben zu verleihen. Dadurch wird das Papier und alles darauf liegende trotz Struktur im Hintergrund in den Fokus gerückt.

Über das Aussehen der Kugel und der Schiefen Ebene müssen wir uns noch mal Gedanken machen. Auch die Schrift wird evtl. noch bearbeitet bzw. auf jeden Fall um eine serifenlose Schrift ergänzt, in der die Inhalte geschrieben werden.

Beim Überdenken des Konzepts und den Interaktionsmöglichkeiten haben wir noch ein paar Kleinigkeiten verändert, die die Anwendung noch intuitiver und interaktiver gestalten sollen:

Kraftvektoren über Gesten visualisieren

Zum einen sollen die Kraftvektoren zusätzlich zu den Schaltern, auch über Gesten angezeigt werden können. So ist es möglich von der Kugel aus in die jeweilige Richtung, in die die Hangabtriebskraft, die Normalkraft und die Gewichtskraft wirken einen Strich zu ziehen. Mit dieser Geste werden die Kraftvektoren an die Kugel angetragen.

Masse über Vektorenpfeil einstellen

Darüber hinaus kann die Gewichtskraft direkt über den Vektorenpfeil reguliert werden. Da die Erdbeschleunigung immer ca konstante 9,81 beträgt, ist der einzige Faktor, den der Nutzer verstellen kann, und der sich direkt auf die Gewichtskraft auswirkt, die Masse der Kugel. Diese wird nun nicht mehr über eine extra Navigation (vgl. “Die Kugel und ihre Masse”) zu verändern sein, sondern direkt über den Vektorenpfeil der Gewichtskraft. Zieht der Nutzer den Pfeil nach unten in die Länge, wird die Kugel schwerer und zur Visualisierung dunkler eingefärbt. Wird der Pfeil nach oben hin verkürzt, wird die Kugel leichter und dementsprechend heller eingefärbt. Der Regulationsspielraum beträgt jedoch nach wie vor 1kg bis 25kg. Um ein besseres Gefühl dafür zu haben wie die Länge des Pfeils sich auf das Gewicht der Kugel auswirkt, erscheint neben dem Pfeil eine Skala sobald der Nutzer den Pfeil berührt.

Hangabtriebskraft und Normalkraft

Hangabtriebskraft und Normalkraft können jedoch nach wie vor nicht direkt verstellt werden. Dies würde nach unserer Auffassung keinen Sinn ergeben, da sie sich auch im “echten Leben” aus der Gewichtskraft und vielen anderen Bedingungen ergeben und nicht direkt einzustellen sind.

Nicht nur technisch, auch in der Darstellung der Multitouchanwendung sind wir am Tüfteln und Ausprobieren. Da das Thema der Anwendung aus dem Schulischen kommt, wollen wir auch durch die Gestaltung an Schulzeiten erinnern. Um den Nutzer später mehr zum Ausprobieren und Experimentieren zu animieren, soll das ganze auf einem Papier stattfinden und einen “Kritzel Charakter” bekommen. Dafür haben wir uns für ein zerknittertes Karo-Papier als Experimentierfläche entschieden.

Ein erster Entwurf der Oberfläche

Darüber hinaus  sollen die gezeichneten Objekte auch eine gezeichnete Optik erhalten. Formeln, Herleitungen und Definitionen werden auf Karteikarten stehen, die der Nutzer so ein und ausziehen kann, wie er es benötigt.

Nach der Analyse des ersten Enwurfs haben wir uns für grade Kanten des Blattes entschieden. Auch der Untergrund des Blattes soll eine weniger auffällige Struktur bekommen und nicht aus Holzmaserungen bestehen. Die Elemente werden neu gestaltet und die Karteikarten werden entworfen.

Das Einarbeiten in die Welt von Box2D (und AS3) geht weiter. Während unser erstes Physik-Engine-Beispiel nicht viel mit unserer Anwendung zu tun hatte, wird es jetzt etwas konkreter. Als hilfreich für’s Lernen von Box2D hat sich http://www.box2dflash.org/ erwiesen. Außerdem finden sich auch bei Emanuele Freonato (immer wieder) gute Tutorials und Code-Schnipsel.

Im unteren rudimentären Prototypen gibt es drei verschieden schwere Kugeln, die eine Schiefe Ebene hinunter rollen. Die Farbe zeigt dabei das Gewicht der Kugeln (1kg, 4kg, 8kg). Interessant ist dabei die Frage, wie sich das Gewicht “anfühlt”, wenn z.B. die Kugel mit der Maus bewegt wird. Die komplette Animation kann per Tastendruck (beliebige Taste) pausiert und wieder abgespielt werden.

Es hat sich außerdem gezeigt, dass Box2D “unsere” Berechnungen (z.B. Hangabtriebskraft) nicht direkt durchführt. D.h. wir müssen die Kräfte unabhängig von der Physik-Engine berechnen.

Box2D Screenshot

Da es sich bei unserer MT-Anwendung im Grunde um eine Physik-Simulation handelt, brauchen wir natürlich auch eine Physics Engine. Dieses Antriebssystem (“Engine”) ist eigentlich sogar das Herzstück unserer Andwendung, weil es alle physikalischen Simulationen und Berechnungen übernimmt. Wir haben uns in den letzten Tagen mit Box2D beschäftig. Das ist eine weit verbreiteten Physics Engine von Erin Catto, die hauptsächlich für Computerspiele eingesetzt wird. Ursprünglich in C++ entwickelt gibt es inzwischen zahlreiche Übertragungen z.B. Box2D FlashAS3. Leider gibt es für Box2D nur eine rudimentäre Dokumentation und nur wenige (gute und vollständige) Tutorials. Die Physics Engine ist auch nicht gerade selbsterklärend und hat einige Eigenarten aus der C++-Welt. Die neueste Version 2.1a scheint noch einige Probleme zu haben, weswegen wir uns für die etwas ältere V2.0.2 entschieden haben. Für diese Version lassen sich auch mehr Tutorials finden. Folgende Ressourcen waren für uns bis jetzt hilfreich:

• Ausführliche Video Tutorials von Todd Kerpelman: http://www.kerp.net/box2d/
• Einsteiger Tutorial von Emanuele Feronato: http://www.emanueleferonato.com/2009/01/27/box2d-tutorial-for-the-absolute-beginners/
• Tutorial zum “Debug Draw”: http://www.emanueleferonato.com/2008/12/10/understanding-box2d-debug-draw/

Und hier unser kleiner “Hallo Box2D-Welt”-Prototyp, ganz im Zeichen der Fußball WM. Die Bälle lassen sich mit der Maus umher “werfen” bzw. k(l)icken

(Leider ist die Online-Version ein wenig fehlerhaft aber wir arbeiten dran … )

Parallel zur Arbeit am Konzept haben wir auch unseren Prototypen zur Gesten Erkennung nochmals verbessert. Folgendes ist neu:

• Es werden nur noch Gesten verarbeitet, die zu mind. 75% mit einer Vorlage übereinstimmen
• Es gibt mehrere Vorlagen für die beiden Elemente, damit schlecht gezeichnete Umrisse besser erkannt werden
• Die Objekte lassten sich einfach per Drag n’ Drop verschieben
• Es gibt eine Begrenzung, damit Elemente nur auf der Bühne verschoben werden können

Weiter werden wir den Prototyp aber nicht mehr ausbauen. Statt dessen werden wir als nächstes mit 2D Physik-Engines für Flash experimentieren.

Update (19.05): Es gibt auch noch zwei weitere, vielversprechende Algorythmen zur Gesten-Erkennung:

• Simple Gesture Recognition in AS3 von Arnaud Icard
  (Schöne Animation und einfache Implementierung unter AS3)
• $N Multistroke Recognizer in JavaScript
  (Erkennung von mehreren, nicht-zusammenhängend gezeichneten Strichen. Bisher leider nur für JavaScript.)

Die erste technische Herausforderung ist gelöst! Wir haben uns überlegt, in unserer Anwendung eine spezielle Gesten-Erkennung einzubauen. Diese soll dazu dienen, dass man (mit Stift oder Hand) Umrisse zeichnen kann, die vom System dann erkannt werden.

In unserem Prototyp lassen sich ganz einfach Kugeln und Schiefe Ebenen zeichnen:

Herzstück unseres ersten Prototyps ist der $1 Recognizer. Dieser einfache aber mächtige Algorythmus verarbeitet Eingaben (graue Linie) zu Punkt-Mustern (rote Punkte) und vergleicht diese mit gespeicherten Vorlagen. Christoph Ketzler hat den $1 Recognizer für ActionScript3 umgesetzt und der Quellcode lässt sich auf seinem Blog herunter laden. Diesen Code haben wir an unsere Bedürfnisse angepasst, eigene Vorlagen definiert und verschiedene Funktionen ergänzt. So werden z.B. Größe und Position der Geste erkannt um dann ein entsprechendes Element (Kugel oder Schiefe Ebene) auf der Zeichenfläche zu erzeugen.

Prototyp auf dem MT Tisch

Nachtrag: Heute (27.04.) haben wir unseren kleinen Prototyp auf dem MT-Tisch (mit der nativen MT Unterstützung von Windows 7) getestet. Die Gesten-Erkennung hat zwar überraschend gut funkioniert, es hat sich aber auch gezeigt, dass noch einige kleine Bugs zu beseitigen sind.