Simulation von gestischerKommunikation

Studienarbeit

vorgelegt vonHendrik Ziezold

Institut fur ComputervisualistikArbeitsgruppe Computergraphik

Februar 2005

Betreuer und Prufer:Prof. Dr. S. Muller

Inhaltsverzeichnis

1 Einleitung und Motivation 1

2 Konzept und Grundlagen 22.1 Modellierung und Programmierung . . . . . . . . . . . . . . . . . . . 22.2 Storyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Softwaretechnischer Entwurf . . . . . . . . . . . . . . . . . . . . . . . 3

2.3.1 Hauptszene . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.2 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.3.3 Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.4 Modell”gestische Kommunikation“ . . . . . . . . . . . . . . . . . . . 6

2.4.1 Berechnung des Gesten-Vektors . . . . . . . . . . . . . . . . . 82.5 Grundlagen und Begriffe . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.1”keyframing“ . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.2”multiple threading“ . . . . . . . . . . . . . . . . . . . . . . . 9

2.5.3 Java3D - Capability Bits . . . . . . . . . . . . . . . . . . . . . 102.5.4 Java3D - Switch . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3 Realisierung 113.1 Implementierung Hauptszene . . . . . . . . . . . . . . . . . . . . . . . 113.2 Export/Import . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.2.1 Export Poser . . . . . . . . . . . . . . . . . . . . . . . . . . . 123.2.2 Import Java3D . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.3 Implementierung zufallige Bewegung von 3D-Objekten . . . . . . . . 153.3.1 Objekt-Thread . . . . . . . . . . . . . . . . . . . . . . . . . . 153.3.2 Steuerung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.3 Randbehandlung . . . . . . . . . . . . . . . . . . . . . . . . . 173.3.4 Abstandsmessung zwischen Objekten . . . . . . . . . . . . . . 17

3.4 Implementierung Kommunikationsregeln und Attribute . . . . . . . . 183.5 Modellierung/Implementierung Gehen . . . . . . . . . . . . . . . . . 183.6 Modellierung Kommunikationsgesten . . . . . . . . . . . . . . . . . . 193.7 Der Szenegraph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

4 Ergebnisse 21

5 Fazit und Ausblick 25

Abbildungsverzeichnis

2.1 UML Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Statustabelle fur Gestenauswahl . . . . . . . . . . . . . . . . . . . . . 62.3 Zuordnung Gesten-Vektor zu Gestenbeschreibung . . . . . . . . . . . 7

3.1 Posers Exportdialogfenster . . . . . . . . . . . . . . . . . . . . . . . . 123.2 Posermodelleinbindung durch 3DS-Loader-Aufruf . . . . . . . . . . . 133.3 Erscheinungsbild - Modell in Poser . . . . . . . . . . . . . . . . . . . 143.4 Erscheinungsbild - Modell in Java3D . . . . . . . . . . . . . . . . . . 143.5 Farbwurfel auf Plattform . . . . . . . . . . . . . . . . . . . . . . . . . 163.6 frames der Geste

”feedback Intensitat 1“ . . . . . . . . . . . . . . . . 19

3.7 Auszuge des Szenegraphen der endgultigen Realisierung . . . . . . . . 20

4.1 Screenshot Gehen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214.2 Screenshot Treffen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 224.3 Screenshot Gestenbsp. 1 . . . . . . . . . . . . . . . . . . . . . . . . . 234.4 Screenshot Gestenbsp. 2 . . . . . . . . . . . . . . . . . . . . . . . . . 24

1 Einleitung und Motivation

Die Qualititat spielerischer 3D-Anwendungen und 3D-Demonstrationen ergibt sichnicht nur aus professioneller Grafikprogrammierung, sondern durchaus auch auseiner realistischen Lebendigkeit der szenischen Umgebung. Um diesenAnwendungen realistische Lebendigkeit zu verleihen, bedarf es neben deraufwendig geplanten Hauptszene und deren Hauptagenten und -objekten, aucheinem realistisch geplanten Hintergrundleben. Abhangig vom Kontext der Szene,konnte dieser Hintergrund z. Bsp. aus so genannten Statisten bestehen. DieLebendigkeit dieser Statisten ergrundet sich hauptsachlich aus deren Bewegungen,und sie konnten den verschiedensten Aktivitaten nachgehen. In dieserStudienarbeit liegt die Konzentration auf der Aktivitat

”Kommunikation“.

Da fur ein Hintergrundleben in einer Szene der Ton als Sinntrager ausgeschlossenist, werden die Gesten der Statisten, im weiteren Verlauf Agenten genannt, dafurSorge tragen mussen, dem Nutzer das Gefuhl sinnvoller Kommunikation zuvermitteln. Insofern soll eine sinnvolle

”Simulation von gestischer Kommunikation“

versucht werden. Dafur erforderlich sind das Aufstellen einer entsprechenden

”Gestengrammatik“ und eines

”Gestenalphabets“, die Modellierung der Agenten

und die Animation durch Gesten.Dabei sei gesagt, dass das primar verfolgte Ziel dieser Studienarbeit das Aneignenpraktischer Fahigkeiten in der 3D-Graphik-Programmierung ist.

Im Folgenden werden zunachst die gewahlten Arbeitsumgebungen, das Storyboardsowie der softwaretechnische Entwurf erlautert. Anschließend wird die tatsachlicheRealisierung vorgestellt und wichtige Einzelheiten werden detaillierter beschrieben.Letztendlich folgen eine Vorstellung der Ergebnisse und ein Ausblick aufzusatzliche Moglichkeiten und Alternativen der Vorgehensweise.

