Jörn Tümmler - Universität Kassel: Aktuelles · possible and permits the usage of these aatarsv in real time 3D applications. The basic idea of this work is to integrate existing

Jörn Tümmler

Avatare in Echtzeitsimulationen

Die vorliegende Arbeit wurde vom Fachbereich Elektrotechnik/Informatik der Universität Kassel als

Dissertation zur Erlangung des akademischen Grades eines Doktors der Ingenieurwissenschaften (Dr.-Ing.)

angenommen.

Erster Gutachter: Prof. Dr.-Ing. Dieter Wloka

Zweiter Gutachter: Prof. Dr.-Ing. Siegbert Hentschke

Tag der mündlichen Prüfung 27. Februar 2007

Bibliografische Information der Deutschen Nationalbibliothek

Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen

Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über

http://dnb.ddb.de abrufbar

Zugl.: Kassel, Univ., Diss. 2007

ISBN 978-3-89958-291-8

URN: urn:nbn:de:0002-2913

© 2007, kassel university press GmbH, Kassel

www.upress.uni-kassel.de

Druck und Verarbeitung: Unidruckerei der Universität Kassel

Printed in Germany

Danksagung

Ich möchte mich ganz herzlich bei Herrn Prof. Dr.-Ing. Dieter Wloka für die Themen-stellung und die Betreuung dieser Arbeit bedanken. Weiterhin bedanke ich mich beiihm für die Scha�ung der notwendigen Arbeitsvoraussetzungen und sein stets fördern-des Interesse. Herrn Prof. Dr.-Ing. Siegbert Hentschke danke ich für die Bereitschaft,die Begutachtung meiner Arbeit mit zu übernehmen.

Besonders bedanken möchte bei Frau Andrea Mäder, der Sekretärin des Fachgebiets�Technische Informatik�, die tatkräftig viele bürokratische Hindernisse aus dem Weggeräumt hat. Ebenso möchte ich meinen Kollegen, Herrn Dipl. Technoinform. KaiesChaouch, Herrn M. Sc. Johann Löwen, Herrn M. T. Bheta Agus Wardijono und HerrnDipl.-Ing. Matthias Wolf für zahllose fruchtbare Diskussionen und das angenehme Ar-beitsklima danken.

Mein Dank gilt auch meiner Familie für die Unterstützung während der Durchführungder Promotion. Insbesondere danken möchte ich meiner Frau Sandra Tümmler für dasKorrekturlesen des Manuskripts und den Mut, den sie mir zusprach, sowie unsererTochter Hanna, dass sie geduldig auf die Fertigstellung der Arbeit wartete.

Jörn Tümmler

Zusammenfassung

Durch die enorm gestiegene Leistungs- und Gra�kfähigkeit heutiger Computer begeg-nen uns computergenerierte Menschenmodelle in vielen Lebensbereichen. Trotz dervielen Fortschritte und dem weit verbreiteten Einsatz sind solche als "Avatare" be-zeichneten Modelle aus Entwicklersicht aber immer noch Spezialanwendungen, die füreine bestimmte Anwendung entwickelt werden. Dies hat zu vielen Insellösungen ge-führt, die sich in der Regel schlecht zu einer Gesamtlösung kombinieren lassen. DasZiel dieser Arbeit ist daher, ein Konzept zu entwickeln und umzusetzen, welches dieModellierung animierbarer und sprechender Avatare ermöglicht und deren Einsatz inEchtzeit 3D Simulationen zulässt.

Die grundlegende Idee der vorliegenden Arbeit ist, so weit wie möglich vorhandeneKomponenten zu einem Gesamtsystem zu kombinieren. Zwei groÿe Problembereichekonnten identi�ziert werden. Bei dem ersten Problembereich handelt es sich um dieModellierung und Animation von Avataren mit existierenden Programmen. Hierzu wer-den exakte Arbeitsabläufe benötigt, damit bei einer Kombination dieser Programmereproduzierbare Ergebnisse erzielt werden können. Im Rahmen dieser Arbeit wird da-her eine Dokumentation von Arbeitsabläufen entwickelt und an praktischen Beispielenvorgestellt, die auf der "Business Process Modeling Notation" (BPMN) aufbaut.

Der zweite Problembereich ist die Echtzeit-Darstellung in einer virtuellen Umgebung.Im Rahmen der Arbeit wird dazu ein Laufzeitsystem entwickelt, welches auf vorhande-ne OpenSource-Komponenten aufbaut. Lippensynchrone Sprachanimation wird dabeidurch ein modulares Sprachsystem auf Basis von Morph-Animationen ermöglicht. DieDarstellung der Avatare wird durch die Erweiterung eines Szenengraphen um einenAvatar-Knoten realisiert, welcher zur Steigerung der Darstellungsqualität auch Gra�k-E�ekte wie Transparenzmasken und Bump-Mapping unterstützt. Dieses System erlaubtauch die Darstellung in der CasCave - einer immersiven Multiprojektionsumgebung.

Als universelle Steuerungsmöglichkeit werden Skript-Knoten entwickelt. Auf diese Wei-se können nicht nur die Avatare selbst, sondern auch andere Objekte der Simulationgesteuert werden. Zusätzlich werden Strategien in Form von Idiomen entworfen, mitdenen sich Steuerungsaufgaben von Avataren lösen lassen.

Letztendlich muss auch eine Brücke zwischen der Erstellung der Inhalte einerseits unddem Laufzeitsystem andererseits gescha�en werden. Hierzu werden verschiedene gra�-sche Werkzeuge entwickelt, die eine Umwandlung der Daten in das Laufzeitformat, dieKon�guration von Avataren, sowie eine leichte Umwandlung von statischer in animier-bare Geometrie ermöglichen.

Insgesamt wird ein System vorgestellt, welches die gesamte Bandbreite von der Modell-erstellung bis zur Darstellung in der CasCave abdecken kann. Dabei werden auch einigeProjekte präsentiert, in denen das entwickelte System bereits zum Einsatz gekommenist.

Abstract

Due to the great improvements of today's computer graphics hardware computer gene-rated models of humans are widely used and become more and more common. Despitenumerous research-results the application of those so-called "avatars" still results inthe development of specialized software. This led to many isolated solutions whichcan hardly be integrated into an overall concept. The aim of this work is to developand realize a concept which makes the modeling of animatable and speaking avatarspossible and permits the usage of these avatars in real time 3D applications.

The basic idea of this work is to integrate existing components into an overall system asfar as possible. Two large problem areas have been identi�ed. The �rst area is dealingwith the problem of modeling and animating avatars by using existing programs. Ifmore than one application is used accurate work�ows are needed which allow thecombination of available applications. In the context of this work a documentation ofwork�ows on basis of the "Business Process Modeling Notation" (BPMN) is thereforedeveloped.

The second problem area concerns real time rendering in a virtual environment. Inthis work a runtime system is introduced which is built on top of existing open-sourcecomponents. Lip-synchronous speech animation is made available by implementing amodular speech-subsystem based on morph animations. The visual representation ofavatars is realized by extending a scene graph by an avatar knot. This knot also supportsvisual e�ects like transparency masks and bump mapping. The developed system alsopermits visualizations in the CasCave - an immersive multi-projection environment.

Control of avatars is achieved by the implementation of a script knot. This solutionhas the advantage that this knot-type may also be used for general steering purposes.In order to make the control of avatars easier, this work also presents some controlstrategies in form of idioms.

Finally a bridge between the model and animation stage on the one hand and theruntime system on the other is needed. This problem is solved by developing graphicaltools to transform the avatar-data into the runtime format, to con�gure avatars, andto easily transform static geometry into animatable geometry.

On the whole a system is presented which is able to cover the entire range from themodel production to visual representation in the CasCave. To demonstrate the practicalapplication of the system, some projects are presented at the end of this work.

Inhaltsverzeichnis

1 Einleitung 1

1.1 Forschungsbereiche des Fachgebiets Technische Informatik . . . . . . . 2

1.2 ICS - Ein System zur Erstellung von interaktiven Inhalten . . . . . . . 3

1.3 Problemstellung und Ziele der Arbeit . . . . . . . . . . . . . . . . . . . 4

1.4 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.5 Sprachliche Konventionen . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Stand der Technik 7

2.1 De�nition des Begri�s �Avatar� . . . . . . . . . . . . . . . . . . . . . . 7

2.2 Anwendungsbereiche von Avataren . . . . . . . . . . . . . . . . . . . . 9

2.2.1 Virtuelle Konferenzen und Umgebungen . . . . . . . . . . . . . 9

2.2.2 Trainingssimulationen . . . . . . . . . . . . . . . . . . . . . . . 11

2.2.3 Spiele und Unterhaltung . . . . . . . . . . . . . . . . . . . . . . 12

2.2.4 Präsentation von Informationen . . . . . . . . . . . . . . . . . . 14

2.2.5 Tutoren in virtuellen Lehrumgebungen . . . . . . . . . . . . . . 15

2.2.6 Ergonomieuntersuchungen . . . . . . . . . . . . . . . . . . . . . 16

2.3 Modellierung von Avataren . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3.1 Techniken zur Repräsentation der Geometrie . . . . . . . . . . . 17

2.3.2 Methoden zur Modellierung der Geometrie . . . . . . . . . . . . 18

2.3.3 Beein�ussung des Aussehens von Avataren durch Texturen . . . 21

2.4 Animation von Avataren . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.4.1 Techniken zur Verformung der Avatar Geometrie . . . . . . . . . 23

2.4.2 Verformung des Körpers . . . . . . . . . . . . . . . . . . . . . . 26

2.4.3 Verformung des Gesichts . . . . . . . . . . . . . . . . . . . . . . 26

2.4.4 Animationstechniken . . . . . . . . . . . . . . . . . . . . . . . . 28

2.5 Vorhandene Modellierungs- und Animationsprogramme . . . . . . . . . 34

2.5.1 Allgemeine Modellierungs- und Animationsprogramme . . . . . 34

i

ii INHALTSVERZEICHNIS

2.5.2 Spezialisierte Avatar Modellierungsprogramme . . . . . . . . . . 35

2.5.3 Spezialisierte Avatar Animationsprogramme . . . . . . . . . . . 36

2.5.4 Gegenüberstellung der Programme . . . . . . . . . . . . . . . . 37

2.6 Vorhandene Datenformate für Avatare . . . . . . . . . . . . . . . . . . 39

2.6.1 Datenformate für die Speicherung des Modells . . . . . . . . . . 39

2.6.2 Datenformate für die Speicherung von Animationen . . . . . . . 40

2.6.3 Datenformate für die Speicherung von Modell und Animation . 40

2.6.4 Gegenüberstellung der Datenformate . . . . . . . . . . . . . . . 41

2.7 Vorhandene Echtzeit Avatar-Systeme . . . . . . . . . . . . . . . . . . . 41

3 Konzept des Avatar-Systems 47

3.1 Anforderungen an das Avatar-System . . . . . . . . . . . . . . . . . . . 47

3.2 Einbeziehung vorhandener Anwendungen und Lösungen . . . . . . . . . 48

3.2.1 Integration von 3D Anwendungen durch Dokumentation von Ar-beitsabläufen . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

3.2.2 Implementierung des Avatar-Systems auf Basis vorhandener Kom-ponenten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.3 Unterstützung mehrerer Betriebssysteme . . . . . . . . . . . . . . . . . 51

3.4 Einfache Modellierung von Avataren . . . . . . . . . . . . . . . . . . . . 52

3.4.1 Anforderungen an die Avatarmodellierung . . . . . . . . . . . . 52

3.4.2 Auswahl der Modellierungsprogramme . . . . . . . . . . . . . . 53

3.4.3 Verwendung von Modellbibliotheken . . . . . . . . . . . . . . . 54

3.5 Änderbares Aussehen von Avataren . . . . . . . . . . . . . . . . . . . . 55

3.5.1 Aufbau von Textur- und Modellbibliotheken . . . . . . . . . . . 55

3.5.2 Kon�guration von Avataren . . . . . . . . . . . . . . . . . . . . 56

3.6 Realistische Animation von Avataren . . . . . . . . . . . . . . . . . . . 56

3.6.1 Anforderungen an die Animation . . . . . . . . . . . . . . . . . 57

3.6.2 Auswahl der Programme für die Animation . . . . . . . . . . . . 58

3.7 Möglichkeit zur Gesichtsanimation und Sprachausgabe . . . . . . . . . 58

3.7.1 Anforderung an die Gesichtsanimation und Sprachausgabe . . . 59

3.7.2 Gesichtsanimation mit Audio-Dateien . . . . . . . . . . . . . . . 59

3.7.3 Gesichtsanimation mit Text-to-Speech . . . . . . . . . . . . . . 60

3.8 Entwicklung eines Avatar API . . . . . . . . . . . . . . . . . . . . . . . 61

3.9 Rapid Prototyping und �exible Steuerung von Avataren . . . . . . . . . 62

3.9.1 Anforderung an die Skripting Sprache . . . . . . . . . . . . . . . 63

3.9.2 Auswahl der Skripting Sprache . . . . . . . . . . . . . . . . . . 63

INHALTSVERZEICHNIS iii

3.10 Darstellung und Animation in Echtzeit . . . . . . . . . . . . . . . . . . 64

3.10.1 Anforderungen an die Darstellung der Avatare . . . . . . . . . . 64

3.10.2 Auswahl des Darstellungssystems . . . . . . . . . . . . . . . . . 65

3.10.3 Auswahl des Animationssystems . . . . . . . . . . . . . . . . . . 66

3.10.4 Darstellung der Avatare in der CasCave . . . . . . . . . . . . . . 67

3.10.5 Auswahl des Audiosystems . . . . . . . . . . . . . . . . . . . . . 68

3.11 Systemüberblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

3.11.1 Modellierung und Animation der Avataren . . . . . . . . . . . . 69

3.11.2 Kon�guration von Avataren . . . . . . . . . . . . . . . . . . . . 70

3.11.3 Steuerung der Avatare . . . . . . . . . . . . . . . . . . . . . . . 70

3.11.4 Darstellung von Avataren . . . . . . . . . . . . . . . . . . . . . 72

4 Modellierung von Avataren 75

4.1 Grundsätzliche Hinweise zur Modellierung von Avataren . . . . . . . . . 75

4.1.1 Aufbau der Skelettstruktur . . . . . . . . . . . . . . . . . . . . . 75

4.1.2 Modellierung des sichtbaren Avatarmodells . . . . . . . . . . . . 76

4.1.3 Standard-Pose für die Modellierung . . . . . . . . . . . . . . . . 77

4.1.4 Skalierung von Avataren . . . . . . . . . . . . . . . . . . . . . . 78

4.2 Programme und Datenformate für die Avatar Modellierung . . . . . . . 79

4.3 Dokumentation der Arbeitsabläufe . . . . . . . . . . . . . . . . . . . . 80

4.4 Arbeitsabläufe zur Avatar-Modellierung . . . . . . . . . . . . . . . . . . 82

4.4.1 Modellierung mit Poser . . . . . . . . . . . . . . . . . . . . . . . 83

4.4.2 Erstellung von Morph-Zielen mit Poser . . . . . . . . . . . . . . 85

4.4.3 Konvertierung von Poser Daten in das FBX Format . . . . . . . 87

4.4.4 Aufbereitung eines Poser Modells . . . . . . . . . . . . . . . . . 88

4.4.5 Korrektur eines Modells . . . . . . . . . . . . . . . . . . . . . . 91

4.4.6 Vorbereiten eines Modells für die Animation . . . . . . . . . . . 93

4.4.7 Export eines Modells in das FBX-Format . . . . . . . . . . . . . 94

5 Animation von Avataren 97

5.1 Grundsätzliche Hinweise zur Animation von Avataren . . . . . . . . . . 97

5.1.1 Struktur der Bewegungsdaten . . . . . . . . . . . . . . . . . . . 97

5.1.2 Gesichtsanimation mit Audiodaten . . . . . . . . . . . . . . . . 98

5.2 Programme und Datenformate zur Animation von Avataren . . . . . . 98

5.3 Arbeitsabläufe zur Avatar-Animation . . . . . . . . . . . . . . . . . . . 100

5.3.1 Vorbereitung des Avatar-Modells für die Animation . . . . . . . 101

iv INHALTSVERZEICHNIS

5.3.2 Charakterisierung des Avatar-Modells . . . . . . . . . . . . . . . 103

5.3.3 Animation eines Avatar-Modells mit einer vorhandenen Animation105

5.3.4 Aufbereitung von MOCAP-Daten für die Avatar-Animation . . 107

5.3.5 Erzeugung parametrischer Laufanimationen . . . . . . . . . . . 109

5.3.6 Erzeugung von lippensynchroner (O�ine) Sprachanimation . . . 110

6 Aufbereitung und Kon�guration von Avataren 113

6.1 Programme und Datenformate zur Kon�guration von Avataren für dasLaufzeitsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113

6.2 Konvertierung von Daten aus dem FBX Format . . . . . . . . . . . . . 114

6.3 Erzeugung von animierbaren Kleidungsstücken aus statischen Modellen 115

6.4 Speicherung der Avatar-Kon�guration . . . . . . . . . . . . . . . . . . . 118

6.5 Gra�sche Kon�guration von Avataren . . . . . . . . . . . . . . . . . . . 118

6.5.1 Kon�guration des Aussehens von Avataren . . . . . . . . . . . . 120

6.5.2 Visuelle Kontrolle und Korrektur von Avataren . . . . . . . . . . 121

7 Steuerung von Avataren 123

7.1 Das C++ API zur Steuerung von Avataren . . . . . . . . . . . . . . . . 123

7.2 Realisierung des Skriptings zur Steuerung von Avataren . . . . . . . . . 125

7.2.1 Eigenschaften und Funktionsweise von Lua . . . . . . . . . . . . 126

7.2.2 Aufbau des Skripting-Knotens . . . . . . . . . . . . . . . . . . . 126

7.2.3 Bindung des OpenSceneGraph API an Lua . . . . . . . . . . . . 127

7.3 Konzepte zur Steuerung von Avataren mit Skript-Knoten . . . . . . . . 129

7.3.1 Speichern von zusätzlichen Eigenschaften zu einem Objekt . . . 129

7.3.2 Erweiterung von bestehenden Klassen um neue Methoden . . . 130

7.3.3 Warteschlangen für Animationen . . . . . . . . . . . . . . . . . 131

7.3.4 Lineare Steuerung von Avataren . . . . . . . . . . . . . . . . . . 133

8 Gesichtsanimation und Sprachausgabe 137

8.1 Integration von Morph-Sequenzen in Cal3D . . . . . . . . . . . . . . . 138

8.1.1 Entwicklung einer Datenstruktur für Morph-Sequenzen . . . . . 138

8.1.2 Abspielen von Morph-Sequenzen . . . . . . . . . . . . . . . . . . 139

8.2 Audioausgabe der Sprachdaten . . . . . . . . . . . . . . . . . . . . . . 139

8.3 Erzeugung von Sprachanimationen mit externen Programmen . . . . . 140

8.4 Erzeugung von Sprachanimationen mit einemSprachsynthese-System . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8.4.1 XML Steuerelemente zur Beein�ussung der Sprachanimation . . 142

INHALTSVERZEICHNIS v

8.4.2 Erzeugen der hörbaren Sprachausgabe . . . . . . . . . . . . . . 144

8.4.3 Generierung der Sprachanimation . . . . . . . . . . . . . . . . . 145

8.4.4 Synchronisation von Mimik und Gestik . . . . . . . . . . . . . . 146

9 Echtzeit Darstellung von Avataren 149

9.1 Darstellung von Avataren in OpenSceneGraph . . . . . . . . . . . . . . 149

9.1.1 Datenstrukturen und Funktionsweise von Cal3D . . . . . . . . . 149

9.1.2 Datenstrukturen und Funktionsweise von OpenSceneGraph . . . 151

9.1.3 Integration von Avataren in den Szenengraphen . . . . . . . . . 151

9.2 Darstellung von Avataren in der CasCave . . . . . . . . . . . . . . . . . 154

9.2.1 Das SYZYGY Master-Slave Rahmenwerk . . . . . . . . . . . . . 155

9.2.2 Darstellung einer Szene mit OpenSceneGraph . . . . . . . . . . 156

9.2.3 Synchronisierung der OpenSceneGraph Anwendungen . . . . . . 158

9.2.4 Implementierung . . . . . . . . . . . . . . . . . . . . . . . . . . 159

10 Anwendungen des Avatar-Systems 161

10.1 Entwicklung eines Tutorials für das Projekt�GaFab� . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

10.1.1 Projektziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

10.1.2 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161

10.1.3 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162

10.1.4 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

10.2 Visualisierung von Simulationsergebnissen . . . . . . . . . . . . . . . . 164

10.2.1 Projektziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

10.2.2 Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

10.2.3 Realisierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165

10.2.4 Ergebnis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166

11 Zusammenfassung und Ausblick 169

11.1 Zusammenfassung der Ergebnisse . . . . . . . . . . . . . . . . . . . . . 169

11.2 Ausblick . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170

A Glossar und Abkürzungsverzeichnis 173

Literaturverzeichnis 179

vi INHALTSVERZEICHNIS

Abbildungsverzeichnis

1.1 Szene aus dem RMS Projekt [222] . . . . . . . . . . . . . . . . . . . . . 2

2.1 Avatare in virtuellen Umgebungen . . . . . . . . . . . . . . . . . . . . . 10

2.2 Avatare in Trainingssimulationen . . . . . . . . . . . . . . . . . . . . . 12

2.3 Avatare in Spielen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4 Avatare zur Präsentation von Informationen . . . . . . . . . . . . . . . 14

2.5 Tutoren in virtuellen Lehrumgebungen . . . . . . . . . . . . . . . . . . 15

2.6 Avatare in Ergonomieuntersuchungen . . . . . . . . . . . . . . . . . . . 16

2.7 Beispiel für eine Modellierung per �Box-Modelling� und Unterteilungs-�ächen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.8 PhantomOmni mit ClayTools der Firma Sensable [72] . . . . . . . . . . 19

2.9 3D Scanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.10 Beein�ussung des Aussehens durch Texturen . . . . . . . . . . . . . . . 22

2.11 Texturen für Haare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.12 EFFD für die Gesichtsanimation [206] . . . . . . . . . . . . . . . . . . . 24

2.13 Typische Defekte des SSD Algorithmus (kollabierender Ellenbogen) . . 25

2.14 MPEG 4 Gesichts-Parameter [185] . . . . . . . . . . . . . . . . . . . . . 27

2.15 Motion Capture Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.16 Performance Capture: Tom Hanks als Scha�ner im Film �Der Polar-express� (Warner Bros. Pictures) (links). Auf der rechten Seite ist diegerenderte Szene zu sehen. . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.17 Beispiele parametrischer Animationen [153] . . . . . . . . . . . . . . . . 31

2.18 Modellierungs- und Animationsprogramme . . . . . . . . . . . . . . . . 34

2.19 Spezialisierte Avatar Modellierungsprogramme . . . . . . . . . . . . . . 36

2.20 Spezialisierte Avatar Animationsprogramme . . . . . . . . . . . . . . . 37

2.21 Editoren von Echtzeit Avatar-Systemen . . . . . . . . . . . . . . . . . . 43

3.1 Modell mit unterschiedlichen Texturen . . . . . . . . . . . . . . . . . . 55

3.2 Kombination von Basisbewegungen . . . . . . . . . . . . . . . . . . . . 57

vii

viii ABBILDUNGSVERZEICHNIS

3.3 Vergleich der Geschwindigkeit von Python und Lua (Zusammenfassungder Ergebnisse von [46, 47]) . . . . . . . . . . . . . . . . . . . . . . . . 64

3.4 Beispiel für einen Szenengraphen . . . . . . . . . . . . . . . . . . . . . 65

3.5 Bearbeitungsstufen in einem Szenengraphen . . . . . . . . . . . . . . . 65

3.6 Die CasCave im Fachgebiet Technische Informatik, mit SpaceMouse(rechts, oben), sowie Shutter-Brille mit Positionssensor (rechts, unten) . 67

3.7 Teilbereiche des Avatar-Systems . . . . . . . . . . . . . . . . . . . . . . 69

3.8 Komponenten des Avatar-Systems . . . . . . . . . . . . . . . . . . . . . 71

3.9 Externe Komponenten des Avatar-Systems . . . . . . . . . . . . . . . . 72

3.10 Externe Komponenten des Skript-Knotens . . . . . . . . . . . . . . . . 72

3.11 Externe Komponenten der CasCave Darstellung . . . . . . . . . . . . . 73

4.1 Skelettstrukturen für Avatar-Modelle . . . . . . . . . . . . . . . . . . . 76

4.2 Standard-Pose für Avatare . . . . . . . . . . . . . . . . . . . . . . . . . 78

4.3 Programme und Datenformate für die Avatar-Modellierung und Animation 79

4.4 Verwendete Symbole für Arbeitsabläufe . . . . . . . . . . . . . . . . . . 80

4.5 Erstellung von animierbaren Avatar-Modellen . . . . . . . . . . . . . . 82

4.6 Modellierung mit Poser . . . . . . . . . . . . . . . . . . . . . . . . . . . 83

4.7 Erstellung von Morph-Zielen mit Poser . . . . . . . . . . . . . . . . . . 85

4.8 Viseme für deutsche Sprachanimation . . . . . . . . . . . . . . . . . . . 86

4.9 Konvertierung von Poser Daten in das FBX Format . . . . . . . . . . . 87

4.10 Aufbereitung eines Poser Modells . . . . . . . . . . . . . . . . . . . . . 88

4.11 Korrektur der Handstellung in 3D Studio Max . . . . . . . . . . . . . . 89

4.12 Extrahieren der Skinning-Informationen . . . . . . . . . . . . . . . . . 90

4.13 Übertragung der Skinning-Informationen . . . . . . . . . . . . . . . . . 90

4.14 Korrektur eines Modells . . . . . . . . . . . . . . . . . . . . . . . . . . 91

4.15 Beispiel für fehlerhafte Normalen-Vektoren (links). Rechts ist die kor-rekte Darstellung zu sehen. . . . . . . . . . . . . . . . . . . . . . . . . . 92

4.16 Vorbereiten eines Modells für die Animation . . . . . . . . . . . . . . . 93

4.17 Export eines Modells in das FBX-Format . . . . . . . . . . . . . . . . . 94

4.18 Export eines Avatar-Modells aus 3D Studio Max . . . . . . . . . . . . . 95

5.1 Programme und Datenformate für die Avatar-Modellierung und Animation 99

5.2 O�ine-Animation von Avatar-Modellen . . . . . . . . . . . . . . . . . . 100

5.3 Vorbereitung des Avatar-Modells für die Animation . . . . . . . . . . . 101

5.4 Charakterisierung des Avatar-Modells . . . . . . . . . . . . . . . . . . . 103

5.5 Animation eines Avatar-Modells mit einer vorhandenen Animation . . . 105

ABBILDUNGSVERZEICHNIS ix

5.6 Optionen zur Umwandlung einer Körperanimation in Key-Frames . . . 106

5.7 Aufbereitung von MOCAP-Daten für die Avatar-Animation . . . . . . 107

5.8 Einstellungen zur Batch-Konvertierung von Animationen . . . . . . . . 108

5.9 Erzeugung parametrischer Laufanimationen . . . . . . . . . . . . . . . 109

5.10 Erzeugung von lippensynchroner Sprachanimation . . . . . . . . . . . . 110

5.11 Optionen zur Umwandlung einer Gesichtsanimation in Key-Frames . . 111

6.1 Programme und Datenformate für die Avatar-Modellierung und Animation114

6.2 Benutzerober�äche des FBX Konverters . . . . . . . . . . . . . . . . . 115

6.3 Benutzerober�äche der �Retarget� Anwendung . . . . . . . . . . . . . . 116

6.4 Ergebnisse eines Retarget-Durchgangs . . . . . . . . . . . . . . . . . . . 116

6.5 Retarget bei Modellen mit gröÿeren Abweichungen in der Geometrie . . 117

6.6 Beispiel für eine Avatar-Kon�guration im XML-Format . . . . . . . . . 119

6.7 Klassendiagramm für die Kon�guration von Avataren . . . . . . . . . . 119

6.8 Dialog zur Kon�guration von Avataren . . . . . . . . . . . . . . . . . . 121

6.9 Änderung von Cal3D Geometrie- und Materialdaten . . . . . . . . . . . 121

6.10 Korrektur von Gröÿe und Ausrichtung . . . . . . . . . . . . . . . . . . 122

7.1 Klassendiagramm für Avatare . . . . . . . . . . . . . . . . . . . . . . . 125

7.2 Klassendiagramm für Skripting . . . . . . . . . . . . . . . . . . . . . . 126

7.3 In Lua verfügbare OpenSceneGraph-Klassen . . . . . . . . . . . . . . . 128

7.4 Animation mit einem Skript-Knoten . . . . . . . . . . . . . . . . . . . 128

7.5 Kontrolle von 100 Avataren durch kooperative Threads . . . . . . . . . 136

8.1 Beispiel für eine Morph-Sequenz im XML-Format . . . . . . . . . . . . 138

8.2 Klassendiagramm für Morph-Sequenzen . . . . . . . . . . . . . . . . . . 139

8.3 Programme und Datenformate für die Sprachanimation mit externenProgrammen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140

8.4 O�ine-Sprachanimation . . . . . . . . . . . . . . . . . . . . . . . . . . 141

8.5 Module zur Online-Sprachanimation . . . . . . . . . . . . . . . . . . . 142

8.6 Phonemliste des Wortes �Willkommen� . . . . . . . . . . . . . . . . . . 144

8.7 Phasen des implementierten Koartikulationsmodells . . . . . . . . . . . 146

8.8 Online-Sprachausgabe . . . . . . . . . . . . . . . . . . . . . . . . . . . 146

8.9 Phoneme mit eingebetteten XML-Elementen . . . . . . . . . . . . . . . 147

9.1 Cal3D Klassendiagramm . . . . . . . . . . . . . . . . . . . . . . . . . . 150

9.2 Cal3D Render-Pipeline . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

x ABBILDUNGSVERZEICHNIS

9.3 Klassendiagramm des Subsystems für die Darstellung von Avataren . . 152

9.4 Jessi ohne und mit Transparenz . . . . . . . . . . . . . . . . . . . . . . 153

9.5 Bump-Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154

9.6 James ohne und mit Bump-Map . . . . . . . . . . . . . . . . . . . . . . 155

9.7 Das SYZYGY Master-Slave Rahmenwerk . . . . . . . . . . . . . . . . . 156

9.8 Klassendiagramm des CasCave Darstellung . . . . . . . . . . . . . . . . 159

9.9 Avatar in der CasCave . . . . . . . . . . . . . . . . . . . . . . . . . . . 160

10.1 Beispiele aus dem Tutorial der Simulationsplattform �GaFab� . . . . . . 163

10.2 Beispielskript für eine Szenario-Animation . . . . . . . . . . . . . . . . 164

10.3 Beispiel für eine Trace-Datei . . . . . . . . . . . . . . . . . . . . . . . . 165

10.4 Klassendiagramm der Lua-Klassen für die Visualisierung . . . . . . . . 166

10.5 Visualisierung von Material�üssen mit dem Skript-Knoten . . . . . . . 168

Tabellenverzeichnis

2.1 Programme zur Modellierung und Animation von Avataren . . . . . . . 38

2.2 Datenformate für Avatare . . . . . . . . . . . . . . . . . . . . . . . . . 42

2.3 Echtzeit Avatar-Systeme . . . . . . . . . . . . . . . . . . . . . . . . . . 45

3.1 Beispiele für die Synchronisierung von Sprache und Gestik . . . . . . . 61

4.1 Anzahl der Gelenke (Bones) je Körperteil . . . . . . . . . . . . . . . . . 77

5.1 Zuordnung der MotionBuilder Phoneme zu deutschen Visemen . . . . . 102

7.1 Funktionen des Avatar-API . . . . . . . . . . . . . . . . . . . . . . . . 124

8.1 Phonem-Visem Zuordnung aus [119] . . . . . . . . . . . . . . . . . . . . 145

xi

Kapitel 1

Einleitung

Es ist jetzt über 40 Jahre her, dass die ersten gra�schen Menschenmodelle mit Com-putern erzeugt wurden. William Fetter, ein Mitarbeiter des Flugzeugherstellers Boing,suchte einen Weg, um ein möglichst ergonomisches Design für ein Cockpit zu erstellen[141]. Hierzu modellierte er ein einfaches Drahtgitter-Modell eines Menschen, mit demer Erreichbarkeitsstudien durchführen und die Ergebnisse auf einem Plotter ausgebenkonnte. Für diese Zeichnungen verwendete er erstmals den Begri� �Computergra�k�.

Durch die enorm gestiegene Leistungs- und Gra�kfähigkeit heutiger Computer begeg-nen uns computergenerierte Menschenmodelle in vielen Lebensbereichen. Viele Compu-terspiele wären ohne die Darstellung von Menschen undenkbar. Aber auch in Film undFernsehen, sowie in wissenschaftlichen Computersimulationen werden solche als �Avat-are� bezeichnete Modelle häu�g eingesetzt. Dabei hat die visuelle Darstellungsqualitäteinen so hohen Stand erreicht, dass Neal Stephensons Fiktion von einem �Metaverse�[205] - einem zukünftigen Internet, welches auf virtueller Realität basiert und in demsich Menschen tre�en können, die durch täuschend echte Avatare vertreten werden -bald Realität werden könnte.

Trotz der vielen Fortschritte und dem weit verbreiteten Einsatz sind Avatare aus Ent-wicklersicht immer noch Spezialanwendungen, die für eine bestimmte Anwendung ent-wickelt werden. Ein Grund hierfür dürfte sein, dass eine realitätsnahe Darstellung vonMenschen ein komplexes Unterfangen ist, weshalb bestimmte Bereiche je nach Anwen-dungsfall vereinfacht werden. Dies hat zu vielen Problemlösungen für unterschiedlicheAspekte des Einsatzes von Avataren geführt, die von der Modellierung über die Anima-tion bis zu biomechanisch korrekter Modellierung und autonomen Verhalten reichen.In dem Artikel �Creating Interactive Virtual Humans: Some Assembly Required� [148]wird daher zurecht festgestellt, dass erst durch eine Integrationsmöglichkeit der ver-schiedenen Lösungen die Erscha�ung von perfekten Avataren ermöglicht und beschleu-nigt wird.

Auch diese Arbeit entstand deshalb, weil Avatare für eine interaktive Simulationsumge-bung benötigt wurden, aber keine existierende Lösung in der Lage war, allen Anforde-rungen zu genügen. Da eine komplette Neuentwicklung aller benötigten Softwarekom-ponenten zu aufwändig gewesen wäre, wird in dieser Arbeit ein Konzept entwickelt,existierende Lösungen zu einem funktionsfähigen Gesamtsystem zu kombinieren.

Im folgenden wird der Kontext beschrieben, in dem die Avatare eingesetzt werden sol-len. Hierzu wird kurz auf die Forschungsbereiche des Fachgebiets �Technische Informa-

1

2 KAPITEL 1. EINLEITUNG

Abbildung 1.1: Szene aus dem RMS Projekt [222]

tik� eingegangen, an dem diese Arbeit entstanden ist. Es folgt dann die Beschreibungder Problemstellung und des Aufbaus der Arbeit.

1.1 Forschungsbereiche des Fachgebiets Technische In-formatik

Das Fachgebiet Technische Informatik an der Universität Kassel arbeitet auf dem Ge-biet der gra�schen Simulation und virtuellen Realität. Die Schwerpunkte liegen in derEntwicklung von Werkzeugen für die Erzeugung von Inhalten für Lehr- und Trai-ningssimulationen und der stereoskopischen Visualisierung. In Eigenregie wurde dieCasCave (Kasseler Cave automatic virtual environment), eine immersive Echtzeit-VR-Umgebung, entworfen und aufgebaut. Sie ermöglicht aktive Stereoprojektion und kannzur Visualisierung im Maÿstab 1:1 und als Interface für Trainingssimulationen einge-setzt werden.

In den vergangenen Jahren wurde im Fachgebiet das vom BMBF geförderte Projekt�RMS - Radfahren mit Multimedia Software� durchgeführt (siehe Abbildung 1.1). Zieldieses Projekts war die Entwicklung einer Multimedia Software, mit deren Hilfe Kinderdas richtige Verhalten im Straÿenverkehr lernen können. Es wurde eine möglichst de-tailgetreue Abbildung der simulierten Welt angestrebt, so dass man sich aufgrund derdamaligen Leistungsfähigkeit von Standard PCs für den Einsatz von vorgerendertenAnimationen entschied. Für verschiedene Verkehrssituationen existieren unterschiedli-che Animationssequenzen, die dynamisch, je nach Entscheidung des Anwenders, hin-tereinander gefügt werden.

Neben dem Vorteil der detailgetreuen Darstellung hat dieses System aber auch Nachtei-

KAPITEL 1. EINLEITUNG 3

le. Dadurch, dass die Simulation entlang eines Entscheidungsbaumes verläuft, kann einAnwender nur an bestimmten Kontrollpunkten den Ablauf der Simulation verändern.Ansonsten wird zwischen zwei Entscheidungspunkten immer die jeweils passende Ani-mation abgespielt. Des weiteren hat das System in Bezug auf die Erweiterungsmöglich-keiten Nachteile. Wird beispielsweise in einer Szene ein Gegenstand hinzugefügt, mussnicht nur die einzelne Szene neu gerendert werden, sondern auch alle nachfolgenden Sze-nen im Entscheidungsbaum. Mit zunehmender Komplexität des Entscheidungsbaumessteigt der Bedarf an animierten Zwischensequenzen. Es wird daher immer schwieriger,den Überblick über den Gesamtablauf zu behalten, wodurch auch die Wahrscheinlich-keit für logische Fehler steigt. Das System ist nur für Einzelplatzsysteme ausgelegt. Inder jetzigen Implementierung ist eine stereoskopische Darstellung in der CasCave nichtmöglich. Um dies zu ermöglichen, müssten die Inhalte neu umgesetzt werden.

1.2 ICS - Ein System zur Erstellung von interaktivenInhalten

Die Erfahrungen mit dem Projekt �RMS�, sowie der Wunsch, einmal erstellte Inhal-te auch mit unterschiedlichen Ausgabemedien darstellen zu können, führten zu derIdee, ein System zur Erstellung von interaktiven 3D Inhalten zu entwickeln. Hierbeisollen Lehrsimulationen im Vordergrund stehen. Es sollen aber auch andere Anwen-dungsbereiche - beispielsweise Visualisierungen in der �Digitalen Fabrik� - abgedecktwerden können. Das zu entwickelnde �Interactive Content System� (ICS) soll folgendeMöglichkeiten bieten:

Erweiterungsmöglichkeit um neue Technologien: Mit dem geplanten System sol-len neue Methoden des �Story Telling� und Konzepte der künstlichen Intelligenz(KI) erforscht und entwickelt werden. Vorrangiges Ziel ist, Autoren bei der Er-stellung von Inhalten bestmöglich zu unterstützen und so die Realisierung vonTrainingssimulationen zu erleichtern. Damit neue Technologien möglichst �exibelumgesetzt werden können, sollte das System idealerweise im Quelltext vorliegen.

Unterstützung von Avataren: Das System soll den Einsatz von Avataren ermögli-chen. Diese sollen sowohl zur Belebung der Simulation, als auch zur Interaktionmit dem Benutzer eingesetzt werden können. Benutzereingaben, sowie Skript-und KI-Technologien ermöglichen die Steuerung der Avatare. Zur Modellierungund Animation soll auf das breite Angebot vorhandener Anwendungen zugegrif-fen werden können. Da die Avatare auch als virtuelle Tutoren eingesetzt werdensollen, ist eine Sprachausgabe notwendig.

Darstellung auf verschiedenen Ausgabemedien: Die Darstellung der Inhalte sollohne Anpassungen sowohl auf Einzelplatzsystemen, als auch in der CasCave mög-lich sein.

Einsparung von Lizenzkosten: Es gibt bereits kommerzielle Anwendungen, bei-spielsweise Game-Engines, die für die Erstellung interaktiver Inhalte eingesetztwerden können. Bei dem produktiven Einsatz solcher Anwendungen fallen aberin der Regel hohe Lizenzkosten an. Auf der anderen Seite kann im Bereich For-schung und Lehre normalerweise nicht mit genügend hohen Einnahmen gerechnet


werden, so dass sich der Einsatz solcher Werkzeuge nicht �nanzieren würde. Esist daher vorteilhaft, wenn Lizenzkosten möglichst eingespart und vorhandene�nanzielle Mittel vorrangig in der Erzeugung von Inhalten investiert werden kön-nen.

Es wurde bewusst eine Neuentwicklung angestrebt, da keines der vorhandenen Syste-me allen Anforderungen gerecht wird. Quest 3D der Firma Act3D unterstützt zwarMultiprojektionsumgebungen, bietet aber nicht die gewünschte Flexibilität bei demEinsatz von Avataren. Es liegt auÿerdem nicht im Quelltext vor und lässt sich nurschwer erweitern. Kommerzielle Game-Engines wie die Unreal Game-Engine der FirmaEpic MegaGames haben zwar komfortable Skripting und Animationsmöglichkeiten,unterstützen aber nur einen einzelnen Bildschirm. Für beide Produkte gilt, dass Li-zenzkosten bei einem produktiven Einsatz anfallen. So betragen die Lizenzkosten derUnreal Game-Engine beispielsweise $300.000 [112].

Auch für die Realisierung der Avatare selbst war eine Neuentwicklung notwendig. Esgibt zwar bereits ein Avatar-System im Fachgebiet [206], welches die dreidimensionaleDarstellung, Animation und Sprachausgabe von Avataren erlaubt. Jedoch unterstütztdas System nur einen Avatar und ist von den Animationsmöglichkeiten eingeschränkt.Auÿerdem ist eine Änderung oder Neuerstellung von Avataren schwierig.

1.3 Problemstellung und Ziele der Arbeit

Ziel dieser Arbeit ist die Entwicklung eines Systems, mit dem in Echtzeit animierbareAvatare in das ICS integriert werden können. Dazu gehört nicht nur die Realisierung derEchtzeitanimation und der 3D Darstellung, sondern auch das Ermitteln von Möglichkei-ten zur Avatarmodellierung und -animation. Es muss daher die gesamte Arbeitskette,von der Modellierung des Avatars, über die interaktive Steuerung, bis zur Ausgabe,abgedeckt werden.

Innerhalb des ICS sollen die Avatare verschiedene Aufgaben übernehmen können. Siesollen sowohl als Stellvertreter realer Personen, als Statisten zur Belebung der Simulati-on und als interaktive Tutoren eingesetzt werden können. Die Steuerung der Bewegun-gen erfolgt daher entweder durch Benutzereingaben, durch das �Story Telling� Systemoder die KI. Für die Interaktion mit dem Benutzer und die Realisierung virtueller Tu-toren muss die Möglichkeit zur Gesichtsanimation und Sprachausgabe gegeben sein.Da das ICS zur Erstellung interaktiver, dreidimensionaler Inhalte eingesetzt werdensoll, müssen die Avatare ebenfalls in Echtzeit animiert und dargestellt werden können.

Die Darstellung und Animation der Avatare sollen möglichst glaubhaft erfolgen. Inder Regel erfordert dies umfangreiche Kenntnisse in der Modellierung und Animati-on. Damit auch Fachanwender mit Grundkenntnissen in der 3D Modellierung Inhal-te erstellen können, sollen so weit wie möglich bestehende Daten und Anwendungeneingesetzt werden können. Wegen des hohen Modellierungsaufwands sollen Avatareauÿerdem möglichst in verschiedenen Szenarien wiederverwendet werden können. DieAnpassung an ein Szenario soll beispielsweise durch Änderung der Kleidung realisiertwerden. Der Einsatz von vorhandenen Lösungen soll auch unter dem Aspekt erfolgen,den Entwicklungsaufwand für das System zu reduzieren.

KAPITEL 1. EINLEITUNG 5

Auÿerdem soll das System auch in der CasCave eingesetzt werden und so die Dar-stellung der Avatare in Lebensgröÿe ermöglichen. Hierdurch ergeben sich höhere An-forderungen an die Darstellungsqualität, da Anwender dem Avatar �Auge in Auge�gegenüberstehen. Es erfordert auÿerdem die Kopplung der Darstellungssoftware an einVR-System, so dass die Darstellung auf den drei Wänden der CasCave erfolgen kann.

1.4 Aufbau der Arbeit

Die folgenden Kapitel beschreiben die Realisierung des Avatar-Systems. Bevor mit derDarstellung des Realisierungskonzepts begonnen wird, wird in Kapitel 2 der Begri��Avatar� zunächst genauer de�niert und es werden typische Anwendungsgebiete aufge-zeigt. Da Avatare seit vielen Jahren Gegenstand der Forschung sind, erfolgt im weiterenVerlauf eine Übersicht der aktuellen Forschungen, mit einem besonderen Augenmerkauf in Echtzeit animierbaren Avataren. Das Kapitel schlieÿt mit einer Betrachtung ak-tueller Anwendungen zur Modellierung, Animation und Integration von Avataren inSimulationssysteme.

Abhängig von den Anforderungen an das Avatar-System wird in Kapitel 3 ein Konzeptzur Realisierung des Systems entwickelt. Dieses Konzept wird in den nachfolgendenKapiteln umgesetzt.

Die Umsetzung beginnt mit einer Darstellung von Arbeitsabläufen, mit deren Hilfevorhandene Anwendungen zur Modellierung (siehe Kapitel 4) und Animation (sieheKapitel 5) eingesetzt werden können. Durch den Einsatz vorhandener Anwendungenkann auf umfangreiche Werkzeuge zur Gestaltung und Animation zurückgegri�en wer-den.

Bevor die erzeugten Modelle und Animationen in der Simulationsanwendung verwendetwerden können, müssen sie in ein spezielles Laufzeit-Format umgewandelt werden. DieUmwandlung, sowie die Kon�guration von Avataren für das Laufzeit-System wird inKapitel 6 beschrieben.

Interaktive Animationen erfordern eine Steuerungsmöglichkeit der Avatare. Eine Mög-lichkeit zur Realisierung dieser Steuerung ist der Einsatz von Skripten, die die Aktionender Avatare festlegen. In Kapitel 7 werden daher verschiedene Möglichkeiten gezeigt,um Avatare mit Skripten beein�ussen zu können.

Gesichts- und lippensynchrone Sprachanimation erfordern spezielle Lösungsansätze,weshalb diese separat in Kapitel 8 beschrieben werden. Das Kapitel zeigt, wie sichGesichtsanimation mit vorhandenen Sprachdateien und zur Laufzeit mit einem Text-to-Speech System umsetzen lassen.

Kapitel 9 beschreibt die Darstellung der Avatare in interaktiven Anwendungen, sowiedie Kopplung des Avatar-Systems an die CasCave. Die Darstellung der Avatare wird mitHilfe eines portablen Systems zur Erstellung von Echtzeitgra�ken realisiert. Durch dieKopplung dieses Systems mit einem VR-System wird die Darstellung in der CasCaverealisiert.

Das entwickelte Avatar-System wurde bereits in einigen Anwendungen eingesetzt. DieseAnwendungen werden in Kapitel 10 vorgestellt.

In Kapitel 11 werden die Ergebnisse der Arbeit zusammengefasst und es wird einAusblick auf mögliche Weiterentwicklungen gegeben.


1.5 Sprachliche Konventionen

Ein groÿes Problem beim Schreiben eines deutschen Textes über ein Thema, bei demdie vorhandene Literatur zu einem überwiegenden Anteil in Englisch verfasst ist, ist dieVerwendung von englischen Fachausdrücken. So weit möglich wurde in dieser Arbeit derVersuch unternommen, passende deutsche Begri�e für englische Begri�e zu verwenden.In englischer Fachliteratur zur Computergra�k wird beispielsweise häu�g der Begri��Vertex� für einen Punkt im dreidimensionalen Raum verwendet, wobei mehrere dieser�Vertices� zu sogenannten �Faces� verbunden werden. In dieser Arbeit wird der Begri��Eckpunkt� für �Vertex� verwendet, wobei mehrere Eckpunkte zu Polygonen verbundenwerden können.

Manchmal ist eine passende Übersetzung jedoch schwierig. Im späteren Verlauf der Ar-beit wird der Begri� �Skinning� auftauchen. Dieser beschreibt die Bindung des sichtba-ren Modells an ein Skelett. Die wörtliche Übersetzung wäre jedoch �Häutung�, was nurnoch eine entfernte Ähnlichkeit mit der beabsichtigten Bedeutung hat. Daher wird insolchen Fällen der englische Begri� verwendet. Namen von Softwarekomponenten undKlassen werden üblicherweise ebenfalls in Englisch angegeben, weshalb auch hier keineÜbersetzung erfolgt. Auf eine gesonderte Markierung englischer Begri�e wird eben-falls verzichtet, um das Schriftbild nicht unnötig mit verschiedenen Formatierungen zuüberfrachten.

Kapitel 2

Stand der Technik

Die Entwicklung von Avataren ist eine disziplinübergreifende Aufgabe, in der Kennt-nisse aus Bereichen wie Computergra�k und Animation, Anthropologie, Biomechanik,künstlicher Intelligenz und Soziologie miteinander kombiniert werden. Trotz der enor-men Fortschritte, die in den letzten Jahrzehnten erzielt wurden, wird immer nochintensiv in diesem Bereich geforscht. Unter den Forschungen �nden sich sowohl gene-relle Ansätze, in denen komplette Avatare realisiert werden [184, 195, 158, 161, 82],als auch Ansätze, in denen nur Teilaspekte untersucht werden. Hierzu gehören bei-spielsweise korrekte Simulationen der menschlichen Hand [118] oder des menschlichenAtmungsapperates [225]. Die folgenden Abschnitte liefern einen Abriss aktueller An-wendungen und Forschungen im Bereich Avatare. Hierbei werden überwiegend nur inEchtzeit animier- und darstellbare Avatare betrachtet. Zunächst wird jedoch der Begri��Avatar� de�niert.

2.1 De�nition des Begri�s �Avatar�

Das Wort �Avatar� leitet sich von dem Begri� �Avatara� aus dem Sanskrit ab. Avata-ra (wörtl.: der Herabsteigende) bezeichnet im Hinduismus einen Gott, der die Gestalteines Menschen oder Tieres annimmt. In virtuellen Welten wird der Begri� gemein-hin für eine künstliche Person oder einen gra�schen Stellvertreter einer echten Personverwendet. Der Begri� legt hierbei nicht fest, wie die Darstellung des Avatars erfolgt.Bilder, die in Internetforen zur Identi�zierung der Benutzer eingesetzt werden, be-zeichnet man ebenso als Avatar, wie in Echtzeit gerenderte, dreidimensionale Modelle.Avatare müssen dabei nicht zwingend menschliche Gestalt haben.

Je nach Einsatzzweck und Funktion wird in der Literatur der Begri� Avatar weiterspezi�ziert. Dabei wird im allgemeinen nach dem Grad der Autonomie des Avatarsunterschieden. Als Avatar wird meist ein Modell bezeichnet, welches einen Menschenin einer virtuellen Welt repräsentiert und welches der direkten Kontrolle des Nutzersunterliegt. Wird das Modell von einem Computer kontrolliert, spricht man hingegen voneinem Akteur (Actor). Folgende Begri�e werden in der Literatur im Zusammenhangmit Avataren ebenfalls verwendet:

Digital Human / Virtual Human: Die Begri�e �Digital Human� und �Virtual Hu-man� werden oft synonym verwendet. �Digital/Virtual Human� steht dabei als

7

8 KAPITEL 2. STAND DER TECHNIK

Oberbegri� für alle Arten von im Computer simulierten oder dargestellten Men-schenmodellen, seien es nun Menschenmodelle in Computerspielen, Filmen, usw.[171]. Je nach Autor wird der Begri� aber auch weiter spezi�ziert. Badler [120]de�niert mit dem Begri� �Virtual Humans� Computermodelle von Menschen,die während der Design-Phase als Stellvertreter für den realen Menschen in er-gonomischen Untersuchungen von Autos und Arbeitsplätzen eingesetzt werdenkönnen. Ein weiteres Einsatzgebiet ist aber auch die Verwendung als echzeita-nimierte Repräsentation von Menschen in virtuellen Umgebungen. Rickel [196]beschreibt �Virtual Humans� als autonome Agenten, die in virtuellen Umgebun-gen eine Interaktion mit dem Anwender von Angesicht zu Angesicht ermöglichenund eine Vielzahl von verschiedenen Rollen übernehmen können.

Digital Manikin: Hierunter werden dreidimensionale Modelle von Menschen verstan-den, die innerhalb von CAD Systemen während des Designs dazu verwendetwerden, die ergonomische Eignung einer Planung zu untersuchen [39]. Dazu ge-hören die Abschätzung von Produktdimensionen, Erreichbarkeits- und Sichtbar-keitstests, sowie Belastungsuntersuchungen. Je nach Anwendungsgebiet kann dasModell auf Basis statistischer Datenbanken in Bezug auf Geschlecht, Gröÿe undAlter kon�guriert werden. Anwendungsgebiete sind beispielsweise Automobil-,Luftfahrt-, Fabrik- und Gebäudedesign.

Digital Actor / Synthetic Actor: Magnenant-Thalmann und Thalmann verstehenunter einem �Digital Actor� einen menschenähnlichen, autonomen Akteur, derkomplett im Computer generiert wird [208]. Sie folgen daher der allgemeinenAu�assung in der Computergra�k, dass ein Akteur autonomes Verhalten hat.Im Gegensatz dazu wird in [160] die ursprüngliche Bedeutung des Schauspielershervorgehoben. Hier wird unter einem �Digital Actor� ein virtueller Schauspielerverstanden, der so real dargestellt werden kann, dass ein Betrachter ihn nichtvon einem echten menschlichen Schauspieler zu unterscheiden vermag. Der Fokusliegt auf der Darstellung. Es wird daher nicht vorausgesetzt, dass der Akteur überkünstliche Intelligenz verfügt oder autonom lebensechte Animationen erzeugenkann. Der Akteur muss auch nicht in Echtzeit dargestellt werden können.

Animated Pedagogical Agents: Nach Johnson et al. [168] sind animierte, pädago-gische Agenten animierbare Modelle, die das Lernen innerhalb von computerba-sierten Lehrumgebungen unterstützen. Die Agenten können auf Benutzereinga-ben reagieren und haben ausreichendes Verständnis des Lehrkontexts, so dass siesinnvolle Aufgaben in Lehrszenarien übernehmen können.

Virtual Interface Agent: Nach Mase [174] ist ein �Interface Agent� ein autonomerAgent, der zwischen Anwender und dem Computer Cyberspace vermittelt. Jenach Beziehung zum Anwender und der Kontrolle, die der Anwender ausübenkann, werden drei verschiedene Kategorien unterschieden: Ein Avatar ist eine vi-suelle Repräsentation des Anwenders in einer virtuellen Welt. Ein Assistent kanndem Anwender in der virtuellen Welt helfen, beispielsweise Fragen beantworten.Ein Akteur schlieÿlich stellt andere (computergesteuerte) Menschen in der Um-gebung dar, auf die der Anwender aber keinen Ein�uss hat.

Embodied Conversational Agent: Unter Konversationsagenten versteht Cassell [132]Schnittstellen Agenten, die menschliche Verhaltensweisen bei der Kommunikati-

KAPITEL 2. STAND DER TECHNIK 9

on mit dem Benutzer aufzeigen können. Hierzu gehört, dass sie verbale und non-verbale Eingaben erkennen und angemessen darauf reagieren können. Weiterhinmüssen sie mit Dialogfunktionen wie Feedback sowie Reparaturmechanismen um-gehen können. Sie haben auÿerdem die Fähigkeit, den Zustand der Konversationzu signalisieren.

Auch wenn der Bergi� Avatar - wie angedeutet - ungenau ist, wird er in dieser Arbeitfür echtzeitanimierbare Menschenmodelle verwendet. Da das zu entwickelnde Systemnur für die Darstellung verantwortlich ist, können diese Avatare im eigentlichen Sinn- als Stellvertreter des Nutzers - oder aber auch vom Computer gesteuert als Akteureingesetzt werden.

So unterschiedlich wie die Begri�e sind auch die Einsatzbereiche von Avataren. Imfolgenden sollen einige der Einsatzbereiche dargestellt werden. Zur Eingrenzung wer-den dabei bevorzugt Anwendungen vorgestellt, in denen dreidimensionale Modelle vonMenschen verwendet werden, welche in Echtzeit animiert und in virtuellen Umgebun-gen dargestellt werden können.

2.2 Anwendungsbereiche von Avataren

Avatare sind in vielen Anwendungsbereichen anzutre�en [120]. Hierzu gehören:

• Virtuelle Konferenzen und Umgebungen

• Trainingssimulationen

• Spiele und Unterhaltung

• Präsentation von Informationen

• Tutoren in virtuellen Lehrumgebungen

• Unterstützung bei Ergonomieuntersuchungen, z.B. im Bereich Design, Konstruk-tion und Wartung

In den folgenden Abschnitten werden einige Beispielanwendungen aus den obigen An-wendungsbereichen aufgeführt.

2.2.1 Virtuelle Konferenzen und Umgebungen

�Networked Virtual Environments� (NVE) ermöglichen die Kommunikation und Zu-sammenarbeit von Teilnehmern, die sich an geogra�sch verschiedenen Orten aufhalten.Die Darstellung der Teilnehmer durch Avatare erfüllt dabei verschiedene Funktionen.Nach Pandzic et al. [187] gehören dazu die Wahrnehmung, Lokalisierung und Identi�-zierung der anderen Teilnehmer, Visualisierung des Interesses und von Aktionen, sowiedie Erweiterung der Kommunikationsmöglichkeiten durch Gesten.


(a) Blaxxun Contact [8] (b) Avatar Conference [27]

(c) Workspace 3D der Firma Tixeo [77] (d) Max [161]

Abbildung 2.1: Avatare in virtuellen Umgebungen


Es gibt bereits mehrere Umsetzungen solcher NVEs. In der Studie �CyberTennis� [158]wurde ein virtuelles Tennisspiel realisiert. Dabei konnten zwei Menschen an verschie-denen Orten miteinander Tennis spielen. Jeder Spieler befand sich in einer virtuellenUmgebung, die per �Head mounted display� dargestellt wurde. Der jeweilige Gegnerwurde innerhalb dieser Umgebung als Avatar dargestellt. Per Tracking-System erfolg-te die Erfassung der Bewegungen der menschlichen Spieler, die dann auf die Avatareübertragen wurden.

Die Firma Blaxxun bietet mit der Software �Blaxxun Contact� [8] (siehe Abbildung2.1 (a)) die Möglichkeit, virtuelle Welten aufzubauen, in denen sich Anwender tre�enund unterhalten können. Über ein Plugin können diese Welten im Internet-Browser desAnwenders dargestellt werden. Jeder Nutzer wird in dieser Welt durch einen Avatarrepräsentiert. Der eigene Avatar kann durch die Welt gesteuert werden. Über Tastaturund eine begrenzte Auswahl an Gesten kann Kontakt zu anderen Avataren aufgenom-men werden. Schon 1998 wurde eine ähnliche Software bei der �Avatar98�, der erstenvirtuellen Konferenz des �Contact Consortium�, eingesetzt [142]. Dabei sollen 4.000Teilnehmer an der Konferenz teilgenommen haben.

Das von der EU geförderte Projekt �Avatar-Conference� [27] (siehe Abbildung 2.1 (b))hatte zum Ziel, eine Sammlung von Werkzeugen zur Kon�guration und zum Mana-gement von skalierbaren Konferenzsystemen zu entwickeln. Die Teilnehmer einer vir-tuellen Online-Konferenz werden als Avatare dargestellt und haben die Möglichkeit,untereinander Dokumente zu präsentieren und auszutauschen. Durch den Einsatz vonvirtuellen Darstellungstechniken verspricht man sich die Einsparung von Übertragungs-bandbreite. Auÿerdem geht man von einem spontanerenWissensaustausch aus, da nichterst langwierig Termine vereinbart und Tagungsräume gebucht werden müssen. Oben-drein könnten Reisekosten eingespart werden.

Die Firma Tixeo bietet mit den beiden Produkten �Meeting3D� und �WorkSpace3D�(siehe Abbildung 2.1 (c)) zwei kommerzielle Lösungen für Avatar-gestützte Web Kon-ferenzen [77]. Auch hier werden die Teilnehmer als Avatare dargestellt und können ineiner virtuellen Umgebung Daten austauschen und gemeinsam an Dokumenten arbei-ten.

Avatare werden aber nicht nur zur Darstellung anderer Teilnehmer verwendet, sondernauch als Assistenten. Bei �Max� [161] (siehe Abbildung 2.1 (d)), einer Entwicklung desKI Labors der Universität Bielefeld, handelt es sich um einen multimodalen Assistenten,der Anwender durch interaktive Konstruktionsprozesse führt. Mit Hilfe von Sprache,Gesichtsanimation und Gestik kann der Avatar bestimmte Arbeitsschritte erläuternund Anwender während eines Konstruktionsprozesses unterstützen.

2.2.2 Trainingssimulationen

Trainingssimulationen üben auf Industrie und Militär einen besonderen Reiz aus, dasie ein Training von komplexen Situationen ermöglichen, welches in der realen Weltzu gefährlich, zu teuer oder aber ohne weiteres nicht nachzustellen wäre. In [177] wer-den weitere Vor- und Nachteile diskutiert. Demnach gehört zu den Vorteilen, dass be-stimmte Situationen zielgerichtet und mit unterschiedlichen Schwierigkeitsstufen trai-niert werden können. Da jede Trainingssituation exakt reproduziert werden kann, er-möglichen Simulationen ein wiederholtes Einüben. Auÿerdem können Benutzeraktionen


(a) Militärische Trainingssimulation [170] (b) Trainingssimulation mit Quest3D [1]

Abbildung 2.2: Avatare in Trainingssimulationen

aufgezeichnet und zur Re�exion des Trainings verwendet werden. Demgegenüber ste-hen Nachteile wie unzureichender Realismus, zusätzliches Erlernen der Bedienung derSimulation und negative Ein�üsse wie �Cybersickness� oder Verletzungen, beispielswei-se durch die Überbeanspruchung des Nackens durch �Head mounted displays�. Hinzukommt, dass durch Trainingssimulationen auch die Gefahr besteht, falsches Verhalteneinzuüben, wenn in der Simulation von der Realität abweichende Regeln herrschen.

In Trainingssimulationen werden Avatare sowohl als Stellvertreter von realen Menschen,als auch als computergesteuerte Akteure eingesetzt. Es existieren einige kommerzielleSysteme, mit denen Avatare in Trainingssimulationen integriert oder komplette Si-mulationen umgesetzt werden können. Hierzu gehört das DI-Guy [12] System (sieheAbbildung 2.2 (a)) der Firma Boston Dynamics, mit dem sich Avatare in EchtzeitSimulationen integrieren lassen. Bestandteile von DI-Guy ist eine Sammlung von Men-schenmodellen, die auf eine umfangreiche Verhaltensbibliothek zurückgreifen können.Hinzu kommt ein API, welches die Kontrolle der Avatare ermöglicht. Quest3D [1] (sieheAbbildung 2.2 (b)) der Firma Act3D ist ein komplettes Paket, welches die Umsetzungvon Trainingssimulationen ermöglicht. Es unterscheidet sich von anderen Paketen da-durch, dass Inhalte ohne Programmierkenntnisse erstellt werden können.

2.2.3 Spiele und Unterhaltung

Avatare sind in Spielen weit verbreitet. Meist wird der Spieler selbst als Avatar in demSpiel angezeigt und kontrolliert diesen direkt über Eingabegeräte wie Tastatur, Game-pad oder Joystick. Eine Ausnahme in der Darstellung bilden �First Person Shooter�,bei denen der Anwender die Szene aus der �Ich Perspektive� sieht. Weitere Avatare inSpielen werden entweder vom Computer kontrolliert (�Non player characters� (NPC))oder von anderen Mitspielern gesteuert.

Das Spiel �Die Sims� [25] (siehe Abbildung 2.3 (a)) ist ein Beispiel, in dem viele Avataredurch den Computer kontrolliert werden. Der Spieler hat meist nur indirekten Ein�uss,indem er das äuÿere Umfeld ändern kann. Bei online Rollenspielen (�Massively Mul-tiplayer Online Role-Playing Games� (MMORG)) wie �World of Warcraft� [10] (sieheAbbildung 2.3 (b)) spielen dagegen mehrere hundert Mitspieler durch Avatare vertretengleichzeitig in einer virtuellen Welt.


(a) Die Sims 2 [25] (b) World of Warcraft [10]

(c) Tomb Raider Legend [24] (d) FIFA WM 2006 [26]

Abbildung 2.3: Avatare in Spielen


(a) Charamel [16] Avatare im "Virtual Hu-man"Projekt des DFKI

(b) Avatar für Gebärdensprache [213]

Abbildung 2.4: Avatare zur Präsentation von Informationen

Durch die immer weiter steigende Leistungsfähigkeit von Consumer-PCs und 3D Gra-�kkarten werden die in den Spielen eingesetzten Avatare immer detaillierter dargestellt.Bestand die Haupt�gur �Lara� aus der �Tomb Raider� Reihe [24] zu Beginn nur aus 250Polygonen, wurden 2003 schon ca. 5.000 und bei dem aktuellen Titel �Legend� ca. 9.800Polygone verwendet (siehe Abbildung 2.3 (c)) [114]. Umfangreiche Bewegungsbiblio-theken werden dabei ebenso eingesetzt wie Gesichtsanimation. Auch Sportsimulationenwie die FIFA Reihe von Electronic Arts [26] (siehe Abbildung 2.3 (d)) sind mittler-weile so fortgeschritten, dass die realen Vorbilder der Spieler-Avatare ohne Problemewiedererkannt werden können.

2.2.4 Präsentation von Informationen

Avatare können zur Präsentation von Informationen eingesetzt werden. Hierbei ersetzensie einen menschlichen Redner. Entwicklungen in diesem Bereich sind Systeme wieder �Talking Avatar� [206] und �Presentation Jack� [183]. Mit dem �Talking Avatar�-System können dreidimensionale Kinder-Modelle dargestellt werden, welche sprechenund gestikulieren können. Die Animation der Kinder-Avatare wird durch ein Skriptgesteuert. Dieses Skript enthält Anweisungen für den zu sprechenden Text, einen Codefür die Gesichtsausdrücke und für die auszuführenden Körperbewegungen.

Mit �BEAT� [133] existiert ein System, das auf die Wiedergabe von gesprochenem Textspezialisiert ist. Abhängig vom Inhalt des Textes erzeugt dieses System eine passendeBetonung der Sprachausgabe, sowie Ab�aufpläne für Mimik und Gestik. Diese könnendann durch ein Animationssystem visualisiert werden. Das System erleichtert daherdie Animation von Avataren.

Neben der Präsentation von Informationen ermöglicht �Cyberella� [197] zusätzlich aucheine Interaktion mit dem Anwender. Das Programm ist als virtuelle Empfangsdame aneiner Rezeption konzipiert und kann Besuchern Hilfestellungen beim Au�nden vonRäumen oder Personen in einem Gebäude liefern. Der Avatar hat emotionale Fähig-keiten und kann so, je nachdem wie ein Besucher mit dem System kommuniziert, un-terschiedliches Verhalten zeigen.

Die Firma Charamel [16] bietet kommerziell Avatare für Produktvorstellungen und Fir-menpräsentationen an. Diese können sowohl als �Web-Guide�, als auch innerhalb eines


(a) Steve [195] (b) Cosmo [166]

Abbildung 2.5: Tutoren in virtuellen Lehrumgebungen

�Living Kiosk� eingesetzt werden. Als �Web-Guide� sollen die Avatare Vertrauen för-dern und Berührungsängste mindern und somit der Kundenbindung zugute kommen.Ein �Living Kiosk� ist ein multimedialer Informationsstand, der direkt in Kaufhäu-sern verwendet werden kann (siehe Abbildung 2.4 (a)). Zielsetzungen sind auch hierAkzeptanzsteigerung, bessere Kundenerreichung und Kundenbindung.

Hinzu kommen noch Avatare, die in der Lage sind, die Gebärdensprache für Gehörlo-se wiederzugeben. Mit dem ViSiCast Projekt [213] wurde ein Avatar entwickelt, derin Web-Anwendungen eingebunden werden kann und Texte in der Gebärdensprachewiedergibt (siehe Abbildung 2.4 (b)).

2.2.5 Tutoren in virtuellen Lehrumgebungen

Animierte, pädagogische Agenten sind Weiterentwicklungen von animierten Präsen-tatoren. In Kombination mit einem Intelligenten Tutoren System (ITS) unterstützensie Lernende innerhalb von Simulationsanwendungen aktiv, indem sie fortwährend dieAktionen und den Lernfortschritt der Anwender kontrollieren und bei Problemen Un-terstützung anbieten. Vertreter dieser Klasse von Avataren sind beispielsweise �Steve�[195] und �Cosmo� [166].

�Steve� (siehe Abbildung 2.5 (a)) kann bestimmte Abläufe demonstrieren und dabeijederzeit vom Anwender unterbrochen werden. Sollte der Anwender mit dem weite-ren Vorgehen Probleme haben, kann �Steve� Tipps geben, bzw. unvollendete Abläufefortsetzen. Alle Aktionen werden von �Steve� aufgezeichnet und können in einer Nach-besprechung automatisch erläutert und bewertet werden. Um dies zu erreichen, besitzt�Steve� die Fähigkeit, bereits errechnete Ablaufpläne mit den Handlungen des Anwen-ders in Einklang zu bringen und sich so an unvorhergesehene Aktionen anzupassen.

Bei �Cosmo� (siehe Abbildung 2.5 (b)) steht eine besonders glaubhafte Animationdes Avatars im Vordergrund. Dies wird dadurch erreicht, dass zur Animation aus einerumfangreichen Datenbank mit audiovisuellen Segmenten ausgewählt werden kann. DasErgebnis sind hochqualitative Animationen, denen aber eine arbeitsintensive Zusam-menstellung der Datenbanken gegenübersteht.


(a) CATIA Human Builder [15] (b) Santos [82]

Abbildung 2.6: Avatare in Ergonomieuntersuchungen

2.2.6 Ergonomieuntersuchungen

Computer basierte Menschenmodelle werden vielfach bei der Entwicklung von Fahr-zeuginnenräumen, Flugzeugcockpits, Fahrgasträumen und Arbeitsplätzen verwendet.Sie unterstützen Unternehmen verschiedener Branchen dabei, die Ergonomie von Pro-dukten und Abläufen an Arbeitsplätzen zu verbessern. Produkte wie �CATIA HumanBuilder� [15], �Ramsis� [38] und �UG Jack/Jill� [81] ermöglichen es dem Anwender,biomechanisch genaue, digitale menschliche Modelle verschiedener Gröÿen in virtuelleUmgebungen zu platzieren. Hierbei kann oft auf anthropometrische Daten verschiede-ner Weltregionen zurückgegri�en werden, um so digitale Abbilder der Kundengruppenzu generieren.

Mit den Modellen können verschiedene Analysefunktionen ausgeführt werden. Hierzugehört die Ermittlung des Platz- und Raumbedarfs, Erreichbarkeitshüllen, direkte undindirekte (Spiegel) Manikin-Sicht (siehe Abbildung 2.6 (a)) und die Simulation derhaltungsbedingten Maximalkraft. Mit den so gewonnenen Informationen können be-reits während des Designs Probleme in der Ergonomie erkannt und Entwicklungszeitenverkürzt werden.

�Santos� [82] (siehe Abbildung 2.6 (b)), der im Rahmen des �Virtual Soldier Research�Projekts an der Universität von Iowa entwickelt wird, soll darüber hinaus autonom undintelligent in virtuellen Welten agieren können. Der Avatar kann per Sprache gesteuertwerden und selbstständig die Bewegungsabläufe für bestimmte Aufgaben koordinieren.Dies soll die automatische Bewegungsanalyse in vielen Szenarien ermöglichen.

2.3 Modellierung von Avataren

Ausgangsbasis für den Einsatz eines Avatars ist immer ein geometrisches Modell, wel-ches den Avatar darstellt. Die Erzeugung eines solchen Modells von Grund auf ist sehraufwändig und erfordert künstlerisches Geschick. Aus diesem Grund wird in diesemBereich sehr intensiv geforscht, um die Modellierung zu vereinfachen.

In den folgenden Abschnitten werden Möglichkeiten zur Modellierung der Geometrieeines Avatars besprochen. Dazu werden zunächst Techniken zur Repräsentation, sowieanschlieÿend Methoden zur Erzeugung der Geometrie besprochen. Die Betrachtungen


beschränken sich hierbei auf die Erstellung der Geometrie und die Beein�ussung derDarstellung durch Texturen. Die Modellierung von dynamischen Haaren und dyna-mischer Kleidung wird nicht betrachtet, da die physikalisch korrekte Simulation vonHaaren und Kleidung zur Zeit immer noch zu rechenintensiv für die Echtzeitdarstel-lung ist [180]. Stattdessen wird gezeigt, wie sich Haare durch eine reduzierte Geometrieund mit geeigneten Texturen darstellen lassen.

2.3.1 Techniken zur Repräsentation der Geometrie

In der Vergangenheit wurden mehrere Technologien zur Repräsentation von geometri-schen Körpern - wie Polygon-, Parametrische-, Implizite- und Unterteilungs�ächen -entwickelt. Diese werden im folgenden kurz vorgestellt. Weiterführende Informationenkann man beispielsweise in [136] �nden.

Polygon�ächen

Bei polygonbasierten Techniken wird eine Menge von Eckpunkten zu Drei- oder Viere-cken (Polygonen) miteinander verbunden, aus denen dann die Ober�äche geformt wer-den kann. Abhängig von der Anzahl der Polygone können auch sehr komplexe Formenmodelliert, bzw. angenähert werden. Da aktuelle 3D Gra�kkarten solche Datenstruk-turen direkt verarbeiten können, ist diese Art der Darstellung sehr e�zient. Unter Um-ständen müssen jedoch sehr viele Polygone verwendet werden, um feine und gerundeteStrukturen nachzubilden. Hierdurch kann auch die Modellierung erschwert werden.

Parametrische Flächen (Parametric Surfaces)

Parametrische Flächen werden aus Spline-Kurven aufgebaut, wobei das Aussehen derKurven durch wenige Kontrollpunkte de�niert wird. Mehrere dieser Flächen werdenzu einem kompletten Modell zusammengefügt. Es gibt verschiedene Arten von para-metrischen Flächen. Meist sind in der Computergra�k jedoch NURBS (Non-UniformRational B-Splines) Flächen anzutre�en. Die Modellierung wird insofern vereinfacht,als nur wenige Kontrollpunkte editiert werden müssen, um glatte und gerundete Flä-chen zu erzeugen. Daher ist die Modellierung sehr intuitiv. Probleme können dannauftauchen, wenn mehrere Flächen zu einem durchgehenden Modell zusammengefasstwerden sollen und die Grenzen der Flächen nicht zusammenpassen. Auÿerdem könnenparametrische Flächen nicht direkt gerendert, sondern müssen erst diskretisiert werden- beispielsweise in eine Polygon�äche.

Unterteilungs�ächen (Subdivision Surfaces)

Bei einer Unterteilungs�äche wird ausgehend von einem grob vorgegebenen Kontroll-gitter per Iteration eine immer feinere Ober�äche erzeugt. Die Verfeinerung wird durcheine Unterteilung der Polygone aus dem vorherigen Iterationsschritt erreicht. Die dazuverwendeten Algorithmen ähneln denen zur Berechnung von Splines und können nach


approximierenden und interpolierenden Methoden unterschieden werden. Bei approxi-mierenden Methoden werden neue Stützpunkte hinzugefügt und bestehende verscho-ben. Interpolierende Methoden lassen dagegen die originalen Kontrollpunkte unange-tastet. Unterteilungs�ächen vereinen die Vorteile von Polygon�ächen und parametri-schen Flächen, indem sie eine zu Polygonen kompatible Repräsentation mit Eigenschaf-ten - wie wenige Kontrollpunkten und gerundete Flächen - kombinieren.

Implizite Flächen (Implicit Surfaces)

Implizite Flächen werden entsprechend der Formel {p ∈ R3 | f(p) = 0} de�niert, wo-bei mit der Funktion f eine implizite Ober�äche festgelegt wird. Implizite Flächenlassen sich verformen und miteinander verschmelzen. Wie auch die parametrischen Flä-chen müssen sie zuerst diskretisiert werden, bevor sie gerendert werden können. Dazukann der �Marching Cubes� Algorithmus verwendet werden. �Metaballs�, entwickelt vonBlinn [125], gehören zu der Gruppe der impliziten Flächen und werden beispielsweisefür die Modellierung von Muskeln eingesetzt.

2.3.2 Methoden zur Modellierung der Geometrie

Es gibt verschiedene Möglichkeiten, die Geometrie eines Avatars zu erstellen. NachMagnenant-Thalmann [172] können diese nach kreativen, rekonstruktiven und inter-polierenden Methoden unterschieden werden. Die folgenden Abschnitte geben einenÜberblick der verfügbaren Modellierungsmöglichkeiten.

Kreative Modellierung

Zu den kreativen Modellierungsmöglichkeiten gehören allgemeine Methoden wie �Box-Modelling� oder die Verwendung von �Spline-Cages�, die mit handelsüblichen Model-lierungsprogrammen wie 3D Studio Max oder Maya realisiert werden können. Ein de-tailliertes Beispiel für die Modellierung mit Spline-Cages �ndet sich beispielsweise in[206].

In Abbildung 2.7 kann man ein Beispiel für das übliche Vorgehen beim �Box-Modelling�sehen. Sowohl hier, als auch bei den meisten anderen Verfahren macht man es sich zuNutze, dass der menschliche Körper symmetrisch aufgebaut ist. Man modelliert daherzuerst eine Hälfte und setzt den gesamten Körper aus der ursprünglichen Hälfte undderen Spiegelung zusammen. Die Modellierung startet mit einem einfachen Quader.Aus diesem werden per Extrusion die Extremitäten heraus modelliert. Durch Verschie-bung der Eckpunkte wird die Kontur immer weiter angenähert, wobei die vorhandenenFlächen nötigenfalls feiner untergliedert werden können. Es erfolgt dann das Zusam-mensetzen der beiden Hälften. In der Regel wird anschlieÿend noch ein Glättungsope-rator (z.B. durch eine Unterteilungs�äche) angewendet, um der Geometrie eine feinereStruktur zu geben.

Ein anderer Ansatz wird bei der anatomischen Modellierung verfolgt [200, 219, 158,118]. Es wird dabei der Versuch unternommen, den realen Körper - zumindest in Tei-len - nachzuahmen. Die Modelle werden hierzu aus mehreren Schichten aufgebaut.


Abbildung 2.7: Beispiel für eine Modellierung per �Box-Modelling� und Unterteilungs-�ächen

Abbildung 2.8: PhantomOmni mit ClayTools der Firma Sensable [72]

Zunächst wird ein Skelett modelliert, das anschlieÿend um Muskel- und Fettgewebe er-gänzt wird. Thalmann et al. [158] verwenden beispielsweise �Metaballs�, um die Musku-latur zu modellieren. Dazu werden diese mit verschiedenen Eigenschaften (verschmelz-bar, nicht verschmelzbar, deformierbar, nicht deformierbar) an dem Skelett befestigt.Andere Möglichkeiten für die Muskelmodellierung sind Ellipsoide [200] oder Zylinder[219]. Durch die Muskelschicht wird die eigentliche Form des Körpers de�niert, die an-schlieÿend mit Hautschicht überzogen wird. Hierzu können Spline Ober�ächen [158],Implizite Flächen [200] oder eine Voxelisierung der unteren Schichten und Berechnungeiner polygonalen Ober�äche [219] verwendet werden.

Der Einsatz von haptischen Eingabegeräten, wie dem PhantomOmni [72] der FirmaSensable (siehe Abbildung 2.8), fällt ebenfalls in die Gruppe der kreativen Modellie-rung. Bei diesem Gerät werden Position und Ausrichtung eines Modellierstifts erfasst.Force-feedback ermöglicht es, die Ober�äche der virtuellen Geometrie zu erfühlen. Solässt sich der Stift schwerer bewegen, wenn sich der Stift einer Ober�äche nähert. Zu-sammen mit einer Software wie den �ClayTools� [71] kann so wie mit virtuellem Tonmodelliert werden, wodurch eine natürlichere Schnittstelle zur Modellierung der Geo-metrie bereitgestellt wird.


(a) Vitus Pro Scanner [86] (b) FastScan Scorpion [28]

Abbildung 2.9: 3D Scanner

Rekonstruktive Modellierung

Bei der rekonstruktiven Modellierung wird das Ziel verfolgt, die 3D Geometrie auto-matisch durch die Analyse von existierenden Formen zu erzeugen. Hierzu gehört derEinsatz von 3D Scannern, sowie der Rekonstruktion von 2D Bildern oder Videosequen-zen.

3D Scanner sind mittlerweile eine gängige Möglichkeit, die Geometrie von existierendenGegenständen oder Personen zu erfassen (siehe Abbildung 2.9). Kommerzielle Lösungenwerden von Firmen wie Cyberware [17], Vitronic [86] oder Polhemus [28] angeboten.Die TU Braunschweig hat eine einfache Hard- und Softwarelösung entwickelt und stelltBauanleitung und Software per Download zur Verfügung [76]. Die Scanner verwendenverschiedene Technologien wie Laserlicht und strukturiertes Licht und liefern Punkt-daten, sowie ggf. die Farbe des erfassten Punktes [194].

Aktuelle Problemstellungen sind die Optimierung der erfassten Daten (Datenreduk-tion, Füllen von Löchern, Rauschunterdrückung), sowie die automatische Erkennungder internen Skelett-Hierarchie, um die Animation der Modelle zu ermöglichen. Dabeiversucht man das Problem zu vereinfachen, indem eine bestimmte Skeletthierarchievorausgesetzt wird [172]. Ein anderer Ansatz wird in [157] beschrieben: Hier wird eingenerisches, animierbares Modell an die eingescannten Daten angepasst. Die Datenwerden also nicht für die unmittelbare Darstellung verwendet, sondern nur für dieKon�guration des Ursprungsmodells.

Bei der Rekonstruktion aus 2D Material werden herkömmliche Kameras und Metho-den aus der Bildverarbeitung eingesetzt. Die Verfahren unterscheiden sich darin, obentweder ein Bild oder eine Videosequenz als Quelle eingesetzt wird und darin, ob derGegenstand aus einer oder unterschiedlichen Perspektiven abgebildet werden muss.Methoden, die nur ein Bild einsetzen, verwenden u.a. anthropometrische Statistikenund lassen bestimmte Hypothesen über die Form des menschlichen Körpers in die Er-kennung mit ein�ieÿen (siehe [194]). Andere Methoden verwenden verschiedene, meistorthogonal zueinander stehende Ansichten, um ein vorhandenes Modell an die erkannte


Struktur anzupassen (siehe [172]). Mit Hilfe von Videosequenzen können auch Anima-tionen erkannt werden [186]. Hier werden zunächst ebenfalls bestimmte Einschränkun-gen in den Bewegungen (beispielsweise bestimmte Bewegungswinkel und physikalischeBewegungsmodelle) vorausgesetzt, um die Erkennung der Bewegung zu vereinfachen.

Interpolierende Modellierung

Bei der interpolierenden Modellierung werden vorhandene Modelle zu neuen Modellenkombiniert. Das Ausgangsmaterial kann sowohl durch kreative Modellierung, als auchdurch rekonstruktive Modellierung erstellt werden. Besonders vorteilhaft ist hierbei,dass neue Modelle interaktiv und leicht kontrollierbar - durch Kontrollparameter wieAlter, Geschlecht, Gröÿe und Gewicht - erzeugt werden können [172].

Bei der interpolierenden Modellierung müssen zwei Probleme gelöst werden. Zum einenmüssen die Ausgangsdaten so umgewandelt werden, dass eine Interpolation ermöglichtwird. Morphing erfordert beispielsweise, dass die vorhandenen Modelle die gleiche Geo-metriestruktur haben. In [123] wird hierzu ein Algorithmus entwickelt, der die Eckpunk-te eines Gittermodells denen eines bestehenden Morph-Modells zuordnen kann und soeine gleiche Struktur sicherstellt. Das zweite Problem besteht darin, geeignete Wertefür die Kontrollparameter zu �nden, um so bestehende Gesichter anzunähern. Hierzukönnen Fotos [123] oder Videosequenzen [215] eingesetzt werden.

In [146] wird ein weiteres Beispiel für die interpolierende Modellierung gezeigt. Zieldieser Arbeit ist die Rekonstruktion der Ober�ächenstruktur der Haut. Hierzu werdenhochau�ösende 3D Scans von Gesichtern (verschiedenen Alters, Geschlecht, etc.) erfasstund Haut-Details extrahiert sowie analysiert. Die Ergebnisse der Analyse können fürdie Synthese von Haut-Details verwendet werden, beispielsweise um Details zu niedrigau�ösenden 3D Scans hinzuzufügen oder um verschiedene Altersstufen zu simulieren.

2.3.3 Beein�ussung des Aussehens von Avataren durch Textu-ren

Texturen sind Bilder, die auf die Ober�äche von geometrischen Formen gelegt werdenkönnen. Hierdurch erscheint die Darstellung des Modells detailreicher und realistischer,ohne dass die zugrunde liegende Geometrie selbst verfeinert werden muss (siehe Abbil-dung 2.10). Dadurch sind Texturen für die Echtzeitdarstellung besonders interessant,da ein Modell mit einer einfachen Geometrie durch Texturen erheblich aufgewertetwerden kann. Mit der Ausnahme von �Displacement-Maps� verändern Texturen nichtdie Geometrie an sich, sondern nur die Darstellung. Hierzu gehört die Festlegung vonFarbwerten, Transparenz, sowie von Ober�ächenunebenheiten.

Mit einer Farb-Textur wird de�niert, welche Farben von dem Objekt re�ektiert werden.Je nach Lichteinstrahlung (indirekt, direkt, glänzend) können verschiedene Texturende�niert werden. Abbildung 2.10 (b) zeigt ein Modell mit einer Farb-Textur.

Durch Transparenz-Texturen können durchsichtige Bereiche der Geometrie de�niertwerden. Eine Transparenz-Textur wird in einem Graustufenbild abgelegt. Schwarz(Farbwert 0) de�niert durchsichtige Bereiche, Weiÿ (Farbwert 255) undurchsichtigeBereiche. Mit Grauwerten dazwischen können teilweise durchsichtige Bereiche de�niertwerden.


(a) ohne Texturen (b) mit Texturen (c) mit Bump-Map

Abbildung 2.10: Beein�ussung des Aussehens durch Texturen

(a) Farb-Textur (b) Transparenz-Textur

Abbildung 2.11: Texturen für Haare

Ober�ächenunebenheiten können durch Bump-Mapping dargestellt werden. Hierdurchkönnen extrem detailreiche Modelle dargestellt werden, ohne die Geometriekomplexitätdes Modells zu erhöhen. Bei dieser von Blinn [124] entwickelten Technik werden in einerTextur Informationen gespeichert, mit deren Hilfe Schattierungen auf die Ober�ächegezeichnet werden. Diese Informationen werden beispielsweise in Form von relativenHöhendaten gespeichert, wobei auch hier Graustufenbilder verwendet werden können.Hierbei de�niert Schwarz (Farbwert 0) die tiefste und Weiÿ (Farbwert 255) die höchsteStelle. Abbildung 2.10 (c) zeigt ein Modell mit einer Bump-Map.

Je nach Anwendungsgebiet können verschiedene Texturen auch kombiniert werden.Für eine detaillierte Darstellung der Haut kann eine Farb-Textur mit einer Bump-Mapkombiniert werden. Die Bump-Map enthält das Ober�ächenrelief der Haut, so dass inder Darstellung Falten sichtbar werden.

Farb- und Transparenz Texturen werden häu�g bei Haaren eingesetzt (siehe Abbildung2.11). Da das Rendern von mehreren Tausend einzelnen Haaren für die Echtzeitdarstel-lung ungeeignet ist, werden mehrere Haare zu Gruppen zusammengefasst, die durchtexturierte Polygon�ächen dargestellt werden (siehe [202]). Transparenz-Texturen wer-den in diesem Fall dazu verwendet, um die Geometrie an den Stellen transparent zumachen, an denen sich keine Haare be�nden. Die einzelnen Haare und die Haarfarbewerden durch eine Farb-Textur festgelegt. Diese Art der Darstellung hat den Vorteil,dass sie e�zient mit heutiger Gra�k-Hardware gerendert werden kann.

2.4 Animation von Avataren

Erst durch Bewegungen erwacht ein Avatar zum Leben. Die Animation wird jedochdadurch erschwert, dass der menschliche Körper nicht starr ist, sondern stattdessen


aus vielen Gelenken besteht. Deshalb ändert sich die äuÿere Form bei Bewegungen. Esmüssen daher Möglichkeiten gefunden werden, das geometrische Modell entsprechendmenschlicher Bewegungsabläufe verformen zu können. Neben einem verformbaren Mo-dell gehören dazu auch Methoden, Bewegungen zu generieren und wiederzugeben.

Der folgende Abschnitt stellt einige Möglichkeiten vor, das Modell eines Avatars zuverformen. Bei der Animation von Avataren wird traditionell zwischen Körper- undGesichtsanimation unterschieden. Während bei der Körperanimation primär Rotati-onsbewegungen in den Gelenken wiedergegeben werden müssen, sind bei der Gesichts-animation - mit Ausnahme der Bewegung des Unterkiefers - primär Muskelbewegungenvon Bedeutung. Die Abschnitte 2.4.2 und 2.4.3 beschreiben daher, welche Methodenbevorzugt für die Animationen von Körper und Gesicht eingesetzt werden. Abschnitt2.4.4 beschäftigt sich dann mit der Fragestellung, wie ein verformbares Modell animiertwerden kann.

2.4.1 Techniken zur Verformung der Avatar Geometrie

Starrkörpermodelle

Eine einfache Möglichkeit, ein verformbares Modell zu erzeugen, besteht darin, denKörper aus mehreren Teil-Modellen für Kopf, Hals, Brustkorb, Oberarm, Unterarm,etc. aufzubauen. In den Anfängen der Computergra�k wurden hierfür gra�sche Primi-tive wie Zylinder, Ellipsoide oder Kugeln eingesetzt [151]. Später wurden aber auchkomplexere Geometriestrukturen [158] verwendet. Die Animation beschränkt sich aufdie Translation und Rotation der Teilmodelle und lässt sich so e�zient implementieren.Die Technik hat jedoch den Nachteil, dass das Modell starr wirkt und die Übergängezwischen den Teilmodellen - je nach Verformung - sichtbar werden können.

Morphing

Eine andere Möglichkeit besteht darin, das Modell durch einen Animator in verschie-denen Schlüssel-Posen (Si) modellieren zu lassen. Für einen �ieÿenden Übergang wirddann zwischen Schlüssel-Posen interpoliert, indem diese mit verschiedenen Gewichtenkombiniert werden:

S =∑

i=0 wiSi

Dabei können die Gewichte wk gröÿer als eins oder kleiner als null sein.

Diese Technik, auch �shape blending� oder �multi-target morphing� genannt, wurdeoft in älteren Spielen für die Animation allgemein und heute noch für die Gesichts-animation eingesetzt. Sie erlaubt zwar alle künstlerischen Freiheiten, hat jedoch denNachteil, dass bei umfangreicheren Modellen sehr viele Eckpunkte editiert werden müs-sen, wodurch die Animation aufwändig und mühsam wird. Vor allem bei Rotationenmuss mit kleinen Animationsschritten gearbeitet werden, da die betro�enen Eckpunktenicht rotiert, sondern zwischen den Schlüsselposen linear interpoliert werden. Bei zugroÿen Animationsschritten kann es so zu unschönen und unnatürlichen Verformun-gen kommen (die Geometrie schrumpft). Durch den Einsatz von 3D Scannern kannzwar der Modellierungsaufwand verringert werden, mit einer zunehmenden Anzahl anSchlüssel-Posen wird aber die Speicherung der Modelldaten zusätzlich zum Problem.


(a) Vorderansicht (b) EFFD Gitter des Mundes

Abbildung 2.12: EFFD für die Gesichtsanimation [206]

Freiformdeformationen

Um die Animation zu vereinfachen, wurden verschiedene Techniken entwickelt, mit de-nen ein komplexes Modell mit Hilfe weniger Kontrollparameter verformt werden kann.Hierzu gehören Techniken wie die Freiform Deformation (�Free Form Deformation�(FFD)), erweiterte Freiform Deformation (�Extended Freeform Deformation� (EFFD))und Unterteilungs�ächen.

Freiform Deformation wurde zuerst von Sederburg und Parry [201] entwickelt. EinModell wird in ein umgebendes Gitter (FFD Box) eingeschlossen. Änderungen an demGitter werden auf das innen liegende Modell übertragen. Sederburg verwendet dieAnalogie, dass das Modell in verformbares Gummi eingebettet ist. Verformt man diesesGummi, wird das Modell - das ebenso �exibel wie das umschlieÿende Gummi ist -mitverformt. FFD wurde durch Coquillart [137] zu Erweiterten Freiform Deformation(EFFD) weiterentwickelt. Statt dem fest vorgegeben FFD Gitter kann der Anwendereigene Kontrollgitter (z.B. Zylinder) erzeugen.

Wie schon erwähnt, liegt der Vorteil beider Methoden darin, dass nur die Kontroll-punkte der umgebenden Kontrollgitter verändert werden müssen - die Komplexitätdes innen liegende Modells hat keinen Ein�uss mehr auf die Bearbeitung der Anima-tion. In [206] wurde EFFD beispielsweise für die Animation des Gesichtes verwendet(siehe Abbildung 2.12). Die verschiedenen Muskelgruppen des Gesichts werden EFFDKontrollgittern zugeordnet, wodurch die Gesichtsanimation auf die Veränderung derKontrollpunkte reduziert werden konnte.

Weitere Deformationsmöglichkeiten sind �Subspace Gradient Domain Mesh Deforma-tions� [154] und Multigrid Techniken [203].

Mehrschichtige Modelle

Mehrschichtige Modelle bestehen aus übereinandergelegten Schichten, wobei untereSchichten das Aussehen der überliegenden Schichten beein�ussen. Die unterste Schichtbesteht aus einem Skelett, an dem die gewünschten Verformungen durch Rotation inden Gelenken vorgenommen werden. Das Skelett kann mit weiteren Schichten umhülltwerden, die den Verformungen des Skeletts folgen. Bei einschichtigen Modellen - zu de-nen auch die Starrkörpermodelle gehören - ist das Skelett selbst sichtbar. Zweischichti-


Abbildung 2.13: Typische Defekte des SSD Algorithmus (kollabierender Ellenbogen)

ge Modelle bestehen aus dem (unsichtbaren) Skelett und der sichtbaren äuÿeren Hülle.Modelle mit mehr als zwei Schichten versuchen, den biologischen Aufbau des Körpersnachzuahmen und führen zusätzliche Schichten für Muskeln und Fettgewebe ein.

Zweischichtige Modelle auf Basis von �skeleton subspace deformation� (SSD) - auchbekannt unter den Bezeichnungen �skeleton driven deformation� (SDD), �linear blendskinning�, �smooth skinning� und �enveloping� - sind besonders weit verbreitet und wer-den von gängigen Modellierungsprogrammen unterstützt und in vielen Anwendungeneingesetzt [167, 172]. Bei dieser Methode wird jeder Eckpunkt v mit n Gewichtungs-faktoren (w1..wn) an n verschiedene Gelenke (Bones) des Skeletts gebunden, wobeidie Summe der Gewichtungsfaktoren gleich 1 sein muss. Diese Gewichtungsfaktorenwerden im folgenden auch �Skinning Informationen� genannt. Die Gewichtung erfolgtwährend der Modellierung (�Skinning�) und kontrolliert die Deformation. Die Trans-formationsmatrizen Mi der verknüpften Gelenke haben dann gemäÿ folgender Formeleinen Ein�uss auf die neuen Position eines Kontrollpunktes v′:

v′ =n∑

i=1

wiMiv,n∑

i=1

wi = 1

Der Algorithmus ist sehr vielseitig. Sekundäre Animationse�ekte, wie das Anschwellenvon Muskeln, können durch variable Gewichtung erzielt werden. Das verformte Modelllässt sich auÿerdem e�zient und schnell berechnen - mit Hilfe von Vertex-Shadernsogar direkt auf der Gra�khardware. Dadurch eignet sich das Verfahren besonders fürdie Echtzeitanimation.

Ein groÿer Nachteil des Algorithmus ist, dass die möglichen Positionen der Eckpunkteauf einen Unterraum beschränkt bleiben. Es ist durchaus möglich, dass die erwünsch-te Deformation nicht in diesem Unterraum liegt, gleichgültig wie sehr man auch dieGewichte optimiert. Es kann daher zu typischen Defekten (siehe Abbildung 2.13) kom-men. Ein weiterer Nachteil ist, dass der Algorithmus keine direkte Manipulation er-laubt. Stattdessen werden die Gewichte editiert, die nur indirekt zu der gewünschtenForm führen. Der Algorithmus - bzw. eher der Skinning-Vorgang - hat daher den Ruf,zeitraubend und schwer kontrollierbar zu sein.

Mehrere �skinning by example� Verfahren wurden entwickelt, um die genannten Pro-bleme zu beheben. Eines dieser Verfahren ist die �pose space deformation� [167], beider mit mehreren Korrekturmodellen gearbeitet wird. Die Animation erfolgt mit SSD,


bei kritischen Posen wird aber eines der Korrekturmodelle eingeblendet. Eine Erwei-terung wurde von [162] vorgestellt: �principal component analysis� (PCA) wird da-zu verwendet, um die benötigten Korrekturdaten zu reduzieren und erzielt so einekompaktere und schnellere Berechnung der Deformation. Die Berechnung ist auch aufGra�k-Hardware möglich.

Mohr et al. [178] führten zusätzliche Pseudo-Gelenke ein, bei denen die Skeletthier-archie erweitert wird, um die Unterschiede zwischen zwei benachbarten Gelenken zureduzieren. �Multiweight Enveloping� [216] führt dagegen zusätzliche Gewichte ein, umdie in einem Training analysierten Verformungen besser anzunähern.

James et al. [156] verzichten ganz auf ein Skelett. Sie haben ein �skinning by exam-ple� Verfahren entwickelt, bei dem ein automatischer Algorithmus progressive Skin-ning-Approximationen berechnet. Als Ausgangsbasis wird eine vorhandene Animationverwendet. Der Algorithmus schätzt unter anderem die Gewichte von Eckpunkten abund kann so die Animation reproduzieren. Die resultierenden Animationen können aufhandelsüblicher 3D Gra�khardware gerendert werden.

Statt Gewichten und einem herkömmlichen Modell verwenden Capell et al. [131] dyna-mische, elastische Körper. Die Form eines solchen Körpers wird durch �physical dyna-mics� bestimmt. Da konventionelle Rigging-Systeme nicht eingesetzt werden können,wurde ein neues Verfahren auf Basis von �rigging-forces� entwickelt. Mit diesem Ver-fahren kann das Modell durch einen Animator in Form gebracht werden. Da �riggingforces� - anders als bei SSD - nicht eng mit dem Modell verknüpft sind, können sieauch leichter auf andere Modelle übertragen werden.

2.4.2 Verformung des Körpers

Viele der zuvor genannten Methoden, darunter Morphing und Freiformdeformatio-nen, können für die Verformung des Körpers eingesetzt werden. Meist werden jedochMehrschicht-Modelle eingesetzt. Einschichtige Modelle werden beispielsweise im H-Anim 1.1 Standard [37] verwendet. Zur Zeit dominieren jedoch die zweischichtigenModelle, da sie e�zient gerendert werden können und gute visuelle Ergebnisse liefern.Modelle mit mehr als zwei Schichten werden bei physikalisch basierenden Modelleneingesetzt und wurden u.a. von Nedel und Thalmann [182], Scheepers et al. [200] sowieWilhelms und van Gelder [219] entwickelt.

Da bei mehrschichtigen Modellen die Verformung des Körpers durch das Skelett de-�niert wird, reicht die Angabe der aktuellen Gelenkparameter zur Beschreibung derVerformung aus. Auch wenn diese Vorgehensweise nicht der Realität entspricht - beider die Form durch Muskelkontraktionen festgelegt wird - ist sie sehr intuitiv.

2.4.3 Verformung des Gesichts

Die Verformung des Gesichts kann mit Morphing Techniken, parametrischer Anima-tion oder physikalisch basierenden Methoden realisiert werden. Morphing-Techniken[188, 192, 123] sind hier besonders weit verbreitet, da sich das Rendering - bei gleich-zeitig guten visuellen Ergebnissen - e�zient umsetzen lässt. Bei parametrischen Anima-tionen [189, 217, 173, 206] werden Muskel-Vektoren oder EFFD Techniken dazu verwen-


(a) Primäre Face Animation Parameter (b) Feature Points

Abbildung 2.14: MPEG 4 Gesichts-Parameter [185]

det, die Geometrie des Gesichtsmodells zu verändern. In Spielen werden auch SSD Tech-niken eingesetzt [108]. Muskeln werden dabei durch zusätzliche Gelenke simuliert, dieim Kopf angeordnet werden. Physikalisch basierende Methoden [165, 207, 129, 117, 157]verwenden mehrschichtige Modelle, die aus einer Muskel- und einer Hautschicht auf-gebaut sind. Simulierte Muskelkontraktionen führen dann zur Verformung der äuÿerenHautschicht.

Die Beschreibung von Gesichtsausdrücken wird durch die Vielzahl an möglichen Pa-rametern erschwert und ist daher nicht so intuitiv wie die Verformung eines Skelettsbei der Körperanimation. Durch zwei Parametrisierungsstandards, das �facial actioncoding system� (FACS) und die MPEG4 �facial animation parameters� (FAP), wer-den die Parameter vereinheitlicht und die Animation von Gesichtern erleichtert. Beidewerden oft eingesetzt und haben sich so als de facto Standards zur Beschreibung vonGesichtsbewegungen etabliert [130].

Das FACS wurde von Ekman und Friesen [139, 42] entwickelt, um jeden möglichen Ge-sichtsausdruck kategorisieren zu können. Hierzu wurde untersucht, wie sich bestimmteMuskelgruppen auf den Gesichtsausdruck auswirken. Sichtbare Muskelbewegung imGesichtsbereich werden so genannten �Action Units� (AU) zugeordnet. An einer AUkönnen ein oder mehrere Gesichtsmuskeln beteiligt sein (z.B. AU1: Frontalis, pars me-dialis). Mit dieser Klassi�kation ist es möglich, Gesichtsausdrücke schriftlich zu no-tieren. Umgekehrt wird das FACS aber in der Computergra�k auch dazu verwendet,einen bestimmten Gesichtsausdruck festzulegen, indem die für einen Gesichtsausdruckbenötigten AUs aktiviert werden. Ein überraschter Gesichtsausdruck ist zum Beispieldie Kombination �Action Units� AU1, AU2 und AU26 [206].

Bei MPEG4 wird jede Aktion, die ein Gesichtsmodell in einem neutralen Zustand ver-ändert, einem �face animation parameter� (FAPs) zugeordnet [185]. Wie auch die AUsdes FACS sind sie eng mit Muskelbewegungen verwandt. Beispiele für FAPs sind �Freu-de� oder �Langweile�, aber auch Kopf-, Augen- und Mundbewegungen (siehe Abbildung2.14 (a)). Der Wert eines FAPs gibt die Stärke der Beein�ussung an, wobei mehrereFAPs auch gemischt werden können. Dadurch können auch die AUs des FACS de�niertwerden. Insgesamt werden 68 FAPs de�niert, die in 10 Gruppen untergliedert werden.Jede Gruppe wird dabei einem bestimmten Teil des Gesichts zugeordnet. FAPs ba-sieren auf 84 Merkmalspunkten (feature points) (siehe Abbildung 2.14 (b)) und sinddaher unabhängig vom verwendeten Kopfmodell.


2.4.4 Animationstechniken

Für die Animation von Avataren können verschiedene Techniken eingesetzt werden.Üblich sind Verfahren wie Keyframing, kinematische Techniken sowie Motion Capture.Es werden aber auch parametrische Verfahren eingesetzt, bei denen die Bewegungdurch den Computer generiert wird. Oft werden Techniken auch kombiniert. So könn-te beispielsweise Motion Capture für eine Laufbewegung eingesetzt werden, währendGreifbewegungen der Hand durch parametrische Animation erzeugt werden.

Keyframing

Keyframing ist eine der ältesten Animationstechniken. Hierbei werden durch einen Ani-mator die Animationsparameter - z.B. Gelenkwinkel für das Skelett oder Morphing-Gewichte für das Gesicht - verschiedener Schlüsselposen erzeugt. Eine �ieÿende Ani-mation wird durch anschlieÿende Interpolation der Animationsschritte zwischen denSchlüsselposen realisiert. Abhängig von den Fähigkeiten des Animators können mitdieser Technik sehr gute Ergebnisse erzielt werden. Bei vielen Animationsparameternist die Animation aber arbeits- und zeitaufwändig.

Kinematische Techniken

Bei den kinematischen Techniken wird zwischen Vorwärts- und Inverser Kinematik un-terschieden. Beide basieren auf einer kinematischen Kette, d.h. einer hierarchischenAnordnung von Gelenken. Bei der Vorwärtskinematik werden der Reihe nach alle Ge-lenkparameter de�niert und spezi�zieren so die Position des Endes der Kette (End-E�ektor). Bei der inversen Kinematik wird die Position des End-E�ektors festgelegtund die dazu passenden Parameter der Kette berechnet.

Kinematische Techniken werden beispielsweise zur Steuerung von Robotern eingesetzt[221], können aber auch die Animation erleichtern. Bei der Animation von Avatarenmüssen beispielsweise nur noch die Positionen von Händen oder Füÿen festgelegt wer-den, und die Gelenkwinkel für Arme und Beine werden mit inverser Kinematik automa-tisch bestimmt. Hierfür sollten spezielle Implementierungen eingesetzt werden, da dieüblichen Lösungsverfahren meist auf Roboter spezialisiert sind [209]. Die Generierungrealistischer Bewegungen ist jedoch problematisch, da bei den bestehenden Lösungennatürliche Krafteinwirkungen und Beschleunigungen keinen Ein�uss auf die Animationhaben [144].

Motion Capture (MOCAP)

Die Animation von Avataren unter Verwendung von aufgezeichneten Bewegungsdatenist eine weit verbreitete Technik und besonders in der Film- und Computerspielein-dustrie sehr populär. Hierzu werden Bewegungen realer Akteure erfasst und gespei-chert. Die erfassten Daten können dann für die Animation verwendet werden. Da realeBewegungen aufgezeichnet und wiedergegeben werden, wirken die resultierenden Ani-mationen sehr natürlich. Motion Capture wird nicht nur für die Computeranimationeingesetzt, sondern hat auch viele Anwendungsgebiete in der Biomechanik und derErgonomie.


(a) optisch [85] (b) magnetisch [2] (c) mechanisch [53] (d) Gyroskope[53]

Abbildung 2.15: Motion Capture Systeme

Für die Erfassung von Bewegungen können optische, magnetische und mechanischeSysteme eingesetzt werden. Bei optischen Systemen werden in der Regel re�ektierendeMarker an markanten Körperstellen befestigt (siehe Abbildung 2.15 (a), z.B. von VI-CON [85]). Die Bewegung wird anschlieÿend mit einer oder mehreren Videokamerasaufgezeichnet und die Markerpositionen per Software ermittelt. Es existieren aber auchSysteme, bei denen die Bewegung ohne die Marker erfasst werden kann (u.a. [159]).Optische Systeme können Bewegungen zuverlässig in Echtzeit erfassen und behindernnicht den Akteur. Demgegenüber stehen ein eingeschränkter Aktionsradius und Pro-bleme bei der Erfassung, wenn Marker verdeckt sind.

Magnetische Systeme verwenden Hall-Sensoren, die auf dem Körper des Akteurs ver-teilt sind (siehe Abbildung 2.15 (b), z.B. von Ascension [2]). Die Sensoren übertragenihre Daten zu einer elektronischen Kontrolleinheit, die dann die Position und Ausrich-tung der Sensoren im dreidimensionalen Raum berechnet. Auch magnetische Systemekönnen Daten in Echtzeit erfassen. Es gibt keine Überdeckungsprobleme wie bei denoptischen Systemen. Die Erfassung kann aber durch metallische Gegenstände gestörtwerden.

Bei mechanischen Systemen trägt der Akteur eine Art Auÿenskelett, welches den Be-wegungen des Akteurs folgt (siehe Abbildung 2.15 (c), z.B. von MetaMotion [53]). DieBewegungen werden mit Hilfe von elektromechanischen Sensoren gemessen. Im Gegen-satz zu den beiden anderen Systemen liefern mechanische Systeme nur Rotationsdatenund keine Positionsangaben. Sie können Bewegungen in Echtzeit erfassen und der Ak-tionsradius ist quasi nicht eingeschränkt. Das Auÿenskelett schränkt jedoch die Bewe-gungsmöglichkeiten des Akteurs ein. Statt des Auÿenskeletts können die Bewegungenaber auch mit Gyroskopen erfasst werden (siehe Abbildung 2.15 (d)).

Mit den erfassten Bewegungsdaten kann ein Avatar, der die gleichen Körperdimensio-nen wie der aufgezeichnete Akteur hat, die Bewegung exakt reproduzieren. Oft sollendie Bewegungen aber auch für die Steuerung von Avataren mit abweichenden Kör-perdimensionen verwendet werden. Auÿerdem ist die Aufzeichnung jeder möglichenBewegungssequenz aufwändig und speicherintensiv. Es wurden daher Verfahren entwi-ckelt, mit denen die Bewegungsdaten weiterverarbeitet und auf Basis von vorhandenen


Bewegungen neue Bewegungen erzeugt werden können.

Die Anpassung von Bewegungsdaten an neue Körperdimensionen wird �motion retar-getting� genannt. Die Bewegungsdaten werden dabei so angepasst, dass der neue Ziel-Avatar plausibel und koordiniert animiert werden kann. Eine naheliegende Methodeist, die Bewegung so anzupassen, dass die Bewegungsbahnen der End-E�ektoren mitdenen der originalen Bewegung übereinstimmen [134]. Hierdurch wird sichergestellt,dass der Ziel-Avatar externe Objekte auf die gleiche Art und Weise berührt, wie esder originale Akteur getan hat (er tritt z.B. in die gleichen Fuÿstapfen). Hierbei be-steht jedoch die Gefahr, dass der originale Charakter der Animation verloren geht unddie Bewegung unnatürlich wirkt. Andere Verfahren schränken daher die Bewegungs-möglichkeiten der End-E�ektoren ein und verwenden inverse Kinematik [126]. Eineweitere Möglichkeit ist die Verwendung von Optimierungsverfahren, die die originaleBewegung annähern, aber gleichzeitig gewisse Einschränkungen berücksichtigen [127].Neben allgemeinen Ansätzen gibt es auch spezialisierte Verfahren, die die Eigenschaf-ten bestimmter Bewegungen (z.B. Laufen) in Trainingssequenzen analysieren und dannfür beliebige Avatare anwenden können [199, 145].

Für den praktischen Einsatz werden oft groÿe Datenbanken mit Bewegungssequen-zen aufgebaut, die in geeigneter Weise aneinander gefügt und überblendet werden, umdie fertige Animation zu erzeugen. Bewegungssequenzen können aber nicht beliebigkombiniert werden, da es sonst zu Sprüngen in den Übergängen kommen kann. Eswurden daher spezielle Verfahren entwickelt, mit denen man e�zient in den Bewe-gungsdatenbanken suchen und zur aktuellen Bewegung passende Sequenzen abfragenkann (u.a. von [163, 181]). Andere Verfahren können zwischen zwei Bewegungssequen-zen interpolieren [179, 226], wodurch sich die Datenbanken �exibler einsetzen lassen.Die Bewegungssynthese ermöglicht die Generierung neuer Bewegungen aus einer Be-wegungsdatenbank [198, 223]. Hierbei werden nur Start- und Endpose vorgegeben. DieVerfahren generieren dann mit Hilfe der Datenbank eine Animation, so dass die Posendes Avatars Geometrische-, Kinematische- und Haltungseinschränkungen erfüllen.

MOCAP kann auch zur Erfassung der Gesichtsmimik verwendet werden, wobei hieroptische Systeme eingesetzt werden. Es können sowohl markerlose, als auch Systememit Markern verwendet werden. �Performance Capture� (siehe Abbildung 2.16) ist eineErweiterung des klassischen MOCAP, bei der sowohl Gesicht, als auch Körper in einemDurchgang aufgezeichnet werden.

Parametrische Animation

Bei der parametrischen Animation (siehe Abbildung 2.17) werden Algorithmen einge-setzt, die die Bewegung errechnen. Die Bewegung wird so nur noch durch die Parame-ter der Algorithmen beein�usst. Dies kann bei einem Laufalgorithmus beispielsweisedie Gangart (gehen, laufen, rennen) sein. Einen passenden Algorithmus vorausgesetzt,können mit Hilfe der Parameter viele Variationen der gleichen Grundbewegung erzeugtwerden, was insbesondere dann von Interesse ist, wenn viele Avatare gleichzeitig ein-gesetzt werden. Oft lassen sich parametrische Animationen auch direkter beein�ussenals dies bei Motion Capture Animationen möglich ist [153].

Für die Berechnung der Animation werden sowohl constraint-basierte Systeme, wieauch dynamische Simulationen eingesetzt. Bei dynamischen Simulationen wird die


Abbildung 2.16: Performance Capture: Tom Hanks als Scha�ner im Film �Der Polar-express� (Warner Bros. Pictures) (links). Auf der rechten Seite ist die gerenderte Szenezu sehen.

Abbildung 2.17: Beispiele parametrischer Animationen [153]


Newtonsche Mechanik angewendet, um mit Hilfe von Kraft- und Beschleunigungs-einwirkungen realistische Animationen zu erzeugen. Bei constraint-basierten Systemenwerden die Animationen unter Verwendung von Einschränkungen und Vorgaben de�-niert und sind das Ergebnis eines Optimierungsprozesses. Raum-Zeit-constraints wur-den zuerst von Witkin und Kass [220] eingeführt. Der Animator spezi�ziert, was einAvatar tun soll (�springe von A zu B�), wie die Bewegung realisiert werden soll (�keineEnergie verschwenden�), die Körperstruktur (Hierarchie, Masse) und die physikalischenRessourcen (Muskeln, etc.). Eine Lösung, die allen Bedingungen gerecht wird, soll danneine realistische Animation liefern. Wegen ihrer hohen Komplexität sind Raum-Zeit-constraints zur Zeit aber auf einfache Systeme beschränkt [144].

Für die Simulation von Bewegungen verwendet das �Jack�-System [121] dynamischeund kinematische Modelle von Menschen, welche auf biomechanischen Daten und ein-gebauten Verhaltenseigenschaften basieren. Um realistische Bewegungen zu erzeugen,werden bei den eingebauten Verhaltenseigenschaften verallgemeinerte Daten verwen-det, die aus Motion Capture Daten gewonnen wurden.

Hodgins et al. [153] verwenden von Hand entwickelte Algorithmen für Bewegungenwie Laufen, Radfahren und Springen. In die Entwicklung der Algorithmen �ossen Er-gebnisse von Beobachtungen von realen Menschen, sowie biomechanische Daten ein.Constraints wurden verwendet, um Fuÿkontakte auf dem Boden und an den Fahrrad-pedalen zu modellieren.

Eine andere Möglichkeit ist die Verwendung von Bewegungsmodellen (motion models)und Clip-Operatoren [149]. Bewegungsmodelle bezeichnen elementare Bewegungen, dienicht weiter untergliedert werden können (beispielsweise �Laufen� oder �Winken�). Je-des Bewegungsmodell hat seinen eigenen Satz von Parametern, mit denen die Cha-rakteristik der Bewegung festgelegt werden kann. Diese Bewegungen können mit ver-schiedenen Clip-Operatoren miteinander verknüpft werden, wodurch neue, komplexereBewegungen entstehen.

Ein Problem, das vielen parametrischen Animationen gemeinsam ist, ist ihr zu perfektesErscheinungsbild und ihre exakte Wiederholung bei zyklischen Bewegungen. Dadurchkönnen die Bewegungen steril und roboterhaft wirken. Das Improv System von Perlinund Goldberg [191] versucht dies zu vermeiden, indem es Bewegungen der Extremitä-ten kleine, zufällige Störungen beimischt. Improv besteht aus zwei Subsystemen. Daserste Subsystem ist die Animationseinheit, welche prozedurale Techniken bereitstellt,um Animationen zu beschreiben. In diesen Beschreibungen wird u.a. de�niert, welchenEin�uss die zufälligen Störungen haben dürfen. Mehrere Animationen können kombi-niert werden, wobei sinnlose Kombinationen verhindert werden (�Laufen� kann nichtmit �Stehen� kombiniert werden). Um dies zu erreichen, werden die Animationen ineiner Hierarchie angeordnet. Diese wird dann für die Entscheidung verwendet, ob undwie eine Kombination von Animationen möglich ist. Das zweite Subsystem baut aufder Animationseinheit auf und ist für die Steuerung des Verhaltens zuständig. Übereine Skriptsprache können Regeln aufgestellt werden, die die Aktionen der Avatarede�nieren.

Lippensynchrone Animation von sprechenden Avataren

Eine weitere Herausforderung ist die Animation von sprechenden Avataren. Menschensind hoch spezialisiert darin, Änderungen in der Gesichtsmimik zu interpretieren. So-


wohl Sprachausgabe, als auch Gesichtsmimik haben daher Ein�uss auf die Wahrneh-mung von Informationen. Im günstigen Fall kann Gesichtsanimation das Verständniserhöhen, sowie die Wiedergabe emotionaler Zustände unterstützen [128]. Auf der an-deren Seite kann ein schlecht animiertes Gesicht durch den McGurk-E�ekt [52] auchInformationen verfälschen und den Betrachter verwirren.

Alle zuvor aufgezählten Animationsverfahren können sowohl für den Körper, als auchfür das Gesicht eines Avatars eingesetzt werden. Abgesehen von MOCAP sind sie fürdie Animation von sprechenden Avataren aber eher ungeeignet. Im folgenden werdendaher zwei Verfahren vorgestellt, mit denen die Animation von sprechenden Avatarenrealisiert werden kann.

Bei dem ersten Verfahren wird der zu sprechende Text in Textform vorgegeben [122,138, 147, 185, 117, 206]. Der Text wird zunächst in sprachliche Bestandteile, z.B. Pho-neme, zerlegt. Phoneme sind kleinste bedeutungsunterscheidende lautliche Einheiteneiner Sprache und haben visuelle Entsprechungen, die Viseme genannt werden [119].Mit Hilfe dieser Viseme wird das Gesicht animiert. Die Sprachausgabe erfolgt durchein �Text to Speech�-System, welches den Text in das Sprachsignal umwandelt.

Das zweite Verfahren verwendet Audioinformationen von gesprochenem Text für dieGenerierung der Animation. Unter anderem werden Neuronale Netze [116, 175] oderVerborgene Markow-Modelle (Hidden Marcov Model (HMM)) [116, 128, 212] einge-setzt, die mit Sprachaufzeichnungen von realen Personen trainiert werden. Nach demTraining können diese Systeme die Viseme aus dem Sprachsignal ermitteln, welchedann für die Animation eingesetzt werden.

Die Viseme können jedoch nicht einfach hintereinander wiedergegeben werden, da dasAussehen eines Visems durch seinen lautlichen Kontext beein�usst wird (Koartikula-tion). Zur Realisierung der Koartikulation können drei Modelle unterschieden werden.Dies sind zeitgebundene (time-locked), vorausschauende (look-ahead) und hybride Mo-delle [190].

Bei zeitgebundenen Modellen werden Laute zu einem festen Zeitpunkt eingeblendet,wobei die Gewichtung vom Umfeld des Lautes unabhängig ist [135]. VorausschauendeModelle berücksichtigen dagegen das lautliche Umfeld. Zwei Beispiele hierfür sind eindatenbasiertes Modell und ein regelbasiertes Modell aus [140]: �Das datenbasierte Mo-dell wählt aus einer Datenbank zwei Parameterbelegungen eines Lautes aus, die demlautlichen Umfeld des Lautes in der zu generierenden Äuÿerung am ähnlichsten sind.[. . . ] Das regelbasierte Modell berechnet über eine Zielpositionsfunktion für die Lauteeiner Äuÿerung aus �ktiven Idealpositionen der Artikulatoren und Dominanzen eineKette von einzunehmenden Zielpositionen. Dominanz bedeutet in diesem Zusammen-hang der Ein�uss eines Lautes auf einen Artikulator/Bewegungsparameter.�

Hybride Modelle sind Kombinationen beider Verfahren [190]. Koartikulationse�ektebeein�ussen die Animation in zwei Phasen. Der Beginn der ersten Phase wird durchein vorausschauendes Modell berechnet. Die zweite Phase startet wie von dem zeitge-bundenen Modell berechnet. Hierdurch wird ein Laut in der ersten Phase langsamerund beein�usst durch seine Umgebung eingeblendet. In der zweiten Phase beschleunigtdie Einblendung.

Verschiedene Sprachen unterscheiden sich in ihrer Koartikulation. Abhängig von derZielsprache können daher bestimmte Modelle besser geeignet sein als andere [135, 190].


(a) 3D Studio Max [4] (b) Blender [9]

Abbildung 2.18: Modellierungs- und Animationsprogramme

2.5 Vorhandene Modellierungs- und Animationspro-gramme

Modellierung und Animation von Avataren haben in den letzten Jahrzehnten groÿe,wissenschaftliche Fortschritte gemacht. Ein groÿes, nach wie vor ungelöstes Problemist jedoch, dass sich die entwickelten Lösungen nur schwer zu einem Gesamtsystemkombinieren lassen [148]. Zum einen liegt dies daran, dass Verfahren an Prototypengetestet wurden, die nicht für die Allgemeinheit verfügbar sind. Und selbst wenn sieverfügbar sind, sind sie nur selten darauf ausgelegt, um mit anderen Komponenten zukooperieren.

Auf der anderen Seite existieren bewährte kommerzielle Programme wie 3D StudioMAX, Maya, Poser oder MotionBuilder, die sich ebenfalls zur Modellierung und Ani-mation von Avataren eignen. Ebenfalls verfügbar sind OpenSource-Lösungen wie Blen-der oder MakeHuman. Im folgenden sollen verfügbare Programme kurz vorgestellt unddann anhand einer Tabelle miteinander verglichen werden.

2.5.1 Allgemeine Modellierungs- und Animationsprogramme

3D Studio Max [4] ist ein 3D Gra�k- und Animationsprogramm, welches sowohl inBereichen wie Computerspiele, Comic, Animationen und Film (TV / Kino), als auchin gestalterischen Berufen wie Design oder Architektur seinen Einsatz �ndet [91]. Ins-besondere in der Spieleentwicklung ist es weit verbreitet. Das Programm wird zur Zeitvon der Firma Autodesk entwickelt und hat einen umfangreichen Funktionsumfang.Unter anderem werden zur Modellierung Polygonobjekte und parametrische Flächen(NURBS) angeboten. Hinzu kommen Partikelsysteme und Character Animation. Die-se kann entweder mittels Morphing oder skelettbasiert erfolgen, wobei das Programmsowohl herkömmliche Gelenke, als auch eine vorkon�gurierte Skelettstruktur für huma-noide Figuren bereitstellt. Diese �Bipeds� lassen sich sowohl parametrisch, als auch mitMOCAP animieren. 3D Studio Max lässt sich einfach durch selbst entwickelte Pluginserweitern, wodurch eine groÿe Anzahl an Erweiterungen verfügbar ist.

Blender [9, 93] nimmt eine Sonderstellung unter den hier vorgestellten Programmenein, da es als einziges kostenlos verfügbar ist. Das Programm wurde zunächst von


der Firma NaN entwickelt und vermarktet. Nach dem Bankrott der Firma wurde dasProgramm unter die freie Softwarelizenz GNU General Public License (GPL) gestelltund weiterentwickelt. Blender kann zur Modellierung, Animation und zum Renderndreidimensionaler Modelle verwendet werden. Als Besonderheit enthält das Programmauch ein Modul, mit dem sich Spiele und interaktive 3D Anwendungen realisierenlassen. Unter Verwendung der Skriptsprache Python kann das Programm �exibel mitPlugins erweitert werden.

Carrara [18] ist ein vergleichsweise günstiges 3D Modellierungs-, Animations- und Ren-dering Paket und wird zur Zeit von DAZ Productions vertrieben. Eine Besonderheit istdie nahtlose Integration von Poser - einem Design- und Animationspaket für Avatare(s.u.) - , wodurch der Im- und Export von Poser-Modellen erleichtert wird. Da Carraraauch das FBX Format (s.u.) verarbeiten kann, eignet es sich für die Konvertierung vonAvatar-Modellen.

Cinema 4D [50] wird von der Firma Maxon entwickelt. Es wird in der Architektur,bei der Konstruktion, sowie in TV und Film eingesetzt. Es ist modular aufgebautund kann u.a. mit Modulen zur Character Animation, Haar- und Kleidungssimulationsowie Dynamischer Simulation erweitert werden. MOCCA, das Character AnimationsModul, bietet ein gelenkbasiertes System für die Erzeugung des Skeletts, sowie einMuskelsystem, welches für die Verformung der Haut eingesetzt werden kann. Werkzeugezum Morphing und zur Erstellung von Kleidung runden den Funktionsumfang ab.

Lightwave 3D [58] der Firma NewTek war eines der ersten bedeutenden und profes-sionell eingesetzten Programme zum Modellieren, Animieren und Rendern und wirdin vielen Spiel-, Fernseh- und Filmproduktionen eingesetzt. Im Gegensatz zu ande-ren Programmen besteht Lightwave aus zwei Komponenten: �Modeler� und �Layout�[97]. �Modeler� bietet Werkzeuge zur Modellierung von dreidimensionalen Objekten,während mit �Layout� die Beleuchtung, Animation und das Rendering durchgeführtwerden. Die Ober�äche dieser Module ist jeweils so ausgelegt, dass ein möglichst e�-zientes Arbeiten ermöglicht wird. Wie viele professionelle 3D Programme lässt es sichüber ein SDK und eine eingebaute Skriptsprache erweitern.

Maya [5] wird mittlerweile ebenfalls von Autodesk entwickelt und ist wie 3D StudioMax eine professionelle und leistungsstarke integrierte Lösung für 3D-Modelling, Ani-mation, E�ekte und Rendering. Das Programm wird für Spiele, häu�ger aber bei Film-und Videoproduktionen eingesetzt. Es wird in den Varianten �Complete� und �Unlimi-ted� angeboten. Die �Complete� Variante enthält bereits umfangreiche Werkzeuge zurCharakter Animation. Die �Unlimited� Version erweitert den Funktionsumfang um Mo-dule zur Erzeugung von Kleidung und Haaren. Maya hat eine o�ene Architektur undkann unter Verwendung eines umfassenden SDK geskripted oder programmiert werden.

2.5.2 Spezialisierte Avatar Modellierungsprogramme

Poser [23] ist auf die realitätsgetreue Animation und Gestaltung von menschlichen undtierischen Charakteren spezialisiert und wird zur Zeit von der Firma e-frontier entwi-ckelt. Das Programm wurde ursprünglich als virtueller Ersatz für die von Künstlernverwendeten Gliederpuppen entworfen. Mit Poser können keine Avatare von Grund aufmodelliert werden. Stattdessen werden verschiedene Basis-Avatare bereitgestellt, derenAussehen bis zu einem gewissen Grad an die eigenen Anforderungen angepasst werden


(a) Poser [23] (b) MakeHuman [20]

Abbildung 2.19: Spezialisierte Avatar Modellierungsprogramme

kann. Es eignet sich daher für die schnelle Erzeugung von Avataren. Die Avatare könnenskelettbasiert animiert werden. Gesichtsanimation ist unter Verwendung von Morphingmöglich. Poser verfügt über Module zur Haar- und Kleidungssimulation und enthältWerkzeuge zur Animation der Avatare. Da Poser keine 3D Modellierungsmöglichkeitenhat, hat sich um das Programm herum ein groÿer Markt an Zulieferern entwickelt, dieneue Inhalte für Poser anbieten.

Eine kostenlose Alternative zu Poser ist DAZ-Studio [19]. Das Programm kann Poser-Dateien verarbeiten, hat aber einen kleineren Funktionsumfang. So werden beispiels-weise weder inverse Kinematik, noch dynamische Haare und Kleidung unterstützt.

MakeHuman [20] ist auf die Modellierung von Avataren spezialisiert. Das OpenSourceProjekt erlaubt die interpolierende Modellierung von Modellen. Mehr als 3.000 Morph-Ziele können miteinander kombiniert werden, um eine groÿe Anzahl an verschiedenenModellen zu erzeugen. Fertige Modelle können exportiert und in anderen Programmenweiterverarbeitet werden.

2.5.3 Spezialisierte Avatar Animationsprogramme

Das Programm MotionBuilder [6] der Firma Autodesk ist ein leistungsstarkes Paketfür komplexe 3D-Character Animation und bietet viele Werkzeuge für die Echtzeit-Bearbeitung in Animationsprojekten. Es unterstützt sowohl Morphing, als auch ske-lettbasierte Animation, und bietet eine Reihe von Echtzeit-Animationswerkzeugen. Da-zu gehören Keyframe-Animationen, sowie die Verarbeitung von MOCAP Daten. DasProgramm beherrscht das �retargetting� von MOCAP Daten, so dass aufgezeichneteBewegungsinformationen mit verschiedenen Avataren verwendet werden können. DasProgramm unterstützt auch die Gesichtsanimation von Avataren. Diese kann unterEinsatz von MOCAP, sowie mit Audiodaten von gesprochenem Text realisiert werden.

Animationen können in so genannten Clips organisiert werden, die in einem Story-Editor miteinander kombiniert werden können, wodurch sich auch komplette Szenenumsetzen lassen. MotionBuilder wurde mit einem besonderen Augenmerk auf Echtzeit-wiedergabe der Animationen entwickelt, weshalb sich Animationen zu jedem Zeitpunktkontrollieren lassen. Durch Schnittstellen zu MOCAP-Hardware verschiedener Herstel-ler können Daten aufgezeichnet und in Echtzeit auf Avatare übertragen werden.


(a) MotionBuilder [6] (b) Endorphin [56]

Abbildung 2.20: Spezialisierte Avatar Animationsprogramme

Endorphin [56] der Firma NaturalMotion ist ein Programm zur dynamischen Bewe-gungssynthese. Es verwendet Techniken aus der künstlichen Intelligenz und der Bio-mechanik, um sowohl menschliche Verhaltensweisen, als auch physische Körpereigen-schaften zu simulieren. Adaptive Verhaltensregeln werden zur Steuerung der Avatareeingesetzt. Anwender animieren die Avatare nicht direkt, sondern geben Verhaltensre-geln vor und können Simulationsparameter beein�ussen. Entsprechend den Einstellun-gen wird eine Simulation durchgeführt, deren Ergebnis direkt im Programm betrachtetwerden kann. Fertige Animationen können aus dem Programm exportiert und in an-deren Programmen wie 3D Studio Max, Maya oder MotionBuilder weiterverarbeitetwerden.

2.5.4 Gegenüberstellung der Programme

In Tabelle 2.1 sind die Eigenschaften der zuvor vorgestellten Programme zusammen-gefasst. Die Tabelle erhebt keinen Anspruch auf Vollständigkeit. Vielmehr wurden fürden Vergleich nur Eigenschaften herangezogen, die für Modellierung und Animationenvon Avataren relevant sind (siehe Kapitel 2.3 und 2.4).

Insbesondere die groÿen 3D Pakete wie 3D Studio Max, Cinema 4D, Lightwave undMaya gehen in ihrem Funktionsumfang weit über die in der Tabelle aufgeführten Funk-tionen hinaus - nur haben diese Funktionen nicht unmittelbar etwas mit Avataren zutun. Die Tabelle gibt auch keinen Aufschluss über die Qualität der jeweiligen Funktio-nen. So sind die inverse Kinematik und die retargetting Möglichkeiten von Spezialpro-grammen wie MotionBuilder beispielsweise besser zu bewerten als die von allgemeinenProgrammen wie Blender oder 3D Studio Max.

Es wurden nur Funktionen berücksichtigt, die in den Programmen in den maximalenAusbaustufen verfügbar sind. Viele fehlende Funktionen können aber teilweise auchmit Erweiterungen von Drittanbietern nachgerüstet werden. So existieren für 3D StudioMax beispielsweise Erweiterungen, die die interpolierende Modellierung von Gesichternund die lippensynchrone Animation mittels Sprachdateien zulassen. Der Markt an Er-weiterungen ist aber so groÿ, dass ein objektiver Vergleich schwierig wird. Auÿerdembesteht immer die Gefahr, dass Erweiterungen für zukünftige Versionen der aufgeführ-ten Programme nicht mehr weitergep�egt werden und damit nicht mehr verfügbar sind.Diese Gefahr ist bei fest eingebauten Funktionen geringer.


3DSMax

Blender

Carrara

Cinem

a4D

Lightwave

3D

Maya

Poser

DazStudio

MakeHuman

MotionBuilder

Endorphin

Modellierung

Polygon�ächen Ja Ja Ja Ja Ja Ja - - - - -

Parametrische Flächen Ja Ja - Ja Ja Ja - - - - -

Unterteilungs�ächen Ja Ja Ja Ja Ja Ja - - - - -

Implizite Flächen - Ja Ja Ja Ja Ja - - - - -

Interp. Modellierung - - - - - - Ja Ja Ja - -

Texturen

Farbe Ja Ja Ja Ja Ja Ja Ja Ja - Ja -

Transparenz Ja Ja Ja Ja Ja Ja Ja Ja - Ja -

Bump-Map Ja Ja Ja Ja Ja Ja Ja Ja - Ja -

Animation

Starrkörper Ja Ja Ja Ja Ja Ja - - - Ja -

Morphing Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja -

Freiformdeformation Ja - - Ja - Ja - - - - -

Skelettbasiert Ja Ja Ja Ja Ja Ja Ja Ja - Ja Ja

Animationstechniken

Keyframing Ja Ja Ja Ja Ja Ja Ja Ja - Ja -

MotionClips Ja - - Ja Ja Ja Ja - - Ja -

Kinematisch FK/IK FK/IK FK/IK FK/IK FK/IK FK/IK FK/IK FK - FK/IK -

Parametrisch Laufen Laufen - - - - Laufen - - - Ja

Dynamisch - - - - - - - - - - Ja

KI Techniken - - - - - - - - - - Ja

MOCAP Verarbeitung

Import Ja Ja Ja Ja Ja Ja Ja Ja - Ja Ja

Retarget Ja - - Ja - Ja - - - Ja -

Bearbeitung - - - - - - - - - Ja -

Lippensynchrone Gesichtsanimtion

MOCAP - - - - - - - - - Ja -

Audio - - - - - - - - - Ja -

Erweiterbarkeit

SDK Ja - - Ja Ja Ja - - - Ja -

Skript Ja Ja - Ja Ja Ja Ja - - Ja -

Betriebssysteme

Windows Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja Ja

MacOS X - Ja Ja Ja Ja Ja Ja Ja Ja Ja -

Linux - Ja - Ja - Ja - - Ja - -

Preis (in Euro)

Standard 4.930 0 249 690 690 2.434 220 0 0 3.764 8.995

Maximaler Umfang - - 549 3.229 - 8.524 - - - - -

Schulversion 116 - - 139 225 290 172 - - 174 895

Tabelle 2.1: Programme zur Modellierung und Animation von Avataren


Die angegebenen Preise wurden Anfang November 2006 erfasst, sind aber Schwankun-gen unterworfen und sollten hier nur als Anhaltspunkte angesehen werden. Für vieleProdukte werden auch spezielle Schulversionen angeboten, die dem Funktionsumfangder normalen Produkte entsprechen. Abgesehen von 3D Studio Max können diese auchzeitlich uneingeschränkt genutzt werden. Bei 3D Studio Max ist die Laufzeit auf zweiJahre beschränkt. Schulversionen sind deutlich günstiger als die Standardversionen,dürfen aber normalerweise nicht für kommerzielle Anwendungen verwendet werden.

Die Tabelle und auch aktuelle Film- und Spielproduktionen zeigen, dass kommerzielleund OpenSource Programme so weit entwickelt sind, dass eine anspruchsvolle Model-lierung und Animation von Avataren möglich sind. Auf der anderen Seite gibt es keinProgramm, welches alle Funktionen in sich vereint. In der Praxis werden daher oftmehrere Programme in einem Projekt eingesetzt, beispielsweise Maya für die Modellie-rung und das Rendering und MotionBuilder für die Animation. Diese Zusammenarbeitwird durch gemeinsame Datenformate möglich. Im folgenden Abschnitt sollen daherDatenformate betrachtet werden, die für den Austausch von Avatardaten relevant sind.

2.6 Vorhandene Datenformate für Avatare

Im Bereich der 3D Gra�k wurde eine ganze Reihe von Datenformaten entwickelt. Meistsind dies proprietäre Formate, die nur von den jeweiligen Anwendungen gelesen werdenkönnen. Es gibt jedoch auch Datenformate, die von mehreren Programmen verarbei-tet werden können und sich somit für den Datenaustausch eignen. Ein Nachteil dieserFormate ist aber oft, dass diese - im Gegensatz zu den proprietären Formaten - nureinen Teil der Informationen transportieren können. Einige Formate, wie das weit ver-breitete Wavefront OBJ Format, können beispielsweise nur Geometrieinformationentransportieren, während das BioVision BVH Format nur skelettbasierte Animations-daten speichern kann. Daher wird in den folgenden Abschnitten darin unterschieden,welche Daten mit den Formaten gespeichert werden können.

2.6.1 Datenformate für die Speicherung des Modells

Das 3DS Format [30] war ursprünglich das Format von Autodesk 3D Studio, einerMS-DOS Anwendung. Mittlerweile kann es aber auch von vielen anderen Programmengelesen und geschrieben werden und hat sich so als Austauschformat etabliert. DasFormat ist sehr komplex und kann neben der Geometrie von Objekten auch Transfor-mationen und hierarchische Beziehungen der Objekte speichern. Änderungen in denTransformationen können als Keyframes abgelegt werden, wodurch das Format auchAnimationen speichern kann. Die Komplexität des Formats ist wahrscheinlich auchein Grund dafür, dass der Datenaustausch mit 3DS nicht immer problemlos verläuft.Typische Defekte sind falsch rekonstruierte Hierarchien, sowie gekürzte Texturnamen,da viele Programme die Dateinamen der Texturen auf MS-DOS Konventionen 1 zu-rechtstutzen. Das Format kennt keine skelettbasierte Animation und kein Morphing,weswegen es nur für die Speicherung des Avatar-Modells verwendet werden kann.

1MS-DOS Konvention für Dateinamen: Acht Buchstaben für Dateinamen und drei Buchstaben fürdie Dateiendung.


Wavefront OBJ Dateien [31] können Objekte bestehend aus Linien, Polygonen undFreiform Kurven und Flächen speichern. Das Format ist ASCII basiert und kann dahermit einem beliebigen Texteditor eingesehen werden. OBJ Dateien speichern nur Infor-mation über die Geometrie von Objekten. Materialien werden in separaten Dateien mitder Endung �.mtl� gespeichert. Auch dieses Format wird von sehr vielen Programmenunterstützt und eignet sich daher als Austauschformat. Da das Format auch relativeinfach aufgebaut ist, lässt es in der Regel einen problemlosen Datenaustausch zu.

Eine weitere Alternative für den Austausch von 3D Informationen ist die �VirtualReality Modeling Language� (VRML) [90, 102]. Sie ist eine Beschreibungssprache für3D-Szenen, deren Geometrien, Ausleuchtungen, Animationen und Interaktionsmöglich-keiten. Ursprünglich als 3D-Standard für das Internet entwickelt, wird das Format auchvon den meisten 3D-Modellierungsprogrammen unterstützt. Wie das Wavefront OBJ-Format werden die Daten als ASCII Text abgelegt. VRML Szenen werden aus mehre-ren Knoten zusammengesetzt, die in einer Baumstruktur angeordnet werden. Es gibtverschiedene Knotentypen wie gra�sche Primitive (Quader, Zylinder, Kugel), Polygon-�ächen, Transformationen und Interpolatoren. Mit letzteren können auch Animatio-nen realisiert werden. NURBS Flächen gehören nicht zum Standard, können aber überPROTO-Knoten realisiert werden. VRML unterstützt keine skelettbasierte Animation.Dadurch kann es in diesem Fall ebenfalls nur für die Speicherung des Avatar-Modellsverwendet werden.

2.6.2 Datenformate für die Speicherung von Animationen

Hersteller von MOCAP Hardware haben eine ganze Reihe von proprietären Formatenfür die Speicherung der aufgezeichneten Bewegungen entwickelt. Von diesen Formatenist das BVH-Format (Biovision Hierarchy) besonders weit verbreitet und eignet sichdaher für den Datenaustausch. Das Format wird im ASCII Text gespeichert, wobeieine Datei aus zwei Blöcken besteht.

Im ersten Block wird eine Skeletthierarchie beschrieben. Hier werden auch so genann-te Kanäle de�niert, mit denen die Hierarchie animiert werden kann. Für die Wurzelder Hierarchie werden üblicherweise drei Translations- (X, Y, Z) und Rotationskanäle(XRot, YRot, ZRot) de�niert. Alle übrigen Elemente haben drei Rotationskanäle.

Im zweiten Abschnitt werden für jeden Kanal die Animationsdaten de�niert. Bei Trans-lationskanälen sind dies Positionsangaben, während für Rotationskanäle Drehwinkelangegeben werden. Da das Format nur skelettbasierte Animationen speichern kann,wird es in der Regel auch nur für Körperanimationen eingesetzt.

2.6.3 Datenformate für die Speicherung von Modell und Ani-mation

Die folgenden Formate können sowohl Avatar Modelle, als auch deren Animation spei-chern. Von diesen Formaten ist das COLLADA-Format die neuste Entwicklung. COL-LADA (COLLAborative Design Activity) [44, 94] de�niert ein XML Schema, welchesfür den Datenaustausch zwischen 3D Anwendungen geeignet ist. Das Format wurdezunächst von Sony Computer Entertainment als o�zielles Datenformat der PlayStati-on 3 und PlayStation Portable entwickelt. Es wurde dann von der Khronos Gruppe,


einem OpenSource Konsortium, übernommen. Zusammen mit Sony arbeiten mehrereFirmen wie Autodesk, Avid Technology und Criterion Software an dem Standard, umeinen möglichst vollständigen Datenaustausch realisieren zu können. Als universellesDatenformat unterstützt es Morphing und skelettbasierte Animation und eignet sichdaher auch für Avatare.

Das FBX (Filmbox) [7] Format existiert bereits seit einigen Jahren und ist ein plattfor-munabhängiges 3D-Authoring- und Austauschformat. Autodesk verteilt das FBX-SDKkostenlos, weshalb das Format von einer steigenden Anzahl von 3D Anwendungen un-terstützt wird. Ursprünglich als Datenformat für MotionBuilder entwickelt, kann esumfangreiche Geometrie- und Animationsdaten speichern. Es ist daher besonders fürdie Speicherung von Avataren geeignet.

Während die beiden vorhergehenden Formate ursprünglich von Firmen als proprietäreFormate entwickelt wurden, ist das H-Anim Format das Ergebnis der Arbeiten der�Humanoid Animation Working Group� [37] des Web3D Konsortiums. Es wurde alsStandard für die Repräsentation von Avataren in VRML Szenen entwickelt und soll dieErstellung, Animation und den Datenaustausch von Avataren erleichtern. Jeder Avat-ar wird aus Segmenten (wie Ober- und Unterarm), sowie Gelenken (z.B. Ellenbogen)aufgebaut. Durch Änderungen der Gelenkwinkel kann der Avatar animiert werden. DieSegmente können entweder durch VRML Primitive oder Polygon�ächen repräsentiertwerden. H-Anim Avatare entsprechen daher Starrkörpermodellen, weshalb das Formatnicht mehr zeitgemäÿ ist. Es stellt aber einen der wenigen Versuche dar, ein standar-disiertes Format für den Austausch von Avatar Modellen zu etablieren.

2.6.4 Gegenüberstellung der Datenformate

Tabelle 2.2 fasst die Eigenschaften der Datenformate zusammen. Auch hier wurdendiejenigen Eigenschaften für den Vergleich herangezogen, die für Modellierung undAnimationen von Avataren relevant sind (siehe Kapitel 2.3 und 2.4). Die Betrachtungder Programme, die die jeweiligen Formate unterstützen, beschränkt sich auf die Aus-wahl aus Kapitel 2.5. Auch wenn diese Auswahl nicht repräsentativ ist, kann man docheine Tendenz über die Verbreitung der Formate ablesen.

Obwohl die beiden Formate 3DS und OBJ sehr weit verbreitet sind, hat die Erfahrunggezeigt, dass der Datenaustausch über das OBJ Format in der Regel problemloser ist.Durch seine weite Verbreitung ist das BVH Format für die Speicherung reiner Animati-onsdaten besonders geeignet. Bei den Komplettformaten emp�ehlt sich die Verwendungdes FBX Formats. Da das FBX-SDK kostenlos verfügbar ist, ist hier auch mit einerzunehmenden Unterstützung zu rechnen. In Zukunft könnte noch das COLLADA For-mat interessant werden, da es auf der einen Seite zwar ähnlich leistungsfähig wie dasFBX Format ist, auf der anderen Seite aber nicht von der zukünftigen Strategie einesHerstellers abhängig ist.

2.7 Vorhandene Echtzeit Avatar-Systeme

Bei den vorhandenen Systemen, die eine Animation von Avataren in Echtzeit ermögli-chen, kann zwischen Komplettsystemen und spezialisierten Animations Toolkits unter-schieden werden. Komplettsysteme wie Quest3D [1], Unreal 3 Engine [83] oder Source


3DS

OBJ

VRML

BVH

COLLADA

FBX

H-Anim

Modellierung

Polygon�ächen Ja Ja Ja - Ja Ja Ja

Parametrische Flächen - Ja Ja - Ja Ja Ja

Unterteilungs�ächen - - - - - - -

Implizite Flächen - - - - - - -

Texturen

Farbe Ja Ja Ja Ja Ja Ja

Transparenz Ja Ja Ja Ja Ja Ja

Bump-Map Ja Ja Ja Ja Ja Ja

Animation

Starrkörper Ja - Ja - Ja Ja Ja

Morphing - - - - Ja Ja -

Skelettbasiert - - - Ja Ja Ja -

Unterstützt von ...

3D Studio Max Ja Ja Ja Ja Ja Ja -

Blender Ja Ja Ja Ja Ja - -

Carrara Ja Ja Ja Ja - Ja -

Cinema 4D Ja Ja Ja Ja - - -

Lightwave 3D Ja Ja Ja Ja - - -

Maya Ja Ja Ja Ja Ja Ja -

Poser Ja Ja - Ja - - Ja

Daz Studio - Ja - Ja - - -

MakeHuman - Ja - - - - -

MotionBuilder Ja Ja - Ja - Ja -

Endorphin - - - Ja - Ja -

Verbreitung ++ ++ + ++ o + o

Tabelle 2.2: Datenformate für Avatare


(a) DI-Guy Motion Editor [11] (b) Emotion Studio [55]

Abbildung 2.21: Editoren von Echtzeit Avatar-Systemen

Engine [84] beschränken sich nicht nur auf die Charakter Animation, sondern ermög-lichen die Realisierung kompletter 3D Anwendungen. Alle Programme unterstützenskelettbasierte Animation. Die beiden letzteren unterstützen auch explizit Gesichtsani-mation. Als Komplettsysteme scheiden sie jedoch für die folgenden Betrachtungen aus,da der Fokus auf der Integration von Avataren in selbst entwickelten Echtzeit Simula-tionen liegt. Im folgenden sollen daher existierende Toolkits betrachtet werden, die ineigene Anwendungen eingebettet werden können.

Cal3D [14] ist ein in C++ implementiertes, skelettbasiertes 3D Animationssystem undwird in vielen OpenSource Projekten eingesetzt. Das System besteht im wesentlichenaus einer Bibliothek und einigen Export-Plugins für 3D Modellierungssoftware wie 3DStudio Max, Blender und Milkshape. Die Bibliothek ist Plattform und Gra�k-API un-abhängig implementiert. Sie kann daher sowohl unter Microsoft Windows als auch unterLinux eingesetzt werden. Die Bibliothek stellt alle Routinen bereit, um skelettbasier-te Modelle zu laden und zu animieren. Die gra�sche Darstellung des Modells ist demAnwendungsprogramm überlassen, d.h. es existiert keine direkte Abhängigkeit zu ei-nem Gra�k API wie OpenGL oder DirectX. Cal3D unterstützt Morphing, so dass dieseTechnik zur Gesichtsanimation eingesetzt werden kann. Die Steuerung der Animationmuss aber vom Anwendungsprogramm realisiert werden.

DI-Guy [12] der Firma Boston Dynamics ermöglicht die Einbindung von Avataren ineigene Anwendungen. Das Toolkit wird in zivilen und militärischen Trainingssimulatio-nen eingesetzt. Die Darstellung kann sowohl mit DirectX, als auch OpenGL erfolgen.Das DI-Guy API erlaubt den vollen Zugri� auf einen Avatar, wodurch dieser von einemAnwendungsprogramm gesteuert werden kann. Gesichtsanimation wird unter Verwen-dung von Morphing realisiert. Das Toolkit wird zusammen mit Avatar Modellen undeiner Animationsbibliothek ausgeliefert. Über das Programm �DI-Guy Motion Editor�[11], welches auch MOCAP Daten importieren kann, lässt sich die Animationsbiblio-thek erweitern.

EMotion FX [55] ist ein Echtzeit Charakter Animationssystem und wird in mehrerenSpieleproduktionen eingesetzt. Es erlaubt die Integration von interaktiven, lebensech-ten Avataren in eigene Anwendungen. Gesichtsanimation kann sowohl mit skelettba-sierter Animation, als auch mit Morphing realisiert werden. Das Paket unterstütztauch lippensynchrone Animation mit Sprachdateien. Dabei werden versteckte MarkowModelle zur Erkennung der Phoneme eingesetzt. Die Animation der Avatare wird mit


inverser Kinematik und so genannten Controllern unterstützt. Controller ermöglichendie Realisierung von interaktiven Bewegungen wie beispielsweise �LookAt�, bei der derAvatar immer automatisch in eine bestimmte Richtung schaut. In das Toolkit kannauch eine Physik-Engine integriert werden, mit der Fallbewegungen simuliert werdenkönnen. Das Programm �EmotionStudio� ist Bestandteil des Toolkits und erlaubt dieErzeugung eigener Gesichts- und Körperanimationen. Auÿerdem werden Plugins für3D Studio MAX und Maya mitgeliefert, so dass diese Programme für die Modellierungund Animation der Avatare eingesetzt werden können.

Replicant Body [88] ist ein OpenSource Toolkit auf Basis von Cal3D. Es erweitertCal3D um eine Warteschlange für Animationen mit niedriger Priorität, sowie die Mög-lichkeit, bestehende Animationen zu neuen Animationen zu kombinieren. Zum Rendernder Avatare setzt das Programm OpenSceneGraph - ein plattformübergreifendes Echt-zeitgra�k Toolkit - ein. Das Toolkit ist Bestandteil des Coloseum3D Rahmenwerks desVRlab der Umeå University in Schweden. Es wird auch von der Delta3D [21] Simu-lationsumgebung eingesetzt, welche in mehreren Projekten des US Militärs verwendetwird.

Sarge [22] von DnS Development unterstützt ebenfalls skelettbasierte Animation undMorphing. Modelle und Animationen können mit Lightwave 3D erstellt und direkt mitdiesem Toolkit verwendet werden. Wie das EMotion FX Toolkit unterstützt Sarge auchPhysiksimulationen für Fallbewegungen.

Tabelle 2.3 fasst die Eigenschaften der Toolkits zusammen. Alle unterstützen Morphingund skelettbasierte Animation. Die Wiedergabe von gegebenen Keyframe-Animationengehört ebenfalls zum Standard. MOCAP Daten werden von den Systemen nicht direktunterstützt, können aber in den Modellierungsprogrammen eingeladen und für die Ani-mation eingesetzt werden. Bei vielen Toolkits werden herkömmliche 3D Modellierungs-programme eingesetzt, die in Kombination mit einem Export Plugin Modell- und Ani-mationsdaten erzeugen können. Bei DI-Guy und EmotionFX existieren auÿerdem nocheigene Editoren. Wenn physikalische Simulationen unterstützt werden, so beschränkensie sich auf Fallbewegungen.


Cal3D

DI-Guy

EmotionFX

ReplicantBody

Sarge

Animation

Morphing Ja Ja Ja Ja Ja

Skelettbasiert Ja Ja Ja Ja Ja

Animationstechniken

Keyframing Ja Ja Ja Ja Ja

Kinematisch FK FK FK/IK FK FK

Dynamisch - - Ja - Ja

MOCAP Ja Ja Ja Ja Ja

Lippensynchrone Animation

Audio - - Ja - -

Modellierung und Animation

Eigener Editor - Ja Ja - -

3DS Max Export Ja - Ja Ja -

Blender Export Ja - - Ja -

Lightwave Export - - - - Ja

Maya Export Ja - Ja Ja -

Gra�k API

DirectX Ja Ja Ja - Ja

OpenGL Ja Ja Ja - Ja

OpenSceneGraph Ja Ja - Ja -

Betriebssysteme

Windows Ja Ja Ja Ja Ja

Linux Ja Ja - Ja -

Preis (in Euro)

Standard 0 k.A. k.A. 0 1.750

Schulversion 0 - - 0 150

Tabelle 2.3: Echtzeit Avatar-Systeme


Kapitel 3

Konzept des Avatar-Systems

Ausgehend von der Problemstellung aus Kapitel 1 soll im folgenden ein Konzept zurRealisierung eines Avatar-Systems für das �Interactive Content System� (ICS) entwi-ckelt werden. Dazu werden zunächst Anforderungen an ein solches System formuliert,auf deren Basis mögliche Lösungswege diskutiert werden. Das Kapitel schlieÿt mit einerDarstellung der Gesamtarchitektur.

3.1 Anforderungen an das Avatar-System

Die Integration von Avataren in das ICS erfordert ein Konzept, welches die gesamteProzesskette, von der Modellerstellung bis zur animierten Ausgabe in der CasCave,abdecken kann. Die Abläufe sollen dabei so konzipiert werden, dass die anvisierte Nut-zergruppe in die Lage versetzt wird, Avatare im ICS einsetzen zu können. Bei dieserNutzergruppe handelt es sich um Fachanwender, die Avatare für Trainingssimulatio-nen und Visualisierungen benötigen. Bei diesen werden Grundkenntnisse in der 3DModellierung und Animation, sowie Programmierkenntnisse vorausgesetzt.

Unmittelbar ergeben sich hieraus folgende Anforderungen:

• Einfache Modellierung von Avataren

• Änderbares Aussehen von Avataren

• Realistische Animation von Avataren

• Möglichkeit zur Gesichtsanimation und Sprachausgabe

• Bereitstellung eines Avatar API zur Steuerung der Avatare in Anwendungen

• Bereitstellung einer Lösung zum �Rapid Prototyping� und zur �exiblen Steuerungder Avatare

• Darstellung und Animation in Echtzeit

• Darstellung der Avatare in der CasCave

Mittelbar ergeben sich folgende Anforderungen:

47

48 KAPITEL 3. KONZEPT DES AVATAR-SYSTEMS

• Einbeziehung vorhandener Anwendungen und Lösungen zur Realisierung des Sys-tems

• Unterstützung mehrerer Betriebssysteme

Ausdrücklich nicht durch das System abgedeckt werden die Simulation von virtuellen,autonomen Menschen, sowie die biomechanisch korrekte Simulation des menschlichenKörpers. Die Simulation von virtuellen, autonomen Menschen würde die Implemen-tierung von KI Technologien bedeuten, die nicht Bestandteil dieser Arbeit sind. Einvorhandenes KI System könnte jedoch auf das Avatar-System zur Darstellung der Avat-are zurückgreifen.

Biomechanisch korrekte Simulationen werden beispielsweise in Ergonomieuntersuchun-gen benötigt. Diese gehören jedoch nicht zu den beabsichtigten Anwendungen des ICS,weshalb auch bei den Avataren auf eine exakte biomechanische Modellierung verzichtetwerden kann.

Im folgenden wird genauer auf die oben angegebenen Anforderungen und deren Lösungeingegangen. Da die beiden mittelbaren Anforderungen Ein�uss auf mögliche Lösungender unmittelbaren Anforderungen haben, werden diese zuerst diskutiert. Hieran schlieÿtsich die Besprechung der übrigen Anforderungen.

3.2 Einbeziehung vorhandener Anwendungen und Lö-sungen

Die Abschnitte 2.3 und 2.4 haben gezeigt, dass bereits umfangreiche Forschung auf demGebiet echtzeitanimierter, dreidimensionaler Avatare betrieben wurde. Konkrete Imple-mentierungen sind jedoch oft nicht verfügbar, so dass Eigenimplementierungen auf Ba-sis dieser Forschungsergebnisse notwendig werden würden. Andererseits hat Abschnitt2.5 gezeigt, dass sowohl im kommerziellen Sektor, als auch im OpenSource-Bereich,eine Reihe leistungsfähiger 3D Modellierungs- und Animationswerkzeuge existiert.

Neben der Unterstützung gängiger Modellierungs- und Animationstechniken haben diemeisten dieser Programme den Vorteil, dass sie bereits eine breite Nutzerbasis haben.Es ist daher wahrscheinlicher, Nutzer solcher Programme zu �nden, die dann Inhal-te für das Avatar-System erstellen können. Einige dieser Programme haben auÿerdemgezeigt, dass Anwender mit Grundkenntnissen in der 3D Modellierung bereits in derLage sind, akzeptable Ergebnisse zu erzielen. Insbesondere vor dem Hintergrund, Ent-wicklungszeiten für das System möglichst gering zu halten, emp�ehlt sich daher derEinsatz von verfügbaren 3D Anwendungen.

3.2.1 Integration von 3D Anwendungen durch Dokumentationvon Arbeitsabläufen

Bei dem Einsatz vorhandener 3D Anwendungen entsteht oft der Wunsch, die Vorzügeverschiedener Programme miteinander kombinieren zu können. Beispielsweise könntedie interpolierende Modellierung von Poser mit den Möglichkeiten zur Kleidungserstel-lung in 3D Studio Max und den Animationsmöglichkeiten von MotionBuilder verknüpft

KAPITEL 3. KONZEPT DES AVATAR-SYSTEMS 49

werden. Theoretisch ist eine solche Zusammenarbeit über gemeinsame Dateiformatemöglich. In der Praxis gibt es jedoch immer wieder Fallstricke, die eine reibungsloseZusammenarbeit verhindern. Hierzu gehören missinterpretierte Material- und Geome-trieinformationen ebenso wie unterschiedliche Skalierungen und Koordinatensysteme.Oft hängen solche Fehler von falschen Ex- oder Importeinstellungen, beziehungsweiseden Bearbeitungsreihenfolgen in den Programmen ab. Für reproduzierbare Ergebnissemüssen daher Arbeitsabläufe dokumentiert werden.

Die Dokumentation der Arbeitsabläufe sollte leicht verständlich sein. Hierzu bieten sichgra�sche Notationen an, wobei zum besseren Verständnis auf bestehenden Standardsaufgebaut werden sollte. Es existieren mehrere standardisierte Möglichkeiten, Arbeits-abläufe gra�sch wiederzugeben. Hierzu gehören Flussdiagramme, die �Business ProcessModeling Notation� (BPMN), sowie UML Aktivitätsdiagramme.

Flussdiagramme werden für die gra�sche Darstellung sowohl von Programmabläufen,als auch von anderen Prozessen und Tätigkeiten eingesetzt [96]. Der Symbolumfangfür Computerprogramme ist in der DIN 66001 genormt und enthält u.a. Symbole fürOperationen, Unterprogramme, Verzweigungen sowie Ein- und Ausgaben.

Die BPMN ist eine standardisierte gra�sche Notation, um Geschäftsprozesse darzustel-len [43, 13]. Sie wurde von der �Business Process Management Initiative� entwickeltund wird seit 2005 von der �Object Management Group� (OMG) gep�egt. Die BPMNverfolgt das Ziel, eine einheitliche, leicht zu verstehende Notation für alle Anwender -vom Analysten, über Entwickler bis zum Endanwender - bereitzustellen. Sie erweitertherkömmliche Flussdiagramme um Konzepte wie Ereignisse, Synchronisationsmecha-nismen und Schwimmbahnen (swimlanes). Letztere ermöglichen eine Gruppierung vonAktivitäten nach Organisationseinheiten.

UML 2 Aktivitätsdiagramme gehören zu der Kategorie der UML Verhaltensdiagram-me und werden zur Beschreibung der dynamischen Aspekte eines Software-Systemsverwendet [92]. Zielgruppe der Diagramme sind daher - im Gegensatz zur BPMN -vornehmlich an der Entwicklung beteiligte Personen. Aktivitätsdiagramme erweiternFlussdiagramme um ähnliche Konzepte wie die BPMN, verwenden jedoch eigene gra�-sche Symbole. Von ihrer Mächtigkeit her sind beide, BPMN und Aktivitätsdiagramme,nahezu identisch [218].

Alle drei Notationen sind von ihren Möglichkeiten her gleichermaÿen zur Dokumentati-on von Arbeitsabläufen geeignet. Um eine möglichst breite Nutzergruppe zu erreichen,scheint der Einsatz von Flussdiagrammen, bzw. der BPMN angebrachter als der Einsatzvon Aktivitätsdiagrammen. Hinter der BPMN steckt auÿerdem die Idee, Prozesse zuautomatisieren. Hierzu existieren Möglichkeiten, um BPMN Diagramme in die �Busi-ness Process Execution Language� (BPEL) [107] zu übersetzen, mit der Web-Dienstekoordiniert werden können. Eine Automatisierung könnte auch für die Arbeitsabläufezur Erstellung und Animation von Avataren nützlich sein. Hierzu ist die BPEL zwarnicht geeignet, aber eine spätere Automatisierung auf Basis von BPMN Diagrammenwäre trotzdem denkbar. Da die Automatisierung mit ein Designkriterium für die BPMNwar, wird diese Notation zur Dokumentation ausgewählt.

Bei der praktischen Arbeit hat sich herausgestellt, dass die reine Bearbeitungsreihen-folge nicht ausreichend ist, um die Ergebnisse von Arbeitsabläufen reproduzieren zukönnen. Die BPMN-Diagramme müssen daher um folgende Informationen ergänzt wer-den:


Kurzbeschreibung: Die Kurzbeschreibung soll einen kompakten Überblick über einenArbeitsablauf liefern.

Anwendungen: In diesem Abschnitt werden die beteiligten Anwendungen aufgeführt.Neben den Programmen selbst sollten auch die Versionsnummern samt Release-nummer angegeben werden, da der Funktionsumfang bei verschiedenen Versions-und Releasenummern schwanken kann. Hierdurch kann es auch passieren, dassein Arbeitsablauf nicht mit jeder vorhandenen Versionsnummer funktioniert. Mitden angegebenen Versionen sollte er jedoch funktionieren.

Vorbedingungen: Die nachfolgende Vorgehensweise ist oft von dem verwendetenDatenformat, bzw. dem Zustand der Daten (z.B. reine Geometrie, Modell mitSkinning-Informationen) abhängig und muss daher dokumentiert werden. Hierzugehören ggf. auch Programmkon�gurationen, beispielsweise Skalierungseinstel-lungen. Diese sollten daher ebenfalls dokumentiert werden.

Nachbedingungen: In den Nachbedingungen wird beschrieben, in welchem Zustanddie Daten nach der Bearbeitung sind. Werden Daten gespeichert, sollte hier auchdas Datenformat angegeben werden.

Arbeitsablauf: In diesem Abschnitt folgt die gra�sche Dokumentation der benötigtenArbeitsschritte. Hierzu gehört die Dokumentation von aufzurufenden Programm-funktionen, eventuell benötigter Einstellungen, sowie Anweisungen im Freitext.Da auch bedingte Arbeitsschritte und Alternativen möglich sind, sollten dieseauch dokumentiert werden. Im- und Exporteinstellungen müssen in diesem Ab-schnitt ebenfalls dokumentiert werden, da falsche Parameter die folgenden Ar-beitsschritte negativ beein�ussen können.

Ergänzende Hinweise: Gelegentlich werden detaillierte Hinweise oder Bildschirm-fotos benötigt, um Arbeitsschritte besser darzustellen. Zwar könnten diese auchin die Diagramme integriert werden, jedoch können diese dadurch leicht mit In-formationen überfrachtet werden. Daher werden ergänzende Hinweise in einemnachfolgenden Abschnitt aufgeführt, wo sie bei Bedarf nachgelesen werden kön-nen.

Durch gleiche Vor- und Nachbedingungen lassen sich mehrere Arbeitsabläufe kombinie-ren. Hierdurch können komplexe Bearbeitungsgänge in mehrere einfache Arbeitsabläufezerlegt werden. Dies erlaubt unter Umständen auch eine Wiederverwendung bestimm-ter Arbeitsabläufe, wodurch der Aufbau von Bibliotheken ermöglicht wird.

3.2.2 Implementierung des Avatar-Systems auf Basis vorhan-dener Komponenten

In der Form, in der vorhandene Anwendungen für die Erstellung und Animation derAvatare verwendet werden, sollen auch bei der Entwicklung des Laufzeitsystems mög-lichst vorhandene Komponenten eingesetzt werden. Da das Laufzeitsystem je nach An-wendung auch an Dritte weitergegeben werden muss, ergeben sich hierdurch spezielleAnforderungen an die Lizenzen der eingesetzten Komponenten.


Kommerzielle Komponenten erfordern bei der Distribution des Laufzeitsystems in derRegel den Abschluss spezieller Lizenzverträge, die sich in höheren Kosten niederschla-gen. Da diese vermieden werden sollen, wird - sofern möglich - auf OpenSource Kom-ponenten zurückgegri�en. Da auÿerdem der Quelltext o�en liegt, kann solche Softwareden eigenen Vorstellungen angepasst werden. OpenSource bedeutet jedoch nicht, dasssolche Software nach belieben eingesetzt und verändert werden darf. Vielmehr unterlie-gen auch OpenSource Komponenten speziellen Lizenzen, die die Rechte und P�ichtender Anwender regeln.

In den letzten Jahren ist eine ganze Reihe solcher Lizenzen entstanden (siehe [80]).Häu�ges gemeinsames Merkmal ist, dass sie einen Haftungsauschluss enthalten, d.h. dieUrheber der Komponenten können nicht für Fehler und resultierende Schäden haftbargemacht werden. Erlaubt ist in aller Regel die Weiterverteilung des Quelltextes undder erzeugten Programme und Bibliotheken. Die Lizenzen unterscheiden sich aber inden Bedingungen, die an den Einsatz und die Weiterverteilung geknüpft sind.

Eine weit verbreitete OpenSource Lizenz ist die �GNU Public License� (GPL) [33, 109].Diese gewährt jedermann das Recht, Software einzusetzen und zu verändern. Wird Soft-ware vertrieben, so muss der Quelltext mitgeliefert oder gegen Anfrage zum Selbstkos-tenpreis ausgeliefert werden. Der Empfänger des Quelltextes hat wiederum alle Rechte,die sich aus der GPL ergeben, d.h. auch er darf die Software uneingeschränkt verwen-den, verändern und verteilen. Programme, die GPL Komponenten einsetzen, unterlie-gen ebenfalls automatisch der GPL. Dies gilt auch, wenn ein Programm GPL lizen-zierte Bibliotheken einsetzt. Dies kann zu einem Problem werden, wenn der Quelltexteines Programms aus verschiedenen Gründen - z.B. Geheimhaltungsabkommen mitProjektpartnern - anderen nicht zugänglich gemacht werden soll. Es gibt daher eineabgeschwächte GPL, die �Lesser GNU Public License� (LGPL) [34, 110]. Eine LGPLBibliothek kann auch in Programmen eingesetzt werden, ohne dass diese automatischder GPL unterliegen und sich die P�icht zur Verö�entlichung des Quelltextes ergibt.Nur wenn an der Bibliothek selbst Änderungen vorgenommen werden, müssen dieseÄnderungen auch anderen zugänglich gemacht werden.

Ebenfalls weit verbreitet ist die �Berkeley Software Distribution� (BSD) Lizenz, diean der �University of California, Berkeley� entstanden ist [32, 106]. Auch diese Lizenzerlaubt die freie Verwendung, Veränderung und Verbreitung. Veränderte und abgelei-tete Programme müssen jedoch nicht im Quelltext bereitgestellt werden. Es darf nurnicht der Copyright-Vermerk des ursprünglichen Programms entfernt werden. Ähnlichverhält es sich auch bei der �Massachusetts Institute of Technology� (MIT) Lizenz, vonder die BSD Lizenz abgeleitet wurde [35, 111].

Der Einsatz des Avatar-Systems soll keine Projekte gefährden, bei denen eine O�enle-gung des Quelltextes nicht möglich ist. Daher dürfen nur externe Komponenten ausge-wählt werden, deren Lizenzen ein solches Vorgehen erlauben. Hierzu gehören die LGPL,BSD und MIT Lizenzen. GPL lizenzierte Komponenten dürfen nicht eingesetzt werden.

3.3 Unterstützung mehrerer Betriebssysteme

Das ICS soll sowohl unter Linux als auch unter Windows einsetzbar sein. Dies er-gibt sich daraus, dass die in der CasCave eingesetzte VR-Software auf einem Linux


Cluster läuft. Andererseits sind Windows Systeme weit verbreitet und die bevorzugtePlattform bei Einzelplatzanwendungen. Das Avatar-System muss daher ebenfalls beideBetriebssysteme unterstützen.

Da beide Betriebssysteme sich in ihren Schnittstellen zur Anwendungsentwicklungunterscheiden, stellt dies besondere Anforderungen an die Entwicklung des Avatar-Systems. Um die Kompilierung auf unterschiedlichen Betriebssystemen zu ermöglichen,ist üblicherweise eine Anpassung an die verschiedenen APIs notwendig. Dies führt zuerhöhtem Entwicklungs- und Wartungsaufwand. Um diesen Aufwand zu verringern,sollen stattdessen Bibliotheken eingesetzt werden, die eine Abstraktion von dem ver-wendeten Betriebssystem ermöglichen. Hierdurch kann der Quelltext im Idealfall un-verändert unter beiden Betriebssystemen eingesetzt werden.

3.4 Einfache Modellierung von Avataren

Um eine einfache Modellierung zu ermöglichen und den Implementierungsaufwand ge-ring zu halten, sollen bestehende Lösungen zur Modellierung von Avataren eingesetztwerden können. Damit eine Auswahl der Programme zur Modellierung möglich wird,wird zunächst de�niert, welche Anforderungen an das Modell gestellt werden. In demanschlieÿenden Abschnitt folgt die Auswahl der Modellierungsprogramme.

In Abschnitt 3.4.3 werden auÿerdem noch Hinweise auf bestehende Modellbibliothe-ken gegeben, die ebenfalls Modelle bereitstellen, die für das Avatar-System verwendetwerden können.

3.4.1 Anforderungen an die Avatarmodellierung

Wie zu Beginn des Kapitels festgelegt, dient das Avatar-System zur Darstellung vonanimierten, humanoiden Avataren. Hierdurch können die Modelle von dem Aufbaurealer Menschen stark abstrahiert werden, so dass sich nur zwei Hauptanforderungen andie Avatar-Modelle ergeben. Zum einen müssen die Modelle in Echtzeit animierbar sein.Andererseits sollen sie in ihrer Darstellung echten Menschen möglichst nahe kommen.

In Abschnitt 2.4 wurden eine ganze Reihe von Möglichkeiten diskutiert, wie Avatareanimiert werden können. Von diesen Möglichkeiten stellen zweischichtige Modelle, dieum Morphing ergänzt werden können, den besten Kompromiss zwischen Darstellungs-qualität und dem Aufwand zur Animation und Darstellung dar.

Durch den zweischichtigen Aufbau muss zur Animation nur eine überschaubare Anzahlan Gelenken manipuliert werden. Auÿerdem werden solche Modelle von vielen beste-henden Modellierungsprogrammen unterstützt (vgl. auch Tabelle 2.1). EinschichtigeModelle sind dagegen aufgrund ihrer Darstellungsqualität nicht mehr zeitgemäÿ. Mo-delle mit mehr als zwei Schichten sind zwar näher an der Anatomie realer Menschen,jedoch werden sie nur von wenigen Programmen unterstützt und es existiert kein ein-heitliches Format zum Datenaustausch. Auÿerdem erfordern sie mehr Rechenleistungbei der Darstellung.

Mit Hilfe von Morphing kann die Gesichtsanimation realisiert werden. Morphing hatden Vorteil, dass es von gängigen Programmen unterstützt wird und sich e�zient in


Echtzeit darstellen lässt. Der Nachteil besteht in einem erhöhten Modellierungsauf-wand. Allerdings kann dieser Aufwand durch den Einsatz von 3D Scannern reduziertwerden. Bei parametrischen Animationen oder physikalisch basierenden Methoden zurGesichtsanimation taucht das gleiche Problem auf wie bei Modellen mit mehr als zweiSchichten: Sie werden von keiner verfügbaren Anwendung unterstützt.

Von den in Abschnitt 2.3 vorgestellten Möglichkeiten zur Repräsentation der Geometrieeignen sich besonders Polygon�ächen. Diese werden von jedemModellierungsprogrammunterstützt und lassen sich auÿerdem e�zient mit existierender Gra�khardware dar-stellen. Selbst wenn andere Techniken während der Modellierung eingesetzt werden,können die resultierenden Modelle immer in Polygon�ächen umgewandelt werden.

Polygonbasierte Modelle eignen sich jedoch nur bedingt für die Darstellung aller visu-ellen Eigenschaften von Menschen wie Haaren, Hautstrukturen und Gewebestrukturenvon Kleidung. Dies tri�t insbesondere dann zu, wenn die Anzahl der Polygone mög-lichst gering gehalten werden soll. So würde die Modellierung jedes einzelnen Haaresdurch Polygone eine Echtzeitdarstellung unmöglich machen.

Abhilfe können hier geeignete Texturen scha�en, mit denen die zugrunde liegende Geo-metrie komplexer erscheinen kann als sie tatsächlich ist. Eine Frisur kann so beispiels-weise durch mehrere �Haarlappen� realisiert werden, die eine vergleichsweise gerin-ge Komplexität haben können. Auf diese werden zwei Texturen aufgetragen, wobeidie Farb-Textur die Haare und ihre Farbe repräsentiert und die zweite Textur alsTransparenz-Maske durchsichtige Bereiche de�niert. Durch die Transparenz-Maske wir-ken die �Haarlappen� �ligraner und können zum Haar-Ende hin ausfransen. Auch dasAussehen der Haut kann durch eine geeignete Farb-Textur sehr gut angenähert wer-den. Zusammen mit einer Bump-Map können auÿerdem Falten realistisch dargestelltwerden.

Da sowohl dynamische Haarsimulation, als auch dynamische Kleidungssimulation zurZeit aus Performanzgründen von dem Avatar-System nicht unterstützt werden, be-schränkt sich die Modellierung daher auf die Erstellung des Skeletts und der Geo-metrie, sowie der Bindung der Geometrie an das Skelett. Auÿerdem werden passendeMaterialien in Form von Texturen benötigt.

3.4.2 Auswahl der Modellierungsprogramme

Die manuelle Modellierung glaubhafter Avatare erfordert viel künstlerisches Geschickund Erfahrung. Daher sollen vorhandene Programme oder Bibliotheken eingesetzt wer-den, wodurch die Modellierung vereinfacht werden kann. Diese Programme müssenin der Lage sein, zweischichtige, polygonbasierte Avatarmodelle zu erzeugen. WennSprachausgabe der Avatare möglich sein soll, müssen die Programme auÿerdem in derLage sein, Morph-Ziele zu verarbeiten.

Insbesondere Standardpakete wie 3D Studio Max, Blender, Cinema 4D, Lightwave undMaya unterscheiden sich erheblich in ihren Bedienkonzepten. Je nach Anwendung sinddaher für die gleiche Aufgabe unterschiedliche Bedienungsschritte notwendig. Obwohlprinzipiell alle Anwendungen für die Realisierung der Avatarmodelle eingesetzt werdenkönnten, wird daher im folgenden nur noch eine Auswahl der Programme eingesetzt,um die Übersichtlichkeit zu erhöhen und den Dokumentationsumfang zu reduzieren.


Von den in Kapitel 2.5 vorgestellten Programmen wurden 3D Studio Max, Poser undCarrara in die engere Wahl genommen.

Von den allgemeinen Modellierungsprogrammen wurde 3D Studio Max ausgewählt.Es hat einen groÿen Funktionsumfang und lässt sich �exibel erweitern. Im FachgebietTechnische Informatik existieren auÿerdem umfangreiche Modellsammlungen im Max-Format, so dass auf diesen Fundus zurückgegri�en werden kann.

Poser eignet sich besonders für die einfache Erstellung des Avatarmodells. Das Pro-gramm bietet in der Version 6 über 40 verschiedene Avatarmodelle in verschiedenenDetailstufen. Durch den Einsatz interpolierender Modellierungstechniken kann auÿer-dem eine Vielzahl von verschiedenen Avataren erzeugt werden. Unter anderem könnenso auch Morph-Ziele für die Sprachausgabe erzeugt werden. Es ist leistungsfähiger alsDAZ-Studio und die Avatare sind - im Gegensatz zu MakeHuman - bereits animierbar.

Obwohl Avatare in Poser animierbar sind, kann es nur statische Modelle ohne Skinnin-ginformationen in gängigen Formaten exportieren. Daher muss nachträglich, beispiels-weise in 3D Studio Max, ein Skelett erzeugt und per Skinning an das Modell gebundenwerden. Dieser Prozess erfordert ebenfalls viel Erfahrung, weswegen eine Vermeidungdieses Arbeitsschritts wünschenswert wäre.

Tatsächlich kann Carrara Poser Modelle inklusive Skinninginformationen importieren.Es unterstützt auÿerdem das FBX-Format, mit dem ebenfalls alle nötigen Informa-tionen transportiert werden können. Jedoch verwirft der Carrara Exporter sämtlicheMaterialinformationen, so dass nur die Geometrie inklusive Skelett und Skinninginfor-mationen gespeichert wird.

Durch eine Kombination beider Exportergebnisse kann allerdings ein vollständig ani-mierbares Modell mit allen Materialeigenschaften erzeugt werden. Dazu müssen dieSkinning-Informationen des Modells aus Carrara auf das Modell übertragen werden,welches aus Poser direkt exportiert wurde. Diese Übertragung der Skinning-Informationenkann mit den �SkinUtilities� in 3D Studio Max vorgenommen werden. Da 3D StudioMax auch Morphing unterstützt, können bei Bedarf auch Morph-Ziele zu dem Modellhinzugefügt werden. Es ist so möglich, mit den Programmen Poser, Carrara und 3DStudio Max komplett animierbare Avatarmodelle zu erzeugen. Für eine reibungsloseZusammenarbeit müssen jedoch Arbeitsabläufe entwickelt werden.

3.4.3 Verwendung von Modellbibliotheken

Eine andere Möglichkeit der Bereitstellung von Avatarmodellen für das Avatar-Systembesteht in der Verwendung von vorhandenen Modellen, wie sie beispielsweise im Inter-net bei Turbosquid [79] oder �The online 3d model library� [61] angeboten werden. DieFirma Rocketbox Studios GmbH bietet auÿerdem zwei Modellbibliotheken mit insge-samt 150 Avataren für zivile [68] und militärische [69] Anwendungsgebiete an. DieseModelle werden komplett inklusive Modell, Materialien, Skelett und Skinninginforma-tionen angeboten und können direkt in 3D Studio Max verarbeitet werden. Da 3DStudio Max in die Modellierungsabläufe integriert wird, können so auch Modellbiblio-theken verwendet werden.


Abbildung 3.1: Modell mit unterschiedlichen Texturen

3.5 Änderbares Aussehen von Avataren

Auch wenn die im vorigen Abschnitt vorgestellten Werkzeuge die Modellierung erheb-lich vereinfachen, benötigen die erforderlichen Arbeitsschritte ein bis zwei Stunden, bisein Poser-Avatar in Echtzeitsimulationen eingesetzt werden kann. Oft reichen aber auchwenige Detailänderungen aus, um ein Modell auch in anderen Szenarien einsetzen zukönnen. Denkbar wären geänderte Texturen oder der Austausch von Kleidungsstückenoder Frisuren. Mit Textur- und Modellbibliotheken können so individuelle Avatare inkurzer Zeit kon�guriert werden. Hierzu werden sowohl Bibliotheken mit Modellkompo-nenten, als auch ein Kon�gurationsprogramm benötigt.

3.5.1 Aufbau von Textur- und Modellbibliotheken

Texturen lassen sich mit üblichen Bildbearbeitungsprogrammen erstellen und modi�-zieren. Für die Änderung von Haut- und Gesichtstexturen bietet sich auÿerdem Poseran. Das Programm kann auf Basis von zwei Gesichtsfotos Texturen für Gesicht undKörper berechnen. Solange die geänderten Texturen das gleiche Layout wie die origi-nalen Texturen haben, können sie einfach ausgetauscht werden. So ist in Abbildung 3.1jeweils das gleiche geometrische Modell mit unterschiedlichen Texturen zu sehen.

Der Austausch von Kleidungsstücken lässt sich ebenfalls einfach realisieren, wenn dasAvatar-Modell aus mehreren Komponenten (Kopf, Oberkörper, Unterkörper, Arme undBeine) aufgebaut wird. Für jede Komponente können mehrere Varianten angebotenwerden, so dass je nach Bedarf ein passender Avatar kon�guriert werden kann. Alter-native Kleidungsstücke können direkt in 3D Studio Max unter Verwendung des �GarmetMaker Modi�ers� erstellt werden. Das Vorgehen ähnelt der Erstellung realer Kleidung,indem virtuelle Sto�stücke miteinander �vernäht� werden und sich an die Körperformdes Avatars anpassen. Fertige Kleidungsstücke sind auÿerdem direkt in Poser verfügbarund werden auch im Internet zum Erwerb angeboten.

Da das Avatar-System keine dynamische Kleidungssimulation unterstützt, müssen auchdie alternativen Kleidungsstücke an das Skelett gebunden werden, um eine Animationzu ermöglichen. Analog zur Modellierung ist zwar auch hier ein manuelles Skinningmöglich, sollte aber aufgrund des zeitlichen Aufwands vermieden werden. Die �SkinU-tilities� von 3D Studio Max sind andererseits nicht �exibel genug, um die Übertragung


von Skinninginformationen auf Kleidungsstücke zuzulassen, wenn diese von der origi-nalen Geometrie zu stark abweichen. Es muss daher ein Werkzeug entwickelt werden,welches eine �exiblere Übertragung ermöglicht.

3.5.2 Kon�guration von Avataren

Der Wechsel von Texturen und die Kon�guration von Komponenten kann in 3D StudioMax vorgenommen werden. Dies würde jedoch bedeuten, dass für Änderungen eine3D Studio Max Lizenz verfügbar sein muss. Im Hinblick auf Lizenzkosten erscheint esdaher sinnvoller, wenn 3D Studio Max nur für die Modellierung der Komponenten-Bibliothek eingesetzt wird. Mit Hilfe dieser Bibliothek und in Kombination mit einerKon�gurationsanwendung können dann konkrete Avatare zusammengestellt werden.Dieser �Avatar-Designer� wird ebenfalls Bestandteil des Avatar-Systems sein.

Mit Hilfe des Avatar-Designers können Avatare kon�guriert und notwendige Anpas-sungsschritte vorgenommen werden. Dabei kann festgelegt werden, aus welchen Kom-ponenten das Modell aufgebaut wird und welche Materialien verwendet werden. Einweiteres Problem, insbesondere wenn Avatarmodelle aus verschiedenen Quellen stam-men, ist eine einheitliche Skalierung und Ausrichtung der Modelle. Auch diese Einstel-lungen sollen mit dem Avatar-Designer möglich sein.

Die Kon�guration erfolgt mit einer gra�schen Benutzerober�äche. Diese wird, wie auchdie restlichen GUI-Komponenten des ICS, mit der Qt-Bibliothek von Trolltech [78]realisiert. Qt abstrahiert von dem verwendeten Betriebssystem, so dass ein einheitlicherQuelltext für alle Betriebssysteme ermöglicht wird.

Für die Kon�gurationen wird ein Dateiformat benötigt, so dass die erstellten Kon�-gurationen gespeichert und vom Laufzeitsystem geladen werden können. Kon�guratio-nen werden in einem XML-Format gespeichert. Dies hat zum einen den Vorteil, dassauf existierende XML-Parser zurückgegri�en werden kann. Auÿerdem können XML-Dateien auch mit herkömmlichen Text-Editoren verändert werden, wodurch einfacheÄnderungen auch ohne Avatar-Designer vorgenommen werden können.

3.6 Realistische Animation von Avataren

Für eine möglichst glaubhafte Darstellung ist eine realistische Animation der Avat-are notwendig. Damit die gesamte Bandbreite an verfügbaren Animationstechnikeneingesetzt werden kann, wird bei dem Avatar-System zwischen Online- und O�ine-Animation unterschieden. Animationen, die mit externen Programmen erzeugt werden,werden als O�ine-Animationen bezeichnet. Diese können zu Bewegungsbibliothekenzusammengefasst werden, wobei jeder Avatar seine eigene Bibliothek hat. Die Zusam-menstellung der Bewegungsbibliotheken erfolgt im Avatar-Designer.

Im Gegensatz zu O�ine-Animationen werden Online-Animationen zur Laufzeit desAvatar-Systems generiert. Hierzu können Bewegungen aus der Bewegungsbibliothekabgespielt werden, wobei die Möglichkeit besteht, mehrere Bewegungen miteinander zukombinieren. Beispielsweise lässt sich so eine Laufbewegung mit einer Wink-Bewegungkombinieren, um einen laufenden und winkenden Avatar darzustellen.


Laufzyklus Laufzyklus(Wiederholung)

Transition

Abbildung 3.2: Kombination von Basisbewegungen

Im folgenden werden einige Anforderungen an O�ine-Animationen formuliert. Im An-schluss folgt die Auswahl der Programme zur Generierung der Animationen. Online-Animationen werden im Zusammenhang mit dem Avatar-API erläutert.

3.6.1 Anforderungen an die Animation

Durch die Festlegung auf zweischichtige Modelle erfolgt die Animation durch Animierender internen Skelettstruktur. Betrachtet man die in Abschnitt 2.4 vorgestellten Anima-tionsverfahren, bleiben im Hinblick auf die vorgesehene Anwendergruppe nur MOCAPund parametrische Animation übrig. Eine Animation mittels Keyframing scheidet beikomplexeren Animationen aus, da hier - ähnlich wie bei der manuellen Modellierung -ebenfalls fortgeschrittene Kenntnisse notwendig sind.

Ziel der O�ine-Animation ist häu�g, kleinere Animationsfragmente zu generieren, diezur Laufzeit miteinander kombiniert werden können. Hierbei können drei Kategorienunterschieden werden. Die erste Kategorie sind so genannte Aktionen. Aktionen sindnicht wiederholende Bewegungen, beispielsweise eine Zeigebewegung mit der Hand, dasDrücken eines Knopfes, eine Fallbewegung, usw.

Zu der zweiten Kategorie gehören zyklische Bewegungen, d.h. Bewegungen, die wieder-holt abgespielt werden können. Zyklische Bewegungen werden oft für Laufbewegungeneingesetzt. Hierzu wird ein Laufzyklus, beispielsweise eine Laufbewegung, bei der derKörper von dem rechten auf das linke und wieder auf das rechte Bein verlagert wird,bereitgestellt (siehe Abbildung 3.2). Durch das Aneinanderhängen dieser Laufzyklenkann so eine beliebig lange Laufanimation erzeugt werden.

Zu der dritten Kategorie gehören Transitionen. Hierbei handelt es sich um Übergangs-bewegungen, die den Körper von der Schlusspose einer Animation in die Anfangspose


einer anderen Animation überführen. Dies kann beispielsweise der Übergang von einerstehenden Haltung in eine Laufbewegung sein, wie in Abbildung 3.2 dargestellt.

Neben dem sequenziellen Abspielen von Basisbewegungen können Bewegungen auchmiteinander gemischt werden. Dies kann asynchron und synchron erfolgen. Bei einerasynchronen Mischung wird eine zweite Animation zu einem beliebigen Zeitpunkt ineine bereits ablaufende Animation eingemischt. Dies kann eine Zeigebewegung sein,die mit einem Laufzyklus kombiniert wird. Synchrone Animationen haben die gleicheLänge und werden zum gleichen Zeitpunkt gestartet. Beispielsweise könnten verschie-dene Laufzyklen generiert werden, die verschiedene Gang-Charakteristiken (normal,beschwingt, niedergeschlagen) repräsentieren. Durch individuelle Mischungsverhältnis-se können beliebige Kombinationen dieser Bewegungen erzeugt werden.

3.6.2 Auswahl der Programme für die Animation

Die Programme für die Animation von Avataren müssen so ausgewählt werden, dass dieVerarbeitung von MOCAP Daten, sowie die Erzeugung von parametrischen Animatio-nen möglich ist. Dabei soll es mit den Programmen möglich sein, O�ine-Animationenzu erzeugen, die als Aktion, zyklische Animation oder Transition zu einer Online-Animation kombiniert werden.

Für die Verarbeitung von MOCAP Daten wurde MotionBuilder ausgewählt. Poser und3D Studio Max sind zwar auch in der Lage, MOCAP-Daten zu verarbeiten, haben abereinen geringeren Funktionsumfang. MotionBuilder bietet auÿerdem leistungsfähige ki-nematische Funktionen und kann durch Motion-Clips und den Story-Editor auch fürumfangreichere Bewegungssequenzen eingesetzt werden. Es unterstützt jedoch keineparametrische Animation. Zumindest für Laufbewegungen wird diese aber von Poserund 3D Studio Max angeboten, so dass diese durch Datenaustausch auch in MotionBuil-der weiterverarbeitet werden können. Für eine reibungslose Zusammenarbeit müssenjedoch Arbeitsabläufe entwickelt werden.

3.7 Möglichkeit zur Gesichtsanimation und Sprach-ausgabe

Durch Gesichtsanimation und lippensynchrone Sprachanimation können Avatare dieAufnahme von gesprochenen Informationen unterstützen [122, 116, 143]. Beides istdaher vor allem für die Verwirklichung von virtuellen Tutoren bedeutend.

In Abschnitt 2.4 wurden zwei Verfahren zur lippensynchronen Sprachanimation vorge-stellt, die jeweils Vor- und Nachteile haben. Sprachanimation mit vorgegebenen Audio-Daten hat den Vorteil, dass reale Sprachaufzeichnungen verwendet werden können.Demgegenüber steht ein erhöhter Speicherbedarf, da alle benötigten Audio-Daten vor-gehalten werden müssen. Prinzipbedingt eignet sich das Verfahren auch nicht für dieWiedergabe von Texten, die erst zur Laufzeit des Programms entstehen. SekundäreAnimationen, die die Gesichtsmimik beein�ussen, lassen sich ebenfalls nicht automa-tisch erzeugen. Sie müssen daher bei Bedarf manuell hinzugefügt werden.

Alle genannten Nachteile entfallen bei der Sprachanimation mit einem SprachsyntheseSystem. Allerdings hat dieses Verfahren den Nachteil, dass die erzeugte Sprache - trotz


aller Fortschritte auf dem Gebiet der Sprachsynthese - künstlich klingt. Da der Bedarfan den jeweiligen Verfahren anwendungsabhängig ist, soll das Avatar-System beideVerfahren unterstützen.

3.7.1 Anforderung an die Gesichtsanimation und Sprachaus-gabe

Die Gesichtsanimation und Sprachausgabe der Avatare sollen die lippensynchrone Ani-mation des Gesichtes und andere Animationen wie Zwinkern der Augen oder emotiona-le Gesichtsausdrücke wie Freude, Ärger, usw. ermöglichen. Diese Animationen könnendurch die Bereitstellung von Morph-Zielen realisiert werden, wodurch sich zusätzlicheAnforderungen an die Modellierung ergeben. Insbesondere für die Sprachausgabe mussauch der Mund detailliert modelliert werden, d.h. der Mund muss sich ö�nen lassenund es müssen Zähne sichtbar sein.

Lippensynchrone Sprachanimation kann dadurch realisiert werden, dass die gesproche-nen Phoneme Visemen zugeordnet werden. Hierzu wird eine Phonem-Visem Zuordnungbenötigt, die abhängig von der gesprochenen Sprache ist. Da die Avatare zunächst einedeutsche Sprachausgabe ermöglichen sollen, kann die Phonem-Visem Zuordnung aus[119] verwendet werden. In dieser Zuordnung werden 15 Viseme verwendet, weswe-gen diese bereitgestellt werden müssen. Für die Sprachausgabe zur Laufzeit muss esauÿerdem möglich sein, den gesprochenen Text zu synthetisieren.

Neben der reinen Sprachausgabe muss auch eine Steuerung von sekundären Anima-tionen möglich sein. Da sekundäre Animationen die Kommunikation zusätzlich unter-stützen sollen, müssen sie geeignet mit dem gesprochenen Text synchronisiert werdenkönnen.

3.7.2 Gesichtsanimation mit Audio-Dateien

Wie in Abschnitt 2.4.4 dargelegt, ist für die Animation mit Audio-Daten eine Analy-se des Audiostroms notwendig, mit der die verwendeten Phoneme identi�ziert werden.Hierzu kann das Programm MotionBuilder eingesetzt werden. Es besitzt ein so genann-tes �VoiceDevice�, welches mit Hilfe einer Audio-Quelle passende Viseme aktivierenkann. Diese Viseme werden in Form von Morph-Zielen de�niert, welche beispielsweisemit Poser erzeugt werden können. Sekundäre Animationen werden zwar nicht auto-matisch berücksichtigt, jedoch bietet MotionBuilder komfortable Möglichkeiten, diesemanuell hinzuzufügen. Hierdurch lassen sich komplette Gesichtsanimationen realisie-ren.

Dass die Animationen o�ine mit einem externen Programm erzeugt werden, stelltkeine Einschränkung für die Anwendung dar, da die verwendeten Audio-Daten ebenfallsauÿerhalb der Laufzeit des Avatar-Systems bereitgestellt werden müssen. In Analogie zuder Animation des Körpers wird dieses Verfahren daher im folgenden �O�ine-Gesichts-animation� genannt. Es werden somit Arbeitsabläufe benötigt, in denen die genanntenAnwendungen zur Erzeugung der Animation eingesetzt werden können.


3.7.3 Gesichtsanimation mit Text-to-Speech

Die Gesichtsanimation mit einem Text-to-Speech System kann zur Laufzeit erfolgen,weswegen sie in das Avatar-System integriert werden muss. Im Gegensatz zu der Ge-sichtsanimation mit Audio-Daten wird sie daher im folgenden �Online-Gesichtsanimation�genannt. Für die Realisierung muss der zu sprechende Text in Phoneme umgewandeltund anschlieÿend den passenden Visemen zugeordnet werden. Hierbei können die glei-chen Viseme verwendet werden, die auch bei der O�ine-Gesichtsanimation verwendetwerden.

Zusätzlich wird die Synthetisierung der Sprache benötigt. Auf dem Markt be�ndensich zwei Sprachsynthese Systeme, die für nicht kommerzielle Anwendungen kostenlosverwendet werden können. Festival [29] ist multi-lingual aufgebaut und unterstütztEnglisch und Spanisch. Das System wurde in C++ implementiert und verwendetdie �Edinburgh Speech Tools Library� für die Implementierung, sowie einen Scheme-Kommandointerpreter für die Kontrolle.

MBROLA [51] ist ein Sprachsynthesizer, der auf dem Aneinanderhängen von Diphonenbasiert. Als Eingabe verarbeitet dieser Synthesizer eine Phonemliste, die mit Hilfe einerSprachdatenbank in gesprochenen Text umgewandelt wird. Die Sprachdatenbankenwerden für mehr als 30 Sprachen angeboten, darunter auch Englisch und Deutsch.MBROLA ist jedoch kein komplettes Text-to-Speech (TTS) System, da es nur Phonemeals Eingabe verarbeiten kann. Es wird daher ein weiteres Programm benötigt, das denzu sprechenden Text in Phoneme umwandelt.

Hierzu kann Mary TTS [49] eingesetzt werden. Mary TTS wird von dem �DeutschenForschungszentrum für Künstliche Intelligenz� (DFKI) gep�egt und weiterentwickeltund ist ein komplettes Sprachsynthese-System für Englisch und Deutsch. Für dieSprachausgabe kann es sowohl Festival, als auch MBROLA einsetzen. Mary TTS istmodular aufgebaut und als Server-Anwendung implementiert. Der modulare Aufbauerlaubt den Zugri� auf alle Zwischenstufen der Sprachgenerierung. Auf diese Weisekann eine Anwendung sowohl auf die Phoneme, als auch auf die fertigen Audiodatenzugreifen.

Die Art der Spracherzeugung kann bei Sprachsynthesizern durch Parameter wie Sprech-geschwindigkeit, Stimmhöhe oder spezielle Betonung von Textteilen beein�usst werden.Über Mary-XML bietet Mary TTS bereits die Möglichkeit, diese Parameter zu beein-�ussen, so dass hierfür keine Erweiterungen notwendig sind.

Die von Mary TTS produzierte Phonemliste liefert auch Zeitwerte, die angeben, wannein Phonem ausgesprochen wird. Mit Hilfe dieser Daten, sowie der Phonem-VisemZuordnung aus [119] und der Implementierung eines Koartikulations-Modells kann sodie lippensynchrone Animation erzeugt werden. Da es verschiedene Koartikulations-Modelle gibt und ggf. später auch andere Sprachsynthesizer eingesetzt werden sollen,wird das Teilsystem für die Online-Sprachausgabe modular aufgebaut.

Steuerung von sekundären Animationen bei der Online-Gesichtsanimation

Sekundäre Animationen, wie Gesichtsmimik und andere Körperbewegungen, könnenmit Skripten [152, 206] oder mit in den Text eingebetteten Anweisungen [150, 117]kontrolliert werden. Dabei spielt die Synchronisierung von sekundären Bewegungen


Talking Avatar TVML VHML

\expression{1}

\say Schau, da ist er!

\HeadNod(lf,OM,20,0.1)

character:talk(name="Julia",

text="Schau,da ist er!",

emotion=neutral,

wait=no)

wait(time = 0.1)

character:look(name="Julia",

what="Er")

<vhml>

<person

disposition="neutral">

Schau,

<look_left>

da ist er!

</look_left>

</person>

</vhml>

Tabelle 3.1: Beispiele für die Synchronisierung von Sprache und Gestik

mit dem gesprochenen Text eine wichtige Rolle. In [206] erfolgt die Synchronisierungdurch den Autor des Skripts. Jeder Skriptbefehl ist mit einem Zeitstempel versehen, derden Ausführungszeitpunkt festlegt. Diese Art der Synchronisierung ist nicht besondersintuitiv, insbesondere wenn eine Aktion erst dann ausgeführt werden soll, wenn einbestimmtes Wort gesprochen wird. Da die Dauer des gesprochenen Textes im Vorausnicht bekannt ist, kann eine Feinjustierung der Zeitstempel oft nur durch Ausprobierenerreicht werden.

TVML [152] hat Synchronisierungsmechanismen eingebaut, bei denen auf die absoluteAngabe eines Zeitstempels verzichtet werden kann. Normalerweise werden Anweisun-gen sequenziell abgearbeitet. Soll eine nachfolgende Anweisung bereits während derAusführung der aktuellen Anweisung gestartet werden, kann eine relative Zeitangabeverwendet werden, um die zeitliche Di�erenz zwischen zwei Aktionen festzulegen. Auchhier kann eine Feinjustierung nur durch Ausprobieren erreicht werden.

Eingebettete Anweisungen - wie bei der VHML [150] - werden direkt in den zu spre-chenden Text eingefügt. Sobald das Sprachmodul bei der Abarbeitung des zu sprechen-den Textes die eingebettete Anweisung erreicht, wird die Anweisung ausgeführt. EinAnwender muss sich so keine Gedanken über die Sprechgeschwindigkeit machen.

Zur Verdeutlichung der Konzepte sind in Tabelle 3.1 drei Beispiele angegeben. Es solljeweils der Satz �Schau, da ist er!� gesprochen werden, wobei der Kopf bei dem Wort�da� nach links gedreht werden soll. Die Verwendung von eingebetteten Anweisungenerscheint hierbei besonders intuitiv. Da Mary-XML ohnehin schon XML-Tags zur Kon-trolle der Sprachausgabe verwendet, wird dieses Verfahren auch für das Avatar-Systemverwendet.

Mary-XML wird daher um Anweisungen erweitert, mit denen sekundäre Animationenkontrolliert werden können. Um maximale Flexibilität zu erreichen, wird nicht wie beider VHML ein fester Befehlsvorrat vorgesehen. Stattdessen kann ein Anwender jedeverfügbare Animation aus der Animationsbibliothek verwenden. Die Steuerung dersekundären Animation wird in das Teilsystem für die Online-Sprachausgabe integriert.

3.8 Entwicklung eines Avatar API

Für den Einsatz der Avatare im ICS wird ein API benötigt, welches die Verwendung undSteuerung der Avatare erlaubt. Hierzu gehören Funktionen zum Laden eines Avatars,zum Erstellen weiterer Instanzen eines Avatars, zur Kontrolle der Position und Aus-


richtung, zur Steuerung der Online-Animation und zur Ausgabe von lippensynchronerSprache.

Das Laden eines Avatars erfolgt durch Einlesen einer XML-Kon�gurationsdatei unddas anschlieÿende Laden aller Modell-Komponenten, Materialien und Animationen.Von einem einmal eingeladenen Avatar können anschlieÿend mehrere Instanzen erzeugtwerden, was insbesondere in Massenszenen sinnvoll sein kann. Da alle Instanzen auf dengleichen Daten basieren, können durch das einmalige Laden Ladezeiten und benötigterSpeicherplatz reduziert werden. Jede Instanz ist jedoch separat steuerbar.

Zur Steuerung der Avatare können Position und Ausrichtung durch Verschiebe- undRotationsoperationen verändert werden. Weiterhin können die in der Bewegungsbiblio-thek vorhandenen Animationen zur Laufzeit aktiviert und miteinander gemischt wer-den, um Online-Animationen zu erzeugen. Hierbei wird automatisch berücksichtigt, obeine Animation zyklisch abgespielt werden soll. Die Animationen können auÿerdem mitunterschiedlichen Gewichten versehen werden, wodurch sich vielfältige Möglichkeitenzum Mischen der Animationen ergeben. Auÿerdem wird direkter Zugri� auf die Gelen-ke des Skeletts ermöglicht, wodurch auch programmgesteuerte Animationen möglichwerden.

Weiterhin können die vorhandenen Morph-Ziele aktiviert werden, so dass auch die Ge-sichtsmimik zur Laufzeit verändert werden kann. Die lippensynchrone Sprachausgabewird durch zwei Funktionen ermöglicht, die entweder die Sprachanimation aus einerDatei, oder den in einer Zeichenkette angegebenen Text wiedergeben können.

Um eine bessere Kontrolle der Avatare durch die Anwendung zu ermöglichen, wirdauÿerdem noch ein Callback-Mechanismus implementiert. Hierdurch kann eine Anwen-dung die Behandlung bestimmter Ereignisse - beispielsweise das Ende einer Animation- um eigene Funktionalitäten erweitern.

Da mehrere Avatare parallel eingesetzt werden können, wird die Avatar-API in einerC++ Klasse abgebildet. Jede Instanz der Klasse repräsentiert einen Avatar. Die APIFunktionen werden durch Methoden der Avatar-Klasse repräsentiert.

3.9 Rapid Prototyping und �exible Steuerung von Ava-taren

Zwar ist das Avatar-System als eine Komponente des ICS geplant, jedoch stand diesesSystem während der Entwicklung des Avatar-Systems nicht zur Verfügung. Tests zurKontrolle der Funktionalität sowie erste Anwendungen des Avatar-Systems erfordernjedoch eine Möglichkeit, kleinere Szenarien erstellen zu können. Hierzu können C++Programme eingesetzt werden, die das Avatar-API zur Steuerung der Avatare verwen-den. Gerade bei Versuchen, bei denen mit verschiedenen Parametern experimentiertwerden soll, ist der übliche C++ Entwicklungszyklus bestehend aus Kodierung, Kom-pilierung, Binden und Test zu zeitaufwändig. Je nach Leistungsfähigkeit des verwen-deten Rechners können die beiden mittleren Schritte mehrere Minuten beanspruchen.Für Prototyping sind jedoch kürzere Entwicklungszyklen wünschenswert. Dies kannmit einer Bindung des Avatar-API an eine interpretierte Sprache ermöglicht werden,bei der Kompilieren und Binden entfällt.


3.9.1 Anforderung an die Skripting Sprache

In der Forschung wurden eine Reihe von Möglichkeiten für die Beschreibung und Steue-rung von Avataren diskutiert. Hierzu gehören XML basierte Sprachen wie MPML [210],VHML [150] und CML [224], aber auch spezialisierte Skriptsprachen wie Improv [191],TVML [152], Crosstalk Skripting Sprache [197] oder Q [155]. Diese Sprachen sind aufdie Steuerung von Avataren spezialisiert. Die Beschreibung von kompletten Anwen-dungsszenarien ist - wenn überhaupt - nur in Ansätzen möglich.

Mit der Skriptsprache sollen jedoch nicht nur die Avatare selbst, sondern auch kom-plette Szenarien gesteuert werden können. Die Sprache soll sich auÿerdem für die Rea-lisierung neuer Steuerungskonzepte eignen, die auf Basis des vorhandenen Avatar-APIimplementiert werden. Daher wird ein allgemeiner Skripting-Ansatz verfolgt. Hierzuwird auf einen verfügbaren Sprachinterpreter zurückgegri�en, um Entwicklungszeit ein-zusparen.

Dieser Sprachinterpreter sollte Merkmale besitzen, die eine schnelle Erstellung von Pro-grammen ermöglicht. Dazu gehören implizit deklarierte Variablen, sowie fehlende bzw.automatische Typumwandlung. Hinzu kommt eine automatische Speicherverwaltung.Auÿerdem sollte der Sprachinterpreter möglichst schnell arbeiten.

3.9.2 Auswahl der Skripting Sprache

Es gibt mehrere universelle Skriptsprachen, die sich für eine Bindung an das Avatar APIeignen. Von den verfügbaren Skriptsprachen sind Python [67] und Lua [48] besondersweit verbreitet.

Die Skriptsprache Python wurde Anfang der 1990er Jahre am �Centrum voor Wiskundeen Informatica� in Amsterdam entwickelt [101]. Sie wurde mit dem Ziel entworfen,möglichst einfach und übersichtlich zu sein. Der Funktionsumfang von Python kannzur Laufzeit mit Modulen erweitert werden, so dass mittlerweile eine groÿe Anzahlan Erweiterungen verfügbar ist, die viele Aufgabenbereiche abdecken. Python kannauch in Anwendungen eingebettet werden, wodurch diese um Skriptingfunktionalitätenerweitert werden können. Beispiele hierfür sind Blender, Poser und MotionBuilder.

Lua wurde 1993 von der �Computer Graphics Technology Group� der Ponti�kalen Ka-tholischen Universität von Rio de Janeiro in Brasilien entwickelt [98]. Das ursprünglicheZiel war die Entwicklung einer Datenbeschreibungssprache, die in Simulationen einge-bettet werden kann, und die Erstellung von Parametersätzen erleichtert. Die Sprachewurde immer weiterentwickelt und ist inzwischen universell einsetzbar. Ebenso wie Py-thon kann der Funktionsumfang von Lua erweitert werden. Es gibt jedoch keinen au-tomatischen Lademechanismus. Stattdessen muss das Laden der Erweiterungen durchdie Anwendung vorgenommen werden, in die Lua eingebettet wird. Lua wird häu�geingesetzt, um die Inhalte in Spielen und interaktiven Anwendungen zu skripten. Sobietet auch Quest3D eine Lua Schnittstelle.

Von ihrer Mächtigkeit her sind beide Sprachen gleichermaÿen für eine Bindung an dasAvatar-System geeignet. Während Python durch die Vielzahl an verfügbaren Moduleneinen gröÿeren Funktionsumfang hat, ist der Lua Interpreter schlanker als sein PythonGegenstück. Vergleichende Benchmarks [46, 47] zeigen auÿerdem, dass Lua in der Regelschneller als Python ist (siehe auch Abbildung 3.3). Daher wird Lua zur Realisierungdes Skriptings ausgewählt.


schnell

langsam

1 5 10 15 20 25 30 35

PythonLua

Abbildung 3.3: Vergleich der Geschwindigkeit von Python und Lua (Zusammenfassungder Ergebnisse von [46, 47])

3.10 Darstellung und Animation in Echtzeit

Die Darstellung und Animation der Avatare soll sich dynamisch während der Laufzeitverändern lassen. Änderungen können je nach Anwendung entweder vom Benutzer,vom �Story Telling� System, oder der KI ausgelöst werden. Durch den Einsatz in derCasCave bekommt der Echtzeit-Aspekt einen besonderen Stellenwert, denn für eineoptimale stereoskopische Darstellung muss die gerenderte Szene möglichst schnell denKopfbewegungen des Betrachters angepasst werden. Die Avatare werden in der Cas-Cave auÿerdem in Lebensgröÿe dargestellt, wodurch sich höhere Anforderungen an dieDarstellungsqualität ergeben.

3.10.1 Anforderungen an die Darstellung der Avatare

Für die Darstellung der Avatare in Echtzeit wird eine Schnittstelle benötigt, die eineplattformunabhängige Darstellung der Avatare in Echtzeit erlaubt. Da Avatare in einerSzene nur selten alleine eingesetzt werden, sollte auÿerdem eine einfache Einbindunganderer Modelle möglich sein. Das Animationssystem muss zweischichtige Modelle undMorphing unterstützen.

Die Ausgabe in der CasCave erfolgt auf mehreren Rechnern. Daher muss das Dar-stellungssystem ein koordiniertes Rendern auf mehreren Rechnern unterstützen. Dabeisollte das gewählte Ausgabesystem keinen Ein�uss auf die Avatar-Modelle und dieSzene haben, d.h. ein einmal erstelltes Modell sollte sich sowohl auf einem normalenBildschirm, als auch in der CasCave darstellen lassen.

Da die Avatare auch in der Lage sind, Sprache auszugeben, wird neben der visuellenDarstellung auch eine plattformübergreifende Audio-Ausgabe benötigt.


Abbildung 3.4: Beispiel für einen Szenengraphen

Abbildung 3.5: Bearbeitungsstufen in einem Szenengraphen

3.10.2 Auswahl des Darstellungssystems

Es gibt zwei weit verbreitete APIs, die die Darstellung und Animation von dreidimen-sionalen Avatarmodellen in Echtzeit zulassen. Dies ist zum einen die von Microsoftentwickelte DirectX API [54], die unter MS-Windows Betriebssystemen und der Spiel-konsole X-Box verfügbar ist. Zum anderen ist dies OpenGL [63], das auf dem von SiliconGraphics entwickelten IRIS GL basiert und zur Zeit von der OpenGL Arbeitsgruppeder Khronos Gruppe [45] weiterentwickelt wird. Im Gegensatz zu DirectX ist OpenGLplattformunabhängig. Es bietet sich daher für die Umsetzung des Avatar-Systems an.

Das OpenGL API bietet jedoch nur low-level Befehle, mit denen sich alleine das Rende-ring realisieren lässt. Es enthält beispielsweise keine Befehle zum Laden von Texturenoder vorhandenen Modellen. Auch eine automatische Optimierung der Darstellungs-geschwindigkeit, beispielsweise durch Auslassen von Modellen, die nicht sichtbar sind(culling), wird von OpenGL nicht unterstützt. An dieser Stelle setzen Szenengraphenan, bei denen Szenen in einer hierarchischen Graphen- oder Baumstruktur abgelegtwerden.

Die Knoten in dem Graphen repräsentieren entweder die Geometrie von Modellen (sogenannte Geodes), oder Transformationen und Verwaltungsinformationen (siehe Bei-spiel in Abbildung 3.4). Während des Programmablaufs durchläuft der Szenengraphzyklisch drei Bearbeitungsstufen. In der Update-Stufe wird der Szenengraph aktua-lisiert, d.h. die Anwendung bekommt Gelegenheit, die Struktur des Graphen zu ver-ändern. In der anschlieÿenden Cull-Stufe werden die sichtbaren Objekte identi�ziert.Nur diese gelangen in die Draw-Stufe, die das Zeichnen der Objekte übernimmt (sieheAbbildung 3.5).

Szenengraphen vereinfachen die Entwicklung von 3D Anwendungen, da sie von denlow-level OpenGL Befehlen abstrahieren und Veränderungen in der Szene durch Mani-pulationen am Szenengraphen realisiert werden können. Sie können meist mit gängigenGra�k- und Modellformaten umgehen, wodurch der Aufbau von Szenen erleichtert


wird. Durch culling und andere automatische Optimierungen wird auÿerdem die Ren-dergeschwindigkeit erhöht.

Neben den Veteranen Inventor [73] und Performer [74] gibt es zwei moderne Open-Source Szenengraphen, die auf verschiedenen Plattformen lau�ähig sind und derenLizenzen eine Verwendung auch in closed-source Anwendungen zulassen: OpenSG undOpenSceneGraph [64].

OpenSG wurde zunächst von Reiners [193] entwickelt, ist aber heute ein o�enes Ge-meinschaftsprojekt mit freiwilligen Entwicklern. Der Szenengraph kann Bildformatewie BMP, GIF, JPG, PNG, sowie Modellformate wie 3DS und OBJ verarbeiten. Wei-tere Datenformate können durch Plugins hinzugefügt werden. Zur Optimierung derDarstellungsgeschwindigkeit unterstützt OpenSG culling und state-sorting. Eine Be-sonderheit ist, dass OpenSG von Haus aus in Rechenclustern eingesetzt werden kannund das verteilte Rendern erlaubt. Daher unterscheiden sich die interne Struktur undHandhabung von klassischen Szenengraphen wie Performer.

Auch OpenSceneGraph, zunächst von Burns und Os�eld entwickelt, ist ein o�enes Ge-meinschaftsprojekt mit vielen freiwilligen Entwicklern. Dieser Szenengraph unterstütztebenso die Bildformate BMP, GIF, JPG und PNG, sowie Modellformate wie 3DS, OBJund COLLADA. Durch Plugins können auÿerdem noch weitere Formate integriert wer-den. Die Darstellungsgeschwindigkeit wird durch culling und state-sorting optimiert.Da OpenSceneGraph zunächst als Ersatz für Performer entwickelt wurde, ähneln sichStruktur und Handhabung. Hierdurch wird die Einarbeitung für Entwickler mit Per-former Vorkenntnissen erleichtert. Im direkten Vergleich (siehe z.B. [89]) hat OpenSGVorteile beim verteilten Rendern, welches von OpenSceneGraph nicht direkt unter-stützt wird. Auf der anderen Seite unterstützt OpenSceneGraph mehr Datenformateund lässt sich leichter erweitern, weswegen dieser Szenengraph für das Avatar-Systemausgewählt wird.

3.10.3 Auswahl des Animationssystems

Sowohl skelettbasierte Animation, als auch Morphing gehören heute zu den StandardTechniken bei der Charakteranimation. Diese sollen auch bei dem Avatar-System ver-wendet werden und können mit Hilfe von Cal3D (siehe Abschnitt 2.7) realisiert werden.Die Lizenz von Cal3D erlaubt eine Verwendung auch in closed-source Projekten (LG-PL).

Da Cal3D das Rendern der Avatare der Anwendung überlässt, muss eine Kopplungzwischen Cal3D und OpenSceneGraph implementiert werden. Mehrere Projekte ha-ben diese Kopplung bereits realisiert. Hierzu gehören osgCal [65], osgCal2 [66] undReplicantBody (siehe Kapitel 2.7). osgCal und osgCal2 sind reine Adapter und ermög-lichen nur die Darstellung eines Cal3D-Modells in OpenSceneGraph. Zur Animationkann das Standard Cal3D API eingesetzt werden. osgCal verwendet das GPL Lizenz-modell, wodurch diese Bibliothek nicht in closed-source Projekten eingesetzt werdenkann. osgCal2 kann zwar in closed-source Projekten eingesetzt werden, ist aber nichtso leistungsfähig in der Renderleistung.

ReplicantBody kann ebenfalls in closed-source Projekten verwendet werden und erwei-tert auÿerdem die Kontrollmöglichkeiten von Cal3D. Zwar ist das System plattformu-nabhängig implementiert, in Tests gab es jedoch Schwierigkeiten beim Einsatz auf un-


Abbildung 3.6: Die CasCave im Fachgebiet Technische Informatik, mit SpaceMouse(rechts, oben), sowie Shutter-Brille mit Positionssensor (rechts, unten)

terschiedlichen Betriebssystemen. Keines der Projekte unterstützt auÿerdem Spracha-nimation, bzw. Transparenz- oder Bump-Maps. Aus diesem Grund wird keines derProjekte eingesetzt und stattdessen ein neuer Adapter implementiert.

3.10.4 Darstellung der Avatare in der CasCave

Die Avatare sollen im Maÿstab 1:1 in der CasCave dargestellt werden. Hierfür muss ei-ne Kopplung zwischen der CasCave und dem Avatar-System entwickelt werden. Da diegra�sche Ausgabe auf OpenSceneGraph basiert, wird eine Integration des Szenengra-phen in die CasCave benötigt. Auf diese Weise pro�tiert nicht nur das Avatar-Systemvon der Anbindung, sondern prinzipiell jede Szene, die sich mit OpenSceneGraph dar-stellen lässt.

Die CasCave ist eine Multiprojektionsumgebung mit drei Wänden für linke, vordereund rechte Ansicht (siehe Abbildung 3.6). Jede Wand besteht aus einer Rückprojekti-ons�äche mit einer Gröÿe von 2.5m×2.5m, auf die jeweils ein Marquee 8500-Projektordas Bild überträgt. Die Projektoren können für eine aktive Stereodarstellung mit 60Hz Bildwiederholfrequenz eingesetzt werden.

Insgesamt fünf Rechner sind an der Darstellung in der CasCave beteiligt. Jeweils eineWand wird von einem Render-Rechner mit den Bildinformationen versorgt. Diese Rech-ner sind mit Gra�kkarten ausgestattet, die aktive Stereodarstellung ermöglichen. Aufden Render-Rechnern wird das Betriebssystem Linux eingesetzt. Ein weiterer Rech-ner ist für die Verarbeitung der Eingabesignale zuständig. Zu diesen Eingabesignalengehören Informationen des Tracking-Systems der CasCave, sowie Benutzereingabenbeispielsweise über die SpaceMouse. Das Tracking-System erfasst die Kopfposition desBenutzers, die für eine optimale Darstellung der Szene benötigt wird. Aufgrund derbesseren Versorgung mit Treibern für verschiedene Eingabegeräte läuft dieser Rechnerunter dem Betriebssystem Windows. Der fünfte Rechner wird als Datenserver einge-


setzt, auf dem zentral Modelldaten und Programme für den CasCave-Betrieb abgelegtwerden können. Auf diesem Rechner wird ebenfalls Linux eingesetzt. Die Rechner sinduntereinander mit einem Gigabit Netzwerk verbunden.

Die Darstellung in der CasCave erfolgt dadurch, dass die drei Render-Rechner die glei-che Szene aus jeweils unterschiedlichen Ansichten (für linke, vordere und rechte Wand)gleichzeitig darstellen. Diese gleichzeitige Darstellung erfordert eine Synchronisierungder Render-Rechner. Auÿerdem werden für jeden Rechner passende Projektionseinstel-lungen benötigt. Beide Aufgaben können von VR-Systemen wie Net-Juggler [57] undSYZYGY [75] übernommen werden. Neben Kon�gurations- und Synchronisationsme-chanismen bieten diese Systeme auch eine Abstraktionsschicht für die Verarbeitungvon Benutzereingaben an, die über Netzwerk zu den Render-Rechnern verteilt werden.

Von den beiden Systemen wird SYZYGY für die CasCave ausgewählt. Dieses VR-System unterstützt zwei Rahmenwerke für die Umsetzung von VR Applikationen. Beidem ersten Rahmenwerk handelt es sich um einen verteilten Szenengraphen. Hierbeiexistiert ein Anwendungs-Rechner, der den Szenengraphen manipuliert, sowie beliebigviele Render-Rechner, die den Graphen - je nach Projektionseinstellung - darstellen.Da nur ein Szenengraph zur Laufzeit existiert, kann die Synchronisierung der Bild-darstellung komplett von SYZYGY übernommen werden. Dieser Szenengraph stehtaber weit hinter der Leistungsfähigkeit von OpenSceneGraph zurück. Auÿerdem würdedie Verwendung dieses Rahmenwerks die Implementierung eines weiteren Adapters fürCal3D erforderlich machen.

Mit dem zweiten Rahmenwerk kann eine Master/Slave Betrieb realisiert werden, beidem auf allen Render-Rechnern die gleiche Anwendung läuft. Einer dieser Rechnerfungiert als Master und gibt den Bearbeitungstakt vor. Die restlichen Rechner folgenals Slaves dem vorgegebenen Takt. Bei diesem Rahmenwerk kümmert sich SYZYGYnur um die Kon�guration der Projektions�ächen, die Synchronisierung der Render-Rechner, sowie die Verteilung der Eingabedaten. Die gra�sche Ausgabe muss von derAnwendung implementiert werden. An dieser Stelle kann OpenSceneGraph eingesetztwerden, weswegen diese Kombination für die Darstellung in der CasCave ausgewähltwird.

3.10.5 Auswahl des Audiosystems

Mit zur Darstellung gehört auch die Audioausgabe der Sprachdaten. osgAL [87] istzur Zeit das einzige Audiosystem, das in OpenSceneGraph integriert ist. Bei osgALhandelt es sich um einen Adapter für OpenAL [62], einem plattformunabhängigen 3D-Audio-API. Diese API ermöglicht Audioe�ekte wie Raumklang und Dopplere�ekte. AlsAudio-Ergänzung zu OpenGL ist OpenAL für viele Plattformen verfügbar und eignetsich so für die Umsetzung des Avatar-Systems.

3.11 Systemüberblick

Abbildung 3.7 fasst die Teilbereiche des Avatar-Systems zusammen. Insgesamt kön-nen vier Teilbereiche identi�ziert werden: Modellierung und Animation mit externenAnwendungen, Kon�guration der Avatare mit Hilfe der erstellen Inhalte, Steuerung


Abbildung 3.7: Teilbereiche des Avatar-Systems

der Avatare in der Simulation und Darstellung auf unterschiedlichen Ausgabemedien.Die folgenden Abschnitte beschreiben jeweils das übergeordnete Realisierungskonzeptdieser Teilbereiche. Die konkreten Implementierungen werden in den nachfolgendenKapiteln beschrieben.

3.11.1 Modellierung und Animation der Avataren

Für die Modellierung und Animation, d.h. für die Erstellung der Modell- und Ani-mationsbibliotheken, werden bestehende Anwendungen eingesetzt. Hierbei werden diebenötigten Arbeitsabläufe mit erweiterten BPMN Diagrammen dokumentiert. Benöti-ge Arbeitsabläufe sind:

• Erstellung von animierbaren Avatar-Modellen


• Erstellung von Morph-Zielen für die Gesichtsanimation

• Animieren von Modellen mit MOCAP

• Aufbereitung von MOCAP-Daten

• Parametrische Laufanimation

• Erzeugung von lippensynchroner O�ine-Sprachanimation

Die Arbeitsabläufe für die Modellierung werden in Kapitel 4 beschrieben. In Kapitel 5folgt die Beschreibung der Arbeitsabläufe zur O�ine-Animation.

3.11.2 Kon�guration von Avataren

Die Kon�guration ermöglicht die Zusammenstellung konkreter Avatare für den Ein-satz in der Simulation. Diese Kon�guration wird mit Hilfe des Avatar-Designers er-möglicht, der somit als Bindeglied zwischen Modellierung und Anwendung dient. DerAvatar-Designer erlaubt die Auswahl aller Modellkomponenten. Hierzu gehören Skelett-Hierarchie, Geometrie des Modells, Morph-Ziele, Materialien und Animationen. Hinzukommen Einstellungen, die den Einsatz in Simulationen erleichtern.

Neben der Kon�guration ermöglicht der Avatar-Designer auch eine einheitliche Ska-lierung und Ausrichtung der Avatare, sowie visuelle Tests. Das Programm wird alsQt-Anwendung realisiert, so dass es sowohl unter Linux, als auch unter Windows ein-gesetzt werden kann.

Da die Cal3D Bibliothek verwendet wird, müssen alle Daten im Cal3D Format vorlie-gen. Während der Modellierung werden jedoch das Wavefront OBJ Datenformat fürstatische und das FBX Datenformat für dynamische Modelle verwendet. Mit zur Kon-�guration gehören daher auch die Aufbereitung und Umwandlung der Daten in dasLaufzeitformat.

Aufbereitung und Kon�guration der Avatare werden in Kapitel 6 beschrieben.

3.11.3 Steuerung der Avatare

C++ API

Die Steuerung der Avatare erfolgt durch ein C++ API. Dieses API wird durch dieAvatar-Klasse bereitgestellt, welche als OpenSceneGraph-Knoten implementiert wird.Hierdurch kann ein Avatar direkt in den Szenengraphen eingefügt werden. Das APIbietet Zugri� auf die in Abschnitt 3.8 aufgeführten Funktionen, die zur Übersicht nocheinmal aufgezählt werden:

• Einladen von Avataren unter Verwendung einer Kon�gurationsdatei

• Verschieben und Rotieren der Avatare

• Aktivieren und Mischen von Animationen


avatar

config graphics speech

Abbildung 3.8: Komponenten des Avatar-Systems

• Direkte Kontrolle der Gelenke des Skeletts

• Kontrolle von Morph-Zielen

• Ausgabe von Sprache

Die Avatar-Klasse hat auÿerdem die Funktionalität eines Gruppen-Knotens, wodurchsich der Avatar bei Bedarf durch zusätzliche Komponenten �exibel erweitern lässt.Hiervon wird auch bei der Umsetzung eines kompletten Avatar-Modells Gebrauch ge-macht, das aus mehreren Komponenten aufgebaut wird (siehe Abbildung 3.8). Zu denKomponenten gehören:

con�g: Diese Komponente ist für die Verwaltung der Kon�gurationsdaten verantwort-lich. Mit ihr können die XML-Kon�gurationen gelesen und geschrieben werden.

graphics: Diese Komponente ist für die gra�sche Anbindung an den Szenengraphenzuständig und sorgt für das Rendern der Cal3D Daten in OpenSceneGraph.

speech: Die Komponente �speech� ist für die Sprachausgabe zuständig. Sie regelt dieSprachanimation des Avatars, sowie die Audio-Wiedergabe.

Gemäÿ der Vorgabe, bei der Implementierung des Avatar-Systems möglichst auf vor-handene Lösungen aufzubauen, wird eine Reihe von externen Komponenten eingesetzt(siehe Abbildung 3.9). Hierzu gehört die LibXML zum Lesen und Schreiben der XML-Daten, sowie Cal3D, OpenSceneGraph und OpenGL für die gra�sche Ausgabe. DieSprachausgabe wird mit Mary TTS, osgAL und OpenAL realisiert.

Weitere Details zur Avatar-API be�nden sich in Kapitel 7.

Skripting

Eines der grundlegenden Konzepte von Szenengraphen ist, dass Knoten in dem Szenen-graphen Kontrollaufgaben von angehängten Teilbäumen übernehmen können. So trans-formieren beispielsweise Transformations-Knoten den angehängten Teilbaum. DiesesKonzept wird auch für das Skripting übernommen, indem ein Skript-Knoten realisiertwird. Diese Skript-Knoten kontrollieren den angehängten Teilbaum unter Verwendungeiner Skriptsprache. Mehrere Skript-Knoten können so parallel in den Szenengrapheneingefügt werden. Der Skript-Knoten wird als eigenständige Komponente realisiert, sodass er auch ohne Avatare eingesetzt werden kann.


Abbildung 3.9: Externe Komponenten des Avatar-Systems

Abbildung 3.10: Externe Komponenten des Skript-Knotens

Auch bei den Skript-Knoten werden vorhandene Komponenten eingesetzt (siehe Ab-bildung 3.10). Hierzu gehört Lua zur Realisierung des Skriptings. Der Skript-Knotenimplementiert auÿerdem noch eine Bindung an OpenSceneGraph und osgAL, wodurchsich die Gra�k- und Audioausgabe durch Skripte steuern lässt. Da auch die AvatareBestandteile des Szenengraphen sind, können sie ebenfalls durch den Skript-Knotenkontrolliert werden.

Die Implementierung der Skript-Knoten wird in Kapitel 7 beschrieben.

3.11.4 Darstellung von Avataren

Darstellung und Sprachausgabe von Avataren mit OpenSceneGraph

Die Darstellung der Avatare in OpenSceneGraph wird durch einen neuen Geometrie-Knoten realisiert. Die Aufgabe dieses Knotens besteht darin, bei jedem Update-Zyklus


Abbildung 3.11: Externe Komponenten der CasCave Darstellung

des Szenengraphen den internen Cal3D-Animationsstatus zu aktualisieren und die ge-änderten Geometrieinformationen in die OpenSceneGraph Datenstrukturen zu über-tragen. Hinzu kommt die Verwaltung von Materialinformationen und Texturen. DieImplementierung der Darstellung wird in Kapitel 9 beschrieben.

Die Sprachausgabe wird durch eine Erweiterung der Cal3D-Bibliothek realisiert, die dasAbspielen von Morph-Sequenzen ermöglicht. Die Audio-Ausgabe erfolgt durch Anhän-gen eines Sound-Knotens an den Avatar-Knoten. Die Umsetzung der Sprachausgabezur Laufzeit wird in Kapitel 8 beschrieben.

Darstellung in der CasCave

Die Darstellung der Avatare in der CasCave erfolgt durch eine Kopplung des SYZY-GY Master/Slave Rahmenwerks und OpenSceneGraph. Dies wird durch Implementie-rung einer Darstellungskomponente erreicht, die das Rendern entsprechend den SY-ZYGY Einstellungen umsetzt. Diese Komponente muss auch eine geeignete Synchro-nisierung der Szenengraphen auf den beteiligten Rechnern übernehmen. Die Kopp-lung ist unabhängig von dem eigentlichen Avatar-System und kann daher von jederOpenSceneGraph-Anwendung genutzt werden.

In Abbildung 3.11 sind die zur Darstellung in der CasCave eingesetzten Komponentenzusammengefasst. Zu diesen Komponenten gehören SYZYGY, welches für die Kon�-guration und Synchronisierung der CasCave Projektions�ächen verwendet wird, sowieOpenSceneGraph, welcher das Rendering übernimmt. Avatare und Skript-Knoten sindin den Szenengraphen integriert und werden daher in der Abbildung nicht gesondertausgewiesen. Die Implementierung der Darstellung in der CasCave wird in Kapitel 9beschrieben.


Kapitel 4

Modellierung von Avataren

Wie im Konzept festgelegt, sollen zur Modellierung von Avataren vorhandene Program-me miteinander kombiniert werden. Da in dem System zweischichtige Avatar-Modelleverwendet werden, muss es mit diesen Programmen möglich sein, die benötigten Datenzu erzeugen.

Hierzu gehört zunächst das zur Animation verwendete Skelett. Dieses Skelett wirddurch mehrere Gelenke (Bones) repräsentiert, die hierarchisch miteinander verbundensind. Hinzu kommt das sichtbare Modell des Avatars, welches Geometrie- und Mate-rialinformationen benötigt. Die Geometrie wird hierbei durch Polygone beschrieben.Materialinformationen sind Farbwerte oder Texturen. Sichtbares Modell und Skelettwerden mit Hilfe von Skinning-Informationen - d.h. Gewichtungsfaktoren, die den Ein-�uss der Gelenke auf die sichtbare Geometrie festlegen - miteinander verknüpft.

Bevor mit der Beschreibung der Modellierung begonnen wird, werden im folgendeneinige grundsätzliche Hinweise zur Modellierung gegeben. Hierbei handelt es sich umHinweise zur Bescha�enheit des Skeletts und des sichtbaren Modells, sowie zur Ska-lierung. Es folgen dann eine Übersicht über die verwendeten Programme, sowie dieDatenformate, die für den Austausch der Informationen verwendet werden. Hieranschlieÿen die entwickelten Arbeitsabläufe an.

4.1 Grundsätzliche Hinweise zur Modellierung von Ava-taren

4.1.1 Aufbau der Skelettstruktur

Die Struktur des Skeletts ist entscheidend dafür, wie �exibel ein Avatar animiert werdenkann. Dabei wird in aller Regel nicht das menschliche Skelett mit seinen über 200 Kno-chen im Detail nachgebildet, sondern mit einem reduzierten Skelett gearbeitet. DiesesSkelett ist nicht aus Knochen, sondern aus Gelenken aufgebaut, die hierarchisch ange-ordnet sind. In Abbildung 4.1 (a) ist eine minimale Skelettstruktur zu sehen, welche mit15 Gelenken auskommt (in der Abbildung durch Kugeln mit Kreuzen dargestellt). Die-se minimale Skelettstruktur kann bei Bedarf erweitert werden, indem beispielsweise dieWirbelsäule aus mehreren Gelenken aufgebaut wird oder zusätzlich die Fingergelenkeder Hand (siehe Abbildung 4.1 (b)) hinzugefügt werden.

75

76 KAPITEL 4. MODELLIERUNG VON AVATAREN

linker Oberschenkel(LeftUpLeg)

linker Unterschenkel(LeftLeg)

linker Fuß(LeftFoot)

Hüfte (Hips)

Wirbelsäule (Spine)

l. Oberarm(LeftArm)

l. Unterarm(LeftForeArm)

linke Hand(LeftHand)

Kopf(Head)

rechter Oberschenkel(RightUpLeg)

rechter Unterschenkel(RightLeg)

rechter Fuß(RightFoot)

r. Oberarm(RightArm)

r. Unterarm(RightForeArm)

rechte Hand(RightHand)

(a) einfache Skelettstruktur (b) Skelettstruktur der Hand

Abbildung 4.1: Skelettstrukturen für Avatar-Modelle

In Tabelle 4.1 sind die minimale und maximale Anzahl an Gelenken je Körperteil zu-sammengefasst. Diese Tabelle entspricht den Vorgaben von MotionBuilder, da diesesProgramm für die Animation verwendet werden soll. Mit diesen Angaben können �e-xibel Skelettstrukturen aufgebaut werden, die alle denkbaren Anwendungsgebiete desAvatar-Systems abdecken sollten.

Es ist gängige Praxis, die Gelenke in einer bestimmten Hierarchie anzuordnen. DieseHierarchie geht von der Hüfte aus. Von dieser verzweigt die Skelettstruktur in linkesund rechtes Bein (jeweils Oberschenkel, Unterschenkel, Fuÿ) und in die Wirbelsäule.Von dem oberen Ende der Wirbelsäule verzweigt die Hierarchie weiter in den linkenund rechten Arm (jeweils Oberarm, Unterarm, Hand) und weiter in den Kopf (Hals,Kopf).

Die Hüfte ist das einzige Gelenk des Skeletts, das sowohl rotiert, aus auch verschobenwerden kann. Sie gibt somit Position und Ausrichtung eines Avatars an. Alle anderenGelenke können nur Rotationen ausführen. Geometrisch repräsentiert jedes Gelenkein lokales Koordinatensystem, wobei sich Transformationen eines Koordinatensystemsauch auf alle hierarchisch abhängigen Koordinatensysteme auswirken.

4.1.2 Modellierung des sichtbaren Avatarmodells

Die Geometrie des sichtbaren Avatarmodells wird durch Polygone repräsentiert, dadiese am e�zientesten durch heutige Gra�khardware verarbeitet werden können. Prin-zipiell gibt es keine Einschränkung für die Komplexität der verwendeten Geometrie. Esmuss jedoch berücksichtigt werden, dass die geometrische Komplexität unmittelbarenEin�uss auf die Wiedergabegeschwindigkeit hat. Diese ist auch von der Komplexitätder restlichen Szene, sowie der Anzahl der eingesetzten Avatare abhängig, so dass jenach Anwendungsgebiet andere Höchstgrenzen für die Anzahl der Polygone anfallenkönnen. Gängige Spiele verwenden beispielsweise mehrere tausend Polygone je Avat-ar. Für eine höhere Detailtreue sollten aber auch Avatare mit mehreren zehntausendPolygonen eingesetzt werden können.

KAPITEL 4. MODELLIERUNG VON AVATAREN 77

Körperteil minimale Anzahl Gelenke maximale Anzahl Gelenke

Hüfte 1 1

Wirbelsäule 1 10

Hals 0 10

Kopf 1 1

linke Schulter 0 1

linker Oberarm 1 2

linker Unterarm 1 2

linke Hand 1 24

rechte Schulter 0 1

rechter Oberarm 1 2

rechter Unterarm 1 2

rechte Hand 1 24

linker Oberschenkel 1 2

linker Unterschenkel 1 2

linker Fuÿ 1 24

rechter Oberschenkel 1 2

rechter Unterschenkel 1 2

rechter Fuÿ 1 24

Tabelle 4.1: Anzahl der Gelenke (Bones) je Körperteil

Die Anzahl der Polygone lässt sich dadurch reduzieren, dass nur die wirklich sichtba-ren Polygone in das Modell aufgenommen werden. Körperstellen, die durch Kleidungbedeckt sind, können daher weggelassen werden. Das gleiche gilt für Mund, Zähne undZunge, die nur dann detailliert modelliert werden müssen, wenn eine Sprachausgabeerwünscht ist.

Es ist daher sinnvoll, wenn ein Modell ohne groÿe Probleme in mehrere Bestandteilezerlegt werden kann. Hierdurch besteht die Möglichkeit, Modellbibliotheken aufzubau-en, mit denen auf einfache Art und Weise Modellvarianten erstellt werden können. BeiSprachausgabe sollte das Modell zumindest in Kopf, Augen und Körper zerlegt wer-den. Für eine gröÿere Flexibilität sollte der Körper noch zusätzlich unterteilt werden,beispielsweise in Torso, sowie Ober- und Unterarme und Ober- und Unterschenkel, usw.

Da die Sprachausgabe auf Morphing basiert, werden auÿerdem je Visem passendeMorph-Ziele benötigt. Hierzu werden in dieser Arbeit die 15 Viseme aus [119] ver-wendet, so dass diese ggf. bereitgestellt werden müssen.

4.1.3 Standard-Pose für die Modellierung

Viele Animationsprogramme gehen bei Avataren von einer Standard-Pose aus, der sogenannten T-Stellung (T-Stance). Hierbei steht der Avatar gerade, mit ausgestrecktenArmen und Blick in der Vorder-Ansicht des Modellierungsprogramms zum Betrachter(siehe Abbildung 4.2 (a)). Diese Stellung hat den Vorteil, dass alle lokalen Koordinaten-systeme der Gelenke des Skeletts gleich ausgerichtet sind. Ähnliche Vorgaben existierenauch für die Finger der Hand. In Abbildung 4.2 (b) ist beispielsweise die Vorgabe vonMotionBuilder zu sehen.


(a) T-Stellung (b) Ausrichtung der Finger

Abbildung 4.2: Standard-Pose für Avatare

Sowohl Skelett, als auch das sichtbare Avatarmodell sollten in dieser Stellung model-liert, bzw. vor einem Export in diese Stellung überführt werden, da Korrekturen imspäteren Verlauf oft schwierig, wenn nicht sogar unmöglich sind.

4.1.4 Skalierung von Avataren

Ein groÿes Problem, insbesondere wenn mehrere Programme an der Modellerstellungbeteiligt sind, ist eine einheitliche Skalierung der Modelle. Einer richtigen Skalierungkommt in dieser Arbeit auch deshalb eine erhöhte Aufmerksamkeit zu, weil die Avatarespäter im Maÿstab 1:1 in der CasCave dargestellt werden sollen.

Im Allgemeinen verwenden Programme wie Poser, 3DS MAX und MotionBuilder in-tern Gleitkommazahlen zur Speicherung von Daten im dreidimensionalen Raum. Dabeiunterscheiden sie sich jedoch in den Einheiten (cm, m, inch), mit denen diese Dateninterpretiert werden. Probleme tauchen auf, sobald die 3D Daten eines Programms ineinem anderen Programm weiterverarbeitet werden sollen - insbesondere dann, wenndas verwendete Dateiformat keine Angaben zu den verwendeten Einheiten speichernkann (wie beispielsweise das Wavefront OBJ Format). In diesem Fall verwendet dieimportierende Anwendung ihre eigenen Einheiten, wodurch es zu ungewollten Gröÿen-änderungen kommen kann.

Letztes Programm in der Bearbeitungskette ist MotionBuilder. Spätestens hier solltendie Modelle die richtige Gröÿe haben. Das Programm kennt jedoch keine Einheitenund lässt sich daher auch nicht kon�gurieren. Stattdessen verwendet es direkt die inder Datei vorgefundenen Daten. Die Kon�guration des Gitternetzes, sowie die beige-fügten Beispielmodelle lassen jedoch vermuten, dass eine MotionBuilder-Einheit einemZentimeter entspricht. Ein Modell sollte daher schon vor dem Import in MotionBuilderdie richtige Gröÿe haben, wobei eine Einheit einem Zentimeter entsprechen sollte.

3D Studio Max steht in der Bearbeitungskette unmittelbar vor MotionBuilder und kann�exibel an beliebige Einheiten angepasst werden. Hierzu können Umrechnungsfaktoren


Carrara

Poser 3DS Max MotionBuilder FBX2Cal3DAvatar

Designer

Retarget

PZ3

FBX ohne Materialien

OBJ / MTL

CMF

Cal3DFBXFBXOBJ/MTL

CMF

Modellierung

Animation

Aufbereitung / Konfiguration

BVH Animationen

Medien-Bibliothek (Modelle, Animationen, Audio)

MAX WAV BVH

Abbildung 4.3: Programme und Datenformate für die Avatar-Modellierung und Ani-mation

angegeben werden, die die verwendeten Einheiten an die internen Werte anpassen.Auf diese Weise kann die für MotionBuilder benötige Vorgabe kon�guriert werden (imMenü: Customize . Units Setup ... . System Units Setup . 1 Unit = 1 cm).

In 3D Studio Max werden beispielsweise die Daten von Poser und Carrara weiterverar-beitet. In beiden Fällen stimmt die Skalierung der importierten Modelle nicht. Je nachQuelle des Modells können aber einheitliche Skalierungswerte gefunden werden. Dabeisollten Poser-Modelle um 24.000% und Carrara Modelle um 1.200% vergröÿert werden.

4.2 Programme und Datenformate für die Avatar Mo-dellierung

Abbildung 4.3 zeigt eine Gesamtübersicht der verwendeten Programme und Datenfor-mate, mit denen exemplarisch animierte Avatare für das Avatar-System erzeugt werdenkönnen. In diesem Kapitel wird nur der erste Teil der Gesamtübersicht behandelt. DieBeschreibungen der Animation und Kon�guration folgen in den Kapiteln 5 und 6.

An der Modellierung sind die Programme Poser, Carrara und 3D Studio Max betei-ligt, da sich mit diesen Programmen auf einfache Weise die erforderlichen Daten fürSkelett, sichtbares Modell, Morph-Ziele sowie Skinning erstellen lassen. Das ProgrammPoser dient hierbei als Ausgangsbasis für die Erstellung eines Avatars, da es eine groÿeAuswahl an Modellen bietet, die durch interpolierende Techniken modi�ziert werdenkönnen. Obwohl in Poser alle benötigten Daten vorliegen, gibt es keine Möglichkeit,diese direkt zu exportieren. Daher werden die Programme Carrara und 3D Studio Maxverwendet, um die verfügbaren Daten zu einem animierbaren Avatar zusammenzufü-gen.

Statt Poser und Carrara können aber auch direkt Avatar-Bibliotheken wie �CompleteCharacters� oder �Complete Soldiers� [68, 69] verwendet werden. In diesem Fall wird


Arbeitsschritt Kommentar

Verzweigung

Bedingung 2Bedingung 1

Objekt[Status]

a)

b)

c)

d)

e)

f)Schleife

Arbeitsablauf

+

Start

Ende

Abbildung 4.4: Verwendete Symbole für Arbeitsabläufe

nur 3D Studio Max benötigt, um die Modelle für die Weiterverarbeitung in Motion-Builder vorzubereiten. Als weitere Möglichkeit bleibt noch, die Modelle von Grund aufin 3D Studio Max zu modellieren.

Bei den Datenformaten wurden entsprechend den Ergebnissen aus Abschnitt 2.6 dasWavefront OBJ, sowie das FBX Format ausgewählt. Durch die weite Verbreitung die-ser Formate besteht so die Möglichkeit, weitere Programme in die Arbeitsabläufe zuintegrieren.

4.3 Dokumentation der Arbeitsabläufe

Wie in Abschnitt 3.2 vorgesehen, werden die folgenden Arbeitsabläufe durch BPMNDiagramme dokumentiert, die um Vor- und Nachbedingungen ergänzt werden. Hier-bei haben alle der im folgenden beschriebenen Arbeitsabläufe die gleiche Struktur.Zunächst wird eine Kurzbeschreibung sowie ggf. ein Kurzname des Arbeitsablaufs ge-geben. Auf die Kurzbeschreibung folgen benötigte Anwendungen, Vor- und Nachbe-dingungen, sowie der Arbeitsablauf als BPMN Diagramm.

Für die Diagramme wird eine Untermenge der BPMN Symbole verwendet (siehe Ab-bildung 4.4) . Jeder Arbeitsablauf besteht aus mehreren Arbeitsschritten (a). Arbeits-schritte sind beispielsweise der Aufruf einer bestimmten Funktion oder eine bestimmteTätigkeit im Programm. Sollen Aufrufhinweise oder Parameter zu einem Arbeitsschritthinzugefügt werden, werden sie als Kommentar links oder rechts von dem Symbol darge-stellt. Da bei den folgenden Arbeitsabläufen ausnahmslos englischsprachige Programmeeingesetzt werden, werden Programm-Funktionen und Optionen in englisch angegeben.Bei Optionen werden immer nur diejenigen Optionen aufgezählt, die aktiviert werdenmüssen. Optionen, die nicht erwähnt werden, sind daher deaktiviert.

Wird nichts weiteres angegeben, wird in einem Arbeitsablauf immer das aktuelle Ob-jekt bearbeitet. Gelegentlich müssen in einem Arbeitsablauf aber auch unterschiedlicheObjekte identi�ziert werden. Hierzu kann das Objekt-Artefakt der BPMN verwendetwerden (b). Alternativ werden in den Beschreibungen auch die zwei folgenden Notatio-nen verwendet, um die Arbeitsabläufe platzsparender darzustellen. Wird ein benanntes


Objekt erzeugt, so wird zunächst der Name des Objekts, gefolgt von einem Gleichheits-zeichen und dem erzeugenden Arbeitsschritt angegeben.

Beispiel: Modell = OBJ Datei laden.

Bezieht sich ein Arbeitsschritt auf ein benanntes Objekt, so wird die Name des Objektsgefolgt von einem Doppelpunkt und dem Arbeitsschritt angegeben. Hierbei könnenauch mehrere Namen aufgezählt werden, wenn sich der Arbeitsschritt auf mehrereObjekte bezieht.

Beispiel : Modell: Modell korrigieren

Mehrere Arbeitsschritte können zu einem Arbeitsablauf zusammengefasst werden (b).Innerhalb eines Arbeitsablaufs kann auf weitere Arbeitsabläufe referenziert werden. ZurIdenti�zierung des Arbeitsablaufs kann dessen Kurzname angegeben werden. SollenArbeitsschritte wiederholt werden, so können sie zu einer Schleife (c) zusammengefügtwerden. Die Bedingung für die Ausführung der Anweisungen innerhalb der Schleifewerden links/oben in dem Symbol angegeben.

Die Reihenfolge der Arbeitsschritte wird durch Verbindungspfeile angegeben. Arbeits-abläufe starten mit dem Startsymbol (d) und enden, sobald ein Endsymbol (e) erreichtwird. Einzige Ausnahme ist eine bedingte Verzweigung (f), die als Raute dargestelltwird. Innerhalb der Raute wird die Bedingung wiedergegeben. Von der Raute könnenmehrere Pfeile verzweigen, wobei an jedem Pfeil die zutre�ende Bedingung vermerktwird.


4.4 Arbeitsabläufe zur Avatar-Modellierung

Kurzbeschreibung: Vorbereitung von Avataren aus einer Modellbibliothek oder Er-stellung eines Modells mit Poser.

Anwendungen: 3D Studio Max 8 SR 3, Poser 6 SR 2, Carrara 5

Vorbedingung: Eine Modellbibliothek mit animierbaren Avataren, alternativ die Pro-gramme Poser und Carrara.

Nachbedingung: Ergebnis ist ein animierbares Avatar-Modell im FBX-Format.

Arbeitsablauf

AnimierbaresModell?

Nein

Ja

Modell in 3D StudioMax laden

Modellierungmit Poser

+

Morph-Zielemit Poser

+

Poser inFBX wandeln

+

Poser Modellaufbereiten

+

FBX Export

+

Modell korrigieren

+

Modell[animierbar]

Modell[animierbar]

Abbildung 4.5: Erstellung von animierbaren Avatar-Modellen

Ergänzende Hinweise

keine


4.4.1 Modellierung mit Poser

Kurzbeschreibung: Erstellung der Avatar-Geometrie mit Poser.

Anwendungen: Poser 6 SR 2

Nachbedingung: Geometrie des Modells imWavefront OBJ-Format, sowie eine PoserProjektdatei.

Arbeitsablauf

Modell erstellen

IK ausschalten

Gelenke aufNull-Stellung

Opt: manuelleKorrektur T-Pose

Opt: zusätzlicheElemente hinzufügen

OBJ exportieren

Speichernals PZ3

Figure > Use IK

Windows > Joint Editor > Zero Figure

Include figure names in polygon-groupsWeld body part seams

Zusätzliche Elemente wie Haare,Kleidung, etc. hinzufügen und andas Modell binden (Figure > Conform to ...)

Modell[aus Poser]

Modell[statisch]

Abbildung 4.6: Modellierung mit Poser



Zusätzliche Elemente wie Haare und Kleidung be�nden sich in dem Modellbibliotheken�Hair� und �Props�. Sie werden standardmäÿig nicht an das Modell gebunden, sondernmüssen manuell angebunden werden (Figure . Conform to). Haare des Typs �Strand�und Kleidung des Typs �Dynamic� sollten nicht ausgewählt werden, da sie nicht korrektexportiert werden können!

Die inverse Kinematik sollte in jedem Fall ausgeschaltet werden, da die End-E�ektorennicht durch die �Zero Figure� Funktion beein�usst werden. Da sie fest stehen bleiben,verfälschen sie die Null-Stellung der Gelenke. Insbesondere sollte an dieser Stelle auchdarauf geachtet werden, dass die Finger der Hände sich in der richtigen Grundstellungbe�nden (siehe Abbildung 4.2 (b)), da hier die einzige Möglichkeit besteht, Fehlstel-lungen zu korrigieren.

Je nach Verwendungszweck emp�ehlt es sich, das Modell bei dem Export in mehrereBestandteile zu zerlegen. Ist Gesichtsanimation erwünscht, sollte das Modell zumindestin Kopf, Augen und Körper zerlegt werden. Bei Bedarf kann der Körper noch zusätzlichunterteilt werden, wodurch Avatare �exibler kon�guriert werden können. Hierzu kann indem Export-Dialog von Poser detailliert angegeben werden, welche Elemente exportiertwerden sollen.


4.4.2 Erstellung von Morph-Zielen mit Poser

Kurzbeschreibung: Erstellung von Morph-Zielen mit Poser.


Vorbedingung: Avatar in T-Stellung, bzw. Poser Projektdatei des Avatars (PZ3).

Nachbedingung: Morph-Ziele für die Gesichtsanimation im Wavefront OBJ Format.

Arbeitsablauf

Schleife

Kopf auswählen

PZ3 Datei laden

Morph-Zielemischen

Export OBJInclude figure names in polygon-groupsWeld body part seams

Morph-Ziele für Viseme:siehe Tabelle

Für jedes Morph-Ziel ...

Morph-Ziel[statisch]

Abbildung 4.7: Erstellung von Morph-Zielen mit Poser


Bei der Modellierung ist darauf zu achten, dass nur Morph-Ziele miteinander kombiniertwerden können, die die gleiche geometrische Struktur aufweisen. Das Modell sollteauÿerdem auf keinen Fall mehr bewegt werden, da es sonst zu verschobenen Morph-Zielen kommen kann. Für die spätere Sprachausgabe sind in Abbildung 4.8 die 15Viseme mit den in Poser notwendigen Morph-Zielen angegeben.


Abbildung 4.8: Viseme für deutsche Sprachanimation


4.4.3 Konvertierung von Poser Daten in das FBX Format

Kurzname: Poser in FBX wandeln

Anwendungen: Poser 6 SR 2, Carrara 5

Kurzbeschreibung: Konvertierung von Poser Projektdateien in das FBX-Format.

Vorbedingung: Poser Projektdatei (PZ3) ist vorhanden.

Nachbedingung: Ergebnis ist das Modell mit Skelett und Skinning-Informationen imFBX-Format (ohne Materialien).

Arbeitsablauf

PZ3 Dateiöffnen

Nativen Importer verwenden Keine Optionen aktivieren Creasing Angle = 50°

FBX Dateiexportieren FBX Version 6.0, binär

Modell[aus Poser]

Modell[ohne Materialien]

Abbildung 4.9: Konvertierung von Poser Daten in das FBX Format


Carrara wird nur für die Konvertierung benötigt, d.h. es wird nur das Modell in Carrarageladen und anschlieÿend die gesamte Szene unverändert im FBX-Format exportiert.


4.4.4 Aufbereitung eines Poser Modells

Kurzname: Poser Modell aufbereiten

Anwendungen: 3D Studio Max 8 SR 3

Kurzbeschreibung: Mit diesem Arbeitsablauf kann ein animierbares Poser Modelldurch Kombination von statischen Modellen im Wavefront OBJ-Format mit ani-mierbaren Modellen im FBX Format erstellt werden.

Vorbedingung: Die Geometrie und Materialien des Modells müssen im WavefrontOBJ-Format, sowie Skelett und Geometrie mit Skinning-Informationen im FBX-Format vorliegen.

Nachbedingung: Ergebnis ist ein animierbares Avatar-Modell in 3D Studio Max.

Arbeitsablauf

FBX =FBX importieren

OBJ =OBJ importieren

MergeImportieren: Bones, Geometries, Skin, Shape

Import multipleOptionen: Rotate, Texture coord., normals, unify, use materials

OBJ: Element undSkinData_FBX:

auswählen

Gewichteübertragen

SkinData_FBX =FBX: Gewichte

extrahieren

Utilities Panel >Skin Utilities >Extract Skin Data To Mesh

Skin Utilities >Import Skin Data From MeshMatch by VertexFBX: und OBJ:

in Übereinstimmungbringen

SieheErgänzendeHinweise

OBJ: Vorbereitenfür Animation

+

FBX:Modell korrigieren

+

OBJ:Modell korrigieren

+

Für jedes OBJ: Element

Abbildung 4.10: Aufbereitung eines Poser Modells


Dieser Arbeitsablauf basiert darauf, dass die Geometrie aus der FBX-Datei mit derGeometrie aus der Wavefront OBJ-Datei übereinstimmt. Da 3D Studio Max in diesem


Abbildung 4.11: Korrektur der Handstellung in 3D Studio Max

Fall die Skinning-Informationen von einer Geometrie auf eine andere übertragen kann,können so Skelett und Skinning-Informationen aus der FBX-Datei mit dem statischen,aber mit korrekten Materialien ausgestatteten Modell aus der OBJ-Datei kombiniertwerden. Hierzu ist es notwendig, die beiden Modelle so gut wie möglich in Überein-stimmung zu bringen. Neben einer äquivalenten Skalierung, Rotation und Translationkann ggf. auch eine Manipulation der Gelenke des FBX-Modells notwendig sein, umeine Übereinstimmung herzustellen (siehe Abbildung 4.11).

Die Übertragung der Skinning-Informationen wird durchgeführt, indem zunächst dieInformationen aus dem FBX-Modell extrahiert werden. Dadurch entsteht eine Kopie,die zwar keine direkte Beziehung zu dem ursprünglichen Skelett hat, aber die Ge-wichtungen der Gelenke enthält (siehe Abbildung 4.12). Von dem FBX-Modell wirdjetzt nur noch das Skelett benötigt, so dass die ursprüngliche FBX-Geometrie gelöschtwerden kann.

Es können jetzt der Reihe nach die Skinning-Informationen auf die Elemente der OBJ-Datei übertragen werden. Hierzu wird die Kopie mit den Skinning-Informationen undein OBJ-Element ausgewählt. Mit der Funktion �Import Skin Data to Mesh� wird der�Paste Skin Data�-Dialog aufgerufen (siehe Abbildung 4.13). Da beide ausgewähltenModelle das gleiche Skelett, sowie die gleiche Eckpunkte-Struktur haben, können dieGelenke durch ein �Match by Name� und die Gewichte durch die Option �Match byVertex� einander zugeordnet werden.


Abbildung 4.12: Extrahieren der Skinning-Informationen

Abbildung 4.13: Übertragung der Skinning-Informationen


4.4.5 Korrektur eines Modells

Kurzname: Modell korrigieren


Kurzbeschreibung: Mit diesem Arbeitsablauf kann ein Modell so korrigiert werden,dass es den Anforderungen bezüglich der Grundstellung entspricht.

Vorbedingung: Ein statisches oder dynamisches Modell in 3D Studio Max.

Nachbedingung: Ein korrigiertes Modell in 3D Studio Max.

Arbeitsablauf

Modellskalieren

Modell rotieren:Gesicht vorne

Modell ver-schieben:

Füße in Ursprung

ÜberflüssigeGeometrieentfernen

Normalenkorrigieren

Poser: 24000 %Carrara: 1200%

Carrara: Z -90°

Carrara: Z -4,086

Poser: äußere Augenhülle

Test: Rendern des Modells, "Force 2 sided" deaktiviert

Abbildung 4.14: Korrektur eines Modells


Bevor die Skalierung durchgeführt wird, sollte sichergestellt werden, das in 3D StudioMax die Einheiten entsprechend der Empfehlung in Abschnitt 4.1.4 vorgenommen wur-den. Die korrekte Gröÿe kann mit dem �Measure Tool� im �Utilities Panel� überprüftwerden.


Abbildung 4.15: Beispiel für fehlerhafte Normalen-Vektoren (links). Rechts ist die kor-rekte Darstellung zu sehen.

Carrara-Modelle sind an ein Hilfs-Objekt mit dem Namen �FBX_Root� gebunden.Für die Korrektur reicht es aus, dieses Objekt zu manipulieren, da sich Änderungenautomatisch auf die angehängten Objekte auswirken. Nach der Korrektur können alleHilfs-Objekte entfernt werden.

Wird ein Poser-Modell in mehrere Wavefront OBJ-Dateien zerlegt, sollten die Kor-rekturen der Reihe nach an den einzelnen Elementen durchgeführt werden, da sonstnachträglich die Füÿe des Avatars wieder in den Ursprung verschoben werden müssen.

Ein häu�ges Problem beim Import von Geometriedaten sind Normalen, die der ur-sprünglichen Richtung entgegengesetzt sind (siehe Abbildung 4.15). In diesem Fallwird nicht die Ober�äche der Geometrie gezeigt, sondern die Innen�äche, wie es beidem linken Paar Schuhe in der Abbildung der Fall ist. Damit der Fehler in 3D StudioMax sichtbar wird, darf nicht die Anzeigeeinstellung �Force 2 Sided� aktiviert sein. DerFehler kann mit der �Flip Normals� Funktion im Modify-Panel behoben werden.

Transparente Flächen, die nicht mit einer Transparenz-Maske versehen sind, könnenebenfalls zu Problemen bei der späteren Echtzeitdarstellung führen. Diese werden bei-spielsweise für die äuÿere Hülle der Augen der Poser-Modelle verwendet. Da sie kom-plett durchsichtig sein sollen, können sie auch entfernt werden.


4.4.6 Vorbereiten eines Modells für die Animation

Kurzname: Vorbereiten für Animation


Kurzbeschreibung: Ziel dieses Arbeitsablaufs ist die Vorbereitung eines statischenModells für die skelettbasierte Animation. Auÿerdem können Elemente des Mo-dells, beispielsweise der Kopf, für Morphing vorbereitet werden.

Vorbedingung: Das statische Modell, Morph-Ziele, sowie das Skelett sind in 3D Stu-dio Max vorhanden.

Nachbedingung: Ergebnis ist ein animierbares Modell in 3D Studio Max. In derRegel sind noch Feineinstellungen nötig.

Arbeitsablauf

Modell Elementauswählen

Morpherhinzufügen

Alle Elementeauswählen

Skin hinzufügen

Boneshinzufügen

Modify Panel > Morpher

Modify Panel > Skin

Modify Panel > Skin : Add bones

Für jedes Element mitMorphing ...

Abbildung 4.16: Vorbereiten eines Modells für die Animation


Die Zuweisung des Morph-Modi�zierers in 3D Studio Max sollte vor der Zuweisung desSkin-Modi�zierers erfolgen. Dies kann auch erfolgen, wenn Morph-Ziele erst zu einemspäteren Zeitpunkt hinzugefügt werden sollen.

In der Regel werden durch das bloÿe Hinzufügen der Gelenke zu dem Modell noch keinekorrekten Skinning-Informationen erzeugt. Diese müssen entweder manuell korrigiertoder von einer Vorlage auf das Modell kopiert werden (siehe 4.4.4).


4.4.7 Export eines Modells in das FBX-Format

Kurzname: FBX Export


Kurzbeschreibung: Mit diesem Arbeitsablauf wird ein animierbares Modell aus 3DStudio Max in das FBX Format exportiert.

Vorbedingung: Ein animierbares Modell in 3D Studio Max.

Nachbedingung: Ergebnis ist ein animierbares Avatar-Modell im FBX-Format.

Arbeitsablauf

Hilfsobjekteentfernen

Skelett undGeometriegruppieren

Reference:exportieren als

FBX

Carrara: alle (FBX_Root, ...)

Export: Geometries, Geometries used as bones, exported as bones, Shape (Morph modifier) Skins (Skind modifier and Physique)

Reference

Modell[animierbar]

Abbildung 4.17: Export eines Modells in das FBX-Format


Vor dem Export müssen Skelett und Geometrie unbedingt zu einer Gruppe mit demNamen �Reference� zusammengefügt werden (siehe Abbildung 4.18). Falls eine Grup-pierung nicht möglich ist, sollte überprüft werden, ob das Skelett eventuell hierarchischvon anderen Objekten abhängt. Dies ist beispielsweise bei Carrara-Modellen der Fall,bei denen das Skelett an zwei Hilfsobjekte (Helper) gebunden ist. Diese Hilfsobjektekönnen problemlos entfernt werden, wodurch eine Gruppierung möglich wird.

Bei dem Export kann es zu Warnmeldungen kommen. Warnmeldungen bezüglich nichtgefundenen Texturen können ignoriert werden. Auch die Meldung �The node 'Reference'does not have a valid InitTM� kann mit �Yes� bestätigt werden.


Abbildung 4.18: Export eines Avatar-Modells aus 3D Studio Max


Kapitel 5

Animation von Avataren

Wie im Konzept beschrieben, unterscheidet das Avatar-System zwei Arten von Anima-tionen, nämlich O�ine- und Online-Animationen. O�ine-Animationen sind auÿerhalbder Laufzeit erzeugte Animationen. Hierbei kann es sich sowohl um kurze Animati-onsfragmente, als auch um komplette Animationssequenzen handeln. Diese Animatio-nen können zur Laufzeit aufgerufen und miteinander gemischt werden, um Online-Animationen zu erzeugen.

In diesem Kapitel wird die Erzeugung der O�ine-Animationen beschrieben. Hierbeihandelt es sich sowohl um die Erzeugung der Körperanimation, als auch die Animationdes Gesichts zur Sprachausgabe. Da eine möglichst einfache und realistische Animati-on angestrebt wird, werden hierzu drei Animationstechniken eingesetzt. Zur Animati-on des Körpers werden MOCAP Daten und parametrische Animation verwendet. DasGesicht wird durch die Analyse von Sprachaufzeichnungen animiert. Es werden da-her Bewegungs- und Audiodaten benötigt, um die Animationen durchzuführen. Diesemüssen so umgeformt werden, dass verwendbare O�ine-Animationen erzeugt werdenkönnen.

Im folgenden werden einige Hinweise zur Animation gegeben. Hierbei handelt es sichum Hinweise zur Bescha�enheit der Bewegungs- und Animationsdaten. Es folgt danneine Übersicht über die verwendeten Programme, sowie die Datenformate, die für denAustausch der Informationen verwendet werden. Hieran schlieÿen die Arbeitsabläufean.

5.1 Grundsätzliche Hinweise zur Animation von Ava-taren

5.1.1 Struktur der Bewegungsdaten

Bewegungsdaten bestehen meist aus einem Skelett, sowie Bewegungsdaten für die-ses Skelett in Form von Rotationswinkeln und Verschiebungen für die Gelenke. Auchwenn ein Skelett nicht explizit vorgegeben ist - beispielsweise indem nur die bei einerMOCAP-Aufzeichnung erkannten Marker-Positionen gespeichert werden - , können ausdiesen Daten das Skelett, sowie die Bewegung zurückgerechnet werden.

97

98 KAPITEL 5. ANIMATION VON AVATAREN

Bewegungsinformationen werden als Key-Frames gespeichert, d.h. zu bestimmten Zeit-punkten werden jeweils die Daten für die Gelenke hinterlegt. Diese Hinterlegung erfolgtmeist in festen, zeitlichen Abständen. Üblich sind 30 Frames pro Sekunde. Zum Ab-spielen der Animation werden die Bewegungsdaten zu den gegebenen Zeiten auf dasSkelett übertragen, wodurch sich dieses bewegt.

Damit die Bewegungsinformationen weiterverarbeitet werden können, muss die Ske-lettstruktur den gleichen Aufbau haben, wie in Abschnitt 4.1.1 beschrieben. D.h. siemuss zumindest aus den 15 Basis-Gelenken aufgebaut sein. Die Hierarchie muss vonder Hüfte ausgehen, wobei nur diese verschoben und rotiert werden darf. Alle anderenAnimationswerte sollten Rotationen für die Gelenke sein.

Unterscheiden sich das Skelett der Animation und das Skelett des Modells - beispiels-weise durch eine unterschiedliche Anzahl an Gelenken oder unterschiedliche Abständezwischen den Gelenken - , kann eine Animation nicht direkt zur Bewegung des Modellsverwendet werden. Sie muss erst durch einen Retarget-Prozess angepasst werden.

5.1.2 Gesichtsanimation mit Audiodaten

Soll eine Gesichtsanimation mit Audiodaten erfolgen, wird zum einen ein Avatar-Modellbenötigt, welches Gesichtsanimation unterstützt. Andererseits wird eine Sprachaufnah-me benötigt. Zur Animation wird diese Sprachaufnahme einer Analyse unterworfen, umdie verwendeten Phoneme zu erkennen. Damit diese Erkennung möglichst fehlerfreifunktioniert, sollte die aufgenommene Stimme gut erkennbar sein. Dies bedeutet, dassnur eine Stimme aufgezeichnet werden darf und keine anderen Hintergrundgeräuschevorkommen sollten.

Nach der Erkennung der Phoneme wird die Gesichtsanimation dadurch realisiert, dassbestimmte Viseme in Form von Morph-Zielen aktiviert werden. Hierzu wird eine Zu-ordnung der Phoneme zu den Visemen benötigt. In dieser Arbeit werden die 15 Vise-me verwendet, die bereits während der Modellierung erzeugt wurden (siehe Abschnitt4.4.2).

Wie bei der Körperanimation auch, kann die Gesichtsanimation in Form von Key-Frames gespeichert werden. Dazu werden zu bestimmten Zeitpunkten Gewichtungs-faktoren der aktivierten Viseme gespeichert. Die Gewichtungsfaktoren geben hierbeian, wie stark ein Visem in das Endergebnis eingemischt werden soll.

5.2 Programme und Datenformate zur Animation vonAvataren

Zur Erzeugung der Animationen wurden im Konzept die Programme MotionBuilderund Poser ausgewählt (siehe Abbildung 5.1). MotionBuilder eignet sich besonders fürdie Erzeugung der O�ine-Animationen, da es direkt mit MOCAP-Daten arbeiten kannund vielfältige Bearbeitungsmöglichkeiten bietet. Hierzu gehört auch das automatischeAnpassen unterschiedlicher Skelettstrukturen. Es unterstützt auÿerdem die Gesichtsa-nimation mit Sprachdateien, so dass alle O�ine-Animationen mit diesem Programmerzeugt werden können. Poser wurde exemplarisch ausgewählt, da es parametrische

KAPITEL 5. ANIMATION VON AVATAREN 99


MAX WAV BVH

Carrara


Designer

Retarget

PZ3


OBJ / MTL

CMF

Cal3DFBXFBXOBJ/MTL

CMF

BVH AnimationenModellierung

Animation



Laufbewegungen erzeugen kann. Es dient als Beispiel dafür, wie Bewegungsgenerato-ren in die Arbeitsabläufe integriert werden können. Stattdessen könnten auch andereProgramme eingesetzt werden, die Animationen im BVH-Format liefern. Dies könnteMOCAP-Software oder Endorphin [56] zur dynamischen Simulation sein. Alternativkönnen die Animationen auch aus einer Bewegungsbibliothek stammen.

Bei den Datenformaten wurden entsprechend den Ergebnissen aus Abschnitt 2.6 dasBVH, sowie das FBX Format ausgewählt. Durch die weite Verbreitung dieser Formatebesteht so die Möglichkeit, weitere Programme in die Arbeitsabläufe zu integrieren.Hinzu kommen Audiodateien im WAV-Format, die die Sprachaufzeichnungen enthal-ten.

Die folgenden Arbeitsabläufe werden wie in Abschnitt 4.3 dargestellt dokumentiert.Sie haben das Ziel, Aktionen, Zyklen und Transitionen für die Körperanimation, sowieDaten für die Sprachanimation zu erzeugen.


5.3 Arbeitsabläufe zur Avatar-Animation

Kurzbeschreibung: Animation eines Avatar-Modells mit MOCAP oder Audio-Daten.

Anwendungen: MotionBuilder 7, Poser 6 SR 2

Vorbedingung: Animierbares Avatar-Modell im FBX-Format.

Nachbedingung: O�ine-Animation im FBX-Format.

Arbeitsablauf

Animation?mit Audio

mit FBX

mit BVH

Modellvorbereiten

+

Parametrisch?

Animation

+

Sprachanimation

+

ParametrischeAnimation

+

Ja

Nein

BVH aufbereiten

+

Abbildung 5.2: O�ine-Animation von Avatar-Modellen


Keine.


5.3.1 Vorbereitung des Avatar-Modells für die Animation

Kurzbeschreibung: Vorbereiten eines Avatar-Modells für die Animation mit Moti-onBuilder. Nach Abschluss des Arbeitsablaufs können sowohl Körperanimation,als auch Gesichts- und Sprachanimation durchgeführt werden.

Anwendungen: MotionBuilder 7

Vorbedingung: Animierbares Avatar-Modell im FBX-Format.

Nachbedingung: Mit MotionBuilder animierbares Avatar-Modell im FBX-Format.

Arbeitsablauf

FBX Modellladen

Charakterisieren

+

Gesichts-animation?

Ja

Nein

"Character Face"hinzufügen

"Voice Device"hinzufügen

ZuordnungViseme - Shapes

FBX Modellspeichern

Templates > Characters > Character face

Templates > Devices > VoiceViseme (Englisch): AE, AO, B, D, F, FV, G, H, IY, K, KG, L, M, N, OW, P, PB, S, SH, SZ, SZH, T, TD, UH, UW, V, Z, ZH

Character Faces > Character Face > Character Face Definition

Modell[animierbar]

Modell[Charakterisiert,

Voice]

Abbildung 5.3: Vorbereitung des Avatar-Modells für die Animation


Durch diesen Arbeitsablauf wird ein voll animierbares Modell erstellt. Für die Gesichts-animation mit Audiodaten benötigt MotionBuilder eine Zuordnung von Phonemen zuVisemen. Hierzu stellt MotionBuilder insgesamt zwei unterschiedliche Phonem-Sätze


Phonem Visem Phonem Visem Phonem Visem Phonem Visem

AE A H R OW O T T

AO O IY E P P TD T

B P K T PB P UH U

D T KG T S S UW U

F F L N SH Z V F

FV F M M SZ S Z Z

G T N N SZH Z ZH Z

Tabelle 5.1: Zuordnung der MotionBuilder Phoneme zu deutschen Visemen

bereit. Der eine Phonem-Satz repräsentiert Phoneme der englischen Sprache, der an-dere Phoneme, die anderen Sprachen gemeinsam sind. Da die Avatare deutsche Textewiedergeben sollen, wurde daher zunächst der internationale Phonem-Satz ausgewählt.Dieser enthält jedoch keine Konsonanten, weswegen nur eine kleine Menge der verfüg-baren 15 Viseme verwendet werden konnten. Dementsprechend waren die Ergebnisseauch nicht zufriedenstellend.

In einem zweiten Ansatz wurde daher der englische Phonem-Satz ausgewählt, der zu-sätzlich Konsonanten enthält. Bei der Zuordnung der Phoneme zu den Visemen wur-de darauf geachtet, die Phoneme entsprechend den deutschen Lauten zuzuordnen. Sowurde das Phonem �UH� wie in dem englischen Wort �boot� (Stiefel), dem Visem �U�zugeordnet. Tabelle 5.1 enthält die komplette Zuordnung der Phoneme zu Visemen. Indieser Tabelle konnten 12 der 15 verfügbaren Viseme verwendet werden. Nicht verwen-det wurden die Viseme �C�, �Q� und �Y�. Diese Zuordnung liefert bessere Ergebnisse.


5.3.2 Charakterisierung des Avatar-Modells

Kurzbeschreibung: Durchführung des Charakterisierungsprozesses, damit ein Avatar-Modell oder eine Animation in MotionBuilder verwendet werden kann.


Vorbedingung: Animierbares Avatar-Modell.

Nachbedingung: Mit MotionBuilder animierbares Avatar-Modell.

Arbeitsablauf

Template > Characters > Character

Benennungder Bones?

eigenes Schema / keine Vorlage

"Character"hinzufügen

"Merge CharacterTemplate"

"Character"hinzufügen

Bones manuellzuordnen

"Naming Template"extrahieren

"Character Temp-late" exportieren

Bones auf"Character" ziehen

KorrekturT-Pose

Charakterisierungabschließen

eigenes Schema

MotionBuilderSchema

Modell[charakterisiert]

Characters > Character > Character Definition: Extract Naming Templ.

Nur Character auswählen,File > Save Selection ...

Modell[animierbar]

Abbildung 5.4: Charakterisierung des Avatar-Modells



Durch die Charakterisierung werden in MotionBuilder jedes Modell und jede Animationmit einer einheitlichen Abstraktionsschicht versehen. Diese ermöglicht es, dass Moti-onBuilder die Bewegungen zwischen charakterisierten Objekten austauschen kann.

Damit eine Charakterisierung möglich wird, muss MotionBuilder die Struktur des Ske-letts erkennen können. Dies wird dadurch erreicht, dass vorgegebene Namen für die Ge-lenke verwendet werden (siehe Abbildung 4.1 (a)). Werden nicht die Standard-Namenfür die Gelenke verwendet, kann auch eine eigene Zuordnung durch manuelle Zuordnungder Gelenke erzeugt werden. Diese manuelle Zuordnung kann auch als Vorlage gespei-chert werden, wodurch nachfolgende Charakterisierungsprozesse bei Skeletten mit dengleichen Gelenknamen beschleunigt werden können.

Zusätzlich muss das Skelett in der T-Stellung sein, wenn es charakterisiert wird. Hier-durch kann MotionBuilder die lokalen Koordinatensysteme der Gelenke auf ein ein-heitliches System umrechnen kann. Sollte das Skelett nicht in T-Stellung sein, kann esmeist einfach in diese Stellung gebracht werden, indem alle Gelenke ausgewählt unddann alle Rotationen auf Null zurückgesetzt werden (rechte Maustaste . Zero . Ro-tation). Sollte die T-Stellung dann immer noch nicht stimmen, müssen die Gelenkemanuell in die richtige Stellung gebracht werden.


5.3.3 Animation eines Avatar-Modells mit einer vorhandenenAnimation

Kurzbeschreibung: Animation eines Avatar-Modells mit einer vorhandenen Anima-tion im FBX-Format.


Vorbedingung: Ein vorbereitetes Avatar-Modell, sowie eine vorbereitete Animationim FBX-Format.

Nachbedingung: FBX-Datei, in der sich die auf das Modell angewendete Animationbe�ndet.

Arbeitsablauf

Characters > Modell Character > Character Settings : Input Type = Character, Source = Animation Character

VorbereitetesFBX Modell

laden

Animation zurSzene hinzufügen

Modell[charakterisiert, Voice]

Animation[charakterisiert]

Modell mit Animation[Charakterisiert]

animieren

Modell[animiert]

Animation aufSkelett plotten

Animation[Charakterisiert]

entfernen

GeplotteteAnimation

exportieren

Modell[geplottet]

Animation(FBX)

Modell Character > Character Settings > Plot Character ... : Skeleton, Unroll, Translation on Root only

Schemativ View > Animation auswählen, entfernen

File > Export ... : FBX (Animation only)

File > Merge ...

Abbildung 5.5: Animation eines Avatar-Modells mit einer vorhandenen Animation


Abbildung 5.6: Optionen zur Umwandlung einer Körperanimation in Key-Frames


Mit diesem Arbeitsablauf kann ein Modell mit einer vorhandenen (MOCAP) Animati-on animiert werden. MotionBuilder übernimmt hierbei automatisch das Retargettingder Animationen. Gegebenenfalls ist diese Animation noch zu bearbeiten, um sie bei-spielsweise als zyklische Animation oder Transition einsetzten zu können. Für �üssigeAnimationen können hierzu Anfangs- und Endposen gespeichert und an den passendenStellen am Ende oder Beginn einer Animation eingefügt werden.

Die fertige Animation kann nur dann weiterverarbeitet werden, wenn die Animationauf das Skelett übertragen wird. Hierzu sind die Einstellungen entsprechend Abbildung5.6 vorzunehmen.


5.3.4 Aufbereitung von MOCAP-Daten für die Avatar-Animation

Kurzbeschreibung: Aufbereitung von BVH-Daten für die Animation von Avatar-Modellen.


Vorbedingung: Eine oder mehrere BVH Dateien, die den Basis-Anforderungen be-züglich der Skelettstruktur entsprechen.

Nachbedingung: Ergebnis ist eine vorbereitete Animation im FBX-Format.

Arbeitsablauf

File > Batch ... : Input: BVH Output: FBX (animation only) Keep Character Constraint

BVH importieren

Charakterisieren

+

Batch Konvertierungstarten

BVH

BVH[charakterisiert]

BVH[charakterisiert]

BVH

Neben den Basis-Gelenken mussauch die "Reference" zugeordnet sein!

Abbildung 5.7: Aufbereitung von MOCAP-Daten für die Avatar-Animation


MOCAP Daten aus externen Programmen müssen - wie Modelle auch - zunächst cha-rakterisiert werden. Hierzu wird die T-Stellung des Skeletts benötigt, die meist nichtseparat vorliegt. Da bei vielen MOCAP-Systemen die Kalibrierung ebenfalls in T-Stellung - bzw. einer leicht abgewandelten Stellung, bei der die Arme parallel zumOberkörper angelegt sind - durchgeführt wird, kann sie durch Nullsetzen der Rotatio-nen der Gelenke rekonstruiert werden. Hierbei geht jedoch die Animation verloren.


Abbildung 5.8: Einstellungen zur Batch-Konvertierung von Animationen

Das so charakterisierte Skelett kann dazu verwendet werden, um BVH-Dateien mit glei-cher Skelettstruktur in einem Batch-Prozess zu konvertieren. Hierdurch können BVH-Sammlungen schnell in das FBX Format überführt werden und sind direkt einsatzbe-reit. Die Einstellungen der Batch-Konvertierung sind gemäÿ Abbildung 5.8 vorzuneh-men. Bei �Character� muss das Skelett ausgewählt werden, welches zuvor charakterisiertwurde.


5.3.5 Erzeugung parametrischer Laufanimationen

Kurzbeschreibung: Erstellung von parametrischen Laufanimationen mit Poser.


Vorbedingung: Ein mit Poser erstelltes Avatar-Modell.

Nachbedingung: Laufanimation für das Avatar-Modell im BVH-Format.

Arbeitsablauf

Pfad erstellenund ausrichten

"Walk Designer"aufrufen und

Gang festlegen

Gang ausführen

BVH exportieren

Modell laden

Modell(PZ3)

BVH

Figure > Create Walk Path ...

Window > Walk Designer ...

Apply: Follow path Always complete last step

File > Export BVH: Scale automatically

Abbildung 5.9: Erzeugung parametrischer Laufanimationen


Mit dem Gang-Designer von Poser kann eine Vielfalt von Laufbewegungen erzeugtwerden, indem bestimmte Laufcharakteristiken miteinander gemischt werden. Da dieAnimation als BVH-Datei gespeichert werden kann, kann sie wie jede andere BVH-Datei in MotionBuilder weiterverarbeitet werden.


5.3.6 Erzeugung von lippensynchroner (O�ine) Sprachanima-tion

Kurzbeschreibung: Erzeugung von Sprachanimationen mit Hilfe von Sprachaufnah-men.


Vorbedingung: Mit MotionBuilder animierbares Avatar-Modell im FBX-Format, so-wie eine Sprachaufnahme.

Nachbedingung: Mit Sprachaufnahmen animiertes Modell im FBX-Format.

Arbeitsablauf

VorbereitetesFBX Modell

laden

Audio Dateiimportieren

Audio Datenals Quelle fürModell Voice

Aufnahme

Animationplotten

FBX Modellspeichern

Modell[charakterisiert, Voice]

Audio

Modell[animiert]

Modell mit Animation(FBX)

Devices > Modell Voice > Source = Audio Online aktivieren

Modell Voice > Recording aktivierenRecordPlay

Modell Voice > Record, Live deaktivierenModell Character face > Character Face Animation > Plot ... Unroll

Abbildung 5.10: Erzeugung von lippensynchroner Sprachanimation


Abbildung 5.11: Optionen zur Umwandlung einer Gesichtsanimation in Key-Frames


Das Voice-Device ist ein Live-Device, d.h. einkommende Signale eines Mikrofons odereiner Audiodatei führen unmittelbar zu der Aktivierung der passenden Viseme. Damitdie Animation von externen Programmen verwendet werden kann, muss sie zunächstaufgezeichnet werden. Hierbei kann die Warnung, dass Daten überschrieben werden,ignoriert werden.

Erst nach der Aufnahme kann eine Umwandlung in Key-Frames durch Plotten derAnimation erfolgen. Hierzu sind die Einstellungen gemäÿ Abbildung 5.11 vorzunehmen.


Kapitel 6

Aufbereitung und Kon�guration von

Avataren

Entsprechend dem Konzept in Kapitel 3 müssen die aus der Modellierung und Animati-on kommenden Daten erst aufbereitet werden, bevor sie von der Laufzeitumgebung desAvatar-Systems verwendet werden können. Dies schlieÿt die Umwandlung der Datenaus dem FBX-Format in das Cal3D-Format, die Verwendung von statischer Geometrieals Kleidung, sowie die Kon�guration der Avatare ein. Zur Speicherung der Kon�gura-tion wird zum einen ein Datenformat benötigt. Auÿerdem ist eine Anwendung nötig,mit der die Kon�guration gra�sch vorgenommen werden kann.

Im folgenden werden kurz die an der Aufbereitung und Kon�guration beteiligten Pro-gramme und Datenformate beschrieben. Bei diesen Programmen konnte nicht auf exis-tierende Anwendungen zurückgegri�en werden. Daher erfolgt im Anschluss eine detail-liertere Beschreibung der im Rahmen dieser Arbeit entwickelten Programme.

6.1 Programme und Datenformate zur Kon�gurationvon Avataren für das Laufzeitsystem

Für die Aufbereitung und Kon�guration der Avatar-Daten werden drei Programmeeingesetzt (siehe Abbildung 6.1). Das Programm FBX2Cal3D dient hierbei zur Kon-vertierung der FBX Daten - in denen Modelle und Animationen vorliegen - in dasverwendete Cal3D Format.

Damit Avatare �exibler eingesetzt werden können, ist ein �exibler Austausch von Klei-dungsstücken sinnvoll. Da das System keine dynamische Kleidung unterstützt, wirdKleidung genauso gehandhabt wie die restliche Geometrie des Avatars. Daher mussauch Kleidung per Skinning an das Skelett gebunden werden. Hierbei sollte ein erneu-tes Skinning für jedes Kleidungsstück aus Zeitgründen vermieden werden. Es wurdedaher ein Programm entwickelt, welches die Skinning-Informationen von einer Geome-trie auf eine andere Geometrie ohne Skinning-Informationen übertragen kann.

Am Ende der Aufbereitung steht die Kon�guration der Avatare. Hierzu wurde ein XML-Format entwickelt, mit dem die Kon�guration eines Avatars abgespeichert werden kann.Diese Kon�gurationen können entweder manuell, mit Hilfe eines Texteditors oder mitHilfe einer gra�schen Benutzerober�äche erzeugt und bearbeitet werden.

113

114 KAPITEL 6. AUFBEREITUNG UND KONFIGURATION VON AVATAREN


MAX WAV BVH

Carrara


Designer

Retarget

PZ3


OBJ / MTL

CMF

Cal3DFBXFBXOBJ/MTL

CMF

BVH AnimationenModellierung

Animation



Die Datenformate, die in dieser Bearbeitungsstufe verarbeitet werden, sind das FBXFormat für Modelle und Animationen, das Wavefront-OBJ Format für statische Klei-dung, sowie das Cal3D Format als Laufzeit-Format für die Avatar-Modelle.

6.2 Konvertierung von Daten aus dem FBX Format

Bevor Avatare von dem System verwendet werden können, müssen deren Daten indas verwendete Cal3D Format konvertiert werden. Hierzu bietet Cal3D ein Export-Plugin für 3D Studio Max an. Wenn dieses Plugin verwendet wird, müssen Avatareund Animationen zunächst immer in 3D Studio Max importiert werden. Da 3D StudioMax jedoch nicht am Ende der Modellierungs- und Animationsabläufe steht, ist diesesVorgehen umständlich.

In der Regel steht MotionBuilder am Ende der Bearbeitungsabläufe, da mit diesem Pro-gramm die O�ine-Animationen erzeugt werden. Dieses Programm kann jedoch keineCal3D-Dateien exportieren. Vielmehr verwendet MotionBuilder ein eigenes Datenfor-mat - das FBX Format - welches Modelle und Animationen speichern kann. Mit derFBX Initiative versucht der Hersteller Autodesk das Format als Austauschformat für3D Programme zu etablieren. Hierzu wird ein FBX-SDK [7] angeboten, welches dasLaden und Speichern von FBX-Dateien in C++ Programmen erlaubt.

Mit Hilfe des FBX-SDK kann daher ein Konverter geschrieben werden, der FBX Datei-en in das Cal3D-Format umwandeln kann. Ein solcher Konverter hat mehrere Vorteile.Zum einen kann durch die direkte Konvertierung bei jeder erzeugten O�ine-Animationein Arbeitsschritt eingespart werden. Hierdurch werden die Arbeitsabläufe sowohl be-schleunigt, als auch potenzielle Fehler, die bei dem zusätzlichen Import und Exportin 3D Studio Max auftreten könnten, vermieden. Zum anderen wird FBX von vielengängigen Programmen unterstützt (siehe Tabelle 2.2). Auf diese Weise ist man nichtauf 3D Studio Max als einzige Quelle für Modelle und Animationen angewiesen.

KAPITEL 6. AUFBEREITUNG UND KONFIGURATION VON AVATAREN 115

Abbildung 6.2: Benutzerober�äche des FBX Konverters

Der Konverter wurde im Rahmen einer Diplomarbeit im Fachgebiet Technische In-formatik implementiert [169] (siehe Abbildung 6.2). Mit dem Konverter kann eineFBX-Datei mit einem Avatar oder einer Animation geladen und in das Cal3D For-mat konvertiert werden. Die Konversion kann auch selektiv erfolgen, d.h. es könnenauch nur Bestandteile wie Animationen aus der FBX-Datei extrahiert werden.

6.3 Erzeugung von animierbaren Kleidungsstücken ausstatischen Modellen

Mit der �Retarget�-Anwendung können statische Modelle von Kleidungsstücken ani-mierbar gemacht werden. Hierzu wird ein zu dem statischen Modell möglichst ähnlichesModell mit Skinning-Informationen benötigt. In aller Regel wird dies das Basis-Modelldes Avatars sein (siehe Abbildung 6.3 (a)). Das statische Modell wird anschlieÿend soauf das Basis-Modell gelegt, dass eine möglichst groÿe Übereinstimmung gegeben ist(siehe Anzug in Abbildung 6.3 (b)).

Die grundlegende Idee des verwendeten Algorithmus ist, dass Eckpunkte an ähnlichenPositionen auch ähnliche Gewichtungsfaktoren für das Skinning haben sollten. Dazuwerden die Eckpunkte der beiden Modelle analysiert. Hierbei versucht der Algorithmus,zu einem gegebenen Eckpunkt des statischen Modells einen möglichst naheliegendenEckpunkt des Modells mit Skinninginformationen zu �nden. Die Gewichtsinformatio-nen des gefundenen Eckpunktes werden dann auf den Eckpunkt des statischen Modellsübertragen.


(a) Basis-Modell mit Skinning Informationen (b) Basis-Modell mit zugefügten statischenModellen

Abbildung 6.3: Benutzerober�äche der �Retarget� Anwendung

Abbildung 6.4: Ergebnisse eines Retarget-Durchgangs

Obwohl der Algorithmus sehr einfach ist, kann er bei ähnlichen Modellen sehr guteErgebnisse erzielen - und dies bei deutlich reduziertem Aufwand für das Skinning. InAbbildung 6.4 ist das Ergebnis der Übertragung von Abbildung 6.3 zu sehen. Mankann gut erkennen, dass sich der Anzug mit dem Basis-Modell verformt.

Auch wenn die Abweichungen gröÿer sind, kann der Algorithmus noch gute Ergebnisseerzielen. In Abbildung 6.5 wurden die Skinning-Informationen des Basis-Modells aufein komplettes statisches Avatar-Modell übertragen. Hierbei weicht die Geometrie desKleides von der Geometrie der Hose ab. In Abbildung 6.5 (c) ist das animierte Ergebniszu sehen.

Bei deutlicherem Hinsehen fällt auf, dass die Textur des Kleides bei Laufbewegungenauseinander gezogen wird. Dies lässt sich darauf zurückführen, dass die Eckpunkte desunteren Teils des Kleides entweder fest dem linken oder dem rechten Bein zugewiesenwerden. Hierdurch entsteht in der Mitte ein abrupter Übergang vom linken zum rechtenBein, weshalb die Geometrie bei Laufbewegungen an dieser Stelle extrem auseinandergezogen wird. Durch einen �ieÿenderen Übergang könnte dies vermieden werden. Da-zu müssten die Gewichte der Eckpunkte miteinander neu abgemischt werden. DieseFunktion ist momentan aus Zeitgründen noch nicht implementiert.

Der Algorithmus hat aber auch Grenzen, die sich durch fehlerhafte Darstellungen äu-ÿern. Diese können aus Fehlzuordnungen resultieren. Der Algorithmus untersucht zur


(a) Basis-Modell (b) Statisches Modell (c) Modell nach 'Retarget'

Abbildung 6.5: Retarget bei Modellen mit gröÿeren Abweichungen in der Geometrie

Zeit nicht, welche Eckpunkte logisch zueinander gehören. Er unterscheidet beispielswei-se keine Eckpunkte, die vom Kopf, der Frisur oder vom Oberkörper stammen. In Fällen,bei denen die statische Geometrie stärker von dem Basis-Modell abweicht, kann es dannzu Fehlzuordnungen kommen, wenn Eckpunkte des statischen Modells Eckpunkten desBasis-Modells zugeordnet werden, die unterschiedlichen logischen Gruppen angehören.So könnte bei langen Haaren ein Eckpunkt des Oberkörpers die Gewichte eines Eck-punktes der Frisur bekommen. Da die Frisur an das Kopf-Gelenk gebunden ist, derOberkörper in der Regel aber an die Schultergelenke, bzw. die Wirbelsäule, kommt esbei Animationen zur Darstellungsfehlern.

Wenn das Basis-Modell - wie in Kapitel 4 vorgeschlagen - in mehrere Bestandteile zer-legt wird, kann der Fehler vermieden werden, indem der Übertragungsvorgang in meh-reren Schritten durchgeführt wird. Hierzu werden immer nur diejenigen Bestandteileals Quelle für die Skinning-Informationen angeboten, die zu den statischen Bestand-teilen passen. Soll beispielsweise ein statischer Oberkörper mit Skinning-Informationenversorgt werden, wird nur der Basis-Oberkörper als Quelle verwendet. Haare werdendagegen weggelassen.

Mit dem Algorithmus können zwar Kleidungsmodelle animierbar gemacht werden,jedoch führt der Algorithmus keine echte Kleidungssimulation durch. Dazu gehört,dass keine Kollisionserkennung durchgeführt wird. Liegt die Basis-Geometrie sehr na-he der statischen Geometrie, und wird sowohl die Basis-Geometrie, als auch die mitSkinning-Informationen versorgte Geometrie gleichzeitig im Modell genutzt, kann dieBasis-Geometrie bei Animationen durchscheinen. Daher sollten übereinanderliegendePolygonschichten vermieden werden. Auch dies kann durch Weglassen der überdecktenGeometrien erreicht werden, wozu das Basis-Modell in mehrere Bestandteile zerlegbarsein muss.

Auch die letzte Fehldarstellung hat ihren Ursprung darin, dass keine echte Kleidungs-simulation durchgeführt wird. Sie tritt dann auf, wenn die vorhandenen Skinning-Informationen eine andere Charakteristik aufweisen als von dem statischen Modellbenötigt. Ein Beispiel hierfür ist die Übertragung von Skinning-Informationen einerHose auf ein weites Kleid. Die Charakteristik der Skinning-Informationen der Hosesorgt dafür, dass die Eckpunkte der Geometrie einen festen Abstand zu den beein-


�ussenden Gelenken haben. Durch die Übertragung behalten auch die Eckpunkte desKleides diese Charakteristik bei. Dies führt jedoch zu unnatürlichen E�ekten, wennbei Laufbewegungen die Beine bewegt werden. Hierbei wird das Kleid wie eine starreHülle um die Beinen bewegt, statt locker nach unten zu fallen. Da der Algorithmuseine abweichende Charakteristik nicht korrigieren kann, sollte er in diesem Fall nichtangewendet werden.

6.4 Speicherung der Avatar-Kon�guration

Die Cal3D Bibliothek verteilt die Bestandteile eines Avatar-Modells wie Skelett, Geo-metrie, Materialien und Animationen auf verschiedene Dateien. Die Bibliothek stelltjedoch keine Strukturen zur Organisation dieser Daten bereit, sondern überlässt diesder Anwendung. Es wird daher eine Möglichkeit benötigt, die Eigenschaften einesAvatars, sowie die verfügbaren Animationen zu kon�gurieren. Hierzu gehören nichtnur eine Zusammenstellung der Cal3D-Dateien, sondern auch die Speicherung zusätz-licher Informationen, wie ein Skalierungsfaktor und Korrekturwerte für Translationund Rotation des Modells. Für die Gesichtsanimation muss auÿerdem die Möglichkeitbestehen, die vorhandenen Morph-Ziele festzulegen. Des Weiteren benötigt die Online-Sprachausgabe eine Zuordnung zwischen Phonemen und Visemen, sowie Parameter fürdie Sprachsynthese.

Laut Konzept sollen Avatar-Kon�gurationen in einem XML-Format gespeichert wer-den. Dabei gehört zu den vielen Vorteilen des XML-Formats auch die Tatsache, dass dieXML-Struktur für spätere Erweiterungen einfach um weitere Elemente ergänzt werdenkann. In Abbildung 6.6 ist ein Beispiel für eine Kon�gurationsdatei zu sehen.

Zur Verwaltung der Kon�guration wurde ein Klassenmodell entworfen, welches in Ab-bildung 6.7 zu sehen ist. Die Klasse �Value� ist die Basis-Klasse zur Speicherung derCal3D Bestandteile. Jeweils ein Objekt dieser Klasse verwaltet eine Cal3D Datei. Hier-zu kann die Klasse den Dateinamen, einen internen Namen, die eigentlichen Cal3D-Daten und eine Statusinformation (aktiviert / deaktiviert) speichern. Die Klasse kannauÿerdem ihre Einstellungen in eine XML-Datei schreiben, bzw. von dort lesen.

Von dieser Klasse werden konkrete Implementierungen zur Verwaltung der Cal3DDaten abgeleitet. Die �Mesh�-Klasse wurde insofern erweitert, als sie eine Liste vonMorph-Zielen verwalten kann. Auÿerdem wurde die Animationsklasse erweitert undkann zusätzliche Informationen zu Animationen speichern. Hierzu gehört eine Infor-mation darüber, ob die Animation zyklisch verwendet werden kann und mit welcherStandardgewichtung die Animation in die Gesamtanimation eingemischt wird.

Die �AvatarCon�g�-Klasse speichert die gesamte Kon�guration und setzt sich daher ausden Bestandteilen des Avatar-Modells, sowie den benötigten Zusatzinformationen fürKorrekturen und die Spracherzeugung zusammen.

6.5 Gra�sche Kon�guration von Avataren

Mit dem �Avatar-Designer� wird eine gra�sche Benutzerober�äche zur Aufbereitungder Avatar-Modelle für den Einsatz in der Simulation bereitgestellt. Er dient somit


<?xml version="1.0" encoding="UTF-8"?>

<avatar>

<skeleton name="skeleton" filename="jessi.csf" enabled="true"/>

<mesh name="body" filename="Jessi_-_Body.cmf" enabled="true"/>

<mesh name="eyes" filename="Jessi_-_Eyes.cmf" enabled="true">

<morph name="smile" filename="Jessi_-_Smile.cmf" enabled="true"/>

</mesh>

<mesh name="head" filename="Jessi_-_Head.cmf" enabled="true"/>

<mesh name="pony tail" filename="Jessi_-_Pony.cmf" enabled="true"/>

<mesh name="dress" filename="dress.cmf" enabled="true"/>

<material name="dress_0" filename="dress_0.crf" enabled="true"/>



...

<animation name="idle" filename="idle.caf" enabled="true"

looped="true" weight="1.000000"/>

<animation name="walk" filename="walk.caf" enabled="true"

looped="true" weight="1.000000"/>

<animation name="wave" filename="wave.caf" enabled="true"

looped="false" weight="1.000000"/>

<translation x="0.000000" y="0.000000" z="0.000000"/>

<rotation angle="0.000000"/>

<scale factor="100.000000"/>

<size value="167.000000"/>

<voice name="DE7"/>

</avatar>

Abbildung 6.6: Beispiel für eine Avatar-Kon�guration im XML-Format

Value

AvatarConfig

1

1

* * *

Skeleton Mesh Material Animation

Morph Target

*

Abbildung 6.7: Klassendiagramm für die Kon�guration von Avataren


als zentrales Bindeglied zwischen Modellerstellung und Anwendung. Die Funktionendes Programms lassen sich in drei Aufgabenbereiche einteilen. Hierzu gehört zuerst dieAufbereitung der Modelldaten durch Konvertierung aus dem FBX-Format, bzw. dieÜbertragung von Skinning-Informationen auf statische Modelle. Dabei wird auf die indiesem Kapitel vorgestellten Programme zurückgegri�en. Die so entstandenen Cal3DBestandteile können dann zu konkreten Avataren kon�guriert werden. An dieser Stellekann das Aussehen der Avatare durch die Auswahl der Bestandteile, sowie Änderun-gen in den Materialeinstellungen beein�usst werden. Des Weiteren kann eine visuelleKontrolle der Avatare erfolgen.

Da die Aufbereitung der Daten schon in den Abschnitten 6.2 und 6.3 beschriebenwurde, werden im folgenden nur noch die beiden Funktionen zur Kon�guration undKorrektur der Avatare beschrieben.

6.5.1 Kon�guration des Aussehens von Avataren

Der Dialog zur Kon�guration von Avataren ist in vier Abschnitte (siehe Abbildung6.8) eingeteilt, wobei jeder Abschnitt einem Cal3D Datentyp entspricht. Abgesehenvon dem Eintrag für das Skelett können für jeden Eintrag der Dateiname der Cal3DDatei, ein interner Name und ein Aktivierungsstatus angegeben werden.

Der Abschnitt zur Kon�guration der Geometrie erlaubt neben der Auswahl der gra-�schen Bestandteile des Avatars auch die Zuweisung von Morph-Zielen. Die hier ver-gebenen Namen der Morph-Ziele können zur Laufzeit dazu verwendet werden, um einMorph-Target zu aktivieren. Generell können die Namen frei gewählt werden. Für Vi-seme muss jedoch eine bestimmte Namenskonvention eingehalten werden. Hierzu mussbei den Namen das Prä�x �Visem�, gefolgt von einem der Buchstaben A, C, E, F, M,N, O, P, Q, R, S, T, U, Y oder Z verwendet werden.

In dem �Material�-Abschnitt können die zu verwendenden Materialien ausgewählt wer-den. Da die Reihenfolge der Materialien auch Ein�uss auf die Darstellung hat, kanndiese mit dem Dialog geändert werden. Neben der Auswahl von bestehenden Mate-rialien können hier auch neue Materialien erzeugt und zur Kon�guration hinzugefügtwerden.

Der letzte Abschnitt erlaubt die Auswahl und Kon�guration der Animationen. Hierkann eingestellt werden, ob eine Animation zyklisch eingesetzt werden kann und mitwelcher Standard-Gewichtung sie in eine Online-Animation eingemischt werden soll.

Über den Kon�gurationsdialog können auch Änderungen an den Cal3D Dateien selbstvorgenommen werden (siehe Abbildung 6.9). Dies ist insbesondere dann nötig, wennMaterialzuordnungen korrigiert oder geändert werden sollen. So speichert Cal3D inden Geometriedaten die Materialzuordnungen in Form von Material-IDs. Material-IDshängen von der Reihenfolge ab, in der Materialien zu dem Modell hinzugefügt werden.Ändert sich diese Reihenfolge oder wurden während des Exports falsche IDs ermittelt,kann die Materialzuordnung mit dem Geometrie-Editor nachträglich korrigiert werden.Es ist auÿerdem möglich, die Anzahl der verwendeten Materialien ohne Modellierungs-programm zu verändern.

Mit dem Material-Editor können Farb- und Textureinstellungen geändert werden, wo-durch auf einfache Weise das Aussehen eines Avatars verändert werden kann. Insgesamt


Abbildung 6.8: Dialog zur Kon�guration von Avataren

Abbildung 6.9: Änderung von Cal3D Geometrie- und Materialdaten

werden maximal drei Texturen je Material unterstützt. Hierzu gehört neben der Farb-Textur eine Transparenzmaske im Graustufen-Format. Auÿerdem kann je Material eineBump-Map zugeordnet werden.

6.5.2 Visuelle Kontrolle und Korrektur von Avataren

Mit Hilfe der visuellen Kontrolle können Gröÿe, Position und Ausrichtung eines Avatarsüberprüft werden. Dies ist notwendig, um eine einheitliche Skalierung und Blickrichtungder Avatare zu gewährleisten. Durch die Verwendung eines einheitlichen Maÿstabs kanndie originalgetreue Darstellung in der CasCave sichergestellt werden.

Um die Einstellungen zu erleichtern, kann zur Orientierung ein Referenz-Koordinatensystemeingeblendet werden, an dem der Ursprung, die Gröÿe, sowie die Standard-Blickrichtungabgelesen werden können (siehe Abbildung 6.10). Durch Translation, Rotation und Ska-


Abbildung 6.10: Korrektur von Gröÿe und Ausrichtung

lierung kann ein Anwender das Modell in Übereinstimmung mit dem Referenz-Systembringen.

Neben demModell selbst können auch die verfügbaren Animationen und die Sprachaus-gabe in der Voransicht getestet werden. Es kann eine beliebige Anzahl von Animationengestartet und miteinander gemischt werden, wodurch sich auch Online-Animationentesten lassen.

Der Test der Sprachausgabe erlaubt die Auswahl verschiedener verfügbarer Stimmen,sowie die O�ine- und Online- Sprachausgabe.

Kapitel 7

Steuerung von Avataren

Zur Steuerung von Avataren sieht das Konzept aus Kapitel 3 einerseits ein C++ APIvor, mit dem Anwendungen die Avatare direkt steuern können. Andererseits wird aucheine Bindung an eine Skript-Sprache angeboten, die eine �exible Implementierung vonSteuerungskonzepten und Anwendungen ermöglicht.

In dem folgenden Abschnitt wird das C++ API beschrieben. In den beiden verbleiben-den Abschnitten werden dann die Implementierung des Skript-Knotens, sowie Steue-rungskonzepte auf Basis des Skript-Knotens beschrieben.

7.1 Das C++ API zur Steuerung von Avataren

Das API zur Steuerung der Avatare wird durch die Avatar-Klasse bereitgestellt, wobeidie Methoden der Klasse die aus dem Konzept (siehe Abschnitt 3.11.3) gefordertenFunktionalitäten umsetzen. Die vorhandenen Methoden sind in Tabelle 7.1 zusammen-gefasst und gliedern sich die Funktionsgruppen �Erzeugung�, �Positionierung�, �Anima-tion�, �Sprachausgabe� und �Callbacks�.

Ein Avatar kann entweder durch Laden einer Kon�gurationsdatei oder durch Erzeu-gen einer weiteren Instanz eines bereits geladenen Avatars erzeugt werden. Um diePositionierung eines Avatars in einer Szene zu ermöglichen, wurde die Klasse von derOpenSceneGraph MatrixTransform-Klasse abgeleitet. Hierdurch kann die kompletteMatrixTransform Funktionalität übernommen werden, so dass Avatare auch entlangvon Pfaden bewegt werden können. Dabei vereinfachen die Methoden �setPath� und�removePath� die Verarbeitung von Pfaden.

Die Funktionsgruppe �Animation� enthält Methoden, die die Online-Animation vonAvataren ermöglichen. Hierzu gehört das Ein- und Ausblenden von vorhandenen O�-line-Animationen, sowie von Morph-Zielen. Die sichtbare Animation kann durch dieAngabe von Verzögerungen zum Ein- und Ausblenden, sowie durch die Angabe vonGewichten modi�ziert werden. Abhängig von der Kon�guration werden Animationenautomatisch als Aktion bzw. Transition oder als Zyklus abgespielt. Um programmierteAnimationen zu ermöglichen, wird auÿerdem mit der �setBoneRotation�-Methode derZugri� auf das Skelett des Avatars erlaubt.

Mit den Methoden der Funktionsgruppe �Sprachausgabe� kann die animierte Online-und O�ine-Sprachausgabe erfolgen. Hierzu wird entweder direkt der zu sprechende

123

124 KAPITEL 7. STEUERUNG VON AVATAREN

Methode Beschreibung

Erzeugung

Avatar(�lename) Lädt einen Avatar aus einer Kon�guration.

Avatar(avatar) Erstellt eine weitere Instanz eines Avatars.

Positionierung

setMatrix(matrix) Setzt Position und Ausrichtung eines

Avatars.

getMatrix(matrix) Liefert aktuelle Position und Ausrichtung

eines Avatars.

setPath(animationPath, timeO�set = 0.0,

timeMultiplier = 1.0)

Bewegt einen Avatar entlang eines Pfades.

removePath() Stoppt die Bewegung entlang eines Pfades.

move(speed) Bewegt den Avatar in der angegebenen

Geschwindigkeit vorwärts.

turn(degree) Dreht den Avatar um den angegebenen

Wert.

Online-Animation

startAnimation(name, delayIn = 0.0,

delayOut = 0.0)

Mischt die angegebene Animation in die

Online-Animation ein.

stopAnimation(name) Entfernt die angegebene Animation aus der

Online-Animation.

blendMorph(name, weight = 1.0, delay =

0.0)

Mischt das angegebene Morph-Ziel in das

Modell ein.

clearMorph(name, delay = 0.0) Entfernt das angegebene Morph-Ziel.

setBoneRotation(name, rotation) Setzt die Rotation eines Gelenks.

Sprachausgabe

setVoice(voice) Setzt die (MBROLA) Stimme für die

Sprachausgabe.

say(text) Startet die Online-Sprachausgabe des

angegebenen Textes.

sayFile(facialAnim) Startet die O�ine-Sprachausgabe der

angegebenen Datei.

enableBubble(enabled) Aktiviert die Sprechblase des Avatars.

setBubbleText(text) Setzt den Text der Sprechblase des Avatars.

Callbacks

setUpdateHandler(eventHandler) Setzt den Callback für Update-Ereignisse.

setAnimationFinishedHandler(eventHandler) Setzt den Callback für beendete

Animationen.

setSpeechCallbackHandler(eventHandler) Setzt den Callback für

Sprachausgabe-Ereignisse.

Tabelle 7.1: Funktionen des Avatar-API

KAPITEL 7. STEUERUNG VON AVATAREN 125

MatrixTransform

Avatar

AvatarConfig SpeechBubble SoundNode Model

Abbildung 7.1: Klassendiagramm für Avatare

Text oder der Dateiname einer Sprachanimation angegeben. Bei der Online-Sprach-ausgabe kann auÿerdem die zu verwendende Stimme ausgewählt werden. Unter Ver-wendung von Comic-ähnlichen Sprechblasen können Informationen auch in Textformdargestellt werden.

Um Animationen besser steuern zu können, wurde ein Callback-Mechanismus imple-mentiert. Hierdurch kann eine Anwendung eine Routine registrieren, die aufgerufenwird, sobald ein bestimmtes Ereignis eintritt. Hierzu gehört das �Update�-Ereignis,welches bei jedem Update-Zyklus des Szenengraphen ausgelöst wird. Ein anderes Er-eignis wird ausgelöst, sobald das Abspielen einer Aktion bzw. Transition abgeschlossenwurde. Dieses Ereignis erleichtert die Realisierung von sequentiellen Animationsfolgen,da eine Anwendung nicht laufend den aktuellen Animationsstatus überprüfen muss.Stattdessen muss sie erst wieder eingreifen, wenn eine Animation abgeschlossen wurde.Mit diesem System lassen sich auch die von ReplicantBody [88] bekannten Animations-Warteschlangen implementieren. Es ist jedoch �exibler, da durch den Callback nichtnur eine neue Animation gestartet, sondern prinzipiell auch jede andere Aktion ausge-führt werden kann.

Hinter der Avatar-Klasse verbirgt sich ein Teilbaum, der aus den verschiedenen Kom-ponenten des Avatars besteht (siehe Abbildung 7.1). Auf diesen Teilbaum braucht eineAnwendung in der Regel nicht zuzugreifen, da die Avatar-Klasse die benötigten Funk-tionalitäten bereitstellt. Die Struktur erlaubt jedoch eine �exible Erweiterung einesAvatars, da bei Bedarf weitere Komponenten angehängt werden können.

7.2 Realisierung des Skriptings zur Steuerung von Ava-taren

Das Konzept des Avatar-Systems sieht die Verwendung einer Skriptsprache vor, um aufeinfache Weise die Steuerung der Avatare in einer Anwendung zu realisieren. Hierzuwurden Skript-Knoten als universelle Steuerungseinheiten vorgeschlagen, die nicht nurdie Avatare selbst steuern, sondern allgemein zur Kontrolle der Animation eingesetztwerden können. Diese Skript-Knoten werden mit der Skriptsprache Lua programmiert.Der folgende Abschnitt geht daher auf einige Eigenschaften von Lua ein. Es folgt an-schlieÿend die Beschreibung der Implementierung des Skript-Knotens.


NodeCallback

ScriptCallback

Group

LuaStateLuaNode* 1

Abbildung 7.2: Klassendiagramm für Skripting

7.2.1 Eigenschaften und Funktionsweise von Lua

Lua besitzt eine prozedurale Syntax mit der Möglichkeit zur Beschreibung von Datenauf der Basis von assoziativen Datenfeldern ("Tabellen"). Die Typenbindung der Spra-che ist dynamisch, d.h. Variablen sind typfrei, Werte sind jedoch typbehaftet. Zu denDatentypen gehören nicht nur klassische Typen wie Zahlen und Zeichenketten, sonderninsbesondere auch Lua-Funktionen.

Einige wenige "Meta-Mechanismen" erlauben die Implementierung von Eigenschaften,die die Sprache selbst nicht zur Verfügung stellt. So ist die Sprache selbst zwar nichtobjektorientiert. Grundlegende Mechanismen der Objekt-Orientierung (wie ein- odermehrfache Vererbung) lassen sich jedoch einfach mit Lua-eigenen Mitteln nachbauen.Hierzu können beispielsweise Tabellen verwendet werden. Eigenschaften von Objektenwerden direkt als Werte in der Tabelle gespeichert. Da Funktionen auch Werte sind,können auf diese Weise den Tabellen auch Methoden hinzugefügt werden.

Lua-Skripte werden entweder implizit zur Laufzeit oder explizit mithilfe eines separa-ten Übersetzers in Byte-Code übersetzt. Dieser wird anschlieÿend von einer VirtuellenMaschine (VM) interpretiert. Die Speicherverwaltung erfolgt automatisch, d.h. nichtmehr benötigte Werte werden im Rahmen einer �Garbage Collection� ohne Zutun desProgrammierers aus dem Speicher entfernt.

Als Erweiterungssprache bietet Lua ein C-API, welches die Erweiterung der Spracheum neue C/C++ Funktionen ermöglicht. Auÿerdem kann eine Lua-Funktion aus einemC/C++ Programm heraus aufgerufen werden. Der Datenaustausch zwischen dem Pro-gramm und der Lua VM wird über eine Stack-Struktur realisiert. Auf dieser werdenParameter für Funktionen abgelegt. Nach Abarbeitung der Funktion können über denStack die Ergebnisse wieder abgeholt werden.

7.2.2 Aufbau des Skripting-Knotens

Skript-Knoten werden als Gruppen-Knoten implementiert (siehe Abbildung 7.2). Aufdiese Weise können weitere Knoten an den Skript-Knoten gehängt werden. Diese an-gehängten Knoten können durch Lua-Funktionen manipuliert werden. So kann bei-spielsweise die Initialisierung der Szene durch Einladen und Positionieren von externenModellen ermöglicht werden. Um die Kontrolle des angehängten Teilbaumes zu ermög-lichen, muss ein Teil der OpenSceneGraph- und Avatar-API für Lua-Skripte zugänglichgemacht werden.

Alle Skript-Knoten teilen sich einen Skript-Kontext, wodurch zwischen den Knotenüber globale Variablen Informationen ausgetauscht werden können. Damit alle Skript-Knoten einen gemeinsamen Skript-Kontext verwenden können, wurde dieser in einer


Klasse mit statischen Methoden gekapselt. Die LuaState-Klasse bietet Funktionen zumAufruf von Lua-Funktionen und fängt auÿerdem Lua-Fehlermeldungen ab. Desweiterenkönnen mit dieser Klasse Skript-Dateien eingeladen und globale Lua-Variablen initia-lisiert und gelesen werden.

Da der Skript-Knoten zur Laufzeit Kontrollfunktionen übernehmen soll, wird ein Me-chanismus benötigt, der den Knoten über die Durchführung des Update-Zyklus desSzenengraphen informiert. Hierzu bietet OpenSceneGraph Node-Callbacks an. Die-se Callbacks können in dem Szenengraphen registriert werden und werden währenddes Updates automatisch aufgerufen, wodurch die Update-Stufe um benutzerde�nierteFunktionen erweitert werden kann.

Die Einbindung des Skriptings in die Abläufe des Szenengraphen wird dadurch rea-lisiert, dass der Skript-Knoten bei bestimmten Ereignissen Lua-Funktionen aufruft.Hierzu gehören:

init: Die Init-Funktion wird aufgerufen, wenn der Skript-Knoten erstellt wird. Sie er-möglicht beispielsweise das Hinzufügen weiterer Elemente an den Skript-Knoten.In der Init-Funktion kann auch eine Update-Funktion registriert werden.

update: Die Update-Funktion wird bei jedem Update-Zyklus des Szenengraphen auf-gerufen und ermöglicht so eine Manipulation des Graphen zur Laufzeit.

destroy: Die Destroy-Funktion wird aufgerufen, wenn der Skript-Knoten gelöschtwird. Es besteht so die Möglichkeit, durch den Skript-Knoten belegte Ressourcenwieder freizugeben.

7.2.3 Bindung des OpenSceneGraph API an Lua

Damit der Skript-Knoten seine Kontrollfunktionen übernehmen kann, muss ein Teil derOpenSceneGraph und Avatar APIs in Lua zugänglich gemacht werden. Man sprichthier auch von einer Bindung, die zwischen Lua und den C++ Funktionen und Klassenerzeugt werden muss.

Eine solche Bindung kann mit dem Programm tolua++ [41] erzeugt werden. DiesesProgramm benötigt als Eingabe eine Schnittstellenbeschreibung der einzubindendenFunktionen und Methoden. Dies können zum einen C++ Header-Dateien oder Pa-ketbeschreibungen sein. Letztere entsprechen vereinfachten und reduzierten Header-Dateien. Aus diesen Dateien erzeugt tolua++ den Quelltext einer Funktion, die dieBindung zwischen C++ und Lua erzeugt. Diese Funktion muss nach Erstellung desLua-Kontextes aufgerufen werden, um die Bindung zu aktivieren.

Mit Hilfe von tolua++ wurde eine Teilmenge des OpenSceneGraph API in Lua in-tegriert. Abbildung 7.3 zeigt die zur Zeit verfügbaren Klassen. Hinzu kommen nochHilfsfunktionen und Objekte, die die Realisierung von interaktiven Anwendungen er-leichtern. Dazu gehören die Verarbeitung von Tastatureingaben, sowie die Steuerungder aktuellen Ansicht (Kamera). Eine Übersicht des gesamten integrierten Sprachum-fangs be�ndet sich in [211].

Abbildung 7.4 zeigt ein einfaches Beispiel, bei dem ein Teilgraph durch einen Skript-Knoten animiert wird. Das Skript baut in der �init�-Funktion zunächst ein einfachesPlanetensystem auf. Dieses wird in der �update�-Funktion animiert, indem die beidenkleineren Planeten rotiert werden.


Object

NodeFollowPath SoundState

SoundNodeGroup

MatrixTransform

Camera

Avatar

SequenceSwitchLODLuaNode

MatrixVector Quat

Abbildung 7.3: In Lua verfügbare OpenSceneGraph-Klassen

Abbildung 7.4: Animation mit einem Skript-Knoten


7.3 Konzepte zur Steuerung von Avataren mit Skript-Knoten

Das C++ API stellt eine bewusst einfache Schnittstelle bereit, die aber eine vollständigeSteuerung der Avatare erlaubt. Zusammen mit den Skript-Knoten kann diese Schnitt-stelle zur Realisierung von komplexeren Steuerungskonzepten verwendet werden. Dabeihaben sich mehrere Eigenschaften von Lua zur Steuerung von Avataren in der Praxisals nützlich erwiesen. Im folgenden werden daher einige Idiome vorgestellt, die sich zurSteuerung der Avatare eignen. Zu diesen gehören:

• Speichern von zusätzlichen Eigenschaften zu einem Objekt

• Erweiterung von bestehenden Klassen um neue Methoden

• Warteschlangen für Animationen

• Lineare Steuerung von Avataren

Zu jedem Idiom werden eine kurze Problembeschreibung und eine mögliche Imple-mentierung in Lua angegeben. Der jeweils abschlieÿende Abschnitt liefert zusätzlicheHinweise zu Anwendungs- und Rahmenbedingungen.

7.3.1 Speichern von zusätzlichen Eigenschaften zu einem Ob-jekt

Kurzbeschreibung

Zusätzliche Werte - beispielsweise Statusinformationen - sollen zusammen mit einemObjekt - beispielsweise einem Avatar - gespeichert werden. Solche Werte können direktim Objekt gespeichert werden.

Lösung

Da Objekte in Lua durch Tabellen abgebildet werden, kann ein Lua Skript auch weitereFelder zu der Tabelle hinzufügen.

Beispiel

avatar = newAvatar("James.avatar")

avatar.name = "James"



Die Möglichkeit, neue Felder direkt zu einem Objekt hinzuzufügen, hat sich in vielenSituationen als sehr nützlich erwiesen. Sie sollte jedoch auch mit Bedacht angewendetwerden, da prinzipiell jedes Element überschrieben werden kann - also auch eingebun-dene C++ Methoden.

Ist man nicht sicher, ob ein Feld bereits vorhanden ist, kann mit einer if-Anweisungdessen Existenz überprüft werden:

if avatar.name == nil then

cout("Avatar has no name!")

end

7.3.2 Erweiterung von bestehenden Klassen um neue Metho-den

Kurzbeschreibung

Eine bestehende Klasse soll um Lua-Methoden erweitert werden. Dies kann dadurcherreicht werden, dass die neuen Funktionen - wie neue Eigenschaften - direkt zu beste-henden Objekten hinzugefügt werden.

Lösung

Da Funktionen in Lua ebenfalls Werte sind, können sie einfach zu bestehenden Objektenhinzugefügt werden. In der Praxis hat es sich bewährt, eine Konstruktor-Funktion zuerstellen. Diese erstellt das Basis-Objekt und fügt die neuen Methoden hinzu. Das somodi�zierte Objekt wird als Ergebnis der Funktion zurückgeliefert.

Damit die neuen Funktionen als Methoden verwendet werden können, benötigen sieimmer mindestens einen �this� Parameter, der als Referenz auf die aktuelle Instanzverwendet wird. Dieser Parameter muss der erste in der Parameterliste sein.

Beispiel

function newNamedAvatar(config)

-- Create base-object

local avatar = newAvatar(config)

-- Add methods

function avatar.printName(this)

cout("My name is "..this.name)

end

-- Add properties


avatar.name = "default"

-- Return extended object

return avatar

end


Bei der Erstellung des neuen Konstruktors sollte eine gewisse Reihenfolge eingehaltenwerden. Zuerst sollte das Basis-Objekt als lokales Element erstellt werden. Es emp�ehltsich, das Objekt lokal zu erzeugen, damit nicht ein gleichnamiges globales Objekt über-schrieben wird.

Anschlieÿend sollten alle neuen Methoden direkt zu dem Objekt hinzugefügt werden.Hierbei muss darauf geachtet werden, dass jede Methode als ersten Parameter einen�this� Parameter hat. Dieser Parameter ist zu verwenden, wenn auf das zu bearbeitendeObjekt zugegri�en werden soll.

Hierauf können dem Objekt neue Eigenschaften hinzugefügt werden, bevor es letztend-lich als Ergebnis zurückgeliefert wird.

Mit dieser Vorgehensweise können auch existierende Methoden überschrieben werden.Sofern eine Methode nicht komplett ersetzt werden soll, sollte zuvor jedoch die alteMethode unter einem neuen Namen gesichert werden, da andernfalls kein Zugri� aufdie Methode mehr möglich ist.

7.3.3 Warteschlangen für Animationen

Kurzbeschreibung

Eine Liste von Animationen soll der Reihe nach - ohne zusätzliche Kontrolle des Pro-gramms - abgespielt werden. Dies kann unter Verwendung von Callbacks und einererweiterten Avatar-Klasse realisiert werden.

Lösung

Das Problem kann durch eine erweiterte Avatar-Klasse gelöst werden, die neben einerListe für die abzuspielenden Animationen auch zwei Methoden zum Hinzufügen (ad-dAnimation) und Starten (nextAnimation) von Animationen enthält. Mit der erstenMethode kann ein Anwender eine beliebige Anzahl von Animationen zur Liste hinzu-fügen. Die nextAnimation-Methode wird durch den AnimationFinished-Callback desAvatars ausgelöst und startet die nächste Animation.

Beispiel

Zunächst muss ein neuer Konstruktor geschrieben werden, der die nötigen Erweiterun-gen vornimmt:


function newQueueAvatar(config)


function avatar.addAnimation(this,animation)

table.insert(this.queue,1,animation)

this:nextAnimation()

end

function avatar.nextAnimation(this)

if (this.active) then

return

end

if (table.getn(this.queue) > 0) then

this:startAnimation(table.remove(this.queue))

this.active = true

end

end

avatar.queue = {}

avatar.active = false

avatar:setAnimationFinishedCB("dispatchAnimationEvent")

return avatar

end

Des Weiteren wird noch ein Callback benötigt, der das Ereignis �AnimationFinished�an die nextAnimation-Methode durchreicht:

function dispatchAnimationEvent(avatar)

if (avatar.nextAnimation ~= nil) then

avatar.active = false

avatar:nextAnimation()

end

end

Eine Anwendung kann jetzt die Animationen hinzufügen:


mancasul = newQueueAvatar("mancasul.avatar")

mancasul:addAnimation("walk")

mancasul:addAnimation("greeting")

mancasul:addAnimation("point_left")

mancasul:addAnimation("walk")

mancasul:addAnimation("point_right")


Das Beispiel zeigt, wie die Basis-Funktionalitäten der Avatare mit Hilfe des Skript-Knotens erweitert werden können, um komplexere Verhaltensweisen zu de�nieren. Eszeigt auÿerdem, wie der Callback-Mechanismus der Avatare eingesetzt werden kann, umAnwendungen zu vereinfachen. Anstatt den aktuellen Animationsfortschritt ständig zuüberprüfen, greift das Skript erst dann wieder ein, wenn eine neue Animation gestartetwerden muss.

7.3.4 Lineare Steuerung von Avataren

Kurzbeschreibung

Mit Skript-Callbacks können prinzipiell auch komplexere Animationsfolgen gesteuertwerden. Jedoch wird die Steuerung durch den Umstand erschwert, dass die Callbacksdie Kontrolle immer wieder an den Szenengraphen zurückgeben müssen, damit diesermit der Darstellung der Szene fortfahren kann. Dies bedeutet in der Regel, dass einCallback bei jedem Aufruf nur kleine, inkrementelle Veränderungen vornehmen kann.Zur globalen Kontrolle der Animation muss der Callback eine Zustandsbeschreibungverwalten, die eine Einordnung in den aktuellen Kontext erlaubt.

Dagegen ist es übersichtlicher, wenn die Aktionen eines Avatars linear, ohne eine ma-nuelle Verwaltung des Kontexts, festgelegt werden können. Dies kann mit kooperativenThreads ermöglicht werden. Kooperative Threads werden in Lua �Koroutinen� genannt.

Lösung

Mit Hilfe von Lua wird die Basis-Klasse so erweitert, dass ein Lua-Thread die Kon-trolle des Avatars übernehmen kann. Hierzu werden die auszuführenden Aktionen inBasis-Aktionen zerlegt, die dann von einer übergeordneten Steuerung aufgerufen wer-den. Lua unterstützt nur kooperative Threads. Daher sind die Threads selber dafürverantwortlich, die Kontrolle zurück an die aufrufende Instanz abzugeben. Da Lua denKontext der Koroutinen automatisch verwaltet, werden sie jedoch immer an der Stellewieder fortgesetzt, an der sie zuletzt die Kontrolle abgegeben haben.


Beispiel

Im nachfolgenden Beispiel wird eine Klasse für umherwandernde Avatare implemen-tiert. Die Methode �wanderThread� übernimmt die globale Steuerung des Avatars. DieMethoden �move� und �turn� sind Basis-Aktionen und bewegen den Avatar.

function newWanderAvatar(config)


function avatar.wanderThread(this)

this:startAnimation("walk_loop")

while (true) do

if math.random(100) < 10 then

this:pause()

end

this:move()

this:turn()

end

end

function avatar.move(this)

local i

for i=0,math.random(20,200) do

this:preMult(translate(0,-this.speed,0))

coroutine.yield()

end

end

function avatar.turn(this)

...

end

function avatar.pause(this)

...

end

function resumeThread(this)


coroutine.resume(this.thread)

end

avatar.speed = 0.05

avatar.thread = coroutine.create(avatar.wanderThread)

coroutine.resume(avatar.thread,avatar)

avatar.setUpdateCB("resumeThread")

return avatar

end


Mit kooperativen Threads können Avatare übersichtlicher kontrolliert werden. Da essich jedoch nicht um echte Threads handelt, ist der Anwender dafür verantwortlich,die Kontrolle mit dem yield-Befehl an den Szenengraphen zurückzugeben. Je schnellerdies geschieht, desto geringer ist die Wahrscheinlichkeit, dass die Wiedergabe durchRuckeln gestört wird. Vergessene und zu wenige yield-Befehle sind daher eine möglicheFehlerquelle.

Bei dem gezeigten Beispiel wurde die Kontrolle der kooperativen Threads von denBasis-Aktionen übernommen. Hierdurch kann in der globalen Steuerungsmethode aufzusätzliche �yield�-Befehle verzichtet werden, wodurch die Kontrollstruktur klarer wird.

In Abbildung 7.5 wurde von der beschriebenen Technik Gebrauch gemacht. In dieserAbbildung werden 100 Avatare durch 100 kooperative Threads gesteuert. Die Initiali-sierung der Szene, sowie die übergeordnete Steuerung werden von einem Skript-Knotenübernommen.


Abbildung 7.5: Kontrolle von 100 Avataren durch kooperative Threads

Kapitel 8

Gesichtsanimation und Sprachausgabe

Das Konzept des Avatar-Systems sieht zwei Möglichkeiten zur Erzeugung von Gesichts-animation und Sprachausgabe vor. Die O�ine-Sprachausgabe wird mit externen Pro-grammen wie MotionBuilder erzeugt und kann zur Laufzeit wiedergegeben werden.Dieses Vorgehen hat den Vorteil, dass natürliche Sprachaufzeichnungen verwendet wer-den können. Es hat aber auch den Nachteil, dass jede möglich Animation im Vorauserzeugt werden muss. Bei der Online-Sprachausgabe wird die Animation zur Laufzeitberechnet. Hierdurch kann der zu sprechende Text zur Laufzeit erzeugt werden. Al-lerdings muss die Audio-Ausgabe hierzu synthetisiert werden, weswegen sie künstlichklingen kann.

Beide Möglichkeiten haben gemeinsam, dass Morphing zur Gesichtsanimation einge-setzt werden soll. Morphing-Animationen können e�zient wiedergegeben werden, be-nötigen aber für jedes Visem ein Morph-Ziel. Dabei wird in beiden Fällen der gleicheVisem-Satz für die deutsche Sprache aus [119] verwendet. Zur Wiedergabe der Gesichts-animation werden diese Morph-Ziele über die Zeit mit unterschiedlichen Gewichtenaktiviert, d.h. sie werden als Morph-Sequenz wiedergegeben.

Die verwendete Charakter-Animations Bibliothek Cal3D kennt zwar Morphing, jedochkeine Morph-Sequenzen. Daher müssen diese nachträglich hinzugefügt werden. Die Er-weiterung von Cal3D um Morph-Sequenzen wird in Abschnitt 8.1 beschrieben.

Neben der Animation wird auch eine Audio-Ausgabe der Sprachdaten benötigt. Hierzusieht das Konzept die Verwendung der Audio-Erweiterung osgAL vor, mit der räumli-cher Klang erzeugt werden kann. Die Verwendung dieser Erweiterung wird in Abschnitt8.2 vorgestellt.

Die beiden folgenden Abschnitte beschreiben die Realisierung der O�ine- und Online-Sprachausgabe in der Laufzeitumgebung des Avatar-Systems. In Abschnitt 8.3 wirddazu erläutert, welche Programme an der Erzeugung beteiligt sind und wie die Sprach-ausgabe zur Laufzeit erfolgt. In Abschnitt 8.4 folgt die Beschreibung der Sprachausgabemit einem Sprachsynthese-System. Hierzu wird erklärt, wie die Animation zur Laufzeiterzeugt wird und welche Möglichkeiten zur Synchronisierung der Sprachausgabe mitder übrigen Animation des Körpers bestehen.

137

138 KAPITEL 8. GESICHTSANIMATION UND SPRACHAUSGABE

<?xml version="1.0" standalone="yes"?>

<morph_sequence>

<track target="VisemA">

<key time="0.19" weight="0"/>



</track>

<track target="VisemE">



...

</track>

...

<sound filename="mein name ist james.wav" />

</morph_sequence>

Abbildung 8.1: Beispiel für eine Morph-Sequenz im XML-Format

8.1 Integration von Morph-Sequenzen in Cal3D

Um Morph-Sequenzen in Cal3D verwenden zu können, werden zwei Dinge benötigt.Dies ist zum einen eine Datenstruktur, mit der eine Morph-Sequenz gespeichert werdenkann. Auÿerdem wird eine Möglichkeit benötigt, die in der Datenstruktur enthalteneAnimation abzuspielen. Hierzu sollte sich eine Morph-Sequenz genauso verhalten wieeine normale Cal3D-Animation. Auf diese Weise können die in Cal3D vorhandenenFunktionen zur Kontrolle und zum Abspielen einer Animation verwendet werden.

8.1.1 Entwicklung einer Datenstruktur für Morph-Sequenzen

Morph-Sequenzen können in Form von Key-Frames abgespeichert werden. Jeder Key-Frame enthält einen Zeitpunkt, das betro�ene Morph-Ziel und ein Gewicht. DiesesGewicht bestimmt, wie stark sich ein Morph-Ziel auf das Aussehen auswirkt. Für dieSpeicherung der Morph-Sequenzen werden alle Key-Frames, die ein bestimmtes Morph-Ziel betre�en, zu einem Track zusammengefasst. Hierdurch muss ein Morph-Ziel nurjeweils pro Track identi�ziert werden. Zur Identi�zierung werden die Namen verwen-det, die im Avatar-Designer bei der Kon�guration der Morph-Ziele angegeben wurden.Ein Key-Frame innerhalb eines Tracks speichert so nur den Zeitpunkt und das Ge-wicht. Dabei wird der Zeitpunkt in Sekunden relativ zum Startzeitpunkt der Sequenzangegeben. Gewichte werden als Prozent-Werte gespeichert, wobei der Wert �1� 100%entspricht. Diese Werte können auch gröÿer als Eins oder negativ sein!

Um Morph-Sequenzen auch in Dateien ablegen zu können, wurde ein XML-Formatentwickelt (siehe Abbildung 8.1). Eine Datei kann genau eine Morph-Sequenz speichern.Neben der Sequenz kann auch der Name einer Audio-Datei de�niert werden, die beiWiedergabe der Morph-Sequenz abgespielt werden soll.

KAPITEL 8. GESICHTSANIMATION UND SPRACHAUSGABE 139

CalCoreAnimation

MorphSequence

CalAnimationCallback

MorphCallback Track

MorphKey

*

1

*1

Abbildung 8.2: Klassendiagramm für Morph-Sequenzen

8.1.2 Abspielen von Morph-Sequenzen

Morph-Sequenzen sollen möglichst nahtlos in Cal3D integriert werden können. Cal3Dunterstützt mit der Klasse CalCoreAnimation jedoch nur skelettbasierte Animationsse-quenzen. Da für diese Klasse bereits Mixer bereitgestellt werden, mit denen Animatio-nen kontrolliert und abgespielt werden können, wurde die MorphSequence-Klasse vondieser Klasse abgeleitet (siehe Abbildung 8.2).

Damit die Klasse das Skelett des Modells nicht beein�usst, erzeugt sie zunächst ei-ne leere skelettbasierte Animation. Die Dauer der Animation wird so festgelegt, dasssie zum Abspielen der gespeicherten Morph-Sequenz ausreicht. Für die Animation derMorph-Sequenz muss die Klasse in regelmäÿigen Abständen die Gewichtsinformatio-nen aus dem gespeicherten Track in die Morph-Ziele übertragen. Hierzu registriert dieKlasse einen Callback, der automatisch bei jeder Aktualisierung von Cal3D aufgerufenwird, wenn die Animation aktiv ist.

Da sich die MorphSequence-Klasse für Cal3D nicht von einer normalen Animationunterscheidet, kann sie wie jede andere Animation verwendet werden. So können auchmehrere Morph-Sequenzen zu einem Modell hinzugefügt werden. Da das Mischen vonmehreren Sprachanimationen in der Regel keinen Sinn macht, reicht es jedoch, wennnur eine Morph-Sequenz zu einem Modell hinzugefügt wird. Bei dieser Morph-Sequenzwerden dann vor dem Abspielen die gespeicherten Track-Informationen durch Ladeneiner XML-Datei oder durch Generierung der Key-Frames zur Laufzeit gesetzt.

8.2 Audioausgabe der Sprachdaten

Die für die gra�sche Ausgabe verwendete OpenSceneGraph Bibliothek enthält aucheine Erweiterung für räumliche Klangerzeugung (osgAL). Mit osgAL können OpenALKlangquellen in einen Szenengraphen eingebunden werden. Die Position der Klangquel-len wird durch Sound-Knoten de�niert. Diese können wie normale Geometrie-Knotenan Transformationsknoten gebunden werden, wodurch Klangquellen auf einfache Weisein der Szene positioniert werden können.

Mit den Sound-Knoten kann auch die Sprachausgabe der Avatare realisiert werden.Hierzu wird ein Sound-Knoten an den Avatar angehängt, wodurch die Position derKlangquelle an die Position des Avatars gebunden wird. Hierdurch kann die Audioaus-gabe auch räumlich einem Avatar zugeordnet werden, wodurch der immersive E�ekt in



WAV WAV

MotionBuilder FBX2Cal3DLaufzeit-system

MorphSequenz

Animation(FBX)

Modell(FBX)

Abbildung 8.3: Programme und Datenformate für die Sprachanimation mit externenProgrammen

der CasCave zusätzlich verstärkt werden kann. Da OpenAL, abhängig von der Hard-ware, nur eine begrenzte Anzahl an Klangquellen unterstützt, wird ein Sound-Knotenjedoch nur bei Bedarf an den Avatar angehängt.

Soll eine Audioausgabe erfolgen, wird zunächst das Vorhandensein eines Sound-Knotensüberprüft und ggf. der Sound-Knoten erstellt. Anschlieÿend werden die Audio-Daten anden Sound-Knoten gebunden. Sobald der Sound-Knoten vorbereitet ist, wird die Au-dioausgabe zeitgleich mit der Morph-Sequenz gestartet. Audioausgabe und Animationlaufen ab diesem Zeitpunkt parallel ab und es erfolgt keine weitere Synchronisation.

8.3 Erzeugung von Sprachanimationen mit externenProgrammen

Die O�ine-Sprachanimation eignet sich immer dann, wenn besonderer Wert auf dieVerwendung von vorhandenen Sprachaufzeichnungen gelegt wird. Da hier reale Stim-men verwendet werden können, wirkt die Sprachausgabe natürlicher.

Für die Sprachanimation mit externen Programmen wird neben einem animierbarenAvatar-Modell auch eine Audio-Datei mit der Sprachaufnahme benötigt. Mit Hilfe vonMotionBuilder und dem Arbeitsablauf aus Abschnitt 5.3.6 kann hiermit eine Spracha-nimation im FBX-Format erzeugt werden. Der Konverter FBX2Cal3D kann aus einersolchen FBX-Datei eine Morph-Sequenz im XML Format generieren. Abbildung 8.3fasst die verwendeten Programme und Datenformate zusammen.

Zusammen mit der in MotionBuilder verwendeten Audio-Datei kann die erzeugte XML-Datei von der Laufzeitumgebung des Avatar-Systems zur Sprachausgabe verwendetwerden. Hierzu stellt das Avatar-API eine Funktion zur Verfügung, mit der eine Morph-Sequenz eingeladen und unmittelbar abgespielt werden kann.

In Abbildung 8.4 ist das Ergebnis einer Sprachanimation zu sehen. In den drei Bilderneiner Reihe werden die drei Abschnitte des Wortes �Ha-ll-o� gesprochen. In der oberenReihe ist das Ergebnis von MotionBuilder zu sehen. Die untere Reihe zeigt die Wieder-gabe im Laufzeit-System. Die Laute werden mit den Standardeinstellungen nicht sehrausgeprägt dargestellt. Durch eine manuelle, stärkere Gewichtung in MotionBuilderkönnte dies jedoch korrigiert werden.


Abbildung 8.4: O�ine-Sprachanimation

8.4 Erzeugung von Sprachanimationen mit einemSprachsynthese-System

Durch die Erzeugung der Animation zur Laufzeit ist die Online-Sprachanimation sehr�exibel. Sie eignet sich daher immer dann, wenn der gesprochene Text erst zur Lauf-zeit feststeht. Ein anderes Anwendungsgebiet ist schnelles Prototyping, bei dem dieletztendlich eingesetzten Sprachaufzeichnungen noch nicht vorhanden sind.

Ausgangspunkt für die Sprachanimation ist der zu sprechende Text. Dabei sieht dasKonzept vor, dass der Text durch Steuerungselemente erweitert werden kann, die dieAussprache und Animation beein�ussen. Die Erzeugung der Sprachanimation gliedertsich dann in die in Abbildung 8.5 dargestellten Funktionsbereiche.

Dies ist zum einen die Synthese des Textes zu Audio-Signalen. Diese Synthese kannmit Hilfe eines Sprachsynthesizers erreicht werden.

Der zweite Funktionsbereich ist die Animation des Gesichts entsprechend dem vorge-gebenen Text. Hierzu wird der Text in Phoneme zerlegt und die gesprochenen Phone-me durch Viseme visualisiert. Die Visualisierung kann mit den bereits beschriebenenMorph-Sequenzen erreicht werden. Ziel ist es daher, aus einem Text eine passendeMorph-Sequenz zu generieren.

Der dritte Funktionsbereich ist die Synchronisierung sekundärer Animationen mit demgesprochenen Text. Dabei werden sekundäre Animationen durch XML-Elemente festge-legt, die in den Text eingebettet werden. Aufgabe dieses Funktionsbereiches ist daher,die Steuerungselemente zu identi�zieren und in den zeitlichen Kontext einzuordnen,damit sie zum richtigen Zeitpunkt ausgeführt werden können.

Im Bereich der Sprachanimation wurde eine Reihe von Möglichkeiten erforscht, Textein Phoneme umzuwandeln und diese Phoneme unter Berücksichtigung verschiedenerKoartikulationsregeln zu visualisieren [117, 122, 135, 138, 147, 176, 185, 206]. Au-


Phonemizer

VisemizerSynthesizer SequenzerMaryTTS

MaryTTS

Sprachanimation

MaryXML

Phoneme + Dauer

Phoneme + Dauer

Audio

Phoneme + Dauer

Audio Morph-Keys Animations-Keys

Text(mit Steuerungs-

elementen)

Abbildung 8.5: Module zur Online-Sprachanimation

ÿerdem existieren neben Mary-TTS auch viele kommerzielle Sprachsynthese-Systeme.Damit solche Lösungen �exibel eingebunden werden können, wurde das Teilsystem zurOnline-Sprachanimation modular aufgebaut. Hierzu gehören ein Modul zur Sprachsyn-these, ein Modul zur Umwandlung von Text in eine Phonemliste, sowie ein Modul zurErzeugung der Morph-Sequenz aus eine Liste von Phonemen. Für diese Module exis-tieren Basis-Implementierungen, die auf Mary-TTS aufbauen und die im Rahmen einerDiplomarbeit entwickelt werden [204]. Bei Bedarf können sie aber auch durch andereImplementierungen ausgetauscht werden.

Im folgenden wird zunächst beschrieben, welche Steuerelemente in den Text eingebettetwerden können. Anschlieÿend wird die Realisierung der drei Funktionsbereiche erklärt.

8.4.1 XML Steuerelemente zur Beein�ussung der Sprachani-mation

Die verfügbaren XML-Elemente können in drei Gruppen eingeteilt werden. Die ersteGruppe beein�usst die Audio-Ausgabe. Da Mary-TTS für die Sprachsynthese einge-setzt wird, kann hier das vorhandene Mary-XML verwendet werden.

Mit der zweiten Gruppe können sekundäre Animationen realisiert werden. Hierzu wer-den Steuerungselemente bereitgestellt, mit denen Animationen gestartet werden kön-nen. Im Gegensatz zu anderen XML Dialekten wie VHML [150] wird kein fest vorgege-bener Satz von Animationen wie <smile>, <eye-blink> oder <look-right> eingesetzt.Stattdessen kann ein Anwender aus den Animationen und Morph-Zielen auswählen,die in dem aktuellen Modell verfügbar sind.

Mit den XML-Elementen der dritten Gruppe können Steuerungsaufgaben realisiertwerden. Um eine Synchronisierung der restlichen Simulation mit der Sprachausgabe zu


ermöglichen, wird das Konzept der Callbacks auch für die Sprachanimation verfügbargemacht. Hierdurch können benutzerde�nierte Aktionen ausgeführt werden, sobald einebestimmte Textstelle erreicht wird.

Beein�ussung der Audio-Ausgabe

Mary-XML enthält bereits viele Steuerungselemente, die die Audio-Ausgabe beein�us-sen. Hierzu gehören Elemente, mit denen die Aussprache, Betonung und Sprachmelo-die gesteuert werden können. Alle XML-Elemente sind umfassend in der Mary XML-Dokumentation erklärt, weswegen hier nur auf zwei wichtigere Elemente eingegangenwerden soll.

Zu den wichtigsten Steuerungselementen gehört das <prosody>-Element, mit demStimmhöhe, Sprechgeschwindigkeit und Lautstärke beein�usst werden können. Wer-te der Attribute werden als relative Veränderung de�niert.

Beispiele:

<prosody pitch="+40%"> Hohe Stimme, </prosody>

<prosody rate="+50%"> schnell gesprochen </prosody>

<prosody volume="-10%"> leise.</prosody>

Ein weiteres wichtiges Steuerungselement ist das <say-as>-Element. Mit diesem Ele-ment kann festgelegt werden, wie ein Text ausgesprochen werden soll.

Beispiele:

<say-as type="telephone">123</say-as>

<say-as type="number:roman">MMVII</say-as>

Beein�ussung der Animation

Mit den Steuerungselementen zur Beein�ussung der Animationen können vorhande-ne O�ine-Animationen und Morph-Ziele aktiviert werden. Hierzu werden die beidenXML-Elemente <animation> und <morph> eingeführt. Für beide existieren nochKurzschreibweisen, d.h. <animation> kann auch mit <a> und <morph> mit <m>abgekürzt werden.

Beide XML-Elemente unterstützen die gleichen Attribute. Dies ist neben dem Namen(name) auch das Gewicht (weight), mit der das Element eingemischt werden soll. DasGewicht kann sowohl relativ, als auch absolut angegeben werden. Auÿerdem kann eineVerzögerung (delay) in Sekunden de�niert werden, wodurch das de�nierte Gewicht erstnach der angegebenen Zeitdauer erreicht wird.

Die Dauer einer Animation wird durch das End-Tag festgelegt. Soll die Dauer unab-hängig von dem gesprochenen Text sein, kann als weiteres Attribut auch eine Dauer(duration) in Sekunden festgelegt werden.

Beispiele:

Schau, <a name="point_left" delay="0.5">da ist er!</a>

<m name="smile" weight="+10%" duration="0.8"/>Hallo!


<ph d="57" end="57" f0="(0,201)" p="v"/>

<ph d="47" end="104" p="I"/>

<ph d="42" end="146" p="l"/>

<ph d="82" end="228" p="k"/>

<ph d="74" end="302" f0="(50,200)" p="O"/>

<ph d="62" end="364" p="m"/>

<ph d="88" end="452" f0="(50,161) (100,150)" p="@"/>

<ph d="63" end="515" p="n"/>

Abbildung 8.6: Phonemliste des Wortes �Willkommen�

Kontrolle

Mit dem XML-Element <callback> kann zur synchronisierten Steuerung der Speech-Callback eines Avatars ausgelöst werden. Durch eine optionale Zeichenkette besteht dieMöglichkeit, den Callback zur Laufzeit zu identi�zieren.

Beispiel:

Ich drücke hier drauf <callback arg="light"/>,

und das Licht geht an!

8.4.2 Erzeugen der hörbaren Sprachausgabe

Für die Erzeugung der hörbaren Sprachausgabe wird in dieser Arbeit Mary-TTS ver-wendet, welches als Front-End für die beiden frei verfügbaren Synthesizer Festival undMBROLA verwendet werden kann. Durch den modularen Aufbau kann aber auch einanderer Sprachsynthesizer verwendet werden, wenn er auf Basis einer Phonem-Listeeine Audio-Ausgabe erzeugen kann.

Die Phonem-Liste wird von dem Phonemizer-Modul erzeugt, welches nicht nur zurErzeugung der Sprachausgabe eingesetzt wird, sondern auch für die Sprachanimation.Dieses Modul bekommt als Eingabe den um XML-Elemente erweiterten zu sprechendenText. Durch den Einsatz von Mary-TTS kann die Implementierung dieses Moduls starkvereinfacht werden. Sie beschränkt sich darauf, eine Anfrage mit dem Eingabetext anden Mary-TTS Server zu schicken und die erzeugte Phonemliste vom Server abzuholen.

Die Phoneme in dieser Liste werden im SAMPA (Speech Assessment Methods PhoneticAlphabet) Code angegeben. Bei diesem Code handelt es sich um ein ASCII-basiertesphonetisches Alphabet, welches im Rahmen des europäischen ESPRIT-Projekts SAM(Speech Assessment Methods) entwickelt wurde [105]. In Abbildung 8.6 ist ein Beispielfür eine Phonemliste zu sehen. Diese enthält neben den Phonemen auch Zeitangaben.

Die hörbare Sprachausgabe wird von dem Synthesizer-Modul erzeugt. Dieses Modulbekommt als Eingabe eine Liste von Phonemen mit Zeitangaben. Durch den Einsatzvon Mary-TTS kann sich das implementierte Synthesizer-Modul ebenfalls darauf be-schränken, eine Anfrage mit der Phonem-Liste an den Mary-TTS Server zu leiten unddie ankommenden synthetisierten Animationsdaten als Ergebnis zurückzuliefern. Wiebei der O�ine-Sprachausgabe werden diese Daten an einen Sound-Knoten übergeben,damit die Sprache hörbar wird.


Nr. Phonem Visem Beispiel

1 a:, a A Wagen, Watte

2 j, C C Junge, Wicht

3 i:, I, e:, E:, E E Bier, Tisch, Weg, Räte, Menge

4 f, v F Finder, Vase

5 m M Mutter

6 n, @n, l, @l N Nadel, raten, Liebe, Igel

7 o:, O O Wolle, Wogen

8 p, b P Pause, Bitte

9 @, 6 Q Bitte, Weiher

10 h, r, R, x, N R Hase, reden, Dach, Wange

11 s, z S Fass, sein

12 t, d, k, g T Tonne, Dach, König, Gier

13 u:, u, U U Buch, Runde

14 y:, Y, 2:, 9 Y Tür, Mütter, Goethe, Götter

15 S, Z, tS, dZ Z Schein, Garage, Tscheche, Dschungel

Tabelle 8.1: Phonem-Visem Zuordnung aus [119]

8.4.3 Generierung der Sprachanimation

Die Sprachanimation wird mit dem Visemizer-Modul erzeugt. Dieses Modul bekommtals Eingabe eine Liste von Phonemen im SAMPA-Code und liefert als Ergebnis eineMorph-Sequenz. Die Aufgabe des Moduls besteht darin, den SAMPA-Phonemen pas-sende Viseme zuzuordnen. Diese Zuordnung wird für die deutsche Sprache mit Tabelle8.1 vorgenommen.

Anschlieÿend werden die identi�zierten Viseme mit passenden Gewichtungsfaktorenin die Morph-Sequenz eingefügt. Hierzu muss auch die Koartikulation berücksichtigtwerden. Aus Zeitgründen wurde zunächst ein einfaches zeitgebundenes Modell imple-mentiert. Durch den modularen Aufbau des Teilsystems zur Online-Sprachanimationkönnen aber zu einem späteren Zeitpunkt auch andere Koartikulationsmodelle inte-griert werden.

Bei dem implementierten Modell wird die Darstellung eines Visems in drei Phasenunterteilt (P1 - P3, siehe Abbildung 8.7). In der ersten Phase wird das Visem mitverringerter Geschwindigkeit eingeblendet. Diese Phase wird bereits in der Endphasedes vorherigen Visems gestartet, wodurch die Viseme ineinander geblendet werden. Diezweite Phase startet, nachdem 15% der Dauer des Visems erreicht sind. In dieser Phasewird das Visem beschleunigt bis zu seinem vollen Gewicht (w) eingeblendet. Das volleGewicht wird bei 30% der Dauer erreicht. Ab diesem Zeitpunkt startet auch die letztePhase, in der das Visem wieder ausgeblendet wird. Das Gewicht, mit dem ein Visemeingeblendet wird, ist auch abhängig von der Dauer. Je länger die Dauer eines Visemsist, desto gröÿer ist sein Ein�uss auf das Aussehen des Modells.

In Abbildung 8.8 ist das Ergebnis einer Online-Sprachanimation zu sehen. In den dreiBildern sind die drei Abschnitte des Wortes �H-all-o� zu sehen. Obwohl das Koartiku-lationsmodell sehr einfach ist, führt es schon zu guten visuellen Ergebnissen. Für eineendgültige Beurteilung müssten jedoch noch andere Koartikulationsmodelle implemen-tiert und verglichen werden. Au�ällig ist auÿerdem, dass die Laute im Vergleich zur


P1 P2 P3

aktuelles Visemvorheriges Visem nächstes Visem

t

w

Abbildung 8.7: Phasen des implementierten Koartikulationsmodells

Abbildung 8.8: Online-Sprachausgabe

O�ine-Sprachausgabe ausgeprägter dargestellt werden (vgl. Abbildung 8.4).

8.4.4 Synchronisation von Mimik und Gestik

Die Synchronisierung von Mimik und Gestik mit der Sprachanimation wird von demSequenzer-Modul übernommen. Das Modul hat die Aufgabe, die eingebetteten sekun-dären Animationen zum richtigen Zeitpunkt auszulösen. Dabei ist es von Vorteil, dassMary-TTS die eingebetteten XML-Elemente im Datenstrom belässt. Hierdurch sindsie nach der Bearbeitung durch das Phonemizer-Modul weiterhin verfügbar. Sie sindjetzt jedoch in die ermittelten Phoneme eingebettet, weshalb sich der zeitliche Kontexteines eingebetteten XML-Elements ermitteln lässt (siehe Abbildung 8.9).

Um die eingebetteten sekundären Animationen während der Animation auszulösen,wurde die Morph-Sequenz erweitert. Sie kann dadurch neben Morph-Zielen auch ske-lettbasierte Animationen und den Sprach-Callback des Avatars auslösen. Auf dieseWeise ist es möglich, die gesamte Animation als Sequenz zu berechnen und in einerDatenstruktur abzulegen.


<ph d="114" end="114" p="S"/>

<ph d="221" end="335" f0="(50,225) (100,225)" p="aU"/>

<boundary breakindex="4" duration="300" tone="H-%"/>

<a delay="0.5" name="point_left">

<ph d="60" end="60" p="d"/>

<ph d="104" end="164" p="a:"/>

<ph d="55" end="219" p="?"/>

<ph d="52" end="271" p="I"/>

<ph d="68" end="339" p="s"/>

<ph d="51" end="390" p="t"/>

<ph d="44" end="434" p="?"/>

<ph d="152" end="586" f0="(100,142)" p="e:"/>

<ph d="39" end="625" p="6"/>

</a>

Abbildung 8.9: Phoneme mit eingebetteten XML-Elementen


Kapitel 9

Echtzeit Darstellung von Avataren

Wie im Konzept in Kapitel 3 festgelegt, wird die Darstellung der Avatare durch eine In-tegration von Cal3D in OpenSceneGraph realisiert. Diese wird im folgenden Abschnittbeschrieben. In dem zweiten Abschnitt wird gezeigt, wie eine OpenSceneGraph-Szenemit Hilfe von SYZYGY in der CasCave dargestellt werden kann.

9.1 Darstellung von Avataren in OpenSceneGraph

Die Animation der Avatare erfolgt durch die Cal3D-Bibliothek. Damit eine Darstel-lung dieser Modelle in OpenSceneGraph realisiert werden kann, ist eine Kenntnis derverwendeten Datenstrukturen notwendig. Diese werden in den folgenden beiden Ab-schnitten erläutert. Im Anschluss daran folgt die Beschreibung der Integration vonAvataren in den Szenengraphen.

9.1.1 Datenstrukturen und Funktionsweise von Cal3D

Als Plattform- und Gra�k-API unabhängige Animationsbibliothek beschränkt sichCal3D auf die Bereitstellung von Datenformaten für die Speicherung von Avatar-Modellen, sowie Funktionen, mit denen Modelle animiert werden können. Zur Ablageder Modelldaten bietet Cal3D mehrere Datenformate an, die jeweils bestimmte Eigen-schaften speichern können:

Skelett (Skeleton): Eine Skelettdatei speichert die Gelenk-Hierarchie eines Avatars.Dieses Skelett kann mit Hilfe von Cal3D animiert werden.

Geometrie (Mesh): Ein- oder mehrere Geometriedateien speichern das Modell desAvatars. Jede Geometriedatei enthält ein- oder mehrere Geometrieblöcke, im fol-genden Submesh genannt. Jedem Submesh kann genau ein Material zugewie-sen werden. Des Weiteren werden in jedem Submesh Geometrieinformationen inForm von Eckpunkte- und Polygonlisten gespeichert. Jedem Eckpunkt können ei-ne Normale, mehrere Texturkoordinaten, sowie die Gewichtungsfaktoren für dieskelettbasierte Animation zugewiesen werden.

149

150 KAPITEL 9. ECHTZEIT DARSTELLUNG VON AVATAREN

CalCoreSkeleton CalCoreMesh

CalCoreModel

CalCoreMaterial

CalModel

CalCoreAnimation

CalRendererCalMixerCalMorphMixer

* * *

1 *

Abbildung 9.1: Cal3D Klassendiagramm

Materialien (Material): Eine Materialdatei beschreibt genau ein Material, wobeijedes Material Farbbeschreibungen für indirektes, direktes und glänzendes Lichtenthalten kann. Daneben kann eine beliebige Anzahl an Texturen gespeichertwerden, wobei diesen keine bestimmte Funktion zugewiesen wird.

Animationen (Animation): Eine Animationsdatei enthält genau eine Animation.Diese besteht aus Positions- und Rotationsangaben für die Gelenke der Ske-letthierarchie. Eine Animation muss sich nicht auf alle Gelenke des Skeletts aus-wirken, sondern kann auch nur eine Teilmenge verändern. Auf diese Weise kön-nen beispielsweise Animationen für Ober- und Unterkörper oder Bewegungen derHände in verschiedenen Dateien abgelegt werden.

Ein komplettes Avatar-Modell besteht somit aus einer Skelettdatei, sowie einer beliebi-gen Anzahl an Geometrie-, Material- und Animationsdateien. Jede Komponente wird indem Cal3D API durch eine eigene Klasse repräsentiert (siehe Abbildung 9.1). Weiterhinwerden Funktionen zum Laden und Speichern dieser Daten, sowie zum Erzeugen deranimierten Geometrie des Avatars bereitgestellt. Hierzu unterscheidet Cal3D zwischenKern- und Laufzeitklassen.

Kernklassen speichern die statischen Eigenschaften eines Modells. Zu diesen Kernklas-sen gehören die Komponenten selbst, sowie die CalCoreModel-Klasse, mit der ein kon-kretes Avatar-Modell de�niert werden kann. Laufzeitklassen speichern die zur Laufzeitbenötigten Informationen - wie den aktuellen Animationszustand - und bieten auÿer-dem die Möglichkeit, die aktuelle Geometrie abzufragen.

Zu den Laufzeitklassen gehört die CalModel Klasse, die ein Modell zur Laufzeit reprä-sentiert. Die Daten des Modells bezieht diese Klasse aus einem CalCoreModel, wobeisich mehrere Modelle ein CalCoreModel teilen können. Zur Verwaltung der Animationenthält jedes CalModel Mixer für skelettbasierte Animation und Morphing. Diese Mi-xer können von der Anwendung kontrolliert werden und ermöglichen so die Steuerungder Animation. Die Aufgabe der Mixer besteht darin, abhängig von der Zeit die Geo-metrie, bzw. das Skelett zu aktualisieren. Die aktualisierten Daten werden dann an denRenderer weitergereicht, der die aktuellen Geometrie-Informationen berechnet. (sieheAbbildung 9.2).

KAPITEL 9. ECHTZEIT DARSTELLUNG VON AVATAREN 151

Abbildung 9.2: Cal3D Render-Pipeline

9.1.2 Datenstrukturen und Funktionsweise von OpenSceneGraph

Darstellbare Objekte werden in OpenSceneGraph durch den Geode Knotentyp reprä-sentiert. Geodes enthalten nicht die Geometrie selbst, sondern dienen als Container fürmehrere darstellbare Elemente. Dies können unter anderem Geometrie-Objekte sein.Geometrie-Objekte können polygonbasierte Modelle auf Basis von Eckpunkten undPolygonlisten speichern. Auÿerdem können zu jedem Eckpunkt Normalen und Textur-koordinaten gespeichert werden. Hierdurch ähneln sich Geometrie-Objekte und Cal3DSubmesh Strukturen.

Die Darstellung der Geometrie - d.h. Farbe und Texturen - wird durch ein State-Set de-�niert. Ein State-Set kapselt OpenGL Zustände. Da viele Zustandswechsel die Render-leistung negativ beein�ussen, sollten sie möglichst vermieden werden. OpenSceneGrapherlaubt es daher, dass State-Sets wiederverwendet werden können. Dies ermöglicht ei-ne automatische Sortierung der darzustellenden Geometrie nach Materialeigenschaftenund kann daher die Darstellung beschleunigen.

Die Animation einer Geometrie kann dadurch erreicht werden, dass die gespeichertenEckpunkte zur Laufzeit verändert werden. Diese Änderungen müssen in der Update-Stufe des Szenengraphen erfolgen (siehe auch Abbildung 3.5 auf Seite 65). Wie beiSkript-Knoten können auch hier Node-Callbacks eingesetzt werden, wodurch die Geodedas Aussehen der angehängten Geometrie-Objekte beein�ussen kann.

9.1.3 Integration von Avataren in den Szenengraphen

Die Integration der Avatare erfolgt im wesentlichen durch die Implementierung einesneuen Geode-Knotens, der um zwei neue Geometrie Typen ergänzt werden kann (sie-he Abbildung 9.3). Die Klasse Model kapselt die CalModel Klasse und organisiert diegra�sche Darstellung. Hierzu gehört die Erzeugung einer CalModel Instanz, sowie derGeometrie-Objekte, die die Darstellung übernehmen. Des Weiteren registriert die Klas-se einen Node-Callback, der zur Aktualisierung des Avatar-Modells verwendet wird. Dieneuen Geometrie-Klassen werden zur Darstellung der Skelettstruktur (Bones) und derCal3D Geometrie-Strukturen (Submesh) verwendet. Hierbei wird jedes Cal3D Submeshdurch ein eigenes Submesh im Szenengraphen repräsentiert.

Als vierte Klasse wurde eine CoreModel Klasse implementiert, die ein CalCoreModelkapselt und auÿerdem die Verwaltung gemeinsamer Daten - beispielsweise der Texturen


Geometry

BumpMapping

CoreModel ModelUpdateCallback

NodeCallbackCalCoreModelObject

1 *

*1 *

Model

BonesSubMesh

GeodeCalModel

Abbildung 9.3: Klassendiagramm des Subsystems für die Darstellung von Avataren

- übernimmt. Die CoreModel Klasse liest eine Avatar-Kon�guration ein und bereitet dieDaten zur Verwendung auf. Hierzu gehören neben dem Einladen der Texturen auch dasErstellen von Morph-Animationen zu jedem verfügbaren Morph-Ziel. Als zusätzlicheErweiterung ermöglicht die Klasse die Verwendung der OpenSceneGraph Referenz-Zeiger, wodurch ein CoreModel automatisch aus dem Speicher entfernt wird, sobalddas letzte referenzierende Model gelöscht wird.

Darstellung von Avataren

Zum Zeitpunkt der Erstellung fragt jedes Submesh Geometrie- und Materialinforma-tionen von dem Cal3D Renderer ab und überträgt diese in die OpenSceneGraph Struk-turen. Von den Geometrieinformationen müssen Polygonlisten und Texturkoordinatennur während dieser Initialisierung abgefragt werden, da sie ansonsten unverändert blei-ben.

Zur Laufzeit erfolgt die Aktualisierung der Geometrie durch den Node-Callback. Die-ser ruft mit jedem Update-Zyklus die Aktualisierungsmethode der Model-Klasse auf,welche die seit dem letzten Aufruf vergangene Zeit ermittelt und an die Cal3D Mixerweitergibt. Anschlieÿend werden alle angehängten Geometriestrukturen zum Updateaufgefordert. Diese verwenden den Cal3D Renderer, um die aktuellen Eckpunkte undNormalen in die OpenSceneGraph Strukturen zu übertragen.

Darstellung von transparenten Texturen

Insbesondere bei der Darstellung von Haaren spielen transparente Texturen eine wichti-ge Rolle. OpenSceneGraph unterstützt die Darstellung von transparenten Texturen mitHilfe der OpenGL Blending Funktion. Hierzu werden Texturen mit einem Alpha-Kanalbenötigt, der angibt, inwieweit hinter der Textur liegende Objekte durchscheinen.

Solche Texturen können auf zweierlei Weise erzeugt werden. Die eine Möglichkeit be-steht in der Erstellung mit einem Bildbearbeitungsprogramm und der Speicherung in


Abbildung 9.4: Jessi ohne und mit Transparenz

einem Datenformat, welches einen Alpha-Kanal unterstützt (z.B. PNG). Die andereMöglichkeit besteht darin, solche Texturen zur Laufzeit durch die Gra�kkarte berech-nen zu lassen. Hierzu wird eine Farb-Textur und eine zweite Textur mit Alpha-Maskebenötigt. Beide Texturen können dann mit dem OpenGL Textur-Kombinierer zu einerTextur mit Alpha-Maske zusammengefasst werden.

Beide Möglichkeiten sollen auch in dem Avatar-System eingesetzt werden können. Dadie Textur-Kombinierer auch für Bump-Mapping E�ekte eingesetzt werden, wurde aufderen Einsatz bei transparenten Texturen verzichtet. Stattdessen wird das Kombinierenvon Farb-Textur und Alpha-Maske von der CoreModel-Klasse übernommen, wenn inden Materialeinstellungen eine Transparenz-Maske angegeben wurde. Hierzu wird dieMaske bei Bedarf zunächst in Graustufen umgewandelt und anschlieÿend in den Alpha-Kanal der Farb-Textur kopiert.

Bei der Initialisierung der Materialien überprüft jedes Submesh, ob in der Farb-Texturein Alpha-Kanal vorliegt. Falls dies zutri�t, wird die Blending-Funktion für dieses Ma-terial aktiviert. Abbildung 9.4 zeigt ein Rendering ohne und mit Verwendung vontransparenten Texturen. Die Unterschiede in der Darstellung werden insbesondere amHaaransatz und den Wimpern deutlich sichtbar.

Darstellung von Bump-Maps

In OpenSceneGraph ist die Unterstützung von Bump-Maps bereits in das E�ektmodulosgFX integriert. Damit der E�ekt verwendet werden kann, benötigt die Geometriezwei Texturen. In der ersten Texturebene wird die Bump-Map gespeichert. Darauffolgt in der nächsten Ebene die Farb-Textur. Auÿerdem werden für jede TexturebeneTexturkoordinaten benötigt. Der E�ekt kann durch Anhängen der so vorbereitetenGeometrie an einen osgFX-BumpMapping Knoten aktiviert werden.

osgFX-BumpMapping implementiert das so genannte �Dot3 Bump-Mapping�. DiesesVerfahren hat den Vorteil, dass es direkt von modernen Gra�kkarten unterstützt wird.Hierbei werden die Höheninformationen nicht in Graustufenbildern kodiert, sondernin RGB Bildern (siehe Abbildung 9.5). Die RGB Kanäle werden dazu verwendet, umje Pixel der Farb-Textur einen Normalenvektor abzuspeichern. Der R-Kanal enthältdabei das Relief des Materials, wenn es von rechts mit Licht angestrahlt wird. Die G-und B-Kanäle enthalten entsprechend das Relief, wenn das Material von unten bzw.von vorne angestrahlt wird [100]. Dot3 Bump-Maps können mit verschiedenen Plugins


(a) Bump-Map mit Graustufen (b) Bump-Map im Dot3-Format

Abbildung 9.5: Bump-Maps

für Photoshop oder Gimp [59, 36], sowie mit eigenständigen Konvertern [3] umgewan-delt werden. nVidia bietet auÿerdem noch ein Programm an, mit dem die detaillierteStruktur eines hochpolygonalen Modells per Bump-Mapping auf ein niedrigpolygonalesModell übertragen werden kann [60].

Die Aufbereitung der Geometrie für das Bump-Mapping wird von der Submesh-Klasseübernommen. Diese überprüft, ob in den Cal3D Materialeinstellungen eine Bump-Mapvorhanden ist. Falls dies zutri�t, wird diese in der ersten Texturebene aktiviert. An-schlieÿend wird die Farb-Textur hinzugefügt.

Ein Problem ist die Bereitstellung der Texturkoordinaten für die Bump-Map. Cal3Dunterstützt zwar Texturkoordinaten für mehrere Ebenen, viele Exporter exportierenaber nur die Koordinaten der Farb-Textur. Oft haben Farb-Textur und Bump-Map aberdas gleiche Layout. Daher verwendet die Submesh-Klasse die Texturkoordinaten derFarb-Textur, falls keine Texturkoordinaten für die Bump-Map bereitgestellt wurden.

Da an den osgFX-BumpMapping Knoten nur diejenigen Submesh-Objekte angehängtwerden dürfen, die für Bump-Mapping vorbereitet sind, stellt die Model-Klasse die er-zeugten Submesh-Objekte in zwei Gruppen zusammen. Objekte ohne Bump-Mappingwerden direkt angehängt. Die anderen Objekte werden in einer separaten Geode orga-nisiert. Diese Geode fungiert nur als Container, d.h. die eigentlichen Aktualisierungender Submesh-Objekte werden nach wie vor von der Model-Klasse übernommen. DieseContainer-Geode kann dann an den E�ektknoten angebunden werden, so dass sich dasBump-Mapping nur auf diese Teilmenge auswirkt. Abbildung 9.6 zeigt ein Modell ohneund mit aktiviertem Bump-Mapping. Im rechten Bild sind Falten und Unebenheitenin der Haut deutlich sichtbar.

9.2 Darstellung von Avataren in der CasCave

Zur Darstellung der Avatare in der CasCave ist eine Kopplung des OpenSceneGraph mitder VR-Software der CasCave notwendig. Zur Umsetzung wird das SYZYGY Master-Slave Rahmenwerk verwendet. Dieses wird im folgenden kurz beschrieben. Es folgtdann eine Erklärung der Kopplung.


Abbildung 9.6: James ohne und mit Bump-Map

9.2.1 Das SYZYGY Master-Slave Rahmenwerk

Das SYZYGY Master-Slave Rahmenwerk ermöglicht die Synchronisierung einer An-wendung, die auf mehreren Rechnern parallel läuft. Einziger Unterschied zwischen denparallelen Instanzen der Anwendungen ist die jeweilige Projektionseinstellung für dieDarstellung, wodurch die drei Wände der CasCave jeweils mit den richtigen Bildinfor-mationen versorgt werden können.

Insgesamt werden in der CasCave drei Rechner für die Darstellung eingesetzt. Einer die-ser Rechner (idR. derjenige, auf dem die Anwendung zuerst gestartet wurde) fungiertals Master und ist dafür verantwortlich, Eingaben- und andere Kontrollinformationenan die beteiligten Slaves zu senden. Die Verteilung der Informationen wird über ei-ne Shared Memory Technik realisiert. Hierzu werden Speicherbereiche de�niert, diedurch das Rahmenwerk auf alle beteiligten Rechner gespiegelt werden. Nur der Masterkann auf diese Bereiche schreibend zugreifen. Alle anderen Rechner können aus diesenBereichen nur lesen.

SYZYGY-Master-Slave Anwendungen durchlaufen fest vorgegebene Bearbeitungsstu-fen. Jede Stufe wird durch das Rahmenwerk initiiert, wodurch SYZYGY die Synchro-nisierung der Anwendungen übernehmen kann. Zu diesen Stufen gehören:

Init: In dieser Stufe können Anwendungen ihre Initialisierung vornehmen. Hauptsäch-lich werden hier die Speicherbereiche für das Shared Memory de�niert.

PreExchange: Die PreExchange-Stufe wird ausgeführt, bevor die Daten des SharedMemory vom Master zu den Slaves übertragen werden. Innerhalb dieser Funk-tion kann der Master den Zustand der Simulation aktualisieren und Daten indas Shared Memory schreiben. Diese Stufe wird allerdings auch von den Slavesdurchlaufen, wobei hier Schreibzugri�e ignoriert werden. In der Praxis kann dieseStufe daher von den Slaves übersprungen werden.

PostExchange: Die PostExchange-Stufe wird ausgeführt, nachdem die Daten desShared Memory vom Master zu den Slaves übertragen wurden. Alle Rechner ha-ben jetzt den gleichen Datenstand und können nun ggf. ihrerseits die Simulationaktualisieren. Diese Stufe ähnelt daher der Update-Stufe bei Szenengraphen.

Draw: In dieser Stufe kann die aktualisierte Szene auf dem Bildschirm dargestelltwerden. Hierzu stellt das Rahmenwerk einen OpenGL-Kontext bereit, so dass die


Master

Poll input devices

PreExchange

Init shared memory

Draw

PostExchange

Slave

PreExchange

Init shared memory

Draw

PostExchange

Slave

PreExchange

Init shared memory

Draw

PostExchange

Distribute shared memory

Sync

Abbildung 9.7: Das SYZYGY Master-Slave Rahmenwerk

Darstellung mit OpenGL-Befehlen vorgenommen werden kann. Vor dem Aufrufwerden die aktuellen Darstellungsparameter durch das SYZYGY Rahmenwerkgesetzt, d.h. eine Anwendung muss sich nicht darum kümmern, für welche Wandsie das aktuelle Bild rendert. Stereo-Darstellungen - wie sie auch in der CasCaveeingesetzt werden - erfordern die Darstellung der Szene aus zwei leicht unter-schiedlichen Betrachtungswinkeln. Daher wird die Draw-Stufe im Stereobetriebzweimal hintereinander ausgeführt.

Die letzten drei Stufen werden zyklisch aufgerufen. Die Synchronisierung erfolgt durchzwei Schranken. Eine Anwendung darf eine Schranke erst dann passieren, wenn alleAnwendungen die Schranke erreicht haben (siehe Abbildung 9.7). Aus Entwicklersichtwird eine Anwendung durch Callbacks an das Master-Slave Rahmenwerk gebunden. Fürjede Bearbeitungsstufe kann eine C++ Funktion registriert werden, die bei Aktivierungder Stufe aufgerufen wird.

Das Rahmenwerk kümmert sich auÿerdem noch um die Verarbeitung der Eingabeda-ten. Hierzu verwaltet SYZYGY eine Navigationsmatrix, aus der die aktuelle Nutzer-position und -orientierung ermittelt werden können. Hinzu kommen die aus OpenGLbekannten Parameter zur Beein�ussung der aktuellen Ansicht (Projection- und Mo-delview Matrix), deren Inhalt durch die CasCave Kon�guration vorgegeben wird. Dieaktuelle Sicht des Anwenders kann durch Multiplikation der Navigationsmatrix mit derModelview-Matrix ermittelt werden.

9.2.2 Darstellung einer Szene mit OpenSceneGraph

Da das SYZYGY Master-Slave Rahmenwerk bereits einen OpenGL-Kontext bereit-stellt, wird eine Möglichkeit benötigt, mit der eine OpenSceneGraph-Szene in einen be-stehenden Kontext gerendert werden kann. Hierzu kann die OpenSceneGraph SceneView-Klasse verwendet werden. Diese kapselt Bildschirmeinstellungen wie Projection- und


Modelview Matrix, sowie Einstellungen über den Stereomodus. Auÿerdem stellt sieMethoden bereit, mit denen die drei Bearbeitungsstufen des Szenengraphen (�update�,�cull� und �draw�) ausgeführt werden können.

Problematisch bei dem Einsatz der SceneView-Klasse ist dabei zunächst der Umstand,dass die Klasse nur die intern gespeicherten Parameter zur Darstellung verwendet.Bereits voreingestellte OpenGL-Parameter - wie sie von dem SYZYGY-Rahmenwerkgesetzt werden - werden ignoriert. Erschwerend kommt hinzu, dass die SceneView-Klasse eine Szene im Stereobetrieb ebenfalls automatisch zweimal zeichnet. Da dasMaster-Slave Rahmenwerk das Zeichnen ebenfalls zweimal anstöÿt, wird dadurch dieSzene bei jedem Durchgang insgesamt viermal gerendert. Es müssen daher folgendeProbleme gelöst werden:

• Kon�guration der SceneView-Klasse entsprechend den SYZYGY-Einstellungen.

• Setzen der Darstellungsparameter für linkes und rechtes Auge im Stereobetrieb.

• Vermeidung des doppelten Renderings im Stereobetrieb.

Die Kon�guration erfolgt durch Abfrage der Parameter aus der SYZYGY Kon�gura-tionsdatenbank und Anpassung der Werte an OpenSceneGraph. Hierzu gehören Para-meter, die die Gröÿe und den Darstellungsmodus der Wiedergabe�äche beein�ussen.Hierbei unterscheiden sich SYZYGY und OpenSceneGraph in den verwendeten Einhei-ten. SYZYGY verwendet �Fuÿ� (feet), während OpenSceneGraph �Meter� verwendet.Daher müssen Gröÿenangaben entsprechend umgerechnet werden. Da die Avatare imMaÿstab 1:1 in der CasCave angezeigt werden sollen, ist hiervon auch die Skalierungder Szene betro�en. Diese wird in SYZYGY durch einen Skalierungsfaktor festgelegt,der eine Umrechnung von Fuÿ in generische Einheiten erlaubt. Da bei den Avatareneine OpenSceneGraph Einheit einem Zentimeter in der Realität entspricht, ergibt sichhierdurch ein Skalierungsfaktor von 30,48 (1 Fuÿ = 30,48 cm).

Die Darstellungsparameter für linkes und rechtes Auge berechnet die SceneView-Klasseauf Basis der aktuellen Einstellungen selbst. Für eine korrekte Darstellung der CasCavemüssen diese Einstellungen daher so vorgenommen werden, dass OpenSceneGraph diegleichen Darstellungsparameter errechnet wie SYZYGY. Besser wäre es jedoch, wenndie von dem SYZYGY Rahmenwerk berechneten Parameter möglichst direkt auch vonder SceneView-Klasse verwendet werden könnten.

Diese direkte Übernahme kann mit Hilfe eines Stereo-Matrix Callback gelöst werden.Der Stereo-Matrix Callback ermöglicht es, die automatische Berechnung der Darstel-lungsparameter zu umgehen und stattdessen die Parameter selbst zu berechnen. Imkonkreten Fall ist keine Berechnung notwendig. Stattdessen wurde ein Stereo-MatrixCallback implementiert, der die von dem SYZYGY Rahmenwerk errechneten Werteabfragt.

Das doppelte Rendern der Szene kann dadurch verhindert werden, dass im Stereo-betrieb nur jede zweite SYZYGY Darstellungsau�orderung an die SceneView-Klasseweitergegeben wird. Ungerade Aufrufe werden daher ignoriert, und nur bei geradenAufrufen werden die �cull� und �draw� Stufen der SceneView-Klasse aktiviert.


9.2.3 Synchronisierung der OpenSceneGraph Anwendungen

Da zur Laufzeit insgesamt drei OpenSceneGraph Instanzen in der CasCave aktiv sind,müssen diese untereinander synchronisiert werden. Dies ist insbesondere für Anima-tionen und Partikele�ekte erforderlich. Zur Steuerung der Animationen werden dieSkript-Knoten aus Kapitel 7 verwendet. Da auf jedem Render-Rechner das gleicheSkript läuft, sollten alle Rechner synchron arbeiten, wenn die Skripte die gleichen Er-eignisse verarbeiten. Zu diesen Ereignissen gehören:

• Bearbeitungsau�orderungen des SYZYGY Rahmenwerks (PreExchange, PostEx-change)

• Benutzereingaben

• Zeitliche Ereignisse

• Ereignisse auf Basis von Zufallszahlen

Bearbeitungsau�orderungen des SYZYGY Rahmenwerks werden durch das Rahmen-werk selbst synchronisiert. Das gleiche gilt für Benutzereingaben, die von dem Rah-menwerk zentral verarbeitet und auf allen Rechnern bereitgestellt werden.

Zeitliche Ereignisse haben Ein�uss auf die Berechnung von Animationen und Partikel-e�ekten. Innerhalb des Szenengraphen werden hierzu Zeitstempel verwendet. JedemFrame wird ein eindeutiger Zeitstempel zugeordnet, der sich aus Zeit und einer Frame-Nummer zusammensetzt. Wird in jeder Szenengraphen Instanz der gleiche Zeitstempelverwendet, dann laufen auch alle Animationen synchron. Der Zeitstempel wird daherüber das Shared Memory auf alle Render-Rechner verteilt. Der Master sorgt dafür, denZeitstempel in der PreExchange Stufe zu aktualisieren.

Da die Anwendungen synchron laufen, fordern sie in der gleichen Reihenfolge Zufalls-zahlen an. Es muss also dafür gesorgt werden, dass auf jedem Rechner die gleichenZufallsfolgen generiert werden. Dies kann durch die Festlegung eines einheitlichen In-itialisierungswertes für den Zufallsgenerator realisiert werden.

Bei dem SYZYGY Master-Slave Rahmenwerk kann ein Rechner zu jedem beliebigenZeitpunkt den anderen Render-Rechnern beitreten. Hierdurch reicht der Zeitstempelalleine nicht mehr aus, damit sich eine Anwendung zu jedem Zeitpunkt auf die anderenparallel laufenden Anwendungen synchronisieren kann. Es müssten daher mehr Infor-mationen im Shared-Memory bereitgestellt werden. Auf der anderen Seite wird dieseFlexibilität bei dem Einsatz in der CasCave nicht benötigt. Es reicht hier aus, wenndie Anwendungen erst dann starten, wenn alle Rechner startklar sind.

Es wurde daher eine Unterscheidung in verschiedene Run-Level eingeführt. Der Run-Level wird durch den Master kontrolliert und ist zunächst im Initialisierungszustand. Indiesem Zustand bleibt der Zeitstempel konstant und es wird auf den bereits gestartetenRechnern eine Wartemeldung angezeigt. Erst wenn alle Rechner gestartet sind, wird derRun-Level in den Ablaufzustand versetzt. Ab diesem Zeitpunkt wird die richtige Szenein den Szenengraphen eingehängt und der Zeitstempel durch den Master aktualisiert.

Durch diesen Mechanismus beschränken sich die Daten im Shared-Memory auf denZeitstempel und den Run-Level. Durch den gemeinsamen Start und die restlichen Syn-chronisierungsmechanismen laufen alle Anwendungen implizit synchron.


SzgStereoMatricesCallback

SceneView StereoMatricesCallback

SzgViewer

Abbildung 9.8: Klassendiagramm des CasCave Darstellung

9.2.4 Implementierung

Die Kopplung zwischen SYZYGY und OpenSceneGraph wurde in einer Klasse imple-mentiert (siehe Abbildung 9.8), deren vier Hauptmethoden die Bearbeitungsstufen desMaster-Slave Rahmenwerks widerspiegeln. Die Methoden übernehmen folgende Funk-tionen:

start: Diese Methode initialisiert das Shared Memory und setzt den Run-Level in denInitialisierungszustand. Auÿerdem ermittelt sie die SYZYGY Darstellungspara-meter und reicht sie an den Szenengraphen weiter.

preExchange: Diese Methode kontrolliert auf dem Master den aktuellen Run-Level.Ist dieser im Initialisierungszustand, wird die Anzahl der angemeldeten Slavesüberprüft. Falls alle Slaves angemeldet sind, wird der Run-Level in den Ablauf-zustand gesetzt. Im Ablaufzustand wird der Zeitstempel aktualisiert.

postExchange: Die postExchange-Methode überträgt den aktuellen Zeitstempel inden Szenengraphen und löst danach ein Update des Szenengraphen aus.

drawFrame: Diese Methode speichert zunächst die aktuellen Darstellungsparameter.Sind im Stereomodus die Parameter für linkes und rechtes Auge aktuell, werdendie �cull�- und �draw�-Stufen des Szenengraphen aktiviert.

Die Methodenaufrufe können in die entsprechenden Callbacks des Master-Slave Rah-menwerks integriert werden, wodurch eine einfache Integration von OpenSceneGraphermöglicht wird.

Erweiterung des Skript-Knotens

Die Skript-Knoten wurden für den CasCave-Betrieb erweitert, um die Verarbeitungvon Benutzereingaben und die Steuerung der Ansicht zu erlauben. Hierdurch hat einSkript Zugri� auf die Navigationsmatrix - die in einer Kamera-Klasse gekapselt wur-de - , sowie auf die aktuellen Parameter und Werte des Master-Slave Rahmenwerks.Es wurde auÿerdem noch ein neuer PreExchange-Callback hinzugefügt. Der Update-Callback wurde unverändert übernommen und entspricht dem SYZYGY PostExchangeCallback.

Abbildung 9.9 zeigt ein Foto aus der CasCave, bei der eine Anwendung durch ein Skriptgesteuert wird. Da die Schnittstelle der Kamera-Klasse der originalen Kamera-Klassegleicht, konnte diese Anwendung zunächst auf einem Einzelplatz-System entworfen unddann unverändert in der CasCave dargestellt werden.


Abbildung 9.9: Avatar in der CasCave

Kapitel 10

Anwendungen des Avatar-Systems

Das Avatar-System wurde bereits in mehreren Projekten eingesetzt. Von diesen Pro-jekten sollen im folgenden zwei Projekte als Beispiele für die Einsatzmöglichkeiten desSystems vorgestellt werden. Bei dem ersten Beispiel handelt es sich um die Entwicklungeines Tutorials für eine Trainingssimulation. Hierbei wurden Avatare zur Erklärung derOber�äche und zur Belebung der Szenerie eingesetzt. Bei dem zweiten Beispiel handeltes sich um ein internes Projekt zur Visualisierung von Simulationsergebnissen. Anhanddieses Beispiels kann der Einsatz von Skript-Knoten als universelle Steuerungsmöglich-keit demonstriert werden.

10.1 Entwicklung eines Tutorials für das Projekt�GaFab�

10.1.1 Projektziel

Das vom Hessischen Ministeriums für Wissenschaft und Kunst im Rahmen eines e-Learning Wettbewerbs geförderte Projekt �Ganzheitliche Fabrik� wurde in Kooperationder beiden Fachbereiche Elektrotechnik/Informatik und Maschinenbau der UniversitätKassel durchgeführt [214]. Ziel des Projektes war es, einen konzeptionellen Ansatz zurUmsetzung einer interaktiven Simulationsplattform zu entwickeln und anhand einesPrototyps zu testen.

Mit Hilfe der Plattform sollen Studierende die Ressourcen und Prozesse einer Fabrikanalysieren können, um die theoretischen Grundlagen aus produktionstechnischen Vor-lesungen zu erproben und zu vertiefen. Dabei wird die Fabrik als begehbares, dreidi-mensionales Modell dargestellt.

10.1.2 Konzept

Die Simulationsplattform �Ganzheitliche Fabrik� besteht im wesentlichen aus den zweiKomponenten Tutorial und Fabriksimulation. Das Tutorial dient als Startportal derPlattform und hat die Aufgabe, Studierenden das Projekt und vorhandene Szenarienzu erläutern (siehe Abbildung 10.1 (a)). Studierende haben auÿerdem die Gelegenheit,

161

162 KAPITEL 10. ANWENDUNGEN DES AVATAR-SYSTEMS

die Fabrik zu begehen und sich über die Bestandteile der Anlage zu informieren (siehe10.1 (b)). Innerhalb des Tutorials werden Avatare für verschiedene Aufgaben einge-setzt. Zum einen geben sie gra�sch animiert Erklärungen zum Ablauf des Tutorialsund unterstützen bei der Erkundung der Fabrik. Zum anderen werden die Szenen mitanimierten Arbeitern belebt und so ein realistischerer Eindruck der Fabrik vermittelt.

Erst wenn sich der Anwender über vorhandene Aufgabenstellungen eines Szenariosinformiert hat, wird die Fabriksimulation gestartet. Hierbei wird auf eine Eigenent-wicklung des Fachbereichs Maschinenbau zurückgegri�en. Innerhalb der Simulationerhalten Studierende in unterschiedlichen Szenarien die Möglichkeit, zentrale Stellgrö-ÿen der Maschinen in der Fabrik wie Taktzeiten, Verfügbarkeit, Ausschussraten etc.zu verändern. Über die Ergebnisse der Simulationsläufe erhalten sie zum einen mate-rial�usstechnische Informationen. Zum anderen können sie aber auch bilanztechnischeZusammenhänge erkennen. In einem �learning by doing�-Ansatz werden somit proze-durale Lernziele verfolgt.

Kon�gurationen und Inhalte sollen mit geringem technischen Aufwand änderbar sein.Daher werden Kon�gurationseinstellungen in XML-Dateien und Texte zur Beschrei-bung der Szenarien in HTML-Dateien abgelegt. Die Avatare werden durch Lua-Skriptegesteuert, die ebenfalls als ASCII-Text vorliegen und sich daher einfach ändern lassen.

10.1.3 Realisierung

Zur technischen Realisierung wurden die in dieser Arbeit entwickelte Avatar-Klasse undder Skript-Knoten eingesetzt. Die Aufgaben des Skript-Knotens liegen in dem Aufbaudes dreidimensionalen Modells, sowie in der Steuerung der Avatare. Beide Komponen-ten wurden in eine Qt-Benutzerober�äche integriert, welche die Auswahl eines Szenariosund den Start der Simulation ermöglicht.

Ein Szenario besteht aus drei Komponenten. Dies ist zum einen ein Erklärungstextim HTML-Format. Durch das HTML-Format können den Texten auch Bilder hinzuge-fügt werden. Sobald ein Szenario ausgewählt wird, wird der Erklärungstext innerhalbder Tutorial-Ober�äche angezeigt. Ein Anwender kann dann entweder den Rundgangstarten oder die Simulation durchführen.

Als zweite Komponente wird ein Lua-Skript benötigt, welches das begehbare Modellaufbaut, sowie die darin eingesetzten Avatare kontrolliert. Dieses Skript wird ausge-führt, wenn der Anwender sich zu einem Rundgang entschlieÿt. Um das Erstellen vonSkripten zu erleichtern, wurde die Avatar-Klasse um Lua-Methoden erweitert. DieseErweiterung ermöglicht die Steuerung der Avatare in kooperativen Threads. In Abbil-dung 10.2 ist ein Beispiel für ein solches Skript zu sehen, in dem ein Avatar das Modellbetritt und die Ober�äche kurz vorstellt.

Als letzte Komponente wird noch eine Kon�gurationsdatei für den Fabriksimulatorbenötigt, welche im XML-Format vorliegt. Da der Fabriksimulator ebenfalls OpenSce-neGraph zur Visualisierung einsetzt, können Avatare auch in die Simulation integriertwerden. Hierzu kann parallel zum Simulations-Knoten ein Skript-Knoten eingefügt wer-den. Dies ermöglicht eine Erweiterung der visuellen Darstellung der Simulation, bei-spielsweise durch Hinzufügen von Avataren oder einer Fabrikhalle.

KAPITEL 10. ANWENDUNGEN DES AVATAR-SYSTEMS 163

(a) Einführung in die Ober�äche

(b) Begehung der Fabrik

Abbildung 10.1: Beispiele aus dem Tutorial der Simulationsplattform �GaFab�


function intro(avatar)

avatar:move(1)

avatar:turn(90,-1)

avatar:stop()

avatar:say("Willkommen in der virtuellen Fabrik!","greeting")

avatar:say("Hier auf der rechten Seite können Sie Näheres zum

Projekt

erfahren.","point_left")

avatar:say("Mit den Schaltflächen links können Sie ein Szenario

auswählen und die Simulation starten.","point_right")

avatar:say("Bis gleich!","greeting")

wait(1)

avatar:start()

avatar:turn(90,1)

end

Abbildung 10.2: Beispielskript für eine Szenario-Animation

10.1.4 Ergebnis

Ein Prototyp der Simulationsplattform konnte erfolgreich realisiert werden. Dabei warbei der Realisierung hilfreich, dass sowohl die Darstellung der Avatare, als auch die derFabriksimulation mit OpenSceneGraph durchgeführt werden. Durch die Verwendungvon Kon�gurations- und Steuerungsdateien im ASCII-Text kann das System auÿerdemmit wenig technischem Aufwand an neue Szenarien und Inhalte angepasst werden.

Das entwickelte System ist o�en für neue Modellinhalte. So wäre es beispielsweisemöglich, reale Arbeitssequenzen mit Hilfe von MOCAP aufzuzeichnen und dann mitHilfe der Avatare innerhalb der Lernumgebung wiederzugeben. Hierdurch könnte dasArbeitsumfeld noch realistischer wiedergegeben werden.

10.2 Visualisierung von Simulationsergebnissen

10.2.1 Projektziel

Die Skript-Knoten haben sich nicht nur bei der Umsetzung der Tutorials bewährt, son-dern konnten auch zur Visualisierung von Simulationsergebnissen eingesetzt werden.Bei diesem internen Projekt mit dem Fachbereich Maschinenbau sollten Simulations-ergebnisse, die in Form von DOSIMIS-3 Trace-Dateien [70] vorliegen, dreidimensionalanimiert dargestellt werden. Hierbei sollten Avatare dazu verwendet werden, um dieAktivitäten an den Bearbeitungsplätzen zu visualisieren.

DOSIMIS-3 Trace-Dateien (siehe Beispiel in Abbildung 10.3) enthalten in jeder Zeileein Ereignis, welches durch ein Kürzel angegeben wird. Das Kürzel �B+� steht beispiels-weise für die Aufnahme von einem Bearbeitungsstück, das Kürzel �AB� für den Beginneiner Bearbeitung. Des Weiteren werden zu jedem Ereignis der Zeitpunkt und eine


B+ 0.0 1 +1 1 1

OW 0.0 1 1 1

B- 0.0 1 -1 1 1

B+ 0.0 3 +1 1 1

BI 2.0 3 1

OW 6.0 3 1 1

B- 6.0 3 -1 1 1

B+ 6.0 7 +1 1 1

BI 6.0 7 3

AB 6.0 7 1 1

B+ 22.4 1 +1 2 1

OW 22.4 1 1 2

B- 22.4 1 -1 2 1

B+ 22.4 3 +1 2 1

Abbildung 10.3: Beispiel für eine Trace-Datei

Identi�zierungsnummer der betro�enen Maschine angegeben. Die Aufgabe der Visua-lisierung besteht darin, die Inhalte der Trace-Datei in eine animierte, dreidimensionaleGra�k umzuwandeln.

10.2.2 Konzept

Da eine Trace-Datei nur Ereignisse enthält, muss das 3D Modell gesondert erstelltwerden. Hierzu wurde 3D Studio Max verwendet. Die Visualisierung der Ereignisse wirddurch ein Lua-Skript realisiert, wobei sich das Skript um die Animation beweglicherGegenstände (Bearbeitungsstücke, Transportwagen) und die Steuerung der Avatarekümmert.

Das in Abschnitt 7.3 vorgestellte Idiom zur Erstellung von Lua-Klassen wurde dazuverwendet, jeden Maschinentyp durch eine eigene Lua-Klasse abzubilden. Jede Klassekann auf bestimmte Ereignisse reagieren und selbstständig die notwendigen Anima-tionen durchführen. Ereignisse werden durch eine Steuerungs-Klasse verwaltet, die dieEreignisse zum richtigen Zeitpunkt an die Maschinen-Klassen durchreicht.

10.2.3 Realisierung

Insgesamt wurden sieben Lua-Klassen implementiert, wobei vier Klassen die verwen-deten Maschinen abbilden (siehe Abbildung 10.4). Die Klassen Event und Schedulerverwalten die DOSIMIS-3 Ereignisse. Die Event-Klasse wird zur Repräsentation vonEreignissen verwendet und entspricht den Einträgen in der Trace-Datei. Hierbei wer-den nicht alle Einträge der Trace-Datei unterstützt, sondern nur diejenigen, die sich aufdie visuelle Darstellung auswirken. Die Scheduler-Klasse verwaltet diese Ereignisse undliefert sie zum richtigen Zeitpunkt an die Ereignisbehandlungsroutinen der Maschinen.

Die Device-Klasse ist die Basis-Klasse für alle Maschinen und Einheiten. Jede Ma-schine kann eine Liste von Bearbeitungsstücken verwalten, wobei immer das erste im


FifoScheduler

DistDevice WorkDeviceLineDevice

DeviceEvent1 * * 1

Avatar

Abbildung 10.4: Klassendiagramm der Lua-Klassen für die Visualisierung

Bearbeitungszustand ist. Das jeweils aktuelle Bearbeitungsstück kann in einer vorge-gebenen Zeit zwischen zwei Punkten bewegt werden. Hierzu verarbeitet die Klassedie zwei Ereignisse zur Aufnahme und Abgabe von Bearbeitungsstücken. Jedes Devicekennt das unmittelbar nachfolgende Device und kann Bearbeitungsstücke automatischweitergeben.

Das LineDevice ist eine Spezialisierung der Device-Klasse und repräsentiert ein Flieÿ-band. Es erweitert die visuelle Darstellung um wartende Bearbeitungsstücke, d.h. einBearbeitungsstück wird nur so lange bewegt, wie der Weg �frei� ist.

Die DistDevice-Klasse simuliert Verteilwagen. Daher wird das Bearbeitungsstück mitdem Modell des Verteilwagens bewegt. Sie kann auÿerdem das Bearbeitungsstück anmehrere Maschinen weitergeben. Hierzu kann die Klasse ein zusätzliches Positionser-eignis verarbeiten, welches das nächste Ziel des Verteilwagens festlegt.

Bearbeitungsstationen werden durch die WorkDevice-Klasse dargestellt. Sie kann dasAussehen eines Bearbeitungsstücks nach dem Bearbeitungsende ändern. Dazu bearbei-tet die Klasse das zusätzliche Ereignis �Bearbeitungsende�. Zusätzlich wird der Arbeiter- dargestellt durch einen Avatar - in Abhängigkeit von den ankommenden Ereignissengesteuert.

Abhängig von den Ereignissen wird eine passende Bewegung aus der O�ine-Datenbankdes Avatars aktiviert. Hierzu werden zwei zyklische Animationen bereitgestellt, die dieZustände �wartend� und �in Bearbeitung� repräsentieren. Zusätzlich existieren zweiTransitionen, die für Zustandsübergänge verwendet werden können.

Da eine Trace-Datei keinerlei Hinweise über den Aufbau der Anlage liefert, muss zujeder Anlage noch ein Skript geschrieben werden, welches die gewünschten Einheitenerzeugt und miteinander verbindet. Anschlieÿend kann eine Trace-Datei eingeladen undvisualisiert werden.

10.2.4 Ergebnis

In Abbildung 10.5 sind zwei Schritte aus einer Visualisierung zu sehen. Es hat sich hier-bei gezeigt, dass die Skript-Knoten auch komplexere Steuerungsaufgaben übernehmenkönnen. Bewährt hat sich auch, dass für die Avatare keine spezialisierte Skriptspracheentwickelt wurde, sondern stattdessen eine universelle Bindung erzeugt wurde. Nur so


konnten neben den Avataren auch die übrigen Objekte der Visualisierung gesteuert wer-den. Durch das o�ene Konzept können auÿerdem bei Bedarf auch weitere Maschinenhinzugefügt werden.


Abbildung 10.5: Visualisierung von Material�üssen mit dem Skript-Knoten

Kapitel 11

Zusammenfassung und Ausblick

11.1 Zusammenfassung der Ergebnisse

Im Rahmen der Arbeit wurde ein System entwickelt, mit dem animierbare und spre-chende Avatare in Echtzeit 3D Simulationen eingebunden werden können. Generell sindsolche Systeme nicht neu. Das Kapitel �Stand der Technik� hat gezeigt, dass im Be-reich echtzeitanimierbarer Avatare umfangreiche Forschungen unternommen wurden.Ein groÿes Problem ist jedoch, dass es keine einheitlichen Schnittstellen gibt. Hier-durch sind viele Insellösungen entstanden, die zwar bestimmte Teilprobleme sehr gutlösen, sich aber schlecht zu einer Gesamtlösung kombinieren lassen [148]. Auÿerdemsind solche Lösungen nur selten in konkreten Implementierungen verfügbar, so dass siefür den praktischen Einsatz neu implementiert werden müssen.

Die grundlegende Idee der vorliegenden Arbeit ist, so weit wie möglich vorhandeneKomponenten zu einem Gesamtsystem zu kombinieren. Hierzu wurden Konzepte undLösungen erarbeitet, die diese Kombination ermöglichen. Zwei groÿe Problembereichekonnten identi�ziert werden. Bei dem ersten Problembereich handelt es sich um dieModellierung und Animation der Avatare mit existierenden Programmen. Damit dieseProgramme eingesetzt werden können, werden Richtlinien benötigt, die eine erfolgreicheKombination der Programme zulassen. Da das aktuell verfügbare Wissen hierzu wenigeinheitlich strukturiert und weit verstreut ist, wurde im Rahmen dieser Arbeit eineDokumentation von Arbeitsabläufen entwickelt, die auf der BPMN aufbaut. Hierdurchkann das Wissen zur Erstellung und Animation von Avataren geordnet und leichterzugänglich gemacht werden. Anhand der Beispiele Poser, 3D Studio Max und Motion-Builder wurden auÿerdem konkrete Arbeitsabläufe zur Modellierung und Animationentwickelt.

Der zweite Problembereich ist die Echtzeit-Darstellung in einer virtuellen Umgebung.Im Rahmen der Arbeit wurde dazu ein Laufzeitsystem entwickelt, das soweit wie mög-lich vorhandene Komponenten wie Cal3D, OpenSceneGraph, Lua und SYZYGY zu ei-nem Gesamtsystem kombiniert und nötigenfalls ergänzt. Zu den Ergänzungen gehörendie Steuerung der Avatare durch Skript-Knoten, die Realisierung der Sprachanimationund die Darstellung in einer Multiprojektionsumgebung.

Als universelle Steuerungsmöglichkeit wurden Skript-Knoten in OpenSceneGraph in-tegriert. Auf diese Weise können nicht nur die Avatare, sondern auch andere Objekteder Simulation gesteuert werden. Zusätzlich wurden Strategien in Form von Idiomen

169

170 KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK

entworfen, mit denen sich Steuerungsaufgaben von Avataren lösen lassen. Diese Steue-rungsmöglichkeit hat sich - zusammen mit dem Avatar-System - schon in mehrerenAnwendungen bewährt.

Die Animation der Avatare wurde mit Hilfe von Cal3D realisiert. Durch den verfüg-baren Quelltext und das o�engelegte Dateiformat kann es teilweise das Problem derSchnittstellen lösen, da es einfach als Basis für die Character-Animation in eigene Pro-jekte integriert werden kann. Die Bibliothek unterstützt jedoch keine Sprachanimation.Daher wurde ein modulares Sprachsystem auf Basis von Morph-Animationen entwor-fen, das sich �exibel erweitern lässt. Auf diese Weise können Avatare zur Laufzeit miteinem Text-to-Speech System Sprachausgabe erzeugen.

Da es das erklärte Ziel war, die Avatare auch in der CasCave einsetzen zu können,musste auch eine Kopplung zwischen dem Darstellungssystem OpenSceneGraph unddem in der CasCave verwendeten VR-System SYZYGY gescha�en werden. Hierfür gabes keine bestehenden Lösungen, weshalb eine neue entwickelt werden musste.

Auÿerdem musste eine Brücke zwischen der Erstellung der Inhalte einerseits und demLaufzeitsystem andererseits gescha�en werden. Hierzu wurde im Rahmen der Arbeitder de Facto Standard FBX in die Arbeitsabläufe integriert, wodurch sich neue undnoch �exiblere Möglichkeiten zur Erstellung und Animation von Cal3D-Avataren erge-ben. Durch die Entwicklung einer gra�schen Ober�äche zur Kon�guration, sowie durchdie Möglichkeit einer leichten Umwandlung von statischer in animierbare Geometriewerden die Modellierungsabläufe zusätzlich optimiert.

Insgesamt konnte ein System entwickelt werden, welches die gesamte Bandbreite vonder Modellerstellung bis zur Darstellung in der CasCave abdecken kann. Auf diese Weisekonnte auch der Nachweis erbracht werden, dass sich die vielen vorhandene Teillösun-gen im Bereich des Einsatzes von Avataren zu einem funktionierenden Gesamtsystemzusammenfügen lassen.

11.2 Ausblick

Ein groÿe Herausforderung bei der Realisierung des Avatar-Systems war, dass ein groÿerProblembereich abgedeckt werden musste. Hierdurch konnten Detaillösungen aus Zeit-gründen nicht umgesetzt werden. Das entstandene System kann aber als Ausgangsbasisfür zukünftige Erweiterungen dienen.

Beginnend bei der Modellierung könnte der Übertragungs-Algorithmus aus Abschnitt6.3 verfeinert werden, indem er die Skinning-Informationen auch bei gröÿeren Abwei-chungen von Quelle und Ziel zuverlässig übertragen kann. Dies könnte auch zu einemautomatischen Skinning ausgebaut werden, so dass nur noch eine statische Geome-trie vorgegeben werden muss, für die automatisch ein Skelett mit passenden Skinning-Informationen erzeugt wird.

Auch die vorhandenen Modell- und Animationsbibliotheken könnten um zusätzlicheInhalte ergänzt werden, wodurch das System schneller in unterschiedlichen Anwen-dungsbereichen eingesetzt werden könnte. Dabei könnten die Modellierungs- und Ani-mationsabläufe beschleunigt werden, wenn eine (Teil-) Automatisierung der in denKapiteln 4 und 5 vorgestellten Arbeitsabläufe möglich wäre. Hierzu müsste untersucht

KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK 171

werden, ob und ggf. wie die beteiligten Anwendungen von einer externen Software ge-steuert werden könnten. Diese könnte dann mit Hilfe von BPMN-Diagrammen eineAutomatisierung vornehmen.

Zur Steuerung der Animation bietet das System Basis-Funktionen, die durch Lua-Skripte zu komplexeren Steuerungsstrategien erweitert werden können. Eine Integra-tion von fortgeschrittenen Steuerungskonzepten in das Avatar-System könnte die Ani-mation jedoch erleichtern - insbesondere wenn kein Skripting zur Verfügung steht.Hierzu gehören erweiterte Möglichkeiten, Animationssequenzen aufzubauen. Insbeson-dere könnte der Einsatz der Avatare vereinfacht werden, wenn Transitionen zwischenAnimationen automatisch generiert würden oder Animationen zielgerichtet aus einerDatenbank ausgewählt werden könnten, wie es in aktuellen Arbeiten wie [115, 164, 181]realisiert wird.

Auch die Online-Sprachanimation könnte erweitert und um emotionale Fähigkeiten er-gänzt werden. Mit EmoSpeak [40] existiert eine Erweiterung für Mary-TTS, die dieSynthetisierung von Sprache mit emotionalen Ein�üssen ermöglicht. Dies könnte miteinem erweiterten Animationssystem kombiniert werden, wodurch die Avatare auf ein-fache Weise Emotionen durch Sprache und Mimik wiedergeben könnten.

Das Avatar-System ignoriert zur Zeit völlig physikalische Gesetzmäÿigkeiten. Die Im-plementierung solcher Gesetzmäÿigkeiten könnte jedoch für verschiedene Bereiche einesinnvolle Ergänzung sein. Haare und Kleidung könnten beispielsweise durch eine phy-sikalische Simulation realistischer animiert werden. Auch die Interaktion mit anderenGegenständen der Simulation würde hierdurch erleichtert werden. Durch eine physika-lische Simulation wäre ein Avatar in der Lage, Gegenstände in die Hand zu nehmenund Manipulationen an seiner Umgebung durchzuführen, ohne jede Veränderung durchProgrammierung in einem Skript festlegen zu müssen.

In Kombination mit einer Spracherkennung und KI-Technologien könnte das Avatar-System auÿerdem zu einem intelligenten Dialogsystem ausgebaut werden. Dieses könnteinnerhalb von virtuellen Umgebungen als Schnittstelle dienen, wodurch man dem inder Einleitung erwähnten Metaverse einen Schritt näher wäre.

172 KAPITEL 11. ZUSAMMENFASSUNG UND AUSBLICK

Anhang A

Glossar und Abkürzungsverzeichnis

Actor siehe Akteur

Akteur in dieser Arbeit ein von einem Computer gesteuerter Avatar

API Application Programming Interface;Programmierschnittstelle zur Anwendungsentwicklung

ASCII American Standard Code for Information Interchange;Standard für die Kodierung von Zeichen im Computer

AU Action Unit;im FACS die Bezeichnung für sichtbare Muskelbewegungen

Avatar in dieser Arbeit ein animierbares, dreidimensionales Modell einesMenschen

BMBF Bundesministerium für Bildung und Forschung

BMP (Windows)-Bitmap;Dateiformat zur Speicherung von Bildern

Bone siehe Gelenk

BPEL Business Process Execution Language;Sprache zur Automation von Geschäftsabläufen

BPMN Business Process Modeling Notation;Notation zur Modellierung von Geschäftsabläufen

BSD-Lizenz Berkeley Software Distribution Lizenz;OpenSource Softwarelizenz [32]

BVH Biovision Hierarchy;Dateiformat für skelettbasierte Bewegungsdaten

CAD Computer Aided Designcomputerunterstütztes Design

173

174 ANHANG A. GLOSSAR UND ABKÜRZUNGSVERZEICHNIS

CML Character Markup Language;Auszeichnungssprache zur Animation von Avataren [224]

COLLADA COLLAborative Design Activity;�rmenübergreifender Standard zum Austausch von 3D Modellda-ten [44]

Constraint beschreibt in dieser Arbeit eine Einschränkung oder Vorgabe, dievon einer Lösung eines (Animations-) Problems erfüllt werdenmuss.

Cyberspace Kunstwort aus �Cyber� (Cybernetic) und �Space�;bezeichnet einen virtualisierten Raumeindruck, der keine topogra-�sche Lokalität aufweist [104].

DFKI Deutsches Forschungszentrum für Künstliche Intelligenz

Diphon beschreibt in der Sprachsynthese den kurzen Abschnitt (Baustein)gesprochener Sprache, der in der Mitte eines Phons beginnt und inder Mitte des folgenden Phons endet [95].

DirectX API zur Entwicklung von Multimedia-Anwendungen unter Micro-soft Windows

EchtzeitSimulation

eine Simulation, deren zeitliche Abläufe denen der �realen Welt�entsprechen

Eckpunkt in dieser Arbeit ein Punkt im dreidimensionalen Raum, der dieGeometrie eines Modells aufspannt

EFFD Extended Freeform Deformation;Die �Erweiterte Freiform Deformation� ist eine Technik zur Verfor-mung von dreidimensionalen Modellen.

ESPRIT Forschungsförderungsprogramm der Europäischen Union zurFörderung der Informationstechnologie

Face siehe Polygon

FACS Facial Action Coding System;bezeichnet ein Kodierungssystem, um Gesichtsausdrücke kategori-sieren zu können [42].

FAP Facial Animation Parameters;Ein FAP kodiert jede Aktion, die ein Gesichtsmodell in einemneutralen Zustand verändert.

FBX FilmBox Format;Dateiformat zur Speicherung von Modellen und Animationen

FFD Freeform Deformation (Freiform Deformation);Die �Freiform Deformation� ist eine Technik zur Verformung vondreidimensionalen Modellen.

ANHANG A. GLOSSAR UND ABKÜRZUNGSVERZEICHNIS 175

FK Forward Kinematic;In einer kinematischen Kette werden bei der Vorwärtskinematikder Reihe nach alle Gelenkparameter de�niert und spezi�zieren sodie Position des Endes der Kette (End-E�ektor).

Gelenk in dieser Arbeit ein Teil eines Skeletts, der rotiert oder verschobenwerden kann

Geometrie in dieser Arbeit die Bezeichnung für die Geometriedaten (z.B.Eckpunkte und Polygonlisten) eines dreidimensionalen Modells

GIF Graphics Interchange Format;Dateiformat zur Speicherung von Bildern

GPL GNU General Public LicenseOpenSource Softwarelizenz [33]

HMM Hidden Markov Model;siehe VMM

ICS Interactive Content System;ein System zur Erstellung von interaktiven, dreidimensionalenInhalten

IK Inverse Kinematic;In einer kinematische Kette wird bei der inversen Kinematik diePosition des End-E�ektors festgelegt und die dazu passendenParameter der Kette berechnet.

Immersion das Eintauchen bzw. der Grad des Eintauchens in eine Szene dervirtuellen Realität

ITS Intelligent Tutor System;ein intelligentes System, das Anwender bei Lehr- und Übungsan-wendungen unterstützt

JPG Joint Photographic Experts Group;Dateiformat zur Speicherung von Bildern

KI Künstliche Intelligenz;Teilgebiet der Informatik, welches das Ziel verfolgt, Maschinen mitintelligentem Verhalten zu entwickeln

Koartikulation bezeichnet die Beein�ussung eines Lautes durch seinen lautlichenKontext.

LGPL Lesser/Library GNU General Public License;OpenSource Softwarelizenz [34]

Metaball eine spezielle implizite Fläche, die bei Avataren häu�g zur Model-lierung von Muskeln verwendet wird [99]


Mesh siehe Geometrie

MIT-Lizenz Massachusetts Institute of Technology-Lizenz;OpenSource Softwarelizenz [35]

MMORG Massively Multiplayer Online Role-Playing Game;bezeichnet ein Rollenspiel mit vielen über Netzwerk verbundenenTeilnehmern.

MOCAP Motion Capture;Bewegungsaufzeichnung

Morphing bezeichnet die Berechnung von Sequenzen zwischen zwei Bildern,Modellen oder Klängen.

MPEG Moving Picture Experts Group;Organisation zur Festlegung von Standards für Multimedia-Wiedergabe

MPML Multimodal Presentation Markup Language;Auszeichnungssprache zur Animation von Avataren [210]

NPC Non Playable Character;bezeichnet eine computergesteuerte Spiel�gur.

NURBS Non-Uniform Rational B-Splines;Nicht-uniforme rationale B-Splines sind spezielle parametrischeFlächen, die zur Modellierung von Avatar-Modellen eingesetztwerden können.

NVE Networked Virtual Environments;Bezeichnung für über Netzwerke verbundene virtuelle Umgebungen

OBJ Wavefront Object;Dateiformat zur Speicherung von Modellen

OMG Object Management Group;bezeichnet ein internationales Konsortium, das Standards für dieobjektorientierte Programmierung entwickelt.

OpenAL plattformübergreifendes API zur Entwicklung von 3D Audio-Ausgabe [62]

OpenGL plattformübergreifendes API zur Entwicklung von 2D und 3DGra�k-Ausgabe [63]

OpenSource bezeichnet im weitesten Sinne Software, deren Quelltext zurVerfügung gestellt wird. Meistens schlieÿt dies auch das Recht ein,diesen Quelltext zu verändern und weiterzugeben.

ANHANG A. GLOSSAR UND ABKÜRZUNGSVERZEICHNIS 177

PCA Principal Component Analysis;Die Hauptkomponentenanalyse ist ein statistisches Verfahren zurAnalyse multivarianter Daten.

Phonem bezeichnet die kleinsten bedeutungsunterscheidenden, aber nichtbedeutungstragenden Einheiten einer Sprache.

Pixel Kunstwort aus �Picture� und �Element�;bezeichnet einen Bildpunkt in einem zweidimensionalen Bild.

PNG Portable Network Graphics;Dateiformat zur Speicherung von Bildern

Polygon in dieser Arbeit die Verbindung mehrerer Eckpunkte zu einer Fläche

RGB bezeichnet die Abkürzung für die Farbkanäle Rot, Grün, Blau.

rendern bezeichnet den Prozess, ein zweidimensionales Bild aus einem 3DModell zu berechnen.

Retargetting bezeichnet die Übertragung von Bewegungsdaten auf ein Skelett,welches abweichende Proportionen hat.

RMS Radfahren mit Multimedia Software

SAM Speech Assessment Methods;Esprit Projekt der Europäischen Union

SAMPA Speech Assessment Methods Phonetic Alphabet;Kurzbezeichnung für ein ASCII-basiertes phonetisches Alphabet[105]

Scheme Programmiersprache

SDD Skeleton Driven Deformation;eine Technik zur Verformung von dreidimensionalen Modellenunter Verwendung eines Skeletts

SDK Software Development Kit;bezeichnet eine Sammlung von Programmen und Dokumentationenzur Softwareentwicklung.

Skinning bezeichnet die Bindung eines Modells an ein Skelett um das Modellanimierbar zu machen. Hierbei werden Eckpunkte des Modellsmit unterschiedlichen Gewichten an die Gelenke eines Skelettsgebunden.

Sprachsynthese bezeichnet die Synthetisierung von Sprache durch einen Computer.

SSD Skeleton Subspace Deformation;eine Technik zur Verformung von dreidimensionalen Modellenunter Verwendung eines Skeletts


SYZYGY von Syzygyum (eine bestimmte Stellung der Gestirne);u.a. Name für eine VR-Software [75]

Textur in dieser Arbeit die Bezeichnung für ein Bild, welches auf dieOber�äche eines 3D Modells gezogen wird

TTS Text to Speech;Synthetisierung von Sprache durch Vorgabe des zu sprechendenTextes

TVML Television Modeling Language;Auszeichnungssprache zur Animation von Avataren [152]

UML Uni�ed Modeling Language;eine von der Object Management Group (OMG) entwickelte undstandardisierte Sprache zur Modellierung von Software

Vertex siehe Eckpunkt

VHML Virtual Human Modeling Language;Auszeichnungssprache zur Animation von Avataren [150]

Visem bezeichnet visuelle Entsprechungen von Phonemen.

VM Virtuelle Maschine;virtuelle Laufzeitumgebung für Programme

VMM Verstecktes Markow Modell;ein stochastisches Modell, das zur Muster- und Spracherkennungeingesetzt werden kann

Voxel Kunstwort aus �Volumetric� und �Pixel�;bezeichnet das dreidimensionale Äquivalent eines Pixels.

VR Virtual Reality;Als Virtuelle Realität (VR) werden die Darstellung und gleich-zeitige Wahrnehmung der Wirklichkeit und ihrer physikalischenEigenschaften in einer in Echtzeit computergenerierten, interakti-ven, virtuellen Umgebung bezeichnet [113].

VRML Virtual Reality Modeling Language;Dateiformat zur Speicherung von 3D Szenen

XML Extensible Markup Language;bezeichnet einen Standard zur Modellierung von halb-strukturierten Daten in Form einer Baumstruktur [103].

Literaturverzeichnis

[1] ACT3D - Informationen zu Quest3D. http://www.quest3d.com, Abruf:06.10.2006

[2] Ascension - Magnetisches MOCAP. http://www.ascension-tech.com/

products/motionstarwireless.php, Abruf: 06.11.2006

[3] ATI - Programm zur Berechnung von Dot3 Bump-Maps. http://ati.

amd.com/developer/sdk/radeonSDK/html/Tools/ToolsPlugIns.html, Abruf:10.12.2006

[4] Autodesk - Informationen zu 3D Studio Max. http://www.autodesk.com/

3dsmax, Abruf: 24.11.2006

[5] Autodesk - Informationen zu Maya. http://www.autodesk.com/maya, Abruf:06.10.2006

[6] Autodesk - Informationen zu MotionBuilder. http://www.autodesk.com/

motionbuilder, Abruf: 24.11.2006

[7] Autodesk - Informationen zum FBX SDK. http://usa.autodesk.com/adsk/

servlet/index?siteID\=123112\&id\=6839916, Abruf: 06.10.2006

[8] Blaxxun - Blaxxun Contact. http://www.blaxxun.com/home/index.

php?option\=com\_content\&task\=view\&id\=42\&Itemid\=85, Abruf:06.10.2006

[9] Blender - Informationen zu Blender. http://www.blender.org, Abruf:06.10.2006

[10] Blizzard Entertainment - World of Warcraft. http://www.wow-europe.com, Ab-ruf: 12.12.2006

[11] Boston Dynamics - DI-Guy Motion Editor. http://www.bostondynamics.com/content/sec.php?section\=diguy\_motion, Abruf: 24.11.2006

[12] Boston Dynamics - Informationen zu DI-Guy. http://www.bostondynamics.

com/content/sec.php?section\=diguy, Abruf: 06.10.2006

[13] BPMN - OMG Final Adopted Speci�cation. http://www.bpmn.org/Documents/OMGFinalAdoptedBPMN1-0Spec06-02-01.pdf, Abruf: 28.11.2006

[14] Cal3D - eine freie Charakter-Animations Bibliothek. https://gna.org/

projects/cal3d, Abruf: 24.11.2006

179

180 LITERATURVERZEICHNIS

[15] Catia - Informationen zu Catia Human Builder. http://www.3ds.com, Abruf:06.10.2006

[16] Charamel - Informationen zu CharActor. http://www.charamel.de, Abruf:06.10.2006

[17] Cyberware - Informationen zu Ganzkörperscannern. http://www.cyberware.

com/products/scanners/wb4.html, Abruf: 06.10.2006

[18] Daz3D - Informationen zu Carrara. http://www.daz3d.com, Abruf: 24.11.2006

[19] Daz3D - Informationen zu DAZ Studio. http://www.daz3d.com/program/

studio/1\_0index.php, Abruf: 06.10.2006

[20] Dedalo - Informationen zu MakeHuman. http://www.dedalo-3d.com, Abruf:06.10.2006

[21] Delta 3D - Informationen zur Delta 3D Simulationsumgebung. http://www.

delta3d.org, Abruf: 24.11.2006

[22] DnS Development - Informationen zum Sarge SDK. http://www.sarge-sdk.

com, Abruf: 24.11.2006

[23] e-frontier - Informationen zu Poser. http://www.e-frontier.com/article/

articleview/1383/1/580?sbss\=580, Abruf: 06.10.2006

[24] Eidos - Tomb Raider Legend. http://www.tombraider.de/trl, Abruf:12.12.2006

[25] Electronic Arts - Die Sims 2. http://www.electronic-arts.de/publish/ea\_spiele/spiele\_info.html?etitel\=Die+Sims+2, Abruf: 12.12.2006

[26] Electronic Arts - FIFA 2006. http://www.electronic-arts.de/publish/

sportspiele/spiele\_info.html?etitel\=FIFA+06, Abruf: 12.12.2006

[27] Exodus - Avatar Conference. http://www.exodus.gr/Avatar\_Conference,Abruf: 06.10.2006

[28] Fastscan - Informationen zu 3D Scannern. http://www.fastscan3d.com, Abruf:06.10.2006

[29] Festival TTS. http://www.cstr.ed.ac.uk/projects/festival, Abruf:24.11.2006

[30] FileFormat.info - Informationen zum 3DS Dateiformat. http://www.

fileformat.info/format/3ds, Abruf: 24.11.2006

[31] FileFormat.info - Informationen zum OBJ Dateiformat. http://www.

fileformat.info/format/wavefrontobj, Abruf: 24.11.2006

[32] Free Software Foundation - Informationen zur BSD Lizenz. http://www.

opensource.org/licenses/bsd-license.php, Abruf: 24.11.2006

[33] Free Software Foundation - Informationen zur GPL. http://www.fsf.org/

licensing/licenses/gpl.html, Abruf: 24.11.2006

LITERATURVERZEICHNIS 181

[34] Free Software Foundation - Informationen zur LGPL. http://www.fsf.org/

licensing/licenses/lgpl.html, Abruf: 24.11.2006

[35] Free Software Foundation - Informationen zur MIT Lizenz. http://www.

opensource.org/licenses/mit-license.php, Abruf: 24.11.2006

[36] Gimp - Plugin zur Berechnung von Dot3 Bump-Maps. http://nifelheim.

dyndns.org/~cocidius/normalmap, Abruf: 10.12.2006

[37] H-Anim Arbeitsgruppe - Informationen zum H-Anim Standard. http://www.

h-anim.org, Abruf: 24.11.2006

[38] Human Solutions - Informationen zu RAMSIS. http://www.human-solutions.com/automotive\_industry/ramsis\_de.php, Abruf: 06.10.2006

[39] Informationen zu Digital Manikin. http://www.dh.aist.go.jp/research/

centered/digitalmanikin/index.php.en, Abruf: 04.10.2006

[40] Informationen zu EmoSpeak. http://cling.dfki.uni-sb.de/emospeak, Abruf:12.12.2006

[41] Informationen zu tolua++. http://www.codenix.com/~tolua, Abruf:10.12.2006

[42] Informationen zum FACS. http://face-and-emotion.com/dataface/facs/

description.jsp, Abruf: 02.11.2006

[43] Informationen zur Business Process Modeling Notation. http://www.bpmn.org,Abruf: 28.11.2006

[44] Khronos - Informationen zu COLLADA. http://www.khronos.org/collada,Abruf: 24.11.2006

[45] Khronos Group. http://www.khronos.org, Abruf: 24.11.2006

[46] Lua Benchmarks. http://dada.perl.it/shootout, Abruf: 24.11.2006

[47] Lua Benchmarks. http://shootout.alioth.debian.org, Abruf: 24.11.2006

[48] Lua Skriptsprache. http://www.lua.org, Abruf: 24.11.2006

[49] Mary TTS. http://mary.dfki.de, Abruf: 24.11.2006

[50] Maxon - Informationen zu Cinema 4D. http://www.maxon.net/pages/

products/cinema4d/cinema4d\_d.html, Abruf: 24.11.2006

[51] MBROLA Sprachsynthesizer. http://tcts.fpms.ac.be/synthesis/mbrola.

html, Abruf: 24.11.2006

[52] McGurk E�ekt. http://www.media.uio.no/personer/arntm/McGurk\

_english.html, Abruf: 24.11.2006

[53] MetaMotion - Mechanisches MOCAP. http://www.metamotion.com, Abruf:06.11.2006


[54] Microsoft - Informationen zu DirectX. http://www.microsoft.com/directx,Abruf: 24.11.2006

[55] Mystic Game Development - Informationen zu EmotionFX. http://www.

emotionfx.com, Abruf: 24.11.2006

[56] Natural Motion - Informationen zu Endorphin. http://www.naturalmotion.

com/endorphin.htm, Abruf: 24.11.2006

[57] NetJuggler - VR System. http://netjuggler.sourceforge.net, Abruf:24.11.2006

[58] NewTek - Informationen zu Lightwave 3D. http://www.lightwave3d.com, Ab-ruf: 24.11.2006

[59] nVidia - Plugin zur Berechnung von Dot3 Bump-Maps. http://developer.

nvidia.com/object/photoshop\_dds\_plugins.html, Abruf: 10.12.2006

[60] nVidia - Programm zur Berechnung von Dot3 Bump-Maps. http://developer.nvidia.com/object/melody\_home.html, Abruf: 10.12.2006

[61] The online 3d model library. http://www.3d02.com, Abruf: 24.11.2006

[62] OpenAL.org - Informationen zu OpenAL. http://www.openal.org, Abruf:24.11.2006

[63] OpenGL.org - Informationen zu OpenGL. http://www.opengl.org, Abruf:24.11.2006

[64] OpenSceneGraph.org - Informationen zu OpenSceneGraph. http://www.

openscenegraph.org, Abruf: 24.11.2006

[65] osgCal - Ein Cal3D Plugin für OpenSceneGraph. http://cvs.gna.org/cvsweb/osgcal/?cvsroot\=underware, Abruf: 24.11.2006

[66] osgCal2 - Ein Cal3D Plugin für OpenSceneGraph. http://osgcal.

sourceforge.net, Abruf: 24.11.2006

[67] Python Skriptsprache. http://www.python.org, Abruf: 24.11.2006

[68] Rockebox Studios - Complete Characters. http://www.complete-characters.

com, Abruf: 24.11.2006

[69] Rockebox Studios - Complete Soldiers. http://www.complete-soldiers.com,Abruf: 24.11.2006

[70] SDT GmbH - Informationen zu DOSIMIS. http://www.sdz.de/inhalt/

produkte\_dosimis.html, Abruf: 12.12.2006

[71] Sensable - Informationen zu Claytools. http://www.sensable.com/

products-claytools-system.htm, Abruf: 22.10.2006

[72] Sensable - Informationen zu Phantom Omni. http://www.sensable.com/

haptic-phantom-omni.htm, Abruf: 22.10.2006


[73] SGI - Informationen zu Inventor. http://oss.sgi.com/projects/inventor,Abruf: 24.11.2006

[74] SGI - Informationen zu Performer. http://www.sgi.com/products/software/performer, Abruf: 24.11.2006

[75] SYZYGY - VR System. http://www.isl.uiuc.edu/syzygy.htm, Abruf:24.11.2006

[76] Technische Universität Braunschweig - 3D-Scanner für jedermann. http:

//www.cs.tu-bs.de/rob/forschung/auszeichnungen/dagm2006.htm, Abruf:23.10.2006

[77] Tixeo - Informationen zu Workspace 3D. http://www.tixeo.com, Abruf:06.10.2006

[78] Trolltech - Informationen zu Qt. http://www.trolltech.com/products/qt,Abruf: 24.11.2006

[79] TurboSquid. http://www.turbosquid.com, Abruf: 24.11.2006

[80] Übersicht von OpenSource Lizenzen. http://www.opensource.org/licenses,Abruf: 24.11.2006

[81] UGS Tecnomatix - Informationen zu Jack/Jill. http://www.ugs.com/

products/tecnomatix/human\_performance/jack, Abruf: 06.10.2006

[82] University of Iowa - Informationen zu Santos. http://www.digital-humans.

org, Abruf: 06.10.2006

[83] Unreal Technology - Informationen zur Unreal 3 Game-Engine. http://www.

unrealtechnology.com/html/homefold/home.shtml, Abruf: 24.11.2006

[84] Valve Software - Informationen zur Source Game-Engine. http://www.

valvesoftware.com, Abruf: 24.11.2006

[85] VICON - Optisches MOCAP. http://www.vicon.com, Abruf: 06.11.2006

[86] Vitronic - Informationen zu Vitus Pro. http://www.vitus.de/english/vitus\_pro\_en.html, Abruf: 06.10.2006

[87] VR-Lab Umea University - Informationen zu osgAL. http://www.vrlab.umu.

se/research/osgAL, Abruf: 24.11.2006

[88] VR-Lab Umea University - Informationen zu Replicant Body. http://www.

vrlab.umu.se/research/replicantbody, Abruf: 24.11.2006

[89] VRSource - Vergleich OpenSG und OpenSceneGraph. http://opensg.

vrsource.org/trac/wiki/OSGComparison, Abruf: 24.11.2006

[90] Web3d.org - Informationen zu VRML. http://www.web3d.org/x3d/

specifications/\#vrml97, Abruf: 24.11.2006

[91] Wikipedia - Informationen zu 3D Studio Max. http://de.wikipedia.org/

wiki/3ds\_max, Abruf: 24.11.2006


[92] Wikipedia - Informationen zu Aktivitätsdiagrammen. http://de.wikipedia.

org/wiki/Aktivit{\"a}tsdiagramm, Abruf: 28.11.2006

[93] Wikipedia - Informationen zu Blender. http://de.wikipedia.org/wiki/

Blender\_(Software), Abruf: 24.11.2006

[94] Wikipedia - Informationen zu COLLADA. http://en.wikipedia.org/wiki/

COLLADA, Abruf: 24.11.2006

[95] Wikipedia - Informationen zu Diphonen. http://de.wikipedia.org/wiki/

Diphon, Abruf: 12.12.2006

[96] Wikipedia - Informationen zu Flussdiagrammen. http://de.wikipedia.org/

wiki/Programmablaufplan, Abruf: 28.11.2006

[97] Wikipedia - Informationen zu Lightwave 3D. http://en.wikipedia.org/wiki/Lightwave, Abruf: 24.11.2006

[98] Wikipedia - Informationen zu Lua. http://de.wikipedia.org/wiki/Lua, Ab-ruf: 24.11.2006

[99] Wikipedia - Informationen zu Metaballs. http://de.wikipedia.org/wiki/

Metaball, Abruf: 24.11.2006

[100] Wikipedia - Informationen zu Normal-Mapping. http://en.wikipedia.org/

wiki/Normal\_mapping, Abruf: 10.12.2006

[101] Wikipedia - Informationen zu Python. http://de.wikipedia.org/wiki/

Python\_(Programmiersprache), Abruf: 24.11.2006

[102] Wikipedia - Informationen zu VRML. http://de.wikipedia.org/wiki/Vrml,Abruf: 24.11.2006

[103] Wikipedia - Informationen zu XML. http://de.wikipedia.org/wiki/XML, Ab-ruf: 12.12.2006

[104] Wikipedia - Informationen zum CyberSpace. http://de.wikipedia.org/wiki/Cyberspace, Abruf: 12.12.2006

[105] Wikipedia - Informationen zum SAMPA. http://de.wikipedia.org/wiki/

SAMPA, Abruf: 12.12.2006

[106] Wikipedia - Informationen zur BSD Lizenz. http://de.wikipedia.org/wiki/

BSD-Lizenz, Abruf: 24.11.2006

[107] Wikipedia - Informationen zur Business Process Execution Language. http://

de.wikipedia.org/wiki/BPEL, Abruf: 12.12.2006

[108] Wikipedia - Informationen zur Gesichtsanimation. http://en.wikipedia.org/wiki/Facial\_animation, Abruf: 01.11.06

[109] Wikipedia - Informationen zur GPL. http://de.wikipedia.org/wiki/GPL, Ab-ruf: 24.11.2006


[110] Wikipedia - Informationen zur LGPL. http://www.fsf.org/licensing/

licenses/lgpl.html, Abruf: 24.11.2006

[111] Wikipedia - Informationen zur MIT Lizenz. http://de.wikipedia.org/wiki/

MIT-Lizenz, Abruf: 24.11.2006

[112] Wikipedia - Informationen zur Unreal Engine. http://de.wikipedia.org/

wiki/Unreal\_Engine, Abruf: 24.11.2006

[113] Wikipedia - Informationen zur Virtuellen Realität. http://de.wikipedia.org/wiki/Virtuelle\_Realit{\"a}t, Abruf: 12.12.2006

[114] WikiRaider - Informationen zu TombRaider Legend. http://www.wikiraider.de/index.php/Tomb\_Raider\_Legend, Abruf: 06.10.2006

[115] Abe, Y. ; Popovic, J.: Interactive Animation of Dynamic Manipulation. In:Proceedings of the ACM SIGGRAPH, 2006

[116] Agelfors, E. ; Beskow, J. ; Granström, B. ; Lundeberg, M. ; Sal-vi, G. ; Spens, K.-E.: Synthetic Visual Speech Driven From AuditorySpeech. http://citeseer.ist.psu.edu/314718.html;http://www.speech.

kth.se/~beskow/papers/avsp99teleface.pdf. Version: 1999

[117] Albrecht, I. ; Fischer, J. ; Kähler, K. ; Schröder, M. ; Seidel, H.-P.:May I talk to you? - Facial Animation from Text. In: Proceedings of the 10thPaci�c Conference on Computer Graphics and Applications (PG'02), 2002

[118] Albrecht, I. ; Haber, J. ; Seidel, H.-P.: Construction and Animation ofAnatomically Based Human Hand Models. In: Breen, D. (Hrsg.) ; Lin, M.(Hrsg.): Proceedings of the 2003 ACM SIGGRAPH/Eurographics Symposium onComputer Animation (SCA-03). Aire-la-Ville : Eurographics Association, Juli26�27 2003, S. 98�109

[119] Aschenberner, B. ; Weiss, C.: Phoneme-Viseme Mapping for German / In-stitut für Kommunikationsforschung und Phonetik, Universität Bonn. 2005. �Forschungsbericht

[120] Badler, N. I.: Virtual Humans for Animation, Ergonomics, andSimulation. In: Workshop on Motion of Non-Rigid and Articula-ted Objects (NAM) 00 (1997), S. 0028. http://dx.doi.org/http:

//doi.ieeecomputersociety.org/10.1109/NAMW.1997.609848. � DOIhttp://doi.ieeecomputersociety.org/10.1109/NAMW.1997.609848. ISBN 0�8186�8040�7

[121] Badler, N. I. ; Phillips, C. B. ;Webber, B. L.: Simulating Humans: ComputerGraphics Animation and Control. New York : Oxford University Press, 1993. �ISBN 0�19�507359�2

[122] Beskow, J.: Animation of Talking Agents. In Proc. AUSP, pp. 149-152, 1997

[123] Blanz, V. ; Vetter, T.: A morphable model for the synthesis of 3d faces. In:Proceedings of the ACM SIGGRAPH, 1999, S. 187�194


[124] Blinn ; James, F.: Simulation of Wrinkled Surfaces. In: Proceedings of the ACMSIGGRAPH, 1978 (3 12), S. 286�292

[125] Blinn ; James, F.: A Generalization of Algebraic Surface Drawing. In: Procee-dings of the ACM SIGGRAPH, 1982 (3 1), S. 235�256

[126] Boulic, R. ; Thalmann, D.: Combined Direct and Inverse Kinematic Controlfor Articulated Figures Motion Editing. In: Computer Graphics Forum, 1992,189�202

[127] Boulic, R. ; Thalmann, D.: Retargetting motion to new characters. In: Pro-ceedings of the ACM SIGGRAPH, 1998, 33�42

[128] Brand, M.: Voice Puppetry. In: Proceedings of the ACM SIGGRAPH, 1999,21�28

[129] Breton, G. ; Bouville, C. ; Pelé, D.: FaceEngine a 3D facial animation enginefor real time applications: a 3D facial animation engine for real time applications.In: Web3D, 2001, 15�22

[130] Byun, M. ; Badler, N. I.: Facemote - qualitative parametric modi�ers for facialanimations. In: Proceedings of the ACM SIGGRAPH, 2002, S. 65�71

[131] Capell, S. ; Burkhart, M. ; Curless, B. ; Duchamp, T. ; Popovic, Z.:Physically based rigging for deformable characters. In: Proceedings of the ACMSIGGRAPH, 2005, S. 301�310

[132] Cassell, J.: More than just another pretty face - embodied conversationalinterface agents. In: Proceedings of the ACM SIGGRAPH, 2000

[133] Cassell, J. ; Vilhjalmsson, H. H. ; Bickmore, T.: Beat - behavior expressionanimation toolkit. In: Proceedings of the ACM SIGGRAPH, 2001, S. 477�486

[134] Choi, K. ; Ko, H. S.: On-line Motion Retargetting. In: Proceedings of the 7thPaci�c Conference on Computer Graphics and Applications, 1999, S. 32�42

[135] Cohen, M. M. ; Massaro, D. W.: Modeling Coarticulation in Synthetic Vi-sual Speech. In: Thalmann, M. (Hrsg.) ; Thalmann, D. (Hrsg.): ComputerAnimation 1993, Springer-Verlag

[136] Collins, G. ; Hilton, A.: Models for character animation. In: Software Focus2 (2001), Nr. 2, S. 44�51

[137] Coquillart, S.: Extended free-form deformation. In: Proceedings of the ACMSIGGRAPH, 1990, S. 187�196

[138] Cosi, P. ; Cohen, M.M. ; Massaro, D.W.: Baldini: Baldi speaks Italian. In:Proceedings of 7th International Conference on Spoken Language Processing, S.2349�2352

[139] Ekman, P. ; Friesen, W. V.: Manual for the Facial Action Coding System.Consulting Psychologists Press., 1977


[140] Fagel, S. ; Clemens, C.: Two Articulation Models for Audiovisual SpeechSynthesis - Description and Determination. In: Proceedings of ISCA Tutorialand Research Workshop on Audio-Visual Speech Processing (AVSP), 2003, S.215�220

[141] Fetter, W.: A progression of human �gures simulated by computer graphics.4 (1982), Nr. 2, S. 9�13

[142] Forman: Avatar pedagogy. Version: 1999. http://technologysource.org/

article/avatar/pedagogy, Abruf: 06.10.2006

[143] Garau, M. ; Slater, M. ; Bee, S. ; Sasse ; Angela, M.: The Impact of EyeGaze on Communication using Humanoid Avatars. In: Proceedings of ACM CHI2001 Conference on Human Factors in Computing Systems, 2001 (Seeing andBeing Seen), S. 309�316

[144] Giang, T. ; Mooney, R. ; Peters, C. ; O'Sullivan, C.: Real time cha-racter animation techniques. Version: 2000. "http://citeseer.ist.psu.

edu/361543.html;ftp://ftp.cs.tcd.ie/pub/tech-reports/reports.00/

TCD-CS-2000-06.pdf". 2000. � Forschungsbericht

[145] Glardon, P. ; Boulic, R. ; Thalmann, D.: PCA-Based Walking Engine UsingMotion Capture Data. In: Computer Graphics International, IEEE ComputerSociety, 2004, S. 292�298

[146] Golovinskiy, A. ; Matusik, W. ; Pfister, H. ; Rusinkiewicz, S. ; Funk-houser, T.: A statistical model for synthesis of detailed facial geometry. In:Proceedings of the ACM SIGGRAPH, 2006, S. 1025�1034

[147] Granström, B. ; House, D.: Multimodality and speech technology: Verbal andnon-verbal communication in talking agents. In: Proceedings of EUROSPEECH2003, 2003, S. 2901�2904

[148] Gratch, J. ; Rickel, J. ; Andre, E. ; Cassell, J. ; Petajan, E. ; Badler,N. I.: Creating Interactive Virtual Humans: Some Assembly Required. In: IEEEIntelligent Systems 17 (2002), Nr. 4, S. 54�63

[149] Grünvogel, S.: Dynamic character animations. In: Int. J. Intell. Games& Simulation 2 (2003), Nr. 1, 11�19. http://www.scit.wlv.ac.uk/~cm1822/

ijgruen.pdf

[150] Gustavsson, C. ; Strindlund, L. ; Wiknertz, E.: Veri�cation, Validationand Evaluation of the Virtual Human Markup Language (VHML). 2002

[151] Hansrudi Noser, Daniel T.: A Rule-Based Interactive Behavioral AnimationSystem for Humanoids. In: IEEE Transactions on Visualization and Computer-graphics 5 (1999), Oktober-Dezember, Nr. 4, S. 281�307

[152] Hayashi ; Ueda ; Kurihara ; Yasumura: TVML - Automatic TV programgeneration from text-based script, 1999

[153] Hodgins, J. K. ;Wooten, W. L. ; Brogan, D. C. ; O'Brien, J. F.: Animatinghuman athletics. In: Proceedings of the ACM SIGGRAPH, 1995, 71�78


[154] Huang, J. ; Shi, X. ; Liu, X. ; Zhou, K. ; Wei, L.-Y. ; Teng, S.-H. ; Bao,H. ; Guo, B. ; Shum, H.-Y.: Subspace gradient domain mesh deformation. In:Proceedings of the ACM SIGGRAPH, 2006

[155] Ishida, Toru: Q: A Scenario Description Language for Interactive Agents. In:Computer (2002), Nr. IEEE 0018-9162/02

[156] James, D. L. ; Twigg, C. D.: Skinning mesh animations. In: Proceedings of theACM SIGGRAPH, 2005

[157] Kähler, K. ; Haber, J. ; Yamauchi, H. ; Seidel, H.-P.: Generating animatedhead models with anatomical structure. In: Proceedings of the ACM SIGGRAPH,2002, S. 55�63

[158] Kalra, P. ; Magnenat-Thalmann, N. ; Moccozet, L. ; Sannier, G. ; Au-bel, A. ; Thalmann, D.: Real-time Animation of Realistic Virtual Humans. In:IEEE Computer Graphics & Applications 18 (1998), September � Oktober, Nr.5

[159] Kim, S.-E. ; Lee, R.-H. ; Park, C.-J. ; Lee, I.-H.: MIMIC: Real-Time Marker-Free Motion Capture System to Create an Agent in the Virtual Space. In: ICCE,2002, S. 48�49

[160] Ko, H.-S. ; Choi, K.-J. ; Choi, M. G. ; Tak, S. ; Choe, B. ; Song, O.-Y.:Research problems for creating digital actors. In: Proccedings EUROGRAPHICS2003, 2003

[161] Kopp, S. ; Jung, B. ; Leÿmann, N. ; Wachsmuth, I.: Max - A MultimodalAssistant in Virtual Reality Construction. In: KI 17 (2003), Nr. 4, S. 11

[162] Kry, P. G. ; James, D. L. ; Pai, D. K.: Eigenskin - real time large deformationcharacter skinning in hardware - 2002. In: Proceedings of the ACM SIGGRAPH,2002, S. 153�159

[163] Lee, J. ; Chai, J. ; Reitsma, P. S. A. ; Hodgins, J. K. ; Pollard, N. S.:Interactive control of avatars animated with human motion data, 2002, S. 491�500

[164] Lee, K. H. ; Choi, M. G. ; Lee, J.: Motion Patches: Building Blocks for Vir-tual Environments Annotated with Motion Data. In: Proceedings of the ACMSIGGRAPH Bd. 25, 2006, S. 898�906

[165] Lee, Y. ; Terzopoulos, D. ; Waters, K.: Realistic Modeling for Facial Ani-mations. In: Proceedings of the ACM SIGGRAPH, 1995, S. 55�62

[166] Lester, J. C. ; Voerman, J. L. ; Towns, S. G. ; Callaway,C. B.: Cosmo: A Life-like Animated Pedagogical Agent with Deictic Belie-vability. http://citeseer.ist.psu.edu/184580.html;http://www.dfki.de/

imedia/workshops/anina-contributions/lester.ps.gz. Version:April 231997

[167] Lewis, J. P. ; Cordner, M. ; Fong, N.: Pose space deformation. In: Proceedingsof the ACM SIGGRAPH, 2000, S. 165�172


[168] Lewis, W. ; Shaw, J. E. ; Ganeshan, R.: Pedagogical Agents on the Web. In:Agents, 1999, S. 283�290

[169] Li, N.: Optimierung der Vearbeitung von Avatar-Modellen. 2006

[170] Loftin, R. B. ; Scerbo, M. W. ; McKenzie, F. D. ; Catanzaro, J. M.:Training in Peacekeeping Operations Using Virtual Environments. In: IEEEComputer Graphics and Applications 24 (2004), Nr. 4, S. 18�21

[171] LoPiccolo, P.: What are 'vpeople' for? http://www.temple.edu/ispr/

examples/ex02\_11\_01.html, Abruf: 04.10.2006

[172] Magnenat-Thalmann, N. ; Seo, H. ; Cordier, F.: Automatic Modeling ofAnimatable Virtual Humans - A Survey. In: 3DIM, IEEE Computer Society,2003. � ISBN 0�7695�1991�1, S. 2�11

[173] Magnenat-Thalmann, N. ; Thalmann, D.: Computer Animation. SpringerVerlag, Tokyo, 1990. � 149�152 S.

[174] Mase, K.: Aspects of Interface Agents: Avatar, Assistant and Ac-tor. http://citeseer.ist.psu.edu/604864.html;http://www.mic.atr.co.

jp/~mase/papers/mase97a.pdf. Version: Juli 10 2001

[175] Massaro, D. W. ; Beskow, J. ; Cohen, M. M. ; Fry, C. L. ; Rodri-guez, T.: Picture My Voice: Audio to Visual Speech Synthesis using Arti-�cial Neural Networks. http://citeseer.ist.psu.edu/686918.html;http:

//mambo.ucsc.edu/pdf/avsp9922.pdf. Version: 1999

[176] Massaro, D. W. ; Cohen, M. M. ; Beskow, J. ; Daniel, S.; Cole, R. A.: Developing and Evaluating Conversational Agents.http://citeseer.ist.psu.edu/255558.html;http://cslu.cse.ogi.edu/

publications/./ps/MassaroCole_WECC98.pdf. Version: 2000

[177] Matthews, S. W. ; Miller, K. H.: An open architecture for defense virtualtraining systems. 2003

[178] Mohr, A. ; Gleicher, M.: Building e�cient accurate character skins fromexamples. In: Proceedings of the ACM SIGGRAPH, 2003

[179] Mukai, T. ; Kuriyama, S.: Geostatistical motion interpolation, 2005, S. 1062�1070

[180] Müller, M. ; Heidelberger, B. ; Teschner, M. ; Gross, M. H.: Meshlessdeformations based on shape matching, 2005, S. 471�478

[181] Müller, M. ; Röder, T. ; Clausen, M.: E�cient Content-Based Retrieval ofMotion Capture Data. In: Proceedings of the ACM SIGGRAPH Bd. 24, 2005, S.677�685

[182] Nedel, L. P. ; Thalmann, D.: Modeling and Deformation of the Human Bodyusing an Anatomically-Based Approach. In: CA, 1998, 34�40


[183] Noma, T. ; Badler, N. I.: A Virtual Human Presenter. http:

//citeseer.ist.psu.edu/37965.html;http://www.dfki.de/imedia/

workshops/anina-contributions/noma.ps.gz. Version:April 23 1997

[184] Noma, T. ; Zhao, L. ; Badler, N. I.: Design of a Virtual Human Presenter. In:IEEE Computer Graphics and Applications (2000), Nr. 0272-1716/00, S. 79�83

[185] Ostermann, J. ; Beutnagel, M. ; Fischer, A. ; Wang, Y.: Integration ofTalking Heads and Text-to-Speech synthesizers for visual TTS. In: InternationalConference on Speech and Language Processing (Sydney, Australia), 1998

[186] Panagiotakis, C. ; Tziritas, G.: Construction of animal models and moti-on synthesis in 3d virtual environments using image sequences. In: Proceedingsof the 2nd International Symposium on 3D Data Processing, Visualization, andTransmission, 2004

[187] Pandzic, I. S.: Facial Communication in Networked Collaborative Virtual En-vironments, University Geneva, Diss., 1998

[188] Parke, F. I.: A Parametric Model of Human Faces. Salt Lake City, Universityof Utah, Diss., 1974

[189] Parke, F. I.: Parameterized Models for Facial Animation. In: IEEE ComputerGraphics and Applications (1982), November, S. 61�68

[190] Pelachaud, C. ; Prevost, S.: Talking heads: Physical, Linguistic and Co-gnitive Issues in Facial Animation. http://citeseer.ist.psu.edu/154661.

html;ftp://ftp.cis.upenn.edu/pub/prevost/cgi95/course_main.ps.Z.Version: 1995

[191] Perlin, K. ; Goldberg, A.: Improv: A System for Scripting Interactive Actorsin Virtual Worlds. In: Proceedings of the ACM SIGGRAPH, 1996, 205�216

[192] Pighin, F. ; Hecker, J. ; Lischinski, D. ; Szeliski, R. ; Salesin, D. H.:Synthesizing realistic facial expressions from photographs. In: Proceedings of theACM SIGGRAPH, 1998, S. 75�84

[193] Reiners, D.: OpenSG: A Scene Graph System for Flexible and E�cient Re-altime Rendering for Virtual and Augmented Reality Applications. Darmstadt,Technische Universität Darmstadt, Fachbereich Informatik, Diss., Juni 2002

[194] Remondino, F. ; Roditakis, A.: Human �gure reconstruction and modelingfrom single image or monocular video sequence. In: 4th International Conferenceon 3D Digital Imaging and Modeling (3DIM), 2003

[195] Rickel, J. ; Johnson, W. L. ; Thiebaux, M.: Steve: A Virtual Hu-man for Individual and Team Training. http://citeseer.ist.psu.edu/

490323.html;http://www.isi.edu/~rickel/agents2000/rickel.pdf.Version:April 05 2000

[196] Rickel, J. ; Maresella, S. ; Fratch, J. ; Hill, R. ; Traum, D. ; Swatout,W.: Toward a New Generation of Virtual Humans for Interactive Experiences.17 (2002), Nr. 4, S. 32�38


[197] Rist, T. ; Baldes, S. ; Gebhard, P. ; Kipp, M. ; Klesen, M. ; Rist, P. ;Schmitt, M.: CrossTalk: An Interactive Installation with Animated PresentationAgents. citeseer.ist.psu.edu/rist02crosstalk.html. Version: 2002

[198] Safonova, A. ; Hodgins, J. K. ; Pollard, N. S.: Synthesizing physicallyrealistic human motion in low-dimensional, behavior-speci�c spaces, 2004, S. 514�521

[199] Savenko, A. ; Clapworthy, G.: Using Motion Analysis Techniques for MotionRetargetting. In: IV, 2002, 110

[200] Scheepers, F. ; Parent, R. E. ; Carlson, W. E. ;May, S. F.: Anatomy-BasedModeling of the Human Musculature. In: Proceedings of the ACM SIGGRAPH.New York : ACM Press, August 3�8 1997. � ISBN 0�89791�896�7, S. 163�172

[201] Sederberg, T. W. ; Parry, S. R.: Free-form deformation of solid geometricmodels. In: Proceedings of the ACM SIGGRAPH, 1986, S. 151�160

[202] Seidel, H.-P. ; Koster, M. ; Haber, J.: Real-Time Rendering of Human HairUsing Programmable Graphics Hardware

[203] Shi, L. ; Yu, Y. ; Bell, N. ; Feng, W.-W.: A fast multigrid algorithm for meshdeformation, 2006. � ISSN 0730�0301, S. 1108�1117

[204] Spohr, J.: Lippensynchrone Sprachanimation in Echtzeitanwendungen. 2007

[205] Stephenson, N.: Snow Crash. Wilhelm Goldman Verlag, München, 1994

[206] Suhendra, A.: The development of System for Talking Avatar. Kassel, Univer-sität Kassel, Diss., 2001

[207] Terzopoulos, D. ; Waters, K.: Physically-based facial modeling, analysisand animation. In: The Journal of Visual and Computer Animation 1 (1990), S.73�80

[208] Thalmann, D.: Autonomy and Task-Level Control for Virtual Ac-tors. http://citeseer.ist.psu.edu/581710.html;http://vrlab.epfl.ch/

Publications/pdf/Thalmann_PCS_95.pdf. Version:April 26 2002

[209] Tolani, D. ; Goswami, A. ; Badler, N. I.: Real-Time Inverse KinematicsTechniques for Anthropomorphic Limbs. In: Graphical Models 62 (2000), Nr. 5,S. 353�388

[210] Tsutsui, T. ; Saeyor, S. ; Ishizuka, M.: MPML: A Multimodal Pre-sentation Markup Language with Character Agent Control Functions.http://citeseer.ist.psu.edu/377085.html;http://www.miv.t.u-tokyo.

ac.jp/papers/santiWebNet2000.pdf. Version:November 10 2000

[211] Tümmler, J.: osgLua Quick Reference Guide / Universität Kassel, FachgebietTechnische Informatik. 2006. � Forschungsbericht

[212] Vanroose, P. ; Kalberer, G. A. ; Wambacq, P. ; Gool, L.v.: Fromspeech to 3D face animation. http://citeseer.ist.psu.edu/509547.html.Version: 2002


[213] Verlinden, M. ; Tijsseling, C. ; Frowein, H.: A Signing Avatar on theWWW. In: Gesture and Sign Language in Human-Computer Interaction: Inter-national Gesture Workshop, GW 2001, 2002, S. 169

[214] Verzano, N. ; Mostert, C. ; Tümmler, J.: Interaktive Simulationsplattformim Erkenntnisraum der 'Ganzheitlichen Fabrik' � eine virtuelle Lernumgebung.In: Simulation in Produktion und Logistik 2006, S. Wenzel, 2006, S. 413 � 422

[215] Vlasic, D. ; Brand, M. ; Pfister, H. ; Popovic, J.: Face transfer withmultilinear models, 2005, S. 426�433

[216] Wang, X. C. ; Phillips, C.: Multi weight enveloping - least-squares approxi-mation techniques for skin animation. In: Proceedings of the ACM SIGGRAPH,2002, S. 129�138

[217] Waters, K.: A muscle model for animating three-dimensional facial expression.In: Proceedings of the ACM SIGGRAPH, 1987, S. 17�24

[218] White, S. A.: Process Modeling Notations and Work�ow Patterns.http://www.bpmn.org/Documents/NotationsandWorkflowPatterns.pdf, Ab-ruf: 28.11.2006. � 24�25 S.

[219] Wilhelms, J. ; Gelder, A.v.: Anatomically based modeling. In: Proceedingsof the ACM SIGGRAPH, 1997, S. 173�180

[220] Witkin, A. ; Kass, M.: Spacetime Constraints. In: Proceedings of the ACMSIGGRAPH, 1988, S. 159�168

[221] Wloka, D.: Roboter Systeme 1. Springer�Verlag Berlin Heidelberg, 1992

[222] Wloka, D.: Das Projekt Fahrradtraining, Entwicklung einer interaktiven Si-mulationsumgebung zum Fahrradtraining für Kinder. In: ASIM Nachrichten,ARGESIM, TU Wien (2002), Juni, S. 7�15

[223] Yamane, K. ; Kuffner, J. J. ; Hodgins, J. K.: Synthesizing animations ofhuman manipulation tasks, 2004, S. 532�539

[224] Yasmine Arafa, Abe M. (Hrsg.) ; IEEE Computer Society (Veranst.): Multi-modal Embodied Agents Scripting. Proceedings of the Fourth IEEE InternationalConference on Multimodal Interfaces, 2002

[225] Zordan, V. B. ; Celly, B. ; Chiu, B. ; DiLorenzo, P. C.: Breathe easy: modeland control of simulated respiration for animation. In: SCA '04: Proceedings ofthe 2004 ACM SIGGRAPH/Eurographics symposium on Computer animation.New York, NY, USA : ACM Press, 2004. � ISBN 3�905673�14�2, S. 29�37

[226] Zordan, V. B. ; Majkowska, A. ; Chiu, B. ; Fast, M.: Dynamic response formotion capture animation, 2005. � ISSN 0730�0301, S. 697�701