1

2 Konzept und Grundlagen

Fur die Konzepterstellung muss zunachst die Entscheidung getroffen werden, wieviel Aufwand auf die verschiedenen Komponenten der Arbeit fallen soll. Die Fragestellt sich, ob die graphische Darstellung der Agenten selbst programmiert werdensoll. Aufgrund des damit verbunden Aufwands sollten diese evtl. nur als

”Strichmannchen“ dargestellt werden. Die andere Moglichkeit ware, ein

Modellierungstool fur die Erstellung zu Hilfe zu nehmen, was einen anschließendenImport in einen Szenegraphen erforderlich macht.Die Verwendung eines Modellierungstools mit anschließendem Import in dieProgrammierumgebung stellt nach ersten Recherchen fur das angestrebte Ziel denadaquaten Weg dar, weil Modellierungstools die benotigten Modelle unmittelbarzur Verfugung stellen und eine Modellierung der Gesten relativ einfach moglich ist.Da es außerdem fur die Beurteilung des unter anderem angedachten Ziels, dieGesten moglichst authentisch wirken zu lassen, gewichtig erscheint, eine moglichstrealistische 3D-Darstellung eines menschlichen Agenten zu verwenden, fallt dieEntscheidung auf die Verwendung eines solchen Modellierungstools.

Es wird nun festgelegt, in welchen Umgebungen gearbeitet wird und was dertatsachliche Inhalt der Studienarbeit sein wird. Ein Storyboard und der Entwurfeinzelner Komponenten werden ausformuliert. Eine tatsachlich authentischwirkende Simulation von gestischer Kommunikation setzt eine sinnvolle Abfolgeder Gesten voraus. Regeln und eine Menge an Gesten (Alphabet), auf welchendiese Regeln operieren, werden entworfen und innerhalb dieses Kapitels vorgestellt.

2.1 Modellierung und Programmierung

Das Modellierungstool meiner Wahl ist”Curious Labs’ Poser 5“, welches eine

relativ umfangreiche Bibliothek vormodellierter Charaktere zur Verfugung stellt.Die Implementierung der Anwendung soll in der plattformunabhangigen,multiple-threading-fahigen und objektorientierten Programmiersprache Java unterder Verwendung des Java3D API erfolgen. Fur die Programmierung in Java wirddas j2se1.4.2 SDK und als Virtual Machine das JRE benotigt. Zusatzlich muss dasJava3D API 1.3.1 installiert werden.Als Programmierumgebung soll Eclipse 3.0 dienen.

2

2.2 Storyboard

Fur die Realisierung der Aufgabenstellung dieser Studienarbeit ist die Aufstellungeines Storyboard’s der erste Schritt. Wie und in welcher Form etwas realisiertwerden und vor Allem wie der chronologische Ablauf der Anwendung aussehensoll, wird hier festgelegt. Auch das Verhalten der Agenten sowie alle anderenKomponenten werden hier grob entworfen.

Beim Start der Applikation wird zunachst die einfach gehaltene3D-Szenerie sichtbar, in welcher sich zwei oder mehr Agenten befinden.Diese Agenten bewegen sich (Animation: Gehen) zufallig auf einerPlattform in X- und Z-Richtung. Diese Plattform ist raumlichbegrenzt, das heißt, die Agenten durfen sich vom Ursprung nur bis zueinem festgelegten Radius um den Ursprung entfernen. Treffen sieaufeinander, so drehen sich die Agenten zueinander und fangen an,gestisch zu kommunizieren (Animation: Gesten). Die Gesten werdenaus Gestenmengen, aufgrund von verschiedenen Attributen undvordefinierten Regeln ausgewahlt. Dabei sollen die Gesten einesAgenten die darauf folgende Geste des anderen Agenten bedingen usw.

Nach einer bestimmten Zeit gehen die Agenten wieder auseinanderund bewegen sich wieder zufallig durch den Raum in X- undZ-Richtung. Der beschriebene Ablauf wiederholt sich.

So soll erreicht werden, dass beim Betrachter der Eindruck einer sinnvollenUnterhaltung entsteht, welcher ausschließlich durch die Gesten vermittelt wird.

2.3 Softwaretechnischer Entwurf

Wie zuvor durch den Entwurf des Storyboard’s deutlich geworden, werden fur dieRealisierung der Applikation verschiedene Komponenten benotigt. Es mussen zumeinen die Hauptszene und die Agenten graphisch realisiert und zum anderen dieAnimationen der Gesten und die auslosenden Regeln und Attribute implementiertwerden.Außerdem wird eine Art Kollisionserkennung bzw. Abstandsmessung zwischen denAgenten erforderlich sein, damit diese an passender Stelle anhalten, sichzueinander drehen und mit dem gestischen Kommunizieren beginnen konnen. Voneiner tatsachlichen Kollisionserkennung auf Polygonebene kann fur denangedachten Zweck abgesehen werden, da hier die bloße Ermittlung einebestimmten Abstands ausreicht.Um die Unterteilung in die einzelnen Komponenten klar zu formulieren, folgt einedetailliertere Beschreibung. Anschließend wird in UML (UML= Unified ModellingLanguage [9]) ein Klassendiagramm aufgestellt.

3

2.3.1 Hauptszene

Die Hauptszene wird in der spateren Implementierung der eigentliche Szenegraphsein, in welchen die Agenten

”eingefugt“ werden. Diese Szene besteht zunachst im

Inhalts-Bereich aus einem einfarbigen Hintergrund, einer x-z-Ebene, welche denBoden darstellen wird und verschiedenen Lichtquellen. Dem Kamera-Bereichdieses Szenegraphen soll eine Kameranavigation angehangt werden, damit dieSzene spater aus unterschiedlichen Perspektiven betrachtet werden kann.

2.3.2 Agent

Ein Agent innerhalb dieser Anwendung ist eine graphische 3D-Darstellung bzw.3D-Animation eines Menschen. Dieser Agent kommuniziert mit anderen Agentenuber zuvor definierte Gesten, greift also auf ein zentral gespeichertes Alphabet zu,welches die zuvor modellierten animierten Gesten beinhaltet.

Verhalten

Beim Start der Anwendung bewegt sich der Agent. Bevorzugt soll der Agentumhergehen. Hierfur muss eine Methode

”walk“, die das Gehen eines Menschen

simulieren soll, implementiert werden. Randbedingungen fur das Erreichen derPlattformgrenze der Hauptszene und Abbruchbedingungen fur dasZusammentreffen mit einem anderen Agenten mussen implementiert werden. ImFalle des Zusammentreffens mit einem anderen Agenten, besteht das Verhalten desAgenten aus der gestischen Kommunikation mit diesem Anderen. Eine Methode

”talk“ und Methoden fur die eindeutige Bestimmung der nachstfolgenden Geste

sind wesentlicher Bestandteil des Agentenverhaltens und mussen implementiertwerden.

Graphik

Die graphische Realisierung des Agenten soll durch dasCharakter-Modellierungstool Poser bewerkstelligt werden. Als nachster Schrittmuss die fertige Modellierung fur den Szenegraphen verfugbar gemacht werden.Poser bietet die Moglichkeit, die Korperhaltung der Charaktere zu modifizieren,also die einzelnen Gesten zu modellieren. Dies geschieht nach demWYSIWYG(what you see is what you get)-Prinzip. Dadurch, dass eine direktevisuelle Kontrolle beim Modellieren der Gesten vorgenommen werden kann, sollhier das Ziel sein, nicht nur die Poser-Charaktere fur die Simulation zu nutzen,sondern auch die modellierten Animationen der Gesten.

Fur die Implementierung der Simulation sollen also die in Poser erstelltenGesten-Animationen sowie die Geh-Animation zur Verfugung gestellt werden.

4

Verschiedene Formate, welche von Poser zum Export zur Verfugung gestelltwerden, konnen in den Szenegraphen Java3D uber eine vorhandeneLoader-Schnittstelle in Verbindung mit einem zuvor implementierten loadereingebunden werden. Es werden das Modellierungstool Poser in Verbindung mitdem anschließenden Export/Import uber das .OBJ- und .3DS-Format betrachtet.Um files, die in in diesen Formaten vorliegen, in eine Java3D Anwendung einbindenzu konnen, existieren bereits implementierte open source loader packages.

2.3.3 Klassendiagramm

Das UML-Klassendiagramm in Abbildung 2.1 soll nun den geplanten Aufbau derAnwendung noch einmal ubersichtlicher beschreiben.

Abbildung 2.1: UML Klassendiagramm

5

2.4 Modell”gestische Kommunikation“

Ein zentrales Thema dieser Arbeit ist die Kommunikation der Agenten anhandvon Gesten. Der hier verfolgte Ansatz fur die Bearbeitung dieser Aufgabenstellungist der, dass, ahnlich einer sprachlichen Unterhaltung, ein abwechselnderInformationsaustausch zwischen den Agenten simuliert werden soll. Dabei wirdinnerhalb dieser Arbeit nur die Kommunikation zwischen zwei Agenten betrachtet.

Um den Kontext der Gesten etwas einzugrenzen und doch allgemein genug zubleiben, um dem Betrachter den Eindruck sinnvoller Kommunikation zuvermitteln, ist die Entscheidung auf eine Standard-Gesprachssituation gefallen.Innerhalb dieser Gesprachssituation befindet sich ein Agent selbst in einer internenSituation, d.h. er hat einen bestimmten Status. Status heißt in diesemZusammenhang, er nimmt eine Rolle (Erzahler oder Zuhorer) ein und hat in dieserRolle eine Aktivitat (aktiv oder passiv). Durch die Verknupfung dieser zweiAttribute hat ein Agent einen von vier moglichen Status: Erzahlen (aktiv underzahler), Zuhoren (passiv und zuhorer), Fragen (passiv und erzahler) oderAntworten (aktiv und zuhorer). Hinzu kommt fur die Gestenbestimmung alsdritter Faktor die Intensitat. Die zu entwerfenden Gesten sollen sich durch dieKombination aus den drei Faktoren eindeutig referenzieren lassen.Die drei Faktoren werden dafur in einem Gesten-Vektor abgelegt, der folgendesAussehen hat: (Intensitat, Aktivitat, Rolle). Dieser Vektor dient dann als Referenzauf eine so definierte Geste (s. 2.2).

Abbildung 2.2: Statustabelle fur Gestenauswahl

Die inhaltliche Zuordnung einer Geste zu einem Gesten-Vektor geschieht durch dieaufgestellte Tabelle in Abbildung 2.3.

6

Abbildung 2.3: Zuordnung Gesten-Vektor zu Gestenbeschreibung

7

2.4.1 Berechnung des Gesten-Vektors

Entscheidend fur die Simulation von gestischer Kommunikation nach dem obenvorgestellten Modell ist die funktionale Abhangigkeit und Berechnung derFaktoren, aus denen der Gesten-Vektor besteht. Die Personlichkeit eines Agentenließe sich relativ aufwendig modellieren, jedoch fur das relativ einfach konzipierteModell genugt es, die Personlichkeit auf den Personlichkeits-Intensitatsfaktor zubeschranken. Dieser Faktor wird bei der Initialisierung zufallig vergeben und liegtzwischen 1 (weniger intensiv) und 5 (sehr intensiv). Er ist ausschlaggebend fur dieErmittlung der ersten Komponente des Gesten-Vektors, dem Intensitatsfaktor dernachstfolgenden Geste. Bei den im Folgenden beschriebenen Komponenten desGestenvektors sei hinzugefugt, dass die Werte bei einer Berechnung sowohl fur deneigenen als auch fur den Gestenvektor des Gegenuber abgespeichert werden. Hierwird also immer wieder auf die Zentralintelligenz zugegriffen und die Agentenkonnen so maximal als

”teilautonom“ bezeichnet werden.

Intensitatsfaktor

Die erste Komponente des Vektors steht fur den Intensitatsfaktor der Geste, dereinen Wert zwischen 1 und 5 einnimmt, welcher sich wie folgt berechnet:

intensityFactor - personliche Intensitat

sendGIntensity -Intensitat der letzten eigenen Geste

receiveGIntensity - Intensitat der letzten Geste des Gegenuber

randomFactor - Zufallszahl zwischen 0.0 und 0.5

intens - Intensitat der nachsten Geste

randomFloat = (letzter Rollenfaktor + letzter

Aktivitatsfaktor)*randomFactor

intens = (intensityFactor +3*receiveIntensity +

sendGIntensity + randomFloat) / 5

Aktivitatsfaktor

Der Aktivitatsfaktor, der die zweite Dimension des Gesten-Vektors darstellt,nimmt entweder den Wert 1 (aktiv) oder den Wert -1 (passiv) ein. Dieser Faktorwird zufallig geandert. Mit der Wahrscheinlichkeit von 1/10 wird die Aktivitat aufdie entsprechend andere geandert.

8

Rollenfaktor

Der Rollenfaktor, der letzte ausschlaggebende Faktor, gibt an, ob der Agent, alsZuhorer oder als Erzahler die nachste Geste auswahlt und ausfuhrt.Hier wird die Intensitat der letzten eigenen Geste und die Intensitat der letztenGeste des Gegenuber verglichen. Ist die Intensitat der eigenen Geste kleinergewesen, so wird die Rolle fur die nachste Geste auf Zuhorer gesetzt, ist sie grosserauf Erzahler. Sind die Intensitaten gleich gewesen, so wird die Rolle zufalliggesetzt.

2.5 Grundlagen und Begriffe

2.5.1”keyframing“

Eine in Poser erstellte Charakter-Animation besteht aus mehreren, zuvorfestgelegten frames und keyframes. Keyframing bedeutet, dass frames zwischenmodellierten keyframes

”interpoliert“ werden, bzw. hier in Poser zusatzlich die

Polygone unter Zuhilfenahme von inverser Kinematik neu berechnet werden.Beim Exportieren der Animationen werden dann abhangig vom gewahltenExport-Format die einzelnen frames (inkl. der keyframes) exportiert. Es liegendann Einzelbilder zur weiteren Verwendung vor.

2.5.2”multiple threading“

Multiple Threading ist eine sehr vorteilhafte Eigenschaft von Java. Hierdurch kannman Programm-Prozesse nebenlaufig laufen lassen. Dafur werden die betreffendenKlassen in Threads ausgelagert, was relativ einfach durch die Vererbung von derKlasse thread moglich ist. Diese Klasse benotigt dann noch eine Methode run umvon dem Hauptprogramm gestartet werden zu konnen. Fur die Aufgabenstellungdieser Studienarbeit erscheint diese Vorgehensweise ein brauchbarer Ansatz, da so

”teilautonome“Agenten simuliert werden konnen. Ein Agent besteht nur aus seiner

eigenen Klasse und hat seine eigene Main-Methode, was auch fur eine tatsachlicheKollisionserkennung von Vorteil ware. Sogar eine Gestenerkennung fur die Gestenanderer Agenten ware denkbar. Die Moglichkeit die Anzahl der Agenten zuerhohen ist dann durch einen einfachen Konstruktor moglich.

Im Zuge dieser Studienarbeit, sollen die Agenten aber die relevantenInformationen in einer so genannten Steuerungsklasse und darin enthaltenenTabellen abspeichern. Jeder Agent hat zugriff auf diese Steuerung, sollte aber furdie anderen laufenden Agenten dieses Betriebsmittel, so lange wie etwas ausgelesenoder abgespeichert wird, sperren. Dies geschieht in Java durch Sychnronisation(synchronized siehe Java Dokumentation [2]).

9

2.5.3 Java3D - Capability Bits

Um in einem Szenegraphen auf Objekte zugreifen zu konnen, die bereits an denSzenegraphen angehangt wurden, also lebendig (engl. live) sind, mussen sogenannte

”Capability Bits“gesetzt werden, die angeben, welche Zugriffsmoglichkeit

nachtraglich noch erlaubt sein soll. Ist ein solches Bit vor dem Anhangen desObjektes gesetzt worden, ist eine Manipulation in entsprechender Art und Weiseauch noch nach dem Rendering moglich.Um nun zum Beispiel in einem Szenegraphen ein Objekt, welches ein Kind einerTransformGroup (= Gruppe, welche Transformationsinformationen sowie Objekteenthalt, siehe Java3D Dokumentation [1]) ist, nachtraglich zu bewegen, ist derZugriff auf die Transforminformationen, die sich im Transform3D-Objekt in derTransformGroup, an welches das Objekt angehangt wurde, befinden, erforderlich.Hierfur muss das Capability-Bit ALLOW TRANSFORM WRITE gesetzt werden.In diesem Fall durfen die Transforminformationen, wie Große, Rotation undTranslation geandert werden.Fur nahere Informationen sei auf die Java3D Dokumentation ([1]) verwiesen.

2.5.4 Java3D - Switch

Ein Switch in Java3D umfasst mehrere graphische Objekte. Die Besonderheit ist,dass uber einen Index, welcher den Objekten zugeteilt wird, entschieden wird,welches Objekt gerade gerendert werden soll. Die anderen im Switch enthaltenenObjekte sind solange inaktiv, bis sie selektiert werden. Mit Hilfe von einem Switchlassen sich Animationen durch keyframing (2.5.1) realisieren (siehe Java3DDokumentation [1]).

10

3 Realisierung

In diesem Kapitel wird die Umsetzung des in Kapitel 2 verfassten Storyboards(2.2) und softwaretechnischen Entwurfs (2.3) beschrieben. Die Realisierung erfolgtin einzelnen Teilaufgaben. Erst nach der technischen Realisierung der einzelnenTeilaufgaben werden die Teilaufgaben in einer Implementierung vereint undinhaltlich weiter ausgearbeitet. In diesem Kapitel wird zunachst die Hauptszeneund der Import von Poser-Modellen in die Java3D Umgebung beschrieben. DieMoglichkeiten, die sich daraus fur die weitere Nutzung der Modelle ergeben,werden dargestellt. Ein weiterer Aspekt ist die Implementierung der Gestenauswahlmit den dazugehorigen Regeln und Attributen. Abschließend in diesem Kapitelbeschreibt eine graphische Darstellung Auszuge des endgultigen Szenegraphen.

3.1 Implementierung Hauptszene

Die Hauptszene der Anwendung besteht nur aus der Platform, auf welcher dieAgenten spater agieren sollen. Weitere Einstellungen wie die Hintergrundfarbe etc.sind auch dieser Hauptszene zuzuschreiben. Die Hauptszene befindet sich imHauptprogramm, in welchem durch Anhangen an den Ursprung des Szenegraphendas Rendering ausgelost wird.

3.2 Export/Import

Wichtig fur die weitere Verfolgung des Ansatzes, die Charaktere und Gesten vorabin Poser zu modellieren und uber ein gangiges Format fur die Verwendung inJava3D zur Verfugung zu stellen, ist ein vorlaufiger Testlauf diesesArbeitsschrittes. Es soll ein Charakter aus Poser exportiert und in Java3Deingebunden werden. Die verschiedenen Charaktere aus der Poser-Bibliothekhaben eine unterschiedliche Anzahl an Polygonen und so wird fur die Performanzein Modell mit einer geringeren Polygonanzahl ausgewahlt. Der gewahlteCharakter ist bereits seit der Poser Version 2 enthalten und heißt Poser 2 lo casualman. Neben der Anzahl der Polygone der Charaktere existieren weitereUnterschiede fur den anschließenden Import. Im Folgenden liegt die Konzentrationauf den Formaten .OBJ und .3DS. Im Wesentlichen gleichen sich die Vorgange furden Export/Import der beiden Formate, so dass hier nur der Vorgang fur dasletztendlich genutzte Format 3DS detailliert beschrieben wird.

11

3.2.1 Export Poser

Fur den Export ist in Poser eine Export-Funktion integriert. Hier kann zwischenverschiedenen Formaten ausgewahlt werden. Als Format wird nun das 3DS-Formatfur den Export ausgewahlt.

3DS

Exportiert man in das 3DS-Format, so erscheint ein Dialog, in welchem zwischenEinzelbild oder gesamter Animation ausgewahlt werden kann. Als nachsteserscheint ein Fenster mit einer Darstellung der Poser-Szene in Baumstruktur, wodie Moglichkeit einige Korperteile oder aber auch andere Komponenten separat furden Export ab- bzw. auszuwahlen (siehe Abbildung 3.1). Da der Charakter spaterin die Hauptszene als Agent eingefugt werden soll, wird nur die Figur und nichtdie gesamte Poser-Szene ausgewahlt.

Abbildung 3.1: Posers Exportdialogfenster

Schließlich erscheint eine weitere Abfrage durch Poser, und es soll entschiedenwerden, ob einzelne Gruppen fur die Korperteile exportiert werden sollen. Da evtl.noch auf einzelne Korperteile zugegriffen werden soll, wird hier diese Optionbestatigt. Diese Option macht es moglich, zum Beispiel die Hemden der Agentenspater unterschiedlich einzufarben.

12

3.2.2 Import Java3D

Java3D verfugt bereits uber einen internen loader fur das .OBJ Format. Furweitere Formate, so auch fur das 3DS-Format werden auf der Java3D-Webseite [3]verschiedene open source loader-packages aufgelistet, die sich in die eigeneAnwendung einbinden lassen. Da das .OBJ Format einige Probleme bei der Texturbereitet, erscheint das .3DS Format das geeignetere. Der Loader fur das3DS-Format meiner Wahl ist der von Josh DeFord und Eric Miller, der auf derSourceforge-Webseite [7] zum download steht. Der Loader leistet nun das Auslesender Szene aus einem angegebenen 3DS-file. Nun steht der Inhalt dieser Szene furdie weitere Verwendung in Java3D zur Verfugung. (siehe Abbildung 3.2).

Abbildung 3.2: Posermodelleinbindung durch 3DS-Loader-Aufruf

Hangt man den gewahlten Poser-Charakter Poser 2 lo casual human in denSzenegraphen, so erscheint die Farbgebung des Charakters in Java3D falsch. Beider naheren Betrachtung der importierten Poser-Szene im Debug-Modus vonEclipse ist zu Erkennen, dass nicht nur die Korperteile exportiert wurden, sonderndass außerdem verschiedene Lichtquellen in dieser Szene enthalten sind. DieseLichtquellen lassen sich aus der Szene entfernen.Das Erscheinungsbild des Charakters im Java3D-Szenegraphen (3.4) ist dannahnlich wie das in Poser(3.3).

13

Abbildung 3.3: Erscheinungsbild - Modell in Poser

Abbildung 3.4: Erscheinungsbild - Modell in Java3D

14

Im Debug-Modus ist auch zu erkennen, dass die in Abbildung 3.1 vorhandeneBaumstruktur des Posermodells nicht mit der Baumstruktur der importiertenSzene ubereinstimmt. Hier sind die Korperteile Kinder auf gleicher Ebene.Weiterhin hat sich herausgestellt, dass, durch den Export der Charaktere inEinzelbilder, samtliche Transformationsinformationen, welche noch in Poser injedem frame fur jedes Korperteil zu manipulieren waren, verloren gehen. Dies istder Fall, weil die frames in Poser nach jeder Manipulation neu errechnet werdenund Methoden der inversen Kinematik die Polygonenzahl und das Ausseheneiniger Korperteile verandern. Daher wurde es fur Poser keinen Sinn machen, dieTransformationsinformationen mit zu exportieren, da sich die Objekte unterhalbdieser Transformknoten verandert haben.Es bleibt also die Moglichkeit, will man die modellierten Gesten in Java3Dverwenden, diese in Form von mehreren Einzelbildern einzubinden.

3.3 Implementierung zufallige Bewegung von

3D-Objekten

Zunachst soll sich ein abstraktes Objekt zufallig auf der Plattform bewegen. Dasverwendete Objekt fur die folgenden Arbeitsschritte, ist der von Java3Dbereitgestellte Farbwurfel (colorcube) auf Abbildung 3.5, der durch dieverschiedenen Farben alle wesentlichen Eigenschaften besitzt und so als Testobjektfur einen menschlichen Agenten vorerst eingesetzt werden kann.

Damit die Bewegung der Wurfel zufallig und zur Laufzeit berechnet werden, ist esnotig, auf Kinder des bereits kompilierten Szenegraphen zuzugreifen. Hierfurmussen, so genannte

”Capability Bits“ (siehe Kapitel 2.5.3) fur das betreffende

Kind gesetzt werden.

Zu Beginn der Anwendung sollen sich diese Objekte auf einer beliebigen Positionauf der Plattform befinden. Nachdem der Szenegraph das erste Mal

”gerendert“

wurde, ist uber die zuvor gesetzten Capability Bits noch der Zugriff auf dierelevanten Informationen moglich. Damit die Bewegung der Objekte derenVerhalten darstellt, werden diese durch einen eigenen Objekt-Thread realisiert(Grundlagen zu multiple threading s. 2.5.2).

3.3.1 Objekt-Thread

Die Objekt-Threads haben durch die Nebenlaufigkeits-Eigenschaft ein eigenesVerhalten, und konnen unabhangig vom Hauptprogramm oder anderen threadsablaufen. Nur gemeinsam genutzte Datenstrukturen außerhalb des Objekt-Threadsmussen synchronisiert (siehe 2.5.2) werden. Dies ist auch ein wichtiger Schritt, dieAgenten bzw. vorerst die Objekte, so weit wie moglich autonom zu halten. Sie

15

Abbildung 3.5: Farbwurfel auf Plattform

werden nicht von einer zentralen Intelligenz gesteuert, greifen jedoch auf die ineiner solchen zentralen Intelligenz gespeicherten Informationen, wieTransform-Informationen, zu.In dieser Ausarbeitung fungiert eine so genannte Steuerung als zentrale Intelligenz,welche im wesentlichen aus Tabellen und anderen Datenstrukturen besteht.

Die implementierte Objekt-Klasse soll nun noch in das Hauptprogramm, also deneigentlichen Szenegraphen eingebunden werden. Dafur muss zunachst eine Instanzder Klasse konstruiert und dann der neue Thread gestartet werden. Erst durch dasStarten des Threads, wird die run-Methode der Klasse aufgerufen und dasVerhalten kann gestartet werden. Durch wait-Anweisungen kann spater der Threadan bestimmten Stellen, an welchen dies fur den gesamten Ablauf der Anwendungsinnvoll ist, angehalten werden. Fur nahere Informationen uber Vererbung derThreadklasse und allgemeine Informationen zu Threads wird auf dieJava-Dokumentation ([2]) oder auf GoTo Java2 von G. Kruger ([4]) verwiesen.

16

3.3.2 Steuerung

Die hier so benannte Steuerung ist das zentrale Betriebsmittel fur dieAgentenobjekte. Hier sollen alle Daten abgespeichert und verwaltet werden, welchevon den Agentenobjekten spater gebraucht werden. Dort zu speicherndeInformationen sind die Positionsinformationen, die Gestenvektorinformationen unddiverse Steuerungsvariablen. Die Daten stehen dann unter bestimmtenBedingungen den Agentenobjekten wieder zur Verfugung. Dies allerdings zu einemZeitpunkt t nur genau einem Agentenobjekt. Dieses Objekt sperrt dasBetriebsmittel durch Synchronisierung und gibt es fur andere Zugriffe nachBeendigung des Zugriffs wieder frei.

Die Tabellen in der Steuerung haben zwei Spalten, von denen in der ersten derSchlussel des Objekts und in der zweiten die zu relevanten Informationenabgespeichert werden. Wird dann spater erneut ein Paar in die Tabelle eingegeben,von denen der Schlussel bereits in der Tabelle existiert, so wird die alte zu demSchlussel gehorige Information durch die neue uberschrieben. So wird zum Beispielin der Transform3D-Tabelle die aktuelle Position eines Objektes nach jederPositionsanderung abgespeichert. Dies ist relevant fur die hier realisierteRandbehandlung und die Abstandsmessung zwischen verschiedenen Objekten.

3.3.3 Randbehandlung

Randbehandlung heißt in diesem Zusammenhang, dass die Objekte den Rand derPlattform erreichen und, um sich weiterhin innerhalb der Plattform zu bewegen,ein bestimmtes Verhalten annehmen. Eine vereinfachte Methode, die hier realisiertwird, besteht daraus, dass sie auf der Stelle stehen bleiben und sich wieder inRichtung Innenraum der Plattform drehen.

3.3.4 Abstandsmessung zwischen Objekten

Bevor ein Objekt bewegt wird, wird untersucht, ob es in seiner Umgebung bereitsein Objekt gibt, mit welchem es kommunizieren konnte. Dies wird ermittelt, indemaus der Steuerung aus der Transform3D-Tabelle fur jedes Objekt auf der Plattformder Translationsvektor ausgelesen wird. Anhand der nun verfugbarenTranslationsvektoren der anderen Objekte kann der Abstand zwischen demaktuellen und allen anderen Objekten errechnet werden. Erst wenn ein vorherfestgelegter Abstand zu keinem anderen Objekt unterschritten wird, wird die neuePosition des Objektes auf der Plattform berechnet.Sobald sich zwei Objekte auf der Plattform

”treffen“, bzw. einen bestimmten

Abstand unterschreiten, drehen sie sich zueinander und konnen mit der gestischenKommunikation beginnen. Fur die Drehung wird zunachst der Vektor zwischenden beiden Objekten bestimmt und so der Winkel errechnet, in welchen sich das

17

Objekt drehen soll. Die Drehung selbst geschieht in 5◦ Schritten und in dieRichtung in welche die zu leistende Drehung kleiner ist.

3.4 Implementierung Kommunikationsregeln und

Attribute

Wie bei der Planung in 2.4 im”Modell gestische Kommunikation“ entworfen,

geben ein Personlichkeitsintensitatsfaktor sowie die Attribute der eigenen undfremden Vorgangergeste den Ausschlag fur die Bestimmung der aktuellen Geste.Die Methoden, die die Attribute der aktuellen Geste bestimmen, sind Teil einerTalk-Methode des Agenten-Threads, und sind neben einer Walk-Methode daszweite mogliche Verhalten eines Agenten.Die eindeutige Referenz auf eine Geste durch den neu bestimmten Gesten-Vektorist der Schlussel in einer Tabelle in der Steuerung, in welcher zu diesen Schlusselnjeweils eine Geste zugeordnet ist. Eine

”Geste“ besteht aus einem Switch 2.5.4, in

welchem die einzelnen frames einer modellierten Gesten-Animation aus Poserabgelegt werden, und anschließend die indexierten frames in einer Schleifenacheinander abgespielt werden.Die Realisierung der Animation durch einen Switch gilt sowohl fur dieKommunikationsgesten als auch fur das Gehen. Wird eine Animation durch eineandere abgelost, so muss der alteSwitch durch den neuen ersetzt werden. Hierfurmussen ebenfalls die spezifischen Capability Bits 2.5.3 gesetzt werden.

3.5 Modellierung/Implementierung Gehen

Nachdem die Basis fur die Bewegung der Agenten bereits durch dieAbstandsmessung und Thread-Implementierung geschaffen ist, konnen nun dieQuadrate durch reale Agenten ersetzt werden.Es werden nun animierte Posercharaktere eingebunden. Poser bietet bereits eineFunktion an, welche ein zuvor gewahltes Poser-Modell animiert, so dass dasModell auf der Stelle geht. Diese Funktion ist optimal. Als frame-Anzahl werdenfur die Gehen-Animation 15 frames eingestellt. Die Animation ist zyklisch, washeißt, dass die Animation nahtlos wiederholt werden kann. Diese frames werden inder Anwendung in einen Switch (2.5.4) gelegt und der Reihenfolge nachdurchlaufen und nur die Position wird durch die Walk-Methode bestimmt. Die altePosition und Blickrichtung werden in dieser Methode betrachtet. Die Blickrichtungdarf sich nur um maximal 15◦ andern und die Position wird anhand des durch dieBlickrichtung vorgegebenen Richtungsvektors in diese Richtung abgeandert. Beijeder Positions- und Richtungsanderung wird der nachstfolgende frame derAnimation aktiviert, so dass der Eindruck eines Laufenden Menschen entsteht.

18

3.6 Modellierung Kommunikationsgesten

Die 20 Kommunikationsgesten, die fur die das aufgestellte Gestenmodell 2.4benotigt werden, werden in Poser erstellt. Die einzelnen Animationen derKommunikationsgesten werden in je 9 frames realisiert, von der Startposition zurGestenposition. Diese 9 frames werden spater in der Anwendung zunachstvorwarts, dann ruckwarts abgespielt. Dies ist erforderlich, da die Grundhaltungdes Modells fur jede Geste zu Begin die gleiche ist.

Fur die Modellierung in Poser werden recht komfortable Funktionen zur Verfugunggestellt. Zum einen kann ein Korperteil durch Manipulation mit der Maus bewegt,rotiert etc. werden, zum Anderen konnen fur die verschiedenenTransformationskomponenten exakte Werte eingegeben werden (siehe dazu dasPoser 5 Handbuch [5]). Modelliert man nur die so genannten Schlusselframes, sowerden die frames zwischen diesen Schlusselframes automatisch durch Posergeneriert.

Folgende Abbildung zeigt ein Beispiel der frames einer modellierten Geste inPoser.

Abbildung 3.6: frames der Geste”feedback Intensitat 1“

19

3.7 Der Szenegraph

Hier wird der endgultige Aufbau der Anwendung durch die graphische Darstellungvon Auszugen des Szenegraphen beschrieben. Wobei die Tiefe des Graphen meistnur bis zu den Gruppen reicht. Der Inhalt fur die graphische Darstellung derAnimationen der Agenten befindet sich in den einzelnen Szenen (SC), die durchden loader eingebunden wurden. Die Position der Agenten ist in derTransformGroup vor der BranchGroup fur den Switch zu finden. Fur ein besseresVerstandnis zur graphischen Darstellungsform wird auf das Java3D Sun Tutorial[8] verwiesen.

Abbildung 3.7: Auszuge des Szenegraphen der endgultigen Realisierung

20

4 Ergebnisse

Abbildung 4.1: Screenshot Gehen

21

Abbildung 4.2: Screenshot Treffen

22

Abbildung 4.3: Screenshot Gestenbsp. 1

23

Abbildung 4.4: Screenshot Gestenbsp. 2

24

5 Fazit und Ausblick

Im Verlauf dieser Arbeit wurden Modelle fur gestische Kommunikation aufgestelltund eine konkrete Realisierung umgesetzt. Der verfolgte Ansatz war, externmodellierte Agenten in Java3D uber das 3DS-Format einzubinden. DieMoglichkeiten, die die Einbindung statischer Einzelbilder mit sich bringen, sindallerdings sehr beschrankt. Die gewahlte Losung kann aber erste Eindrucke zu dembeispielhaft aufgestellten Modell gestischer Kommunikation liefern.

Die Realisierung der einzelnen Agenten durch Threads ermoglicht die ansatzweiseautonome Ausrichtung der Agenten. Hier konnten Methoden fur dieGestenerkennung, so etwas wie der Aufbau einer erfahrungsbasierten Wissensbasisund evtl. andere Methoden der K.I. oder Bilderkennung eingebunden werden.Spannend ware auch die Erweiterung um zusatzliche Agenten, und deren gestischeKommunikation in Gruppen.

Neben der Wahl des zugrundeliegenden”Modells gestischer Kommunikation“ war

die graphische Realisierung Hauptthema der Arbeit. Ein alternatives Vorgehen, inwelchem das Posermodell erst nach dem Import nach Java3D animiert wird, waresicher auch interessant zu betrachten. Der Vorteil, eine direkte visuelle Kontrollebei der Modellierung der Gesten zu haben, ginge dann allerdings verloren.

Abschließend sei gesagt, dass die Herausforderung, eine graphische Realisierungvon sinnvollem Verhalten zu erreichen, eine spannende und anspruchsvolleAufgabe in vielen Bereichen der Informatik ist.

25

Literaturverzeichnis

[1] Java3D Dokumenation. java.sun.com/products/java-media/3D/download.html.2004

[2] Java Dokumentation. java.sun.com/j2se/1.4.2/docs/api/index.html. 2004

[3] Java3D-Webseite. www.j3d.org/utilities/loaders.html. 2004

[4] Kruger, Guido. GoTo Java. Addison Wesley. 1999

[5] Poser 5 Handbuch. Curious Labs. 2002

[6] Selmann, Daniel. Java3D Programming. Manning Publications. 2002

[7] Sourceforge-Webseite. sourceforge.net/projects/java3dsloader/, 2004

[8] Sun. Java3D Tutorial.http://java.sun.com/products/java-media/3D/collateral/. 2001

[9] Unified Modelling Language specification, www.uml.org

26